OCPP-Integrations-Bereitschafts-Checkliste für EV-Ladesysteme

1. Ziel-OCPP-Version festgelegt

OCPP 2.0.1 (stabil) oder OCPP 2.1 (in Entwicklung) explizit ausgewählt. Jeder Ladegerät-CSMS-Integrationspfad zielt auf eine Protokollversion. Migrationen bei gemischten Flotten erfordern eine dokumentierte Übergangsmatrix.

2. Build-vs-Integrate-Entscheidung getroffen

OCPP von Grund auf schreiben, Open-Source nutzen oder ein wiederverwendbares Engineering-Asset integrieren. Diese Entscheidung ändert Teststrategie, Zertifizierungsumfang, Eigentumsmodell und Zeitplan. Für ausgewählte Projekte kann Clemios FlexCharge.OCPP als wiederverwendbaren Engineering-Beschleuniger einsetzen, wobei Implementierungsstack, Integrationsumfang und IP-Eigentum am Kundenprojekt ausgerichtet bleiben.

3. Benötigte OCPP-Funktionsblöcke identifiziert

Funktionsblöcke aufgelistet: Core, Smart Charging, Reservation, Local Auth List, Firmware Management, ISO 15118 Certificate Management. Nur benötigte Funktionsblöcke ausgewählt.

4. Protokoll-Migrationspfad dokumentiert (bei Upgrade von 1.6)

Jede OCPP-1.6-Nachricht auf das 2.0.1- oder 2.1-Äquivalent abgebildet. Aufgeteilte, umbenannte und umstrukturierte Nachrichten in einer Migrationsmatrix erfasst.

5. Hardware-Plattform erfüllt Mindestanforderungen

Clemios-Planungsbaseline: Ziel-MCU/SoC mit 8 MB Flash und 2 MB RAM für OCPP 2.0.1 Core + TLS + WebSocket. Höhere Funktionsblöcke (ISO 15118-2, OCPP 2.1 in Entwicklung) erfordern möglicherweise mehr. Ziele unterhalb dieser Baseline sollten eine Architekturüberprüfung auslösen.

6. Kommunikationspfad definiert

Ladegerät-zu-CSMS-Konnektivität ausgewählt: Ethernet, WLAN, Mobilfunk (4G/LTE) oder Kombination. Reconnect-Strategie und Fallback-Verhalten bei Verbindungsverlust definiert. Auswirkungen auf Latenz, Zuverlässigkeit und Zertifikatsbereitstellung dokumentiert.

7. WebSocket + TLS 1.2+ auf Zielhardware bestätigt

OCPP 2.0.1 und 2.1 verwenden WebSocket mit JSON-Payloads. Für Produktions-Sicherheitsprofile ist wss:// mit TLS 1.2+ erforderlich. Firmware-WebSocket-Bibliothek und TLS-Unterstützung auf der Zielplattform für das gewählte Sicherheitsprofil verifiziert.

8. Backend (CSMS) identifiziert

Integration mit bestehendem CSMS, Eigenentwicklung oder Drittanbieter. CSMS-Fähigkeiten bestimmen, welche OCPP-Profile das Ladegerät implementieren muss.

9. TLS-Zertifikatsstrategie definiert

Selbstsigniert für Entwicklung, CA-signiert für Produktion. Vollständiger Zertifikatslebenszyklus dokumentiert: Ausstellung, Verlängerung, Widerruf.

10. Sicherheitsprofil-Stufe gewählt

Eines von drei OCPP-Sicherheitsprofilen ausgewählt: ungesichert, Basic Auth + TLS oder Client-Zertifikate + TLS. Die Profilwahl bestimmt direkt die Firmware-Komplexität.

11. Ansatz zur Private-Key-Speicherung festgelegt

HSM, Secure Element oder softwarebasierte Schlüsselspeicherung ausgewählt. Hardware-Sicherheit beeinflusst Kosten und Zertifizierungsbereitschaft.

12. Interoperabilitäts-Testplan erstellt

Validierung gegen mindestens 2-3 verschiedene CSMS-Implementierungen. Testmatrix deckt alle ausgewählten OCPP-Profile ab. Teilnahme an OCA-Plugfests evaluiert.

13. OCTT-Testfälle auf Implementierungsumfang abgebildet

OCA OCPP Compliance Testing Tool (OCTT) Konformitätsfälle geprüft. Anwendbare OCTT-Konformitätsprofile identifiziert: Core, Advanced Security, Smart Charging, Reservation, Local Auth List, ISO 15118 Certificate Management.

14. Firmware-Unit-Testing-Framework ausgewählt

TDD-Framework vor Codierungsbeginn gewählt: Ceedling (C), GoogleTest (C++) oder äquivalent. Protokolllogik ist betriebskritisch und erfordert regressionssichere Entwicklung.

15. Regressionstestumgebung mit CI/CD betriebsbereit

Automatisierte Protokoll-Testsuite wird nach jeder Firmware-Änderung erneut ausgeführt. CI/CD-Pipeline konfiguriert und liefert Pass/Fail-Ergebnisse.

16. Gerätemodell-Variablen auf OCPP Component/Variable-Struktur abgebildet

Jeder konfigurierbare Parameter (Anschlussanzahl, Leistungsgrenzen, Messintervalle) aufgelistet und auf das OCPP-Gerätemodell (Component/Variable-Struktur in 2.0.1 und 2.1) abgebildet.

17. Messwerte und Abtastintervalle definiert

Von der Hardware gemeldete Energie- und Leistungswerte identifiziert. Abtastrate dokumentiert. MeterValues-Nachrichtenkonfiguration entspricht den Hardware-Fähigkeiten.

18. Firmware-Images kryptographisch signiert

Firmware-Binärdateien mit einem projektspezifischen Schlüssel signiert. Signaturprüfung wird auf dem Gerät vor der Installation erzwungen. Unsignierte oder manipulierte Images werden abgelehnt.

19. Firmware-Rollback-Mechanismus vorhanden

Gerät kann sich von einem fehlgeschlagenen oder unterbrochenen Firmware-Update erholen. Rollback auf das letzte bekannte funktionsfähige Image erfolgt automatisch oder wird manuell ausgelöst. Bootloader-Verhalten bei Korruption ist definiert.

20. Remote-Firmware-Update per OCPP bestätigt

OCPP FirmwareManagement (UpdateFirmware / FirmwareStatusNotification) ist auf der Zielplattform implementiert, oder Remote-Update ist explizit außerhalb des Umfangs mit dokumentierter Begründung.

21. OCPP-geschultes Engineering-Team zugewiesen

Engineering-Fachkräfte, die die OCPP-Spezifikation (Teile 1 und 2 der Zielversion) gelesen haben und Nachrichtenflüsse nachvollziehen können, sind dem Projekt zugewiesen. Schulung oder externe Unterstützung organisiert, falls nicht.

22. Projektzeitplan berücksichtigt Protokollkomplexität

Erste OCPP-Integration (Core + Smart Charging + Security Profile 2): 3-6 Monate für ein erfahrenes Team. 30-50 % aufschlagen bei erstem OCPP-Projekt. OCPP 2.1 (in Entwicklung) kann den Umfang für neue Features (Tarif, Netz) erweitern. Zeitplan berücksichtigt dies.