Beschreibung prüfen: Sind die Nutzung von dem Löschen und "TERMINATE" von Ladeanfragen eindeutig beschrieben?

[hellner-init]

[DohmenClaus]

Notiz aus der Sitzung am 14./15.04.2025:
Unterschied zwischen Terminate (Abbrechen laufender Ladevorgang) und Delete (weglassen Ladeanfrage) in VDV463 klarmachen. Es gibt keine explizite "Delete" Operation, sondern dies geschieht implizit durch das Weglassen des zu löschenden ChargingRequest in einer erneuten Sendung der chargingRequestList.

[DohmenClaus]

Gustav Thiesing prüft

[DohmenClaus]

Anmerkung: das implizite "Delete" ist zu überdenken, falls mehrere BMS Anfragen an ein LMS schicken können, vgl. #42

[MoritzHalm]

Denke die Spec lässt folgende Punkte offen:

• Wie soll die ChargingInstruction "Terminate" vom DMS verwendet werden? Sehe mindestens 2 Möglichkeiten:
  1. DMS setzt ChargingRequest einmalig auf Termiante und dann wieder auf Normal und muss dann vom LMS abgebrochen werden.
  2. ChargingRequest wird auf Terminate und muss dann auf Terminate bleiben bis er vom DMS gelöscht werden.
• Impliziert Löschen des ChargingRequests ein Terminate? Falls nein, wie kann das DMS dann Ladevorgang beenden und löschen (z.B. einmal terminate schicken und in der nächsten Nachricht löschen)?
• Was bedeutet es, einen geplanten ChargingRequest ohne laufenden ChargingProcess auf Terminate zu setzen? Oder soll das nicht vorkommen und kann vom LMS ignoriert werden?

[gthiesing]

1. den Text in Kaiptel 2.1.1 präzisieren
   • Normal: Es ist ein normaler bzw. neuer Ladeauftrag
   • Changed: Ein bestehender Ladeauftrag wurde geändert bzw. aktualisiert
   • Terminate: Ein bestehender Ladeauftrag (ChargingRequest, vgl. 2.2.1) ist sofort abzubrechen.

2. Es muss in Kapitel 2.2 eindeutig festgelegt oder sollte mindestens als Implenetationshinweis empfohlen werden, wie ein LMS mit sich überschneidenden ChargingRequests umgeht.
   Beispiel: Das LMS arbeitet einen ChargingRequest_1 ab, das DMS sendet einen ChargingRequest_2, anschließend sendet das DMS einen ChargingRequest_3, während das LMS noch den ChargingRequest_1 bearbeitet:

• a) verwirft das LMS den ChargingRequest_2 und arbeitet den ChargingRequest_3 ab, wenn es die Bearbeitung des ChargingRequest_1 beendet hat
  oder
• b) arbeitet das LMS die ChargingRequests nach FIFO-Methode seriell ab.

3. Bezüglich der Frage des Beendens von vorher gestarteten ChargingRequests ist folgendes zu beachten:
   Das Attribut 'chargingInstruction' ist in ChargingRequest optional, damit muss - unabhängig von den unter 2. aufgeführten Verhaltensweisen - ein 'Terminate' zu einem bestehenden ChargingRequest ein identisches Verhalten auslösen wie ein Weglassen des ChargingRequest aus der ChargingList.
   ==> Der Enum-Wert 'Terminate' in ChargingRequest ist identisch und damit redundant zum Weglassen des ChargingRequest

4. Das erstmalige Auftreten eines ChargingRequest in einer ChargingList bedeutet das Auslösen eines neuen Ladeauftrags.
   ==> Der Enum-Wert 'Normal' in ChargingRequest ist identisch und damit redundant zum Einfügen eines neuen ChargingRequests

5. Das Auftreten eines geänderten ChargingRequest in einer ChargingList bedeutet die geänderte Anforderung für einen
   bestehenden (in Bearbeitung befindlichen) Ladevorgang, siehe Kapitel 2.2.1.
   'chargingProcessId (optional): Referenz auf den Ladevorgang, der mit diesem Ladeauftrag geändert wird.
   Diese Referenz muss zwingend angegeben werden, wenn es sich um einen Ladeauftrag handelt,
   zu dem das LMS bereits Informationen geliefert hat.'
   ==> Der Enum-Wert 'Changed' in ChargingRequest ist identisch und damit redundant zum Senden eines ChargingRequests mit einer bestehenden chargingProcessId

Alle drei Stati werden durch das Verhalten des Vorsystems eindeutig abgedeckt,
==> das Attribut 'chargingInstruction' kann - und sollte der Eindeutigkeit halber - entfallen, damit die oben aufgeführten Diskrepanzen nicht auftreten können.

[gthiesing]

Use Case: mehrere DMS beliefern ein LMS mit Charging Lists:

Dann muss explizit ein 'Terminate' für einen bestehenden Prozess gesendet werden, d.h. das Attribut 'chargingInstruction' ist in diesem Fall nicht optional sondern die einzige Möglichkeit, einen Ladeprozess abzubrechen.

Die Verarbeitung der ChargingLists muss dann vom LMS seriell nach FIFO-Methode erfolgen, um keine Auslassungen zu erzeugen oder ChargingRequest' muss eine Vorsystem-Identifikation 'presystemId' erhalten wie ScheduledChargingprocess..