OCPP 2.1 ist der aktuelle Clemios-Produktionsstandard. Es bietet Funktionen wie Ad-hoc-Bezahlung und bidirektionales Laden (V2X). Da Clemios OCPP 2.1 aktiv implementiert hat, liefern wir direkt zertifizierungsbereite Systeme auf Basis von 2.1 aus.

Welche Rolle spielt der Hardware Abstraction Layer (HAL)?

Der Clemios HAL entkoppelt die OCPP-Protokolllogik von der spezifischen Hardware-Peripherie. Dies ermöglicht es Herstellern, Steuerungskomponenten zu wechseln, ohne den gesamten Protokollstack neu entwickeln zu müssen. Der HAL liefert die nötige Abstraktion für metrologische Integration und Eichrecht-Konformität.

Wie unterstützt Clemios das deutsche Eichrecht?

Clemios integriert metrologische Anforderungen direkt in den Software-Architektur-Stack. Durch die Nutzung des Hardware Abstraction Layers (HAL) werden signierte Messdaten sicher vom Zähler bis zum Backend transportiert, um die Anforderungen an die Transparenzsoftware und metrologische Logbuch-Führung zu erfüllen.

Wie handhabt Clemios OCPP-Zertifizierungen?

Clemios entwirft Implementierungen so, dass sie "Certificate-ready" sind. Wir begleiten den gesamten Prozess von der Protokoll-Implementierung bis zur Vorbereitung für die offizielle OCA-Zertifizierung. Durch den Einsatz des OCTT (OCPP Compliance Test Tool) minimieren wir das Risiko von Fehlern vor dem Gang ins Testlabor.

Was ist OCTT und wie nutzt Clemios es?

OCTT ist das Konformitätstest-Tool der Open Charge Alliance. Clemios nutzt OCTT aktiv, um die Protokoll-Konformität während der Entwicklung zu validieren. Dies stellt sicher, dass unsere Implementierungen technisch bereit für die offizielle OCA-Zertifizierung sind.

eMobility › OCPP Engineering

OCA-Mitglied seit 2026

OCPP 2.1 als Produktionsstandard. Bereit für Zertifizierung.

Clemios liefert zertifizierungsbereites OCPP 2.1 als neuen Produktionsstandard. Durch die Integration eines Hardware Abstraction Layers (HAL) gewährleisten wir eine zukunftssichere Charger-to-Backend-Kommunikation, die vollständig auf metrologische Standards und das deutsche Eichrecht ausgerichtet ist. 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.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.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.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.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 der Produktionsstandard für OCPP 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.1 ist die Produktions-Baseline. Zukünftige Protokoll- und Firmware-Upgrades werden 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.

AKTUELLE STANDARDS

OCPP 2.1 Produktionsstandard

Aktiv implementiert. Bereit für Zertifizierung. Optimiert für Hardware Abstraction Layer (HAL) und metrologische Integration.

OCTT Aktiv getestet mit OCTT

Konformitätsvorbereitungs-Methodik. Bereit für die formale OCA-Zertifizierung.

LEGACY & HINTERGRUND

OCPP 1.6 Migrations-Support

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

Gesteuert durch Engineering-Freigabe, nicht durch Marketing.

OCPP-Integrationsmethodik

Bewerten

Ladegeräte-Hardware, bestehende Firmware, CSMS-Anforderungen und Ziel-OCPP-Version prüfen. Neue Clemios-OCPP-Auslieferung orientiert sich an OCPP 2.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.

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.

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.

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.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 für OCPP 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.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 mit OCPP 2.1 als neuen Produktionsstandard. Durch einen Hardware Abstraction Layer (HAL) und metrologische Integration sind die Implementierungen auf volle Zertifizierungsbereitschaft und das deutsche Eichrecht ausgelegt. Clemios baut keine neuen Systeme auf OCPP 1.6.

Was ist OCPP 2.1?

OCPP 2.1 ist der aktuelle Clemios-Produktionsstandard. Er ergänzt kritische Funktionen für bidirektionales Laden, verbessertes Smart Charging und volle Zertifizierungsbereitschaft. Alle neuen Clemios-OCPP-Projekte werden mit Version 2.1 als Basis umgesetzt.

Welche OCPP-Profile implementiert Clemios?

Clemios implementiert den OCPP 2.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.

Wie stellt Clemios sicher, dass OCPP 2.1 mit unterschiedlichen CSMS-Systemen funktioniert?

Clemios validiert jede OCPP-2.1-Implementierung gegen mehrere Ziel-CSMS-Umgebungen, nicht nur gegen einen Referenzserver. Das deckt Abweichungen bei optionalen Feldern, Session-Handling und Fehlerverhalten auf, bevor sie im Feld auftreten.

Wie handhabt Clemios OCPP-Upgrades?

Clemios nutzt einen Hardware Abstraction Layer (HAL), um die Protokolllogik von den zugrunde liegenden Hardware-Controllern zu trennen. Dies ermöglicht eine nahtlose Migration zwischen OCPP-Versionen (1.6 bis 2.1) ohne Neuschreiben von Treibercode, reduziert Regressionsrisiken und gewährleistet metrologische Integrität bei Hardware-Wechseln.

Unterstützt Clemios OCPP 1.6?

Clemios baut keine neuen Systeme auf OCPP 1.6. Die Produktions-Baseline beginnt bei OCPP 2.1. Migration bestehender OCPP-1.6-Systeme kann bei Bedarf unterstützt werden, aber neue Clemios-OCPP-Auslieferung orientiert sich an modernen Standards.

Was ist OCTT und wie richtet sich Clemios daran aus?

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-Implementierungen werden aktiv mit OCTT getestet, um volle Konformität und die Bereitschaft für die formale OCA-Zertifizierung sicherzustellen.

OCPP-Engineering bereit für die Auslieferung

OCPP-2.1-Auslieferung, Interoperabilitätsvalidierung oder den Weg zur Zertifizierung abklären, bevor Implementierungsrisiken eskalieren.

Engineering-Gespräch anfragen OCPP-Readiness-Checklist