OCPP 2.0.1 als Produktions-Baseline. Vorwärts zu 2.1.
OCPP 2.0.1 ist die Produktions-Baseline. Clemios konzipiert Systeme, die sich sicher in Richtung 2.1 weiterentwickeln. Clemios baut keine neuen Systeme auf OCPP 1.6. Das Protokoll wird in reale Ladegeräte-Hardware integriert, gegen reale Backends validiert, und die Firmware wird so architekturiert, dass der Übergang zu 2.1 kein Rewrite erfordert.
Warum OCPP schwieriger ist, als die Spezifikation vermuten lässt
OCPP definiert, wie EV-Ladegeräte mit zentralen Managementsystemen kommunizieren. Die Spezifikation ist offen, gut strukturiert und wird von der Open Charge Alliance gepflegt. Auf dem Papier sieht die Implementierung einfach aus. In der Praxis ist sie es nicht.
Backend-Systeme interpretieren die Spezifikation unterschiedlich. Das Verhalten von Sicherheitsprofilen variiert zwischen CSMS-Anbietern. Firmware-Update-Flows, die gegen ein Backend funktionieren, scheitern stillschweigend gegen ein anderes. Versionsdrift zwischen 1.6-Deployments im Feld und 2.0.1-Produktionszielen erzeugt Upgrade-Pfade, die jede Schicht der Ladegeräte-Firmware berühren. Das sind Engineering-Probleme, keine Konfigurationsprobleme. Unbehandelt führen sie zu Regressionen im Feld, Rückwärtskompatibilitätsfehlern und Ladegeräten, die Labortests bestehen, aber in Produktionsnetzwerken versagen.
Clemios ist OCA-Mitglied seit Januar 2026. Es gibt keinen OCPP-Stack zum Verkauf. Clemios integriert OCPP in Ladegeräte-Hardware mit FlexCharge.OCPP, einem wiederverwendbaren Engineering-Asset, und validiert es gegen die spezifischen Backends, mit denen der jeweilige Kunde interoperieren muss. Der Unterschied zeigt sich, wenn ein Ladegerät Interoperabilitätstests gegen Systeme bestehen muss, für die es nie konzipiert wurde.
OCPP-Versionsvergleich
| Feature | OCPP 1.6 | OCPP 2.0.1 | OCPP 2.1 |
|---|---|---|---|
| Kommunikation | WebSocket (JSON/SOAP) | WebSocket (JSON) | WebSocket (JSON) |
| Sicherheitsprofile | Basis-Authentifizierung | 3 Profile inkl. TLS Mutual Auth | Erweiterte Sicherheit |
| Gerätemodell | Flaches Key-Value | Strukturiertes Komponentenmodell | Erweitertes Komponentenmodell |
| Funktionsblöcke | Monolithisch | Modular (Core, Smart Charging, Reservation, etc.) | Erweiterte Blöcke |
| ISO-15118-Unterstützung | Nein | Plug-and-Charge-fähig | Native Integration |
| Firmware-Management | Basis | Signierte Firmware-Updates | Erweitert |
| Clemios-Status | Legacy-Unterstützung | Aktiv implementiert | In Entwicklung |
Clemios-Produktionssysteme starten mit OCPP 2.0.1. Von dort aus ist die Architektur auf Vorwärtskompatibilität in Richtung 2.1 ausgelegt, ohne grundlegende Rewrites oder parallele Protokoll-Stacks.
Quelle: Open Charge Alliance-Spezifikationen. Der Clemios-Status spiegelt die aktuelle Engineering-Fähigkeit wider, nicht den OCA-Zertifizierungsstatus.
FlexCharge.OCPP in sechs Schichten
FlexCharge.OCPP ist um OCPP-2.0.1-Semantik und Lifecycle-Konzepte herum konzipiert. Die Evolution in Richtung 2.1 wird dadurch zu einem kontrollierten Engineering-Schritt statt eines System-Rewrites.
Jedes OCPP-Integrationsprojekt, das Clemios liefert, startet mit FlexCharge.OCPP. Anstatt OCPP-Code für jeden Kunden neu zu schreiben, stellt Clemios eine modulare, produktionsgetestete Architektur bereit und passt sie an die spezifischen Hardware- und Backend-Anforderungen an.
Die Architektur trennt Zuständigkeiten, sodass Änderungen in einer Schicht nicht auf andere übergreifen. Wenn ein Kunde von einem Infineon- auf einen NXP-MCU wechselt, bleibt die Arbeit in der Hardware-Abstraktionsschicht. Protokollkern, Kommunikationslogik und Sicherheitsdurchsetzung darüber bleiben unverändert. Diese Kapselung macht die Architektur projektübergreifend mit unterschiedlicher Hardware wiederverwendbar.
Für Kunden bedeutet das drei Dinge. Weniger Regressionen beim Upgrade von Protokollversionen, da Änderungen in einer Schicht bleiben. Vorhersagbares Verhalten über verschiedene CSMS-Backends, da Kommunikation und Sicherheit von Protokolllogik isoliert sind. Und testbare Upgrade-Pfade von 2.0.1 auf 2.1, da der Übergang die Protocol-Core-Schicht betrifft, ohne Änderungen an den fünf Schichten darunter zu erfordern.
-
1. Protocol CoreNachrichtenrouting, Zustandsmaschine, Profilverwaltung, Device-Model-Handling. Diese Schicht implementiert die OCPP-Spezifikation direkt.
-
2. CommunicationWebSocket-Transport, JSON-Kodierung und -Dekodierung, Retry-Logik, Session-Management. Behandelt das Wire-Protokoll zwischen Ladegerät und CSMS.
-
3. SecurityTLS-Session-Aufbau, Zertifikats-Lifecycle (Bereitstellung, Verlängerung, Widerruf), Sicherheitsprofil-Durchsetzung über alle drei OCPP-2.0.1-Profile.
-
4. Hardware AbstractionChip-spezifische Treiber, I/O-Adapter, Hersteller-Isolation, Capability-APIs. Unterstützt 8 MCU-Familien.
-
5. DiagnosticsStrukturiertes Logging, Metriken-Erfassung, Fehlerberichterstattung. Konzipiert für Feld-Debugging, wenn physischer Zugang zum Ladegerät eingeschränkt ist.
-
6. LifecycleBoot-Sequenzierung, geordnetes Herunterfahren, Firmware-Update-Management, Recovery-Prozeduren. Behandelt die Betriebszustände, die OCPP nicht spezifiziert, die Produktions-Ladegeräte aber erfordern.
FlexCharge.OCPP: 6-Schichten-Architektur
OCPP-Integrationsmethodik
Diese Methodik gilt für die erstmalige OCPP-Implementierung ebenso wie für die Migration von OCPP 1.6 auf 2.0.1.
Protokollstatus
Die Produktions-Baseline beginnt mit OCPP 2.0.1. Die unten aufgeführten Status spiegeln die aktuelle Clemios-Engineering-Fähigkeit wider.
| Protokoll | Status | Beschreibung |
|---|---|---|
| OCPP 2.0.1 | Aktiv implementiert | Auf realer Hardware deployed. Produktionsbereit. |
| OCPP 2.1 | In Entwicklung | Aktive Engineering-Arbeit. Noch nicht verfügbar. |
| ISO 15118 | Zukünftige Fähigkeit | Auf dem Entwicklungshorizont. Noch nicht implementiert. |
| IEC 61850-104 | Zukünftige Fähigkeit | Für Netzintegrations-Anwendungsfälle. Noch nicht implementiert. |
| VDV 261/463 | Zukünftige Fähigkeit | Für Ladeszenarien im öffentlichen Nahverkehr. Noch nicht implementiert. |
| OCTT | Aktiv getestet mit OCTT | Testmethodik ist an OCTT ausgerichtet. Nicht zertifiziert. |
Diese Tabelle wird aktualisiert, wenn sich Fähigkeiten ändern. Clemios beansprucht keine Zertifizierung, die nicht erreicht wurde. Zuletzt geprüft: April 2026.
Häufig gestellte Fragen
Clemios entwickelt und integriert OCPP-Systeme ab OCPP 2.0.1 als Produktions-Baseline, entwirft sie für die Weiterentwicklung Richtung 2.1 und baut keine neuen Systeme auf OCPP 1.6.
OCPP 2.0.1 ist die Clemios-Produktions-Baseline. Es ist die erste OCPP-Version, die das Sicherheitsmodell, das Gerätemanagement und die Lifecycle-Steuerung bereitstellt, die für produktionsreife Ladesysteme erforderlich sind. Alle Clemios-OCPP-Integrationen starten bei OCPP 2.0.1.
Clemios implementiert den OCPP 2.0.1-Kern und relevante optionale Profile, die für sicheren Betrieb, Firmware-Management, Diagnostik und Backend-Integration erforderlich sind. Die Profilauswahl richtet sich nach der tatsächlichen Systemarchitektur und den Betriebsanforderungen, nicht nach einer festen Checkliste.
OCPP 2.1 ist eine Weiterentwicklung von OCPP 2.0.1, die Funktionalität erweitert und gleichzeitig die architektonischen Grundlagen beibehält. Clemios entwirft Systeme so, dass der Wechsel von 2.0.1 auf 2.1 ein kontrolliertes Upgrade ist, kein Protokoll-Reset oder Neuentwicklung.
Clemios entwirft OCPP-Implementierungen mit Vorwärtskompatibilität als Grundprinzip. Versions-Upgrades werden durch klare Trennung von Protokolllogik, Backend-Integration und gerätespezifischem Verhalten umgesetzt. Dies ermöglicht Upgrades von OCPP 2.0.1 Richtung 2.1 ohne Regressionen oder parallele Protokollstacks.
Clemios baut keine neuen Systeme auf OCPP 1.6. Die Produktions-Baseline beginnt bei OCPP 2.0.1. Migration bestehender OCPP-1.6-Systeme kann bei Bedarf unterstützt werden, aber alle neuen Implementierungen basieren auf modernen OCPP-Versionen.
OCTT ist das Konformitätstest-Tool der Open Charge Alliance. Clemios nutzt OCTT als Teil des Interoperabilitäts- und Validierungsprozesses zur Verifizierung des Protokollverhaltens. Clemios ist nicht OCTT-zertifiziert und beansprucht keine Zertifizierung, die nicht erreicht wurde.
OCPP-Engineering, das liefert
Von der ersten Implementierung bis zur Versionsmigration, von Sicherheitsprofilen bis zur Interoperabilitätstestung. OCPP, das in Produktion funktioniert.