uhi22 / pyPLC

Electric vehicle CCS charging investigations with Python
GNU General Public License v3.0
125 stars 29 forks source link

ISO15118 support? #24

Open uhi22 opened 6 months ago

uhi22 commented 6 months ago

At the moment, pyPLC/OpenV2Gx only support the DIN protocol.

Is it possible to add support for ISO15118, too?

Some discussion on this: https://openinverter.org/forum/viewtopic.php?p=50180#p50180 https://openinverter.org/forum/viewtopic.php?p=50183#p50183 https://openinverter.org/forum/viewtopic.php?p=54026#p54026 https://openinverter.org/forum/viewtopic.php?p=54047#p54047

Current conclusion: Yes, "some kind of ISO15118" is doable with the current approach, but not the latest versions of the ISO15118. It is not clear, whether the ISO part of OpenV2G already includes all wished features.

If we want to go this way, the following steps are necessary:

Regarding necessity / motivation: At the moment (2024), the chargers and cars seem to support DIN, and the hope is, that this will be continue for the next years. At least the chargers should support DIN "forever", because there are a lot of cars on the streets which are DIN-only. Maybe new cars omit the DIN and will support ISO only. Which ISO-only-features would be relevant? Plug-and-charge, yes. This requires also the handling of certificates.

Mustafa19981903 commented 6 months ago

I am writing for the situation mentioned in the last message. I tested it with a 2023 model vehicle and the vehicle supports both dinspec70121 and iso15118.

"msgName": "supportedAppProtocolReq", "info": "68 bytes to convert", "error": "", "result": "Vehicle supports 2 protocols. ProtocolEntry#1 ProtocolNamespace=urn:din:70121:2012:MsgDef Version=2.0 SchemaID=1 Priority=2 ProtocolEntry#2 ProtocolNamespace=urn:iso:15118:2:2013:MsgDef Version=2.0 SchemaID=0 Priority=1 ", "schema": "appHandshake", "AppProtocol_arrayLen": "2", "NameSpace_0": "urn:din:70121:2012:MsgDef", "Version_0": "2.0", "SchemaID_0": "1", "Priority_0": "2", "NameSpace_1": "urn:iso:15118:2:2013:MsgDef", "Version_1": "2.0", "SchemaID_1": "0", "Priority_1": "1", "debug": "" }

Mustafa19981903 commented 6 months ago

@uhi22 By using extension files in the OpenV2Gx file, the main_commandlineinterface.c file was created to support the command line interface of OpenV2Gx. Can we create a main_commandlineinterface.c file to support the command line interface for iso15118 by using the iso1 and iso2 libraries FOUND AS OPEN SOURCE in the OpenV2G file?

uhi22 commented 6 months ago

Nearly. I propose that after compiling, we have one executable that supports DIN and ISO. So the plan would be to extend the main_commandlineinterface.c in a way that is able to handle both cases. And, because it is already big, create a separate file like commandlineinterface_iso.c, where the decoder- and encoder functions for ISO are living. This is already partly prepared, e.g. in runTheDecoder() we have already the case with decode_iso1ExiDocument() and decode_iso2ExiDocument(), the missing part for the decoder direction is the translation of the structures into JSON, translateDocIso1ToJson() etc. In the other direction, in runTheEncoder(), the cases for ISO are also prepared. The missing part is adding a switch-case for the different messages, similar to "case 'D':", and writing the encoder functions.

But: We should be aware that this version of ISO is a quite old one, we see in https://github.com/Martin-P/OpenV2G in the change history of 0.9.3: "15118-2-2016 (ISO2) started besides 15118-2-2013 (ISO1) and DIN". So it is not clear how good is the ISO2 (2016) implementation, and for sure it does not contain the features of more recent ISO versions.

Mustafa19981903 commented 6 months ago

@uhi22 thank you for the answer I tried 3 different tools and all of them gave output like this: "NameSpace_1": "urn:iso:15118:2:2013:MsgDef". Currently, 2023 model electric vehicles support the iso:15118:2:2013 protocol. I will try to implement and improve your suggestions.

uhi22 commented 6 months ago

Yes, this confirms the very slow development cycles in automotive industry, I even saw that brand new 2023 car only supports DIN, not even ISO:2013. Thanks for taking care and good luck.

Mustafa19981903 commented 6 months ago

@uhi22 Is there an ISO 15118 protocol document? I will be very happy if you share it with me

uhi22 commented 6 months ago

I was not able to find a public copy, and the copy which I have is personalized and with a strict copyright. So no, I cannot share this. There seem to be different conditions from country to country how to purchase this document, and to which price. Also universities may offer free access for their students.

(Edit) A part is here, but only the first seven pages: https://cdn.standards.iteh.ai/samples/69114/1ea2bc5fc804423aab1142617a361e9c/ISO-DIS-15118-2.pdf

Mustafa19981903 commented 2 months ago

@uhi22 Are there any current developments regarding this issue? It seems like it would be better to get support from here and continue.

uhi22 commented 2 months ago

Yes, started some ISO related additions to pyPLC (latest is this: https://github.com/uhi22/pyPLC/commit/7e86812032d5643fc57e6e6405781ee8ca282a1a) and OpenV2Gx. The intermediate goal was to run the complete charging session with ISO1 (aka ISO 2013), when using Clara (https://github.com/uhi22/ccs32clara) as car and pyPLC as charger. This works in the meanwhile on the desk. Nothing tested with real cars or real chargers. The car side of the ISO is not implemented at all in pyPLC and OpenV2Gx. I do not plan updates at the moment into the ISO direction, but would be happy about pull requests for improvements.

Mustafa19981903 commented 2 months ago

@uhi22 As far as I understand now, fsmevse.py ISO 2013 has some add-ons. I have my system ready to try in the real-time vehicle. I can always do real-time vehicle testing. I have a few questions, can the schema continue with ISO instead of DIN with the added section? I can provide all kinds of support regarding updates and development.

uhi22 commented 1 month ago

Is your plan to use pyPLC on charger side, to test it with a car on the other side? Or use pyPLC in the vehicle to test with real chargers? In case you use pyPLC on the charger side and have a real vehicle which announces DIN and ISO, the pyPLC will decide for DIN in the current implementation. To test the ISO, you can make the pyPLC ignoring the DIN, by removing these lines in fsmEvse.py: image Then the pyPLC will only talk ISO 2013. Not really tested at the moment, so I expect some findings.

Mustafa19981903 commented 1 month ago

@uhi22 I ran it in the test environment, but pyPlc.py P S only supported DIN spec. I'm going to test it in a real vehicle right now. I will test the iso 2013 scheme

uhi22 commented 1 month ago

Yes, in pevmode the pyPlc only supports DIN at the moment

Mustafa19981903 commented 1 month ago

iso.txt I ran fsmevse with the iso in real time and the results are as in the file

uhi22 commented 1 month ago

Very good. Using the ISO it runs into PreCharge, this is more than I expected for the first real world test. The car stops the session after a lot of precharge loops. We send the correct EVSEPresentVoltage. I guess the car wants to see physical voltage on the CCS inlet, and since there is none, it stops. Is this different when using the DIN schema?

Mustafa19981903 commented 1 month ago

@uhi22 Likewise with the DIN diagram. It does not continue after the Precharge message. The vehicle is waiting for a physical voltage at the CCS DC+ DC- terminals. It reacts the same when I run it with DIN and ISO. When I supply DC voltage with the power module, it will probably switch to the CurrentDemand message.

uhi22 commented 1 month ago

Do you have the chance to test this, with both DIN and ISO?

Mustafa19981903 commented 1 month ago

din.txt I tested it with din and it was stuck in the precharge section as well.

uhi22 commented 1 month ago

Did you apply 431V at the CCS inlet? With the correct polarity?

Mustafa19981903 commented 1 month ago

@uhi22 I did not apply it, I made the target voltage value sent by the vehicle the same as the current voltage value. I tried to move on to the next message but I couldn't succeed.

Mustafa19981903 commented 1 month ago

iso1.txt @uhi22 user action XF86Mail gave the following output. When I did the ISO test, it gave an output like this.

uhi22 commented 1 month ago

The "user action" says that the pyPLC detected that something was pressed on the keyboard. EG button x for exit. I have no clue what xf86mail means. Edit: I think this is just the mail button, https://wiki.linuxquestions.org/wiki/XF86_keyboard_symbols

uhi22 commented 3 weeks ago

Regarding the ISO15118-20 support, cross-linking another exi decoder mentioned here: https://github.com/ChargePoint/wireshark-v2g/issues/56#issuecomment-1974086665