Cloud is powerful, but not the right place for every decision.
Central platforms matter. User management, tariffs, billing, roaming, reporting, fleet overview and long-term optimization benefit from cloud scale. This is where a CPMS should use its strength.
The risk starts when site-critical decisions depend entirely on that connection. A charging site is not just a web portal. It consists of charge points, meters, network components, vehicles, local limits and operating rules that must remain valid when cellular connectivity, VPN, routers or backends become unstable.
In projects, we rarely see an abstract cloud problem. We see concrete operating effects: sessions do not start, RemoteStart arrives too late, charging profiles are delayed, StatusNotification and MeterValues lose context or support teams only see fragments.
- Local load limits must stay active when the backend is temporarily unreachable.
- Running sessions need protection from undefined intermediate states.
- OCPP events must be buffered and synchronized in an auditable way.
- Support teams need a local timeline, not only central error codes.
Cloud-only becomes risky around timing, context and availability.
Many charging decisions have a narrow time window. If a SetChargingProfile is applied too late, the grid limit may already be exceeded. If authorization does not arrive in time, a driver blocks the charge point. If a Reset or Unlock disappears, the issue becomes a field service case.
Central systems also often miss local context. The backend sees an OCPP message, but not always local network quality, meter state, building load, vehicle behavior or the exact event order in seconds. These signals often decide whether the root cause is the charger, vehicle, load management, configuration or backend process.
A robust architecture therefore separates central orchestration from site-critical operating logic. The cloud remains responsible for cross-site processes. The edge handles functions that must act close to charge points and meters.
What should run at the site.
Local functions should protect safety, availability and traceability at the site. This includes load management, local limits, fallback authorization, session protection, OCPP queueing, technical diagnostics and a current digital twin of the charge points.
The edge does not need to know every business feature. It must know which chargers are connected, which sessions are running, which limits apply, which messages are pending and which decisions were made locally. Then it can synchronize cleanly with the central platform.
In Pipelet building blocks, we treat this layer as modular: OCPP Broker, local state cache, digital twin, event journal, CPMS connectors and optional Edge AI diagnostics can be introduced separately or operated together.
- OCPP Broker for routing, normalization, queueing and migration.
- Edge Controller for meters, grid limits, local consumers and energy signals.
- Local CPMS for site-critical operation, session protection and fallback.
- Edge AI for patterns in OCPP, MeterValues, charging power and operating events.
The strongest architecture is edge plus cloud.
The edge does not replace the cloud. It supports the cloud where local reaction matters. The cloud can continue to manage tariffs, users, roaming, billing, reporting, fleet rules and long-term analytics. The edge applies site rules, keeps data complete and provides a defined operating mode during disruptions.
Synchronization is the discipline that makes this work. Local decisions must later become visible in the central platform. Central rules must be versioned and distributed to the site in a controlled way. Without this discipline, the edge becomes a second shadow platform.
From the NeLeSo perspective, this interface is the core: understand OCPP behavior, implement energy logic correctly, keep data models clean and use Edge AI only where it explains or solves a real operating problem.
A good entry point starts with the most expensive operating issue.
Operators should not start with the question whether they want cloud or edge. The better question is: which disruption costs time, money or trust today? Failed sessions, unclear charging stops, load peaks, unstable connectivity, missing diagnostics or a CPMS migration?
That question reveals the right first edge function. Sometimes an OCPP Broker with monitoring is enough. Sometimes the site needs local load rules. Sometimes Edge AI is useful because recurring patterns in MeterValues, status changes and network quality otherwise disappear in support work.
This creates a building block with measurable operational value, not a platform for its own sake. This is where modular approaches such as Pipelet help: start small, create measurable value and expand deliberately.