See the eighth lesson of our comprehensive eMobility training on OICP!

Having a chance to work with well-established startups from the e-mobility sector, Bartek gained invaluable knowledge on the industry requirements. On his path, he was given the opportunity to work on numerous EMSP applications and CPO platforms. Bartek is also our Head of Delivery.

Bartłomiej Łazarczyk

 is happy to introduce you to the Open Standards course led by our e-mobility expert - Bartlomiej. Throughout the following lessons, we will uncover the technicalities and functionalities of the OICP - a protocol developed by 

 - as well as business aspects for e-Mobility Service Providers and Charge Point Operators.

Such a knowledge-pack should serve everyone operating in the e-mobility industry as it unfolds the most crucial aspects of navigating through Open Standards utilization and many more!


Subscribe to our YouTube channel to make sure you don't miss out on the upcoming training entries.

CPO eRoamingAuthorization + eRoamingReservation

CPO eRoamingEVSEdata + eRoamingEVSEstatus

CPO eRoamingDynamicPricing + eRoamingChargingNotifications

EMP eRoamingAuthorization + eRoamingReservation

Open InterCharge Protocol Training - Lesson 8

In this service, EMP has its own operation which allows them to pull EVSE static data from partner operators. This can be done with eRoaming pool EVSE data operation. Its implementation is mandatory by every EMP partner. EVSE data model used in this operation was already covered before and does not differ. worth mentioning is that from OICP2.3 version response should be in paginated format. As we have seen it before, Hubject holds the last update attribute in every record that is stored in their platform. That allows Hubject to offer filtering functionality based on the LastCall attribute added in the request. LastCall is used for fetching only those data records that have changed compared to the EVSE state at the time of LastCall value. Besides the LastCalll, Hubject includes a deltaType attribute in the response which can tell what kind of operation was performed. Unfortunately, LastCall filtering cannot be combined with other types of filtering like search center, country codes and operator IDs. Request for eRoamingPullEVSEData includes many types of filtering parameters that can be used. The only mandatory attributes are provider ID and GeoCoordinatesResponseFormat. Most of the filterings are very useful i.e. you can filter by authentication modes, accessibility, renewable energy and few more. But probably the most useful one is filtering by SearchCenter which can be provided in order to return EVSEs with any specific radius.

Response for eRoamingPullEVSEData is a list of EVSE data records. Each EVSE data record includes the last update and deltaType attributes which were mentioned before. Return the list of EVSE data records is in the paginated format.

Similar as for eRoamingEVSEdata service, this service also has EMP dedicated operation which allows them to pull EVSE in dynamic data from partner operators. This is being done with the eRoamingPullEVSEStatus operation. Its implementation is mandatory for every EMP partner. It's worth mentioning that EVSE status records are grouped per specific CPO.

Hubject offers two additional functionalities for fetching EVSE statuses built on top of eRoamingPullEVSEStatus operation. The first one is eRoamingPull EVSEStatus by ID which is used for fetching statuses based on EVSE ID list. The second one is eRoamingPullEVSEStatus by operator ID which is used for fetching statuses based on operator ID list. Both of those functionalities are very important for EMP, because those filtering criterias are very useful in practice. In eRoamingPull EVSEStatus request only provider ID is mandatory, but you can also specify EVSE status and SearchCenter filtering. If you would like to fetch statuses by EVSE IDs, then you can provide a list of IDs under EVSE ID attribute, instead of EVSE status and SearchCenter filtering. If you would like to fetch statuses based on operator IDs, then you need to provide a list of IDs under operator ID attribute instead of EVSE status and SearchCenter. Response for eRoamingPullEVSEStatus request is a list of EVSE status records. Each list of records is grouped per operator ID under operator EVSE status. Unlike eRoaming EVSE data response, the data in this response is not paginated.

When it comes to the tariffs, Hubject offers EMPs a possibility to pull pricing product information specified by CPOs in their offers with eRoamingPullPricingProductData operation. Pricing product can be per specific EMP or offered to everyone. Hubject will verify if there is a valid pricing business contract between EMP and CPO before any data is returned. Returning functionality is also offered by providing elastical parameter in request. When it comes to the request of eRoamingPullPricingProductData operation, it's very simple. You need to provide a list of operator IDs, in other words a list of CPOsthat you are interested in and eventually you can provide the LastCall parameter for filtering.

As a response for eRoamingPullPricingProductData request you will receive pricing product data details for specific operator. As an EMP, based on that information, you only know what kind of pricing products a given operator offers. You still do not know yet how to apply them to specific EVSEs. That information is a part of the next operation.

eRoamingPullEVSEPricing operation allows EMP to know exactly how pricing products are assigned to EVSE IDs by CPO. Similar as in the previous operation, Hubject will verify if there is a valid pricing business contract between CPO and EMP. Request for this operation is very simple, you need to specify your provider ID as well as a list of operator IDs, which you are interested in. Also LastCall parameter can be provided for filtering.

Response for eRoamingPullEVSEPricing request is a list of operator EVSE pricing. Each object contains a list of EVSE pricing offered by a specific operator. Each EVSE pricing object has a list of pricing products that can be assigned to given EVSE. If that offer is specific only to you, you will see your provider ideas well in this object. In case data is available to everyone, you will see an asterisk character as a value for the provider ID field.

This service does not differ between CPO and EMP almost at all, but as a reminder - charging notifications allow EMP to know more details about ongoing charging sessions, which is crucial for their customers. Logic, data model and types of notifications are the same as for CPO related service. The only difference is that EMP must be able to handle eRoaming charging notifications request and return eRoaming acknowledgement as a response.

To sum up this part, we have covered all the services from EMP perspective. When it comes to the list of mandatory services and operations, we may divide it into online EMP and offline EMP. 

 must implement: eRoamingAuthorizedStart and eRoamingChargeDetailRecord operations. 

 must implement eRoamingGetChargeDetailRecord and eRoamingPushAuthenticationData. 

 must implement eRoamingAuthorizedRemoteStart, eRoamingAuthorizedRemoteStop, eRoamingPullEVSEData, eRoamingPullEVSEStatus. Of course online EMP may use eRoamingChargeDetailRecord and eeRoamingPushAuthenticationData operation in order to take advantage of the Hubject platform and make the whole experience better.

eRoaming Hubs explained

Get our comprehensive PDF packed with knowledge on eRoaming, hubs and protocols!

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

Certainly, roaming is something known to everyone at this point. However, what that has to do with eMobility?

Being a broad term for services allowing for connection outside of the usual network, roaming turns out to be an on-point solution for EV charging. With many players in the eMobility game (i.e. Charging Point Operators, eMobility Service Providers), some type of a connector is a must. Here’s exactly where eRoaming comes into play allowing for multi-dimensional connection between operators and EV drivers.

In short, eRoaming can be established via the use of hubs and protocols. A hub here can be an open platform which, after subscribing, can be used by many operators, who operate on common terms. This all happens in such a way that a certain charging pool introduced to a common hub can then be easily used by clients (EV drivers) of different providers. Such a solution allows electric vehicle users to charge their car across cities/countries with limited hussle.

In order to facilitate such a solution, the hubs developed their own open protocols, which are essentially responsible for the connection. They also define the functionalities of each eRoaming platform.

Amongst the existing hubs, we can differentiate three major ones. They all come with their own open standards and unify hundreds of CPOs and EMPs as well as millions of EV drivers.

The three biggest hubs and their protocols are:

(eMobility Inter-Operation Protocol - eMIP)

Apart from the proprietary protocols coming from hubs, it’s worth mentioning that there's also an independent one - 

Open Charge Point Interface Protocol (OCPI)

. It allows for eRoaming between the hubs as well as peer-to-peer connection.

To learn more about eRoaming, hubs & protocols, their importance and functionality as well as the future of eMobility - take a look at our exclusive paper covering all that needs to be covered on the topic!

Download our comprehensive PDF and learn about the pricing structures in e-mobility

Although it would seem rather straightforward, the pricing system within the EV charging environment extends further than just to the payments made by electric vehicles right after they charge their car.

Being such an interconnected network of mutual dependencies between numerous involved parties, e-mobility charging services require various levels of settlements.


It must be noted that it takes a few units to build up and manage a charging network. From 

, which manufacture the hardware side of required components (connectors, chargers, cables, etc), through 

, which are responsible for the backend management, all the way to 

, which determine the final user (here: EV driver) experience, there is a whole network of reliabilities.

Put simply and briefly, CPO’s are to establish billing connections with both EVSE and eMSP’s, in order to put the entire charging formation in place, while ensuring all parties receive transparent information and clear instructions.

To facilitate it, there are multiple types of pricings and contracts, some of which allow for complex, dynamic price models. Such undertaking is required so that eMSP’s can shape their end-users pricing often based on certain conditions, leaving the rates flexible.


Interoperability - the core of proper functioning

It should go without saying, that managing a pool of charging stations - oftentimes distributed across entire countries/regions - is not an easy task to handle and can only be achieved via advanced levels of interoperability and clear, unified procedures.

Open Standards are the chief example of how this can be achieved and maintained. Through the utilization of API’s like OICP the flow of information can be sustained in a transparent manner. This allows for a seamless communication and can facilitate the management of a vast majority of proceedings remotely, which comes in handy while developing a state-wide network, especially when there are numerous parties involved.


Knowing the behind-the-scenes nuances and arrangements, we prepared a comprehensive paper portraying the pricing structure within the e-mobility industry. Those who are willing to learn more about tariffs within charging services, should definitely find it useful.

Download our free paper and broaden your horizons with some great knowledge!

E-mobility tariffs. How is the pricing structured within the industry?

Open standards can be a game changer for both eMSP's and CPO's. Here is why.

The initial stages of technologies lead to various types of solutions addressing the same problem. Each company develops a different approach. At the beginning of the XXth century, when commercial electricity had come to the mainstream, multiple energy producers offered power supply with miscellaneous frequencies and voltages. As time passed, governments began to impose certain standards on suppliers. This standard-setting led to the joint effort to create the first power grid.

From the first power plant to the moment when all energy providers linked to the same network, decades passed. This was only possible because they took a mutual direction.

 - literally and figuratively. With global warming, exhaustion of solid fuel resources, and lifestyle changes, companies face the challenge of how to provide accessible new charging forms of green power.

Now, as the e-mobility era is here, we are on the same page, like we were at the very beginning of the XXth century. We already have plenty of providers: eMobility Service Providers (eMSP) and Charge Point Operators (CPO) - two substantial sides of the e-Mobility world. One of the main challenges ahead of this market is to deliver the best user experience, at possible minimum resources use. As usual, user experience is a matter of well-designed apps, customer support, and simplicity itself. But there is an additional fact. End-users need to be able to charge cars at any charging station without being concerned about accessibility. The issue is - having the contract signed with the Charge Point Operators recharging point service. How to achieve this? Partners must take the same course, and this is where the standards start to play a major role. There are two possibilities: Open Charge Point Interfaces or Open Intercharge Protocols. What are the benefits?

The main goal of the Open Charge Point Interface (OCPI) is to allow electric vehicle drivers to charge their cars at any station. OCPI defines a set of modules that cover most cases the driver may need. There are two technical modules that are used to establish connectivity between two platforms using OCPI: Credentials module and Versions module. Other modules are strongly related to real-life use cases. These would be:

Locations - module responsible for sharing information about the Charge Points, like address, geolocation, real-time data about the current status, electrical parameters.

Sessions & Commands - module allows the end-user to start the charging session and be informed about the current status of the charging session.

OCPI is an open standard, and what may be very important for the adopters - it’s very flexible. For instance, CPOs (Charge Point Operators) may implement only the Locations module (apart from two technical mandatory modules) when only sharing Point Of Interest data. With no necessary exposing the eRoaming functionality. But the ultimate goal for many CPOs is to allow end-users to charge their car. In that case, many more modules need to be implemented (Sessions, Commands, CDRs). Some others are optional, even for the eRoaming (Tokens, Tariffs), and that depends on the agreement between certain allies. It’s in terms of how financial flow and security is modeled.

The biggest advantage of having OCPI implemented is that it’s almost a one-time investment. The initial effort is significant, as it might be challenging to transfer internal models and processes to the OCPI. But once it’s done for a partner, it opens the company for quick and cost-effective integration with a lot of other associates.

A bit different concept is proposed by the Berlin-based innovative company - Hubject. Hubject developed its own API (OICP) covering almost the same cases as OCPI. There is one extra. Hubject also acts as a hub. It connects CPOs and eMSPs. Once a company is connected to the Hubject platform, it becomes open for integration with any other comrade being already assigned. That’s a huge advantage because the integration is done once, with one platform, and of course it becomes profitable when it comes to an alliance with multiple partners.

Yet another advantage of the Open Intercharge Protocol is that it’s quite easy to implement. Like with most protocols, the main challenge is to synchronize our internal models with the standard one. What is comforting with OICP - there is not too much to implement. It depends on the level of integration we want to achieve, but it’s enough to implement about 5 HTTP calls to expose eRoaming through the Hubject platform.

Having in mind multiple historical examples, it may be difficult to be a part of a developed market without following widely adopted standards. Initially, it may need some additional effort. But when the standard is implemented, our platform becomes open for the whole market 

. Without it, we would need to spend weeks or months doing the integration with each partner separately.

Open InterCharge Protocole Training. Lesson 8

26 APRIL 2022 • 9 MIN READ