Hello to the community.
I noticed that the length of the array that hosts the eMAID in the PaymentDetailsReq message (https://sourceforge.net/p/openv2g/code/HEAD/tree/trunk/src/iso1/iso1EXIDatatypes.h#l1044) is set to 15 or 16 depending on the string encoding (ASCII or UCS). This is the same for both iso1EXIDatatypes.h and iso2EXIDatatypes.h.
According to Annex H, Section H.1.2 of document ISO15118-2:2016 the eMAID can be minimum 14 or maximum (including optional seperators) 18 characters long.
On the other hand, the official V2GCIMsgDataTypes.xsd included in the document ISO15118-2:2016 states that the eMAID can have a minimum length of 14 and maximum 15 characters. I hereby attach the part from the V2GCIMsgDataTypes.xsd:
<xs:simpleType name="eMAIDType">
<xs:restriction base="xs:string">
<xs:minLength value="14"/>
<xs:maxLength value="15"/>
</xs:restriction>
</xs:simpleType>
We can see that there is an incosistency between the text and the XSD specification in the offical ISO15118-2:2016 document (I mentioned the inconsistency also to the ISO15118 group).
However, from the open-v2g perspective wouldn't be better if the size of the array hosting the eMAID is equal to 18 bytes long (that is to the maximum possible)? This would prevent memory issues like overflow or loosing information if the EV sends an eMAID which is more than 15 bytes long.
Looking forward for your comments and since this is my first post I would like to thank tha authors and contributors of the open-v2g library. It helps a lot on the developement of anytging related to ISO15118.
Best,
Platon Efstathiadis
Mhh, there seems to be a discrepancy between XML schema and the prose around it or in Annex. I guess it should be first clarified whether the XML schema is correct or the annex.
When it come to ASCII vs. UCS the difference comes from the fact that ASCII is terminated by a null terminator \0 while UCS is not. Does this clarify the concern.
Thank you for raising the issue with the ISO15118 group.
Please keep us informed about the fix.
Thanks,
-- Daniel
Thank you for your reply Daniel. As soon as I have any news from the ISO15118 group I will post them here.
Since we mention also the ASCII and UCS, I found also a problem there. Should I open a different ticket for that?
Yes, please open yet another ticket if there is another unrelated ASCII/UCS issue.
I have closed the ticket. Please open it again if not resolved.