This document introduces the technical foundation for OCPP 2.0.1. We will cover terminology, technologies, format of messages, and support channels.
OCPP is an industry protocol for electric vehicle charging stations (CS) to communicate with some external application, normally referred to as a charging station management system (CSMS) or back-end. Protocol means that it’s a definition of communication, in this case in the form of request and response messages which are expected to be sent by either party in specific scenarios such as a charging session. OCPP is developed and maintained by the Open Charge Alliance (OCA), an industry group based in the Netherlands who collectively develop, maintain, and test the protocols.
Implementers of the protocol on the CS side are usually charging station manufacturers, although there are some firmware specific development companies which then sell licenses to the manufacturers. On the CSMS side the industry is more fragmented, with several software-as-a-service (SaaS) companies selling their systems to charging network operators and other operators choosing to build their own in-house.
While the CS software can have a variety of features, such as local load balancing, there is typically a lot more variety and experimentation on the CSMS side due to its position typically as a cloud hosted app. There are a countless number of features and extensions that can be added and interact with the charger via OCPP such as payments, smart charging, customer management, and AI capabilities.
Protocols other than OCPP are typically used on both CS and CSMS side for non CS-CSMS communication. The most common of these are ISO 15118 and DINSPEC on the CS for communicating with the vehicle while charging, and OCPI on the CSMS which is used for sharing information and control of charging stations between different cloud systems.
The most important acronyms to remember for OCPP are CS (Charging Station) and CSMS (Charging Station Management System) - these are the two actors involved in almost every OCPP use case.
Other commons acronyms are EVSE (Electric Vehicle Supply Equipment), CPO (Charge Point Operator), and MSP/eMSP (Mobility/eMobility Service Provider).
This list contains a good overview of other acronyms which it helps to be familiar with in the context of OCPP. There is also a list on Page 9 of Part 2 of the Specification.
All versions of OCPP rely on WebSocket connections to maintain a persistent connection between the charger and the CSMS. It is a cousin of HTTP which most of the web relies on, the key difference being that WebSockets are persistent open connections with two equal parties whereas HTTP relies on a server responding to requests from clients.
The reason the WebSocket protocol are used for OCPP is that is enables either CS or CSMS to initiate communications depending on the use case. It also gives the CSMS a good view of the network of stations as if the stations have a stable internet connection they will always have an open WebSocket connection to the CSMS.
WebSocket libraries exist for all major programming languages, for example Python, C++, Rust, and Node.js.
All messages are one of three types. Each has a number assigned to it which must be included in each message to identify them.
2]3]4]OCPP defines all messages in a specific structure which must be adhered to for it to be accepted by the other party. This includes the message type number, a unique ID which must be matched in the response, the message name, and the payload.
For example a HeartbeatRequest would look like the following, bearing in mind this has no defined payload hence the empty bracket at the end:
The payload examples in this guide will omit these required fields and just show the payload (above this is the {}) for brevity.
Membership of the OCA is paid, varying from €297/year for individuals to €8,250 for the largest organisations (full prices here). Membership means you can participate in the development of the protocols and get access to meeting notes, support, and draft releases of future versions.
As with many protocols, there is an important distinction to be made between “libraries” and “implementations”. Libraries often define the messages from the protocol and the options for certain fields, and implementations use these libraries to actually implement all of the logic from the protocol.
The OCA doesn’t develop any software libraries and the specification is instead distributed as a set of PDF documents. This means that there are a number of different implementations of the protocol by different companies. These are validated against each other and the OCA at Plugfest events or using the OCPP Compliance Test Tool.
There is now an effort by the Linux Foundation to converge on an open source implementation of OCPP, currently this initiative is using https://github.com/EVerest/libocpp which is part of the https://github.com/EVerest/EVerest project for the CS side and https://github.com/citrineos/citrineos for the CSMS side.
Some open source OCPP libraries include https://github.com/codelabsab/rust-ocpp - a Rust library from CodeLabs, https://github.com/mobilityhouse/ocpp - a Python library from The Mobility House, and https://github.com/lorenzodonini/ocpp-go - a Go library
There are also some notable open source OCPP 1.6 projects out there such as https://github.com/steve-community/steve - a Java combined library and implementation. Another useful repository is https://github.com/aws-samples/aws-ocpp-gateway which gives a blueprint of how to set up a CSMS infrastructure using AWS services.