fragment encoding of EMAIDType(15118-2)

[kwoyhope]

I can see your comment about 'eMAID'(ISO 15118-2) in config.py, but it seems that there is an unresolved(remaining) issue.

As you already know, EMAIDType != eMAIDType.
eMAIDType : "Annex H.1 e-Mobility Account Identifier (EMAID)", for PaymentDetailsReq, CertificateUpdateReq
<xs:simpleType name="eMAIDType">
<xs:restriction base="xs:string">
<xs:minLength value="14"/>
<xs:maxLength value="15"/>
</xs:restriction>
</xs:simpleType>

EMAIDType : "8.5.2.30 EMAIDType", for CertificateUpdateRes, CertificateInstallationRes
<xs:complexType name="EMAIDType">
xs:simpleContent
<xs:extension base="eMAIDType">
<xs:attribute name="Id" type="xs:ID" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>

I've tested cbV2G with EMAIDType = {"id4","DEABCC123ABC56"}, and exi output is "80EC02B4B21A041111505090D0CC4C8CD05090CD4D9E80"(same as old(bug) OpenV2G).
Correct(latest OpenV2G and SwitchEV) output is "80EC0202B4B21A40041111505090D0CC4C8CD05090CD4DBD3D00".

FYI, there was almost same issue at OpenV2G.
(https://sourceforge.net/p/openv2g/tickets/11/, https://sourceforge.net/p/openv2g/code/109/)

Please check it further for interoperability(compliance) with others.

[gaohtao]

Unfortunately, I ran into the same eMAID field coding error.
For the CertificateInstallationReq/Res in iso15118-2, I use Trilog ComboCS to test testcase. ComboCS verifies signature after received CertificateInstallationRes, and then an error has occurred to the eMAID field: the eMAID's digest in CertificateInstallationRes and eMAID's digest calculated by ComboCS are inconsistent. It is clear that the exi encoding of the eMAID field causes the digest to differ.

[gaohtao]

This is the test data:
{"eMAID": {"Id": "id4", "value": "FRTRIC00618333C"}}

Using cbexigen encoding results:

message= b'{"eMAID": {"Id": "id4", "value": "FRTRIC00618333C"}}'
namespace= b'urn:iso:15118:2:2013:MsgDef'
command = eMAID
encode ret1= 0
stream.byte_pos =23
dataReq (24 bytes):
+------------------------------------------------------------------------------+
| Offset : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF |
+------------------------------------------------------------------------------+
| 00000000: 80 EC 02 B4 B2 1A 04 51 94 95 14 92 50 CC 0C 0D .......Q....P... |
| 00000010: 8C 4E 0C CC CC D0 DE 80 .N...... |
+------------------------------------------------------------------------------+

The result encoded with ExiCodec.jar:

=============== exi_codec.encode ================
msgName= eMAID
namespace= urn:iso:15118:2:2013:MsgDef
json= {"eMAID": {"Id": "id4", "value": "FRTRIC00618333C"}}
encoded_message.length = 27
[ 0x80, 0xEC, 0x02, 0x02, 0xB4, 0xB2, 0x1A, 0x40, 0x04, 0x51, 0x94, 0x95, 0x14, 0x92, 0x50, 0xCC, 0x0C, 0x0D, 0x8C, 0x4E, 0x0C, 0xCC, 0xCC, 0xD0, 0xFD, 0x3D, 0x00, ]

These errors are in the same position as the above problem, please research to solve！

[kwoyhope]

@barsnick , would you mind checking this issue? (what is current status?)

[barsnick]

Hi @kwoyhope,
coincidentally, we are working on this right now. We probably cannot fix it this year though, as vacations are coming soon.

EXI and some stupid decisions for the ISO XML schemas really make this the most complicated case one can think of.

[kwoyhope]

Hi @kwoyhope, coincidentally, we are working on this right now. We probably cannot fix it this year though, as vacations are coming soon.

EXI and some stupid decisions for the ISO XML schemas really make this the most complicated case one can think of.

Thanks for sharing your status, and have a happy year end vacation.