ERoaming Remote Authorization with Hubject
eRoaming remote authorization with Hubject
IntroductionFor 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 themexpose the possibility to start and stop chargingsend 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 dataIn 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:eRoamingEvseDataeRoamingEvseStatusThose 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 dataDelete 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 sessionOnce 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:eRoamingAuthorizeRemoteStarteRoamingAuthorizeRemoteStopLet’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 useinformation 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-useridentifier 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:EvcoIdSessionIdThat leads us to the last API call we have to implement.Sharing charge data recordsThis functionality is done by a single API call:eRoamingChargeDetailRecordMost 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 platformAccording 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