OCPP 1.6J vs. 2.0.1 vs. 2.1: Unterschiede und Migrationsleitfaden

Wer heute Ladestationen kauft oder eine Ladesoftware auswählt, findet in den Datenblättern drei OCPP-Versionen: 1.6J, 2.0.1 und 2.1. Sie tragen denselben Namen und verfolgen denselben Zweck, sind aber nicht dasselbe Protokoll – und die Unterschiede wirken sich auf Sicherheit, Funktionsumfang und die Skalierbarkeit Ihres Netzes aus.

Dieser Beitrag vergleicht OCPP 1.6J vs. 2.0.1 vs. 2.1 aus praktischer Sicht. Er erklärt, was sich zwischen den Versionen geändert hat, wie Sie ein gemischtes Netz betreiben, wie Sie eine Migration planen und was Sie in Ihre Anforderungen schreiben sollten, wenn Sie jetzt Ladestationen beschaffen.

Eine kurze Geschichte der drei Versionen

Alle OCPP-Versionen werden von der Open Charge Alliance (OCA) veröffentlicht. OCPP 1.6 erschien 2015 in zwei Varianten: 1.6S auf Basis von SOAP und 1.6J mit JSON über WebSocket. Die SOAP-Variante spielt heute kaum noch eine Rolle, daher ist mit „OCPP 1.6“ in der Praxis meist 1.6J gemeint.

2018 folgte OCPP 2.0. Die darin enthaltenen Fehler wurden mit OCPP 2.0.1 behoben, das 2020 erschien – und 2.0.1 ist die Fassung, die die Branche umsetzt. OCPP 2.0.1 wurde 2024 zudem als internationale Norm IEC 63584 angenommen.

OCPP 2.1 wurde im Januar 2025 von der OCA veröffentlicht und später von der IEC als IEC 63584-210 herausgegeben. Es ist eine Weiterentwicklung von 2.0.1 und keine Neukonzeption.

OCPP 1.6J: die bewährte Basis

OCPP 1.6J deckt alles ab, was ein typisches Ladenetz im Tagesbetrieb braucht. Eine Ladestation meldet sich per BootNotification an, bleibt per Heartbeat sichtbar, meldet Ladepunktzustände per StatusNotification und erfasst Ladevorgänge mit StartTransaction, StopTransaction und MeterValues. Das CSMS kann Befehle wie RemoteStartTransaction, RemoteStopTransaction, Reset, UnlockConnector, ChangeAvailability und ChangeConfiguration senden.

Version 1.6 enthält außerdem Smart Charging über Ladeprofile (ChargePointMaxProfile, TxDefaultProfile und TxProfile), Offline-Autorisierung mit lokaler Liste und Cache, Reservierungen sowie Firmware-Updates.

Die größten Schwächen liegen bei Sicherheit und Struktur. Sicherheitsprofile kamen erst später über die Security-Erweiterung der OCA hinzu, weshalb die Unterstützung von Hersteller zu Hersteller variiert. Die Konfiguration ist eine flache Liste von Schlüsseln, und viele Hersteller ergänzen eigene Schlüssel oder nutzen DataTransfer für herstellerspezifische Funktionen – das schränkt die Interoperabilität ein.

OCPP 2.0.1: Neukonzeption für Sicherheit und Skalierung

OCPP 2.0.1 behält das Grundprinzip bei – eine Verbindung per JSON über WebSocket zwischen Ladestation und CSMS –, ändert aber viele Nachrichten. Die wichtigsten Neuerungen:

• TransactionEvent: Eine einzige Nachricht mit den Ereignistypen Started, Updated und Ended ersetzt StartTransaction, StopTransaction und die transaktionsbezogenen MeterValues. Das macht die Verarbeitung von Ladevorgängen konsistenter.
• Gerätemodell (Device Model): Die Ladestation wird über Komponenten und Variablen beschrieben. Das CSMS liest und schreibt diese mit GetVariables und SetVariables statt über flache Konfigurationsschlüssel.
• RequestStartTransaction und RequestStopTransaction: Sie ersetzen die Befehle für Remote-Start und -Stopp aus 1.6.
• Integrierte Sicherheit: Sicherheitsprofile, Zertifikatsverwaltung und Benachrichtigungen über Sicherheitsereignisse sind Teil der Kernspezifikation.
• Besseres Smart Charging und Unterstützung für ISO 15118: Die Ladestation kann Informationen des Fahrzeugs weitergeben, was präzisere Ladepläne und Plug & Charge ermöglicht.
• Display-Nachrichten und Diagnose: Das CSMS kann Nachrichten auf dem Display der Ladestation anzeigen, und die Fehlermeldungen sind detaillierter.

Da sich die Nachrichten unterscheiden, kann eine 2.0.1-Ladestation nicht mit einem CSMS kommunizieren, das nur 1.6 versteht – und umgekehrt ebenso wenig.

OCPP 2.1: neue Anwendungsfälle rund um Energie

OCPP 2.1 ist abwärtskompatibel zu 2.0.1. Ein System, das 2.0.1 bereits umsetzt, benötigt Erweiterungen, aber keine Neuentwicklung. Die neuen Funktionen betreffen die Rolle des Ladens im Energiesystem insgesamt sowie das Bezahlen:

• Bidirektionales Laden (V2X), damit ein Fahrzeug Energie an ein Gebäude oder ins Netz zurückspeisen kann.
• Steuerung dezentraler Energieanlagen (DER).
• Lokale Kostenberechnung und Tarife direkt an der Ladestation.
• Unterstützung für Bezahlterminals und Ad-hoc-Zahlung.
• Batteriewechsel sowie Verbesserungen für ISO 15118-20.

Viele dieser Funktionen hängen von Hardware, Fahrzeugen und lokaler Regulierung ab. Für die meisten Betreiber liegt der praktische Nutzen von 2.1 heute darin, dass es die zukunftssicherste Option ist.

Vergleichstabelle: OCPP 1.6J vs. 2.0.1 vs. 2.1

Ein gemischtes Netz aus Ladestationen betreiben

Die meisten realen Netze sind gemischt. Ältere Ladestationen laufen mit 1.6J, neuere Modelle werden mit 2.0.1 ausgeliefert, und manche Hersteller bieten Firmware an, die beides unterstützt. Das ist normal und muss kein Problem sein – sofern Ihr CSMS jede Version korrekt verarbeitet.

Prüfen Sie bei einem gemischten Netz folgende Punkte:

• Das CSMS sollte die Version beim WebSocket-Handshake erkennen und alle Ladestationen in einem Dashboard anzeigen – mit einheitlichen Statusbezeichnungen und Berichten.
• Ladedaten aus 1.6-Transaktionen und 2.0.1-TransactionEvents sollten in derselben Ladehistorie und denselben Berichten landen.
• Fernbefehle sollten für jede Version in die richtige Nachricht übersetzt werden, zum Beispiel beim Remote-Stopp.
• Die Nachrichtenprotokolle sollten die Rohnachrichten anzeigen, damit Sie versionsspezifisches Verhalten analysieren können.

Üreticy wurde genau für diese Situation entwickelt. Ladestationen mit OCPP 1.6J, 2.0.1 und 2.1 verbinden sich mit demselben Dashboard, wobei 2.1-Ladestationen den gemeinsamen Kern-Nachrichtensatz mit 2.0.1 nutzen. Ladevorgänge, Berichte und Fernbefehle funktionieren für den Betreiber unabhängig von der Version gleich. Details finden Sie auf der Seite zur OCPP-Software von Üreticy.

Tipps zur Migration

Funktionierende 1.6J-Ladestationen müssen Sie nicht austauschen, nur weil es eine neuere Version gibt. Ein sinnvolles Vorgehen sieht so aus:

1. Hardware inventarisieren. Erfassen Sie für jede Ladestation Modell, Firmware-Version und ob der Hersteller eine 2.0.1-Firmware anbietet.
2. Bestand absichern. Stellen Sie 1.6J-Ladestationen, die die Security-Erweiterung unterstützen, von unverschlüsseltem ws:// auf wss:// mit TLS um.
3. Vor dem Upgrade testen. Aktualisieren Sie pro Modell eine Ladestation auf 2.0.1-Firmware, verbinden Sie sie und prüfen Sie Boot, Autorisierung, Ladevorgänge und Fernbefehle.
4. Gruppenweise umstellen. Wechseln Sie die Protokollversion pro Standort oder Modell und behalten Sie dieselben Charge-Point-IDs bei, damit die Historie erhalten bleibt.
5. Neue Hardware mit 2.0.1 oder 2.1 kaufen. So entwickelt sich das Netz mit jedem neuen Standort ganz natürlich weiter.

Was Sie heute beim Kauf von Ladestationen fordern sollten

Nehmen Sie folgende Anforderungen in Ihre Ausschreibung oder Bestellung auf:

• Unterstützung von OCPP 2.0.1 bereits heute und ein verbindlicher Plan für 2.1, zusätzlich OCPP 1.6J für die Kompatibilität mit bestehenden Systemen.
• TLS-Unterstützung (mindestens Sicherheitsprofil 2; Profil 3, wenn Sie Zertifikate verwalten).
• OCA-Zertifizierung oder dokumentierte Ergebnisse von Interoperabilitätstests.
• Firmware-Updates des Herstellers über die erwartete Lebensdauer des Produkts.
• Keine Abhängigkeit von der Hersteller-Cloud für Grundfunktionen.

Falls Sie noch eine Software auswählen: Unsere Checkliste zur Auswahl einer OCPP-Software zeigt, wie Sie ein CSMS anhand dieser Punkte bewerten.

Häufig gestellte Fragen

Betreiben Sie Ladestationen mit 1.6J, 2.0.1 und 2.1 parallel in einem Dashboard. Entdecken Sie die OCPP-Software von Üreticy oder werfen Sie einen Blick auf die Preise pro Ladepunkt.