What the cloud does for a charger
Networked charging stations are run from a central system. The Open Charge Point Protocol (OCPP), published by the Open Charge Alliance, is the open protocol between a charging station and its charging station management system (CSMS). Through it, the management system decides whether a driver’s charge card or app may start a session, receives transaction records for billing, watches status and error reports, and sends remote commands such as a reset.
Three versions are available. OCPP 1.6 was released in 2015, OCPP 2.0.1 in 2020, and OCPP 2.1 in 2025. OCPP 2.0.1 edition 3 was approved as an IEC standard, IEC 63584, in 2024. The Alliance notes that 1.6 and 2.0.1 are not compatible with each other.
The connection between station and management system is the weak point. The Alliance’s uptime guide gives two examples: the station’s cellular data connection drops, or the entire management system goes offline. In both cases the station switches to what OCPP calls offline behaviour.
What happens to a session already running
The Alliance is clear on this. While offline, an OCPP station lets any ongoing transaction continue normally. It buffers the progress messages and the final stop message and sends them as soon as the connection is restored. An outage therefore has no effect on sessions that had already started, and no transaction information is lost: the operator can still invoice them.
What an outage does affect is starting new sessions, because the station can no longer ask the management system whether a card is allowed.
Starting new sessions offline
OCPP gives operators three tools, which they configure per station:
| Mechanism | How it works offline | Trade-off |
|---|---|---|
| Authorisation cache | The station remembers recent authorisation results and accepts a card that was authorised last time | Only regular users are covered. The Alliance notes a cache lifetime of a week or a month covers at least a station’s regular customers |
| Local authorisation list | The operator uploads a list of allowed cards, versioned and updated incrementally to stay in step with its central database | Not part of the OCPP core profile, so not every station implements it |
| Offline acceptance of unknown cards | AllowOfflineTxForUnknownId (1.6) or OfflineTxForUnknownIdEnabled (2.0.1) lets any card start charging | Sessions for unknown cards cannot be invoiced afterwards |
The Alliance frames the last option as a financial risk the operator takes in return for higher availability, and says it may be acceptable for AC chargers but is often considered too high for DC fast chargers, which are much more expensive. In every case, the station checks the card against what it already holds. It never learns about a card blocked or added after its last sync. What is offline authentication? covers this trade-off in general terms.
What still needs the connection
Charge cards are not the only way to start a session. A charge controller vendor’s documentation shows how much depends on the network. Bender lists the requirements for each authorisation flow: an RFID token needs a compatible card reader, while mobile charging apps and payment cards both need an internet connection and an OCPP backend. ISO 15118 Plug and Charge, which also needs an ISO 15118-capable car, likewise needs an internet connection and an OCPP backend that supports it.
So during an outage, drivers who use an app or a bank card depend on whatever offline path the operator has provided. OCPP 2.1 adds new authorisation and payment options, including local cost calculation on the station, prepaid charge cards whose balance caps the transaction cost, and ad hoc payment through a built-in or stand-alone card terminal.
The other gap is visibility. By default only transaction messages are buffered, so failed authorisation attempts and status notifications from the offline period never reach the operator. OCPP 2.0.1 adds a setting, OCPPCommCtrlr.QueueAllMessages, that queues every message for sending once the station reconnects, so the operator can see what went wrong while it was out of contact.
Where device-to-device software fits
The OCPP model is a station that holds a little state locally and settles up with the cloud later, using a kind of outbox for its transaction messages. What OCPP does not define is a local link between the charger and the other devices on site.
The driver’s phone is the obvious one. If the app can reach the charger directly over a short-range radio, the charger can show its status and accept a signed request from a known account without a round trip to the cloud. That only stays safe if the charger can verify the request locally and applies the same rules as an OCPP local list. A site controller that coordinates several chargers can do the same, keeping session state and load decisions on site. In both cases every record still needs a stable ID and its own timestamp, so the management system can put events back in order and invoice each session once when the link returns.