Erweiterung ProvideChargepointInformation Meldungen um kritische Tank- bzw. Batteriezustände (VDV 261)

[mafrenzelpsi]

Ab der VDV 261 Ed 2 können Fahrzeuge Informationen über kritische Batterie- und H2-Tankzustände übertragen. Das LMS bekommt diese Informationen über die VDV261 übermittelt und soll diese geeignet dem Vorsystemen EBMS und ITCS via ProvideChargepointInformation zur Verfügung stellen, damit diese etwaige Folgeaktionen einplanen können. Denkbare Vorsystem-Folgeaktionen sind u.a. Alarmierung, Umdisponierung, Notabstellung auf sicheren Stellplätzen, Einplanung von Prüfungen in der Werkstatt.

Dieses Anforderungen wurde am 15.4.25 auf dem AG Sitzung von der Hochbahn eingebracht.

Dieses Ticket kann ggf. dem allgemeinen Ticket zur Prüfung der VDv261 Ed. 2 Neuerungen zugeordnet werden.

[meppingvector]

Ich empfehle die Schnittstellen-Änderung so auszugestalten, dass im Vorsystem auch erkannt werden kann, wenn gar kein Wert empfangen wurde.

[mafrenzelpsi]

Hallo Herr Epping,

Danke für diesen Hinweis. Ich habe mir mal das JSON Schema und die Schrift diesbezüglich angesehen.

Wenn wir die vorhandene TractionBatteryInfo um einen batteryStatus erweitern, dann müssen wir einen Enumarationstyp ausprägen z.B. mit:

• OK: "status of battery is okay"
• NOK: "battery status not okay"
• NA:"battery status not available" (aber von Fahrzeug per VDv261 als nicht verfügbar gemeldet".

Für H2 Tank Status ist etwas mehr nötig. Hier müssen wir eine H2TankInfo mit einem eigenen Enumarationstyp ausprägen.

• OK: „hydrogen system is okay";
• NOK:"hydrogen system is not okay "
• NA:"hydrogen system status not available"

Wenn gar keine VDV261 Kommunikation aufgebaut wurde, werden die optionalen TractionBatteryInfo und H2TankInfo nicht gesendet.

Frohe Ostern, Martin Frenzel

[meppingvector]

@mafrenzelpsi : Hallo Herr Frenzel,

Danke für die Recherche und den Vorschlag. Könnten Sie im Expertenkreis eine Diskussion führen, wie die Werte später im BMS verarbeitet werden? Das ist zwar für die Schnittstellebeschreibung nicht direkt relevant, aber klärt nochmal was genau die Erwartungshaltung ist.

Würde man ausschließlich bei einem "NOK" bzw "CRIT" reagieren, oder auch wenn Werte ausbleiben?

[mafrenzelpsi]

Der Vorschlag wird sicherlich in der AG diskutiert. Die Anwendungsfälle die bisher diskutiert wurden sind oben erwähnt.

Ich persönlich kann mir vorstellen, dass bei ausbleiben des Signals, obwohl der Bus die Edition 2 unterstützt, man dies nutzt um Fehleranalysen einzuleiten. Insbesondere, wenn das Fahrzeug an allen Ladepunkten keine VDV261 Daten liefert. Auch jetzt könnte das EBMS den Disponenten solche informationen anzeigen. M.E. passiert das aber nicht, die Anzeige der VDV261 Daten zur Fehleranalyse erfolgt m.W. primär im LMS.

[meppingvector]

@mafrenzelpsi : Sehr gut, Danke. Ich hatte weniger die Fehleranalyse im Sinn, sondern eine Art von Alarmierung, wenn ein kritischer Zustand erkannt wurde. Ich nehme ja an, das war damals der Grund diese Signale in der Version 2 aufzunehmen. Und da würde mich interessieren, ob der Wert "NOK" / "CRIT" explizit empfangen werden muss oder auch ein Verbindungsabbruch berücksichtigt wird.

Wäre es noch sinnvoll einen Zeitstempel zu ergänzen, von wann die Fahrzeuginformationen sind?

[mafrenzelpsi]

Ja, Alarmierung bei NOK/CRIT ist einer der o.g. Anwendungsfälle. Das NOK/CRIT muss m.E. explizit empfangen werden. M.W. baut das Fahrzeug in der VDV261 für jede Datenübertragung zyklisch eine neue Verbindung auf. Verbindungsabbruch kann also nicht - schon rein technisch- zu einer Alarmierung führen. Das wäre auch gefährlich, wenn dadurch weitere Automatismen wie Alarmierung der Feuerwehr ausgelöst werden würden. Es wird sicherlich aber diskutiert, weil der Inhalt der Tickets gesichtet wird :-)