Introduction to OCPP(Open Charge Point Protocol)

Feb 4, 2023

In recent years, electical vehicles have become more and more popular. As a result, the number of charging stations has increased significantly. There is no doubt that this new trend comes with its own challenges. For instance, managing multiple charging stations remotely, monitoring them in real-time, providing a seamless user experience, etc. Of course, those challenges can be addressed by creating backend systems that can communicate with charging stations. Again we have interoperability issues between charging stations and backend systems of different manufacturers. This pushed the industry to come up with a standard protocol that can be used globally. And that’s how OCPP was born. In this article, I will try to explain what OCPP is, how it works, and what are its components. So, let’s get started, shall we?

What is OCPP?

In simple terms, Open Charge Point Protocol (OCPP) is a set of rules that defines how charging stations and backend systems communicate with each other. It is an open standard that is maintained by the Open Charge Alliance. The main goal of OCPP is to provide a common interface between charging stations and backend systems. According to the protocol specs, backend systems called Central System or Charging Station Management Systems (e.g. a backend server) and charging stations called Charge Point which is a physical device that is installed at a charging station.

Below is a topology of a simple OCPP system where two kinds of Charge Points are connected to a Central System. OCPP Topology

OCPP Versions

First version of OCPP was released in 2010. There have been several versions of OCPP since then. The latest version is OCPP 2.0.1. Below is a list of OCPP versions:

Currently, OCPP 1.6 and 2.0.1 are most widely used.

How OCPP works

From now on I will refer to Charging Station Management Systems as CSMS and Charge Point as CP and I will use OCPP 2.0.1 documentations for reference. For beginners, the best way to understand OCPP is to read JSON over WebSockets implementation guide:

As the name of the above document suggests, OCPP uses JSON over WebSockets for communication between CSMS and CP. Let’s translate the phrase “JSON over WebSockets” into plain English.

WebSockets means there can be two types of communication:

CP sends a request to CSMS and gets a response.

     +--------+    request     +--------+
     |        |-------->-------|        |
     |   CP   |                |  CSMS  |
     |        |-------<--------|        |
     +--------+   response     +--------+

CSMS sends a request to CP and get a response.

     +--------+    request     +--------+
     |        |-------<--------|        |
     |   CP   |                |  CSMS  |
     |        |------->--------|        |
     +--------+   response     +--------+

JSON means that all messages are encoded in JSON format. Now, we know data format is JSON. But how do we know which message is a request and which one is a response? The answer is in the message type. In OCPP, we can only use three types of messages:
1. CALL
2. CALLRESULT
3. CALLERROR

In general, when we say JSON, we immediately think of something like below:

{
  "id": "123",
  "name": "John Doe",
}

But OCPP uses json array type for all messages; CALL, CALLRESULT, and CALLERROR. Below are JSON formats of those three types of messages:

  // Message format template
  // CALL
  [<MessageTypeId>, "<MessageId>", "<Action>", {<Payload>}]

  // CALLRESULT
  [<MessageTypeId>, "<MessageId>", {<Payload>}]
  
  // CALLERROR
  [<MessageTypeId>, "<MessageId>", "<errorCode>", "<errorDescription>", {<errorDetails>}]

At this point we can be sure that CALL is a request and CALLRESULT is a response. But what about CALLERROR? It is a response too. But it is a response that indicates an error. For example, CP sends a request (a certain CALL message) to CSMS and CSMS responds with a CALLRESULT message. But if CSMS cannot process the request, it will respond with a CALLERROR message. In simple terms, both CALLRESULT and CALLERROR responses, but one is successful and the other one is not.

Now you might wonder what MessageTypeId, MessageId, Action, Payload, errorCode, errorDescription, and errorDetails are. Let’s learn each of them one by one and construct example messages for each type.

MessageTypeId is an integer value that indicates the type of the message. 2 is for CALL, 3 is for CALLRESULT, and 4 is for CALLERROR. Let’s put this information into a our message format template:

  // Message format template
  // CALL
  [2, "<MessageId>", "<Action>", {<Payload>}]

  // CALLRESULT
  [3, "<MessageId>", {<Payload>}]
  
  // CALLERROR
  [4, "<MessageId>", "<errorCode>", "<errorDescription>", {<errorDetails>}]

Now some might have a light bulb moment and think that following:

Let me imagine I am implementing a CSMS (writing a backend server). I will parse the incoming websocket message and assume it is a JSON array. Then I will check the first element of the array and if it is 2, I will assume it is a CALL message. If it is 3, I will assume it is a CALLRESULT message. If it is 4, I will assume it is a CALLERROR message. Now second element ?

Well, second element is MessageId. It is a string (unique id with max 36 characters) that is used to match a response with a request. For example, CP sends a request to CSMS and CSMS responds with a CALLRESULT message. But how does CSMS know which request this response belongs to? The answer is MessageId. CSMS will put the same MessageId in the response message as it was in the request message. Let’s put this information into our message format template:

  // Message format template
  // CALL
  [2, "7c9dac8f-5e5f-4166-b2f0-8e737bfa1ec7", "<Action>", {<Payload>}]

  // CALLRESULT
  [3, "7c9dac8f-5e5f-4166-b2f0-8e737bfa1ec7", {<Payload>}]
  
  // CALLERROR
  [4, "7c9dac8f-5e5f-4166-b2f0-8e737bfa1ec7", "<errorCode>", "<errorDescription>", {<errorDetails>}]

Now it is time to explain Action and Payload. I will explain them in detail in my next post. Stay tuned!