Learn about OSCP and see how it nourishes (not only) the eMobility environment.

Being an eMobility leader in various projects across multiple startups, Piotr was responsible for OCPI and OCPP integration as well as EMP and CPO platforms development. With extensive expertise in the open standards field and eMobility tech solutions, he is leading teams of experienced developers and contributing with invaluable knowledge and experience.

Piotr Majcher

The rather steep uptake in electric vehicles can be observed across all the transportation branches at a fairly constant rate. To match the pace of this new era, it is crucial that market players communicate and work together in order for there to be an accessible environment. EV Roaming can help create open infrastructure by providing seamless access between cars equipped with wireless charging capabilities or electric batteries as well as those without such technology through mobile phone networks which would allow them roam free at any time.

With contributors from all over the world, up-to-date solutions for any participant are an absolute must to ensure high levels of interoperability. This is why open standards play such a crucial role in this industry's growth and continued expansion into new markets. The global eMobility market has seen rapid developments thanks largely to open networking capabilities that provide equal opportunities across borders

On our blog, we have covered quite a lot on the topic already. Some of the articles are:

EV roaming with open standards - OCPI and OCHP

EV roaming with open standards - OICP and eMIP

Open standards, however, are not the only reason behind the galloping of the whole industry. New technologies, like smart charging are nourishing the business just as much and are, to a great extent, responsible for the significant growth. We’ve launched a comprehensive PDF on smart charging, that can be downloaded here:

With the ever-growing popularity of electric vehicles, one must remember that the industry’s responsibilities grow linearly. As the charging infrastructure expands, conscious steps need to be taken in terms of its impact on the grid. Smart charging plays quite a role here.

As much as some of the open protocols cover in fact a lot of smart charging functionalities, one primarily stands out. Open Smart Charging Protocol is designed to “collaborate” with the grid on a much more advanced level.

Open Smart Charging Protocol - the introduction

OSCP was established by Open Charge Alliance, the same company that runs the OCPP protocol. So far, OSPC has been launched in two versions. The first one, OSCP 1.0 was officially released in 2015, meanwhile its successor, OSCP 2.0 in 2020.

The major difference between the two versions is that the latter has been amended in terms of the terminology used in the specification documents so that it would fit a broader range of audience. The changes also included an architecture revision.

In general, OSCP enables communication between the charge point and the energy management system or a DSO system. That way it can be integrated not only by the EV side but also by the energy suppliers. The core function of OSCP is that it is able to communicate a 24h forecast of the grid capacity to the Charge Point Operator, who can then adjust the charging profiles to create the most optimal EV charging energy demand, without overloading the grid.

Passive charging (aka the charging that occurs when any charger is working at its maximum capacity, no matter the demand’s condition) may theoretically pose a threat to the energy grid and impose steep electricity prices in cases when the demand already runs very high. The spike in prices is strictly related to the need for enlarged electricity input to match the increased demand, and what comes with it, the extended energy production, which is costly. Such a scenario also negatively impacts the “cleanliness” of electric vehicles as with the higher energy production, the emissions increase.

Smart charging seeks to respond to the above issue by an appropriate maneuvering of the energy intake and outtake in order to achieve a satisfactory equilibrium. Given the drastic changes undergoing throughout the entire energy sector it is vital that eMobility (being an integral part of it) matches the innovatory trend.

Given OSCP 2.0 is the leading version, we will focus on its specifications.

The creators of Open Smart Charging Protocol have introduced a well-specified domain model to serve as the grounding behind the entire specification. In the picture, there are:

: a device (i.e.: EV, battery-run devices, heat pumps, etc.) that can consume energy in a controlled manner. The flexibility here adheres to either time or amount of energy that is consumed or generated

: a unit that controls the flexibility resources (i.e. Charge Point Operators). The control mechanisms are not specified by OSCP

a unit that manages certain energy network (i.e. DSO aka Distribution System Operator or EMS aka Energy Management System). It imposes boundaries to the flexibility providers, but does not have a direct access to the control of flexibility resources.

The OSCP also leaves room for a fourth player - Capacity Optimizer whose role is to support flexibility providers in ensuring the most optimal solutions.

As stated before, the main function of OSCP is to provide a 24h forecast of the grid capacity to the Charge Point Operator. The way this works in the above-mentioned setting is that a Capacity Provider informs the Flexibility Provider of foreseeable events and potential predictions in terms of the grid’s capacity. There are few types of forecasts mentioned in the OSCP documentation. Below, the quote:

“Consumption Capacity (CC) - specifies for the given time interval the maximum total amount of capacity that the group of Flexibility Resources can consume

Generation Capacity (GC) - specifies for the given time interval the maximum total amount of capacity that the group of Flexibility Resources can generate

Fallback Consumption Capacity (FC) - specifies the maximum total amount of capacity that can be consumed in island mode, i.e. when the Flexibility Provider and the Capacity Provider have lost connection

Fallback Generation Capacity (FGC) - specifies the maximum amount of capacity that can be produced in island mode, i.e. when the Flexibility Provider and the Capacity Provider have lost connection

Optimum (O) - ) specifies for the given time interval the Optimum amount to be generated or consumed.”

OSCP allows for the communication between involved parties. That is, when a Flexibility Provider requires more/less energy, it can issue a specific request via the ‘AdjustGroupCapacityForecast’ message. Based on the received information, the Capacity Provider then acts accordingly if possible. In cases when there is no option of adjusting the energy flow, a ‘GroupCapacityComplianceError’ is sent to notify all involved parties.

Open Smart Charging Protocol also precisely states the rules and important issues behind the connection of all the involved parties. This entails the registration, connecting and handling connection issues. The registration (meaning registering endpoints) consists of the creation of a unique token to use for authentication in order for the parties to connect to one another. Then connecting is facilitated via “handshaking”. This mechanism allows for expressing the preferences to one another. OSCP also presumes the possibility of detecting whether a certain party remains offline for the time being and it is enabled via the heartbeat mechanism.

Please note, that this is a brief introduction into the OSCP, the full documentation with all the features listed and explained can be downloaded from Open Charge Alliance official website.

Open Charge Alliance did a solid work in creating a protocol allowing for such communication. Even if there’s still room for improvement and it’ll take some time for OSCP to be implemented on a large scale, its biggest benefit lies in the fact that the protocol (in the second version; after the changes) can be used either well for EV-related cases or for others who fall under the energy control spectrum.

The global energy system is a vast and complex network that supplies energy to homes and businesses across the entire planet. It includes everything from power plants and transmission lines to distribution systems and end-use customers. With that in mind, open protocols enabling smooth information exchange are beyond important in ensuring seamless operation.

Demand response

Refresh the knowledge on OCPP and see what changes have been implemented over the last years!

 on OCPI. Given how widely read it was, we thought it’d be a good idea to continue the series on open protocols in the EV charging diligence.

Standing at the forefront of EV mass adoption, open standards and protocols are essentially responsible for the communication within the industry. They connect all involved parties (i.e. CPOs, EMPs, EVSE) altogether and allow for the data exchange, staying up-to-date and allowing for EV drivers to actually facilitate the charging sessions.

We have already covered quite a lot on the subject of open standards, for those interested, here’s the list of some entries so far:


In this piece, all the focus goes into the Open Charge Point Protocol - OCPP.

OCPP has been developed by the Open Charge Alliance, a consortium of electric vehicle infrastructure providers, automakers, utilities, and other stakeholders. OCPP is a communication protocol used by charging stations and electric vehicle service providers. It enables two-way communication between the EVSE and CPOs, allowing for the monitoring and control of charging sessions.

OCPP is an open protocol, and anyone can develop applications that use it. Yet, it has not been officially deemed as standard, meaning that as much as OCA highly recommends using it, it’s not obligatory for EVSE manufacturers to produce hardware compliant with OCPP.

In terms of what it does, understanding of the OCPP placement in the entire ecosystem is crucial. As it has been stated earlier, OCPP is the syntax connecting the CSMS (Charging Station Management System used by CPOs to control their networks) with the actual hardware appliances (charging stations). Amongst operations covered by OCPP there are:

: enables identifying the EV driver and starting/finishing the charging event

: the charging event data is transferred to the backed system to define the chargers and bill the EV user accordingly

: CPOs can monitor the stations’ statuses (i.e. which are currently occupied, which have some issues detected)

Throughout the years, there have been a few versions of OCPP published. Two most recent ones are - OCPP 2.0 and 2.0.1. We’re gonna focus on these two, as they’re currently the most relevant.

In terms of the migration from the previous version (OCPP 1.6), we have covered that subject in this article. When it comes to OCPP 1.6, this version was enriched with multiple new features compared to its 1.5 predecessor (now mostly out of use). As we read in the documentation, to OCPP 1.6 there have been added:

A binding to JSON over WebSocket as a transport protocol is added, reducing data usage and enabling OCPP communication through NAT routers, see: OCPP JSON Specification

Extra statuses are added to the ChargePointStatus enumeration, giving the CPO and ultimately end-users more information about the current status of a Charge Point Structure of MeterValues.req is changed to eliminate use of XML Attributes, this is needed for support of JSON (no attribute support in JSON).

Extra values are added to the Measurand enumeration, giving Charge Point manufacturers the possibility to send new information to a Central System, such as the State of Charge of an EV

The TriggerMessage message is added, giving the Central System the possibility to request information from the Charge Point

A new Pending member is added to the RegistrationStatus enumeration used in BootNotification.conf

More and clearer configuration keys are added, making it clearer to the CPO how to configure the different business cases in a Charge Point

The messages and configuration keys are split into profiles, making it easier to implement OCPP gradually or only in part

Known ambiguities are removed (e.g. when to use UnlockConnector.req, how to respond to RemoteStart/Stop, Connector numbering)

(please note, this extract comes from the OCPI 1.6 documentation and can be downloaded in full from their website)

Now let’s focus on the two latest versions. OCPP 2.0 was first introduced in April 2018. Since then, some issues have been found. As it turned out, some of the problems couldn't have been solved by fixing textual nuances in the documentation and needed bigger changes, to the point where they weren’t backward compatible. This included i.e. messages improvements (like the length of the security message certificate which happened to be too short). This is when OCPP 2.0.1 was introduced and it's recommended by OCA to use this one only.

As the OCPP standard continues to evolve, it is important for charging station operators to stay up-to-date on the latest version of the OCPP protocol. Doing so will ensure that their charging stations are compatible with the latest CSMS software and able to take advantage of the newest OCPP features.

In terms of how OCPP 2.0 followed by 2.0.1 have changed compared to OCPP 1.6, there’s been some major changes. First and foremost an ISO 15118 support has been introduced. In return, this has opened up the possibilities such as the Plug and Charge functionality. In the newest version SOAP is no longer supported as it has been entirely replaced by JSON websockets. There have also been some major improvements in the security area. Amongst some slightly smaller changes,

device management & monitoring replaced formerly used Status Notifications. The transaction handling has been improved so that it could support bigger and more complex networks.

The official OCPP documentation consists of 7 parts:

JSON over WebSockets implementation guide

Open Charge Point Protocol

Get our informative PDF on smart charging and see how it works!

Krzysztof is our Head of Products and he leads the technical development behind the suite of our ready-made solutions. Throughout the years in Solidstudio, he gained an invaluable insight into the eMobilty industry’s requirements and is now more than qualified to share his knowledge with others.

Krzysztof Ciombor

As we move towards an era where oil will likely become less accessible or even regulated in some way due to global warming concerns and other issues such as pollution caused by fuel sources like coal fired power plants, 

electric vehicles are to become the transport of the future.

 With such a massive shift across all transportation branches, all hands on deck in terms of innovative solutions are needed.

Luckily, such industry ameliorations can be observed in every aspect there is to eMobility. From ever-enhancing electric cars with prolonged-battery lives to all kinds of charging facilities, eMobility is entering a whole new level.

Amongst these solutions, a big part is played by software and digital products. Namely, eRoaming, connected car data and smart charging are all here to stay and are only advancing at a speedy pace.

We have already covered eRoaming in one of our downloadable PDFs. To see more click 

A few definitions can be found in terms of what smart charging really is. Some of the widely circulating ones say:

Smart charging is a cloud-based technology that makes it possible to adjust how much energy is used by EVs based on the current state of the energy grid.

But what does it really mean in practice? One must look at smart charging as a complex, inter-connected ecosystem that enables real-time data exchange between:


Through smart charging, the charging stations may monitor, manage, and restrict the use of charging devices to optimize energy consumption. The optimization happens on the basis of collected data which gathers information such as:

renewable energy availability or lack thereof

Future-proof nature of smart charging allows for free-choice maneuvers in terms of the quality and quantity of features, leaving the room for any necessary add-ons. All that to ensure EVs will not pose a threat to the grid in times of high charging demand that’s likely to grow directly proportional to the growing popularity of electric cars.

careful monitoring of the energy consumption and thus, transferring the charging loads across available energy sources and adjusting the power accordingly. 

The shifts are to ensure the continuity of (untouched) energy flow for its other consumers, such as homes and facilities nearby.

All about Smart Charging

Open Charge Point Protocol migration from 1.6 to 2.0.1

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.

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:

From a technical perspective, everything is covered by three OCPP API operations:

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:

electric vehicles connected to charge point (through the ISO 15118)

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:

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.

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:

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.

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:

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).

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

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.

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.

OCPP 2.0.1 introduced business-oriented features but also technical improvements.

About Open Smart Charging Protocol (OSCP)

18 NOVEMBER 2022 • 7 MIN READ