ISO15118 support?

[uhi22]

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:

• Copy and adapt the state machines in pyPLC, so that we have state machines for DIN and for ISO.
• Extend the command line interface of OpenV2Gx to support also the ISO.
  If the latest ISO shall be supported, we would need to search for an actual EXI codec. Maybe looking to everest what they do.

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]

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]

@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]

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]

@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]

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]

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

[uhi22]

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]

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

[uhi22]

Yes, started some ISO related additions to pyPLC (latest is this: 7e86812) 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]

@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]

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:

Then the pyPLC will only talk ISO 2013. Not really tested at the moment, so I expect some findings.

[Mustafa19981903]

@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]

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

[Mustafa19981903]

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

[uhi22]

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]

@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]

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

[Mustafa19981903]

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

[uhi22]

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

[Mustafa19981903]

@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]

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

[uhi22]

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]

Regarding the ISO15118-20 support, cross-linking another exi decoder mentioned here: ChargePoint/wireshark-v2g#56 (comment)