OCPP 2.0.1 ist ein Protokollwechsel, kein Firmware-Update.
OCPP 1.6 und OCPP 2.0.1 sind nicht kompatibel. Ein Ladepunkt spricht entweder das eine oder das andere Protokoll, erkennbar schon am WebSocket-Subprotokoll beim Verbindungsaufbau. Wer die Migration wie ein gewöhnliches Firmware-Update plant, unterschätzt, dass sich Nachrichtenmodell, Zustandslogik und Sicherheitsarchitektur grundlegend ändern.
Die wichtigsten Unterschiede liegen unter der Oberfläche. Das Transaktionsmodell wechselt von StartTransaction und StopTransaction zu einem durchgängigen TransactionEvent-Strom. Die flachen Configuration Keys werden durch ein strukturiertes Gerätemodell aus Components und Variables ersetzt. Und die Security Profiles mit TLS, Basic Auth und Client-Zertifikaten sind kein optionales Extra mehr, sondern fester Bestandteil des Protokolls inklusive Zertifikatsmanagement über OCPP selbst.
Gleichzeitig steigt der Druck, den Wechsel anzugehen. Seit Januar 2026 gilt die ISO 15118-Pflicht für neue öffentliche AC-Ladepunkte in der EU, und Funktionen wie Plug&Charge lassen sich mit OCPP 2.0.1 deutlich sauberer abbilden als mit 1.6-Erweiterungen. OCPP 2.1 ist verfügbar und abwärtskompatibel zu 2.0.1: Wer jetzt auf 2.0.1 migriert, hat einen klaren Pfad zu 2.1, ohne den Umbau zu wiederholen.
- TransactionEvent ersetzt StartTransaction/StopTransaction und ändert die Abrechnungslogik.
- Components und Variables lösen die flachen Configuration Keys ab.
- Security Profiles mit TLS und Zertifikatsmanagement sind Pflichtbestandteil.
- Eigene WebSocket-Subprotokolle: eine Verbindung ist entweder 1.6 oder 2.0.1, nie beides.
- Status wird pro EVSE und Connector gemeldet, nicht mehr nur pro Connector.
Warum der Big-Bang-Ansatz in der Praxis scheitert.
Big Bang heißt: Backend und alle Ladepunkte werden an einem Stichtag gemeinsam umgestellt. In Projekten sehen wir, warum das selten funktioniert. Reale Flotten sind heterogen, mit mehreren Herstellern und Firmwareständen, und manche Geräte unterstützen 2.0.1 nur auf dem Datenblatt. Dazu hängen an der Umstellung Zertifikatsrollout, Backend-Mapping und Abrechnungsketten, die sich nicht alle am selben Tag verifizieren lassen.
Die eigentlichen Fehler zeigen sich erst unter Last. MeterValues kommen in anderer Struktur, das Statusmodell verhält sich anders, und die Eichrecht-Datenkette mit OCMF-signierten Messwerten aus MID-konformen Zählern muss durchgängig bleiben, damit Transparenzsoftware jeden Ladevorgang prüfen kann. Ein Rollback ist nach dem Stichtag schwierig, weil Konfigurationen, Zertifikate und Backend-Zuordnungen bereits umgestellt sind.
Downtime ist dabei nicht nur ein technisches Problem. Ad-hoc-Zahlung nach AFIR und Roaming über OCPI laufen im Betrieb weiter, und jede Datenlücke taucht später in Rechnungen, Roaming-Abgleichen oder Supportfällen wieder auf. Genau deshalb braucht die Migration einen Ablauf, der jederzeit einen definierten Rückweg offenhält.
Der erprobte Ablauf: vier Phasen über einen OCPP Broker.
Der Kern des Ansatzes: Ladepunkte verbinden sich nicht direkt mit dem Backend, sondern mit einer Broker-Schicht dazwischen. Diese Schicht hält die Verbindung zu den Ladepunkten stabil, während dahinter umgebaut wird. In Phase 1, der Schatten-Anbindung, bleibt der Bestand unverändert auf OCPP 1.6 am alten Backend, während der Broker den Nachrichtenstrom zusätzlich in das neue 2.0.1-Zielsystem spiegelt und übersetzt.
In Phase 2, dem Vergleichsbetrieb, laufen beide Pfade parallel und werden systematisch abgeglichen: Transaktionen, MeterValues, Statuswechsel und Autorisierungen müssen in beiden Welten dasselbe Bild ergeben. Abweichungen sind an diesem Punkt fast immer Konfigurations- oder Mapping-Themen, die sich ohne Betriebsrisiko korrigieren lassen. Erst danach beginnt Phase 3, die gruppenweise Umschaltung: Kohorten nach Hersteller, Firmwarestand und Standort, beginnend mit einer kleinen Pilotgruppe.
Phase 4 ist der Abschluss. Der alte Pfad wird kontrolliert abgebaut, das Monitoring auf das neue Zielsystem ausgerichtet und die Umstellung pro Gruppe dokumentiert. Bis zu diesem Punkt bleibt der Rückweg pro Kohorte offen: Eine Gruppe, die Probleme zeigt, kann auf den alten Pfad zurückgeschaltet werden, ohne die übrige Flotte zu berühren. Damit das auch mit laufenden Transaktionen funktioniert, muss der Broker beim Umschalten und Zurückschalten Nachrichten deduplizieren – etwa über eindeutige Message- und Transaktions-IDs beim Reconnect –, damit nichts doppelt verbucht wird, und die Zählerstände konsistent halten, sodass die Abrechnungskette aus Start- und Stop-Werten über den Wechsel hinweg lückenlos bleibt.
- Phase 1 – Schatten-Anbindung: Bestand bleibt auf 1.6, der Broker spiegelt in das 2.0.1-Ziel.
- Phase 2 – Vergleichsbetrieb: Transaktionen und Messwerte beider Pfade werden abgeglichen.
- Phase 3 – Gruppenweise Umschaltung: Kohorten nach Hersteller, Firmware und Standort.
- Phase 4 – Abschluss: alter Pfad wird abgebaut, Rückweg bleibt bis dahin offen.
Was mit laufenden Ladevorgängen passiert.
Kein Ladevorgang sollte durch die Migration abgebrochen werden. Deshalb schaltet der Broker an Session-Grenzen um: Eine Gruppe wechselt erst, wenn dort keine aktive Transaktion läuft, typischerweise in verkehrsarmen Zeitfenstern. Weil der Broker den Session-Status jedes Ladepunkts kennt, ist das keine Hoffnung, sondern eine prüfbare Bedingung vor jeder Umschaltung.
Auch Reconnects und Offline-Phasen brauchen einen Plan. Ladepunkte puffern Transaktionsdaten, wenn die Verbindung kurz wegbricht, und liefern sie nach dem Wiederaufbau nach. Der Broker gleicht dabei Transaktions-IDs zwischen alter und neuer Welt ab, damit die Abrechnung konsistent bleibt. Für eichrechtsrelevante Vorgänge gilt zusätzlich: OCMF-signierte Messwerte gehören eindeutig zu einer Transaktion und müssen auch nach der Umschaltung dem richtigen Vorgang zugeordnet bleiben.
Für Fahrer ist die beste Migration die, die niemand bemerkt. RemoteStart, Autorisierung und Ad-hoc-Zahlung funktionieren durchgehend, weil die Ladepunktverbindung nie abreißt. Und wenn doch etwas auffällt, sieht der Support im Broker die vollständige Nachrichten-Timeline beider Pfade, statt zwischen zwei Backends nach der Ursache zu suchen.
Ein realistischer Zeitrahmen und der erste Schritt.
Eine seriöse OCPP 2.0.1 Migration wird in Wochen und Monaten geplant, nicht in Tagen. Die Schatten-Anbindung selbst geht schnell, weil am Bestand nichts verändert wird. Der Vergleichsbetrieb braucht dagegen genug echte Ladevorgänge über mehrere Wochen, um Wochenlast, Offline-Phasen und Sonderfälle wirklich gesehen zu haben. Die Umschaltwellen danach sind gut planbar, weil jede Kohorte demselben geprüften Muster folgt.
Der längste Posten ist in unserer Erfahrung selten die Broker-Technik, sondern die Umgebung: Firmware-Freigaben der Hersteller, Zertifikatsprozesse für die Security Profiles und die Abstimmung mit Abrechnung und Roaming. Deshalb lohnt es sich, früh eine ehrliche Geräteliste zu erstellen: Welche Modelle können 2.0.1 nachweislich stabil, welche brauchen ein Firmware-Update, welche bleiben vorerst auf 1.6.
Genau für diese Zwischenschicht eignet sich in Migrationsprojekten ein OCPP Broker, der 1.6 und 2.0.1 parallel führt und den Vergleichsbetrieb auswertbar macht. Ob selbst gebaut oder zugekauft – an vier Anforderungen dieser Schicht führt kein Weg vorbei: Verfügbarkeit mindestens auf Backend-Niveau mit redundanter Auslegung, weil der Broker im Nachrichtenpfad zum Single Point of Failure wird; Durchsatz für die volle Flotte inklusive der Lastspitzen von Reconnect-Stürmen; Latenz als Größenordnung im niedrigen zweistelligen Millisekundenbereich, damit Ladepunkt-Timeouts nicht anschlagen; und ein Betriebsstandort mit kurzem Netzpfad – nah an den Ladepunkten oder im eigenen Netz. Wo zusätzlich Backend-Funktionen fehlen, lassen sich modulare CPMS-Bausteine ergänzen, ohne dass die gesamte Plattform gewechselt werden muss.