CPMS is a functional layer, not automatically a location.
Many CPMS functions belong centrally: users, contracts, tariffs, roaming, billing, reporting, fleet overview, permissions and long-term analytics. The cloud is ideal for this.
Other functions act immediately at the site. They affect running sessions, charging profiles, limits, local authorization, technical diagnostics and fallback. These functions suffer when every decision depends on a stable connection.
A CPMS at the edge is therefore not a replacement for a central CPMS. It is a local operating layer that keeps critical functions available near charge points, meters and energy limits.
What should run locally.
Functions that must continue during connection problems or need local signals within seconds belong locally. This includes load management, session protection, fallback rules, local whitelists, OCPP queueing, technical diagnostics and the current view of each charge point.
The edge must be able to explain decisions. If it prioritizes a session, sets a charging profile or buffers a message, it must later be clear why that happened. Without auditability, local intelligence quickly becomes a black box.
- Local authorization and defined fallback rules.
- OCPP Broker with state cache, routing, queue and retry logic.
- Load management against real meters, grid limits and priorities.
- Technical diagnostics from OCPP, MeterValues, network and charging power.
- Synchronization of local decisions back to the central platform.
What belongs in the cloud.
The cloud remains the place for functions that connect multiple sites, user groups or business processes. Tariffs, contracts, invoices, roaming, OCPI, fleet rules, central dashboards, model training and long-term optimization need a cross-site view.
Cloud and edge must not work against each other. Central rules must be versioned and distributed to the edge. Local events must come back complete enough for reporting and billing to remain correct. The boundary is therefore not arbitrary. It is an architecture decision.
The OCPP Broker is the natural boundary.
OCPP connects charge points and operating logic. That makes the broker a natural place to separate cloud and edge cleanly. It can keep charge points stable, normalize messages, hold state and decide which events are processed locally or forwarded centrally.
In Pipelet projects, we often use the broker as a core building block. CPMS functions, connectors, simulators, monitoring and Edge AI diagnostics can then be added around it. The advantage: you do not have to replace a full CPMS immediately. You can start where decoupling or local resilience creates the largest benefit.
A good edge CPMS is deliberately limited.
The local layer should not silently become a second full platform. It should contain exactly the functions required at the site and return everything else to the central layer.
This limitation keeps the system maintainable. Operators get robust charging sites, developers get clear interfaces and support teams get better diagnostics without two competing truths.