Cloud ist stark, aber nicht automatisch der richtige Ort für jede Entscheidung.
Zentrale Plattformen sind wichtig: Nutzerverwaltung, Tarife, Abrechnung, Roaming, Reporting, Flottenübersicht und langfristige Optimierung profitieren von Cloud-Skalierung. Genau dort sollte ein CPMS seine Stärke ausspielen.
Der kritische Punkt entsteht, wenn auch standortnahe Entscheidungen komplett von dieser Verbindung abhängen. Ein Ladepark ist kein reines Web-Portal. Er besteht aus Ladepunkten, Zählern, Netzwerkkomponenten, Fahrzeugen, lokalen Grenzwerten und Betriebsregeln, die auch dann gelten müssen, wenn Mobilfunk, VPN, Router oder Backend temporär wackeln.
In Projekten sehen wir deshalb selten ein abstraktes Cloud-Problem. Wir sehen konkrete Betriebsfolgen: Sessions starten nicht, RemoteStart kommt zu spät, Ladeprofile werden nicht rechtzeitig gesetzt, StatusNotification und MeterValues fehlen im richtigen Kontext oder ein Supportteam sieht nur noch einen unvollständigen Ausschnitt.
- Lastgrenzen müssen lokal weiter gelten, auch wenn das Backend kurz nicht erreichbar ist.
- Laufende Ladevorgänge brauchen Schutz vor undefinierten Zwischenzuständen.
- OCPP-Ereignisse müssen gepuffert und später nachvollziehbar synchronisiert werden.
- Support und Betrieb brauchen eine lokale Timeline, nicht nur zentrale Fehlercodes.
Cloud-only wird vor allem bei Zeit, Kontext und Verfügbarkeit riskant.
Viele Entscheidungen im Ladepark haben ein enges Zeitfenster. Wird ein SetChargingProfile zu spät gesetzt, ist die Netzgrenze vielleicht schon gerissen. Kommt eine Autorisierung nicht rechtzeitig, blockiert ein Fahrer den Ladepunkt. Geht ein Reset oder Unlock ins Leere, entsteht vor Ort ein Servicefall.
Gleichzeitig fehlt zentral oft der vollständige Kontext. Das Backend sieht eine OCPP-Nachricht, aber nicht immer die lokale Netzwerkqualität, den Zustand des Zählers, die aktuelle Gebäudelast, die Reaktion des Fahrzeugs oder die Reihenfolge der Ereignisse im Sekundenbereich. Genau diese Signale entscheiden aber darüber, ob ein Fehler in der Wallbox, im Fahrzeug, im Lastmanagement oder in der Kommunikation liegt.
Eine robuste Architektur trennt daher zwischen zentraler Steuerung und standortkritischer Betriebslogik. Die Cloud bleibt der Ort für übergreifende Prozesse. Der Edge übernimmt die Funktionen, die nah an den Ladepunkten und Zählern wirken müssen.
Was am Standort lokal laufen sollte.
Lokal gehören Funktionen, die Sicherheit, Verfügbarkeit und Nachvollziehbarkeit am Standort sichern. Dazu zählen Lastmanagement, lokale Grenzwerte, Fallback-Autorisierung, Session-Schutz, OCPP-Queueing, technische Diagnose und der aktuelle Digital Twin der Ladepunkte.
Der Edge muss nicht jedes Business-Feature kennen. Er muss aber wissen, welche Ladepunkte verbunden sind, welche Sessions laufen, welche Limits gelten, welche Nachrichten offen sind und welche Entscheidungen lokal getroffen wurden. Danach kann er sauber mit dem zentralen System synchronisieren.
In unseren Pipelet-Bausteinen denken wir diese Ebene bewusst modular: OCPP Broker, lokaler State Cache, Digital Twin, Ereignisjournal, Connectoren zum CPMS und optionale Edge-AI-Diagnose können einzeln eingeführt oder gemeinsam betrieben werden.
- OCPP Broker für Routing, Normalisierung, Queueing und Migration.
- Edge Controller für Zähler, Netzgrenzen, lokale Verbraucher und Energiesignale.
- Lokales CPMS für standortkritische Bedienung, Session-Schutz und Fallback.
- Edge AI für Mustererkennung in OCPP, MeterValues, Ladeleistung und Betriebsereignissen.
Die stärkste Architektur ist Edge plus Cloud, nicht Edge gegen Cloud.
Der Edge ersetzt die Cloud nicht. Er entlastet sie dort, wo lokale Reaktionsfähigkeit zählt. Die Cloud kann weiterhin Tarife, Nutzer, Roaming, Abrechnung, Reporting, Flottenregeln und langfristige Analysen steuern. Der Edge setzt standortnahe Regeln um, hält Daten vollständig und sorgt für einen definierten Betriebsmodus bei Störungen.
Wichtig ist die Synchronisierung. Entscheidungen, die lokal getroffen werden, müssen später auditierbar in der zentralen Plattform erscheinen. Umgekehrt müssen zentrale Regeln versioniert und kontrolliert an den Standort verteilt werden. Ohne diese Disziplin entsteht nur eine zweite Schattenplattform.
Aus NeLeSo-Sicht ist genau diese Schnittstelle der Kern: OCPP-Verhalten verstehen, Energie-Logik korrekt umsetzen, Datenmodelle sauber halten und Edge-AI nur dort einsetzen, wo sie ein echtes Betriebsproblem besser erklärbar oder schneller lösbar macht.
Ein guter Einstieg beginnt mit dem teuersten Betriebsproblem.
Betreiber sollten nicht mit der Frage starten, ob sie Cloud oder Edge wollen. Besser ist die Frage: Welche Störung kostet heute Zeit, Geld oder Vertrauen? Sind es nicht startende Sessions, unklare Ladeabbrüche, Lastspitzen, instabile Konnektivität, fehlende Diagnose oder eine Migration zwischen CPMS-Systemen?
Aus dieser Frage ergibt sich die sinnvolle erste Edge-Funktion. Manchmal reicht ein OCPP Broker mit sauberem Monitoring. Manchmal braucht der Standort lokale Lastregeln. Manchmal lohnt sich Edge AI, weil wiederkehrende Muster in MeterValues, Statuswechseln und Netzwerkqualität sonst im Support verloren gehen.
So entsteht keine Plattform um der Plattform willen, sondern ein ausbaufähiger Betriebsbaustein. Genau dafür sind modulare Ansätze wie Pipelet wertvoll: klein starten, messbaren Nutzen erzeugen und danach gezielt erweitern.