OCPP integration to transmit digitally signed readings - has·to·be eMobility
Talk to us

OCPP integration to transmit digitally signed readings

Charging stations must transmit digitally signed readings to a central backend system. With this specification, we explain the implementation of the compatibility with be.ENERGISED for the transmission of the readings. This process can be used by all market participants.

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 readings

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>

OCPP 1.6 SOAP: MeterValue request including digitally signed meter values

{
  "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>

OCPP 1.6 SOAP: StopTransaction request including digitally signed meter values

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:

Key Type Description
connectorId required Defines the connectorId analogously to the OCPP specification for assigning the measuring capsule to a charging port
meterSerial optional Specifies the serial number of the measuring capsule. The deployment thereof can provide a history
type required Defines the type of legal framework to comply with calibration compliance
publicKey optional Contains the public key of the measuring capsule – the transmission must be Hex-encoded.
The field is required if the value “SIGNATURE" is used as “Type".

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>

DataTransfer Request in order to submit meter configurations to the backend

{
  "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

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:

Type Procedure
SIGNATURE Carrying out a digital signature for measurements in conjunction with a transparency software
LOCAL Local storage and display module that implements the requirements of the calibration law at the station
NONE No calibration law compliant execution, allows flat-rate billing