Prototypische Umsetzung
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.
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.
- 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
CP genaue Ladekurve
Ausgangslage und Ziel
Im Projekt FreeE-Bus wird ein optimiertes Lademanagement für Elektrobusflotten entwickelt, das auf Fahrplandaten, Energiebedarfssimulationen und aktuellen Systemzustände basiert.
Eine Grundvoraussetzung hierfür ist, dass Ladeleistungen fahrzeugindividuell und zeitlich präzise an der Ladeinfrastruktur umgesetzt werden können. Eine rein theoretische Optimierung ist nicht ausreichend - erst wenn jedem Fahrzeug im Betrieb automatisch die passende Ladekurve am jeweiligen Charge Point zugewiesen wird, wird ein optimiertes Ladeökosystem praktisch nutzbar.
In der Praxis bestehen DC-Schnelladesysteme, wie sie im Busbetrieb eingesetzt werden, häufig aus einer Leistungseinheit, die mehrere Ladepunkte bzw. Charge Points versorgt. Für die Umsetzung optimierter Ladepläne ist daher folgende Frage entscheidend zu klären:
Kann die Ladeleistung nicht nur stationsweit, sondern gezielt pro Charge Point und abhängig von der Fahrzeug-ID gesteuert werden?
Ziel der durchgeführten Tests war somit kein Optimierungsnachweis, sondern ein Machbarkeits- und Voraussetzungsnachweis, nämlich der Nachweis, dass individuelle Ladekurven fahrzeugabhängig und Charge Point genau umgesetzt werden können.
Technische Grundlagen/Schematische Darstellung
In der Theorie funktioniert die Charge Point genaue Leistungssteuerung wie folgt:
- Ein Fahrzeug identifiziert sich über eine eindeutige ID (z. B. Ladekarte) an der Ladesäule. Bei Bussen wird diese ID typischerweise direkt über den Ladestecker kommuniziert, sodass keine zusätzliche Authentifizierung erforderlich ist.
- Basierend auf dieser ID wird eine individuelle Ladekurve gezielt auf den jeweiligen Charge Point angewendet.
Was umgangssprachlich häufig als “Ladestation” bezeichnet wird, ist technisch in zwei Ebenen aufgebaut: eine Leistungseinheit, in der die AC/DC-Wandlung erfolgt, sowie die Charge Points (Dispenser), die über den Ladestecker sichtbar sind. Eine Leistungseinheit kann dabei mehrere Charge Points versorgen. Abbildung 1 zeigt beispielhaft eine Station bestehend aus einer Leistungseinheit und zwei Charge Points (Ladepunkten).
Entscheidend ist: Die Steuerung erfolgt nicht auf Ebene der gesamten Ladesäule, sondern CP-genau.
Technische Umsetzung im FreeE-Bus Projekt:
- Backend-Implementierung der Testumgebung durch die E-VO eMobility
- Umsetzung der CP-genauen Steuerlogik durch die Fachhochschule Vorarlberg (FHV)
- Realtests am Depot sowie Koordination des Arbeitspaket durch die Hochschule Ravensburg-Weingarten (RWU)
Versuchsaufbau
Die Umsetzung erfolgte im Rahmen realer Ladetests am Busdepot Loacker. Testumgebung:
- Ladesystem des Herstellers Kempower
- Zwei Leistungseinheiten:
- 1 Einheit mit 4 Ladepunkten (=Charge Points)
- 1 Einheit mit 6 Ladepunkten (=Charge Points)
Um den laufenden Betrieb nicht zu beeinträchtigen, wurde:
- ausschließlich die Einheit mit 4 Ladepunkten verwendet
- diese wurde temporär (~ 4 Stunden) durch die VKW in ein separates Testsystem überführt
Für den Test wurden zwei unterschiedliche Ladekurven im Backend hinterlegt (siehe Abbildung 2), welche jeweils einer ID zugewiesen wurden. Ziel war es, durch aufeinanderfolgende Ladevorgänge am selben Charge Point zu zeigen, dass die jeweils korrekte Ladekurve angewandt wird.
An selben Charge Point wurde nacheinander dasselbe Fahrzeug mit zwei unterschiedlichen IDs authentifiziert - zunächst mit Ladekarte 2, anschließend mit Ladekarte 1.
Dadurch wurde sichergestellt, dass abhängig von der verwendeten ID die jeweils konfigurierte Ladekurve gezielt auf diesen Charge Point angewendet wird.
Für das Backend-System ist dabei unerheblich, auf welchem Weg die ID bereitgestellt wird. Diese kann entweder über die Ladekarte oder - wie im realen Busbetrieb - über die Fahrzeug-ID erfolgen, die direkt über den Ladestecker kommuniziert wird.
Testergebnisse
Wie in Abbildung 3 und Abbildung 4 ersichtlich, werden die konfigurierten Ladekurven abhängig von der jeweiligen ID angewendet. Zusätzlich zeigt die Station die Meldung “Grid Limits”, was darauf hinweist, dass die Leistungsbegrenzung durch das Netz bzw. die stationsseitige Leistungsgrenze verursacht wird und nicht durch das Fahrzeug selbst.
Randbemerkungen:
Bei der Ladekurve für Karten-ID 1 beträgt die vorgegebene Soll-Ladeleistung in den ersten 120 Sekunden 30 kW. Wie in Abbildung 3 zu erkennen ist, wird diese Leistung jedoch nicht erreicht, da das Fahrzeug die Ladeleistung zunächst selber limitiert. Ursache hierfür ist der bereits hohe Ladezustand des Akkus von über 80 %.
Erst ab der zweiten Leistungsstufe mit 20 kW erfolgt die Begrenzung durch den Charge Point bzw. die Station. Dies wird zusätzlich durch die Anzeige “Grid Limits” auf dem Display der Ladesäule bestätigt.
Erkenntnisse
Die Tests zeigen, dass Ladekurven CP-genau und fahrzeugindividuell angewendet werden können. Damit ist eine zentrale technische Voraussetzung für die Umsetzung optimierter und netzdienlicher Ladepläne im Rahmen von FreeE-Bus erfüllt.
Abgrenzung und Ausblick
Physikalische Einschränkungen auf Fahrzeugseite (z. B. Batterietemperatur oder Ladezustand) können dazu führen, dass geplante Ladekurven nicht exakt eingehalten werden (siehe Abbildung 3). Die hinterlegte Ladekurve stellt stets ein Leistungsmaximum dar.
Der Umgang mit solchen Effekten ist Teil zukünftiger robuster Optimierungsansätze und nicht Bestandteil der hier dargestellten Protypischen Umsetzung.
Dank
Wir danken alle beteiligten Personen für ihre Unterstützung, insbesondere Herrn Saban Smailovic von Loacker Tours, siehe Abbildung 5.
