The Economics of Software in eMobility: Financial Strategies & Optimal ROI

Webinar 09.05

close button
E-MobilityOpen StandardsOICP

Open InterCharge Protocol Training. Overview

20 JANUARY 2022 • 10 MIN READ

Bartłomiej Łazarczyk

Bartłomiej

Łazarczyk

Open charge point protocol training

Solidstudio 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 Hubject - 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.

Open InterCharge Protocol Training - overview

OICP Training Transcript

Hubject - introduction

At the beginning let's start with a short introduction about the Open InterCharge Protocol itself and Hubject - a company that has developed this protocol. In general Hubject is one of the most important companies on the European market that offers a large unified and open e-roaming network called Intercharge. Hubject acts like a hub for numerous e-mobility partners, like Charge Point Operators and e-Mobility Service Providers. Hubject became quite popular because they offered the possibility to integrate with a lot of individual market players at relatively low cost. The goal of Hubject is to create an e-mobility platform that will simplify communication between charge point operators and e-mobility service providers.

They would also like to automate their contract-based relationships - in order to achieve that, each partner must agree on common terms and their Hubject user agreement. Signing Hubject user agreement is mandatory in order to use their platform. Of course, each partner may have additional contracts. For example e-Mobility Service Providers may have a contract with end customers as well as Charge Point Operators may have a contract with a distribution system operator.

Open Charge Point Protocol - what is it?

Previously mentioned simplification of communication is mostly achieved by using well-defined and standardized protocol called Open Intercharge Protocol, currently being developed by Hubject. This protocol defines the message format and possible operations to perform, depending whether you are an EMSP or CPO. OICP is one of the most popular protocols in Europe and it mostly covers the communication between CPO and EMSP.

As a proof for the popularity that I've mentioned, here we have a list of partners that already integrate with Hubject via OICP or would like to integrate. We can find big names here like: Electrify America, Innnogy, Ubitricity, Virta or Porsche. Also, Hubject claims that over 960 partners already use intercharge network so we can only imagine how many possibilities it can offer.

OICP - services

The OICP protocol is divided into different services which specify a list of operations to perform, i.e.: we have authorization service which consists of operations like:

  • e-roaming authorization start
  • e-roaming authorization stop
  • e-roaming authorization remote start
  • e-roaming authorization remote stop
  • e-roaming charge detail record

Each service may also have a different set of operations to perform depending on the role. For example, in EVSE data service, we have an e-roaming pool EVSE data specified only to EMP and e-roaming push EVSE data specified only to CPO. In order to be fully compatible with a service you as a partner need to implement all of the operations that are marked mandatory for your role. Typically it means that most of the operations or even all must be implemented.

We will cover all of those services independently within this course.

Charge Point Operator - Fundamentals

You have already heard the terms like Charge Point Operator or e-Mobility Service Provider but what exactly does it mean? And how can they interact with the Hubject platform?

Let's start with the Charge Point Operator. A partner that owns charging infrastructure, would like to expose it to as many customers as possible and to benefit from e-roaming network. OICP allows CPOs to expose their charging infrastructure to any customer that has a valid contract with an EMSP already registered in the Hubject network. CPOs have their dedicated service interfaces in OICP.

e-Mobility Service Provider - Fundamentals

On the other hand, we have e-Mobility Service Providers - those are the partners that would like to offer access to big public charging infrastructure to all of their customers. OICP in this case allows them to identify and communicate with charging stations which are available in the Hubject network. EMSPs also have their dedicated service interfaces in OICP.

Offline & online EMP

Hubject distinguishes between offline and online EMP. Offline EMP stands out with no need for real-time connection for authorization - the most important process. Offline EMP does not have to handle authentication data on its own, instead you push the data to the Hubject platform. After that, Hubject will try to authorize any incoming charging sessions with the data that was sent and without any additional interaction with EMP (if that's possible). That comes with a small trade-off: as an EMP you will need to pull CDRs on your own from the Hubject platform. It will not be automatically forwarded to you after the charging session is completed. We may also have an online EMP which is characterized by real-time connection for authorization. That means that this kind of EMP must implement authorization service and handle authorization start/stop requests on its own. That will allow Hubject to forward requests automatically to EMP if it cannot authorize them on their platform.

On the other hand CDRs which are created are automatically forwarded to EMP in almost real time. That means that online EMP also must implement a service for accepting and processing CDRs.

CPO Services

Now, let's briefly introduce services from a CPO perspective.

The first one is e-roaming authorization service which covers all authorization processes, including remote start/remote stop and CDR processing. Then we have e-roaming reservation service, as the name suggests it allows you to reserve a charging station - this feature can be optionally offered by CPO. Then we have e-roaming EVSE data and e-roaming EVSE status. Both services allow you to push and pull EVSE data with but with a small difference. EVSE data is all about static data, like location, and EVSE status is all about dynamic data. Then, we have e-roaming dynamic pricing service, even though it's dynamic it covers mostly flexible pricing which we'll discuss later. For now, we need to remember that this service allows you to push and pull pricing product details and see which pricing product is specified to given EVSE. Then we have e-roaming charging notification service. Basically this service covers all the events that can happen during a charging session i.e. start/stop, progress or error.

EMP Services

When it comes to the services from EMP perspective, it's almost the same as for CPO with one small detail. We have an e-roaming authentication data service. This service allows EMP to push authentication data to the Hubject platform. This option allows EMP to behave like an offline EMP which we have covered before.

Release policy

At the end of this short introduction we also need to mention a release policy, because it's very specific in OICP. Each previously mentioned service is versioned individually and independently from our OICP version. For example, we might have e-roaming authorization service in version 2.1 and we may have OICP version in 2.2 at the same time. Each new OICP release version results in a new service version specification; those are the services that will be supported. Each new OICP release version must be supported by Hubject for at least two years. At last, each new implementation should be done with the latest OICP version. Currently it's 2.3. Here we have an example of how release policy works in practice. The data here is not valid and it's only for the need of the presentation.

As you can see each OICP version has its own service version specification which is mandatory for a given OICP version. First two OICP versions 2.0 in 2.1 are already deprecated, therefore for e-roaming service x version 1.0 and 1.1 is also deprecated. The next three OICP versions are still supported, therefore e-roaming service x version 2.0 2.1 and 2.2 is also supported. If OICP version 2.2 becomes deprecated, then e-roaming service x version 2.0 and e-roaming service z version 2.1 also will become deprecated, because the next OICP version 2.3 is not supporting those service versions. On the other hand, for e-roaming service y version 2.1 would still be supported, because the next OICP version still supports that service version.

In this course we will focus on the latest OICP version which is 2.3. In this table you can find the service version specification. We will cover

  • e-roaming authorization service 2.1
  • e-roaming authentication data 2.1
  • e-roaming reservation 1.1
  • e-roaming EVSE data 2.3
  • e-roaming EVSE status 2.1
  • e-roaming dynamic pricing 1.0
  • e-roaming charging notifications 1.1