In recent years, there has been an energy crisis; natural gas prices have skyrocketed in various parts of the world. In Europe specifically, prices went up as far as +231% in Czechia and +165% in Romania. The lowest increases were recorded in Croatia and Slovakia, and even though they were lower than in other parts of the world, they were significant, +14% and +18% respectively. With those increases, many people have turned towards renewable energy. It offers lower long-time costs, and it has the added benefit of not polluting the world (as much as natural gas pollutes). While the interest for renewable energy has always been around, now it is present more than ever.

For example, the automotive industry is now focusing on developing and manufacturing cars that run on electricity. While in the past the adaptation of electric vehicles (EVs in further text) has been slow, recently it has gained traction, most notably in Nordic countries such as Sweden, Norway, and Denmark. The number of electric vehicles is projected to rapidly increase in Nordic countries, Central Europe and North America. As the market is expanding there is also a sharp increase in manufacturers who develop their own charging units for EVs.

There are charging units both for personal and commercial use. The user can control them using his phone or computer. Each manufacturer offers their own API for controlling these charging points. If we, for example, had 3 different charging points from three different manufacturers, we would have to implement three different API handlers to control our devices. As an alternative and solution to the problem above, the Open Charge Alliance developed a standard protocol for all charging stations - OCPP (Open Charge Point Protocol).

OCPP is a protocol that enables direct communication with charging points. It is based on the already existing WebSocket protocol, but it has a strictly defined schema of messages (further down in the text we will talk about some of those messages). That means that, if we were to send a message which doesn’t follow the schema, the charging point would not accept it, and would return an error instead.

The protocol has different versions and variations, the most common one is OCPP 1.6 in its JSON variation. It is also possible to send SOAP messages via OCPP, but it isn’t as often implemented on the charging points. While OCPP 1.6 is the most common, there is also a newer version of OCPP - 2.0. The new version expands on the already existing protocol with major changes. As of today, it hasn’t yet seen widespread adaptation, but that will likely change in the future.

In order to communicate with a charge point we need to have a Central Management System (CMS in the further text). The CMS can receive messages from the charging point and it can also send messages, to trigger specific commands on the charging point. The CMS is essentially a WebSocket server, which keeps track of the connections with the charging points. Also, it can store relevant messages from the charger and issue out commands. A REST API, which is available to the end user, is usually used for issuing commands to the charger.

If a user wants to connect their charger to a CMS, they have to configure their charger and point it towards the CMS, using the CMS WebSocket URL. The user can do that either through the manufacturer's app or by connecting their device to a computer and entering its settings. The URL usually looks like this:

wss://server.io/ocpp
Copy

The ‘’wss'' prefix indicates a secure WebSocket connection, most devices require secure connections, but there are also those who accept non-secure ones.

There are three elements that communicate when charging an EV. First, the EV connects to the charger via a socket, and then the charging point changes its internal state from Available to Preparing and notifies the CMS about it, using a StatusNotification message. Of course, the communication goes both ways, when the CMS receives the message it replies with a configuration message as a way to confirm that it received the message.

Those are just two examples of communication via OCPP. We will now take a look at charging point-initiated calls and CMS-initiated calls.

Here we have an example of communication initiated by the charging point. The charging point would like to initiate charging. It’s important to note that in OCPP, a charging session is called a transaction. For the charger to start a transaction it has to authorize the call, and wait for confirmation from the CMS. The CMS confirms with a corresponding configuration, which contains a message indicating if the request sent by the charger is Accepted or Rejected. The same process is repeated for each request the charger sends. The charger always has to wait for the CMS to reply. The charger can be configured to work on its own if it's offline, but when it gets back online it has to notify the CMS about its actions.

Relevant charging point initiated calls:

• Heartbeat.req - this request is sent periodically based on the HeartbeatInterval configuration key, and it's used to keep the WebSocket connection alive, it’s similar to the usual PingPong message in WebSocket
• BootNotification.req - notifies the CMS that the charger has booted and provides it with information about its firmware, serial number and other important properties
• StatusNotification.req - notifies the CMS about the charger's status, this is relevant because the CMS can confirm or deny some calls based on the charger's status, for example, we wouldn’t want to start a transaction if there is an already ongoing one
• MeterValues.req - this request is sent periodically during a transaction and it shows us values such as the current Power, Current, Battery Percentage…
• StartTransaction.req
• StopTransaction.req

Here we have an example of a CMS-initiated call. Here the charge point sends its configuration message to the CMS, again with an *Accepted *or Rejected status. While the rest of the flow after that stays the same as in the charger initiated calls.

Relevant CMS initiated calls:

• GetConfiguration.req - with this request we can ask the charging point to send us its configuration keys and their values
• ChangeConfiguration.req - this is used for changing a configuration key, in OCPP 1.6 only one configuration key at a time can be changed, in OCPP 2.0 it is possible to change multiple keys with one request
• SetChargingProfile.req - using this request we can set a transaction profile, transaction profiles are used for limiting the chargers Current (A) and Power (W) outputs
• MessageTrigger.req - when sending this request we can trigger certain charging point initiated calls from the CMS side, those calls are the aforementioned BootNotification, Heartbeat, MeterValues and StatusNotification
• DataTransfer.req - this request is used for custom messages, some manufacturers can implement new messages outside of the regular OCPP schema, those messages are sent via the DataTransfer request
• StartRemoteTransaction.req
• StopRemoteTransaction.req

An example of the TriggerMessage request and response payloads:

{
    "requestedMessage": MessageTrigger,
    "connectorId"?: integer
}
Copy

{
    "status": TriggerMessageStatus
}
Copy

While the OCPP protocol offers many commands and options it isn’t yet fully implemented in many chargers, often manufacturers only implement the minimum needed for the OCPP certification. For the official subset certification, only some of the core functionality has to be satisfied, while many of the really useful features such as SmartCharging, which takes care of transaction profiles, are optional.

OCPP is a very capable and useful protocol which is gaining popularity because of its generic approach of direct communication with charging points. And while it isn’t fully implemented everywhere yet, it sure will be in the future, as more and more people switch to EVs and more and more chargers exist. See you on our blog on the next topic.