Wiederholtes Senden aktualisierter Charging Requests

[hellner-init]

Aktuelles Verhalten klarstellen
Für BMS nur Antwort auf letzte Request relevant
Unklar welche Request Information bei ProcessInformation Nachricht beachtet wurden

In Konfliktbehandlung AG besprechen

[DohmenClaus]

Notiz aus der Sitzung am 14./15.04.2025:
Das Zeitverhalten von BMS und LMS beim mehreren aufeinanderfolgenden Anfragen eines BMS ist nicht sauber beschrieben.
ToDo: Sauberer beschreiben, dass die ChargingInformation NICHT eine Antwort auf einen bestimmten Stand der ChargingRequests ist, sondern ein aktueller Stand.
Sie ist nicht zu verwechseln mit der Confirmation, die auschließlich eine Quittung über den Erhalt einer eines ChargingRequest darstellt, ohne das daraus eine Aussage über die Verarbeitung im LMS abgeleitet werden kann.
(s. Version 1.1.0, S. 41, Ende erster Absatz: " Eine Bestätigung hat nicht den Anspruch, dass die Nachricht bereits verarbeitet wurde."

[mafrenzelpsi]

In der letzten AG-Sitzung in Hamburg ist mir klar geworden, dass eine Betrachtung des Gesamtsystems als regelungstechnischer Prozess in der VDV 463 Schrift fehlt. Das Zusammenspiel des Gesamtsystem lässt sich m.E. so vereinfacht darstellen:

1. ChargingRequest (Sollwert): Das eBMS gibt eine strategische Planvorgabe. Dies geschieht in größeren Intervallen (Minuten).
2. Confirmation (Quittung): Eine reine Empfangsbestätigung auf Kommunikationsebene. Sie bedeutet nur "Nachricht erhalten", nicht "Wird jetzt oder ist bereits umgesetzt".
3. Systemträgheit (Regelstrecke): Das Lademanagement (LMS) berechnet die Leistungsvorgaben zyklisch (z.B. alle 30s) und die Ladestation reagiert darauf mit einer physikalischen Verzögerung (i.d.R. 20-40s).
4. ChargingInformation (Ist-Zustand & Prognose): Das LMS meldet den aktuellen IST Zustand der Ladeprozesse und der Ladepunkte sowie eine eigene Prognose der Ladeprozesse auf Basis der aktuell vorliegenden Charging Requests am Ende jedes Zyklus.

Die Interaktion zwischen eBMS und LMS folgen demnach den Prinzipien eines Regelungssystems mit signifikanten Systemlatenzen (LMS-Berechnungszyklen von ca. 30s, physikalische Reaktion der Ladeinfrastruktur von 20-40s). Daraus leitet sich eine klare Anforderung an das anfragende System (eBMS) ab: Die Frequenz der ChargingRequests muss auf die Verarbeitungsgeschwindigkeit des LMS abgestimmt sein. Das Senden von Anfragen in einer deutlich höheren Frequenz als der Berechnungszyklus des LMS ist ineffektiv und daher zu vermeiden.

Diese Ergänzung zu den angenommenen Regelkreisen löst natürlich nicht die bereits diskutierten Probleme, dass a) das Vorsystem nicht eindeutig zuordnen kann auf welche Version der Ladeanfragen sich die Prognose in Charging Information bezieht und b) das LMS in einem Zyklus die Berechnung der Prognose nicht abgeschlossen haben kann. Für a) wurde diskutiert den das Datum der berücksichtigten Ladeanfrage zurück zu melden, für b) wurde diskutiert einen PrognoseStatus pro Ladepunkt zu ergänzen.

[DohmenClaus]

Weitere Diskussion im Rahmen der Konfliktbearbeitungs-Gruppe, Berücksichtigung der Kommentare von IVU (Jörg Decker, Anna Hutfils), Einbindung in Diskussion der Konfliktbearbeitungs-Gruppe

[BenjaminKowatschVector]

Vorschlag zur Auftrennung von Ist-Informationen und Planungs-Informationen muss noch genauer ausgearbeitet werden.
Zuordnung zur Version muss noch geklärt werden, sobald der Vorschlag genauer ausgearbeitet ist.
Weitere Diskussion im Rahmen der Konfliktbearbeitungs-Gruppe