Smart Charging in OCPP 1.6 Vs OCPP 2.01 Vs ISO 15118 | Understanding basic differences

Open Charge Point Protocol – OCPP 1.6 already offers smart charging feature; time, cost, source and load based optimizations are already possible. Then, what is it new in OCPP 2.0.1? and why is OCPP 2.0 smart charging often referred along with the smart charging functionality of ISO 15118?

This post aims to clarify these questions in simple words as well a bit detailed with relevant OCPP messages information for developers.

Smart charging in OCPP 1.6

When it comes to smart charging in OCPP 1.6, the entire implementation is based on charging profiles. A single profile describes time intervals with power/current limits. For instance, an OCPP smart charging profile can define that between 17:00 and 21:00 , the user can charge at a max speed of 5kW, and between 21:00 and 07:00 maximum energy is 22kW.

Profiles can be stacked and merged in order to build complex profiles. There are three types of charging profiles:
  1. ChargePointMaxProfile - profile of whole charge point
  2. TxDefaultProfile - default profile for a transaction (can be for whole charge point or for specific connector)
  3. 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 OCPP 1.6:
  1. internal load balancing
  2. central smart charging
  3. local smart charging

For developers

From a technical perspective, everything is covered by ,
  • Three OCPP API operations: setChargingProfile, clearChargingProfile, GetCompositeSchedule
  • and four configuration keys: ChargeProfileMaxStackLevel, ChargingScheduleAllowedChargingRateUnit, ChargingScheduleMaxPeriods, MaxChargingProfilesInstalled

Smart Charging with OCPP 2.0.1

Open charge point protocol OCPP 2.0.1 is open to new sources of information driving smart charging. Since now we can consume information from:
  • external energy management systems (EMS)
  • 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 OCPP 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

For developers

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 ISO 15118 standard 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.).

For developers

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:
  1. requested energy
  2. maximum voltage
  3. minimum current and 
  4. 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.
Hope this post gave a deeper insight to understand the differences of smart charging with different versions of OCPP. Please feedback in case any mistakes in the post or suggestions to improve the knowledge base.

No comments

Powered by Blogger.