eMobility Engineering für produktionsreife EV-Ladesysteme
Für Charger-OEMs und CPOs: OCPP 2.0.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.0.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.0.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.0.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.0.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 aktiv implementiert. 1 in aktiver Entwicklung. 2 zukünftige Fähigkeiten. 2 Integrationsunterstützung. 1 aktiv getestet.
Wischen für alle Spalten →
| Protokoll | Engineering-Status | Lieferverfügbarkeit | Bedeutung |
|---|---|---|---|
| Kern-OCPP | |||
| OCPP 2.0.1 | Aktiv implementiert | Verfügbar für OCPP 2.0.1-Auslieferung im definierten Umfang | Auf realer Ladegeräte-Hardware validiert mit strukturierter Funktionsprofil-Abdeckung. |
| OCPP 2.1 | In Entwicklung | Noch nicht für Kundenprojekte verfügbar | Aktive Engineering-Arbeit, noch nicht in Kunden-Deployments angeboten. |
| Zukünftige Standards | |||
| ISO 15118-2 | Zukünftige Fähigkeit | Nicht verfügbar (zukünftige Fähigkeit) | Auf dem Entwicklungshorizont für Plug&Charge und TLS-basierte Kommunikation. |
| ISO 15118-20 | Zukünftige Fähigkeit | Nicht verfügbar (zukünftige Fähigkeit) | Auf dem Entwicklungshorizont für bidirektionale Energieübertragung. |
| 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 gegen OCTT-Praktiken getestet, nicht zertifiziert. |
| 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 · In Entwicklung = in aktiver Engineering-Arbeit, nicht für Kunden nutzbar · Zukünftige Fähigkeit = auf dem Entwicklungshorizont · Integrationsunterstützung = in Projekten adressierbar, kein Ladegeräte-Kernprotokoll · Aktiv getestet = Tests mit OCTT-Methodik, nicht zertifiziert | |||
Häufig gestellte Fragen
Embedded-Firmware, OCPP 2.0.1-Protokollintegration, 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 Ziel-CSMS-Umgebungen 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.0.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.
Inkrementell. Jeder Funktionsblock wird unabhängig aktualisiert, während der Protokollkern stabil bleibt. Start auf 2.0.1 heute, Umstieg auf 2.1, wenn das Backend und die Geschäftsanforderungen bereit sind.
Nein. Clemios baut keine neuen Systeme auf OCPP 1.6. Die Engineering-Baseline ist OCPP 2.0.1, und alle Werkzeuge, Tests und Architektur basieren auf dem modernen Protokoll.
Ein eMobility-Engineering-Projekt starten
OCPP 2.0.1-Integration, Embedded-Firmware, Backend-Anbindung und Real-Hardware-Validierung für ein produktionsreifes EV-Ladesystem planen. OCPP 2.1 bleibt in Entwicklung.