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.
Konzipiert für Teams, die OCPP-Auslieferung zum Funktionieren brauchen
Auf realer Hardware, gegen reale Backends, mit einem kontrollierten Pfad in Richtung 2.1.
Für Charger-OEMs
Neue Ladesysteme auf einer OCPP-2.0.1-Produktions-Baseline aufbauen, konzipiert für reale Hardware und Backend-Interoperabilität.
Für Upgrade- und Migrationsteams
Von OCPP 1.6 migrieren oder den Weg in Richtung 2.1 planen, über einen kontrollierten Architekturpfad, der Rewrite-Risiken reduziert.
Für interoperabilitätskritische Programme
OCPP-Verhalten gegen reale Backends, Sicherheitsprofile und Feld-Randfälle validieren, bevor deployed wird.
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.
Warum Clemios für OCPP
Das Angebot ist Engineering-Ausführung, kein Protokoll-Stack als Produkt.
Reale Hardware-Integration
Clemios integriert OCPP in Charger-Firmware und Hardware-Randbedingungen, nicht nur in abstrakte Protokolllogik.
Reale Backend-Validierung
Clemios validiert Verhalten gegen die CSMS-Umgebungen, mit denen der jeweilige Kunde tatsächlich interoperieren muss.
Kontrollierter Upgrade-Pfad
OCPP 2.0.1 ist die Produktions-Baseline. Der Pfad in Richtung 2.1 wird ohne Rewrite-Risiko architekturiert.
Service-basierte Auslieferung
FlexCharge.OCPP beschleunigt die Auslieferung, aber das Angebot bleibt Engineering-Ausführung statt Boxed-Stack-Verkauf.
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.
Protokollstatus
Clemios veröffentlicht den Protokollstatus offen. Keine vagen Fähigkeitsbehauptungen. Kein „unterstützt“ ohne Kontext. Diese Tabelle bildet den exakten aktuellen Engineering-Status ab:
1 aktiv implementiert. 1 in aktiver Entwicklung. 2 zukünftige Fähigkeiten. 3 Integrationsumfang. 1 aktiv getestet.
Wischen für alle Spalten →
| Protokoll | Engineering-Status | Was das bedeutet |
|---|---|---|
| Core OCPP | ||
| OCPP 2.0.1 | Aktiv implementiert | Auf realer Hardware deployed. Produktionsbereit für aktuelle Kundenprogramme. |
| OCPP 2.1 | In Entwicklung | Aktive Engineering-Arbeit. Noch nicht für Kunden-Deployments verfügbar. |
| Zukünftige Standards | ||
| ISO 15118-2 | Zukünftige Fähigkeit | Auf dem Entwicklungshorizont für Plug&Charge und TLS-basierte Kommunikation. |
| ISO 15118-20 | Zukünftige Fähigkeit | Auf dem Entwicklungshorizont für bidirektionalen Energietransfer. |
| Integrationsumfang | ||
| IEC 60870-5-104 | Integrationsumfang | Im Rahmen von Netzintegrationsprojekten adressierbar. Kein Charger-Kernprotokoll. |
| VDV 261 | Integrationsumfang | Im Rahmen von ÖPNV-Ladeprojekten adressierbar (Betriebsplanung). |
| VDV 463 | Integrationsumfang | Im Rahmen von ÖPNV-Ladeprojekten adressierbar (Ladeinfrastruktur). |
| Validierung | ||
| OCTT | Aktiv getestet mit OCTT | Aktiv gegen OCTT-Praktiken getestet. Nicht zertifiziert. |
| Diese Tabelle wird aktualisiert, wenn sich der Clemios-Protokollstatus ändert. Sie unterliegt dem Engineering-Sign-off, nicht dem Marketing. | ||
| Aktiv implementiert = produktionsbereit und deployed · In Entwicklung = unter aktiver Entwicklung, nicht kunden-nutzbar · Zukünftige Fähigkeit = auf dem Entwicklungshorizont · Integrationsumfang = in Projekten adressierbar, kein Charger-Kernprotokoll · Aktiv getestet = Testmethodik an OCTT ausgerichtet, nicht zertifiziert | ||
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.
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
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
OCPP-2.0.1-Auslieferung, Interoperabilitätsvalidierung oder den Pfad in Richtung 2.1 abklären, bevor Implementierungsrisiken eskalieren.