OCPP 2.1 ist ein evolutionärer Schritt, kein neuer Bruch.
OCPP 2.1 ist verfügbar und baut direkt auf OCPP 2.0.1 auf. Der entscheidende Unterschied zu früheren Versionssprüngen: 2.1 ist vollständig abwärtskompatibel zu 2.0.1. Ein Ladepunkt mit 2.0.1 kann gegen ein 2.1-Backend betrieben werden, und die neuen Funktionsblöcke sind additiv, nicht verpflichtend. Wer die Grundlagen von 2.0.1 sauber umgesetzt hat, bekommt den Weg zu 2.1 ohne Architekturbruch.
Das steht im deutlichen Kontrast zum Schritt von OCPP 1.6 auf 2.0.1. Diese beiden Versionen sind nicht kompatibel: anderes Transaktionsmodell, Device Model statt Configuration Keys, andere Nachrichtenstruktur, andere Security-Profile. Zwischen 1.6 und 2.0.1 liegt eine echte Migration, zwischen 2.0.1 und 2.1 ein kontrolliertes Upgrade.
In Projekten sehen wir genau hier die größte Verunsicherung: Viele Betreiber lesen OCPP 2.1 als weiteren erzwungenen Umbau nach dem Muster 1.6 auf 2.0.1. Das ist nicht der Fall. Die realistische Frage lautet nicht, ob 2.1 einen neuen Bruch erzeugt, sondern wie der Bestand geordnet auf den 2.0.1-Pfad kommt, von dem aus 2.1 erreichbar ist.
Die wichtigsten Neuerungen: Bidirektionalität, DER und robuster Offline-Betrieb.
Der sichtbarste Baustein ist bidirektionales Laden. OCPP 2.1 kann Entlade-Setpoints und bidirektionale Ladeprofile Richtung Ladepunkt steuern, während ISO 15118-20 die Aushandlung zwischen Fahrzeug und Ladepunkt übernimmt. Erst dieses Zusammenspiel macht V2G als durchgängige Kette vom Backend bis ins Fahrzeug steuerbar, inklusive Plug&Charge auf Basis von ISO 15118-20.
Zweiter Schwerpunkt ist die Integration von DER, also dezentralen Energieressourcen. Ladepunkte und Standorte werden als steuerbare Ressourcen im Zusammenspiel mit Erzeugung, Speichern und Netzanforderungen behandelt. Für Betreiber mit PV, Batteriespeicher oder netzdienlichen Verpflichtungen wird das Protokoll damit deutlich näher an die Energieseite gerückt, die bisher oft in proprietären Nebensystemen gelöst wurde.
Dritter Schwerpunkt ist der Offline-Betrieb. OCPP 2.1 definiert das Verhalten von Transaktionen bei gestörter Backend-Verbindung robuster, inklusive geordneter Nachsynchronisation. Dazu kommt die Integration von Payment-Terminals für Ad-hoc-Zahlung, was direkt auf die AFIR-Anforderungen einzahlt, die seit 2024 für öffentliche Ladeinfrastruktur gelten.
- Bidirektionales Laden (V2G) im Zusammenspiel mit ISO 15118-20.
- DER-Steuerung für Erzeuger, Speicher und steuerbare Lasten am Standort.
- Robustere Offline-Transaktionen mit definierter Nachsynchronisation.
- Payment-Terminal-Integration für Ad-hoc-Zahlung im Sinne der AFIR.
- Erweiterte Tarif- und Kosteninformationen Richtung Fahrer.
Für den OCPP-1.6-Bestand führt der Weg über 2.0.1.
Wer heute eine 1.6-Flotte betreibt, kann nicht direkt auf 2.1 springen. OCPP 1.6 und 2.0.1 sind nicht kompatibel, und 2.1 setzt die 2.0.1-Basis voraus. Konkret heißt das: Die Firmware der Ladepunkte muss 2.0.1 oder 2.1 nativ unterstützen, das Backend muss das neue Transaktionsmodell mit TransactionEvent verarbeiten, und Zertifikats- und Security-Prozesse müssen auf die neuen Profile umgestellt werden.
Damit wird die 2.1-Frage für Bestandsbetreiber zuerst zur Hardware- und Firmware-Frage. Ein Teil der 1.6-Geräte im Feld wird nie ein 2.0.1-Update erhalten. Für diese Ladepunkte ist die ehrliche Antwort: Sie laufen auf 1.6 weiter, solange sie ihren Zweck erfüllen, und werden beim regulären Hardware-Tausch ersetzt, nicht vorher zwangsmigriert.
In der Praxis entstehen dadurch über Jahre gemischte Flotten aus 1.6, 2.0.1 und 2.1. Das ist kein Planungsfehler, sondern der Normalfall. Entscheidend ist, dass neue Beschaffungen den Pfad nicht weiter verlängern und dass die zentrale Architektur mit dieser Mischung umgehen kann, ohne für jede Version eigene Sonderprozesse zu pflegen.
Eine sinnvolle Adoptionsstrategie ist anlassgetrieben, nicht versionsgetrieben.
Ein Umstieg nur wegen der Versionsnummer lohnt sich selten. Tragfähige Anlässe kommen aus drei Richtungen: regulatorisch, weil AFIR seit 2024 Datenbereitstellung und Ad-hoc-Zahlung verlangt und neue öffentliche AC-Ladepunkte in der EU seit Januar 2026 ISO-15118-fähig sein müssen; geschäftlich, weil V2G- und Flexibilitätsanwendungen ohne 2.1 und ISO 15118-20 nicht sauber abbildbar sind; und betrieblich, weil robusteres Offline-Verhalten reale Supportkosten senkt.
Daraus ergibt sich eine klare Reihenfolge: Neue Standorte und Ausschreibungen sollten OCPP 2.0.1 verpflichtend und 2.1-Fähigkeit als Kriterium führen. Die Backend- oder Broker-Seite kann früh auf 2.1 gehoben werden, weil die Abwärtskompatibilität zu 2.0.1 dieses Upgrade risikoarm macht. Der 1.6-Bestand wird dagegen nur bei echtem Anlass angefasst, etwa bei Hardware-Erneuerung, Security-Anforderungen oder konkreten neuen Funktionen.
- Neue Ausschreibungen: OCPP 2.0.1 verpflichtend, 2.1-Fähigkeit als Bewertungskriterium.
- Zentrale Systeme früh auf 2.1 heben, da abwärtskompatibel zu 2.0.1.
- ISO-15118-Fähigkeit bei neuen öffentlichen AC-Ladepunkten seit Januar 2026 einplanen.
- 1.6-Bestand nur bei echtem Anlass migrieren, nicht flächendeckend.
- V2G- und DER-Anwendungsfälle zuerst an einzelnen Standorten pilotieren.
Ein OCPP Broker puffert zwischen Bestand und Zielbild.
Die eigentliche Herausforderung der nächsten Jahre ist nicht OCPP 2.1 selbst, sondern der Parallelbetrieb mehrerer Protokollwelten. Ein OCPP Broker nimmt die Verbindungen aller Ladepunkte entgegen, egal ob 1.6, 2.0.1 oder 2.1, normalisiert die Unterschiede und stellt nachgelagerten Systemen ein konsistentes Modell bereit. Das zentrale CPMS muss dann nicht jeden Dialekt gleichzeitig beherrschen.
Besonders wertvoll ist diese Pufferschicht bei der schrittweisen Einführung: Ladepunkte bleiben verbunden, während das Backend auf 2.1 gehoben wird. Neue 2.1-Funktionen wie DER-Steuerung oder bidirektionale Profile lassen sich zuerst gegen einzelne Standorte testen, während der Rest der Flotte unverändert weiterläuft. Nachrichten können gespiegelt, gefiltert und vollständig protokolliert werden, sodass jede Migrationsphase auditierbar bleibt.
Für genau diese Übergangsphasen ist eine Broker-Schicht mit modularen CPMS-Bausteinen das passende Werkzeug: gemischte Flotten stabil betreiben, den 2.0.1-Pfad geordnet gehen und 2.1-Funktionen dann aktivieren, wenn der Anwendungsfall sie wirklich braucht.