Allgemeiner Abgleich der VDV-Schrift 261 Edition 2 mit den Angaben im Spezifikationsdokument und im Schema

[maikwoehl-psi]

Die Arbeitsgruppe hat im heutigen Gespräch am 04.07.2023 entschieden, dass wir die VDV-Schrift 463 im Allgemeinem gegen die neue Edition 2 der VDV-Schrift 261 prüfen wollen.

Dies hängt mit PR #16 zusammen.

• [ ] VDV-intern werden die Beweggründe zur Änderung der Datentypen in Edition 2 abgefragt
• [x] Schriften vergleichen
• [x] Ergebnis aufbereiten und der Arbeitsgruppe präsentieren
• [ ] @BenjaminKowatschVector Bild aktualisieren (siehe #30 )

Die Aufgabe soll idealerweise bis zum kommenden Treffen am 25.10.2023 erledigt werden.

[maikwoehl-psi]

Wir haben es doch noch geschafft folgende Aussage bis heute zum Arbeitsgruppentreffen auszuarbeiten. Dies wird ggbf. heute diskutiert.

Wir möchten empfehlen sich in der Arbeitsgruppe 463 zu folgenden Themen zu beraten:

1. Bereitstellung der Umlaufdistanz an den VDV261-Parameter target_dist durch einen neuen Wert in ChargingRequestData.
2. Aktualisierung der Enumeration von PreconditioningRequest, um der Änderung in VDV261 zu entsprechen.
3. Wertebereiche für bestimmte Werte (z.B. SoC) im JSON-Schema vorgeben.
4. Bei Einhaltung der Aussage „Die Zustände entsprechen den Festlegungen der VDV261.“ Müsse die Enumeration zu VehicleChargingStatus der geänderten Enumeration in VDV261 angepasst werden.

Im Allgemeinen empfehlen wir Änderungen, die sich unmittelbar aus der Kompatibilität zur VDV-Schrift 261 ergeben, im Dokument zu kennzeichnen. Ein ergänzter Enumerationswert könne im Dokument mit einem Hinweis auf die Ergänzung in VDV-Schrift 261 versehen werden. Ein geänderter Enumerationswert könne im Dokument mit einem Hinweis auf die unterschiedliche Interpretation in VDV-Schrift 261 versehen werden. Solange der geänderte Enumerationswert seine primäre Bedeutung beibehält, kann die textuelle Ausprägung geändert werden.

Im JSON-Schema wird zwischen integer und number unterschieden. Die konkrete Interpretation dieser Werte obliegt den Parser-Programmen in der jeweiligen Programmiersprache und der konkreten Verwendung des Parser-Ergebnisses in der Anwendung und nicht zuletzt dem Betriebssystem und Prozessor. Vereinfacht kann jedoch festgestellt werden, dass der Umstieg auf vorzeichenbehaftete Ganzzahlen keine Änderung im Schema erfordert. Die Implementierungen müssen dies jedoch berücksichtigen, weshalb ein gut sichtbarer Hinweis in das Dokument eingefügt werden sollte.

[DohmenClaus]

Beschluss 24.10.2023:

• Werte sollen nicht mehr einfach von 261 gelesen und nach 463 weitergegeben werden. Stattdessen Mapping Tabelle und Weitergabe definierter Werte alphanumerischer Werte gemäß einer neuen Enumeration. Dadurch wird auch parallele Behandlung verschiedener 261-Versionen möglich.

• Magic Numbers für SNA sollen perspektivisch nicht mehr weitergegeben sondern stattdessen ein separates SNA-Flag eingeführt werden. b.a.w. soll aber auch noch die alte Lösung der Weitergabe von SNA-Werten möglich sein aber als „künftig wegfallend“ gekennzeichnet werden

• Herr Wöhl und Herr Kowatsch formulieren ein entsprechendes Issue in GitHub #27

[DohmenClaus]

Zu diskutieren in Arbeitsgruppe:

(a) mit Version 1.1 komplette Anpassung an neue Version der 261 (d,h, o.g. Punkte sind noch zu behandeln) oder (b) auch teilweise Anpassung in v1.1 ok (dann z.b. nur Umsetzung von PR #16 ) oder (c) komplette Anpassung an neue Version der 261. aber erst mit Version 2.0 ( dann revert merge bei PR #16 )

Argument für (b) von Herrn Frenzel: Teilweise Umsetzung wurde auch von Fahrzeugherstellern gemacht und bringt Mehrwert für eBMS-Anwender.

[DohmenClaus]

Beschluss der Arbeitsgruppe am 11.4.2024:

Lösung (c), d.h. komplette Anpassung an neue Version der 261 erst mit Version 2.0 ( d.h. revert merge bei PR #16 )