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.

[pe-jenguidanos]

I am trying to generate the CertificateInstallationRes message from an OCPP server, but Josev fails when comparing the eMAID fragment, which does not match. I have no problem with the other three fragments in this message. While looking for a solution, I came across this issue.

@barsnick, you mentioned that you were working on this – could you please let me know if there has been any progress since then or if there is a planned timeline for a fix?

[kwoyhope]

@pe-jenguidanos , I guess this issue is not easy to fix on cbexigen side, but you could modify generated C sources to support correctly.

[andcaspe]

Hi everyone!

I’ve tried to address this issue in pull request.

It’s true that this doesn’t solve the root cause of the problem, but it could serve as a temporary workaround until a proper grammar-level solution is implemented.

I hope this helps!