Introduction
For the last months, I was working for our EV partner willing to integrate his CPO platform with Hubject. The partner’s charge point does not support RFID token, so the easiest way to start a charging session is to use remote authorization. Wanting to share my experience, I’d like to describe how to integrate with Hubject using remote authorization.
Let’s start with something not related to Hubject itself. What makes the easiest charge point operator API allowing to start a charging session with remote authorization? I would say three factors have to happen:
- expose information about our charge point to let end-user to find them
- expose the possibility to start and stop charging
- send the details of the charging session.
What I really like in Hubject’s API is that those high-level features are mapped one to one to their API operations. For this eMobility solution, five operations have to be implemented in order to introduce eRoaming through Hubject’s platform into our system. Unlike in the OCPI case, there is no complicated handshake. Nothing is related to security on the API level. It’s done by SSL Client Authentication, so there is no need to obtain tokens, etc. In fact, there are no “technical” endpoints that have to be implemented, only those related to the business processes. Let’s start by exposing our charge points to the end-users.
Sharing EVSE data
In order to let end-users find our charge points on Hubject’s map (or to find them on the maps of any EMP integrated with Hubject), we have to share both static and dynamic data of our charging network. Open Intercharge Protocol (OICP) has two operations supporting this process:
- eRoamingEvseData
- eRoamingEvseStatus
Those two operations should be invoked in two contexts: real-time and batch updates. Any time something is changing to the static or dynamic data of our charging network, it should be synchronized with Hubject’s B2B Service Platform (HBS platform) in real-time. Apart from that, CPO should send periodic updates (daily) of all existing charge points, including static and dynamic data.
Deleting EVSE data
Delete may be a problematic operation. It’s because in most cases, we don’t want to delete a charge point completely. We may need to store information about currently not used charge points for some reports, historical statistics, or investigations. That’s why we may not have an operation ‘delete’ explicitly modeled, it may be done by setting the charge point state to “out of order”, or setting something like ”valid to” date for the charge point. But each CPO has some logic based on which we can tell if the charge point should be visible on the maps or not. This is where the OICP batch update comes up. Instead of deleting the charge point that is out of order, we can run full load and the invisible charge point will be removed from Hubject’s system. We need to have in mind that we introduce some level of eventual consistency with such a solution. Of course, the straightforward delete operation is also supported, so if your system has the ‘delete’ operation modeled, it can be easily applied.
Starting and stopping charging session
Once we share our charge points with end-users, we should give them the possibility to start and stop charging sessions. There are two operations responsible for that in the OICP:
- eRoamingAuthorizeRemoteStart
- eRoamingAuthorizeRemoteStop
Let’s think of what kind of data would be good to receive when starting a charging session.
- information about the charge point user wants to use
- information about the EMP (it’s eRoaming and many EMP can use our platform, so it would be good to distinguish charging session from different EMP at least for some reporting)
- information identifying the end-user
- identifier of the charging session (in order to know which session has to be stopped when our backend receives eRoamingAuthorizeRemoteStop)
That’s exactly what is sent by HBS to the CPO backend when starting a charging session. It’s worth describing a bit deeper one parameter which is the end-user identification. For the remote start, it’s called EvcoId and it's the identifier of the contract between the EMP and the end-user charging the car. We have to store this value in our system because it has to be sent to HBS together with a completed charging data record. The same has to happen with the session id, but as a more common concept, there is a chance that our backend already has an idea of the session with some identifier and it’s also assigned to the charging data record. If not, then we have to enrich our CDR before sending them to HBS by two values:
- EvcoId
- SessionId
That leads us to the last API call we have to implement.
Sharing charge data records
This functionality is done by a single API call:
- eRoamingChargeDetailRecord
Most of the fields that have to be sent to Hubject are probably stored in a CPO platform. There are charging start and end, meter value start and end, and more. Apart from that, there are two parameters, already mentioned in the previous paragraph (SessionId and EvcoId) that our CDR has to be enriched with.
Open your CPO platform
According to Hubject’s website, they already have more than 700 partners integrated. This confirms that they know how to well prepare the integration process. Their documentation is relatively easy to follow, and monitoring tools make the whole compatibility procedure smooth. But if you need a helping hand to seamlessly open your CPO platform for eRoaming through Hubject, do not hesitate to reach me out via contact@solidstudio.io