Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISO15118 support? #24

Open
uhi22 opened this issue Jan 19, 2024 · 23 comments
Open

ISO15118 support? #24

uhi22 opened this issue Jan 19, 2024 · 23 comments

Comments

@uhi22
Copy link
Owner

uhi22 commented Jan 19, 2024

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
Copy link

Mustafa19981903 commented Jan 19, 2024

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
Copy link

@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
Copy link
Owner Author

uhi22 commented Jan 23, 2024

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
Copy link

@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
Copy link
Owner Author

uhi22 commented Jan 23, 2024

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
Copy link

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

@uhi22
Copy link
Owner Author

uhi22 commented Jan 25, 2024

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
Copy link

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

@uhi22
Copy link
Owner Author

uhi22 commented May 28, 2024

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
Copy link

@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
Copy link
Owner Author

uhi22 commented May 31, 2024

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
Copy link

@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
Copy link
Owner Author

uhi22 commented May 31, 2024

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

@Mustafa19981903
Copy link

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

@uhi22
Copy link
Owner Author

uhi22 commented May 31, 2024

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
Copy link

@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
Copy link
Owner Author

uhi22 commented May 31, 2024

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

@Mustafa19981903
Copy link

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

@uhi22
Copy link
Owner Author

uhi22 commented May 31, 2024

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

@Mustafa19981903
Copy link

@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
Copy link

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

@uhi22
Copy link
Owner Author

uhi22 commented Jun 3, 2024

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
Copy link
Owner Author

uhi22 commented Jul 2, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants