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:
- Overview
- Business introduction
- Technical details
- CPO eRoamingAuthorization + eRoamingReservation
- CPO eRoamingEVSEdata + eRoamingEVSEstatus
- CPO eRoamingDynamicPricing + eRoamingChargingNotifications
- EMP eRoamingAuthorization + eRoamingReservation
- EMP eRoamingEVSEdata + eRoamingDynamicPricing
Open InterCharge Protocol Training - Lesson 9
OICP Training Transcript
OCPI vs OICP
In this module we will briefly compare the OICP protocol with another very common and popular protocol called Open Charge Point Interface. We will also present a charging terminology and topology model commonly used in Europe. We will see how OICP and OCPI protocol fit into it. Open Charge Point Interface protocol supports communication between eMobility Service Providers and Charge Point Operators. This protocol is free to use and is developed and maintained by EV Roaming Foundation. Details of OCPI protocol will not be covered in this course. We will only compare it with the OICP protocol and point out the most important features.
OCPI protocol works mostly in the peer-to-peer communication model and hub model is also offered in the latest 2.2 version. OICP, however, works only as a protocol between different partners and the hub. That influences how you implement and integrate with those two protocols. In case of OCPI, you can start implementation almost immediately and test it against any other company solution. With OICP however, you can start to build a model and write some implementation but in order to fully test integration, you need your own QA environment and access to the Hubject platform. The next difference is modules vs services approach. In OCPI, you have multiple modules. Each module covers a complete functionality over a specific aspect, like i.e. charging sessions. The division of previously mentioned aspects is more granular. Therefore it is more flexible. OICP, however, operates only on a few services which cover only the most important issues in the eMobility world. The list of required services is not so big, so in theory the implementation should be easier. In practice you will need more services than it is required in order to be effective.
The next technical difference is how the operations are modeled. In OCPI you will use multiple http methods in order to perform specific actions for EMP or CPO. In most of the modules you are not limited and you can push your data as well as pull it from others. In OICP you will use only post http method in order to model push and pull operations. What's more? Those operations are not bi-directional and valid only for the specific role. For example; EMP can push authentication data to the Hubject platform but CPO cannot pull it. OICP protocol is definitely well defined, standardized and more mature. It's clear that Hubject does not allow us to do everything, but every exposed operation is easy to understand, easy to implement and covers most of the needs. The only drawback is that introducing any kind of change to the protocol is hard and takes more time. OCPI on the other hand is more flexible, due to its structure and EV Roaming Foundation policy. They've built a community which can suggest what kind of changes are necessary and what kind of solutions may be good to introduce in the future.
One of the most important differences we have encountered is connected with previously mentioned authentication data. In OICP, CPO cannot pull EMP authentication data from the Hubject platform. While in OCPI, CPO can pull it directly from an EMP partner. But why is that so important? Let's imagine that you've built a complex CPO platform which integrates with multiple partners with OICP, OCPI and some other protocols. You may have a situation, where some end customer would like to start a charging session under a charging point with an RFID card. You as a CPO need to validate if a given user is able to do that. Therefore, you need to authorize the request in some EMP partner, but how would you know which partner is involved? If you have EMSP authentication data, you can build a simple eRoaming table and know exactly which partner is involved. Unfortunately, OICP does not allow to pull EMP authentication data. Therefore, you cannot fully build that roaming table. If you receive a request and you do not know which partner is involved, you need to treat Hubject and its authorized request as a fallback and if you have other protocols with similar behavior as in OICP, you need to perform a broadcast in order to authorize the request.
The next thing is that OCPI offers more details about ongoing charging sessions which is a crucial feature for other EMSP partners. Also, basic smart charging functionalities are offered in 2.2 OCPI version, while OICP does not cover this topic for now. The last thing is strictly business related, OCPI is more flexible, therefore it makes it easier for you to build your own business processes and business model on top of it. You can define your own rules and use functionalities offered to you in many combinations. On the other hand, OICP is designed to be compatible with processes defined by Hubject, so sometimes you need to be compliant with them in order to integrate and use full of its potential.
Charging topology
Now, I would like to present to you a charging topology model which is standard in Europe. At the highest level, we have a charging pool which is basically a location of a given charging spot. Each charging pool may have multiple charging stations. You can think of them as a physical stand next to the parking spot. Each charging station may have multiple charge points which represent supply equipment needed for charging, i.e. we may have two parking spots next to the one charging station with two charge points. It allows both of the electric vehicles to charge at the same time. At the lowest level we have connectors i.e. type 2. Each charging point may have multiple connectors but only one can be used at the moment.
As you can see OCPI and OICP are not fully compatible with European standard. OCPI at the highest level has a location which can be related to the charging pool. Charging station level is omitted, so the next level is EVSE. EVSE in general is the same concept as a charging point, but as far as I recall there are small differences. At the lowest level we have connectors which are almost the same as for European standard.
When it comes to OICP, Hubject introduced a similar vocabulary to the protocol by adding charging pool ID and charging station ID, but those are just IDs. Location is still a part of an EVSE and is not separated out. Also, OICP does not have a separate model for connectors. Those are present as the plugs in EVSE data model and are not separated as an entity according to the european standard. My general advice is to use vocabulary and domain model from the European standard, because there is a probability it will become a mandatory standard in the future. Of course, because of those differences it might be quite hard to bring together those three models, so everything depends on your case. If you are a CPO, then it might be good for you to have a four layered model, because you can define different logic on each layer. But if you are an EMSP it might be quite hard to present all the data in an attractive form to the end customer.
Good to know
Finally, I would like to present to you some good-to-know things. First let's focus on no delete policy and using full load operation instead. The main reason for using full load operation is because Hubject is versioning every data set that was pushed to their platform. Because of that, you can see exactly how the data has changed over time and you have a possibility to roll back to some old version of the data set. The next reason is because delete operation is not the soft type. It will not create any kind of event and it's hard to keep everything consistent. It's better to use full load operation to always update the latest data set of i.e. EVSEs. Worth mentioning is that Hubject agrees on 24 hours eventual consistency. Therefore, it's possible to perform one full load operation in the night and not delete a single EVSe once it will happen.
As I’ve told you before, direct communication with Hubject may be very beneficial, but only you will understand their API better, but they can also help you in more complicated ways. For example; by providing a custom API. Let's take a look at the case with lack of authentication data for CPO. We have talked with Hubject about this problem and it turned out that this operation was exposed before, but due to some problems and misunderstandings it must have been removed from the API. Maybe they can cooperate and unlock this functionality only for your specific environment if that's what you really need.
The delta pool last call parameter cannot be combined with other filterings like i.e. search center. According to Hubject documentation, there are some corner cases where it can lead to some data inconsistency on the EMP site, but we do not know more details. Nonetheless it's definitely worth remembering.
When it comes to pagination it's good to know that the default number of records provided in paginated data response is 20 records. The maximum number of records that can be obtained in one single page is 2 000 records.