Keeping IT systems up-to-date, even with basic tasks like dependencies or newly coming company-wide best practices is challenging. Even if all components are maintained in-house, it’s time-consuming to keep all areas updated. This applies also to keeping up-to-date external protocols our system uses. Whether we are integrated with Stripe over HTTP API, or with thousands of charging stations over OCPP, it’s good to know what the latest API version introduces. All this in order to examine if there are new opportunities upfront our business that can be supported by the newest version of the protocol we use. Or maybe our market requires covering long-waited, flow enabling updates. Let’s dive deeper into the new features introduced in OCPP 2.0.1 to see if it’s worth spending time upgrading your CPO platform.
OCPP 2.0.1 introduced business-oriented features but also technical improvements like device management or security. Those aspects are likewise very important, but this article gathers the latest OCPP updates focusing on the business angle.
More sophisticated support for smart charging is OCA’s (Open Charge Alliance) answer for a growing interest in this area. Energy cost fluctuates during the day. Also, the amount of energy available on different levels (charging station, building/parking, grid) changes according to the current consumption, production, and network capabilities.
Having that fact in mind we can use it to plan the charging process, buy cheaper energy for the end-user, and not overload the network. We need to know when energy is cheaper or the network load is too high. It’s out of the scope of OCPP, but once we have such information, we should inform the charging station how to apply it to finally reduce the cost of charging and limit network load.
OCPP 1.6 already supports smart charging. What is new, OCPP 2.0.1 is being open for new types of input having an impact on the charging process. Let’s start from a quick overview of OCPP 1.6’s support for smart charging and then move to things that are new in version 2.0.1.
Smart charging in OCPP 1.6
Whole smart charging is based on charging profiles. A single profile describes time intervals with power/current limits, for instance, a profile can define that between 0:00 and 10:00 we can charge using 5kW, and between 10:00 and 0:00 maximum energy is limited to 2kW.
Profiles can be stacked and merged in order to build complex profiles. There are three types of charging profiles:
- ChargePointMaxProfile - profile of whole charge point
- TxDefaultProfile - default profile for a transaction (can be for whole charge point or for specific connector)
- TxProfile - profile for a single transaction, deleted once a transaction is finished.
The second essential concept is a type of smart charging. There are three types of smart charging setup supported in version 1.6:
- internal load balancing
- central smart charging
- local smart charging
From a technical perspective, everything is covered by three OCPP API operations:
and four configuration keys:
Features introduced in OCPP 2.0.1
As it was mentioned earlier, 2.0.1 is open to new sources of information driving smart charging. Since now we can consume information from:
- external energy management systems
- electric vehicles connected to charge point (through the ISO 15118)
Let’s focus now on the first point.
External Energy Management Systems (EMS)
Imagine a situation where there are some external indicators saying the energy our charge points transfer to EVs has to be limited. We can handle that on the CPO side, consuming the information and preparing an adequate charging profile being sent to the charging station over OCPP. But the 2.0.1 version supports direct integration between charge points and EMS. An extreme example of such integration can be a hospital with a lot of critical health-related systems consuming energy and with parking having charge points. It’s obvious that charging cars is less important than keeping the core hospital’s infrastructure running. This is an example in case of a bigger load, the energy management system should limit energy flowing to the charging stations. It can be done directly between the EMS and charging stations outside the OCPP. But such an approach introduces a problem. The CPO platform can be lost because the charging station behaves not the way it was requested by the system. OCPP 2.0.1 solves this problem by introducing a notification mechanism that informs CSMS (Charging Station Management System) about some external limitations. There are many cases that can be solved by support for direct smart charging inputs from an energy management system:
- consuming DSO signals
- integration with Building Energy Management System
- integration with Home Energy Management System
From a technical perspective, a new charging profile type (ChargingStationExternal) has been introduced. External signals changing the charging profiles should be stored as a charging profile of this type. Once an external charging profile has been added, the charging station has to notify CSMS and it does it using the new message - NotifyChargingLimitRequest.
Smart charging with ISO 15118
The issue of support for ISO 15118 will be covered in the next paragraph, now let’s focus on the parts of ISO 15118 related to smart charging. Smart charging is nothing more than gathering information about the state of the network (including prices, load, etc.), processing the data, and steering the charging process. Standard ISO 15118 introduces another one source of information that can be processed in order to plan charging processes effectively. The source of information is an EV. One of the most important pieces of information when planning a charging process is the amount of energy the car wants to consume. There are many options to provide such information to the CSMS:
- user can enter requested energy using a mobile app (delivered by the eMSP) and through the backend-to-backend integration send it to the CPO’s CSMS,
- the charging station may send this data directly to the CSMS using a custom API
We could even use a new measurand introduced in OCPP 1.6 called SoC (State of charge of charging the vehicle in percentage). All those approaches have significant drawbacks. They assume the user's manual action, using a custom API or doing some approximations (when translating percent of battery already charged to the energy to be consumed without knowing the capacity of the battery). None of those solutions is good enough to become a standard. But ISO 15118 together with OCPP 2.0.1 covers this part of smart charging. ISO 15118 as a standard describing communication between an electric vehicle and a charging station specifies what type of information can be exchanged between those two parties. EV sends:
- energy request (target, minimum and maximum)
- charging parameters (current, power, and voltage)
- discharging parameters (current and power)
Once the data is sent to the EVSE, it can be translated to the OCPP message and sent to CSMS which can use this input to prepare the charging schedule and send it back to the charging station (taking into account other inputs like price info, network load from DSO, etc.).
OCPP 2.0.1 introduces the message NotifyEVChargingNeedsRequest to share ISO 15118 based information with CSMS. It has four parameters describing charging details sent by EV:
- requested energy
- maximum voltage
- minimum and maximum current
Once CSMS prepares a charging profile for the current transaction, it sends it using SetChargingProfileRequest OCPP message. EVSE is proxying the information to the EV and as a last step, EVSE can notify CSMS about the charging schedule calculated by the EV using the NotifyEVChargingScheduleRequest OCPP message.
What is also worth mentioning OCPP 2.0.1 introduced ISO 15118 based renegotiation of the charging schedule. Renegotiation can be triggered by both sides - EV and CSMS. It’s useful in order to quickly react to the latest changes in the grid, no matter if it’s to reduce costs or unstress the network.
Support for ISO 15118 - Plug & Charge
Very often the eMobility world is compared to the petrol industry. One of the most frequently compared areas is the transfer of energy from the station to the car. It’s said that we still have to wait years to bring the same user experience for the eMobility users as gasoline-based car users have today because of the time needed to charge the car. There is one improvement that has never been available for classic cars, but some charging stations and electric cars already have it. It’s Plug & Charge. In short, it’s a technology that allows users to start charging sessions without manual authorization. A user just needs to plug in the cable and without scanning the RFID token or using a mobile application car starts to drain energy from the station. Once charging is done, users can be automatically billed, also without entering payment details anywhere. Everything thanks to the PKI based solution introduced in the ISO 15118 and also covered by the OCPP 2.0.1.
Plug & Charge is built on a trust that is guaranteed by the Public Key Infrastructure. The most interesting part of it is how it replaces the need for human intervention when doing the authorization. The EV has the contract certificate stored (X.509 certificate). The certificate associates the end-user with the public key. Because the certificate is issued by a trusted Certificate Authority, the charging station is able to check it, and if it’s valid, the charging station believes that the user presented in the certificate is not fake. User is identified by the ID called E-Mobility Account Identifier (eMAID) stored in the contract certificate. eMAID is also known to the eMSP for billing purposes. Thanks to that, eMSP knows which user has to be charged for the transaction started automatically just by plugging the cable.
Two main parts of OCPP cooperating with ISO 15118 in order to provide Plug & Charge are:
- ISO 15118 Certificate Management
Whole ISO 15118 is built upon Public Key Infrastructure. That’s why the separate component managing certificates has been introduced in order to open OCPP for integration with EVSE supporting ISO 15118. There is a set of OCPP messages including:
that are designed to manage certificates related to ISO 15118.
The second part of OCPP allowing to implement Plug & Charge is Authorization flow. AuthorizeRequest message contains (among other fields) information about the token used for authorization. This is a message used to send RFID token or a Central token in a remote transaction. There are multiple types of tokens supported in OCPP version 2.0.1 (more about it in the next paragraph), but one of them is called eMAID. eMAID is sent together with the data allowing to verify contract certificate (certificate and iso15118CertificateHashData).
New authorization options
OCPP 1.6 and previous versions were designed to support RFID-based authorization. Version 2.0.1 introduced a set of new authorization mechanisms, among them:
- Central - used in for example in remote transactions
- eMAID - used in Plug & Charge flow
- KeyCode - for authorization using PIN-code
It opens new possibilities for the development of user-friendly interfaces that may make charging easier and more accessible for the end-users.
Connection upgrade can be vital
OCPP 2.0.1 introduces significant changes that bring new opportunities for the whole eMobility world. In order to develop an efficient smart charging system or introduce Plug & Charge, we have to involve many parties, to mention only well-known ones like CPOs, eMSPs, and OEMs. The connection between the charging station and the backend system (CSMS) is a piece of a puzzle - linked with an upgrade of OCPP to the latest version. The decision has to be made wisely because it has many consequences, however, the features OCPP 2.0.1 provides can give CPO business a notable boost.