eMobility-Softwareentwicklungspartner für EV-Ladesysteme

eMobility › eMobility Engineering
EMOBILITY-SERVICE

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.

ENGINEERING-LIEFERUNG

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.

DELIVERY-BESCHLEUNIGER

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.

6
Architekturschichten
OCPP 2.0.1
Aktiv implementiert
OCPP 2.1
In Entwicklung
FlexCharge-Architektur entdecken →

Arbeitsmodell

  • Engineers eingebettet in Kunden-Sprints, nicht hinter einer Ticket-Warteschlange
  • Gemeinsame Repositories, Demos und Liefertakt
  • Koordiniert aus Deutschland
LIEFERMODELL

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 anfordern
PROTOKOLLTRANSPARENZ

Protokollstatus

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.

Nach oben scrollen