See the first lesson of our comprehensive e-mobility 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.

Open InterCharge Protocol Training - overview

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.


Previously mentioned simplification of communication is mostly achieved by using well-defined and standardized protocol called 

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

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:

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.

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.

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.

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.

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.

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 

Open InterCharge Protocol Training. Overview

See the second lesson of our comprehensive e-mobility training on OICP!

Open InterCharge Protocol Training - Lesson 2

In this lesson, let's make an introduction into the business side of Hubject platform and processes that are behind. Even though from a developer perspective it may not seem to be important, it's good to know that and be aware of Hubject platform specifics.

Probably the most important business process is onboarding. It may differ a little bit between CPO and EMP so we will cover them both separately. According to Hubject, the typical onboarding may take from 10 weeks up to 12 weeks.

The first phase in onboarding is the pre-contract phase. In this phase, you will share preliminary information, questionnaires, security requirements before signing a contract. Here you will also define your operator ID, generate CSR and white-list your server IP. Then, we have an onboarding start phase. It's basically a continuation of the pre-contract phase, but here you will receive RFID cards from Hubject for test purposes. The QA phase is all about implementation of services, configuration and testing integration. Then you will need to create a production environment and perform final tests with Hubject. That is a mandatory step before starting integrating with the Hubject platform. The last phase is the offer phase; as a CPO you may create an offer for other EMPs with detailed service specification and pricing.

Onboarding EMP is very similar to onboarding CPO, there are just small little differences. In the pre-contract phase you will define your provider ID, as well as generate CSR and whitelist your server IP. In the onboarding start phase you are responsible for sending RFID cards to Hubject for test purposes. The QA phase and production ready phase are almost the same. Here you will implement services, configure them, perform integration tests, prepare production environment and perform final tests with Hubject. The last subscription phase is specific to EMP. Here you can subscribe to services offered by other CPOs. This step is mandatory in order to use the charging infrastructure offered by Hubject network. Normally, you as an EMP would like to subscribe to as many CPOs as possible, but be aware that each CPO may have different details, requirements and pricing for the same service type.

Service offers are created by CPO; they are used for modeling contract-based relationships between EMP and CPO partners. Service offer may be different depending on the CPO and can include individual details of some operations; i.e. different pricing per charging.

 The first one means that the offer is available to all EMP partners that wish to subscribe to it. In other words, any EMP that wishes to subscribe to it, must agree on common terms defined by CPO. The second one is a bilateral offer and it means that you can set a specific offer between EMP and CPO. That's very useful if you have an individual contract between those two and you still would like to use Hubject as your main communication platform.

In order to communicate, each service must be configured in the admin panel. For example: sometimes Hubject needs to communicate with your backend platform in order to perform some operations; i.e. authorization. Differently to OCPI, in OICP there is no endpoint structure or discoverability included in the standard. Only the message format is known to everyone. In order to start integrating with other partners, you need to provide some values i.e. service URL. Of course, each service may have different options to set. As you can see on this example, authorization service may have an option to specify whether you would like to process requests in online mode.

From EMP perspective, you would like to subscribe to service offers. In other words, you would like to have some kind of contract between you and CPO, in order to start using their charging infrastructure and offer it to your customers. That's exactly what is being done in the process of subscribing to service offers. In the Hubject platform you will see multiple offers for different services from different CPOs. Each offer will have individual terms, conditions and pricing. You need to take a look at the details and decide whether you can agree on them. If each partner implements a given service and EMP would agree on CPO terms, then both of them can start integration by subscribing to service offer.

Security mechanism is rather simple. Any partner’s backend platform will communicate with Hubject via a secure connection. Security is based on SSL certificates and IP white-listing. SSL tunnel guarantees confidentiality via encryption, integrity via checksums and authenticity by using digital signatures and certificates. Reverse proxy will handle central https encryption and authentication of all incoming connections. Both reverse proxy and firewall provide access control by using white-lists which grant access only to the specific IP addresses.

In order to start integration between CPo and EMP, CPO must provide a pricing for an authorization service, then EMP may subscribe to the service and therefore its customers can use the charging infrastructure of a given CPO. There are four different types of pricings.

The first one and the most common one is standard pricing. It's a one simple price for all stations. It can be for example per hour, per minute or per kilowatt hours. Then, we have a pricing product which allows us to create multiple pricing products for stations i.e. we may have different pricing per sub-CPOs or different pricing per charging speed. Then, we have flexible pricing which is a slightly more complex version of pricing products. It allows us to create a set of complex business rules when it comes to the pricing. For example: we may define different pricing per EVSE, per location, per time or the combination of all above. It's also worth mentioning that EMP can pull pricing products in the same format; so it is understandable by both sides. Any pricing change needs to be presented before, for at least 42 days according to Hubject. Also, it's not recommended to change pricing very often, because EMP in the past agreed on some specific terms and conditions and now it needs to agree on the new one. The last type of pricing is dynamic pricing, which allows us to change pricing on a daily basis, but it's not so simple. It is allowed only for the bilateral offer between CPO and EMP because both sides need to agree on specific terms and conditions and their implementation must be prepared for that.

Now we're gonna talk about solutions offered by Hubject, but which are not strictly connected with OICP protocol. The first one is intercharge Direct. In general, this solution allows customers to perform a direct payment to the CPO, without having any additional contract with EMP. This product is mostly intended for CPOs, as it increases their customer base. The flow looks very simple: the customer scans QR code at the charge point, then CPO specific website is loaded, the customer can then choose a specific charging product and payment provider after, that you may agree on terms and conditions, perform a final payment and then the charging session can be started. Of course, as a CPO you also need to perform some additional actions in order to configure that. Especially, you need to have a paypal or stripe payment provider account and also upload data needed for white labeling like logos or some custom messages.

Hubject also offers another service called intercharge Settlement. This service is supposed to automate the settlement process between CPO and EMP. It is built on the CDR Rating process, which calculates the final settlement based on product tariff and CPO tax configuration. Hubject will automatically initiate bank account transaction from EMP to CPO and create invoice. Of course, the first transaction from CPo to EMP is also possible in case anything goes wrong.

Of course, there are some requirements to be met. At first, you need to sign additional intercharge Settlement agreement. Then you need to have a bank account at a very specific bank EXFS, then you need to be fully onboarded on the Hubject platform and finally you need to successfully pass the validation process.

Open InterCharge Protocol Training. Lesson 2

See the third lesson of our comprehensive e-mobility training on OICP!

Open InterCharge Protocol Training - Lesson 3

In this module, let's cover some basic technical details characteristic for OICP.

Beginning with OICP version 2.2, every communication must be based on HTTP protocol and use JSON data format in messages. In the past, it was also possible to use SOAP protocol but now it's deprecated and cannot be used anymore. Every service in OICP is synchronous, therefore for each request there must be a response. In most of the services, the response format is an acknowledgement message. When it comes to the character encoding in OICP, there must be in UTF-8. Worth mentioning is the fact that the Hubject platform is highly available. All the details regarding the SLA are individually specified in your partner contracts.

Speaking of data, Hubject aims for high quality data management to enable all partners further scaling. In order to avoid data-related issues, Hubject provides point-of-interest data quality guidelines. Each guideline is a list of property names together with type, description, example and information whether this data is mandatory or not. The other reason for that step is to guarantee a good charging experience for customers and a unique selling point. Each partner is obliged to fill in a point-of-interest data check form and mark if they are able to meet the requirements for specific property. Building form should be sent to your support onboarding team before end-to-end test.

As I've just said, a response message should be a result of any kind of operation in services. In this response message, you must also include information about the status of a given operation. OICP has its own standardized status code and description format. State is called message property - a carrier of that information. The general status code is 000. Below, you can find an example: how it looks like in practice and what is the typical status code response.

Hubject distinguishes between four different types of status codes. The first type is internal system code; here we can include information that an error is about the Hubject system, Hubject database, data transaction, unauthorized access, inconsistent EVcoID, inconsistent EVseID, more general system or data errors.

The next types of status codes are the authentication ones. Here, we can specify more details regarding authentication related errors i.e. we may specify that we had invalid credentials for QR code, that we had invalid UID or cards not readable for RFID, that we have invalid EVcoID for PLC, that we had no positive authentication response, that we have received timeout error on QR code authentication, that we had invalid underlying EVcoID, invalid certificate or timeout error on PLC or that EVcoID was blocked.

Then, we have session related codes. What's more important, those are not the codes related with the charging session itself, but with the session mechanism. So, we may specify that there is no valid contract, that partner is not found, that partner did not respond, that the service is unavailable or that the session is invalid.

Finally, we have EVSE related codes which can specify more details about problems with charging station i.e. we can specify that communication with EVSE has failed, that there is no electric vehicle connected to EVSE , that EVSE is already reserved, that EVSE is already in use or that we have received wrong token, that we don't know EVSE ID and it is unknown, that EVSE ID is not Hubject-compatible or that EVSE is out of a service.

Some services, especially authorization service, require a session mechanism in order to correlate a series of individual operations. The typical scenario is i.e. charging start and stop, as well as pushing CDR correlated with the already finished charging session. If that happens, then session ID must be returned in a response for every initial request i.e. eRoamingAuthorizeStart. Session ID must be provided in each subsequence request. It's good to know that the session ID created by Hubject is in GUID format.

Hubject also offers a possibility to use your own session mechanism by adding two additional properties to each initial request: CPO partner session ID or EMP partner session ID. If the value in one of those properties is provided, then it will be used as a session ID after the initial request. The same value beside the session ID will be also returned as a CPO partner session ID or EMP partner session ID in order to make processing a little bit easier.

In OICP, the message format can be the same for both types of roles: CPO or EMP. Because of that, Hubject needed to create another mechanism in order to differentiate service operations between those two rows. You, as a partner, need to provide in each request either provider ID if you're an EMP or operator ID if you are a CPO. Those two identifiers are unique within the whole Hubject platform and they are assigned to you as a partner during the onboarding process. You, as a partner, may also have both rows CPO and EMP; in this case you need to provide only one value either provider ID or operator ID in each request. Operator ID and provider ID have similar format but with the small differences which we will see in examples later. In general, they are created according to the ISO15118 specification. When it comes to the date and time, it's pretty simple; it needs to be delivered in a given ISO format. It's good to know that Hubject will store those values in their databases in their original form - there will be no conversion to UTC, timestamp or any other form. Below, you can find an example of what it looks like and what the format is.

One of the most important things to remember about OICP protocol is that the data push request for the same service operation needs to be sent sequentially. For example: if you push EVSE data in a few requests, then please make sure that they are being executed one by one after a response from a server is received. The reason for that is because Hubject can process those requests in parallel, therefore sending many requests at the same time may change the expected result or even unintentionally override the data set.

Pagination was introduced in some services in the latest OCIP version. Nothing extraordinary, but it's good to know what the response looks like with properties; content which is a list of elements: number, size, total elements, number of elements, first, last and total pages. When it comes to the query itself, it's also pretty straightforward, you need to provide page and size.

Security aspect of the OICP protocol is also very convenient. Hubject will compare if the provider ID or operator ID is compliant with your SSL client certificate in every request. That should prevent the situation when some partner will perform an operation in the name of the other partner just by providing the correct ID. If there will be a mismatch, then the 017 status code should be returned with an unauthorized access message. Please remember also that Hubject will validate if the IP is on the white list, so your server must have a static IP.

Details of certificate signing request generation will be delivered to you during the pre-contract phase, but in general this process is quite simple. But first, you need to generate private and public key in order to encrypt and decrypt some messages. Then, you need to generate CSR with PKSCS10 standard. After that, you need to send it to Hubject via email and also send the passwords or encrypted files in some other way. Onboarding manager will verify if everything went correctly and they will sign those certificates. Also, in the QA phase, you will receive signed partner certificates together with CA certificates to convert them and finally you can access web services with client authentication.

Open InterCharge Protocole Training. Lesson 3

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

Open InterCharge Protocol Training - Lesson 4

Now, let's focus more on a detailed view of services used in OICP. In this part of the training session, we will cover:

Most of those services have similar flow and logic for both CPO and EMP roles, but in this module we will cover them from CPO perspective. Then we will change perspective to EMP, go through them once again and see the differences. Let's get started.


eRoaming Authorization service. First operation in the eRoaming authorization service is eRoamingAuthorizeStart. This operation is used for authorizing the charging processing Hubject platform. Implementation is mandatory by every CPO partner. In general, this message is used when user authenticates himself at the charging point by i.e. RFID card. Request comes from CPO to Hubject platform and then eventually it goes to EMP. Every request must contain operator ID and type of identification data - as a result you may expect the generated session ID for the charging process.

Authentication process is not so simple, we may have three different scenarios. At first, Hubject will try to authorize the request in offline mode. In other words, it will check its database for the customer token present in request and validate if it can start a charging session. If that's true, it will automatically return a positive response to CPO without any involvement of EMP. Authentication data needed for that can be uploaded by EMP beforehand using eRoaming authentication data service dedicated only for EMPs.

In case when offline authorization is not possible, Hubject will try to communicate with EMP directly. EVcolID present in identification data will be used for identifying involved EMP. If Hubject finds EMP, then it will forward the request to them. Of course, with some conditions given EMP must implement authorization service for online EMP, the response must contain provider ID and also may contain a list of identification data that can be used for stopping a charging session i.e. it can be QR code or RFID card.

If for some reason Hubject cannot identify EMP based on identification data, it will try to authorize the request in another way. At first, it will fetch all the EMPs that are under a contract with CPO. In other words, it will patch all the EMPs that subscribe to CPO authorization service. Then it will forward the request to all of those EMPs and wait for a result. This process is called ‘broadcasting’. After every EMP response to the request, Hubject will check if only one response was positive. If that's true, the charging process can be started and provider ID is known, if not, then this operation cannot be authorized.

Here we have an example of what an eRoamingAuthorizeStart request looks like. CPO partner session ID and EMP partner session ID are optional but can be used for custom session mechanics. EVSE ID is also optional because it can be derived based on identification data. Nonetheless, it's recommended to provide it as well for better debugging. Identification is used for specifying authentication data to authorize the user. Identification types can be RFID, QR code, plug-and-charge and remote. Operator ID is mandatory and it identifies the CPO. Pricing product ID is the name of pricing product for tariff identification. The last one; session ID identifies the process and it also can be optional.

eRoamingAuthorizationStart message is used as a response for eRoamingAuthorizeStart request. This message is very similar to acknowledgement, but has some additional fields. The first one is authorization status which specifies whether the user was authorized to charge or not. The next one is AuthorizeStop identifications which is a list of identification data that can be used for stopping the charging process. The last one; provider ID specified involved EMP.

The next operation to perform in authorized service is eRoamingAuthorizedStop. Basically, authorized stop is almost the same as authorized start but of course it's used for stopping the charging process. Session ID must be provided, because based on that Hubject and derived EMP data use for authorizing the charging process. Also, it will allow Hubject to try to stop the charging process in offline mode.

Request for eRoamingAuthorizeStop is very simple and looks similar to AuthorizeStart. Worth remembering is that EVSE ID is again optional, because it can be derived based on session ID. Nonetheless it's also recommended to provide that for better debugging.

eRoamingAuthorizationStop is a response for eRoamingAuthorizeStop request. This message is very similar to acknowledgement and also almost the same as eRoamingAuthorizationStart message, the only difference between those two is that eRoamingAuthorizationStop message does not include authorization stop identifications field.

eRoamingAuthorizeRemoteStart is another AuthorizeStart operation in authorization service, but this time the request comes from EMP to CPO. It allows EMP customers to directly start a charging process with i.e. mobile application. Implementation is mandatory by CPO, because it must be able to accept and process AuthorizeRemoteStart messages. Requests must contain provider ID and EVSE ID.

Logic for AuthorizeRemoteStart is a little bit different than for AuthorizeStart. At first, Hubject will check if there is a valid contract between CPO and EMP based on provided EVcolID, then it will check if EVSE ID is among the data uploaded by CPO. If that's not true, then the status code 603 on a known EVSE ID will be returned. Also, EVSE with a given ID should be Hubject compatible, otherwise status code 604 will be returned.

If EVSE ID is Hubject compatible or CPO has not uploaded any EVSE records yet, we cannot tell for sure that giving CPO is or isn't the owner of given EVSE. In that case, Hubject will generate a session ID and forward the request to CPO. CPO must return an acknowledgement with information whether he is the owner of EVSE and if the charging process can be started or not.

Based on this example, we can easily tell that the eRoamingAuthorizeRemoteStart request does not differ much from the eRoamingAuthorizeStart request. The only difference between those two is previously mentioned EVSE ID and provider ID.

eRoamingAcknowledgement message is a response for eRoamingAuthorizeRemoteStart request. It is also a response for most of the services we will cover later in this course. Structure is very simple; session ID related fields are the same as we have covered in eRoamingAuthorizeStart and eRoamingAuthorizeStop messages, the only difference is result field, which indicates whether operation was performed successfully or not.

Of course, there must be an eRoamingRemoteStop operation. It allows EMP customers to directly stop a charging session. Again, implementation is mandatory by the CPO partner, because it must be able to process this message in order to stop existing charging session.

As you can see in the example, the request is very simple. You need to provide EVSE ID, session ID and provider ID. As a response, you may expect an acknowledgement message.

After a charging session is completed, CPO must generate a ChargeDetailRecord associated with the session ID. CDR is a final summary of a charging session with details like meter values and consumed energy. CDR is immutable. You can think of it as a kind of invoice for a charging session. Because of that, Hubject created a separate operation in authorization service called eRoamingChargeDetailRecord. This operation is used for sending a CDR from CPO to the Hubject platform. Hubject will not only forward a CDR to online EMP but will also store the CDR in its database, in case EMP system cannot be addressed at the moment.

CDR data model is huge and has a lot of details regarding the charging session. We won't cover them all, but we'll point out the most interesting ones. Scientmeter values is a custom field needed in order to be compliant with german market regulations. Another field needed for that regulation is calibration law verification info. This field contains additional information regarding signed meter values. ChargingStart and ChargingEnd are pretty self-explanatory, but how are they different from SessionStart and SessionEnd? In general, session can be started before the charging process. For example, when a user authenticates himself at the charging point by RFID card. Also, session can end after a charging process is finished. Because of that, Hubject introduced separate fields for start date and end date of those two concepts. Consumed energy is a difference between MeterValueEnd and MeterValueStart, each of these fields is expressed in kilowatt hours.

MeterValueInBetween is a list of meter values present in a charging session. It is used for showing more detailed characteristics of charging.

Another service offered by Hubject is eRoamingReservation, this service is very simple. It contains only two operations; implementation is not mandatory by CPOpo but if a charging station offers reservation services then this functionality can be exposed to EMP by using operations defined in eRoamingReservation service.

First operation is eRoamingAuthorizeRemoteReservationStart, it allows EMP customers to reserve a charging point of a CPO. Information if a charging point offers reservation services is a part of an EVSE data. In value added services field Hubject will first check if there is a valid contract between EMP and CPO, then it will check if EVSE is known and if CPO is the owner of EVSE and after that it will forward the request to CPR. As a result session ID is generated and also we must remember that provider ID and EVSE id must be a part of a request.

Request or AuthorizeRemoteReservationStart is very similar to AuthorizeRemoteStart, we have an identification field which holds authentication data to authorize the user. Also, we have previously mentioned provider ID and EVSE ID fields which are mandatory. Then we have a duration field which is expressed in minutes. Finally, we have session ID related fields.

If we have a possibility to start a reservation, we also need to have a possibility to stop the reservation. eRoamingAuthorizeRemoteReservation tab is used for that. It's very simple; it allows EMP customers to end existing reservations. After that, CPO must generate a proper CDR for this operation.

Request for RemoteReservationStop is very simple - you must provide session ID, provider ID and of course EVSE ID.

Open InterCharge Protocole Training. Lesson 4

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

eRoamingAuthorization + eRoamingReservation

Open InterCharge Protocol Training - Lesson 5

From a CPO perspective this service is probably the most important one in the whole OICP protocol besides authorization service it allows CPO to push static data regarding his charging infrastructure to the Hubject platform in order to allow other EMPs to use it. This service contains only one operation: eRoaming push EVSE data. Of course implementation is mandatory by every CPO partner. Hubject will first check if there is a valid contract between him and CPO. This time Hubject platform is a subscriber to CPO not the specific EMP. Operations like ‘update’ or ‘delete’ are also handled by the same operation; it can be specified in the action type field in the request which we'll see just in a moment.

Hubject has a policy to keep history and version receive the data sets for most of the data that is pushed to their platform. Every push and every update creates a new version of data. Only the latest version of data will be used, but due to keeping history, it is possible to revert some changes on demand. History of all EVSE data records pushed by CPO is stored and versioned by Hubject. Because of that, Hubject can reconstruct static EVSE data for any point in the past. As I've told you before in eRoamingPushEVSEData request you can specify which kind of operation you would like to perform. Action type field defines whether you would like to perform a full load, insert ,update or delete operation. Also, in this request you must provide a list of EVSE data records assigned to a specific operator. EVSE data record is huge and complicated. Nonetheless, it's crucial to at least briefly know what is the structure, what are the fields and what do they represent.

Starting with accessibility, it specifies how the charging station can be accessed. Accessibility location tells us where it could be accessed. Additional info, as the name suggests, is an optional field that specifies additional information regarding charging station. Address is an object that represents a full charging station address - it contains information like country, city, postal code, street name, house number or even parking spot or floor. Authentication modes specify which kind of authentication methods are supported in a given charging station. Calibration law data availability tells us how a charging station provides metering law data. Charging facilities is a list of supported facilities it can specify whether it's AC/DC, what kind of voltage, amperage and power is supported. Charging pool ID and charging station ID are IDs related to the European charging infrastructure model. We will come back to this topic later.

Charging station names, charging station image and charging station location reference are other additional information regarding charging station. It's often presented to the end-user by EMPs. Dynamic info available specifies whether CPO is able to provide dynamic EVSE status. EVSE ID is quite obvious - it's an idea of EVSE. Energy source is a list of sources that are used to provide electric energy. Environmental impact specifies the impact that is being produced by those sources. Geocharge point entrants are geo coordinates of charge point facility entrance, it can be expressed in google, decimal degree or minute/seconds degree format. Hotline phone number and hub operator ID are self-explanatory. IsHubjectCompatible specifies whether eRoaming via intercharge network is possible. Max capacity field is in case EVSE has limited capacity, i.e. has built-in battery, values are expressed in kilowatt hours. Opening times field should be visible only when the charging station is not 24h available. Payment options, as the name suggests, is a list of payment options that are supported: it can be no payment in case of free charging, direct in case of paying by card or cash, or contract in case of for example subscription. Blocks is a list of supported plug types, i.e. type 2. Renewable energy tells us whether a charging station uses this kind of energy. Sub operator name is self-explanatory. Value added services is a list of additional services offered by a charging station: it can be for example reservation, dynamic pricing, parking sensor, maximum power charging, charging plans, roof provided and few others. DeltaType field is mostly valid for pull operations. It is strictly connected with the last call parameter, which can be provided in pull operations query. In general, it says what kind of operation was performed in the middle time compared to the last call. It can be ‘insert’, ‘update’ or ‘delete’. If you provide the last full parameter inquiry and no operation was performed in the middle time, then the given record should not be returned in response. Finally, we have the last update field which tells us when the last time record was updated.

Another EVSE related service important from CPO perspective is eRoaming EVSE status. In contrast to eRoaming EVSE data, it focuses only on dynamic EVSE data, especially status information. It's also very simple - it has only one operation. This operation is eRoaming push EVSE status. Of course, it allows us to push dynamic EVSE data to the Hubject platform. Implementation is mandatory by every CPO partner. When it comes to validation, it behaves the same as for eRoaming push EVSE data. Also, it's possible to specify the action type for a given operation. Similar as for EVSE data records, the history of all EVSE status records is stored and versioned by Hubject.

When it comes to the request of this operation, it's very simple. You need to provide a combination of EVSE ID with evs status in EVSE status records list.

Open InterCharge Protocole Training. Lesson 5

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

CPO eRoamingAuthorization + eRoamingReservation

CPO eRoamingEVSEdata + eRoamingEVSEstatus

Open InterCharge Protocol Training - Lesson 6

Tariffs and pricing issues are very complicated and hard to model. Tariffs may differ depending which aspect is concerned. Going from top to the bottom: we may have an end user which has an individual contract with EMP. EMP can offer him favorable rates under specific conditions, but of course it depends on the charging infrastructure and fees that EMP would like to charge. In order to offer charging infrastructure to end customers, EMP must have a contract with CPO, which can specify different rates than those offered to the end users. Of course, CPO may specify different rates per EVSE, their location, per day time and of course different rates per connector type. This is just a big picture overview and a small presentation of dependencies. In practice, each partner may have its own individual business model and settlement model

Comparing the Hubject model to the model that was presented before, Hubject aims to create a common tariff interface for CPO and EMP by having a specific pricing product within a service offer that EMP can subscribe to. OICP was not designed to cover end user tariffs. Their pricing product interface should be so flexible to cover different pricing depending on charging infrastructure i.e. different rates for type 2 connectors. This solution comes with a trade-offs. If you would like to integrate with the Hubject platform, it would be harder for you to create your own business model, especially as a CPO.

Besides standard pricing and product pricing which were briefly explained before, Hubject created the flexible pricing which allows CPO to offer differentiated pricings in many dimensions. It can depend on charging facility, location, daytime and combination of all above. All of those conditions are in the form of pricing product, which can be assigned to EVSE’s. Flexible pricing offers an API which is clear and understandable between both of the parties. On top of that, Hubject also created dynamic pricing, which enables for almost real-time updates between CPO and EMP. Unfortunately, because of its nature, dynamic pricing cannot be offered to everyone. It must be a bilateral offer. CPO and EMP must agree on business and legal specifics and their system must be prepared on such frequent tariff updates for just one party.

eRoamingPushPricingProductData is an API operation that allows CPO to upload pricing product information. In order to do that, CPO must create flexible or dynamic pricing in authorization service offer. It can be offered to all or per specific EMP. Of course, Hubject will check if there is a valid flexible or dynamic pricing before accepting the request. Hubject will also keep history of all change data records similar as in other services.

eRoamingPushPricingProductData request contains a lot of information about pricing. “PricingDefaultPrice” is quite obvious. It's the default price for a charging session. “AdditionalReferences” can be used for specifying additional pricing components, like start fee, parking fee, fixed fee or minimum/maximum fee. “IsValid24Hours” is self-explanatory, but you need to remember that it is assigned to pricing product not EVSE. “MaximumProductChargingPower” is expressed in kilowatt hours. “PricePerReferenceYouNeed” is a price per reference unit, in our example per hour in product price currency in our example in euros. “ProductAvailabilityTimes” specifies when exactly a given pricing product can be applied, for example it can tell specific begin and end hour of weekday.

Second operation to perform in eRoaming Dynamic Pricing Service is eRoamingPushEVSEPricing. It is used for assigning specific pricing products to EVSE IDs. Hubject will verify if service offer was created before and if pricing product can be assigned to EVSE. Hubject will also keep a history of all changed data records.

Request for eRoamingPushEVSEPricing is pretty straightforward, you need to provide a list of EVSE IDs and then provide a list of products that should be assigned to giving EVSE.

eRoamingChargingNotification is optional, but it's very important from an EMP perspective. It covers charging session functionality similar to a session module in OCPI protocol. In general, Hubject treats any kind of event that can happen during charging as a notification. Each notification may reflect various actions i.e. charging session started, update meter value, charging session ended and different kinds of errors that can happen during charging. Hubject will forward every notification received from CPO directly to the interested EMP. That allows EMP to present more details regarding the charging session to his customers, therefore it's very important for him to receive such kind of information.

Successful authorization and plugged cable does not necessarily mean that the charging process has started and energy is flowing. OCPP protocol which covers communication between chargepoint and chargepoint operator finds a lot of scenarios for charging session start, which must be handled by CPO. If everything goes right, CPO will receive a specific message that says a charging session has started. In this case CPOmay inform EMP about that by sending eRoaming charging notification start

When a charging session has started, EMP and its customer would like to receive more details about the ongoing charging session. They would like to know what is the energy consumption, duration, charging characteristic for some visualization and maybe even some predictions. The typical scenario is that CPO will receive meter values from chargepoint every 15 minutes via OCPP protocol. Therefore CPO may notify EMP about it and send some useful charging session details with eRoaming charging notification progress. Because those notifications are not crucial and not so frequent Hubject recommends at least a five minute frequency between two progress notifications.

CPO may also notify EMP, that the charging process has stopped. It can mean that energy is not flowing and the customer may be informed that his electric vehicle has been fully charged. a notification itself that does not mean that the charging session has been finished. In order to end the charging session and unlock connector you may use authorized stop request normal or remote or CPO may finish charging session on its own and push CDR right after it happens.

Of course, during the charging session there can be a lot of unexpected events i.e. stop triggered by charge points, charging fluctuations or even charge point damage. From an EMP perspective, it's very important to know what is going on and to inform its customer that his charging session cannot be finished successfully or that it was finished before his electric vehicle has been fully charged. In this case, CPO can send an eRoaming charging notification error with some details regarding the problem.

Data model of eRoaming charging notification may differ a little bit depending on the type of notification, but for most of the parts it looks almost the same. Charging duration and consumed energy progress is calculated for the time between charging start and event occurred. Charging duration is expressed in milliseconds, consumed energy progress is expressed in kilowatt hours. Meter value in between is an object representing a list of our meter values, which can be used for specifying charging characteristics. Of course, this data will not be present in eRoaming charging notification start. For error notifications we may also see error type and error additional info, which can be used for specifying more details about charging problem that has occurred.

When it comes to the rest of the fields, we have already seen them before in other data models. So there is no need for an explanation.

To sum up we have covered all OICP services from a CPO perspective and seen how the flow, business logic and data model looks like. Although some services are mandatory in order to integrate with the Hubject platform. Here you have a list of operations network marked as a mandatory in OICP documentation for CPO those operations are
eRoamingAuthorizedStart, eRoamingAuthorizedRemoteStart, eRoamingAuthorizedRemoteStop, eRoamingChargeDetailRecord, eRoamingPushEVSEData, eRoamingPushEVSEStatus. Unfortunately OICP documentation is not perfect and definitely is not clear in many places. In case you encounter some problem, my general advice is to contact the Hubject support team directly. In the past we had a situation where we thought some implementation of operation was mandatory, but it turned out that in our case maybe it's not needed at the moment. After contacting Hubject they said we can postpone it for now and we have definitely saved some time.

Open InterCharge Protocole Training. Lesson 6

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

CPO eRoamingDynamicPricing + eRoamingChargingNotifications 

Open InterCharge Protocol Training - Lesson 7

Now, we are going to look deeper into previously discussed services but from an EMP perspective. For most of the parts, it's the same as for CPO, but EMP also has some operations that are unique and specific only to them. Let's start.

Of course, the first operation in eRoaming Authorization Service is eRomingAuthorizedStart. Similar as for CPO, it is used for authorizing the charging process in the Hubject platform. Its implementation is mandatory for every online EMP partner. The data model and logic is the same as for CPO related operation, the only difference is that now EMP must be able to handle AuthorizedStart request and return eRoamingAuthorizationStart response.

The next operation is eRoamingAuthorizedStop - it is used for authorizing the stop of the charging process. Again, the data model and logic is the same as for CPO related operation. EMP must be able to process AuthorizedStop request and return eRoamingAuthorizationStop response.

eRoamingAuthorizedRemoteStart operation is very important for EMP. It allows EMP customers to directly start a charging session with, for example, a mobile application. Of course, implementation is mandatory by every EMP partner. Fortunately, the data model and logic is the same as for CPO operation. This time, EMP sends eRoaming authorized remote start request which must be processed by CPO and then CPO must return eRoaming Acknowledgement which is directly forwarded to EMP.

The opposite operation is eRoamingAuthorizedRemoteStop it allows EMP customers to directly stop a charging session with i.e. mobile application. Similar as for eRoamingAuthorizedRemoteStart, implementation is mandatory by every EMP partner. Also, data model and logic is the same as for CPO related service.

As we already know from the CPO authorization service, a CDR must be sent after the charging process has been finished. In order to be an online EMP, you must implement eRoamingChargeDetailRecord operation. EMP system must be able to handle charge detail record request and return eRoaming acknowledgement as a response.

But what happens when you would like to be an offline EMP? Or when Hubject tries to communicate with your EMP system but it fails and you cannot receive a CDR? In this case, eRoamingGetChargedDetailRecord operation might be useful. It allows EMP to pull CDRs data that was sent by CPO to the Hubject platform. EMP does not have to handle CDRs in real time, instead it can build some automated process on top of that operation. It's worth to mention, that EMP can pull CDRs in case real-time processing is not possible i.e. due to technical errors. eRoamingGetChargedDetailRecord request is simple. EMP must specify a date range, what can be done by providing from and to date values. EMP may also narrow down the result by specifying a list of session IDs. Also, it is possible to provide CDR forwarded which indicates whether the results should contain only those CDRs which were successfully forwarded to EMP or maybe not. response feRoamingGetChargedDetailRecord request is a list of eRoamingChargeDetailRecord. It's good to know that the data should be paginated.

If CPO offers eRoamingReservation service EMP may subscribe to it and offer its customers a possibility to reserve a charge point of given CPO. This can be done with eRoamingAuthorizedRemoteReservationStart operation. Information if chargepoint can be reserved is included in the value-added services field in EVSE data. Hubject must create a session for every reservation, because reservation may include some costs which are not strictly connected with the charging process itself. For example, it can be a fixed fee. The logic and data model are the same as for CPO-related service.

Second operation is already known: eRoamingAuthorizedRemoteReservationStop. It allows EMP customers to end existing reservation. After finishing a reservation, CPO must generate a CDR for a session that is connected to a given reservation. Again, data model and logic is the same as for CPO related service.

This service and eRoamingPushAuthenticationData operation is dedicated only for EMPs and its implementation is mandatory for every offline EMP partner. Hubject offers a possibility to push authentication data by EMPs to the daily platform, in order to optimize the full authentication process. For an offline EMP that's the only way for their customers to authenticate, therefore this operation is mandatory. For an online EMP you can use push authentication data to optimize the process, but you can have real-time authentication data processing available at the same time. Similar as in other services, update and delete is done with an action type field. Hubject will also keep history of all authentication data records in their platform.

In eRoamingPushAuthenticationData request, you must provide a provider ID together with a list of authentication data records. In each authentication data record you may specify multiple options for customer identification, for example it can be identification by RFID card or by QR code.

Open InterCharge Protocole Training. Lesson 7

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

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.

Open InterCharge Protocole Training. Lesson 8

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

EMP eRoamingEVSEdata + eRoamingDynamicPricing 

Open InterCharge Protocol Training - Lesson 9

In this module we will briefly compare the OICP protocol with another very common and popular protocol called Open Charge Point Interface. We will also present a charging terminology and topology model commonly used in Europe. We will see how OICP and OCPI protocol fit into it. Open Charge Point Interface protocol supports communication between eMobility Service Providers and Charge Point Operators. This protocol is free to use and is developed and maintained by EV Roaming Foundation. Details of OCPI protocol will not be covered in this course. We will only compare it with the OICP protocol and point out the most important features.

OCPI protocol works mostly in the peer-to-peer communication model and hub model is also offered in the latest 2.2 version. OICP, however, works only as a protocol between different partners and the hub. That influences how you implement and integrate with those two protocols. In case of OCPI, you can start implementation almost immediately and test it against any other company solution. With OICP however, you can start to build a model and write some implementation but in order to fully test integration, you need your own QA environment and access to the Hubject platform. The next difference is modules vs services approach. In OCPI, you have multiple modules. Each module covers a complete functionality over a specific aspect, like i.e. charging sessions. The division of previously mentioned aspects is more granular. Therefore it is more flexible. OICP, however, operates only on a few services which cover only the most important issues in the eMobility world. The list of required services is not so big, so in theory the implementation should be easier. In practice you will need more services than it is required in order to be effective.

The next technical difference is how the operations are modeled. In OCPI you will use multiple http methods in order to perform specific actions for EMP or CPO. In most of the modules you are not limited and you can push your data as well as pull it from others. In OICP you will use only post http method in order to model push and pull operations. What's more? Those operations are not bi-directional and valid only for the specific role. For example; EMP can push authentication data to the Hubject platform but CPO cannot pull it. OICP protocol is definitely well defined, standardized and more mature. It's clear that Hubject does not allow us to do everything, but every exposed operation is easy to understand, easy to implement and covers most of the needs. The only drawback is that introducing any kind of change to the protocol is hard and takes more time. OCPI on the other hand is more flexible, due to its structure and EV Roaming Foundation policy. They've built a community which can suggest what kind of changes are necessary and what kind of solutions may be good to introduce in the future.

One of the most important differences we have encountered is connected with previously mentioned authentication data. In OICP, CPO cannot pull EMP authentication data from the Hubject platform. While in OCPI, CPO can pull it directly from an EMP partner. But why is that so important? Let's imagine that you've built a complex CPO platform which integrates with multiple partners with OICP, OCPI and some other protocols. You may have a situation, where some end customer would like to start a charging session under a charging point with an RFID card. You as a CPO need to validate if a given user is able to do that. Therefore, you need to authorize the request in some EMP partner, but how would you know which partner is involved? If you have EMSP authentication data, you can build a simple eRoaming table and know exactly which partner is involved. Unfortunately, OICP does not allow to pull EMP authentication data. Therefore, you cannot fully build that roaming table. If you receive a request and you do not know which partner is involved, you need to treat Hubject and its authorized request as a fallback and if you have other protocols with similar behavior as in OICP, you need to perform a broadcast in order to authorize the request.

The next thing is that OCPI offers more details about ongoing charging sessions which is a crucial feature for other EMSP partners. Also, basic smart charging functionalities are offered in 2.2 OCPI version, while OICP does not cover this topic for now. The last thing is strictly business related, OCPI is more flexible, therefore it makes it easier for you to build your own business processes and business model on top of it. You can define your own rules and use functionalities offered to you in many combinations. On the other hand, OICP is designed to be compatible with processes defined by Hubject, so sometimes you need to be compliant with them in order to integrate and use full of its potential.

Now, I would like to present to you a charging topology model which is standard in Europe. At the highest level, we have a charging pool which is basically a location of a given charging spot. Each charging pool may have multiple charging stations. You can think of them as a physical stand next to the parking spot. Each charging station may have multiple charge points which represent supply equipment needed for charging, i.e. we may have two parking spots next to the one charging station with two charge points. It allows both of the electric vehicles to charge at the same time. At the lowest level we have connectors i.e. type 2. Each charging point may have multiple connectors but only one can be used at the moment.

As you can see OCPI and OICP are not fully compatible with European standard. OCPI at the highest level has a location which can be related to the charging pool. Charging station level is omitted, so the next level is EVSE. EVSE in general is the same concept as a charging point, but as far as I recall there are small differences. At the lowest level we have connectors which are almost the same as for European standard.

When it comes to OICP, Hubject introduced a similar vocabulary to the protocol by adding charging pool ID and charging station ID, but those are just IDs. Location is still a part of an EVSE and is not separated out. Also, OICP does not have a separate model for connectors. Those are present as the plugs in EVSE data model and are not separated as an entity according to the european standard. My general advice is to use vocabulary and domain model from the European standard, because there is a probability it will become a mandatory standard in the future. Of course, because of those differences it might be quite hard to bring together those three models, so everything depends on your case. If you are a CPO, then it might be good for you to have a four layered model, because you can define different logic on each layer. But if you are an EMSP it might be quite hard to present all the data in an attractive form to the end customer.

Finally, I would like to present to you some good-to-know things. First let's focus on no delete policy and using full load operation instead. The main reason for using full load operation is because Hubject is versioning every data set that was pushed to their platform. Because of that, you can see exactly how the data has changed over time and you have a possibility to roll back to some old version of the data set. The next reason is because delete operation is not the soft type. It will not create any kind of event and it's hard to keep everything consistent. It's better to use full load operation to always update the latest data set of i.e. EVSEs. Worth mentioning is that Hubject agrees on 24 hours eventual consistency. Therefore, it's possible to perform one full load operation in the night and not delete a single EVSe once it will happen.

As I’ve told you before, direct communication with Hubject may be very beneficial, but only you will understand their API better, but they can also help you in more complicated ways. For example; by providing a custom API. Let's take a look at the case with lack of authentication data for CPO. We have talked with Hubject about this problem and it turned out that this operation was exposed before, but due to some problems and misunderstandings it must have been removed from the API. Maybe they can cooperate and unlock this functionality only for your specific environment if that's what you really need.

The delta pool last call parameter cannot be combined with other filterings like i.e. search center. According to Hubject documentation, there are some corner cases where it can lead to some data inconsistency on the EMP site, but we do not know more details. Nonetheless it's definitely worth remembering.

When it comes to pagination it's good to know that the default number of records provided in paginated data response is 20 records. The maximum number of records that can be obtained in one single page is 2 000 records.

Open InterCharge Protocole Training. Lesson 9

The great breakdown of major eRoaming hubs, their functionalities and importance within the industry

eRoaming Hubs explained

Stakeholders Mapping designed for E-Mobility Service Providers

Stakeholders list for eMSP

A comprehensive publication with research data, latest achievements, and statistics on e-mobility development at the end of the turbulent year of 2020. From theoretical premises to out-of-the-box concepts, top-down support, and policies in selected European countries to record sales figures and future projections.

The growing concept of e-mobility as a service

Smart charging walkthrough including V2G technology and Dynamic Load Management

Smart charging

The pricing structures on many levels of charging services

eMobility tariffs. How is the pricing structured within the industry?

Informative PDF on the ISO 15118 standard and its functionalities and role in the eMobility environment.

ISO 15118 - what is it?

Comprehensive, knowledge-packed paper on demand response and its role within the global energy system.

Demand response

Helpful guidelines for Charge Point Operators when deciding whether to go custom or pick a ready-made solution. Core platform requirements that must be covered for undisturbed interoperability and some helpful guidelines for aspiring operators. 

Charge Point Operator core platform requirements

A complete checklist for OCPP migration - Open Charge Point Protocol - an application protocol for communication between charging stations and a central management system. We hope this list will help you make a decision on whether to upgrade. With a handy set of hints on if and how to successfully conduct migration, the whole process may be simpler.

How to set up a Charge Point Operator’s platform for migration from OCPP 1.6 to 2.0.1

Informative PDF about the smart grids, their characteristics and importance for the energy industry

Smart grids

A must-read for everyone looking to standardize and settle the knowledge about the eMobility industry from tech to business.

eMobility Fundamentals

Helpful guidelines for eMobility Service Providers. A complete list of essential functionalities, core outcomes, and requirements when designing an application and whole ecosystem for eMobility Service Providers.

Resources

Our featured issues to clarify and streamline the knowledge flow on the selected topics

Ebooks