Decentralizing the charging business for the eMobility Industry (part II)

This is the second part of a series of three posts. In case you haven’t done it, please read the previous (first) article, where I set the current landscape of interactions and operations for EV (Electric Vehicle) charging between the driver, the MSP (Mobility Service Provider), the CPO (Charge Point Operator) and a monthly billing settlement process as a necessary solution to a post-payment scenario.

In this second post I will try to deconstruct and reorganize the architecture, from a current centralized topology with some single points of failure and inefficiencies, into a distributed frameworkof autonomous agents orchestrated by the trusted authority of a smart contract ready (e.g. Ethereum) Blockchain that leverages a decentralized system, in a pre-payment scenario.

Main bottlenecks

As we walk towards decentralization, there are two main activities that need to be handled in a different way:

• Management of the charging infrastructure: this is the role of the CPO CSMS (Charging Station Management System), operating the charge stations.
• Management of the payments: currently constrained by the fact that MSPs hold contracts between the drivers and the CPOs, where the driver receives a monthly bill that had to be previously reconciled between MSPs and CPOs with transaction details manually sent back and forth until they reach “consensus”.

Starting from the payments topic, we quickly realize that we need to get rid of this complicated settlement that is currently the authoritative source for managing the payments. By doing so we will remove an intermediary that is adding unnecessary costs and operation complexities. Besides, if we can strive for a pre-payment (see “real time” or “pay as you go”) model, then both parties can streamline the charging experience from a user’s perspective, while also gaining an enhanced flow of liquidity.

The other central point or “bottleneck” — the charging infrastructure management — is considered so because today, with every CPO being authoritative of all transactions happening in their respective network, MSPs cannot simply drop their part of billing their customers for the charge process without having to trust a “neutral” source for the correctness of the transactions. Therefore, we need to find a solution so that, while transitioning our architecture to a pre-payment system, we can successfully trust that our records are not tampered by any of the parties involved.

New components

What I propose basically is to introduce some new components to the system that can help us rewire the existing platform into a new blockchain network that will allow us achieve our goals:

• EV Wallet: this component will integrate tightly with the MSP UI (User Interface), managing the funds (i.e. tokens, see below) of the driver and the operational logic needed to request charging sessions.
• EV Network: basically a blockchain with token transactions and smart contracts running on the EVM (Ethereum Virtual Machine), processing the business logic that controls the functionality for enabling the management of charging infrastructure and coordinating the payments for its use.
• Core Client: aimed to be run in the CPO “realm”, this piece of software interprets the instructions between the CSMS and its charging infrastructure and the EV Wallet so that they can both communicate via the EV Network. It is a core role in the system.
• Tokens: in order to coordinate the transfer of value between the components when we charge our electric vehicles, we need tokens as a means of payment. Tokenomics are difficult to achieve, but for this article it will be enough to imagine that tokens flow through our system from wallet to wallet, without entering into more details.

Architecture proposal

Figure 2

By following the diagram from Figure 2 (see figure 1 in the previous article to compare) from bottom to top, let’s see how does the charging session journey looks now that we introduced our changes:

• Using the MSP UI, with its account wallet already topped up with user tokens, the user gets the station ID for the station being used by selecting it from a list or map displayed in the app itself. This information comes the smart contracts in the EV Network.
• The EV Wallet requests a new charging session to the Core Client, via the CSMS business logic in the EV Network smart contracts. The OCPI (Open Charge Point Interface) and OCPP (Open Charge Point Protocol) communications are transformed back and forth into JSON-RPC (the exchange protocol used by Ethereum). The user tokens are stored in an escrow account, until the transaction (TX) is completed.
• The Core Client relays the request to the CPO CSMS, and the transaction is executed and stored to the EV Network, again via the Core Client. The total amount of tokens spent are calculated and sent to the CPO account.
• The CPO can create its official invoice, which the driver receives as a support document for the transaction.

Pre-payment token settlement

For the sake of simplicity I did not depict in detail on the diagram how tokens flow from the driver to the CPO wallet. What happened exactly?

Tokens on our network are initially held by the drivers before they are used as means of payment to purchase energy. When the user requests a charge session for a certain amount of kWh or period of time, the tokens are moved from the EV Wallet temporarily to an escrow account controlled by the smart contracts in the network. This method replaces the contracts between MSPs and customers (remember, the post-payment settlement process), and now the only contract needed is to purchase tokens (pre-pay) for charging. The settlement is done individually and in real-time for each transaction, instead of bundling them monthly in cumbersome clearing procedures. The consensus is reached in an atomic way for each operation.

Becoming authoritative

As you remember, we previously mentioned the concept of authoritative roles for the infrastructure management and a pre-payment system as a key action into decentralization. In this scenario, what we want to initially achieve with our new components is to embed our blockchain solution right in the middle of the existing architecture. On the CPO side, we still have to rely on the CPO CSMS as authoritative (represented with the green color, the box in the left “CPO” column) of what’s going on with the charging sessions, although we introduced a second CSMS in the EV Network (yellow color box in the middle “EV Network” column), so that we can store the authoritative transactions (TX) (also green, in the same “EV Network” column).

Next steps

We did a lot of progress into evolving our platform to a state where some unnecessary third parties and elements are removed, the properties of a distributed system are increased, and the overall process has been transformed into a more efficient, streamlined system. But wait! There is much more that we can achieve, Please read the third and last post from this series to see how we can achieve true decentralization.