Thoughts on an interoperable EV charging network

A gas station stall is held for few minutes. A fast charger, on the other hand, is held for twenty to fifty minutes, and it is hard to know when the charging will finish. Duration depends on battery chemistry, connector type, starting and target state of charge, whether the pack was pre-warmed, whether the site has hit its sanctioned peak demand, and whether a demand response event is running.

A good deal of what makes EV charging awkward seems to follow from this one asymmetry. Long dwell times mean queues form, and high variance means those queues are hard to quote reliably. Taken together, the two mechanisms a petrol station leans on — physical first-come-first-served, and the assumption that everyone clears quickly — no longer work. Ensuring a good customer experience, despite these issues requires a tight coordination between forecasting, queue management, navigation, which is harder to achieve in an interoperable network, where charge point, charging app and vehicle OEM could be from completely different companies.

Interoperability, in general, is a honking good idea (channeling the zen of python): it cuts coordination costs, widens market access, and dissolves artificial monopolies. It also makes the coordination problem of delivering value under uncertainty strictly harder, because now the queue is shared across operators who don't trust each other and aggregators who compete for the same customers.

This technical note builds on the customer experience as a primitive and proposes a general conceptual framework to attack above problem using architectural simplification (which merges reservation & walk-in queues) and a machine readable incentive & rules framework that enable dispute-free auto-settlement and reward optimization by agentic DERs.

Disclaimer: these are my personal opinions/thoughts, and may not be shared by organizations I have worked with, including NFH or NPCI.

Raising a network is hard

Unified Bharat e-Charge (UBC) is a revolutionary interoperable network built for EV charging. Launched on India's independence day in 2026, it eliminates complex bilateral integration between aggregators & charge point owners, and helps customers discover more chargers at a cheaper cost from any app of their choice (BHIM now and more to come), reducing range anxiety. Just integrate with the open API once and new CPOs become discoverable and the new aggregators start seeing the whole network from day one. Just like public roads, public internet, public electric grid, these interoperable rails allow more value added apps to be built on top.

The UBC network is built on the specs here and uses Beckn protocol under the hood, for charger discovery and contracting. It offers both walk-in and reservation based booking, which is rare to find in an EV network.

A few corner cases that could lead to poor customer experience in such a network are below:

1. If the charger does not support a pre-reservation lock-out, and if the earlier customer does not stop charging and eats into next reservation time? Such delay accumulates, risking all future reservations.
2. The charger times do vary a lot and are difficult to forecast. They depend on battery type, charging connector type, whether we know the starting and target state of charge, whether the battery is pre-warmed, whether CPO's sanctioned peak demand is reached or if some demand response event is going on. With so much uncertainty, taking on a reservation seems like an invitation for a traffic jam.
3. Given large charge times for an EV, compared to an ICE vehicle, queue management, notification, availability of a waiting area becomes more critical to avoid customer surprises and poor experiences. As with most networks, good testimonials travel much slower than bad ones, risking the reputation of the whole network.
4. If a site does not have a large waiting area, physical queuing of vehicles can cause a problem, if there is no alternate virtual queuing system.

This note proposes how few upgrades to underlying rails could allow the network operator to better manage such corner cases. It also shows how charge point operators could value stack between different interoperable networks in a seamless manner. e.g. responding to the call for flexibility from the grid (discovered on demand-flex network) while the charging is ongoing, or reducing cost of energy procurement by peer-to-peer trading (another network).

Machine readable rewards/rules can help

A settlement contract defines the link from action to a reward/penalties. A machine readable contract can be used as a what-if counterfactual engine and run on loop to co-optimize the value stack from a charger, namely the walk-in flow, reservation flow, p2p-trading and demand response use cases. 

If such contracts can be defined, it will allow an army of optimizers to come up, value stack and improve the customer satisfaction, charger profitability and grid reliability, all at once.

Open Policy Agent/rego and other policy-as-code frameworks can allow the network and sellers to create such policies, and automatically compute settlements once the charging session finishes. A thoughtful construction of such policies can allow interoperable charging networks to offer best in class services that rival siloed vertically integrated networks.

Two policy primitives defined in digital energy grid project are:

1. Network policy: these are *.rego files with all common rules that a network operator defines. Each of these rules are executed on incoming and outgoing json payloads by a watchdog layer such as beckn-onix, and flags any violation of network rules. e.g. If network operator says that a charging reservation can not be made say within 1 hour of charging, automatically such reservation request will receive a NACK citing policy violation.
2. Contract policy: these vary per contract, and is carried as *.rego files linked as part of the trade payload. They define contract specific violation & settlement rules. e.g. They can precisely define how certain combination of charging slot selection, reservation time, actual arrival time, charging start & stop times lead to revenue flows which reflect grace time, idling fees, waiting cost etc. This is the core objective that can be co-optimized between trades and between networks. 

Next we will see what kind of customer experience would be ideal for a variety of users on a EV network, and how it could be incentivized as a contract or network policy.

Customer journey for walk-in flow

1. Walk-in customers come with little or no lead time, with the expectation to be served as soon as possible. This flow can start online or after showing up on the station and scanning a QR code on it. They expect to wait in a real or virtual queue until their number comes up. They can relinquish their position in line without penalty if they choose to walk away or cancel.
2. They put in their vehicle information and connectors they may be carrying, side of the port, current soc & target state of charge. The system matches them to available chargers on a first come first served basis (This could be optimized.. But FIFO is simple, fair & predictable and hence a good start). They may receive an expected wait time, or receive number of people ahead of you with similar equipment and how fast the queue has been moving. They may receive instructions to pre-warm the battery to accelerate charging.
3. Once the number is about to come up, they will receive a notification with the exact charger to go to and charging speed to expect there. At every point in real-time, the system must match one vehicle against one charger. So two customers arriving at the same charger and arguing about who was first, should never happen.
4. After the notification, customers are allowed some grace period to start charging. If they do not show up during that period, that slot goes to someone else.. But instead of being relegated to the last position, they may get pushed back to the next slot for up to few times, determined by policy.
5. If the charger gun disconnects mid-charge, they can get some breather to reconnect again, without getting the session cancelled.
6. After the charging session is over, customers would pay an idling fee in case they don't physically disconnect and remove the vehicle.
7. Advanced use cases such as automatic vehicle identification after inserting the charging gun and automatic deduction from the linked payment account after the charging is complete, also need to be supported.

What can cause customer dissatisfaction in such a flow: lack of virtual queuing which causes crowding of space next to the charger, lack of clarity on who has rights to use the charger at any point, ability of rogue customers to jump the virtual queue by tailgating the current users of the charger, lack of sufficient information about wait-time forecast in order to decide between waiting and leaving, finding the charger occupied/not working/in-compatible even after getting notification to come to charge station, inability to charge without blocking the neighboring charger due to position of charge port, queue taking much longer than forecasted due to vehicle specific limitation.

Many of above issues can be solved by:

1. Contract policy: involves energy pre-payments - refund of unused energy + idle time penalty + credits when charging speed reduces compared to what was promised - penalty for charger not working.. and  so on. 
2. Network policy: that mandates all participants use same schema for expressing vehicle taxonomy and inputs to forecasting. It can also mandate common rules around lead times of walk-in orders, and gps tagged indicators of actually arriving at the charging site, or distance from it. This usually takes a few iterations and consensus, so as to ensure there is no incentives for bad actors.
3. Pricing engine: For most hours, the price of electricity decides the charging cost. But during times of high demand, surge pricing helps keep the price above opportunity cost of wait times of reservation holders, demand charges which apply when site goes near sanctioned load etc. Such pricing also acts as a backpressure to divert incoming vehicle away from the congested charger. 
4. Forecasting engine: The charge point operator publishes wait time range for every vehicle in the queue, including those which are en-route and asking about wait time after arrival.
5. Queuing optimizer: which tries advance queue positions of vehicles with more compatible chargers, less uncertain charge times etc. The goal of such optimizer would be reduce waiting time and its uncertainty.
6. Demand response bid optimizer: Once charging demand profile is understood, opportunity cost of charging revenue can be expressed to the grid as the bid-curve, making it less flexible during busy demand periods, and vice versa. This way, the flexibility is offered only if it is worth more to the grid than the increased wait time for customers, or penalties incurred by charge point operator.

Customer journey for reservation flow

1. Is separate from the walk-in flow, but is connected. A reservation must be made certain hours before the intended charge start time, per policy. Any reservation is not a guarantee for charger availability, but is a higher tier of service contract, which carries penalties for CPO if they are unable to fulfill.
2. Charge point operator will incur penalties if the charger is not available by the reservation start time.
3. Customers typically pay a service premium/ reservation fee to reserve ahead. This fee is forfeited if they cancel their reservation within the last X hours before charge starts. There can be multiple tiers of service, each carrying a higher premium but also penalties for CPO in case of unavailability.
4. All reservation customers enter the same queue as the walk-in customers as the charging start time approaches, and the forecasted end time of the current queue starts overlapping the reservation start time. The optimization engine that decides where in the queue a specific reservation goes tries to minimize the total current & future system cost, which includes penalty cost, cost of customers waiting physically on the site. This is equivalent to a fast-pass in Disneyland, but without the separate line. The fast-pass customers are swapped up/down within the same virtual multi-queues, as uncertainties make the queue go faster or slower.
5. For such optimization to work properly, it is imperative that some forecast of variables that change are available as well as uncertainty therein. Namely the charging time, arrival delay, departure delay, charger demand/queue length at various times of the day, maintenance outages, demand response events etc.
6. For CPOs which run a subscription network for their loyal users, the optimization can factor in preferred access, and ensure a higher service tier, and resist commoditization, which is the most cited complaint against interoperability. (What is my competitive advantage and source of differential profitability, if I remove all moats? Why will a customer stay loyal to me, when there is no way to incentivize loyalty in the protocol.)

What causes customer dissatisfaction in such a contract: all the failure modes in a walk-in contract plus lack of the promised discount/refund in case of delay relative to reservation start time.

1. Contract policy: Walk-in contract revenue line-items + the penalty for charger unavailability at the reservation start time.
2. Network policy: Walk-in contract policy plus rules around allowed reservation and cancellation windows..
3. Queuing optimizer: can move reservation holders earlier in queue in case of emergent delays in case the charger is not going to be available at reservation time, and penalties will start accruing.

Contract for demand response with the grid

Chargers are some of the largest loads that a local grid sees. They can potentially provide the largest demand response and ensure grid reliability. This is sometimes naturally enforced by demand charges, which necessitate chargers to keep max charge load low and below a sanctioned limit.

It could also be a dynamic limit, where based on the time of day, a charger can quote different opportunity cost to curtail charging load. E.g. During busy charging times and multiple reservations, the bid to curtail can be priced high, and reflects opportunity cost of keeping the customers waiting, queues longer and reservation miss penalties.

The same optimization engine that powers the queueing stack can power the demand response integration, because both revenue streams finally affect the same objective, namely the cost of operations, and benefit from knowing the foregone opportunity cost in the other use case. Thus even though queuing and DR optimization appear disconnected, they are in fact tightly connected.

Demand forecasting and back-pressure based road trip planning:

In 2022, Tesla open-sourced the charging connector spec so that other OEMs can adopt it. Later in 2023, in an act of extremely enlightened self-interest, it also struck deals with other OEMs to let them use Tesla's charging network, which is still the most reliable and available network. Many criticized this decision as the selling of crown jewels, but it was necessary for the EV industry to take off, reduce everyone's costs and reduce range anxiety without each OEM needing to stand up its own charging network. Based on public data, this was done by bilateral integration within each OEM app, as well as Tesla's app by making space for non-Tesla vehicle's specs. An interoperable stack would have helped reduce the toil of such integration, and make the demand forecasting and back-pressure based rerouting seamless. Each vehicle stopping by a waypoint would increment demand forecast, and can also sense the back-pressure in a congested charge point much earlier, and route towards most economical or detour-time-saving chargers.

Conclusion:

Like any well running system, running a high performance charging network takes the whole-system approach. To ensure that such a network is interoperable and highly performant, we need to simplify, standardize all the interfaces and enforce rules and broadcast incentives. From the discussion above, the need of AI that co-optimizes demand response, walk-in queues and reservation pricing becomes apparent. This is where great charge point operators can shine. Network operator can help by standardizing control policies, ensuring dispute free settlements (e.g. this is implemented in onix-adapter-deg as the contractpolicyenforcer plugin. At the end of transaction, it automatically generates/validates invoices of who owes what to whom.) and by proposing a common architecture for queue merging between walk-in & reservations.


P.S. An AI assisted detailed blueprint for above is here and schema implementation here.