The Open Intercharge Protocol is used to interact with Hubject which is currently the largest roaming network operating mostly in Europe. The protocol defines the communication between Hubject and both Charge Point Operators (CPOs) and eMobility Service Providers (eMSPs / EMPs).
It competes with the Open ChargePoint Interface (OCPI) as the main roaming protocol in use today. Despite the similar names, there are many differences between these protocols. This article will cover the key concepts to understand when learning about OICP and roaming in general.
OICP, like other roaming protocols, defines two key actors that interact with the protocol; CPOs (Charge Point Operators) and EMPs (eMobility Providers) also knows as MSPs.
Unlike other protocols however OICP only allows these actors to interact with Hubject, not with each other. Every API request either is from an actor to Hubject or from Hubject to an actor.
In these guides you will see the direction of request indicated from one actor to another (eg: CPO -> EMP). It’s important to note that this is actually going via Hubject so there are actually 2 requests happening; CPO -> Hubject and then Hubject -> EMP. The one exception to this rule is when dealing with an offline EMP.
An Offline EMP has no real time connection to the Hubject platform and any authorization request sent to them is automatically approved. The CDR is stored on the platform and the EMP then pulls that data and charges the customer in their own time.
An Online EMP has a real time connection and must implement the authorization service so that Hubject can forward the authorization request to them at the start of a charging session. It must also implement the CDR service so that they can accept and process CDRs
Hubject has a specific versioning system which means there is a broad OICP version but each service has their own version numbers within that. Each OICP release will include a set of service versions, some of them incremented from the previous release and some not.
These articles will indicate the service version number in the heading (eg. Authorization [2.1]). Always check the official documentation linked on the protocol home page for the latest version numbers.
EV charging topology is generally defined as a “three tier model” of Charging Stations, EVSEs, and Connectors. We can also add a “Charging Pool” or location of charging stations on top of this.
In OICP the primary focus is the EVSE, so that is the only real entity in Hubject and all data is communicated on the EVSE level. ChargingPoolID and ChargingStationID are used to group EVSEs into pools or stations respectively but do not exist as their own entity to be interacted with using the API as of version 2.3. Connectors are also described using plug types in the EVSE objects but also do not exist as their own entity to be interacted with.
MANDATORY for CPO & Online EMP
This is a special message which is used as a response payload for many of the requests throughout OICP. Is includes a Result field which indicates whether the requested operation was successfully performed.
As explained above most requests are sent to Hubject first and the eRoamingAcknowledgement is then used as a generic response to acknowledge the request was received and will be sent on to the other party.
Payload:
Hubject is well known as an eMobility roaming hub but it’s also the world leader as a certificate authority for Plug & Charge. Implementing Plug & Charge does not require OICP but they are highly compatible.
Implementing Plug & Charge with Hubject requires using OCPP to get authorization information from a charging station which itself is using ISO 15118. OICP can then be used in its normal capacity for relaying charger and authorization information to counter parties on Hubject. The Open Plug & Charge (OPCP) protocol can then be used for the nuts and bolts of certificate exchange and signing which is needed to enable Plug & Charge authorization.
In summary, Plug & Charge is its own thing and implementing OICP will not enable your network for Plug & Charge. However it’s a good step in the right direction and a robust OICP implementation will ease the process for implementing the remainder of the Plug & Charge requirements.