Signed meter values and "public key"

This article is intended to explain how digitally signed values should be transmitted to the be.ENERGISED backend so that they can be processed correctly.

Introduction

The transmission of digitally signed readings is a basic requirement that a charging device must support in order to meet the legal calibration requirements. With our guide to creating digital signatures for readings, we have presented a process that enables signature formation via a measurement data set.

With the following specification, we clarify the requirements of how the digitally signed readings are transmitted to the backend system by the charging station. The transmission of the measurements is based on the following considerations – the data transmission of measurement information should be economical. This means that the transmission of data on individual charges or individual readings should be as low as possible in order to save data volume. However, in order to allow automation in the validation of readings, it is necessary that certain parameters are made available to the backend system. To ensure this, the charging station provides this information to the backend after the first boot-up notification.

Below are the requirements that ensure data transfer and allow automated data processing and verification.

Data transfer of signed values

Digitally signed readings are transmitted from the charging station to the backend system with each charging process, with either a single or in several distributed messages. The respective data is summarised in a measurement data set and then digitally signed by the measurement capsule. The signed data is then transmitted to the backend system via the OCPP protocol.

The be.ENERGISED application supports the adoption of digitally signed readings both via individual MeterValue Requests and collected in the form of the StopTransaction Request at the end of a charging process. The data format of the digitally signed measurements is identical for all transmissions.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:ns="urn://Ocpp/Cs/2015/10/">
   <soap:Header>
      <ns:chargeBoxIdentity>ABCDEF12345</ns:chargeBoxIdentity>
   </soap:Header>
   <soap:Body>
      <ns:meterValuesRequest>
         <ns:connectorId>1</ns:connectorId>
         <ns:transactionId>1234567</ns:transactionId>
         <ns:meterValue>
            <ns:timestamp>2018-08-02T08:58:21Z</ns:timestamp>
            <ns:sampledValue>
               <ns:value>ENCODED STRING</ns:value>
               <ns:context>Transaction.Begin</ns:context>
               <ns:format>SignedData</ns:format>
               <ns:measurand>Energy.Active.Import.Register</ns:measurand>
            </ns:sampledValue>
         </ns:meterValue>
      </ns:meterValuesRequest>
   </soap:Body>
</soap:Envelope>

{
  "connectorId": 1,
  "transactionId": 1234567,
  "meterValue": [
    {
      "timestamp": "2018-08-02T08:58:21Z",
      "sampledValue": [
        {
          "value": "ENCODED STRING",
          "format": "SignedData",
          "context": "Transaction.Begin",
          "measurand": "Energy.Active.Import.Register"
        }
      ]
    }
  ]
}

OCPP 1.6 JSON: MeterValue request including digitally signed meter values

The example above transmits a single measurement value for a charging operation to the central backend system. The measurement is transmitted in accordance with the OCPP specification and provided with the correct context. In this case, the “value" field contains the hex-coded string of the signature dataset without additional information.

As an alternative to individual MeterValue messages, it is also possible to transmit the digitally signed readings to the backend system with the StopTransaction at the end of a charging process. In this case, the handling takes place analogously to the previously executed structures, with the exception that these are “packaged" into the relevant StopTransaction message.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:ns="urn://Ocpp/Cs/2015/10/">
   <soap:Header>
      <ns:chargeBoxIdentity>ABCDEF12345</ns:chargeBoxIdentity>
   </soap:Header>
   <soap:Body>
      <ns:stopTransactionRequest>
         <ns:transactionId>1234567</ns:transactionId>
         <ns:timestamp>2018-08-02T08:58:21Z</ns:timestamp>
         <ns:meterStop>2500</ns:meterStop>
         <ns:transactionData>
            <ns:timestamp>2018-08-02T08:58:21Z</ns:timestamp>
            <!--1 or more repetitions:-->
            <ns:sampledValue>
               <ns:value>ENCODED STRING</ns:value>
               <ns:context>Transaction.Begin</ns:context>
               <ns:format>SignedData</ns:format>
               <ns:measurand>Energy.Active.Import.Register</ns:measurand>
            </ns:sampledValue>
            <ns:sampledValue>
               <ns:value>ENCODED STRING</ns:value>
               <ns:context>Transaction.End</ns:context>
               <ns:format>SignedData</ns:format>
               <ns:measurand>Energy.Active.Import.Register</ns:measurand>
            </ns:sampledValue>
         </ns:transactionData>
      </ns:stopTransactionRequest>
   </soap:Body>
</soap:Envelope>

On this basis, it should be noted that the time-stamp for the readings is not processed by the backend system, since the time of the measurement, which is documented within the digital signature, is processed for further processing. If a signature format is used that allows the signature of multiple readings in a single dataset (for example, OCMF), then it is permissible for a StopTransaction to use a single dataset with an overarching dataset signature.

Data transfer of the basic data from a charging device

The automated data processing in the backend requires that the charging station provide the backend system with certain data that enables the following automated data processing. This data is the basic operational data required to implement and process the signature procedures.

The general data for processing the measurement signature only needs to be transmitted to the backend system once.

However, to ensure consistency, it is advisable to transfer the data to the backend system immediately after sending a boot-up notification. This ensures that the readings can be transmitted on the basis of the correct data. A charging station may not transmit digitally signed readings to the backend system unless the general data on the signature method has been successfully transmitted to the backend system beforehand.

In the course of the data transfer to the backend system, it is planned to transmit the relevant data to the backend system in a structured form by means of a DataTransfer message.

The following data is processed by the charging device and sent to the backend system.

{
    "meters": [
        {
            "connectorId" : 1,
            "meterSerial" : "123456789",
            "type": "SIGNATURE",
            "publicKey": "887FABF407AC82782EEFFF2220C2F856AEB0BC22364BBCC6B55761911ED651D1A922BADA88818C9671AFEE7094D7F536",
        }
    ]
}

Configuration dataset for setMeterConfiguration dataTransfer request

With a single DataTransfer message, any amount of information on the procedures used can be transmitted. With the format implementation, it is also possible to ensure different calibration requirements on different charging ports. This data format summarises the general information that needs to be provided by a charging device. The structured data contains the following information:

The structured data shown above is subsequently “packaged" into a DataTransfer message by the charging device and sent to the backend system. The transmission is based on the respective OCPP specification, which is used for the connection of the charging device. The following examples show the transmission of the previously shown dataset in conjunction with OCPP 1.6 on SOAP and JSON.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:ns="urn://Ocpp/Cs/2015/10/">
   <soap:Header>
      <ns:chargeBoxIdentity>ABCDEF12345</ns:chargeBoxIdentity>
   </soap:Header>
   <soap:Body>
      <ns:DataTransferRequest>
         <ns:vendorId>generalConfiguration</ns:vendorId>
         <ns:messageId>setMeterConfiguration</ns:messageId>
         <ns:data>{"meters":[{"connectorId":1,"meterSerial":"123456789","type":"SIGNATURE","publicKey":"887FABF407AC82782EEFFF2220C2F856AEB0BC22364BBCC6B55761911ED651D1A922BADA88818C9671AFEE7094D7F536"}]}</ns:data>
      </ns:DataTransferRequest>
   </soap:Body>
</soap:Envelope>

{
  "vendorId": "generalConfiguration",
  "messageId": "setMeterConfiguration",
  "data": "{\"meters\":[{\"connectorId\":1,\"meterSerial\":\"123456789\",\"type\":\"SIGNATURE\",\"publicKey\":\"887FABF407AC82782EEFFF2220C2F856AEB0BC22364BBCC6B55761911ED651D1A922BADA88818C9671AFEE7094D7F536\"}]}"
}

DataTransfer Request in order to submit meter configurations to the backend

Public Key

There are multiple ways how a station can deliver public keys, which are listed as below:

1. Deliver the public key within the signed values (preferred way)

The public keys could be forwarded within the signed values. This enables each application to know the public key at any point in time. This also the format that station need to implement in OCPP 2.0.1 therefore this is our preferred way.

An example (here part of the stop transaction, can also be a regular MeterValue)

[2,"1234",
"StopTransaction",
{"reason":"Local","transactionId":123,"meterStop":500,"timestamp":"2022-08-27T12:34:56.000Z","transactionData":[
{"sampledValue":[
{"unit":"Wh","context":"Transaction.End","format":"SignedData","location":"Outlet","measurand":"Energy.Active.Import.Register",
"value":"
{
\"signedMeterValue\": \"<base64 encoded OCMF string>\", 
\"encodingMethod\":\"OCMF\", 
\"publicKey\":\"<public key>\"
}"
}],
"timestamp":"2022-08-27T12:34:56.000Z"}]}
]

2. Deliver via datatransfer

Stations can send us a DataTransfer request. Each connector here receives a public key which will be then used. A station should send this after the BootNotification.

Payload of the DataTransfer:

{
"vendorId": "generalConfiguration",
"messageId": "setMeterConfiguration",
"data": "{\"meters\":[{\"connectorId\":1,\"meterSerial\":\"123456789\",\"type\":\"SIGNATURE\",\"publicKey\":\"887FABF407AC82782EEFFF2220C2F856AEB0BC22364BBCC6B55761911ED651D1A922BADA88818C9671AFEE7094D7F536\"}]}"
}

3. Via the config keys transmitted in the GetConfiguration request

Via the config keys transmitted in the GetConfiguration request

• PublicKey{nr}
• PublicKey-EnergyMeter{nr}
• MeterPublicKey{nr}
• MeterPubKey{nr}
• publicKeyMeter{nr}
• EMOC_PublicKey_Conn_{nr}
• Meter{nr}PublicKey
• Meter_{nr}_PublicKey
• metergatewaycon{nr}publickey
• Keys where the public keys are separated via a “,” (e.g. key1, key2, key3)
• VWGC.DCMeterPublicKeys
• VWGC.DCMeterPublicKeys
• VWGC.DCMeterPublicKeysOcmf
• metersPublicKeys
• meterPublicKeys
• publicKey

Permitted legal framework for calibration law compliance

In the course of the implementation of the requirements of measurement and calibration law in Germany, various technical processes are supported, which make it legally permissible to bill charging processes. In order to obtain an automated configuration of the backend systems and an appropriate clarity on the legal frameworks used, it is envisaged that the charging device will transmit the type of method used.

Overall, according to our current knowledge, the following procedures are legally permissible:

1. Digital signature of a reading of a measurement device in conjunction with the provision of conformity assessed transparency software
2. Local storage and display of readings directly at the charging device
3. No calibration compliant execution and thus the possibility of flat-rate billing

Based on these foundations, the following types of implementation of the legal framework can be transmitted to the backend system in the current implementation of the charging device: