Actively supported two commercial open standards facilitating EV roaming.

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

Interoperability demands a flexible approach and cooperation between market participants. For opening the electric car charging market open standards have been established. Two are an initiative of independent associations (responsible for the development of Open Charge Point Interface and Open Clearing House Protocol). The two other open standards for EV roaming are privately held but similarly open and free to apply. Hub operators GIREVE and Hubject offer innovative customer-friendly service networks for cross-border charging. Both hubs actively support network growth. Becoming a marketplace for charge point operators, e-mobility service providers, car manufacturers, energy suppliers, and public institutions Hubject and GIREVE offer a broad range of profitable solutions and facilitated communication benefits.

Hubject’s network expands beyond Europe. At the moment hub operator connects 767 partners in 52 countries offering over 250 000 charging stations. Hubject is a joint venture of the BMW Group, Bosch, EnBW, Enel X, Mercedes-Benz, innogy, Siemens, and the Volkswagen Group. Initiated in 2012, forms now the largest pool of charging stations. Via intercharge, the dedicated e-mobility platform, provides standardized access to charging infrastructure. Besides, Hubject advises automotive manufacturers, charging providers, and other EV-related businesses launching e-mobility services or implementing Plug&Charge with ISO 15118.

GIREVE has been created as a startup by leading French players in electric mobility: Renault, CNR, la Caisse des Dépôts, EDF et Enedis. At the moment GIREVE operates on 31 European markets and offers 185 charging networks with 109 476 charging stations accessible via EV roaming. Following the open policy in November 2020 hub operator announced becoming a Full Contributor of EV Roaming Foundation (the one responsible for the development of the OCPI open standard). This provides enhanced opportunities for partners. For instance, for an operator being already OCPI compliant, there is no extra cost to connect to GIREVE. Offering two standards for interoperability enables innovation and progress for e-mobility.

OICP was designed in 2012 by Hubject - formed by leading automotive experts in Germany. Besides being the roaming platform, Hubject offers technical connection and contractual arrangements for e-roaming. The general structure of the OICP is divided into two parts - for the eMobility Service Providers and Charge Point Operators, nevertheless, the product offer is constantly being developed. Hubject proclaims the OCIP is “the most widely implemented communication standard between European eMSP and CPO systems”. The most recent version, 2.3, was released in October 2020. The newest update of the protocol follows market requirements - improves the POI quality in an upscaling market, calibration law compatibility, data process performance, and offers higher transparency on the different charging use cases. Additionally, Hubject offers helpful and relevant for CPOs set of remote testing functionalities, for complex examination of various use cases. With the recent protocol update, from July 1st, OCPI 2.1 will be withdrawn.

The protocol is publicly available at no cost and requires no registration. From May 2019, OICP became an open-source protocol, free of charge, distributed on Hubject’s website and on open code distribution systems. The aim is to include more stakeholders in the evolution of OICP. The protocol is published under the Creative Commons Attribution-ShareAlike 4.0 International License. This grants easy distribution and to be shared under the same consent. Additionally, Hubject offers Hubject-compatibility certification.

OICP is formed on SOAP (Simple Object Access Protocol) and uses an object-based approach. It’s a real-time protocol, that also offers asynchronous operations. Although a back-up database is provided, Hubject doesn’t actively support downloads to the charging station. The platform maintains a record of the transaction data.

The OICP protocol documentation establishes market roles as follows:

The EV user/owner wants to charge an EV at a charge point/charge station, and has an agreement with the eMSP.

The eMobility Service Provider wants to enable EV owners the access the charge points. In most cases, the eMSP has a valid contract and transfers information with the Charge Point Operator via Hubject’s platform. Hubject offers connection via eMSP aggregator, which enables communication with the platform. This means several eMSPs can integrate via an eMSP aggregator, hence, the sub-partners do not need to associate with Hubject.

The Charge Point Operator (CPO) manages a charge point. The operator has a signed contract and exchanges information via Hubject’s platform. Like eMSPs, several CPOs can integrate via a CPO aggregator. Appropriately the sub-partners do not need to register with Hubject, because the communication with Hubject is done via the CPO aggregator.

Hubject, being a roaming hub, facilitates communication between eMSPs and CPOs via the EV roaming platform Hubject Brokering System.

OICP supports the following functionalities:

Roaming via hub - The CPO and the eMSP system connect to based on web services Hubject B2B Service Platform. Both parties, the CPO and MSP, have an e-roaming contract through Hubject.

Ad hoc payment - ‘Intercharge direct’ is an ad hoc payment dedicated solution integrated in OICP and Hubject platform. This allows any contractless EV owner to charge up and pay at any charging station.

Authorization - Hubject links the IDs of eMSPs or CPOs and SSL certificate information. Then each does or does not authorize the charge session. Hubject’s database performs as back-up, but not actively support downloads from their database to the charging station.

Reservation - An EV owner can book a charge point e.g. via eMSP app. Hubject checks charge point compatibility with the EV.  If matches send the request to the CPO, which in return responds whether the booking was successful. A reservation can also be withdrawn.

Billing - Charge session data is recorded in Charge detail records (CDRs). Hubject passes on the CDR to the eMSP and stores the CDR in the system.

Charge point information - Uploaded charge point information can be distributed between CPOs and eMSPs via Hubject’s platform. The information areas are charge point ID, CPO, charge point name, charge point location (name, address, geocode, type), time zone, opening times, current availability, accessibility, tariffs, authorization modes, means of payment, charge mode, connector type, maximum power, hub connection, support contact number, reservation possible, real-time status information possible, predictive charge point usage, smart charging services, and the date of the last update. OICP maintains flexible pricing based on charge facility, charge point location, and time-of-use.

Real-time charge point information - This covers dynamic charge point availability status and tariff information.

Session information - Session ID, service specifics, charge point ID, authentication data, start and end time of charging, start and end time of connection, starting and stopping meter value, meter value in between, consumed energy, CPO ID, MSP ID.

Remote start/stop - From within the eMSP application, a charging session can be operated.


eMIP is designed and developed by a French start-up. Created in 2013 by leading French players in electric mobility: Renault, CNR, la Caisse des Dépôts, EDF et Enedis with the main objective to provide “open access to vehicle charging stations”. The core business of GIREVE is to offer a roaming platform for eMSPs and CPOs.

The eMobility Interoperation Protocol enables roaming via clearinghouse data. The protocol provides access to charging point databases, and smart charging features. Although the GIREVE’s main market is France, in 2017 expansion covered the connection of European operators in Austria, Germany, Netherlands, Switzerland, Sweden, UK, Italy, Romania, Norway, Czech Republic, Lettonia, Hungary, Denmark, Belgium, Spain, Slovakia, Irland, and Luxembourg. In 2018 GIREVE’s platform was made compatible with the open protocol OCPI. Currently, the roaming platform operates in 28 countries.

The most recent version, eMIP 1.0.7, was released at the end of July 2019. eMIP is open for free although requires registration. GIREVE also proposes certification services. Moreover, to join GIREVE, the before-mentioned certification is required to connect to the platform. The eMIP protocol is open and, when a partner is approved by GIREVE, allows complete benefits. This includes connecting with a different hub platform or conducting peer-to-peer connections. Note, the protocol documentation explicitly declares GIREVE as the hub platform, the eMIP in practice does not apply to peer-to-peer connections. To ensure a high level of architectural openness and up-to-date offering, GIREVE consults with stakeholders potential future functionalities. GIREVE entirely takes responsibility for the eMIP protocol, in contrast to the previously mentioned approaches (commercial and non-commercial), there is no formal eMIP-member association.

eMIP is based on SOAP (Simple Object Access Protocol). Although eMIP is designed as a real-time protocol, it also supports asynchronous operations. The peculiarity of eMIP’s architecture makes it fairly adaptable and flexible. Any new sorts of data messages, or identification methods, can quickly be added via definition tables.

eMobility Interoperation Protocol documentation defines market roles as follows:

The EV user/owner wants to charge a vehicle at a charge point and an authorization medium.

The eMobility Services Providers warrant EV owners different services amongst which EV charging service, rental, car-sharing, navigation services, etc. The eMSP has a B2C agreement with the EV owner/user and a subscription to GIREVE’s platform.

The Charge Point Operator (CPO) accesses charging infrastructure and other services to EV users/owners and has a subscription to GIREVE’s platform.

The data aggregator applies to a system controlling charging infrastructure data in a given area and which can be inquired via GIREVE’s platform.

GIREVE, as a hub, manages the eMobility Services Platform which offers and ensures technical and functional means to standard services between the eMSPs, CPOs, and data aggregators.

eMobility Interopeational Protocol supports the following functionalities:

Roaming via hub - eMSPs, CPOs, and data aggregators join, based on web services, GIREVE’s roaming platform. The protocol documentation indicates GIREVE as the hub platform.

Authorization - eMIP offers several authorization processes.

Synchronous Authorization - check-in via the charge point (e.g. with an RFID card) or via the eMSP (e.g. an app).

Asynchronous Authorisation: Authentication Data Exchange. The eMSPs upload a list of approved subscribers to GIREVE’s platform. The list can be downloaded by CPOs. When charging at the charge point, e.g. via a RFID card, the CPO verifies the ID with the list provided.

Asynchronous Authentication Data Exchange & Synchronous Authorisation covers an event when CPOs do not download the list but request GIREVE to review the EV user ID. The decision on which authorization process to implement lies at the CPO's discretion.

Reservation - An EV driver can reserve a charge point via the eMSP app. (If the option is implemented and supported)

Billing - CDRs between CPOs and eMSPs are exchanged via GIREVE’s platform. This forms the foundation for invoicing. Via Asynchronous Exchange, the eMSP can download a CDR supplied by the CPO at any time, or via Synchronous Exchange - the eMSP gets quickly a CDR uploaded by the CPO.

Static charge point information - CPOs upload charge point information to GIREVE’s platform. GIREVE verifies the CPOs contract before updating their repository. The aforementioned data can be regained by CPOs, MSPs, and data aggregators. The information hold charge point ID, CPO, charge point manufacturer, charge point name, charge point location (address, geocode, type), time zone, opening times, current availability status, scheduled availability status, accessibility, tariffs, authorization modes, payment methods, charge mode, connector type, maximum power, guaranteed power, voltage, amperage, support contact, remote start/stop possible, reservation possible, and the time of the last update.

Real-time charge point information - GIREVE’s platform receives from CPOs the current availability status of the charge point. The CPOs agreement is verified before updating GIREVE’s repository. This includes scheduled status changes (e.g. for reservation).

Charge point search - The “charge point finder” function eMSPs can retrieve a list of charge points located in a given area and fulfill a set of charging criteria, (e.g. connector type).

Session information - Recorded and sent in the CDR - Charge Detail Record, covers the session ID, CPO ID, eMSP ID, EV user ID, charge point ID, contract ID, start and end time of charging session, metering report.

Real-time session information - With offered message service, CPOs can report events to eMSPs, and eMSPs can request actions while a charging session is in progress.

Remote start/stop - A charging session can be started or terminated by the eMSP.

Platform monitoring - GIREVE’s platform introduces a monitoring ability to check whether eMSPs, CPOs, and data aggregators have a valid connection to the platform. Specially designed “Heartbeat” tests the connection. The system sends “Heartbeat” requests to the associated companies.

EV roaming charging software of the e-mobility community

Privately held protocols offer great support and match users’ expectations. Joining at least one hub will be beneficial since emobility operators and providers can easily improve services and provide a top-notch experience. GIREVE and Hubject on a road to EV roaming extend charging infrastructure with additional user-friendly features. A cross-border network is on hand, and the support of emobility experts and industry leaders ensures the coherence and sustainability of the network. Keep in mind that even though both hubs are developing their individual protocols (OICP and eMIP), they also contribute to OCPI and OCHP growth.

OICP and eMIP refine the EV charging experience

The fact that both hubs were created at the initiative of automotive leaders makes the established EV charging e-roaming solution a guarantee of stability and accelerated growth of the whole network. Besides coverage of crucial functionalities, both protocols offer and develop additional services. The proof is in the numbers. Hubject operates on more than 50 markets on 4 continents and GIREVE offers a pan-European connection in nearly 30 countries. In light of the reality that the e-mobility market is growing rapidly and 2020 was a record year for electric car sales, it is expected that the scope of both hubs will continue to expand.

An extensive scientific analysis of the four most commonly developed protocols in terms of the search for the ideal protocol can be found 

Actively supported two commercial open standards facilitating EV roaming. Discover cross-border e-mobility standards for accessible charging network.

Checklist - Core CPO platform requirements

Two actively supported independent open standards for EV roaming.

In a search for interoperability, the e-mobility market players need to speak the same language. Demand for coherent infrastructure is dictated by rapid EV penetration. Several factors, such as local policies and incentives, contribute to an enthusiastic approval of electrically-powered vehicles. Hence, the focus has been transferred to the network and its ability to create open, accessible infrastructure. To match the pace - resonate with market expectations and work together to create an accessible, open environment - the new order needs EV roaming.

EV roaming is something users cannot see but witness, and whether knowingly or not, appreciate. Open standards create the road to consistent and complete e-roaming. With a large pool of contributors, up-to-date and secure solutions are available at hand to any participant in the rapidly growing e-mobility market. To understand the role of open standards in e-mobility here are explanations for widely approved models.

Note: In the e-mobility world there are four main open standards facilitating e-roaming. Two are developed and maintained by non-commercial hub operator and independent knowledge board - OCPI Open Charge Point Interface and OCHP - Open Clearing House Protocol & OCHPDirect. Two others were developed by commercial roaming hub operators. These are OICP Open InterCharge Protocol designed by Hubject and eMIP - eMobility Interoperation Protocol maintained by GIREVE.


Originally developed by eViolin, a Dutch association of Charging Station Operators and eMobility Service Providers, that pursues national roaming with international connection, using open standards. In cooperation with ElaadNL -  the knowledge and innovation center in the field of Smart Charging and the charging infrastructure in the Netherlands - major Dutch grid operators. Initially governed by the Nederlands Kennisplatform Laadinfrastructuur (NKL) - Netherlands Knowledge Platform for Public Charging Infrastructure - a partnership of business organizations, governmental figures, and research institutes. From May 2020 the OCPI is managed and maintained by the EVRoaming Foundation. Open Charge Point Interface offers p2p and any roaming hub integration business model.

OCPI is registration-free, openly available at no cost. Published under the Creative Commons Attribution-NoDerivatives 4.0 International Public License. Hence, the distribution is free when given proper credit. Although blocks the distribution of the modified versions of the protocol. The most recent version (v2.2) was released in October 2019. Open Charge Point Interface offers a modular set-up, a very convenient way of deployment - it is up to the individual decision which modules to include. It also covers a variant check, a significant factor for peer-to-peer mutuality as there is no fundamental actor applying updates or completing to support previous protocol versions.

Open Charge Point Interface is the only, so far, set on JSON/rest and is a real-time protocol. It maintains synchronous and asynchronous operations.

Open Charge Point Interface carries multiple explications for Eichrecht (German calibration law for electric vehicle charging), as recommended by the top European e-mobility providers - Has-to-be, Alfen, eBee, and Mennekes. In March 2021 EVRoaming Foundation announced the start of the first independent Roaming Agreement pool. The organization aims to support setting up trusted agreements between parties, for either p2p or via a (virtual) roaming Hub. The pool is available for all Full Contributors (The foundation distinguishes the following membership classification categories: Full Contributor, Associate Contributor, Sponsors, and Managing Contributors).

The protocol’s documentation describes market roles as follows:

The EV user connects to a charge point in can be provided information from the MSP

The e-mobility service provider (eMSP), grants EV services to EV users. eMSP connects to Charge Point Operator (CPO) to offer e-roaming services.

The CPO manages, maintains, and operates charge points (charge stations), on the technical and administrative side. CPO is open to connecting to MSPs to offer roaming services.

The e-mobility service provider ensures charge point location information.

The eMSP influences smart charging sessions depending on extra sources of information.

The purpose of a roaming hub is to facilitate information exchange between market players. In this division Open Charge Point Interface supports:

Roaming via hub - OCPI facilitates data exchange between eMSPs and CPOs via hubs, for this operation, the protocol offers a separate hub supporting module.

Roaming peer-to-peer (p2p) - Both eMobility Service Providers and Charge Point Operators can correlate immediately via OCPI. Separate interfaces are designed for eMSPs and CPOs.

Authorization - The token module in the OCPI architecture supplies Charge Point Operators with the knowledge of any token information of eMSP. There are two ways to execute authorization, which could be real-time or via a whitelist.

Reservation - On the eMSP side, the OCPI offers to make and cancel a reservation.

Billing - OCPI supports the basis for invoicing - sending CDRs - Charge Detail Records.

Tariff information - The protocol supports the exchange of the key details related to energy tariffs. Complex tariff calculations depend on the time charged and energy. All this information is included in the tariff module.

Static charge point information - This covers: IDs, CPOs, charge point site, host, charge point name, charge point location details (name, address, geocode, type, image, platform level, directions), nearby facilities, link to a website, time zone, opening times, current availability status, scheduled availability status, accessibility, tariffs, authorization modes, payment methods, terms and conditions, charge mode, connector type, maximum power, voltage, amperage, energy mix, remote start/stop, reservation, smart charging support, and the last update mark.

Real-time charge point information - Stats: available, blocked, charging, inoperative, out of order, planned, removed, and reserved.

Session information (real-time & static) - Covers: sessions ID, start time, end time, energy consumed, CDR ID, authorization method, location, charge point ID, meter ID, currency, charging periods, total cost, sessions status, and last update. The same information can also be in real-time.

CDR information - CDR IDs, time, duration, finish status, and more.

Callibration law (Eichrecht) support - OCPI maintains the exchange of signed meter data which can be used to conform to Eichrecht - German calibration law.

Remote start/stop - The start and stop of any charging session can be done remotely via the eMSP app.

Smart charging - Several charging profiles are supported by OCPI: the cheapest charging, the fastest charging, the most environmentally-friendly charging, or no particular choices. The preferences can be registered per session by the user. The CPO can accept or decline the option. Although the smart charging profile module does provide certain options, these cannot be ensured, since other factors influence the charging session.

OCPI’s ultimate goal is to allow any EV driver to charge at any charging station in the EU. In fact, the protocol is used intensively throughout Europe (Netherlands, Belgium, Luxembourg, UK, Germany, France, Spain, Italy, Denmark, Austria, Poland), but not limited. It also gains recognition, among others, in the USA, Canada, South Africa, and India. The protocol is gaining acceptance in ever-widening circles and the number of countries is steadily increasing.

OCHP - Open Clearing House Protocol and OCHPDirect

OCHP is the second protocol that offers a hub or p2p connection. Integration with hubs is done via OCHP, and the direct peer-to-peer connection is possible with OCHPDirect. The solution is maintained and expanded by Smartlab Innovationsgesellschaft GmbH.

and ElaadNL (ElaadNL also supports aforementioned OCPI), organizations established by German and Dutch entities. OCHP is used by the roaming hub e-clearing.net (e-clearing.net also offers connectivity via mentioned above OCPI) operated by Smartlab and owned by Smartlab and ElaadNL. As a not-for-profit platform, the main interest of e-clearing.net is to develop the e-mobility market. Both available current versions OCHP v1.4 and OCHPDirect v0.2.6 were released in August 2016 (In October 2020 OCHP introduced to members the newest update 1.5, but no further public information was provided, the valid version remains 1.4).

The OCHP documentation is free to download and does not demand registration. Thanks to the MIT license, the protocol allows for open distribution and alteration. The administration of the OCHP lies on the Smartlab/ElaadNL side, which has the remaining right to apply and execute edits to the protocol. Prior and complete implementation testing needs to be conducted before a participant gains access to the e-clearing.net roaming platform. To support a coherent development of the OCHP protocol each year developers collect user feedback.

The Open Clearing House Protocol is based on the SOAP (Simple Object Access Protocol) computer protocol. It largely relies on asynchronous communication (opposed to real-time communications, as for OCPI). For instance, e-clearing.net does not store transaction data. Instead of real-time authentication, OCHP forms lists of users who are allowed to authenticate. This approach allows avoiding a single point of failure (SPOF) - if the roaming hub breaks down, charging sessions remain active.

The OCHP protocol documentation describes the following market roles:

The EV user, that has a direct or indirect contract with an eMobility Service Provider, charges an EV at a charge point/charge station.

The eMSP grants access to charge points/charge stations to the EV owner. The eMSP provides the EV user access via an RFID card or certificates. The service is supported by CPOs. The CPO operates charge points and acts as a contract agent for the eMSP. Each charging session is settled between the eMSP and the CPO under agreed conditions.

The parking spot operator (PSO) owns and operates the parking spots with access to the charging infrastructure operated by the CPO. The PSO offers a parking spot where a charge point is located and can supply information on location and availability to the CPO.

The clearinghouse operator (hub operator), runs a software platform to enable data exchange between MSPs, CPOs, and NSPs*.

*The documentation of OCHP protocol also distinguishes the role of the Navigation Service Provider (NSP), similar or equivalent to the role of Charge Point Operator. It applies to service towards the EV user for searching, locating, and routing to charge points. The party may have contracts with CPOs or MSPs.

Roaming via hub - Hub’s roaming platform connects the associated partners. OCHP is used by the roaming hub e-clearing.net, but the documentation does not specify if the roaming hub should necessarily be run by e-clearing.net.

Authorization - EV owners are recognized by tokens. The eMSP supplies a list with contract IDs of registered EV users to the hub, that can later be downloaded by CPOs. If an EV is charged at a CPO, the operator’s system checks the ID against the roaming authorization list downloaded from the roaming hub.

Billing - Charge detail records (CDRs) collect charge data, hence CDRs describe the billing. The CPO exports the CDRs to the roaming hub. The hub performs a basic plausibility check. Correct CDRs are forwarded to the eMSP. In case the CDRs fail the validation of reliability check, are sent back to the CPO for the fixing. Besides, the roaming hub also archives CDRs.

Static charge point information - OCHP can be applied to show the charge point ID, CPO, charge point site owner, charge point location (name, address, geocode, type, image), nearby facilitates, link to a website, time zone, current status, scheduled availability status, accessibility, tariffs, authorization forms, payment options, charge mode, connector type, maximum power, guaranteed power, voltage, support phone number, reservation possibility, the maximum time for the reservation, languages of the interface, user feedback form, and the time of the last update. Besides, the tariff model can handle complex advanced tariff schemes based on time of the day, date, charged energy, charging speed, and duration based on input from CPO. The CPO supplies static charge point information to the roaming hub, which can be then processed and transferred to contracted EV owners by eMSP.

Real-time charge point information - OCHP provides the current status of a charge point (available, reserved, occupied, blocked, out of order, unknown). OCHP divides real-time from static data. The dynamic data is stored in a separate database, dedicated to this kind of access. Real-time charge point information is sent to the roaming hub, then is transferred to the signed users of an eMSP.

Session information - refers to CDR ID, charge point ID, token ID, contract ID, CDR status, start time, end time, duration, charge point address, charge point type, connector type, tariffs, meter ID, total cost, and currency.

Remote start/stop - Charging sessions can be controlled via an eMSP app.


The OCHPDirect (dedicated for p2p connections) supports the following functionalities:

Roaming peer-to-peer - Achieving e-roaming is possible without a connection with a hub.

Authorization - Charging sessions can be controlled via an eMSP app.

Real-time sessions information - Start of a charging session, end of a charging session, metering information, power management information, handy invoicing.

Remote start/stop - The charging process can be controlled when stationary started via the eMSP application.

E-clearing.net, unlike commercially orientated hubs, is an open platform that facilitates the exchange of roaming authorization, charge transaction, and charge point information data (all transactions are free). At the moment, e-clearing.net requires only a fee for joining the platform.


Why apply at least one open standard? To save time and open your network to a larger number of users, increase opportunities and reap profits. Or, in other words, applying open EV roaming charging software protects against being excluded from the market. Both, Open Charge Point Interface and Open Clearing House Protocol & OCHPDirect are classified as stable, reliable, and secure solutions. The growing number of countries that support the development and promotion of both solutions indicate openness, independence, and royalty-freedom. Open and modern approach contributes to fast penetration and enthusiastic approval. Many countries are in the early phase of charging infrastructure development. Open standards are meant to facilitate rapid growth and ensure up-to-date functionality.

OCPI and OCHP support installing a public open charging network

Open Charge Point Interface and Open Clearing House Protocol are developed and supervised by non-commercial organizations. Demand for roaming includes cross-border connectivity. The future of the open network will largely depend on the willingness of partners to collaborate and regulatory guidance. For instance, some countries already established conditions for operation on the domestic market. Slovakia requires new parties within three months of the commissioning of the recharging points, to be connected to any roaming platform that connects more than 80 operators. In Norway, Oslo authorities formed an open policy for sharing with third parties. Berlin expects every Charge Point Operator operating a recharging point in the public domain to register it in a central authentication platform managed by the city, offering access to the customers of each eMobility Service Provider under comparable conditions. To meet the conditions, it is necessary to open a network. Following the 2050 EU strategy, soon it might be mandatory to provide seamless connection on large networks in the Union.

Two actively supported independent open standards for EV roaming. Discover cross-border e-mobility standards for accessible charging network.

EV roaming with open standards - OCPI and OCHP 

Replay and transcript of eMobility Open Standards webinar.

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

On October 14th Piotr Majcher and Krzysztof Ciombor led a webinar in which they discussed open standards applied in emobility. Below you can find a video recording of the presented use case, and a transcript for those of you who prefer the written form.

Unlocking eMobility platform using Open Standards - video:

Unlocking eMobility platform using open standards - transcript:

 Hello and welcome to our meeting about the emobility. We'd like to talk today about unlocking the eMobility platform using open standards. OK. Two important things worth sharing before we start. The first one is, as you can see in the topic, we'd like to talk today about 

, but not only. We'd like to also mention different approaches to unlock mobility platform, which are, for instance, OICP by Hubject. And other different protocols allowing to do the same, but in a different way. And the second important thing, we would like to show you, is that we are going to talk about the use case. It's not going to be a theoretical presentation. We would like to show you a step by step description of how we unlock mobility platform using open standards. Let me just quickly go through the agenda. We'll start from the short introduction and just off ahead, we'll go through the description of how we open eMobility platform using the open standards. We'll start from the initial state of the project. That was the point when we decided to introduce open standards to the platform. Then we'll go a bit deeper into technical details. We will describe the transition process and at the end of that part, we will tell you a bit about the challenges and risks. The last part of the presentation is about the results. So, actually what we achieved by opening the platform using open standards. I'm Piotr Majcher and I am a CTO and co-founder of Solidstudio. Three years ago, I and my partner decided to stop working as consultants and we started a software house.

 Now, apart from being IT experts, we are also focused on the EV market, especially in the field of the integration between different components and different partners in that market. Here with me is Krzysztof Ciombor. Krzysztof, can you say a few words about you?

 Yes. Hello, everyone. I am Krzysztof. I've been working with Solidstudio for almost two years now. I am the lead developer in eMobility project. I was primarily a backend developer specializing in JVM technologies and I particularly love the Kotlin programming language

 Thanks Krzysztof. Just let me add a few more things about us. So, why do we share these insights? We have been cooperating with one of the European EV leaders for two years and we have experience in developing both sides of this market. So we were responsible for delivering features normally recognized as something delivered by eMobility service provider. But we are also responsible for the development of the charge point operating platform, and we were involved in the integration between the partners using both approaches. So we were using open standards like OCPI standards and OICP, but we are also using custom APIs.

I'd like to show you a few numbers about the EV market now and in the future. I'd like to focus only on the first number. As you can see here, in 2018 in the UK, almost two percent of all cars sold were electric. I've seen quite hot Twitter news a few days ago that in Norway last month, more than half of the cars sold were electric. I think it proves that the movement of introducing electricity into transport is 

. And there's no question ‘if we should do that’, but ‘how should we do that effectively?’. Before we go to the technical description of our journey from closed to open platform...

 ...let’s talk a bit about the benefits of open standards. I'd like to start with the question. So the first benefit is business model optimization. The question I'd like to ask you is ‘what limits you and your company when making a decision about the integration with partners?’ We have a technical background, but we are working with sales and other business teams.

So how does it work? Normally, the ideas about integration with the partner are brought by the sales reps to the company. They have ideas, because they see some potential benefits from integrating with network parties. But before making the decision about integration, they have to know the time needed to deliver that. They have to somehow involve the delivery team, and in general, integrations with other partners are time-consuming tasks, because we have to remember about two things. If we are integrating with another company using a custom API, we are synchronizing two things. We are synchronizing models and we are synchronizing work of two teams working in a separate organization.

When it comes to the model, we know that the same things can be molded in a different way. For instance, one CPO (Charging Point Operator) may use only sockets and that's enough for their business. But another company may use a much more sophisticated model of charging infrastructure. They may use location, charge points, maybe electric vehicle supply equipment, connectors. And when we are doing the connection between those two different boards, we need to establish some common language. So we have to synchronize our models to be able to talk to each other. And the second point is synchronizing two teams and it's always challenging, even inside one company. My experience says that integrating using custom APIs is a matter of months, not weeks or days. The business knows the answer and that is let's assume three months. That starts during the calculation because they need to compare possible benefits coming from the integration of the partner with the cost of the delivery of such integration. And we just realized that in some cases, business decisions are driven by the cost of technical, by the cost of the delivery of the integration. That's, of course, not good.

Now, imagine a different scenario. Imagine that business doesn't have to ask tech teams about the estimation because they already know that integration with the partners normally takes four days. And for instance, there are some cases when no code has to be changed because everything is done on the platform. Such flexibility to our business can be brought by introducing open standards. The second point, our OCPs are also very important. And the point is our users. We believe that no matter what we are doing, so if you are the CPO, ESP (eMobility Service Provider), or as we are Solidstudio, a software house, users are the central point of our business. It's because scaling in most cases means that more and more users can benefit from our services.

So I’d like to start again from the question, what can make our users' life easier? According to the surveys, users are still worried about not having enough access to efficient charging stations. This is recognized as one of the most serious barriers to purchase EVs. Imagine that the user of the platform, which is not integrated with many partners, is somehow locked to the infrastructure provided. We can compare that to the situation of traditional cars. In order to buy gasoline, you are forced to look for the petrol station of the partner that you have a contract signed with. That's, of course, not a user-friendly approach. But by introducing open standards and by integrating more and more partners, with a quick integration, we can change that. And we can open as a CPO, our charge points to be used by any user on the market. And on the other hand, from the ESP perspective, we can allow our user to charge at any charge point. That brings us to that next point, which is, I believe, a long term goal for the whole market, so it's building a real European charge point network.

I think that the current state of the charge point network in the world can be compared to what we saw in the early years of electricity. There were a lot of small power plants and they produced energy without any kind of standards. Now we have one single grid in Europe and the end-user is not even aware of all those technical details under the hood. Any device can be plugged in and in any place in Europe and it just works. On the other hand, multiple power plants are also connected to the same grid. We can build the same type of experience by introducing more and more operators and mobility service providers into the same network.

I think that we can conclude the introduction now. And now we'd like to dip a bit deeper into the transitional process.

Initial state of the project - scattered, custom-made API

 Thank you very much, Piotr. OK, now we'll talk a little bit more about the technical details, starting with the initial state of the project, which we had a couple of years ago. And it was actually the point where we started to wonder if we can do better. We had many custom-made APIs exposed specifically to the partners that we were integrating with. And it quickly became apparent that this solution is not going to work for the future and it's not going to be maintainable. So let's start with the initial state of the project. As I said, we had multiple custom-made APIs. Those APIs were very limited in the scope of the data that we were exposing. Those APIs were only capable of exposing basic static data out to charge points, which means including the location data, for example.

But it definitely did not support full e-raming flow. And moreover, there were no real-time updates. So whenever a partner wanted to have the current state of the charge points, for example, they had to do it in a polling fashion, which is, of course, not very efficient. Also, we had multiple different APIs exposed to our partners. And as I said, this solution was not very scalable.

Main challenge with this approach was that we had to implement monitoring in multiple places in order to make sure that our APIs work correctly. We also wanted to have those APIs secured. But since we had contractual obligations different in the set up with every partner, we had to have multiple different security mechanisms in place, and we had to test every one of them independently to make sure it worked correctly

Finally, as I already mentioned, the maintainability was not so high, because any change done to our system would then need to be propagated and updated in every single one of those APIs. So, as you can imagine, this leads to an exponential explosion of the cases that we need to cover.

We need to make sure that we test them and we are exposing the correct things in production. And the biggest issue with that approach was also something that we already mentioned from a business perspective. Since we did not have the opportunity to create new integrations in short time This leads to scaling problems because we are only limited to a single user group, which are actually the users that have contracts signed directly with us. As, for example, CPO, use our touchpoints. And we can not extend this to a larger group of people that will be able to use our charge points.

So let's briefly talk about the transformation process and how we applied those changes from a technical perspective.

The transformation process itself is relatively simple. We first decided on the open standards that we want to use and then implemented the simple use case to confirm that the standard is really suited for our needs and we can actually implement it correctly. Then we added successive modules to enrich the API and exposed new functionalities. And finally, we achieved this huge milestone, which is the full e-roaming functionality.

This allows us to open our charged points to more external users and more external integrations. And this is like the full e-roaming functionality is beneficial for both the MSP (Mobility Service Providers) because the MSPs want to attract more users by having more access to more charging networks. This approach is also very attractive for CPOs because we want to increase the utilization of our charge points, and if we are exposing them to a much larger user base, and this means that the utilization will eventually grow, and our charge points will be used more and more. And finally, we can apply the testing and monitoring staff directly to these open standards and have centralized in one place.

As you probably are aware and you have probably seen this picture many times before, there are basically four open standards available on the current market. Of course, for the purpose of this presentation, we are focused mostly on the CPO and MSP connection, which may or may not include the clearinghouse in between. In this area, we have basically four open protocols which are widely used across Europe. This includes the OICP protocol, the Open Intercharge Protocol, which is a proprietary protocol, developed by Hubject, we have the OCPI, which is actually a peer to peer protocol, but it also can be used in a peer to hub fashion and this is currently maintained by the EV Roaming Foundation (previously, it was maintained by a Dutch company). We have the eMIP, the eMobility Interoperation Protocol, which is a kind of proprietary protocol developed by a GIREVE platform. They are a French market player and it also is a hub connection to their platform. And finally, we have the OCHP protocol. Again, to a clearing house and is maintained by the e-Clearing Net Foundation.

So even though those protocols are very similar to the functionalities they expose, like every single one of them allows you to do, the basic authorization exposes the charge information, has a possibility to get information about the session and CDR, and finally, support for e-roaming info. We still need to decide which bridge protocol suits our use cases the best. Having selected the protocol, we can continue with the step by step implementation.

It's important to realize that most of those protocols and in particular OCPI protocol allows us to do the integration step by step. What I mean by that is that OCPI protocol exposes so-called modules which can be implemented basically independently, and that allows us to start with a very simple use case. Then out successive modules along the way for the simple use case, we selected POI data sharing. This, even though it comes with the initial spike in the development effort, because we need to, for example, implement the credentials module in order to perform the full handshake flow.

After completing that once for the first partner, we can basically reuse the implementation for any successive integration with any new partner. And POI data is only about a single module, which in OCPIs the locations module. And in our OICP for Hubject, we can use EVSE data exchange in order to achieve basically the same result. So even though this process is simple, we can already see after completing that, we can already see the benefits, because we can expose to POI data, which can then be used, for example, for display purposes on external partner modules.

Having done that, as I said, we can continue with our successive model implementation along with the new requirements that come from new integrated partners and for this purpose. We can then start, for example, sharing the CDR if a partner is interested in that and finally complete the e-roaming milestone, which for OCPI I would include command sessions and CDR module and remote start-stop session for Hubject OICP protocol. By doing that, we can already start switching existing partners and deprecating the legacy integrations in favor of using open standards. This allows us to successfully remove those custom made APIs and centralize everything within this one open protocol. But that's not the end. We can push it even further and include additional modules like, for example, tariffs, token and charging profiles to improve this platform even more and expose more functionalities to our users.

OK, let's talk about the challenges or risk factors that we encountered along the way and explain what are the main problems and what you should be aware of? OK, so first of all, this is a brief overview of the challenges we encountered. The situation may be different for your company, but in general, we believe that those are accurate representations of everything that everyone is trying to use open platform struggles with. This includes actually a standard selection, many internal processes and data models to the open standards, applying some modifications and extensions to the standard, migrating to a newer version. And finally, the necessity of supporting multiple open standards and open standard versions.

First of all, accurate standards, selection, as we described. There are multiple standards available on the market. So it's important to realize which standard you should implement. This is, of course, dictated by two factors. If we want to achieve wide market coverage, we should probably support the standards which are used by most of the players on the market. But it quickly turned out that this is actually difficult to find out. And it may come only from experience or by, for example, being a member of this larger EV market or EV platform. For example, the EV Roaming Foundation, if you are a member, they may have some data about that. This is particularly important for OCPI where the latest version is 2.2, the 3.0 is in progress, but actually, the most used one is still the 2.1.1 Version.

Selecting the appropriate variant is also important,if you want to apply additional features that are needed for your company, like, for example, supporting the charging profiles and thus enabling the smart charging because this is available only in OCPI 2.2 and it's actually not supported in previous versions. So depending on the use cases in your company, you may want to implement a different standard.

When it comes to matching internal processes and data models to the standard, it comes in two ways.

So first of all, as we already mentioned, you for your purposes internally may model the data differently and the OCPI or OICP or any other open standard requires you to do so. That may need additional transformation/mapping layers in between your internal data models and the open protocol itself. So even though this representation you may already have in your system, in order to fulfill the open standards requirements, you will probably need to remap them to comply with the schema, when it comes to the process adjustments. This is particularly important for the CPI protocol, where this protocol is bi-directional. That means that it supports both a push and pull source. This is not usually the case for developing rest APIs.

For example, where it is mainly about getting the data and there is no active push. However, by doing the bi-directional communication, we achieve real-time updates where we can immediately push, for example, the EVs status change to our partners. And thus they can, for example, show it to the user if a charge point is available or not. I also want to mention the data quality, and this is a part of the processes adjustments since we want to ensure the best experience for both our integrations and our partners, but also for our users.

We want to make sure that the data we're exposing is actually of high quality, which includes, for example, checking the location data, if it's accurate, checking the street name, if correct, et cetera. So some partners are already doing that on their side. For instance, Gireve has their own team, which handles data quality. But for some integration, it is up to you to make sure that the data you're exposing is of high quality.

When it comes to standard modifications and extensions, this is again driven by both sides. It can be driven by us or it can be driven by our partner. What we mean by driven by us is that sometimes we actually want to expose more data than the standard provides. Imagine a case where you as a CPO have a platform for gathering telemetry data from a charge point, and you want to share it with telemetry data with your partner. But there is no property for doing that inside the open standards. If there is an agreement between you and your partner, you can proceed with extending the protocol and thus exposing more data for this particular integration. This is very useful in some cases, but the modification itself can be also driven by our partner, which is a very prominent case in OCPI 2.1.1 where there is actually a slight gap in the standard itself. Basically, there is no property to properly connect CDR to a session. So some partners are forcing you to adjust the standard and again. For Gireve for example, they introduced their own property called authorization idea, which they're using for these purposes. But it means that you will need to adopt the standard on your side and comply with those requirements if you want to integrate with Gireve when it comes to new standard migration.

So, as we already mentioned, the OCPI 2.1.1. version is the most widely used and adopted version on the market. Both version 2.2 Introduces some major changes, which, for example, enabled the smart charging, so you may be tempted to do the upgrade to the latest version. But this also needs to be coordinated properly with the partner you want to integrate with. And it's not always so simple.

Finally, we want to mention that there will be at least for the next couple of years it will be necessary to support several open standards for two reasons. The first reason is that those standards are constantly evolving and they serve different purposes. So if you want to integrate, for example, with Hubject you are basically forced to use OICP protocol. But the other reason would be to enable more peer to peer integrations. You would want to go with OCPI, but the reality for the next couple of years is probably that we either end up with this status quo where we need to have our support for multiple standards.

There are a couple of predictions that it may happen that there will be some kind of unification of the standards, and that will be one open standard. It's up to discussion whether or not this is a probable scenario. But if not, and if the open standards are there on the market, we may need to support them for the future.

So to conclude this section, we want to compare this current status with the status that we had before. So all of the issues we had previously are now solved. For monitoring, we have a single centralized place where we can monitor our APIs and make sure that we are not doing anything wrong. For security, it's not only about a single entry point but also about the unified mechanism where previously every single API of ours could be secured using a different mechanism like basic authorization. Some API can use authorization talk and now they're all forced to use the authorization mechanism provided by the standard. And finally, maintainability. And it should be pretty obvious any change applied directly in our system, can be updated only in one place and propagated to all our partners. It also includes easier testing because we can use some open-source testing tools. We can use interoperability tools to confirm that our APIs are working. Finally, there are also some events called plugfests where everybody gathers and tests their integrations all together to make sure that everything works. If everyone is speaking the same language, which is in our case the open protocol, they can communicate seamlessly and confirm that their APIs are working correctly.

 Thank you Krzysztof for taking us on a journey of opening the platform, using open protocols. I'm sure that this type of information would be very useful before someone decides to introduce open protocols onto their platform.

This is actually the last thing we'd like to share with you, and these are the results of what we did. And we needed four months in order to introduce OCPI into the charge point operation platform. And after that, we were asked by the business ‘How long does it take to integrate the next partner?’ and we estimated the effort to several days. It was about four days. It means that we reduce effort to integrate a partner by 95 percent.

I think that does answer the question that I asked you when we started, how to make our business not limited by the technology. Thank you. That's the end of our presentation and we still have the space for the questions. So if you have any questions, please, use the chart on the right side, and we will do our best to answer.

OK, so you see the first question from Chris. Could you briefly describe some main differences between, OICP and OCPI. How about the cost effectiveness of OCPI? Is it worth a shot? I think this is a question for Krzysztof

 Sure, I can try to explain. So the main difference between OICP and OCPI would be the connection type because OICP's strictly pure to hub connection and Hubject in this example. Where the OCPI is an open protocol which allows both peer to peer and peer to hub connection. Now, in terms of the properties that are exchanged through those protocols, the OCPI is actually more flexible and includes more data. This is especially important, for example, for the German market, where we need to have the signed meter values included in the standard for Eichrech conformity, which is a German specific case, but it's still needed for the open protocols when it comes to the cost effectiveness.

This is rather a question of what is your use case and how you want to integrate with the partner. If you can do a peer to peer connection and this suits you best, it's probably good to try the OCPI. But if you want to integrate the subject, there's no other way. And to use the OICP.

 Thank you Krzysztof. And I hope that answered the question. Here we have another question from Michael. Do you operate on your own network or do you support other networks in those integrations? Solidstudio is a software house and we are supporting our partners, who are looking for technical support. So we have an 

 so we know how to do that, but we don't have ours as a Solidstudio, we don't have our own network. Please let me know if that answers your question.

And we can go to another one from Adam. Question: What is the adoption of OCPI among EV charger manufacturers or suppliers? As Krzysztof mentioned, in order to know such details, we would have to be the member of some bigger organization, some organization that connects similar companies. We know that those four open standards that were presented are widely used, and we have an experience that since we introduced that OCPI into the company, we already have a few other partners that are willing to use that. We also have one partner that used our custom API and now is willing to switch. So I only can say that the adoption is quite, quite big, but I can't give you an exact number.

OK. And the next question: in your opinion, what are the missing features you would like to see in the future of OCPI versions?

 So first of all, I think the standard is relatively good for the cases that we are apparently trying to do, considering the whole EV market. But for the future, they would definitely need to be supported for the upcoming things like the new ISO 15118 standard, which is about the plug and charge functionality, which basically means that you can skip the whole authorization process because the car itself will be authorized within the charge point. So I would like to see OCPI supporting that, maybe not for the features of the OCPI, but I would really like to have a well-defined testing suit and maybe some testing plasma for OCPI because from our perspective, especially, the handshake flow is pretty tweaking OCPI and a lot of people make a lot of mistakes there. It would be nice to have it improved for future integration.

 Thank you Krzysztof. That was the last question we have for now. Let's wait five minutes more. And we have another question, from the US? Some are saying there are problems with PKI governance. Can you please discuss the role of PKI in OCPI?

So by PKI, I mean Private Key Infrastructure. So it's not included, at least in the version 2.1.1 OCPI defines the shape of the data that are replaced by their partners. So it's rather the definition of the in short, JSON's that they're sent from one partner to another and also defines something else. OK, so the concern is with the PKI in OCPP. Well, OCPI, but you know, OCPP. So OCPP is a bit above what is the scope of our webinar. So we are talking about the integration. OK. Sorry for interrupting, but I'm getting more and more information from Michael. So the first question was for the PKI in the context of OCPI, but it's in the OCPP. So is there a similar concept OCPP. OK.

 I would try to clarify that. I already mentioned that while telling you about differences between OCPI and OICP in version 2.2, we do have support for signed meter values which can be used to exchange those authorization data, and also assigned data through the OCPI protocol. As I mentioned, this is required for German conformity. But is still up to our partners to decide on the standard of the encryption and the key exchange, but it's technically supported in OCPI 2.2 but as far as I know, there are plans to improve these OCPI 3.0. I hope that answers your question.

 Thank you, Krzysztof for the support. OK. So if there are no questions. Please feel free to reach us out using our emails. If you have any questions regarding our presentation or in general if you'd like. If you are looking for support in those topics that we presented, do not hesitate to contact us. Thank you very much again for your time for being with us here. And see you next time, hopefully in the next webinar by Solidstudio.

Replay and transcript of eMobility Open Standards webinar. Click to learn more.

Unlocking eMobility platform using Open Standards - #OCPI use case

Anchor points on becoming Charge Point Operator. Click to learn more.

After founding Solidstudio, Pawel was an originator in terms of pursuing expertise in eMobility. With the build-up of a solid knowledge-base on industry’s needs & wants, he now keeps a close eye on products’ development. He’s also hugely responsible for the business’ side and designs the business models for our products.

Paweł Małkowiak

The e-mobility market is booming but still enigmatic in terms of processes between market participants or taken roles and available standards. In general, we can distinguish two sides of the charging ecosystem - being on the user-side eMobility Service Providers and Charge Point Operators providing devices and software to manage the infrastructure. In this piece, we address the part of the market responsible for deploying and managing charging points (also called charging stations).

Charge Point Operator or Charging Station Operator is responsible for providing, managing, and setting the charging infrastructure for the e-mobility industry. A CPO business operates a network of charging points - the hardware devices and future-oriented software. The value lies in connecting smart charging equipment with eMobility Service Providers. A CPO assures the network works seamlessly. This includes diagnostics, maintenance, price setting, and Point of interest (POI) data management.

On the operators' side is to provide available, steady, and 24/7 functioning EV chargers. Managing systems need to real-time report any malfunction that occurs with the device. And if possible, automatically fix it.

The matter of real-time also applies to software platforms. Necessary information delivery for adequate decision-making will help to shape operations, business, and technical statistics analysis. Even when the service does not assume the large scale, automation is the core in reducing the Total Cost of Ownership (TCO). Automated processes should hassle-freely handle transactional and technical concerns without engaging employees.

Charging Stations require sufficient energy supply and distribution. Smart management during peak hours, involving renewables and storing battery power, reduces capital and operating costs. Identifying areas for cost optimization and investigating user’s expectations will help balance business processes. This market will continue to grow, for now, with a focus on segmentation, preferences, and habits, the hidden (greener) Holy Grail is possibly up to grasp.

How does the Charge Point Operator platform work?

First, we need to explain that an Operator’s role range may vary. In some cases, CPO owns the infrastructure, provides connectivity, and can supply only one side of the ecosystem. Some of the CPOs act like 

 . Since it’s a mutual interest, they offer other eMSPs access to the charging infrastructure.

To explain the charging ecosystem’s general flow, let’s place CPO as a separate service - hardware and software provider. In this scenario, CPO exposes access to the charging network and relies on eMSPs.

CPO exposes charging network with tailored API. In this scenario, each new linking with a partner follows the provided documentation and matches eMSPs API. This approach is time-consuming and limiting in terms of fast integration and scaling. Via custom API, we link two models and two teams working separately. The matter lies in the charging options provided, and the service eMSP wants to offer. The integration via custom API takes months. Assuming that each operator offers only integration via its API, connecting with each requires substantial resources and time.

However, there are two faster ways to connect and open the charging network.

 follow the general principle in the e-mobility world, providing an open and accessible network to EV drivers. Charge Point Operator can expose charging network to any eMSP in a standardized way, enabling faster integration and scaling. With Open Charge Point Interface (OCPI), managed by 

 , the linking between partners can be done within several days. Open Standards, besides, provide transparent information to consumers about charging locations and prices. Moreover, they are developed and updated by a strong community 

following technical innovations and market requirements

 . Also, as a part of the ultimate goal, Open Standards are free to use. By simplifying, standardizing, and harmonizing charging networks, standards are an integral part of rapid e-mobility growth.

With one contract owned Charging Stations become exposed to thousands of new users and eMobility Service Providers. Thanks to the Open Intercharge Protocol (OICP), integration with a hub like GIREVE or Hubject opens the broadest spectrum of possibilities. E-roaming networks are the desired state of EV charging cross-border arrangement.

Being integrated with a hub does not limit the other possibilities. Charge Point Operator’s platform can be exposed at the same time to the hub, and eMobility Service Provider via the most commonly applied (and supported) OCPI standard.

What are the Charge Point Operator platform’s features?

At the most basic level, every Charge Point Operator platform should provide via admin panel pricing, reporting and billing solution, remote charging stations management, and smart energy management.

The comprehensive backend system allows CPO to 

 for the charging session. Rates can be modeled and verified at the admin panel. The charging session’s price can be specified on the total charged kilowatt-hours, the duration, or a blend of other circumstances (additional parking fee, time & day of the week). The B2B contract between CPO and eMSP includes all tariffs and is invoiced at the end of the billing period. The price that is exposed to the final user (EV owner) depends on the individual eMSP price management system.

EV roaming with open standards - OICP and eMIP

02 APRIL 2021 • 11 MIN READ