OCPP Protokoll Version 2 für E-Mobility

Die Elektromobilität wächst so schnell, dass wir sagen können, dass sie weltweit zum neuen Mobilitätsstandard wird.

Dies ist nur mit einer umfangreichen Infrastruktur möglich, die einer guten Abdeckung der Ladestationen entspricht. Um die Einführung der Ladeinfrastruktur voranzutreiben, spielen offene Kommunikationsstandards eine Schlüsselrolle. Sie ermöglichen bidirektionale Stromflüsse, Informationsaustausch in Echtzeit, Nachfragesteuerung und eMobility-Dienste.

Das Open Charge Point Protocol (OCPP) ist einer der von der Industrie unterstützten Standards für die Kommunikation zwischen einer Ladestation / Elektrofahrzeugversorgungsausrüstung (EVSE) und einer Ladestationsverwaltung System (CSMS). Es ist ein offener Standard ohne Kosten- oder Lizenzbarrieren für die Annahme. Mit jeder nächsten Version ab 1.2 wird OCPP immer weiter fortgeschritten. Heute kann es in verschiedenen verwendet werden Architekturen für verschiedene Ladestationen.

Im April 2018 veröffentlichte die Open Charge Alliance eine neue Version 2.0 des OCPP. Diese Version löst viele lästige Probleme ab Version 1.6 und bietet viele neue coole Funktionen implementieren und verwenden.

Figure 1. OCPP-Platzierung in der EV-Ladelandschaft

Figure 2. Fluss Diagramm

Agenda

• Was ist neu in OCPP 2.0?

• Use Cases

• OCPP Server

Was ist neu in OCPP 2.0?

OCPP 2.0 führt im Vergleich zu OCPP 1.6 neue Funktionen ein. Aufgrund von Verbesserungen und neuen Funktionen ist OCPP 2.0 nicht abwärtskompatibel mit OCPP 1.6 Mal sehen, was das bringt …​

Device Management

Die Geräteverwaltung (Gerätemodell) wird besonders von CSOs begrüßt, die ein Netzwerk von Ladestationen verwalten. Es bietet die folgenden Features:

• Bestandsberichterstattung

• Verbesserte Fehler- und Statusberichterstattung

• Verbesserte Konfiguration

• Überwachung

Transaktionsverbesserungen

Die Abwicklung einer großen Anzahl von Transaktionen - insbesondere in großen Netzwerken - besteht aus mehr als 100 Ladestationen

• Die Nachrichten StartTransaction, StopTransaction, MeterValue und StatusNotification werden durch TransactionEvent ersetzt

• Datenreduktion - Unterstützung für WebSocket Compression

Verbesserte Sicherheit

• Sicherheitsprofile (3 Ebenen) für Ladestation, CSMS-Authentifizierung und Kommunikationssicherheit hinzugefügt

• Schlüsselverwaltung für clientseitige Zertifikate

• Sichere Firmware-Updates

• Sicherheitsereignisprotokoll

Erweitertes intelligentes Laden

In OCPP 2.0 wurde die Smart Charging-Funktionalität erweitert

• Direkte intelligente Ladeeingaben von einem Energiemanagementsystem (EMS) zu einer Ladestation

• Verbessertes intelligentes Laden mit einem lokalen Controller

• Unterstützung für integriertes intelligentes Laden von CSMS, Ladestation und Elektrofahrzeug ([ISO15118-1]).

Support für ISO 15118

Der ISO 15118-Standard [ISO15118-1] ist ein neueres Protokoll für die Kommunikation von EVSE zu EV. verglichen mit IEC 61851 [IEC61851-1]. ISO 15118 ermöglicht viele neue Funktionen und ist sicherer Kommunikation zwischen EVSE und EV. Von ISO 15118 unterstützte Funktionen hinzugefügt:

• Plug & Charge

• Intelligentes Laden einschließlich Eingabe vom Elektrofahrzeug

Verbesserungen und Kundenerlebnis

• Weitere Autorisierungsoptionen: Plug & Charge [ISO15118-1], Zahlungsterminals, lokaler mechanischer Schlüssel, Smartphones usw.

• Anzeigen von Nachrichten (transaktionsbezogen / global) auf einer Ladestation, die EV-Fahrern angezeigt werden sollen

• EV-Treiber bevorzugte Sprachen

• Tarif und Kosten: Anzeige des geltenden Tarifs / Preises vor / während des Ladevorgangs eines Elektrofahrzeugfahrers an einer Ladestation

OCPP-J Verbesserungen

• Einfaches Nachrichtenrouting

• Keine SOAP-Unterstützung

Kleinere Änderungen / Erweiterungen

• Umbenannte Nachrichten: Die Namen der Nachrichten wurden gegebenenfalls geändert, um die Klarheit und das Verständnis zu verbessern

• TransactionId Identification & Message Sequencing: In OCPP 2.0 werden Transaktionskennungen von der Ladestation generiert

• Erweiterte Aufzählungen: Unterstützt mehr Anwendungsfälle

• Offline-Transaktionsereignisanzeige: Unterstützung für Transaktionsereignisse trat auf, während die Ladestation offline war

• Persönliche Nachricht: Nachricht, die dem EV-Fahrer angezeigt werden kann

Use Cases

Liste der von OCPP 2.0 unterstützten Anwendungsfälle, und welche Anwendungsfälle wurden bereits von OCPP 1.6 unterstützt

UC ID	Use Case	OCPP 1.6	Neues in OCPP 2.0
A - Security
A01	Update Charging Station Password for HTTP Basic Authentication		✅
A02	Update Charging Station Certificate by request of o CSMS		✅
A03	Update Charging Station Certificate initiated by the Charging Station		✅
A04	Security Event Notification		✅
B - Provisioning
B01	Cold Boot Charging Station	✅
B02	Cold Boot Charging Station - Pending	✅
B03	Cold Boot Charging Station - Rejected	✅
B04	Offline Behavior Idle Charging Station	✅
B05	Set Variables		✅
B06	Get Variables		✅
B07	Get Base Report		✅
B08	Get Custom Report		✅
B09	Setting a new NetworkConnectionProfile		✅
B010	Migrate to new CSMS		✅
B011	Reset - Without Ongoing Transaction	✅
B012	Reset - With Ongoing Transaction	✅
C - Authorization
C01	EV Driver Authorization using RFID	✅
C02	Authorization using a start button		✅
C03	Authorization using credit/debit card		✅
C04	Authorization using PIN-code		✅
C05	Authorization for CSMS initiated transactions		✅
C06	Authorization using local id type		✅
C07	Authorization using Contract Certificates		✅
C08	Authorization at EVSE using ISO 15118 External Identification Means (EIM)		✅
C09	Authorization by GroupId	✅
C010	Store Authorization Data in the Authorization Cache	✅
C011	Clear Authorization Data in Authorization Cache	✅
C012	Start Transaction - Cached Id	✅
C013	Offline Authorization through Local Authorization List	✅
C014	Online Authorization through Local Authorization List	✅
C015	Offline Authorization of unknown Id	✅
C016	Stop Transaction with a Master Pass		✅
D - LocalAuthorizationList
D01	Send Local Authorization List	✅
D02	Get Local List Version	✅
E - Transactions
E01	Start Transaction Options		✅
E02	Start Transaction - Cable Plugin First	✅
E03	Start Transaction - IdToken First	✅
E04	Transaction started while Charging Station is offline	✅
E05	Start Transaction - Id not Accepted	✅
E06	Stop Transaction Options		✅
E07	Transaction locally stopped by IdToken	✅
E08	Transaction stopped while Charging Station is offline	✅
E09	When cable disconnected on EV-side: Stop Transaction	✅
E010	When cable disconnected on EV-side: Suspend Transaction	✅
E011	Connection Loss During Transaction	✅
E012	Inform CSMS of an Offline Occurred Transaction	✅
E013	Transaction related message not accepted by CSMS	✅
E014	Check transaction status		✅
E015	End of charging process	✅
F - RemoteControl
F01	Remote Start Transaction - Cable Plugin First	✅
F02	Remote Start Transaction - Remote Start First	✅
F03	Remote Stop Transaction	✅
F04	Remote Stop ISO 15118 charging from CSMS		✅
F05	Remotely Unlock Connector	✅
F06	Trigger Message	✅
G - Availability
G01	Status Notification	✅
G02	Heartbeat	✅
G03	Change Availability EVSE	✅
G04	Change Availability Charging Station	✅
G05	Lock Failure	✅
H - Reservation
H01	Reservation	✅
H02	Cancel Reservation	✅
H03	Use a reserved EVSE	✅
H04	Reservation Ended, not used	✅
I - Tariff and Costs
I01	Show EV Driver-specific tariff information		✅
I02	Show EV Driver running total cost during charging		✅
I03	Show EV Driver final total cost after charging		✅
I04	Show fallback tariff information		✅
I05	Show fallback total cost message		✅
I06	Update Tariff Information During Transaction		✅
J - Metering
J01	Sending Meter Values not related to a transaction	✅
J02	Sending transaction related Meter Values	✅
J03	Charging Loop with metering information exchange		✅
K - Smart Charging
K01	SetChargingProfile	✅
K02	Central Smart Charging	✅
K03	Local Smart Charging	✅
K04	Internal Load Balancing	✅
K05	Remote Start Transaction with Charging Profile	✅
K06	Offline Behavior Smart Charging During Transaction	✅
K07	Offline Behavior Smart Charging at Start of Transaction	✅
K08	Get Composite Schedule	✅
K09	Get Charging Profiles		✅
K010	Clear Charging Profile	✅
K011	Set / Update External Charging Limit With Ongoing Transaction		✅
K012	Set / Update External Charging Limit Without Ongoing Transaction		✅
K013	Reset / release external charging limit		✅
K014	External Charging Limit with Local Controller		✅
K015	Charging with load leveling based on High Level Communication		✅
K016	Optimized charging with scheduling to the CSMS		✅
K017	Renegotiating a Charging Schedule		✅
L - Firmware Management
L01	Secure Firmware Update		✅
L02	Non-Secure Firmware Update	✅
L03	Publish Firmware file on Local Controller		✅
L04	Unpublish Firmware file on Local Controller		✅
M - ISO 15118 Certificate Management
M01	Certificate Installation EV		✅
M02	Certificate Update EV		✅
M03	Retrieve list of available certificates from a Charging Station		✅
M04	Delete a specific certificate from a Charging Station		✅
M05	Install CA certificate in a Charging Station		✅
M06	Get Charging Station Certificate status		✅
N - Diagnostics
N01	Retrieve Log Information	✅
N02	Get Monitoring report		✅
N03	Set Monitoring Base		✅
N04	Set Variable Monitoring		✅
N05	Set Monitoring Level		✅
N06	Clear / Remove Monitoring		✅
N07	Alert Event		✅
N08	Periodic Event		✅
N09	Get Customer Information		✅
N010	Clear Customer Information		✅
O - Display Message
O01	Set DisplayMessage		✅
O02	Set DisplayMessage for Transaction		✅
O03	Get All DisplayMessages		✅
O04	Get Specific DisplayMessages		✅
O05	Clear a DisplayMessage		✅
O06	Replace DisplayMessage		✅
P - DataTransfer
P01	Data Transfer to the Charging Station	✅
P02	Data Transfer to the CSMS	✅

OCPP Server

Jetzt ist es Zeit, einen OCPP-Server zu entwickeln, der die Kommunikation mit Charging Point unterstützt OCPP 2.0. Was bedeutet eigentlich?

Annahmen

Nun, die erste obligatorische Sache ist die Kommunikation über die WebSocket-Schnittstelle (Kommunikation über SOAP ist
nicht mehr unterstützt). Daher müssen alle Sicherheitsaspekte in der Netzwerkverkehrsschicht festgelegt werden.

Das zweite sind Implementierungsnachrichten, die mit Standard-OCPP 2.0 kompatibel sind (meistens Transaktionsverarbeitung).

Drittens: Wir müssen wissen, dass nicht alle Anwendungsfälle abgedeckt werden müssen. Die meisten von ihnen sind nicht obligatorisch
Um den Hauptprozess des Aufladens von Elektrofahrzeugen zu unterstützen, können wir problemlos Funktionen für die MVP-Phase auswählen.

Viertens: Wir brauchen in der ersten Entwicklungsphase keinen Ladepunkt. Natürlich ist das später erforderlich,
Jetzt können wir einen einfachen Ladepunktsimulator erstellen, um das Laden zu emulieren.

Technologie

Für unseren Zweck (Backend-OCPP-Server) wurde Java 11 mit Spring Boot Framework verwendet, aber Sie können wählen andere Backend-Technologie, die Ihnen gefällt und die es Ihnen ermöglicht, ein Backend-Modul zu erstellen und die WebSocket-Kommunikation zu unterstützen. Natürlich ist alles in Docker-Images eingebettet, einschließlich Datenbank, Service usw.

Stellen Sie über WebSocket eine Verbindung zum Simulator her

Herstellen einer Verbindung zum OCPP-Server mithilfe des Simulators und der Verbindungsfunktion

Figure 3. Verbinden Sie sich mit dem Simulator

Und das Ergebnis …​

Figure 4. Verbindungsergebnis

Ja, es scheint gut zu funktionieren!

Beispiel für implementierte Use Cases

• C01 - EV Driver Authorization using RFID / AuthorizeRequest

[
  2,
  "123456789",
  "Authorize",
  {
    "idToken": {
      "idToken": "T01",
      "type": "Central"
    }
  }
]

• E02 - Start Transaction - Cable Plugin First / StatusNotificationRequest (set connector to Occupied state)

[
  2,
  "123456789",
  "StatusNotification",
  {
    "timestamp": "2021-03-19T07:10:11",
    "connectorStatus": "Occupied",
    "evseId": 1,
    "connectorId": 1
  }
]

• E02 - Start Transaction - Cable Plugin First / TransactionEvent (Started) Connect using simulator

[
  2,
  "123456789",
  "TransactionEvent",
  {
    "eventType": "Started",
    "timestamp": "2021-03-19T07:10:11",
    "triggerReason": "CablePluggedIn",
    "seqNo": 1,
    "transactionInfo": {
      "transactionId": "324567986",
      "chargingState": "EVConnected"
    }
  }
]

• E09 - When cable disconnected on EV-side: Stop Transaction / TransactionEvent (Ended)

[
  2,
  "123456789",
  "TransactionEvent",
  {
    "eventType": "Ended",
    "timestamp": "2021-03-19T07:11:11",
    "triggerReason": "EVCommunicationLost",
    "seqNo": 3,
    "transactionInfo": {
      "transactionId": "324567986"
    },
    "idToken": {
      "idToken": "T01",
      "type": "Central"
    },
    "meterValue": [
      {
        "timestamp": "2021-03-19T07:10:11",
        "sampledValue": [
          {
            "value": "75",
            "unitOfMeasure": {
              "unit": "Wh",
              "multiplier": 3
            }
          }
        ]
      }
    ]
  }
]

• G01 - Status Notification / StatusNotificationRequest (statuses according to ConnectorStatusEnumType)

[
  2,
  "123456789",
  "StatusNotification",
  {
    "timestamp": "2021-03-19T07:20:11",
    "connectorStatus": "Available",
    "evseId": 1,
    "connectorId": 1
  }
]

Und mal sehen, wie G01 im OCPP-Simulator aussieht (Anfrage & Antwort)

Figure 5. UC G01 Beispiel

Schön gemacht! Das funktioniert!