Decentralizing the charging business for the eMobility Industry (part I)
In the next upcoming years there’s going to be a collision of trains that will change the habits of commuters, logistics of delivery companies, energy distribution from utilities, payments in public transportation, and many other entities and people everywhere:
Electric vehicles (EV) and decentralization with Distributed Ledger Technologies (DLT).
The impact that this change of paradigm will bring may not be obvious nowadays, but I think it is going to be disruptive in many aspects. And not only for just environmental reasons (removing carbon emissions or noise pollution in our cities) but also on how it will incorporate futuristic technology to our vehicles that will reshape our everyday lives, just as smartphones did a decade ago.
And, just like your smartphone, your EV (not only cars, but also any kind of vehicle such as trucks, buses, bikes, etc) also needs to be charged. In this series of three articles I will try to describe the current landscape — including some efforts that the industry are doing, in the tech field, to overcome the obstacles for adoption — and then offer the steps to gradually introduce new software components to implement architectural decentralization (and, in particular for our case, Ethereum Blockchain based technologies) for all the stakeholders that participate in the journey of charging.
Benefits for the IT
The benefits that Blockchain technologies bring to the business are broad, from the revolutionary concept of Internet of Value to a whole assorted offer of upsides and downsides. A lot of business cases are being discussed, regarding to things such as faster real time payment cycles, renewable-energy certificates, p2p power generation and distribution with micro-grids, real-time transactions to balance supply and demand, smart grid/charging business intelligence, etc. Addressing all of them from every available point of view, strategy or approach is out of the scope of these articles, and there are already good resources out there.
However, I will mention some benefits that can affect directly the IT of eMobility companies.
Perhaps one of the most obvious and easy to spot is the fact that in distributed architectures you can achieve a high degree of fault tolerance. Whilst centralized systems favor single point of failures (e.g. client-server topologies), in a distributed network the resilience of the whole system is not compromised if some nodes or entities fail, because the rest can continue working. So if, for instance, a fatal error occurs on a server controlling thousands of charging points in a client-server situation, all points/stations stop working. But on a distributed situation, a station down doesn’t disrupt the service completely for all locations, as the rest of devices still work.
Another benefit of having our data and value spread on autonomous participants in a DLT is the so-called attack resistance. In an scenario where a malicious agent attacks a central server (cheap to execute), information can be compromised or money can be stolen from thousands of customers. An attacker trying to gain access to the same information or money on a distributed network of nodes (i.e. charging stations) would have to crack down station by station (expensive to execute), and could only get data or value from the ones successfully “hacked”.
From the perspective of accessibility, scalability or maintenance, and especially dealing with proprietary technologies, limited resources or infrastructures, I would finally mention the concept of collusion resistance, where participants in a centralized system can agree to exclude the rest from accessing certain systems, dictate what technologies to use, restrict such technologies, or in general take decisions in a cartel or monopoly style. While this kind of behaviour or activity is generally found in areas outside the realm of technology, at least from a technology perspective if we agree on the mathematical and economic rules of consensus mechanisms found in Blockchains, along with protocols and standards to secure and promote an uncoordinated choice model, then we will build up some resistance to undesired collusion.
Industry standards
When I gave a title to this article, perhaps I should have also included the word “standardising” next to “decentralizing”. When we talk about distributed systems, there has to be at least one protocol that defines the common language that the participants have to follow, in order to communicate and exchange data and value. It turns out that the industry is already hands-on on this matter with several initiatives or standards. For now, I will mention three:
- OCPP (Open Charge Point Protocol): protocol that defines how to provision and manage charging infrastructures.
- OCPI (Open Charge Point Interface): exchange protocol between stakeholders in the charging ecosystem.
- Plug&Charge (part of the ISO 15118): this standard allows us to exchange information between the station and the EV, so that the charging session can be started automatically once the cable is plugged, without any other human interaction.
The amount of adoption or deployment that these technologies have in the mobility ecosystem today is fairly high, at least in Western Europe. By combining them together with our solution, which we will reveal in the next articles, we can leverage the existing infrastructure into a new level of openness, interoperability, scalability, cost effectiveness, innovation, trust, and many other possibilities.
Stakeholders and other players
Beyond the obvious two actors that stand in the origin and the end of this story (that is, the electric utility that generates and distributes the energy and the EV driver that purchases and consumes this energy) there are two main stakeholders that play main roles in the act.
On the one hand, there is the CPO (Charge Point Operator) that provisions and manages the infrastructure of charging stations, usually in public spaces. CPOs need to manage thousands of charging stations with what we call the CSMS (Charging Station Management System), a centralized service running on-premises controlling all the operational functionality. This is the system you need to trust to when it comes to management of devices and settlement of payments. It is, therefore, the authoritative part of the charging processes. Anything went wrong? Ask the CSMS.
On the other hand we have the MSP (Mobility Service Provider) which operates as the interface between the driver and the grid, mainly to solve the roaming problem when acquiring electricity from different utilities. MSPs hold contracts with their customers (the drivers), and are in charge of paying CPOs for the energy charged from their stations. So, instead of drivers having to get contracts with every CPO, MSPs offers them some sort of “universal virtual CPO” mode. One good example in Germany is Hubject.
Another important thing to mention is that MSPs have to provide their users a mechanism to authenticate themselves when charging EVs. For that, the initial and simplest method was to distribute RFID cards to be used directly in the charging station. Nowadays there are mobile apps where drivers can navigate through a map, discover the nearby station and request charging sessions by reading a QR code from the charging station, or selecting the station from the app.
Current architecture
If you read the diagram labelled Figure 1 from bottom to top, you can follow the journey of a charging session:
- A QR code from the station is scanned by the driver using the MSP UI (User Interface), which requests a new charging session to the CPO CSMS via OCPI. The transaction (TX) is stored by the MSP.
- The CSMS manages the charging infrastructure via OCPP. When the charging session has ended, the transaction is also stored by the CPO.
- In the end of the month, both parties (CPO and MSP) interact in the settlement process, until they clear the final numbers, which are sent to the billing departments.
- The CPO sends the invoice for the user to the MSP, which adds their fees to the total balance. This invoice is then sent to the user (driver).
- The user makes a payment to the MSP; after the fees are extracted, the MSP sends the rest to the CPO.
Post-payment settlement
The scenario today is a post-payment scenario where the charging session transactions are recorded and, at the end of the month, the two main actors have to start exchanging their own version of the transaction ledger (settlement), until clearing is done and everybody ends up with the new balance on their accounts or wallets. This is a complex process, prone to errors, disputes, or even fraud (if, for instance, the driver does not pay the MSP, which in turn cannot pay the CPO).
So now we have identified the MSP as another centralized role, together with the CPO. What if the MSP systems fail, disagrees on some operations, or decides not to pay the CPO until they receive the money from its customers? This especially worries CPOs, as it creates a vendor lock-in situation where they can suffer from undesired situations, not to mention the fact of being billed for a lot of money by using a settlement platform.
Next steps
Once we have a clear map of the different participants and how do they interact between each other in all the stages of a charging session, we need to figure out how to gradually transform the “game board” without breaking it in order to decentralize it. Please go to the next article from this series to see how!
