Simplified explanation of OCPP 1.6 messages

February 12, 2020 ,

 

OCPP 1.6 introduces the use of JSON over WebSockets. SOAP is also supported but is almost obsolete, no new station hardware support it. The biggest change from 1.5 to 1.6 is the Smart Charging using Charging Profiles and new statuses.

It has 6 profiles (7 if you include the new security profile):

  1. Core
  2. Firmware Management
  3. Local Auth List Management
  4. Remote Trigger
  5. Reservation
  6. Smart Charging

In order to indicate which side initiates the messages, I will use the following notation:

  • CP→ CS [Initiated by the CP, CS sends the response]
  • CS → CP [Initiated by the CS, CP sends the response]
Note:
-CP stands for Charge point hardware
-CS stands for Charge station management system (CSMS) backend

Will go through each of these profiles in detail below:

Core Profile

Core profile includes all the messages required to make use of the basic functionality of the OCPP. Core profile includes following messages:

  • Authorize —CP → CS. Used to check the authorization status of an idTag. IdTag is basically a user identifier to start/stop charge sessions.
  • BootNotification —CP → CS. Sent when the CP boots up, contains information about the charging station such as firmware version, IMSI/ICCID values, Vendor/Model/SerialNumber information etc.
  • ChangeAvailability — CS → CP. Used to change the CP’s availability to OPERATIVE or INOPERATIVE.
  • ChangeConfiguration —CS → CP. CP has a bunch of configuration items defined by the OCPP (They may also be extended by the vendor). This message is used to change these configurations if they’re not readonly.
  • ClearCache — Initiated by the CS to clear Authorization Cache.
  • DataTransfer — Allows custom messages to be sent. Vendor specific commands are usually implemented using this message. It’s the only two-way message in the protocol, which means it can be initiated by both sides.
  • GetConfiguration — CS → CP. Just like ChangeConfigurations, this message is used to read the contents of the configuration items. If there are vendor-specific configurations, they may also be included in the response of this message.
  • Heartbeat — CP → CS. It is used to inform that CP is still alive. It’s response contains the current time which means this message is used to sync time between Central Station and CP as well. Heartbeat is used as a custom ping-pong since WebSocket’s ping pong is not implemented by some CP vendors.
  • MeterValues —CP → CS. It informs the Central Station about the charging status. It may also be used to detect energy leaks between charge sessions. While this is a transactional message it can still be sent without a transaction (Can either be triggered or through ClockAligned Meter Values).
  • RemoteStartTransaction — CS → CP. Used to start a transaction remotely.
  • RemoteStopTransaction — CS → CP. Used to end a transaction remotely.
  • Reset — CS → CP. Used to reboot the CP. It has two options, Soft and Hard reset.
  • StartTransaction —CP → CS. This message is sent at the start of a transaction(charge session) to inform the Central Station. Response to this message includes a transaction id which is used with the rest of the transactional messages.
  • StatusNotification —CP → CS. Informs the Central Station about the current status of the CP. Currently there are 9 Statuses: AVAILABLE, PREPARING, CHARGING, SUSPENDEDEV, SUSPENDEDEVSE, FINISHING, RESERVED, UNAVAILABLE, FAULTED.
  • StopTransaction —CP → CS. This message is sent at the end of a transaction to inform the Central Station.
  • UnlockConnector — CS → CP. It is used to unlock the connector of a CP remotely, ending the charge session in the process.

Firmware Management Profile

This profile is about updating the firmware of the CP and getting diagnostics logs when required. There are 4 messages related to Firmware Management:

  1. UpdateFirmware — CS → CP. This is the actual message to perform a software upgrade on CP. It contains a link to the firmware file’s location (Usually ftp, since it’s recommended by the specification but http/https may also be used) and a date to indicate when this upgrade package should be downloaded. It also contains some optional fields such as retry count in case download attempt fails for some reason, and a retryInterval to indicate how long the CP should wait between each download retry attempt.
  2. FirmwareStatusNotification — CP → CS. This message is useful for letting the Central Station know about the current update status. It can also be triggered by the Central Station with TriggerMessage.
  3. GetDiagnostics — CS → CP. Used to retrieve diagnostics logs of the CP. Its fields are similar to UpdateFirmware, the only difference is that this message contains two optional fields called startTime and stopTime to indicate which log interval should be uploaded by the CP. OCPP doesn’t define which logs should be kept, so it’s up to the CP to decide what kind of information is logged. Because of that, log format and contents are vendor-specific and as a result of that they may vary a lot.
  4. DiagnosticsStatusNotification — CP → CS. This message is basically the same as FirmwareStatusNotification. It indicates the current diagnostics upload status. Same as FirmwareStatusNotification, this message can also be triggered.

Local Auth List Management Profile

There are some configurations and features to reduce the message traffic between CS/CP and allow CP to operate when its network connection is lost. Local Authentication List is one of these feature as it’s used to send some of the authorization list from to CP so it can perform authorization without needing the CS. There are 2 messages related to this profile:

  1. SendLocalList — CS → CP. This message is used to send the authentication list to CP. This message may contain a full list or a partial list that updates the authentication list that is already on the CP. This message contains a version number to keep track of which local list version is installed on the CP.
  2. GetLocalListVersion — CS → CP. This message queries the local list version set by the SendLocalList.

Remote Trigger Profile

There is a single message under this profile called TriggerMessage that is used to trigger a specific message in case it’s needed. TriggerMessage is sent from CS to CP and may be used to trigger the following message:

  • BootNotification
  • DiagnosticsStatusNotification
  • FirmwareStatusNotification
  • Heartbeat
  • MeterValues
  • StatusNotification

Reservation

This profile is responsible for reserving a connector on the CP. Unfortunately, OCPP 1.6 does not support scheduling a reservation for a future date, it can only reserve at the exact time of reservation. This profile contains following messages:

  1. ReserveNow — CS → CP. Used to reserve a connector or change the reservation information on an already reserved connector. Once this message is sent, it is either accepted or rejected
  2. CancelReservation — CS → CP. Used to cancel a reservation.

SmartCharging

This is the most complicated of all profiles but still I will briefly talk about each message even though there are a lot of vague parts of the profile. The profile is all about controlling the power consumption by limiting charging parameters. It is used to provide hard upper limits to power/current and some of the profiles can be used in combination with each other. Also supports time-based profiles so that CP can be configured to behave differently depending on time of the day. Charging profiles can be stacked, this stack level indicates their priority level.

  1. SetChargingProfile — CS → CP. This message sends a charging profile to a for a connector. Charging Profiles may be generic or transaction-specific. Transaction-specific profiles can also be sent within a RemoteStartTransaction message. This message contains information about when the charging profile should be activated, when it will expire, its stack level, recurrency information and the actual charging schedule. ChargingSchedule contains the numeric values to limit/control the charge, at which point of the day it will be activated and how long it will stay active.
  2. ClearChargingProfile — CS → CP. Used to remove an installed charging profile from the device.
  3. GetCompositeSchedule — CS → CP. This message requests the profile scheduling information for a duration of time. Response to this message contains which profiles will be activated and when during that duration. It’s basically the smart charging plan for a duration of time.

Configuration Keys

Each profile contains a set of configuration keys to define how the CP should behave. They can get quite complicated as some of them interact with each other. Some of these keys are read-only that can only be configured by the CP and cannot be changed with ChangeConfiguration message. Configuration keys control things like whether some functionality should be enabled or disabled, meter value intervals and which meter values should be sent, upper bounds to some other configurations, etc.


Security profile is comparatively new and is not discussed here in this article. If you're looking at OCA certification, below are the implementation requirements need to be fulfilled. 



Post a Comment

No comments

Subscribe to: Post Comments ( Atom )
Powered by Blogger.