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

Clarify formatting of EVCCID in ID field #23

Open
mhei opened this issue Jul 7, 2023 · 5 comments
Open

Clarify formatting of EVCCID in ID field #23

mhei opened this issue Jul 7, 2023 · 5 comments

Comments

@mhei
Copy link
Contributor

mhei commented Jul 7, 2023

Table 16 contains as possible option the identification type EVCCID. In the referenced ISO15118 standard, this is the MAC address of the connected EV which is 6 byte (not 6 character) long.
In my understanding, the description is wrong: I guess that the intent was to have the MAC address formatted as hex-string, so the wording should be changed to in German:

ID eines Elektrofahrzeugs.
Bei Verwendung der ISO/IEC 15118 dargestellt als 6 Bytes
in hexadezimaler Schreibweise, z.B. "01234567ABCD".
Bei Verwendung von OppCharge (siehe V2G2-OC-189_1) dargestellt
als 8 ASCII-Zeichen, z.B. "VN123456".

When the ongoing PRs are merged, I'd open a PR to adapt this.

@simonschllng
Copy link
Collaborator

To be precise, it is not the ID of the vehicle but the ID/MAC of the EVCC.

It contains the MAC address of the EVCC

Also, the MAC is not static and defined for a different application. Thus it is being misused here.

A media access control address (MAC address) is a unique identifier assigned to a network interface controller (NIC) for use as a network address in communications within a network segment.
(…)
Many network interfaces, however, support changing their MAC address.
https://en.wikipedia.org/wiki/MAC_address

I propose to include a proper description and a warning.

Also it is not recommended to use two different representations depending on external factors. It should be transformed to a single representation.

Netzwerk-Adresse des verwendeten Ladecontrollers während des Ladevorgangs.
Dargestellt als 6 Bytes in hexadezimaler Schreibweise, z.B. "01234567ABCD".
Achtung: Diese ID kann nicht sicher zur Benutzerzuordnung verwendet werden, 
da die darin enthaltenen Daten dazu nicht vorgesehen sind.

@mhei
Copy link
Contributor Author

mhei commented Jul 18, 2023

To be precise, it is not the ID of the vehicle but the ID/MAC of the EVCC.

That's true. Especially in case the EV has Wifi onboard etc. pp. then mentioning the "Ladecontroller" makes absolute sense.

It contains the MAC address of the EVCC

Also, the MAC is not static and defined for a different application. Thus it is being misused here.

There are indeed vendors who do not use static MAC addresses for the EVCC. And yes, the original application of the MAC addresses is the network connection, not as identification for billing.
I don't want to judge about a "misuse" here - effectively it is "lived practice", e.g. when used with Autocharge.

I propose to include a proper description and a warning.

I partly agree: a proper description is fine, but a warning is not justified in my eyes: as mentioned, it is reality that EVs are identified with their MAC addresses. To be honest, I don't know whether Autocharge is already part of any Eichrecht-certified solution of any charging station vendor.
But if we warn here that MAC addresses could be forged, then we must included a warning about forged UIDs of RFID cards, too.

Also it is not recommended to use two different representations depending on external factors. It should be transformed to a single representation.

I do not agree. It is a fact that different standards use the same name with different content. Fortunately, the content used is a clear indication of the standard used (length of content, characters used). It's not pretty, I'll admit, but cramming it into a consistent format would only make the situation worse. I suggest that standards bodies do more thinking in the future, especially when standards are related.

@ahzf
Copy link

ahzf commented Jul 18, 2023

We have in Europe PSD2 for any kind of payment. A MAC address is not even mentioned there. AutoCharge therefore cyber crime and you all have to go to jail for supporting this.

Sure, RFID UIDs are also stupid, but at least we can have many RFID cards. There is only one MAC address.

@simonschllng
Copy link
Collaborator

But if we warn here that MAC addresses could be forged, then we must included a warning about forged UIDs of RFID cards, too.
No, the warning should be about the misuse.

I do not agree. It is a fact that different standards use the same name with different content.
Then it would be good to make it two different properties explicitly.

@mhei
Copy link
Contributor Author

mhei commented Jul 19, 2023

We have in Europe PSD2 for any kind of payment.
A MAC address is not even mentioned there.

This is a helpful hint. I did not read into it, probably I should.

AutoCharge therefore cyber crime and you all have to go to jail for supporting this.

What should we do with such a sentence? What is your proposal? Please elaborate!

Sure, RFID UIDs are also stupid, but at least we can have many RFID cards. There is only one MAC address.

According to my knowledge, Autocharge is an opt-in for each user - nobody forces you to link your charging account with one or more EVs.

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

3 participants