Die Protokollreferenz für OCPP 2.0.1 und 2.1.
Alle 91 Nachrichten von OCPP 2.0.1 und 2.1 mit ihren Feldern und einem Beispiel, welche davon 2.1 ergänzt hat, das Gerätemodell, das die Konfigurationsschlüssel von 1.6 abgelöst hat, und die drei Sicherheitsprofile.
NachrichtenGerätemodellSicherheitsprofileUmstieg von 1.6Fragen
Was sind OCPP 2.0.1 und 2.1?
Sie sind die neueren Versionen des Open Charge Point Protocol, des offenen Standards der Open Charge Alliance dafür, wie eine Ladestation mit der Software spricht, die sie verwaltet: in der Spezifikation das CSMS, im Markt das Backoffice. Wie bei 1.6J öffnet die Ladestation einen WebSocket zum Backoffice, und beide Seiten senden darüber JSON-Nachrichten.
OCPP 2.0.1 ist nicht abwärtskompatibel mit 1.6. Es beschreibt eine Ladestation als Gerätemodell aus Komponenten und Variablen, hat drei Sicherheitsprofile eingebaut, meldet eine Transaktion in einer einzigen Nachricht, TransactionEvent, und unterstützt ISO 15118 für Plug and Charge und für intelligentes Laden mit Vorgaben des Autos.
OCPP 2.1 baut auf 2.0.1 auf. Seine Schemas sind die Schemas von 2.0.1 mit zusätzlichen optionalen Feldern, und es ergänzt 27 Nachrichten für bidirektionales Laden, DER-Steuerung, Tarife auf einer Ladestation, die die Kosten selbst berechnet, Bezahlung an der Ladestation, periodische Event-Streams und Batteriewechsel. Eine Ladestation und ihr Backoffice einigen sich beim Öffnen des WebSockets auf eine Version.
- Ein offener StandardFrei implementierbar, gepflegt von der Open Charge Alliance. OCPP 2.1 ist auch als IEC 63584-210 veröffentlicht.
- WebSocket und JSONEine Verbindung, die die Ladestation offen hält. 2.1 ergänzt SEND, eine Nachricht, auf die keine Antwort kommt.
- 91 Nachrichten64 in 2.0.1 und 27 weitere in 2.1, in 19 Funktionsblöcken.
- Beide RichtungenDie Ladestation und das Backoffice starten jeweils eigene Nachrichten.
Alle 91 Nachrichten von OCPP 2.0.1 und 2.1
Jede Nachricht ist eine Anfrage der einen Seite und eine Antwort der anderen, einander zugeordnet über eine Nachrichten-ID. NotifyPeriodicEventStream ist die einzige Ausnahme: eine SEND-Nachricht in 2.1, auf die keine Antwort kommt.
Sicherheit
Zertifikate für die Ladestation und das Backoffice und die Sicherheitsereignisse, die eine Ladestation meldet.
Bereitstellung
Hochfahren, Anmelden beim Backoffice, Lesen und Setzen des Gerätemodells und Resets.
Autorisierung
Prüfen eines ID-Tokens vor dem Laden, der Autorisierungs-Cache und in 2.1 die Ad-hoc-Bezahlung.
Lokale Autorisierungsliste
Die Liste der ID-Tokens, die das Backoffice auf der Ladestation speichert, damit sie selbst autorisieren kann.
Transaktionen
Eine Nachricht, TransactionEvent, für den Beginn, die Aktualisierungen und das Ende jeder Transaktion.
Fernsteuerung
Starten und Beenden einer Transaktion aus dem Backoffice, Entriegeln eines Ladepunkts und Auslösen einer Nachricht.
Verfügbarkeit
Der Status jedes Ladepunkts, der Heartbeat und das Außerbetriebnehmen einer Ladestation oder EVSE.
Reservierung
Reservieren einer EVSE für ein ID-Token und Stornieren dieser Reservierung.
Tarif und Kosten
Preise und laufende Kosten für den Fahrer; in 2.1 auch Tarife auf einer Ladestation, die die Kosten selbst berechnet.
Zählerwerte
Zählerstände außerhalb einer Transaktion; während einer Transaktion laufen sie über TransactionEvent.
Intelligentes Laden
Ladeprofile mit Leistungs- oder Stromgrenzen, Grenzwerte von außen und der Bedarf des Fahrzeugs.
Firmware-Management
Aktualisieren der Firmware auf einer Ladestation und Veröffentlichen über einen lokalen Controller.
Zertifikatsverwaltung
Installieren und Prüfen von Zertifikaten, einschließlich der Vertragszertifikate für Plug and Charge.
Diagnose
Logs, Monitore im Gerätemodell, Ereignisse, Kundendaten und in 2.1 periodische Event-Streams.
Display-Nachrichten
Nachrichten, die das Backoffice für eine Ladestation festlegt, um sie Fahrern anzuzeigen.
Datenübertragung
Herstellerdaten, für Funktionen, die der Standard nicht abdeckt.
Bidirektionale Energieübertragung
Neu in 2.1: Steuerung von Laden und Entladen (V2X) über Ladeprofile.
DER-Steuerung
Neu in 2.1: Einstellungen zur Netzstützung für eine Ladestation und ein Auto, die als dezentrale Energieanlage arbeiten.
Batteriewechsel
Neu in 2.1: Batteriewechselstationen.
Keine Nachricht passt zu dieser Suche.
Das Gerätemodell von OCPP 2.0.1
In OCPP 1.6 hat eine Ladestation eine flache Liste von Konfigurationsschlüsseln. In 2.0.1 und 2.1 beschreibt sie sich als Komponenten, etwa die Ladestation, eine EVSE, ein Ladepunkt oder ein Controller wie OCPPCommCtrlr, und jede Komponente hat Variablen. Eine Variable kann vier Werte haben: Actual, Target, MinSet und MaxSet. Was früher ein Konfigurationsschlüssel war, ist jetzt eine Variable einer Controller-Komponente.
So arbeiten Sie damit
- GetVariables und SetVariablesLesen oder setzen Sie mehrere Variablen in einer Nachricht. Die Ladestation antwortet für jede Variable einzeln.
- GetBaseReport und GetReportFordern Sie das ganze Gerätemodell oder einen Teil davon an. Die Ladestation sendet es in NotifyReport-Nachrichten zurück.
- MonitoreSetVariableMonitoring überwacht eine Variable auf einen Schwellenwert, eine Änderung oder ein festes Intervall, und die Ladestation meldet über NotifyEvent.
- Enabled, pro FunktionDer Controller einer optionalen Funktion, etwa AuthCacheCtrlr oder ReservationCtrlr, hat eine Variable Enabled, die diese Funktion ein- oder ausschaltet.
Die Antworten auf SetVariables
- Accepted
- Der Wert ist gesetzt.
- Rejected
- Die Variable existiert, aber der Wert wurde abgelehnt.
- Unknown
Component - Die Ladestation hat keine solche Komponente.
- Unknown
Variable - Die Komponente hat keine solche Variable.
- NotSupported
AttributeType - Die Variable hat keinen Wert dieses Typs, zum Beispiel kein Target.
- RebootRequired
- Der Wert ist gespeichert und gilt nach einem Neustart.
Variablen, die die bekanntesten Schlüssel von 1.6 abgelöst haben
Die Spezifikation standardisiert viele weitere, aufgeführt in ihren Anhängen. Eine Ladestation meldet die, die sie hat, als Antwort auf GetBaseReport.
| Komponente und Variable | Typ | Was sie festlegt | In OCPP 1.6 |
|---|---|---|---|
| OCPPCommCtrlr | integer in Sekunden | Sekunden ohne andere Nachrichten, nach denen die Ladestation einen Heartbeat sendet. | Heartbeat |
| OCPPCommCtrlr | integer | Wie oft die Ladestation versucht, ein TransactionEvent zuzustellen, das das Backoffice nicht verarbeiten konnte. | Transaction |
| OCPPCommCtrlr | integer | Sekunden, die die Ladestation vor einem neuen Versuch wartet. | Transaction |
| OCPPCommCtrlr | integer in Sekunden | Sekunden zwischen WebSocket-Pings; 0 schaltet die eigenen Pings der Ladestation ab. | Web |
| OCPPCommCtrlr | integer | Wie oft die Ladestation einen fehlgeschlagenen Reset wiederholt. | Reset |
| OCPPCommCtrlr | boolean | Das Kabel an der Ladestation entriegeln, wenn es am Auto ausgesteckt wird. | Unlock |
| SampledDataCtrlr | Liste | Was die Ladestation während einer Transaktion misst, gesendet in TransactionEvent mit eventType Updated. | Meter |
| SampledDataCtrlr | integer in Sekunden | Sekunden zwischen diesen Messungen; bei 0 werden während der Transaktion keine gesendet. | Meter |
| SampledDataCtrlr | Liste | Was in das TransactionEvent kommt, das die Transaktion beendet. | Stop |
| AlignedDataCtrlr | integer in Sekunden | Sekunden zwischen uhrzeitsynchronen Messungen. | Clock |
| AlignedDataCtrlr | Liste | Was die uhrzeitsynchronen Messungen enthalten. | Meter |
| AlignedDataCtrlr | Liste | Uhrzeitsynchrone Messungen, die in das TransactionEvent kommen, das die Transaktion beendet. | Stop |
| TxCtrlr | integer in Sekunden | Sekunden, die ein Fahrer nach Beginn der Transaktion zum Einstecken hat, bevor sie abgebrochen wird. | Connection |
| TxCtrlr | boolean | Die Transaktion beenden, wenn das Kabel am Auto ausgesteckt wird. | Stop |
| TxCtrlr | boolean | Eine laufende Transaktion beenden, wenn sich herausstellt, dass ihr ID-Token nicht angenommen wird. | Stop |
| TxCtrlr | integer | Energie in Wh, die die Ladestation noch liefern darf, nachdem das Backoffice das ID-Token abgelehnt hat. | Max |
| TxCtrlr | Liste | Wann eine Transaktion beginnt: bei der Autorisierung, beim Einstecken, wenn Energie fließt und so weiter. | Neu in 2.0.1 |
| TxCtrlr | Liste | Wann eine Transaktion endet, gewählt aus derselben Liste. | Neu in 2.0.1 |
| AuthCtrlr | boolean | Ob die Ladestation das ID-Token eines Fernstarts zuerst mit einem Authorize prüft. | Authorize |
| AuthCtrlr | boolean | Offline Transaktionen für ID-Tokens starten, die sie schon kennt. | Local |
| AuthCtrlr | boolean | Für ID-Tokens, die sie schon kennt, starten, ohne auf das Backoffice zu warten. | Local |
| AuthCtrlr | boolean | Offline Transaktionen für unbekannte ID-Tokens starten. | Allow |
| AuthCacheCtrlr | boolean | Den Autorisierungs-Cache nutzen. | Authorization |
| LocalAuthListCtrlr | boolean | Die lokale Autorisierungsliste nutzen. | Local |
| LocalAuthListCtrlr | integer | Höchstzahl der ID-Tokens in einer SendLocalList. | Send |
| SmartChargingCtrlr | integer | Höchstes Stack-Level, das ein Ladeprofil haben darf. | Charge |
| SmartChargingCtrlr | Liste | Ob Pläne in Ampere, in Watt oder in beiden angegeben werden können. | Charging |
| SmartChargingCtrlr | integer | Höchstzahl der Zeitabschnitte in einem Ladeplan. | Charging |
| SmartChargingCtrlr | boolean | Ob die Ladestation während einer Transaktion von drei Phasen auf eine umschalten kann. | Connector |
| ReservationCtrlr | boolean | Ob eine Reservierung für die Ladestation als Ganzes statt für eine EVSE gelten kann. | Reserve |
Keine Variable passt zu dieser Suche.
Sicherheitsprofile von OCPP 2.0.1 und 2.1
Beide Versionen definieren drei Sicherheitsprofile. Eine Ladestation und ihr Backoffice nutzen jeweils eines, und es wird vor der ersten OCPP-Nachricht festgelegt. Das Backoffice setzt es pro Verbindungsslot mit SetNetworkProfile, und die Ladestation meldet das genutzte in SecurityCtrlr.SecurityProfile.
| Profil | Wie sich die Ladestation ausweist | Wie sich das Backoffice ausweist | Die Verbindung |
|---|---|---|---|
| 1. Ungesicherter Transport mit Basic Authentication | HTTP Basic Authentication, mit einem Passwort | Gar nicht | Nicht verschlüsselt. Nur für vertrauenswürdige Netze, etwa ein VPN zwischen der Ladestation und dem Backoffice. |
| 2. TLS mit Basic Authentication | HTTP Basic Authentication, mit einem Passwort | Mit seinem TLS-Serverzertifikat | TLS 1.2 oder höher |
| 3. TLS mit clientseitigen Zertifikaten | Mit ihrem eigenen TLS-Clientzertifikat | Mit seinem TLS-Serverzertifikat | TLS 1.2 oder höher |
- HerabstufenEine Ladestation darf nur von Profil 3 auf Profil 2 wechseln, und nur wenn AllowSecurityProfileDowngrade auf true steht. Auf Profil 1 stuft sie über OCPP nie herab.
- Passwörter und ZertifikateDas Passwort ist SecurityCtrlr.BasicAuthPassword. Die Ladestation fordert mit SignCertificate ein neues Zertifikat an, und das Backoffice liefert es mit CertificateSigned.
- SicherheitsereignisseDie Ladestation meldet mit SecurityEventNotification, was passiert ist, etwa einen Reset, ein Firmware-Update oder Zugangsdaten, die das Backoffice abgelehnt hat.
Von OCPP 1.6 zu 2.0.1, Nachricht für Nachricht
OCPP 2.0.1 hat viele Nachrichtennamen von 1.6 behalten und andere umbenannt oder zusammengelegt. Ein Link öffnet die Nachricht in dieser Referenz oder in der Referenz zu 1.6J.
| OCPP 1.6 | OCPP 2.0.1 und 2.1 | Was sich geändert hat |
|---|---|---|
| StartTransaction, StopTransaction | TransactionEvent | Eine Nachricht mit eventType Started, Updated oder Ended. Die Ladestation vergibt die Transaktions-ID, einen String. |
| MeterValues | TransactionEvent, MeterValues | Messungen während einer Transaktion kommen in TransactionEvent; MeterValues überträgt Messungen außerhalb einer Transaktion. |
| StatusNotification | StatusNotification, NotifyEvent | StatusNotification meldet nur noch den Status des Ladepunkts, mit evseId und connectorId. Fehlercodes kommen in NotifyEvent, und 2.1 bevorzugt NotifyEvent auch für die Verfügbarkeit. |
| RemoteStartTransaction | RequestStartTransaction | Überträgt ein idToken-Objekt und eine remoteStartId, die im TransactionEvent zurückkommt, das die Transaktion startet. |
| RemoteStopTransaction | RequestStopTransaction | Beendet eine Transaktion über ihre ID, die jetzt ein String ist. |
| ChangeConfiguration | SetVariables | Setzt mehrere Variablen des Gerätemodells in einer Nachricht. |
| GetConfiguration | GetVariables, GetBaseReport, GetReport | Liest ausgewählte Variablen oder fordert einen Bericht an, der in NotifyReport-Nachrichten ankommt. |
| GetDiagnostics | GetLog | Fordert ein Diagnose- oder ein Sicherheitslog an. |
| DiagnosticsStatusNotification | LogStatusNotification | Meldet den Fortschritt dieses Uploads. |
| Reset | Reset | Immediate oder OnIdle statt Hard oder Soft, und es kann eine einzelne EVSE zurücksetzen. |
| ChangeAvailability | ChangeAvailability | Richtet sich über sein Feld evse an die Ladestation, eine EVSE oder einen Ladepunkt. |
| Authorize | Authorize | Ein idToken-Objekt mit einem Typ statt des Strings idTag. |
| BootNotification | BootNotification | Ergänzt den Grund für den Start; die Angaben zur Ladestation stehen in einem Objekt chargingStation. |
| Heartbeat, UnlockConnector, ClearCache, DataTransfer, ReserveNow, CancelReservation, SendLocalList, GetLocalListVersion, SetChargingProfile, ClearChargingProfile, GetCompositeSchedule, TriggerMessage, UpdateFirmware, FirmwareStatusNotification | Dieselben Namen | Dieselben Nachrichten, mit Feldern für EVSEs und den neueren Datentypen. |
Fragen zu OCPP 2.0.1 und 2.1
Version 2.0.1 des Open Charge Point Protocol, 2020 von der Open Charge Alliance veröffentlicht. Sie hat OCPP 2.0 abgelöst und ergänzt gegenüber 1.6 das Gerätemodell, Sicherheitsprofile, die Unterstützung von ISO 15118 und TransactionEvent. Sie ist nicht abwärtskompatibel mit 1.6.
OCPP 2.1 wurde im Januar 2025 veröffentlicht und ist auch die Norm IEC 63584-210. Es ergänzt 27 Nachrichten und entfernt keine: bidirektionales Laden (V2X) und DER-Steuerung, ISO 15118-20, Tarife auf einer Ladestation, die die Kosten selbst berechnet, Bezahlung an der Ladestation mit Kartenterminal oder QR-Code, Prioritätsladen, dynamische Ladeprofile, periodische Event-Streams und Batteriewechsel. Wählen Sie über den Nachrichten Neu in 2.1, um sie zu sehen.
Die Schemas von 2.1 sind die Schemas von 2.0.1 mit zusätzlichen optionalen Feldern, und laut der Open Charge Alliance funktioniert Logik, die für 2.0.1 geschrieben wurde, mit zwei kleinen Änderungen weiter: SignCertificate kann eine requestId enthalten, die CertificateSigned dann wiederholt, und NotifyMonitoringReport hat ein neues Pflichtfeld. Die Version wird weiterhin pro Verbindung vereinbart: Im WebSocket-Handshake bietet die Ladestation zum Beispiel ocpp2.1, ocpp2.0.1 und ocpp1.6 an, und das Backoffice wählt eine aus.
2.0.1 hat eigene Nachrichten: ein Gerätemodell statt Konfigurationsschlüsseln, Sicherheitsprofile, TransactionEvent statt StartTransaction und StopTransaction, die EVSE als Ebene zwischen der Ladestation und ihren Ladepunkten und Nachrichten für ISO 15118. Eine Ladestation und ihr Backoffice einigen sich beim Aufbau der Verbindung auf eine Version. Die Tabelle oben stellt die Nachrichten einander gegenüber, und die OCPP-1.6J-Referenz enthält jede Nachricht von 1.6.
Nach dem Erscheinen von OCPP 2.0 traten Probleme auf, die sich nur durch Änderungen an den Nachrichtenschemas beheben ließen, und denen konnte eine Implementierung von 2.0 nicht folgen. Die Open Charge Alliance gab der korrigierten Version eine eigene Nummer, 2.0.1, und empfiehlt, nur 2.0.1 zu implementieren. In der Spezifikation bedeutet OCPP 2.0 die Version 2.0.1, sofern nicht anders angegeben.
Die Open Charge Alliance veröffentlicht beide kostenlos auf ihrer Website, mit einem JSON-Schema für jede Nachricht und einer Errata-Liste. Diese Referenz folgt den JSON-Schemas und Teil 2 der Spezifikation. Wo beide voneinander abweichen, gelten die Spezifikation und ihre Errata.
Sehen Sie in der Ladestationsdatenbank nach: Dort nennen 102 Ladestationen OCPP 2.0.1 und 4 nennen 2.1. Meist steht es auch im Datenblatt. Eine Ladestation, die mehrere Versionen unterstützt, bietet beim Verbinden alle an, und das Backoffice wählt eine aus.
OCPP 1.6J mit Plugchoice
Plugchoice verbindet heute OCPP-1.6J-Ladestationen, abhängig von Modell, Firmware und Konfiguration.