Resilience comes from clear responsibilities.
A resilient charging site does not rely blindly on one layer. The cloud provides overview, scale, central processes and cross-site optimization. The edge provides local reaction, data proximity and operating continuity.
The system becomes robust only when both layers have clear tasks. The cloud must not block every local decision. The edge must not invent uncontrolled business logic. Between both layers, you need rules, versioning, an event journal and clean synchronization.
A charging site needs defined operating modes.
During disruptions, the site should not fall into an undefined state. Good architectures explicitly define what happens in each mode: connected, degraded, autonomous and recovery.
In every mode, it must be clear which rules apply, which data is buffered, which actions are allowed and how reconciliation works later. This is especially important for billing, operator obligations and technical traceability.
- Connected: cloud and edge operate in sync, central rules are continuously updated.
- Degraded: edge buffers messages, prioritizes local rules and protects running sessions.
- Autonomous: the site keeps charging with defined local rules.
- Recovery: events, decisions and meter readings are reconciled in a controlled way.
OCPP resilience is more than reconnecting.
Many systems treat resilience as a reconnect problem. That is not enough. What matters is what happens during the interruption: which OCPP messages were created, which of them are critical, which local states changed and which RemoteCommands are obsolete when the connection returns?
An OCPP Broker with local queue and state cache can answer these questions. It protects not only the connection, but the functional state of the charging site. Edge AI can add value by detecting unusual sequences and helping support teams understand the recovery context.
Resilience must be visible to operators.
For operators, it is not enough that a system technically keeps running. They need to see which mode a site is in, which local rules were active, which charge points are affected and which data still needs synchronization.
This visibility creates trust. If a site continued autonomously, that must be explainable later. If data was delivered later, it must be clear whether reporting and billing are complete.
Resilience is an architecture product, not one feature.
A single fallback switch is not enough. Resilience comes from multiple building blocks: OCPP Broker, Edge Controller, local CPMS, event journal, monitoring, test cases, simulators, clear synchronization rules and optional Edge AI.
This is where NeLeSo is strongest. We combine protocol depth, energy integration, Azure and Python engineering and Pipelet building blocks so charging sites do not only work, but remain understandable when something goes wrong.