eMobility Engineering für produktionsreife EV-Ladesysteme
Für Charger-OEMs und CPOs: OCPP 2.1-Integration, Embedded-Firmware, Backend-Anbindung und Konformitätsvorbereitung. Validiert auf realer Hardware, von Deutschland gesteuert.
Was muss stimmen, bevor ein EV-Ladesystem in Produktion geht
Protokollintegration und Embedded-Firmware
Die Firmware, die auf einem Ladegerät läuft, muss OCPP korrekt implementieren, zuverlässig mit dem CSMS kommunizieren und reale Betriebsbedingungen bewältigen.
OCPP 2.1-Implementierung, sichere WebSocket-Kommunikation, Nachrichtenrouting, Gerätemodell-Management und Backend-API-Anbindung. Die Firmware zielt auf reale MCUs mit einer Hardware-Abstraction-Schicht, die Protokolllogik von chipspezifischem Code isoliert.
Smart-Charging-Fähigkeiten (Lastmanagement, Energieplanung, tarifabhängiges Verhalten) werden als OCPP 2.1-Funktionsblöcke implementiert und auf korrekte Interaktion mit Backend-Planungssystemen getestet.
Validierung und Produktionsreife
Code, der kompiliert, ist nicht produktionsreif. Produktionsreife erfordert strukturierte Validierung gegen reale Hardware und reale Backends.
Firmware wird auf realer OEM-Hardware validiert, nicht nur in Simulatoren. Die Integration wird gegen Ziel-CSMS-Umgebungen validiert, um Interoperabilität vor der Übergabe zu verifizieren. OCTT-basierte Konformitätsvorbereitung deckt OCPP 2.1-Funktionsprofile systematisch ab.
Diagnostik, Regressionstests über Firmware-Updates und Release-Bereitschaftsprüfungen sind Teil des Engineering-Workflows. Das Ziel ist, dass Systeme release-bereit sind, wenn sie das Engineering verlassen.
Ein wiederverwendbares Engineering-Asset für OCPP 2.1-Auslieferung
FlexCharge.OCPP ist ein wiederverwendbares Engineering-Asset. Es ist eine modulare OCPP-Implementierung, die als Ausgangspunkt für OCPP-fokussierte eMobility-Projekte eingesetzt wird. Statt OCPP-Code von Grund auf zu schreiben, werden intern validierte Komponenten an die Hardware- und Backend-Anforderungen des Kunden angepasst.
Die sechs Architekturschichten (Protocol Core, Communication, Security, Hardware Abstraction, Diagnostics, Lifecycle) sind für unabhängige Anpassung konzipiert. Wenn ein Kunde einen NXP-MCU statt eines STMicroelectronics-Bauteils verwendet, bleiben die Änderungen innerhalb der Hardware-Abstraction-Schicht. Die Protokolllogik darüber bleibt unverändert.
Dieser Ansatz verkürzt Integrationszeiträume. Er reduziert auch das Risiko von Protokoll-Konformitätsproblemen, da die Kernnachrichtenverarbeitung bereits durch strukturierte Engineering-Zyklen validiert wurde.
Von Deutschland gesteuerte Engineering-Auslieferung
Clemios Engineers arbeiten als Erweiterung des Kunden-Engineeringteams. Eingebunden in bestehende Workflows, verantwortlich für die Auslieferung, von Deutschland gesteuert.
Clemios Engineers nehmen an Kunden-Sprints teil, committen in Kunden-Repositories und präsentieren Fortschritte alle zwei Wochen. Das Team arbeitet auf Englisch und Deutsch. Engineering-Governance, Eskalationspfade und Release-Entscheidungen folgen einer dokumentierten Engineering-Governance, die mit dem Kunden vereinbart wurde. Alle Lieferergebnisse sind geistiges Eigentum des Kunden.
Clemios Engineers nutzen KI-gestützte Werkzeuge (RAG, Prompt Engineering, MCP) zur Unterstützung von Code-Analyse und Protokollrecherche. Dies sind Workflow-Werkzeuge, kein Ersatz für Engineering-Urteilsvermögen.
Dies ist keine Lieferantenbeziehung, bei der Anforderungen eingereicht und in die Warteschlange gestellt werden. Clemios stellt Engineers bereit, die die Codebasis, das CSMS und den Release-Prozess verstehen und die rechenschaftspflichtig bleiben durch Übergabe, Launch-Bereitschaft und Produktionssupport-Übergang.
Technisches Scoping-Gespräch anfragenProtokollstatus
Clemios veröffentlicht den Protokollstatus offen. Keine vagen Leistungsangaben. Kein "unterstützt" ohne Kontext. Diese Tabelle zeigt den exakten aktuellen Stand:
1 Produktionsstandard. 0 in aktiver Entwicklung. 2 zukünftige Fähigkeiten. 2 Integrationsunterstützung. 1 aktiv getestet mit OCTT.
Wischen für alle Spalten →
| Protokoll | Engineering-Status | Lieferverfügbarkeit | Bedeutung |
|---|---|---|---|
| Kern-OCPP | |||
| OCPP 2.1 | Implementiert / Zertifizierungsbereit | Produktionsstandard | Vollständig implementiert und bereit für die offizielle Zertifizierung. Enthält Unterstützung für erweiterte 2.1-Funktionen und native 2.0.1-Abwärtskompatibilität. |
| Zukünftige Standards | |||
| ISO 15118-2 | Zukünftige Fähigkeit | Nicht verfügbar (zukünftige Fähigkeit) | Zukünftige Fähigkeit auf dem Entwicklungshorizont für Plug&Charge und TLS-basierte Kommunikation. Derzeit nicht implementiert. |
| ISO 15118-20 | Zukünftige Fähigkeit | Nicht verfügbar (zukünftige Fähigkeit) | Zukünftige Fähigkeit auf dem Entwicklungshorizont für bidirektionale Energieübertragung. Derzeit nicht implementiert. |
| Integrationsumfang | |||
| IEC 60870-5-104 | Integrationsunterstützung | Nicht als eigenständiger Service verfügbar | Im Rahmen von Netzintegrationsprojekten adressierbar. Kein Ladegeräte-Kernprotokoll. |
| VDV 261/463 | Integrationsunterstützung | Nicht als eigenständiger Service verfügbar | Im Rahmen von Nahverkehrs-Ladeprojekten adressierbar. Kein Ladegeräte-Kernprotokoll. |
| Validierung | |||
| OCTT | Aktiv getestet mit OCTT | Nur Methodik-Ausrichtung | Aktiv getestet mit OCTT für Konformitätsvorbereitungs-Praktiken. Kein Zertifizierungsanspruch. |
| Diese Tabelle wird aktualisiert, wenn sich der Clemios-Protokollstatus ändert. Sie wird durch Engineering-Freigabe gesteuert, nicht durch Marketing. | |||
| Aktiv implementiert = auf realer Hardware validiert und aktiv gewartet · Implementiert / Zertifizierungsbereit = vollständig implementiert und bereit für die offizielle Zertifizierung · Zukünftige Fähigkeit = auf dem Entwicklungshorizont · Integrationsunterstützung = in Projekten adressierbar, kein Ladegeräte-Kernprotokoll · Aktiv getestet mit OCTT = Tests mit OCTT-Methodik, kein Zertifizierungsanspruch | |||
Häufig gestellte Fragen
Embedded-Firmware, OCPP 2.1-Integration (zertifizierungsbereit), Hardware Abstraction Layer (HAL), metrologische Integration (Eichrecht), Backend-Anbindung, Diagnostik, Validierungsworkflows und Release-Bereitschaft. Der Umfang deckt den gesamten Pfad von der Charger-Firmware bis zur CSMS-Interoperabilität ab, validiert gegen reale Hardware vor der Übergabe.
Firmware wird auf realer OEM-Hardware validiert, nicht nur in Simulatoren. Die Integration wird gegen Ziel-CSMS-Umgebungen getestet. OCTT-basierte Konformitätsvorbereitung deckt OCPP 2.1-Funktionsprofile systematisch ab. Regressionstests laufen über Firmware-Updates, bevor ein Release als bereit markiert wird.
FlexCharge.OCPP ist ein wiederverwendbares Engineering-Asset, kein fertiges Produkt. Es stellt intern validierte OCPP-Komponenten bereit, die an die Hardware- und Backend-Anforderungen jedes Kunden angepasst werden. Das reduziert Integrationszeiträume und Konformitätsrisiken, ohne Kunden an eine feste Architektur zu binden.
Engineers arbeiten in CET-Überlappung, kommunizieren auf Deutsch und Englisch und folgen einer dokumentierten Engineering-Governance, die mit dem Kunden vereinbart wurde. Eskalationspfade, Release-Entscheidungen und Liefertakt werden von Deutschland gesteuert. Alle Lieferergebnisse sind geistiges Eigentum des Kunden.
ESP32, Infineon, Microchip, NXP, Renesas, STMicroelectronics, Texas Instruments und Hilscher netX 90 auf Linux, FreeRTOS und Bare-Metal-Targets. Die Hardware-Abstraction-Schicht isoliert Protokolllogik von chipspezifischem Code, sodass neue MCU-Familien ohne Neuschreiben des OCPP-Stacks übernommen werden können.
OCPP 2.1 ist bei Clemios bereits vollständig implementiert und bereit für die offizielle Zertifizierung. Wir unterstützen OEMs bei der Migration bestehender Systeme durch unseren Hardware Abstraction Layer (HAL), um neue Funktionen wie bidirektionales Laden oder erweitertes Energiemanagement ohne Hardware-Lock-in zu ermöglichen.
Nein. Clemios baut keine neuen Systeme auf OCPP 1.6. Die Engineering-Baseline ist OCPP 2.1 (inklusive nativer 2.0.1-Unterstützung), und alle Werkzeuge, Tests und Architektur basieren auf diesem Standard.
Ein eMobility-Engineering-Projekt starten
OCPP 2.1-Integration, Embedded-Firmware, Backend-Anbindung und Real-Hardware-Validierung für ein produktionsreifes EV-Ladesystem planen.