Insights

CPMS

CPMS am Edge: Was lokal laufen sollte und was in die Cloud gehört

Eine robuste Ladeinfrastruktur trennt lokale Betriebslogik und zentrale Plattformfunktionen sauber.

CPMS ist eine Funktionsebene, nicht automatisch ein Ort.

Viele CPMS-Funktionen gehören zentral organisiert: Nutzer, Verträge, Tarife, Roaming, Abrechnung, Reporting, Flottenübersicht, Rechteverwaltung und langfristige Analysen. Dafür ist die Cloud ideal.

Andere Funktionen wirken unmittelbar am Standort. Sie betreffen laufende Sessions, Ladeprofile, Grenzwerte, lokale Autorisierung, technische Diagnose und Fallback. Diese Funktionen leiden, wenn jede Entscheidung von einer stabilen Verbindung abhängt.

Ein CPMS am Edge ist daher kein Ersatz für ein zentrales CPMS. Es ist eine lokale Betriebsebene, die kritische Funktionen nah an Ladepunkten, Zählern und Energiegrenzen verfügbar hält.

Was lokal laufen sollte.

Lokal gehören Funktionen, die bei Verbindungsproblemen weiterlaufen müssen oder die lokale Signale im Sekundenbereich benötigen. Das sind vor allem Lastmanagement, Session-Schutz, Fallback-Regeln, lokale Whitelists, OCPP-Queueing, technische Diagnose und die aktuelle Sicht auf jeden Ladepunkt.

Der Edge muss Entscheidungen erklären können. Wenn er eine Session priorisiert, ein Ladeprofil setzt oder eine Nachricht puffert, muss später nachvollziehbar sein, warum das passiert ist. Ohne Auditierbarkeit wird lokale Intelligenz schnell zur Black Box.

  • Lokale Autorisierung und definierte Fallback-Regeln.
  • OCPP Broker mit State Cache, Routing, Queue und Retry-Logik.
  • Lastmanagement gegen reale Zähler, Netzgrenzen und Prioritäten.
  • Technische Diagnose aus OCPP, MeterValues, Netzwerk und Ladeleistung.
  • Synchronisierung von lokalen Entscheidungen zurück in die zentrale Plattform.

Was in die Cloud gehört.

Die Cloud bleibt der Ort für Funktionen, die mehrere Standorte, Nutzergruppen oder Geschäftsprozesse verbinden. Tarife, Verträge, Rechnungen, Roaming, OCPI, Flottenregeln, zentrale Dashboards, Modelltraining und langfristige Optimierung brauchen eine übergreifende Sicht.

Wichtig ist, dass Cloud und Edge nicht gegeneinander arbeiten. Zentrale Regeln müssen versioniert an den Edge verteilt werden. Lokale Ereignisse müssen vollständig genug zurückkommen, damit Reporting und Abrechnung stimmen. Die Grenze ist also nicht technisch beliebig, sondern eine Architekturentscheidung.

Der OCPP Broker ist die natürliche Trennlinie.

OCPP ist die Verbindung zwischen Ladepunkt und Betriebslogik. Deshalb ist der Broker oft die beste Stelle, um Cloud und Edge sauber zu trennen. Er kann Ladepunkte stabil halten, Nachrichten normalisieren, Zustände führen und entscheiden, welche Ereignisse lokal verarbeitet oder zentral weitergeleitet werden.

In Pipelet-Projekten nutzen wir den Broker häufig als Kernbaustein. Darum herum entstehen CPMS-Funktionen, Connectoren, Simulatoren, Monitoring und Edge-AI-Diagnose. Der Vorteil: Man muss nicht sofort ein komplettes CPMS ersetzen, sondern kann dort beginnen, wo Entkopplung oder lokale Resilienz den größten Nutzen bringt.

Ein gutes Edge CPMS ist bewusst begrenzt.

Die lokale Ebene sollte nicht heimlich zur zweiten Vollplattform werden. Sie sollte genau die Funktionen enthalten, die am Standort gebraucht werden, und alles andere an die zentrale Ebene zurückgeben.

Diese Begrenzung macht das System wartbar. Betreiber bekommen robuste Ladeparks, Entwickler bekommen klare Schnittstellen und Supportteams bekommen bessere Diagnose, ohne dass zwei konkurrierende Wahrheiten entstehen.