eMobility-Softwareentwicklungspartner für EV-Ladesysteme

Menü
eMobility › OCPP Engineering
OCA-Mitglied seit 2026

OCPP 2.0.1 als Produktions-Baseline. Kontrollierter Pfad zu 2.1.

Clemios integriert OCPP 2.0.1 auf realer Charger-Hardware, validiert es gegen reale CSMS-Umgebungen und entwirft einen kontrollierten Upgrade-Pfad in Richtung OCPP 2.1. Clemios baut keine neuen Systeme auf OCPP 1.6.

OCPP Technical Scoping Call anfragen OCPP-Bereitschafts-Checkliste herunterladen
FÜR WEN DIESE SEITE IST

Für Teams, die OCPP-Auslieferung zum Funktionieren brauchen

Auf realer Hardware, gegen reale CSMS-Umgebungen, 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 CSMS-Interoperabilität.

Für Upgrade- und Migrationsteams

Von OCPP 1.6 migrieren oder den Pfad Richtung 2.1 planen, über einen kontrollierten Architekturpfad, der Rewrite-Risiko reduziert.

Für interoperabilitätskritische Programme

OCPP-Verhalten gegen reale CSMS-Umgebungen, Sicherheitsprofile und Feld-Grenzfälle vor dem Deployment validieren.

OCA-Mitglied seit 2026 OCPP 2.0.1 aktiv implementiert Reale Hardware Reale CSMS-Umgebungen

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.

CSMS-Implementierungen interpretieren die Spezifikation unterschiedlich. Sicherheitsprofil-Verhalten variiert zwischen CSMS-Anbietern. Firmware-Update-Abläufe, die gegen ein CSMS funktionieren, scheitern stillschweigend gegen ein anderes. Versionsdrift zwischen OCPP-1.6-Deployments, die noch im Feld sind, und OCPP-2.0.1-Produktionszielen erzeugt Upgrade-Pfade, die jede Schicht der Charger-Firmware betreffen. Das sind Engineering-Probleme, keine Konfigurationsprobleme. Unkontrolliert produzieren sie Regressionen im Feld, Rückwärtskompatibilitätsfehler und Ladegeräte, 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 Charger-Hardware unter Verwendung von FlexCharge.OCPP, einem wiederverwendbaren Engineering-Asset, und validiert es gegen die spezifischen CSMS-Umgebungen, mit denen jeder Kunde interoperieren muss. Der Unterschied wird relevant, wenn ein Ladegerät mit CSMS-Umgebungen, Sicherheitsprofilen und Feldverhalten interoperieren muss, die nicht Teil der ursprünglichen Implementierungsannahmen waren.

LIEFERRELEVANZ
Umfang vor Code

Funktionsprofile, Sicherheitsprofil-Auswahl, CSMS-Ziele und Migrations-Randbedingungen werden definiert, bevor die Implementierung beginnt.

Firmware-Level-Integration

OCPP 2.0.1 wird in Charger-Firmware implementiert, nicht als Konfiguration oder Middleware behandelt.

CSMS-Interoperabilitätsvalidierung

Tests gegen reale CSMS-Umgebungen und anbieterspezifisches Verhalten vor dem Feld-Deployment.

OCTT-basierte Konformitätsvorbereitung

Strukturierte Test-Workflows, ausgerichtet an der OCTT-Methodik, vor formalen Zertifizierungsaktivitäten.

Lifecycle und Upgrade-Pfad

Firmware-Updates, Diagnostik, Regressionstests und ein kontrollierter Pfad von OCPP 2.0.1 in Richtung 2.1.

LIEFERRELEVANZ

Warum Clemios für OCPP

Das Angebot ist Engineering-Ausführung, kein Protokoll-Stack als Boxed-Produkt.

Reale Hardware-Integration

Clemios integriert OCPP in Charger-Firmware und Hardware-Randbedingungen, nicht nur in abstrakte Protokolllogik.

Reale CSMS-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 früh geplant, um vermeidbares Rewrite-Risiko zu reduzieren.

Service-basierte Auslieferung

FlexCharge.OCPP beschleunigt die Auslieferung, aber das Angebot bleibt Engineering-Ausführung statt Boxed-Stack-Verkauf.

OCPP-STATUS

Aktueller OCPP-Engineering-Status

Clemios veröffentlicht den OCPP-Status offen. Keine vagen Fähigkeitsbehauptungen. Kein „unterstützt“ ohne Kontext.

OCPP 1.6 Migrations-Support

Nur dort unterstützt, wo Legacy-Migration oder Interoperabilitäts-Randbedingungen es erfordern. Keine Neubauten.

OCPP 2.0.1 Aktiv implementiert

Produktions-Baseline. Validiert auf realer Charger-Hardware mit strukturierter Funktionsprofil-Abdeckung.

OCPP 2.1 In Entwicklung

Aktive Engineering-Arbeit. Noch nicht für Kunden-Deployments verfügbar.

OCTT Aktiv getestet

Konformitätsvorbereitungs-Methodik. Aktiv getestet mit OCTT. Kein OCA-Zertifizierungsanspruch.

Vollständige Protokolltransparenz, einschließlich ISO 15118, IEC 60870-5-104, VDV 261/463 und OCTT-Status, wird auf der eMobility-Engineering-Seite gepflegt.

Gesteuert durch Engineering-Freigabe, nicht durch Marketing.

OCPP-Integrationsmethodik

01
Bewerten
Ladegeräte-Hardware, bestehende Firmware, CSMS-Anforderungen und Ziel-OCPP-Version prüfen. Neue Clemios-OCPP-Auslieferung orientiert sich an OCPP 2.0.1; OCPP 1.6 wird nur dort behandelt, wo Migrations-Randbedingungen es erfordern. Lücken zwischen Ist-Zustand und Protokollanforderungen identifizieren. Den Umfang definieren: welche Funktionsblöcke, welches Sicherheitsprofil, gegen welches CSMS getestet wird. Das Ziel ist es, Unbekannte zu reduzieren, bevor Integrationscode geschrieben wird.
02
Implementieren
Die relevanten FlexCharge.OCPP-Schichten auf der Ziel-Ladegeräte-Hardware integrieren. Benötigte OCPP-Profile und Funktionsblöcke implementieren. Hardware-Abstraktionsschicht an den spezifischen Chipsatz anpassen. Die Architektur trennt Protokolllogik von hardware-spezifischer Anpassung, wo möglich. Das reduziert CSMS-spezifische Grenzfall-Risiken vor dem Feld-Deployment.
03
Validieren
Interoperabilitätstests gegen das CSMS des Kunden durchführen. Sicherheitsprofil-Verifizierung ausführen. Nachrichtenflüsse für Standard-Sequenzen und Grenzfälle validieren: Netzwerkunterbrechungen, Zertifikatsablauf, Firmware-Update während aktiver Transaktionen und Offline-Recovery. Das reduziert Feld-Regressionsrisiko, indem Fehler im Labor erkannt werden.
04
Unterstützen
Laufende Engineering-Unterstützung nach dem Deployment. Feldverhalten über die Diagnostics-Schicht überwachen. Protokoll-Updates anwenden, wenn neue OCPP-Versionen oder OCA-Errata veröffentlicht werden. Feldprobleme werden in der Laborumgebung reproduziert, bevor Fixes ausgeliefert werden. Das unterstützt sicherere Upgrades über eingesetzte Charger-Umgebungen.

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 ein wiederverwendbares Engineering-Asset zur Beschleunigung der OCPP-Auslieferung. Es ist kein Boxed-Protokoll-Stack. OCPP-fokussierte Integrationsprojekte können von dieser Architektur ausgehen, wo sie das Auslieferungsrisiko reduziert, und sie an die spezifische Charger-Hardware und CSMS-Anforderungen anpassen.

Die sechs Schichten trennen Zuständigkeiten und sind darauf ausgelegt, die Ausbreitung von Änderungen über die Architektur zu begrenzen. Ein Wechsel von einem Infineon- auf einen NXP-MCU wird vorrangig in der Hardware-Abstraktionsschicht behandelt. Protokollkern, Kommunikationslogik und Sicherheitsdurchsetzung darüber sollen stabil bleiben, wo möglich. Diese Kapselung macht die Architektur projektübergreifend wiederverwendbar und unterstützt einen kontrollierten Engineering-Pfad in Richtung OCPP 2.1, während vermeidbares Rewrite-Risiko reduziert wird.

Für Kunden: reduziertes Regressionsrisiko beim Upgrade von Protokollversionen, vorhersagbarere Validierung über Ziel-CSMS-Umgebungen und testbare Upgrade-Pfade von 2.0.1 in Richtung 2.1.

  • 1. Protocol Core
    Nachrichtenrouting, Zustandsmaschine, Profilverwaltung, Device-Model-Handling. Diese Schicht implementiert die OCPP-Spezifikation direkt.
  • 2. Communication
    WebSocket-Transport, JSON-Kodierung und -Dekodierung, Retry-Logik, Session-Management. Behandelt das Wire-Protokoll zwischen Ladegerät und CSMS.
  • 3. Security
    TLS-Session-Aufbau, Zertifikats-Lifecycle (Bereitstellung, Verlängerung, Widerruf), Sicherheitsprofil-Durchsetzung für die erforderlichen OCPP-2.0.1-Profile.
  • 4. Hardware Abstraction
    Chip-spezifische Treiber, I/O-Adapter, Hersteller-Isolation, Capability-APIs. Konzipiert für Anpassung über mehrere MCU-Familien.
  • 5. Diagnostics
    Strukturiertes Logging, Metriken-Erfassung, Fehlerberichterstattung. Konzipiert für Feld-Debugging, wenn physischer Zugang zum Ladegerät eingeschränkt ist.
  • 6. Lifecycle
    Boot-Sequenzierung, geordnetes Herunterfahren, Firmware-Update-Management, Recovery-Prozeduren. Behandelt die Betriebszustände, die OCPP nicht spezifiziert, die Produktions-Ladegeräte aber erfordern.
Protocol Core
Communication
Security
Hardware Abstraction
Diagnostics
Lifecycle

FlexCharge.OCPP: 6-Schichten-Architektur

Vollständige FlexCharge-Architektur ansehen

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. Neue Clemios-OCPP-Auslieferung orientiert sich an OCPP 2.0.1, es sei denn, Migrations-Randbedingungen erfordern OCPP-1.6-Behandlung.

Clemios implementiert den OCPP 2.0.1-Kern und relevante optionale Profile, die für sicheren Betrieb, Firmware-Management, Diagnostik und CSMS-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 kontrollierter Upgrade-Pfad ist, kein unkontrollierter Protokoll-Reset.

Clemios entwirft OCPP-Implementierungen mit Vorwärtskompatibilität als Grundprinzip. Versions-Upgrades werden durch klare Trennung von Protokolllogik, CSMS-Integration und gerätespezifischem Verhalten umgesetzt. Das reduziert Regressionsrisiko und vermeidet unnötige parallele Protokollstacks auf dem Pfad von OCPP 2.0.1 in Richtung 2.1.

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 neue Clemios-OCPP-Auslieferung orientiert sich an OCPP 2.0.1.

OCTT ist das Konformitätstest-Tool der Open Charge Alliance. Clemios nutzt OCTT als Teil des Interoperabilitäts- und Validierungsprozesses zur Verifizierung des Protokollverhaltens. OCTT-Status ist ausschließlich Methodik-Ausrichtung. Kein OCA-Zertifizierungsanspruch wird erhoben.

OCPP-Engineering bereit für die Auslieferung

OCPP-2.0.1-Auslieferung, Interoperabilitätsvalidierung oder den Pfad in Richtung 2.1 abklären, bevor Implementierungsrisiken eskalieren.

Engineering-Gespräch anfragen OCPP-Readiness-Checklist
Nach oben scrollen