issue on Send Stop charging using DIN
Closed this issue · 12 comments
Platform: EVSE
Firmware Version: V02_01_00
Host Controller Interface: SPI
Host: Own Implementation
When we send the stop request (send stop) from the host (EVSE) in most DIN vehicles, the stop process takes place normally (Send Stop Notification -> Send Notification Stop ok -> Stop Charging Request -> Stop charging OK -> Welding detection Start Request). But in the tests carried out with the Volvo XC40 and Jac ICCAR, the send stop notification process does not occurs correctly, because when the "send stop notification" is send from the host (EVSE) to codico, the message 'Send Notification Stop ok' is received, but the stop process does not occurs. This requires alternatives forms of stop that generate errors in these vehicles (such as setting the PWM to 100%). But when we changed to ISO the stop process occurs normally in all tested cars (including VOLVO and ICCAR).
***** CHARGE_STOP_REQUESTED CCS MI*****
Send Stop Notification
AA AA 00 0B 55 55 00 00 C0 27 75 01 00 03 00 00 1E BE C1
AA AA 00 00 55 55 00 00 00 00 00 00 00 00 00 00 00 55 55 00 00 C0 27 75 01 00 01 00 DE C1
Send Notification Stop ok
AA AA 00 00 55 55 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 55 00 00 C0 27 85 FF 00 1C 01 DB 00 0E A6 FF 00 01 00 55 01 A0 00 03 C5 FF 01 64 01 50 00 01 01 01 07 08 00 00 99 C1
AA AA 00 00 55 55 00 00 00 00 00 00 00 00 00 00 00 55 55 00 00 C0 27 63 04 00 01 00 ED C1
Update DC Charging parameters OK
AA AA 00 00 55 55 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 55 00 00 C0 27 85 FF 00 1C 01 DB 00 0E A6 FF 00 01 00 55 01 A0 00 03 C6 FF 01 64 01 50 00 01 01 01 07 08 00 00 98 C1
Update EVSE DC Charging
AA AA 00 1C 55 55 00 00 C0 27 63 04 00 14 01 01 96 00 00 60 00 01 00 0A 02 01 00 C8 00 01 00 3C 03 00 CA C1
AA AA 00 00 55 55 00 00 00 00 00 00 00 00 00 00 00 55 55 00 00 C0 27 63 04 00 01 00 ED C1
Update DC Charging parameters OK
Update EVSE DC Charging
AA AA 00 1C 55 55 00 00 C0 27 63 04 00 14 01 01 96 00 00 60 00 01 00 0A 02 01 00 C8 00 01 00 3C 03 00 CA C1
...
...
...
NEVER STOPS
What can we do to resolve this issue?
Thx.
Hey @LeeoMariani,
thank you for reaching out. In order to fully understand this problem I need the V2G logs of the sessions in question. Please follow this guide in order to capture the logs.
Thank you,
lho
Hello,
Here are 3 log files:
File 1:
log debug codico 24.04 ZOE DIN_asc
At lines bellow we can see the stop request from EVSE working fine on Renault Zoe (DIN PROTOCOL).
[ 95.429] [NOTICE] V2GAPP: Stop charging notification requested with timeout of 30s
[ 97.473] [NOTICE] V2GDIN12: EV requested to stop charging.
[ 97.474] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 97.475] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 97.476] [NOTICE] V2GAPP: Received event 'Stop Charging requested'
[ 97.837] [NOTICE] V2GCPS: Change State from C to B
File 2:
log debug codico 24.04 XC40 ISO_asc
At lines bellow we can see the stop request from EVSE working fine on Volvo XC40 (ISO PROTOCOL).
[ 107.306] [NOTICE] V2GAPP: Stop charging notification requested with timeout of 30s
[ 107.363] [NOTICE] V2GISO13: StopCharging request with timeout of 0ms triggered.
[ 107.364] [NOTICE] V2GISO13: Timeout of 0ms for StopCharging request from EVSE reached. EV should stop charging.
[ 107.407] [NOTICE] V2GISO13: EV requested to stop charging.
[ 107.408] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 107.409] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 107.410] [NOTICE] V2GAPP: Received event 'Stop Charging requested'
[ 107.587] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 107.588] [NOTICE] V2GISO13: EV requested to start post charging.
[ 107.589] [NOTICE] V2GAPP: Received event 'Welding Detection started'
[ 107.590] [NOTICE] V2GAPP: stxXBAR_V2G_SendXBARStatus_EmptyMsg() - SubAdd = 0x8B
[ 107.670] [NOTICE] V2GCPS: Change State from C to B
File 3:
log debug codico 24.04 XC40 DIN_asc
At lines bellow we can see the stop request from EVSE not working on Volvo XC40 (DIN PROTOCOL).
[ 801.253] [NOTICE] V2GAPP: Stop charging notification requested with timeout of 30s
[ 802.372] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
[ 802.497] [NOTICE] V2GAPP: Received event 'DC charge parameters changed'
...
...
After 70 seconds we forced the PWM to 100% to stop charging
...
[ 872.063] [NOTICE] V2GCPS: Change State from C to B
[ 872.063] [NOTICE] V2GCPS: stxXBAR_V2GCPS_NotifyHandler()
[ 872.064] [NOTICE] V2GCPS: # V2GCPS_INFOTYPE_CP_STATE
[ 872.065] [NOTICE] V2GCPS: STATE B
The completed files are attached.
Thx
log debug codico 24.04 XC40 ISO_asc.txt
log debug codico 24.04 XC40 DIN_asc.txt
log debug codico 24.04 ZOE DIN_asc.txt
Hi, my guess is that the volvo does not implement this functionality for the DIN70121 standard. The standard does not have a clear requirement for this feature of the protocol.
Any chance to get a wireshark log for the failing session of the Volvo?
Hi,
About "Volvo does not implement this functionality for the DIN70121 standard". I think it's unlikely that this is the case, because the stop is usually on the host side (EVSE). If this were not implemented, the charge would never finished. I think it's more likely that there's a communication failure (timing) between the codico and the car where the car doesn't recognize this Send Notification stop command (0x75 -> C0 27 75 07 00 03 00 00 1E 00 C1). We've tested the same car on an ABB EVSE (using DIN STANDARD) and it stopped correctly. The ABB charger does not use codico board.
About getting wireshark logs for the failing session, we've sent to you the files from CODICO throught Uart and attached on our last comment.
Attached log debug codico 24.04 XC40 DIN_asc again
Thx
Hi @LeeoMariani , the charging is controlled by the EV, so if the EV decides to stop the charging it can do so. What seems to be the issue is the notification the EVSE can set in the EVSEStatus parameter in the charge loop message.
To see the contents of the message we need a wireshark trace. In the guide my collegue mentioned (https://github.com/Sevenstax/FreeV2G/wiki/guide-creating-log-files) you can also find a description on how to capture a wireshark trace.
Complementing the previous message, to stop the charging through the EVSE, we use the command send notification (0x75), which works correctly in other vehicles. In this case of Volvo XC, that the EV doesn't stop after 0x75 ,should we use the update dc charging command (0x63) to stop charging by seting some of the status parameters? (today we send status 0:Ready)
If this is the case, which status should we send?
0: Ready
1: Not ready
2: Shutdown
3: Utility interrupt event
4: Isolation monitoring active
5: Emergency shutdown
6: Malfunction
Thx
Hey @LeeoMariani,
thank you for your effort of creating the log files. Unfortunately I do not see any V2G messages in the log files. Did you enable the port mirror before starting the session? You are using your own implementation, so you need to send the "Set Port Mirror State" message to enable it (please see Whitebeet manual chapter 13.3.10 Set Port Mirror State for more details).
I kindly ask you to enable the port mirror and recreate the log files.
Best regards,
lho
Hi,
Sorry, after enabling the port mirror we restarted our system and re-enabled it for the tests, our fault. Here are the files with Renault ZOE and Volvo XC40 with the port mirror activated and stoping by send notification (0x75) and ** update dc charging command (0x63) + 2: Shutdown**.
Good news!!! We tried to stop charging by changing the “Status” parameters in update dc charging command (0x63) to 2: Shutdown and it worked !!!
Our doubt is if stopping by 2: Shutdown is correct ? Because the correct way to stop on whitebeet manual is just with send notification (0x75) and this worked in all the other cars except Volvo XC40.
Thx
Hello, I'm a SECC SW developer, and I'd like to share some comments what I know.
As you know, unlike the ISO-2, DIN describes explictly as below, (can't use 'EVSENotification' parameter)
[V2G-DC-500] For DC charging according to DIN SPEC 70121, the value of EVSENotification shall always be set to “None".
[V2G-DC-636] For DC charging according to DIN SPEC 70121, the EVCC shall ignore the value of the parameter NotificationMaxDelay in the EVSEStatus.
[V2G-DC-663] If the SECC wishes to stop the Communication Session for a non-critical reason (e.g. user
interaction) after having sent a ContractAuthenticationRes message, the SECC shall send
the next response message with parameter EVSEStatusCode equal to “EVSE_Shutdown“,
even if another requirement in this document specifies that a different value for
EVSEStatusCode shall be used, but the SECC shall not turn off the CP oscillator unless
this is required by another requirement in this document.
NOTE 1 After the SECC informs the EVCC according to [V2G-DC-662] or [V2G-DC-663] that the SECC wishes to stop
the Communication Session, the further steps are controlled by the EVCC according to [V2G-DC-649] and [V2G-DC-650].
but, there's also another comment as,
[V2G-DC-637] All EVSEStatusCodes in Table 68 for which there are no explicit requirements in this document are for information purpose only. They shall not influence the EV charging process.
It's weird(contradiction) to me, but if some EV(EVCC) implementer ignores 'EVSENotification' and 'EVSEStatusCodes' in CurrentDemandRes, I think they may(should) check other parameters - ie, 'EVSEPresentCurrent'(< too low to charging).
Hey @LeeoMariani,
I think @kwoyhope observation is correct. In DIN case the EVSEStatusCode shall be used, the notification is for ISO only. If it is not clear in the Whitebeet manual it will be improved.
If it is working for other manufacturers they might violate the standard here. I need to discuss this internally and will give you an update.
Best regards,
lho