eMobility Engineering, das liefert – vom Ladegerät bis zur Cloud
Validiert auf realer Hardware, gegen reale CSMS. Firmware, Smart Charging und vollständige Backend-Integration, die in Produktion geht.
Ladegerät-zu-Backend-Integration
Clemios verantwortet den gesamten Softwarepfad zwischen einem physischen Ladegerät und seinem CSMS.
OCPP-Implementierung, sichere Kommunikation, Nachrichtenrouting, Gerätemodell-Management und Backend-API-Anbindung – geliefert als ein integrierter Stack.
Die gesamte Firmware läuft auf realer OEM-Hardware, nicht auf Simulatoren. Der Code zielt auf den tatsächlichen MCU, verbindet sich mit dem Produktions-CSMS und wird unter realen Betriebsbedingungen validiert.
Smart-Charging-Funktionen
Smart Charging ist keine einzelne Funktion. Es ist ein Satz koordinierter Fähigkeiten, die zusammenarbeiten müssen.
Lastmanagement, Energieplanung, tarifabhängiges Laden und netzreaktives Verhalten. Jede Funktion interagiert mit unterschiedlichen OCPP-2.0.1-Funktionsblöcken.
Jede Smart-Charging-Funktion wird gegen mehrere CSMS-Implementierungen getestet, um korrekte Verarbeitung über verschiedene Anbieter hinweg zu verifizieren.
Jedes Projekt profitiert von FlexCharge.OCPP
FlexCharge.OCPP ist ein wiederverwendbares Engineering-Asset. Es ist eine modulare OCPP-Implementierung, die als Ausgangspunkt für jedes eMobility-Projekt eingesetzt wird. Statt OCPP-Code von Grund auf zu schreiben, werden produktionserprobte 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 über frühere Deployments validiert wurde.
Protokollstatus
Clemios veröffentlicht den Protokollstatus offen. Keine vagen Leistungsangaben. Kein „unterstützt“ ohne Kontext. Diese Tabelle zeigt den exakten aktuellen Stand:
Wischen für alle Spalten →
| Protokoll | Engineering-Status | Nutzung in Kundenprojekten | Bedeutung | Zuletzt geprüft |
|---|---|---|---|---|
| OCPP 2.0.1 | Aktiv implementiert | In Kundenprojekten eingesetzt | In realer Ladegeräte-Hardware mit vollständiger Profilunterstützung eingesetzt. | März 2026 |
| OCPP 2.1 | In Entwicklung | Noch nicht für Kundenprojekte verfügbar | Aktive Engineering-Arbeit, noch nicht in Kunden-Deployments angeboten. | März 2026 |
| ISO 15118 | Zukünftige Fähigkeit | Nicht verfügbar (zukünftige Fähigkeit) | Auf dem Entwicklungshorizont, noch nicht implementiert. | März 2026 |
| IEC 61850-104 | Zukünftige Fähigkeit | Nicht verfügbar (zukünftige Fähigkeit) | Auf dem Entwicklungshorizont für Netzintegrations-Anwendungsfälle. | März 2026 |
| VDV 261/463 | Zukünftige Fähigkeit | Nicht verfügbar (zukünftige Fähigkeit) | Relevant für öffentliches Nahverkehrsladen, noch nicht implementiert. | März 2026 |
| OCTT | Aktiv mit OCTT getestet | Nur Methodik-Ausrichtung | Aktiv gegen OCTT-Praktiken getestet, nicht zertifiziert. | März 2026 |
| Diese Tabelle wird aktualisiert, wenn sich der Clemios-Protokollstatus ändert. Sie wird durch Engineering-Freigabe gesteuert, nicht durch Marketing. | ||||
| Aktiv implementiert = produktionsreif und eingesetzt · In Entwicklung = in aktiver Engineering-Arbeit, nicht für Kunden nutzbar · Zukünftige Fähigkeit = noch nicht implementiert · Aktiv getestet = Tests mit OCTT-Methodik, nicht zertifiziert | ||||
Liefermodell
Clemios Engineers arbeiten als Erweiterung des Kunden-Engineeringteams. Eingebunden in bestehende Workflows, verantwortlich für die Lieferung.
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. Wenn etwas im Feld ausfällt, debuggen Clemios Engineers es gemeinsam mit dem Kundenteam.
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, bis Systeme in Produktion laufen.
Angebot anfordernHäufig gestellte Fragen
Den gesamten Pfad vom Ladegerät zum Backend: Protokoll-Stack, sichere Kommunikation, Nachrichtenrouting, Gerätemodell und Smart Charging (Lastmanagement, Energieplanung, netzreaktives Verhalten). Geliefert als ein integrierter Stack auf OCPP 2.0.1, getestet gegen mehrere CSMS-Implementierungen vor der Übergabe.
ESP32, Infineon, Microchip, NXP, Renesas, STMicroelectronics, Texas Instruments und Hilscher netX 90 auf Linux, FreeRTOS und Bare-Metal-Targets. Neue MCU-Familien können ohne Änderung der Protokolllogik übernommen werden.
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 und 2.1 auf realer Hardware, validiert gegen reale Backends, produktionsbereit.