Slow EXI conversion during CurrentDemandResponse in DIN
kojtp2 opened this issue · comments
According to DIN specification Table 75 CurrentDemandRes should take 25ms. Looking on the log on the EVSE side (DC charging) it looks like it takes ~250ms to respond to CurrentDemandRequest in DIN-based data exchange. i.e.:
DEBUG 2022-11-06 00:56:20,985 - iso15118.shared.exi_codec (282): EXI-encoded message (ns=urn:din:70121:2012:MsgDef): 809a0219ba2bf5b89f4c5ad0d1401200881e0192d8080323e8109463c2019004464b602000
DEBUG 2022-11-06 00:56:21,161 - iso15118.shared.exi_codec (299): Decoded message (ns=urn:din:70121:2012:MsgDef): {"V2G_Message":{"Header":{"SessionID":"66E8AFD6E27D316B"},"Body":{"CurrentDemandReq":{"DC_EVStatus":{"EVReady":true,"EVErrorCode":"NO_ERROR","EVRESSSOC":72},"EVTargetCurrent":{"Multiplier":-1,"Value":15},"EVMaximumVoltageLimit":{"Multiplier":0,"Value":310},"EVMaximumCurrentLimit":{"Multiplier":0,"Value":125},"EVMaximumPowerLimit":{"Multiplier":1,"Value":3875},"ChargingComplete":false,"RemainingTimeToFullSoC":{"Multiplier":0,"Value":1},"EVTargetVoltage":{"Multiplier":0,"Value":310}}}}}
INFO 2022-11-06 00:56:21,162 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:56:21,163 - root (782): Send Charging Command
DEBUG 2022-11-06 00:56:21,167 - iso15118.shared.exi_codec (245): Message to encode (ns=urn:din:70121:2012:MsgDef): {"V2G_Message": {"Header": {"SessionID": "66E8AFD6E27D316B"}, "Body": {"CurrentDemandRes": {"ResponseCode": "OK", "DC_EVSEStatus": {"NotificationMaxDelay": 0, "EVSENotification": "None", "EVSEIsolationStatus": "Valid", "EVSEStatusCode": "EVSE_Ready"}, "EVSEPresentVoltage": {"Value": 2857, "Multiplier": -1, "Unit": "V"}, "EVSEPresentCurrent": {"Value": 34, "Multiplier": -1, "Unit": "A"}, "EVSECurrentLimitAchieved": false, "EVSEVoltageLimitAchieved": false, "EVSEPowerLimitAchieved": false}}}}
DEBUG 2022-11-06 00:56:21,403 - iso15118.shared.exi_codec (256): EXI-encoded message: 809a0219ba2bf5b89f4c5ad0e00040800001028548b01018110000c0
INFO 2022-11-06 00:56:21,404 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
DEBUG 2022-11-06 00:56:21,552 - iso15118.shared.exi_codec (282): EXI-encoded message (ns=urn:din:70121:2012:MsgDef): 809a0219ba2bf5b89f4c5ad0d1401200881e0192d8080323e8109463c2019004464b602000
DEBUG 2022-11-06 00:56:21,736 - iso15118.shared.exi_codec (299): Decoded message (ns=urn:din:70121:2012:MsgDef): {"V2G_Message":{"Header":{"SessionID":"66E8AFD6E27D316B"},"Body":{"CurrentDemandReq":{"DC_EVStatus":{"EVReady":true,"EVErrorCode":"NO_ERROR","EVRESSSOC":72},"EVTargetCurrent":{"Multiplier":-1,"Value":15},"EVMaximumVoltageLimit":{"Multiplier":0,"Value":310},"EVMaximumCurrentLimit":{"Multiplier":0,"Value":125},"EVMaximumPowerLimit":{"Multiplier":1,"Value":3875},"ChargingComplete":false,"RemainingTimeToFullSoC":{"Multiplier":0,"Value":1},"EVTargetVoltage":{"Multiplier":0,"Value":310}}}}}
INFO 2022-11-06 00:56:21,738 - iso15118.shared.comm_session (231): CurrentDemandReq received
Unfortunately, after 5 seconds from the first CurrentDemandReq / Res, the car reports "ReadyToChargeState": false, which causes the charging to stop, even though the charging parameters are met by the power unit during these 5 seconds.
Could the duration of the response be the reason why the EV disconnects?
Is 250ms conversion time okay? It was tested on RPi CM4, clean debian, no additional programs running in the background.
I'll try and give this a go on my raspberry pi and see what I get (sometime this week(end) ) and update it here. As a test, could you switch LOG_LEVEL to INFO in the .env file and also set MESSAGE_LOG_EXI to False and retry, please? I believe you have already checked if there is anything else consuming memory, disabled GUI etc.
In Josev_pro we use a Rust version of the EXI codec (which is blazing fast) which is available with Josev_pro.
@shalinnijel2 yes, I checked if logging in anyway slowed down the conversion performance and it looks like it doesn't have a big impact. I didn't mention it before, but I run it natively, not in a container.
Log below:
INFO 2022-11-06 00:33:24,317 - iso15118.shared.comm_session (231): PreChargeReq received
INFO 2022-11-06 00:33:24,522 - iso15118.shared.comm_session (415): Sending PreChargeRes
INFO 2022-11-06 00:33:24,843 - iso15118.shared.comm_session (231): PowerDeliveryReq received
INFO 2022-11-06 00:33:24,844 - iso15118.shared.states (137): Entered state PowerDelivery
INFO 2022-11-06 00:33:24,845 - iso15118.shared.states (141): Waiting for up to 60.0 s
DEBUG 2022-11-06 00:33:24,845 - iso15118.secc.states.din_spec_states (652): ChargeProgress set to Ready
INFO 2022-11-06 00:33:25,067 - iso15118.shared.comm_session (415): Sending PowerDeliveryRes
INFO 2022-11-06 00:33:25,070 - iso15118.shared.states (137): Entered state CurrentDemand
INFO 2022-11-06 00:33:25,072 - iso15118.shared.states (141): Waiting for up to 60.0 s
INFO 2022-11-06 00:33:25,311 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:25,564 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:25,833 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:26,082 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:26,415 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:26,645 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:26,981 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:27,157 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:27,505 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:27,685 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:27,983 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:28,164 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:28,464 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:28,696 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:29,009 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:29,119 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:29,281 - iso15118.shared.comm_session (231): PowerDeliveryReq received
INFO 2022-11-06 00:33:29,283 - iso15118.shared.states (137): Entered state PowerDelivery
INFO 2022-11-06 00:33:29,285 - iso15118.shared.states (141): Waiting for up to 60.0 s
DEBUG 2022-11-06 00:33:29,286 - iso15118.secc.states.din_spec_states (652): ChargeProgress set to Stopping
DEBUG 2022-11-06 00:33:29,287 - iso15118.secc.states.din_spec_states (669): PowerDeliveryReq ready_to_charge field set to false. Stay in this state and expect WeldingDetectionReq/SessionStopReq
Hello there, same issue from my side. Especially during a tesla charge, average timing of a currentDemandRes is 100ms in a dual core celeron.
Digging up a little bit with the code, the most demanding thing in term of timing is the exi conversion (obviously..)
Tesla waits circa 4 minutes and after stops the charge without saying anything, simply turning up the CP value to 9V.
The timings with the ISO protocol are pretty similar and the charging process runs smoothly.
Any suggestion?
Hi @lovalova1991, the fact is that the Java EXI codec is too slow to keep up with the DC timing constraints...the community version primarily intention was to provide a reference implementation of the ISO and DIN and in terms of performance is not suitable for field testing. As mentioned, by Shalin, in the josev_pro version we are using a proprietary battle tested Rust version of the codec, which outperforms the Java version.
I have the intention of, in the near future, to include bindings to the OpenV2G C based EXI codec: https://github.com/chargebyte/openv2g for the community version, but for now I would suggest the following:
- Test with Python 3.11 - Python 3.11 has a big performance boost in comparison to its predecessors: https://docs.python.org/3/whatsnew/3.11.html#summary-release-highlights
- Try testing it in a more powerful target
Let me know your results, if you try it. Thanks!
A question around this. Is the exificient coded as implemented in the JAR file a "plain vanilla" implementation?
One of the guys in our team might be able to work in the reference implementation of exificient that's available in C++....but if the jar file has changes from the plain vanilla exificient implementation then he'd need to know about them.