eMobility Engineering, das liefert – vom Ladegerät bis zur Cloud
Für Charger-OEMs und CPOs: Firmware, Smart Charging und vollständige Backend-Integration, validiert auf realer Hardware gegen reale CSMS.
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.
Arbeitsmodell
- Engineers eingebettet in Kunden-Sprints, nicht hinter einer Ticket-Warteschlange
- Gemeinsame Repositories, Demos und Liefertakt
- Koordiniert aus Deutschland
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 anfordernProtokollstatus
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 | Nutzung in Kundenprojekten | Bedeutung |
|---|---|---|---|
| Kern-OCPP | |||
| OCPP 2.0.1 | Aktiv implementiert | In Kundenprojekten eingesetzt | In realer Ladegeräte-Hardware mit vollständiger Profilunterstützung eingesetzt. |
| 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 = produktionsreif und eingesetzt · 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
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.