EV Charger Behaviour During Network and Power Failure

Losing the backend

This is the common case, and in Indian basement and podium parking it is closer to a permanent condition than an exception.

1. 1

   Sessions in progress continue

   There is no safety reason to stop. A charger that ends sessions on losing connectivity is making an outage the driver's problem.

2. 2

   New sessions authorise locally

   Against a cached list, a local whitelist, or a defined policy for unknown users. Which of those is correct is a commercial decision, and it should be a decision rather than a default.

3. 3

   Records buffer locally

   Complete transaction records, with timestamps that will still make sense when they arrive. Buffer depth is a real design number: how many sessions across how many days.

4. 4

   Reconnect and upload

   Without duplicating, without losing, and without flooding the backend when a hundred chargers reconnect at once after a regional outage.

The fraud window

Offline authorisation means authorising without checking, and that is a commercial exposure rather than a technical one.

• A cached authorisation list ages. A user blocked yesterday may still be on the charger's copy
• A stopped card cannot be checked while the backend is unreachable
• Credit and balance cannot be verified, so a prepaid model is exposed for the duration
• The exposure is bounded by cache age and by how long a site can plausibly be offline

The right answer depends on the site. A residential building where every user is known can authorise offline freely. A public forecourt probably should not. Making this configurable per site, rather than choosing one behaviour globally, is what lets both be right.

Losing power, and restarting safely

Power loss during a session is an ordinary event and the correct behaviour is unglamorous.

• Contactors open, which they will do anyway, and the state before the loss is recorded if there was time
• On restart, do not resume automatically into a connected vehicle. Re-establish the pilot state and require a fresh sequence
• Reconstruct the interrupted transaction from non-volatile storage and close it out honestly rather than discarding it
• Stagger restart across a site, because every charger resuming simultaneously is an inrush the supply just failed to handle
• Do not trust the clock until it has been re-established, which matters for both records and certificates

The reconciliation problem

After any outage there are sessions that happened while nobody was watching, and they have to become revenue.

• Sessions that started before the outage and ended during it
• Sessions that ran entirely offline and arrive late, sometimes days late
• Sessions the backend believes are still open because it never saw them end
• Sessions authorised offline for a user who should have been refused
• Duplicate uploads from a charger that was not sure the first attempt succeeded

Each of these is manageable if it was anticipated and awkward if it was not. Late arriving sessions in particular have to be accepted into a billing period that may already be closed, which is a finance process question as much as a technical one.

What to require at acceptance

All of the above is testable, and testing it takes an afternoon. It is worth requiring rather than assuming.

• Disconnect the backend mid-session. The session must continue and the record must arrive complete on reconnect
• Start a session with the backend disconnected. Authorisation behaviour must match the configured policy
• Cut power mid-session. On restore, the unit must not resume automatically and the interrupted transaction must be recoverable
• State the buffer depth in sessions and days, and verify it rather than accepting a number
• Reconnect several chargers at once and confirm the backend is not flooded
• Confirm the offline authorisation policy is configurable per site, not global