Add support for the SAFE XML and Open Charge Metering Format (OCMF)

[ahzf]

Some customers want to use Chargy for charging stations using the OCMF v1.0 format

• [ ] Support OCMF transport via chargeIT JSON container
• [x] Support OCMF transport via SAFE XML container
• [ ] Parse and display OCMF transparency data
• [ ] Verify OCMF signatures

[ahzf]

Limitations: OCMF supports only a single digital signature. Therefore combining multiple OCMF data sets into a single OCMF charging data set (signed meter values from at least start and end of charging) is not possible.

[ahzf]

ABL's suggestion on combining multiple signed meter values is to wrap it into some XML: https://has-to-be.com/de/development-resources/transparenzsoftware/dateiformat-datensatz/

[ahzf]

The current https://transparenz.software version 1.0 seems not to understand its own XML when the defined XML namespace is used: https://has-to-be.com/de/development-resources/transparenzsoftware/dateiformat-datensatz/

Unclear how to go on here. This is a showstopper bug!

[SirVer]

@ahzf Achim, I am actually experimenting with Chargy right now and have XML files that load fine in the transparenzsoftware.jar, but fail to load in chargy. I provide here a full session (start & stop meter message) for your analysis, maybe it is useful to make this work in chargy too.

I am actually trying to understand how the signature that is embedded in the SML messages is actually verified. Chargy does not seem to have an SML parser, so to get to the signature would actually require to add that as well.

<?xml version="1.0" encoding="UTF-8" ?>
<values>
    <value context="Transaction.Begin" transactionId="2604">
    <signedData encoding="plain" format="SML_EDL40_P">1b1b1b1b01010101760500000001620062007263010176010431323303000f0b0901454d4800008f7ea00101637f4400760500000002620062007263070177010b0901454d4800008f7ea0078180817103ff72620165000acf9f7477078182815401ff0172620373655ebb9c1a53003c53003c01010b9110105ebb9be85c0dd80177070100011100ff6400000872620373655ebb9c3853003c53003c621e52ff56000001e9d40177078100600800010101010172620172620165000acf750177078180817101ff0101010165000000dd018304d2c65603b2f620c8553508721c782b0ffea6aab9a12b8e37ff2fe01a2081d24151ea9f3d057a934043c79996f16fd751011001639e97007605000000036200620072630201710163a8e60000001b1b1b1b1a028188</signedData>
    <publicKey>8c5e765f2f03847381d4f4b893a4d3caf6e28a67b86ca660adaf22be99e29b79fb99027143966303b1f15ab944ba7bd1</publicKey>
</value>
<value context="Transaction.End" transactionId="2604">
    <signedData encoding="plain" format="SML_EDL40_P">1b1b1b1b01010101760500000001620062007263010176010431323303007f0b0901454d4800008f7ea0010163787400760500000002620062007263070177010b0901454d4800008f7ea0078180817103ff72620165000ad0297477078182815401ff0172620373655ebb9c1a53003c53003c01010b9110105ebb9be85c0dd80177070100011100ff6400000872620373655ebb9cc153003c53003c621e52ff56000001e9d40177078100600800010101010172620172620165000acffe0177078180817101ff0101010165000000de018304cc92a5fa65b7db0162d7ea5b0fd7cf44aad152f50ea6559da395d5d550253bbd90365829e83e816d378c00859f66e67f011001638c8c007605000000036200620072630201710163a8e60000001b1b1b1b1a02afc6</signedData>
    <publicKey>8c5e765f2f03847381d4f4b893a4d3caf6e28a67b86ca660adaf22be99e29b79fb99027143966303b1f15ab944ba7bd1</publicKey>
</value>
</values>

[ahzf]

Thank you for providing me this example... now I can implement it :) You find a rough documentation how to decode it here: https://github.com/OpenChargingCloud/ChargyDesktopApp/blob/v1.1/documentation/EDL40plus/sml-decoded.txt

[SerhioLanister]

@ahzf Hi, I am trying to upload the file for verification to Chargy, but I receive an Error "Unbekanntes Transparenzdatensatzformat!". I am not sure which data format should I use here. Can you help me with that?

[ahzf]

Hi, unfortunately not all vendors are very cooperative and use some kind of extensions. But you can mail me your data set and I will take a look what causes this problem.

[SerhioLanister]

@ahzf This data is from electrical meter. The point is that I only have the content of the file, I didn't find any hint in specification what is the extension should be. I tried .txt or .xml for website https://chargy.chargeit-mobility.com/. There is also no hints in website, what is the correct file extension.

[ahzf]

When it come directly from a smart meter, then most likely it will only a single signed meter value, or? In e-mobility (German calibration law) we need at least the start and end value of the charging process. So you would have to wrap it into a container. There is at least the chargeIT JSON container format and the SAFE XML container format.

[pmartens-EnerCharge]

I think there was a misunderstanding in implementation of the OCMF xml parser. We generated an OCMF XML-file that can be succesfully verified in the SAFE-eV transparenzsoftware, using the defined format: https://github.com/SAFE-eV/transparenzsoftware/blob/master/XML_Format.md tested with Transparenzsoftware 1.2.0

The Chargy Desktop App gives the error "at least two OCMF measurements are required". But the measurements (start-transaction, start-charge, stop-charge & stop-transaction) are all included in a single transaction. As described in the OCMF standard: https://github.com/SAFE-eV/OCMF-Open-Charge-Metering-Format/blob/master/OCMF-de.md

You can store multiple different transactions (from different charge transactions) in a single XML, using multiple 'value'-elements. Not multiple value elements for a single transaction.

Here is are two OCMF-examples that are verifiable using the SAFE-eV transparenzsoftware: ocmf-examples.zip

[ahzf]

@pmartens-EnerCharge Yes, you can store multiple whatevers in this XML and the SAFE software does whatever with it. But what is the use case and what the end user benefit of this? The German PTB always speaks of charging sessions and thus there must always be at least 2 signed measurements. The SAFE XML does not allow you to differentiate two charging sessions, nor you can visually tell if the 4 measurements within your screen shot are 2 charging sessions with 2 measurements each, or 1 charging session with 4 measurements.

Sure, you can have multiple measurements within a single OCMF clob and some charging station vendors just return a single OCMF clob at the end of a charging session to the end user. But we did not expect, that someone might use it this way, as this is against the security concepts of the German Calibration Law, as the starting measurement should be send to the end user in the exact moment when the charging sessions starts. This way is is much harder for an attacker or a bad charging station operator to manipulate consecutive measurements. Even when we all know, that this requirement is also mostly unavailable in most roaming protocols/networks.

This is btw. why Chargy TS exists: The SAFE software allows things and displays things in a way no end user will ever understand. This way they drive the entire benefits of the German Calibration Law intentionally ad absurdum.

We also can only implement what we see in the wild, when we have a contract with a charging station manufacturer adopting his/her interpretation of OCMP+XML or his/her own data format or when someone sends us some test data. Sometimes it is really frightening to see how some people have implemented OCMF ;) This "feature" of a single OCMF clob having multiple measurements will for sure be part of one of the next software versions... but with a warning, that this data uses "unsecure practises".