This document introduces the technical foundation for OCPP 2.0.1. We will cover terminology, WebSockets, format of messages, and support channels.
OCPP is developed and maintained by the Open Charge Alliance (OCA), and industry group based in the Netherlands who collectively develop, maintain, and test the protocols.
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 from Virta 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:
[2,"e2b81cc5-3670-4702-acac-283286697741","Heartbeat",{}]
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.