Below, we add the script for those who prefer to read through.
Introduction
Hello, I’m Paweł and I'm co-founder and CEO of Solidstudio. Today I'd like to cover the topic of the digital products in the eMobility ecosystem to build a basic understanding of what is doing what and what the responsibilities are.
I covered this slide many many times before for all our partners to basically be on the same page, regarding the vocabulary. Which products are what and what they are doing in this ecosystem? Today we don’t have a major presentation in front of me, instead I'm going to take you through this very basic slide. I hope that after this brief session you will have a little bit more understanding of how different actors are communicating with each other in this ecosystem. We won’t take on more advanced subjects (like eRoaming Hubs). We’ll go through the two basic digital products you can build on your own - be the software provider or buy off-the-shelf solutions either on the Saas license basis. We will cover roaming a little bit but more like peer-to-peer for the sake of linking those products together.
The roles within the ecosystem - eMobility Service Provider
Let’s start with the end-user perspective. What's actually happening is that the EV driver needs to have the possibility to search for the charging station. We have got our EV driver, who has the mobile application. Users are holding their phone with the eMSP application in place ( eMSP or eMP - it’s the eMobility service provider application). In this kind of applications usually you can: login, register, find charging stations, see the tariffs, navigate to them and basically start charging. That would be the first player - a company that acts as an eMSP. What we briefly covered are the functionalities that every eMSP should be able to offer. The eMSP is actually that party that takes care of the customers. It should: know how to set pricing and present it to the EV drivers, how to do the marketing, how to manage subscriptions and how to make their users reuse their app again. This is very basic differentiation, but I believe that in this case, the EMSP application is responsible for handling EV drivers and is mostly focused on the B2C market. Of course, I mentioned before that the EV driver should be able to search for the stations in the eMSP site, but since the eMSP doesn't really know them at this place yet, there is a need to present a second player.
The roles within the ecosystem - Charge Point Operator
So, the second player is the Charge Point Operator, who needs to use the software to manage their charging network. In essence, the Charge Point Operator is an organization or a company that is managing their stations. This is the main, fundamental differentiation between the EMSP and the CPO. We will cover how they communicate in a second part. We need to realize that EMSP is covering the user interactions and CPO is covering everything that goes with the charger. Here we get the link. So how does it happen that those two parties understand each other and know what to display? This is where the OCPI protocol comes in. But, let's take a pause here.
Connections between the CPOs and EMPs
You can meet many different instances that actually mix those two digital products into one - it is also possible. In Solidstudio, we believe that clear separation of duties and responsibilities is a very important factor, when it comes to building digital products. So in our solutions, you can find a very clear differentiation. This division allows you to actually buy or build one of those products, without necessity to have both. There’s of course a challenge how to make them talk to each other.
The custom API is always the option.This is not always the best one, because even though it can work in your internal ecosystem. We need to remember that there are multiple players in the market. If you've got the custom API (either on the eMSP side or on the CPO side) everybody who wants to connect to you, will be required to actually fulfill your contract. If there's going to be 10 different parties that like to connect to you, basically they need to do the same work 10 times. That's why the Open Standards has been invented and that's why we basically structure all our domain models on the OCPI.
Of course, if you've got two products: the CPO and the EMSP and they can be seen from a very high perspective as the one digital entity, under the hood those are two separated products that talk to each other through the OCPI. This is where the magic happens. Even though the CPO is in charge of managing the stations, it pushes all the locations with all the data to all different eMSP’s that are linked to it, because OCPI connection and the peer-to-peer connections are meant for many relationships. You can have one partner, you can have multiple partners and their partners can have other CPO’s connected to them.
CPOs know which charging stations they are operating and they’re pushing their locations to the eMSP application. eMSP got the back-end, so on the server side everything is computed and this pushes - in our case - through the rest API to the EV driver. EV drivers are able to start charging by pressing the button. There are two basic ways to start charging. First one is the remote start/stop, which is ultimately pressing the button on the mobile application. The second one is the RFID.
Let's focus on the remote start-stop first. When the EV driver presses the remote start-stop, under the hood the mobile application ( it can be the iOS or the Android app) calls over the rest API the eMSP server side. This server knows which CPO pushes the data with a given charging station and over the OCPI and OCPI connectivity, it calls the charging platform to start the charging.
Here we are getting into another open standard that we need to talk about. It's OCPP.
Open Charge Point Protocol in the eMobility ecosystem
OCPP is the open standard that allows CPO’s to talk to different stations. We can imagine the situation that each of the manufacturers has their own proprietary protocol. In this case, the development of the CPO platform would be enormous, because we've got hundreds of different device providers and those would be a hundred different standards. Plus, they would have to invent it from their hardware perspective. So OCPP actually allows different charging stations manufacturers to implement it on the hardware side. And CPO platforms can implement it on the software side. Thanks to that, we, as the CPOs, are allowed to actually use multiple manufacturers of the charging stations. As mentioned before, we've got the OCPP connection between the CPO and the station, in our case we are using web sockets to actually keep this connection open. CPO Platform is able to tell the charger to start the charge.
The circle is closed. The EV driver successfully started charging. And from now on, the charging station will report to the CPO Platform about the current charging session e.g. the current power or how much energy has been consumed. The CPO will push this information to the eMSP and eMSP will display that information to our EV driver. This is how it looks from the EV driver perspective.
Of course, we've got more business or admin side of things. Both eMSP and CPO should expose the admin portal. As I’ve mentioned before, the main duty of the eMSP is actually serving the EV driver. In order to that, in the EMSP admin portal you have to have possibilities such as: setting up the tarfiifs for the EV drivers or managing the RFID’s, because RFID’s needs to be linked with the driver, so we need to know which account to charge.
On the other hand, in the CPO admin portal, you need to have the ability to manage your charging stations. You need features like: add a new charity station, remove or make it unavailable, change the tariffs for B2B purposes, manage other admins, manage OCPI connections and many more.
Tariffs within the EV charging industry
Everything that we know so far is crucial to understand how the tariffs should work in the eMobility ecosystem, because both: the EMSP admin portal and CPO admin portal user are setting up their tariffs. What is important, the CPO’s tariffs are B2B tariffs so for all CDRs, the charging events that have been completed on their stations under their management, that tariff will apply to them, but only for the eMSPs connected.
So those are going to be B2B money transfers. And those do not necessarily have to be the same tariffs that the end user EV driver is paying. eMSP admin can set up the tariff for instance on the basis of adding the margin. In the simple case, if 1kWh costs 1€ on the B2B level then the other in the portal can add 0,5€ margin, so the end user will pay 1,5€ per each kWh consumed. All the money goes to the eMSP, but then depending on the settlement between those two parties, the 1€ will go back to the CPO. This is how it works.
Of course adding the margin is just one possibility. We can imagine that the eMSP admins got some kind of loyalty scheme for the users e.g. every 10th charging is for free. Nevertheless this EMSP will have to settle the bill with the CPO. You can also ask the question: „what if you want to be both?”. We can see all different players on the market and some of them are both CPOs and EMSPs. In this case, let's say using this ecosystem, the tariffs can be set on the CPO side. For instance eMSP can add zero margin just to keep it transparent, so all the profits are in the CPO or vice versa - so the CPO admin can set up the tariffs for zero and all the billing is done by the EMSP.
This is covering the digital ecosystem from a very high level. We need to remember that we brought up the closed ecosystem. There is a possibility to lean different EMSP’s to different CPO’s over peer-to-peer OCPI connectivity, but we need to remember that there are other ways e.g. a hub integration.
That's it. If you've got any questions, please do not hesitate to contact us.