The world of EV charging has always been ripe for innovation and new, creative ideas. New types of chargers with expanded capabilities seem to be appearing every other day. It’s a big wide charger world out there waiting with open arms to embrace all chargers.
But with innovation comes problems. In an EV charging world filled with many types of chargers, communication is a problem. Specifically, how do we build charging control systems that can accommodate all different types of chargers? Put another way: how do we make EVSE hardware (the chargers) and software (the control systems) interoperable?
Two communication protocols are emerging as the most frequently adopted in the industry: OCPP and Modbus. This blog will attempt to explain how OCPP (or Open Charge Point Protocol) works and the advantages it offers.
OCPP was developed by the Open Charge Alliance, a consortium of companies and organizations in Europe. Their mission was to “foster global development, adoption, and compliance of communication protocols in the EV charging infrastructure and related standards through collaboration, education, testing, and certification.” The result of their efforts was a communication protocol that we know today as OCPP. There have been several iterations of OCPP, but as of this writing, most charger manufacturers seem to have settled on OCPP 1.6-J (2015) even though the OCA released OCPP 2.0 in 2020.
Here, in incredibly oversimplified terms, is how OCPP 1.6-J works. The “J” stands for JSON, which is a computing method for sharing information between computers. The easiest way to think of this JSON is by imagining that inside an OCPP charger there’s a whiteboard, and on that whiteboard is written all the data from your charger and any instructions sent to it from the central control system. Both the charger and the control system can read and write on the whiteboard. OCPP 1.6-J defines the vocabulary and the syntax to be used for communications. OCPP separates the functionality it supports into Features. These Features are limited to the messages necessary to support a defined primary use-case.
The OCA designed OCPP to support a specific type of transaction, also known as a “use case.” For OCPP that specific use case is approving a customer to charge and reporting how much energy and time it took to complete charging. The key steps in this use case are authentication, status and usage reporting, and limiting power usage. This is perfect for public charging where customers find an experience that mirrors the operation of a gas pump: put in a credit card, put the hose in your tank, start fueling, wait for completion, and then get a final receipt. Public charging companies have formed payment networks where instead of a credit card a user can simply swipe a membership card. Billing arrives by email at the end of the session.
While this use case is ideal for public on-demand charging, where you want to charge vehicles as quickly as you can and pass on the cost to the end user, it is less than ideal for fleet charging. Having a standard pre-defined use case also means that OCPP can’t easily support unique features that a charger manufacturer might include.
Another interesting and important part of OCPP is how a connection between a charger and a control system is initiated. In order to simplify setting up a Charging Station Management Systems (CSMS), the charger starts every communication session by contacting the CSMS. This allows chargers to be pre-commissioned with the address of the CSMS prior to installation. The beauty of this design is that no matter how the charger is connected to the internet – wired, WiFi, or cellular – it calls home. This avoids the need for the CSMS to navigate the complexity of knowing the address of every charger and the need to authenticate remote devices through VPN’s or other networks.
While simplifying set-up, this phone-home method creates a few issues. One is that the CSMS must wait for the charger to call to get updates or issue commands. Given that OCPP’s primary use-case only requires communication when a charger is starting and ending charging, this makes sense. The charger “knows” to call upon a connection and completed charge. By limiting the number of times a charger “calls” home, OCPP allows the system to reduce overloading the CSMS with too many calls. However, this means that real-time information about ongoing charges can be limited, and importantly, control signals can only be exchanged when the charger makes a connection. As I noted in an earlier post, some charger manufacturers use this design feature to lock their chargers so that customers can’t change CSMS vendors.
It’s important to remember that the OCA and OCPP are specific to EV charging. This is no external standards setting entity – like SAE, IEEE, etc. – other than the OCA setting this standard, which is supported by industry participants. As I learned in school, the purpose of a company is to maximize its own profits. For-profit companies dominate the current list of OCA participants. Furthermore, “Currently there are 5 organizations on the board of OCA: Greenlots, ESB, RWE, G2 mobility and ElaadNL. These 5 organizations represent all OCA participants and are a reflection of the different participant groups of OCA.” These entities all focus in one way or another on public charging which explains the laser focus on the “gas-station” use-case. It also means fleet charging doesn’t have a seat at the table to ensure its concerns and use state are addressed.
In my next post, I’ll describe an older standard that seems to be the next new thing for networking fleet EV chargers: Modbus.