Ladepunkte leben länger als Backend-Verträge.
Ein öffentlicher Ladepunkt wird für ein Jahrzehnt und mehr Betrieb geplant, inklusive Tiefbau, Netzanschluss und Genehmigungen. Backend-Verträge laufen deutlich kürzer, und der Markt dahinter ist alles andere als stabil: Anbieter werden übernommen, stellen Produkte ein oder ändern Preismodelle. Wer heute ein CPMS auswählt, entscheidet damit nicht über die Lebensdauer der Infrastruktur, sondern nur über einen Abschnitt davon. Die Architektur sollte diesen Unterschied abbilden.
Dazu kommt die regulatorische Dynamik. AFIR verlangt seit 2024 Ad-hoc-Zahlung und Datenbereitstellung, seit Januar 2026 ist ISO 15118 für neue öffentliche AC-Ladepunkte in der EU Pflicht, und mit ISO 15118-20 stehen Plug&Charge und V2G auf der Roadmap vieler Betreiber. Jedes dieser Themen erzeugt Backend-Anforderungen, die bei Vertragsabschluss oft noch gar nicht absehbar waren. Ob der aktuelle Anbieter sie rechtzeitig umsetzt, liegt außerhalb der Kontrolle des CPOs – es sei denn, der Wechsel ist technisch jederzeit möglich.
In Projekten sehen wir häufig, dass die Backend-Entscheidung als einmalige Beschaffung behandelt wird: ausschreiben, auswählen, anbinden, abhaken. Die robustere Sichtweise ist eine andere: Das Backend der Ladeinfrastruktur ist eine austauschbare Komponente, die Ladepunkte sind der bleibende Wert. Aus dieser Perspektive wird Wechselfähigkeit vom Nice-to-have zur zentralen Architekturanforderung.
Lock-in entsteht selten im OCPP-Protokoll, sondern in den Schichten darum.
Auf dem Papier ist ein Backend-Wechsel trivial: OCPP ist standardisiert, also genügt es, die WebSocket-URL im Ladepunkt umzustellen. In der Praxis scheitert genau das regelmäßig – nicht am Protokoll, sondern an allem, was sich um das Protokoll herum angesammelt hat. Lock-in ist selten ein einzelner Mechanismus, sondern eine Summe kleiner Abhängigkeiten, die einzeln harmlos wirken. Zusammen machen sie den Wechsel so teuer, dass er unterbleibt.
Die erste Schicht ist die Konfiguration: Über Jahre werden Parameter per ChangeConfiguration oder SetVariables gesetzt, Firmware-Stände verwaltet und herstellerspezifische Eigenheiten im Backend kompensiert – dokumentiert ist davon oft nichts, außer im System des Anbieters selbst. Die zweite Schicht ist die Datenhaltung: CDRs, historische MeterValues, eichrechtlich relevante OCMF-Datensätze (Open Charge Metering Format) und Kundendaten liegen im Datenmodell des Anbieters. Die dritte Schicht sind Verträge: Roaming läuft häufig über die OCPI-Anbindungen und den Hubject-Zugang des Backend-Anbieters, nicht über eigene Verträge des CPOs.
- Konfigurations- und Firmwarestände der Ladepunkte existieren nur im Alt-Backend, nicht als eigene Dokumentation.
- Historische Ladedaten und OCMF-signierte Messwerte sind nicht oder nur unvollständig exportierbar.
- EVSE-IDs, OCPI-Verbindungen und die Hubject-Anbindung hängen an Verträgen des Anbieters.
- Authentifizierung, Tarife und Lastmanagement nutzen proprietäre Funktionen außerhalb des OCPP-Standards.
Multi-Backend-Architektur: ein Broker macht Backends austauschbar.
Der Kern einer Multi-Backend-Strategie ist eine Entkopplungsschicht zwischen Ladepunkten und Backends. Ein OCPP Broker terminiert die Verbindungen der Ladepunkte und routet Nachrichten an ein oder mehrere Zielsysteme. Die Ladepunkte zeigen dauerhaft auf eine URL unter Kontrolle des CPOs – welches Backend dahinter antwortet, wird zur Routing-Entscheidung statt zum Rollout-Projekt. Das verändert die Verhandlungsposition in jedem Vertragsgespräch.
Praktisch beginnt das oft klein: Test- und Produktionsumgebung laufen parallel, indem der Broker Nachrichten spiegelt. Der nächste Schritt ist ein zweiter Anbieter für einen Teil des Bestands, etwa neue Standorte oder ein Pilot-Cluster. Ein vollständiger Wechsel läuft dann als schrittweise Migration: Ladepunkt für Ladepunkt oder Standort für Standort umschalten, mit Rückweg, falls das neue Backend Probleme zeigt. Aus dem riskanten Big Bang wird ein kontrollierter Prozess mit messbaren Zwischenschritten.
Eine Broker-Schicht hilft auch beim Protokoll-Thema. OCPP 1.6 und 2.0.1 sind nicht kompatibel zueinander, viele Bestandsflotten sind gemischt, und OCPP 2.1 ist zwar abwärtskompatibel zu 2.0.1, aber nicht zu 1.6. Ein Broker behandelt diese Unterschiede an einer Stelle und liefert nachgelagerten Systemen ein konsistentes Bild, statt jede Protokollvariante in jedes Backend zu tragen.
Exit-Fähigkeit gehört in die Ausschreibung, nicht in die Krise.
Der schlechteste Zeitpunkt, über einen Backend-Wechsel nachzudenken, ist der Moment, in dem er nötig wird. Wer erst bei einer Insolvenz, einer Preiserhöhung oder einer eingestellten Roadmap den Exit plant, verhandelt aus der schwächsten Position und migriert unter Zeitdruck. Exit-Fähigkeit ist deshalb ein Beschaffungskriterium wie Preis oder Funktionsumfang. Sie lässt sich konkret ausschreiben und vor Vertragsabschluss testen.
Neben OCPP auf der Südseite entscheidet die Nordseite des CPMS über die reale Wechselfähigkeit: dokumentierte APIs (etwa als OpenAPI-Spezifikation), ein offengelegtes Datenmodell und der vollständige Export von Transaktionen, Tarifen und Nutzerkonten. Ob angebundene eigene Systeme wie Kundenportale, ERP oder Analysen einen Backend-Wechsel überleben, hängt an genau diesen Schnittstellen – nicht am Protokoll zum Ladepunkt.
Zur Exit-Fähigkeit gehört auch die kaufmännische Seite. B2B-Abrechnung über XRechnung oder ZUGFeRD muss auch nach einem Wechsel aus den eigenen Daten reproduzierbar bleiben, etwa bei Rückfragen oder Prüfungen. Und Roaming sollte über eigene Verträge laufen: Ein eigener Hubject-Zugang oder zumindest übertragbare OCPI-2.2/2.3-Anbindungen verhindern, dass mit dem Backend auch die Reichweite im Roaming-Netz verschwindet.
- Vollständiger, maschinenlesbarer Datenexport (CDRs, MeterValues, OCMF-Datensätze, Konfiguration) – vertraglich zugesichert und real getestet.
- Eigene Roaming-Verträge oder nachweislich übertragbare OCPI-Anbindungen und EVSE-IDs.
- Ladepunkt-Konfiguration als dokumentierter Stand außerhalb des Backends.
- Ein Probelauf vor Vertragsverlängerung: einen Ladepunkt testweise auf ein zweites System umziehen.
Datenhoheit ist die Grundlage jeder Wechselfähigkeit.
Am Ende entscheidet eine einfache Frage über Lock-in oder Freiheit: Wo liegen die Rohdaten? Wer den vollständigen OCPP-Nachrichtenstrom, die signierten Messwerte und die Konfigurationsstände selbst hält, kann jedes Backend wechseln, ohne Historie zu verlieren. Das ist auch eichrechtlich relevant: MID-konforme Zähler erzeugen die Messwerte, OCMF-Signaturen machen sie mit Transparenzsoftware unabhängig vom Backend prüfbar – aber nur, wenn der CPO die Datensätze tatsächlich besitzt. Datenhoheit ist damit kein abstraktes Prinzip, sondern eine konkrete Betriebs- und Compliance-Anforderung.
Eine Broker-Schicht erzeugt diese Hoheit fast nebenbei: Sie sieht jede Nachricht zwischen Ladepunkt und Backend und kann daraus ein eigenes Journal, einen aktuellen Konfigurationsstand und ein unabhängiges Archiv aufbauen. Backends kommen und gehen, das eigene Datenfundament bleibt. Genau darauf sollte eine Broker-Schicht ausgelegt sein: Ladepunkte einmal anbinden, Backends flexibel routen und die Daten dauerhaft in der Hand des Betreibers halten. Wechselfähigkeit ist dann kein Ausnahmezustand mehr, sondern der Normalzustand der Architektur.