Open InterCharge Protocole Training. Lesson 7

Solidstudio is happy to introduce you to the Open Standards course led by our e-mobility expert - Bartlomiej. Throughout the following lessons, we will uncover the technicalities and functionalities of the OICP - a protocol developed by Hubject - as well as business aspects for e-Mobility Service Providers and Charge Point Operators.

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

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

See the previous lessons:

Open InterCharge Protocol Training - Lesson 7

OICP Training Transcript

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.

eRoamingAuthorizeStart

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.

eRoamingAuthorizeStop

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.

eRoamingAuthorizeRemoteStart

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.

eRoamingAuthorizeRemoteStop

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.

eRoamingChargeDetailRecord

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.

eRoamingGetChargeDetailRecord

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.

eRoamingAuthorizeRemoteReservationStart

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.

eRoamingAuthorizeRemoteReservationStop

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.

eRoamingPushAuthenticationData

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.