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 4
OICP Training Transcript
CPO service details
Now, let's focus more on a detailed view of services used in OICP. In this part of the training session, we will cover:
- eRoaming Authorization
- eRoaming Reservation
- eRoaming EVSE Data
- eRoaming EVSE Status
- eRoaming Dynamic Pricing
- eRoaming Charging Notification Services
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.
eRoamingAuthorizeStart
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
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.
eRoamingAuthorizeStop
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
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
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.
eRoamingAckonwledgement
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.
eRoamingAuthorizeRemoteStop
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.
eRoamingChargeDetailRecord
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.
eRoamingReservation
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.
eRoamingAuthorizeRemoteReservationStart
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.
eRoamingAuthorizeRemoteReservationStop
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.