CCS2 Controller failed at CableCheck state Topic is solved

[peternooy]

Hi,
I have a prototype of CCS2 controller (EVCC) up and running. I'm in the process of compatibility testing of my V2G stack with real DC charger installed in my area. The test set up is fairly simple my EVCC box only connect with CP and PE line and leave PP and High volt DC pin unconnected.

So far I manage to successfully initiate a dummy charging session with ABB Terra (50kw and 120kw) and Efaces charger, everything work fine form SLAC till session termination. Attached is the pcap file for ABB session

However with IES Keywatt60x, the session failed at CableCheck state, with a negative response code of FAILED_SequenceError, see a snippet of V2G message below

CableCheckReq:

CableCheckRes:

EDIT:
I add the design guide showing how thing should look like at this stage, my CP line has 5.7v in state C which should be in tolerance range and please note that the DC pin is left open during my test.




Does anyone has any idea of where should I look for clue to troubleshoot this?

[CCSknowitall]

Sequence error means the other side requested a message type out of order.

Some stations only require one back and forth in Charge Parameter Discovery before moving on to cable check. Others require multiple messages, and will signify this in charge parameter discovery response messages with EVSE processing status of “ongoing”. Once you get a message from the EVSE that says “finished” you can then change to state C and send cable check request.

For the single back and forth, the first Charge Parameter Discovery response will come back with “finished”.

I think ABB and Efacec only do one back and forth, but IES may do more. With out seeing a PCAP of the failed session, this is my best guess as to what’s happening.

[peternooy]

Sequence error means the other side requested a message type out of order.

Some stations only require one back and forth in Charge Parameter Discovery before moving on to cable check. Others require multiple messages, and will signify this in charge parameter discovery response messages with EVSE processing status of “ongoing”. Once you get a message from the EVSE that says “finished” you can then change to state C and send cable check request.

For the single back and forth, the first Charge Parameter Discovery response will come back with “finished”.

I think ABB and Efacec only do one back and forth, but IES may do more. With out seeing a PCAP of the failed session, this is my best guess as to what’s happening.

Thanks for look into this, very appreciate

Your input on IES may require multiple messages during Charge Parameter Discovery sound valid. This may indicate bugs in my implementation to handle this scenario, will check the code again and report back soon.

The pcap file for IES session is attached.

[peternooy]

I forgot to mention, the last response message from IES also indicate that the insulation testing is ongoing and few second later it show error screen, this may be due to my side terminate the session, see attached picture.

[CCSknowitall]

Just looked at the IES PCAP and... yep. That's what's happening.

You seem to be handling this correctly in contract authentication (same mechanism) so hopefully it's an easy fix.

[peternooy]

You are truly expert on this, kudos.

I have found the bug, will fix it and let you know the result.

BTW: It appeared that ABB also require multiple messages during Charge Parameter Discovery state, but it probably more forgiven to this type of error and let the session continue.

[peternooy]

This subject is resolved now, thanks CCSknowitall for his advice. Test sessions pcap file is attached.

[Jack Bauer]

Would you mind sharing some information and details on your project please? We are big on opensource and knowledge sharing here on openinverter:)

[peternooy]

I'm developing commercial SECC and EVCC, so not all details can be revealed (there is an NDA on my contract ).

This project is based on RISE-V2G-1.2.6, running on Raspberry pi with QCA-7000 PLC and CAN interface board ( I ordered from China via AliExpress). At this stage I have a prototype of a 30kw CCS2 DC Charger and a CCS2 controller for EV car.

For V2G stack, I use RISE-V2G-1.2.6 as it provide both side of protocol stack which make prototyping of SECC and EVCC very convenient.

RISE-V2G-1.2.6 is a good piece of SW, nice code structure and need very minimum tweak to make it work. The drawback is, it only support ISO 15118 and my customer need both ISO 15118 and DIN 70121 capability in the final product. So I have to add modification to make it support DIN 70121 as well.

BTW: RISE-V2G is abandoned now, there is new project called Josev (from same team that made RISE-V2G) which look very promising and I plan to switch to it soon. Link here: https://github.com/SwitchEV/josev

Hope this is good to start with.

[YRstar]

The charge parameter discovery response says EVSE processing as "ongoing" and all the parameters are still 0. The Cable check request message must be send only after the message element EVSE processing has changed to finished with Response Code as Ok. Charge parameter discovery request must be send again by the client until the EVSE processing changes to finished and then cable check request shall be send