Prototypische Umsetzung

Veröffentlichungsdatum

3. Februar 2026

IT‑Struktur und Kommunikationsaufbau

Ausgangslage:

Für Tests unter realitätsnahen Bedingungen sollte ein End‑to‑End‑Datenfluss zwischen der FHV‑Serverumgebung und der physischen Ladeinfrastruktur hergestellt werden. Dafür waren CPMS‑seitige Schnittstellen (Steuerung und Monitoring), hierarchische Leistungsgrenzen (Station/Ladepunkt), sowie eine QA‑Umgebung zur risikofreien Erprobung erforderlich. Die direkte Integration von Lademanagement‑Algorithmen war nicht Ziel der prototypischen Umsetzung; stattdessen stand die technische Durchgängigkeit des Sende‑ und Rückkanals im Vordergrund.

Ziel:

  • Automatische Senden von Fahrzeugspezifischen Ladeprofilen in Echtzeit an einzelne Ladepunkte über das CPMS.
  • Empfang von Mess‑ und Statusdaten in Nahe‑Echtzeit zur Überwachung des Ladevorgangs.
  • Sichere, reproduzierbare IT‑Kopplung in einer QA‑Backend‑Umgebung für Vor‑Ort‑Tests.

Die Lösung:

Es wurde eine modulare IT‑Architektur aufgebaut, die Ladeprofile von der FHV‑Serverumgebung an das EVO‑CPMS überträgt und Monitoring‑Daten zurückliefert — ohne produktive Einbindung der Lademanagement‑Algorithmen.

IT-Loop Prototyp

IT-Loop Prototypische Umsetzung
  • FHV‑Server (Prototyping/Dispatch)
    • Erzeugt Ladeprofile/Leistungs‑Setpoints (z. B. Zeitreihe [t, P_set]) und übermittelt sie per CPO‑REST‑API an das CPMS.
    • Abonniert MQTT‑Topics für Near‑Real‑Time Monitoring (Status, Leistung, Energie) zwecks Soll/Ist‑Abgleich und Testauswertung.
    • Erstellt Zuordnung zwischen Session-ID, Ladepunkt-ID, Fahrzeug-ID verschiedener Systeme.
  • EVO‑CPMS (CPO/EMP, OCPP, MQTT)
    • CPO‑REST‑API: Annahme von dynamischen Leistungs‑Limits und Ladeprofilen auf Stations‑ und Ladepunkt‑Ebene.
    • EMP‑REST‑API: Bereitstellung der Fahrzeug-ID an Ladepunkten.
    • OCPP 1.6j: Weiterleitung der Vorgaben an die Ladestationen
    • MQTT‑Broker: Bereitstellung von Status- und Messdaten (Leistungen, Energiewerte, Stati).
    • QA‑Umgebung: Mandanten‑ und risikogetrennte Integration des FHV‑Servers in das EVO‑Backend.
  • Kommunikationsablauf (IT‑Loop, prototypisch)
    • Monitoring: MQTT‑Stream liefert information zu Verbindungs-Status und Ladepunkt-ID an FHV-Server.
    • Mapping: FHV-Server liefert Ladepunkt-ID an EMP-API und erhält ID von verbundenem Fahrzeug.
    • Profilbereitstellung: FHV generiert Ladeprofile für konkretes Fahrzeug am Ladepunkt.
    • Dispatch: Übermittlung der Ladeprofile an CPO‑API.
    • Durchleitung: CPMS übergibt Profile via OCPP an Ladestationen.
    • Monitoring: MQTT‑Stream liefert Ist‑Werte & Status zurück an FHV.
    • Auswertung: Soll/Ist‑Vergleich