Skip to content

Introduction

Upon instantiation, the driver creates a basic Central System Server to which Charge Points can connect. Then, it is required to set up Channels for the request types to be implemented.

The OCPP protocol exchanges can basically be divided in:

  • Requests from Central System → towards Charge Point
  • Requests from Charge Point → towards Central System

Depending on the type of a request specified in the request.type parameter, a different Channel configuration is required.

Central System → Charge Point

This type of requests are mapped in the driver as a single read or write channel operation. As soon as a channel is read/written, the driver sends the OCPP Request to the Charge Point specified in the channel itself (if connected), and waits for a Confirmation from that Charge Point. The result of the operation is then made available in the Channel status.

Read requests

The following OCPP request types must be mapped in a READ channel. It is also required to set the request.json parameter, to be the JSON representation of the corresponding standard OCPP request message. At the end of the channel read, the value will be the Confirmation response in JSON format.

  • GET_CONFIGURATION example json: { "key": [ "...", "..." ] }
  • GET_DIAGNOSTICS example json: { "location": "/upload/path" }
  • GET_LOCAL_LIST_VERSION example json: { } (this request does not include any parameter)
  • GET_COMPOSITE_SCHEDULE example json: { "connectorId": 1, "duration": 60 }

Write requests

The following OCPP request types must be mapped in a WRITE channel. At the end of the channel write, the status of the operation is mapped depending on the resulting Confirmation status.

  • CHANGE_AVAILABILITY Success if confirmation status = Accepted, Scheduled
  • CHANGE_CONFIGURATION Success if confirmation status = Accepted, RebootRequired
  • CLEAR_CACHE Success if confirmation status = Accepted
  • DATA_TRANSFER_REQ Success if confirmation status = Accepted
  • RESET Success if confirmation status = Accepted
  • REMOTE_START_TRANSACTION Success if confirmation status = Accepted
  • REMOTE_STOP_TRANSACTION Success if confirmation status = Accepted
  • UNLOCK_CONNECTOR Success if confirmation status = Unlocked
  • UPDATE_FIRMWARE Success if confirmation arrives
  • SEND_LOCAL_LIST Success if confirmation status = Accepted
  • CANCEL_RESERVATION Success if confirmation status = Accepted
  • RESERVE_NOW Success if confirmation status = Accepted
  • CLEAR_CHARGING_PROFILE Success if confirmation status = Accepted
  • SET_CHARGING_PROFILE Success if confirmation status = Accepted
  • TRIGGER_MESSAGE Success if confirmation status = Accepted

Charge Point → Central System

This type of requests are handled by the driver in two different channel events.

  1. Reception of a request (through a listen channel)
  2. Sending of the Confirmation (through a channel write)

The Request from a Charge Point is first received by the channel which is configured in listen mode with one of the following request types:

  • AUTHORIZE
  • BOOT_NOTIFICATION
  • START_TRANSACTION
  • STOP_TRANSACTION
  • DATA_TRANSFER_CONF
  • STATUS_NOTIFICATION
  • HEARTBEAT
  • METER_VALUES
  • DIAGNOSTICS_STATUS_NOTIFICATION
  • FIRMWARE_STATUS_NOTIFICATION

The OCPP Request is then wrapped in a OcppDriverRequest object containing an arbitrary ID of the request just received (requestId). Example JSON:

/* OcppDriverRequest */
{
    "requestId": "1c08e3ce-1273-11ed-861d-0242ac120002",
    "chargePointId": "/CP1",
    "requestType": "AUTHORIZE", /* as above */
    "request": /* object representing the Standard OCPP Request */
}

Such object is then emitted out of the Asset. At this point, it is required to implement an external system that can process this request and generate a corresponding OCPP Confirmation. Once generated, the OCPP Confirmation must be wrapped in a OcppDriverResponse object containing the corresponding requestId:

/* OcppDriverResponse */
{
    "requestId": "1c08e3ce-1273-11ed-861d-0242ac120002",
    "confirmation": /* object representing the Standard OCPP Confirmation */
}

This response must be written to a channel with the corresponding request type and charge point ID (for simplicity, the listen channel and WRITE channel could even be the same).

In summary:

  1. The driver receives an OCPP Request from a Charge Point through a listen channel;
  2. This request is wrapped in a OcppDriverRequest object and emitted out;
  3. The OcppDriverRequest should be sent to an external system that is able to process it;
  4. The external system produces a OcppDriverResponse;
  5. The OcppDriverResponse is received from the external system, and written to the corresponding channel;
  6. The OCPP Confirmation is sent back to the Charge Point.