Ist-Daten-Schnittstellen: Fragen und Antworten (VDV453 und VDV454)

Frage: Wie ist eine Übertragung von Informationen (z. B. Name oder Koordinaten) über Zusatzhalte die nur im Sonderfall (z. B. Schienenersatzverkehr) mit den Ist-Daten-Diensten möglich?

Antwort: Auch Zusatzhalte sollten besser im Sollfahrplan angelegt werden – auch wenn sie im Normalbetrieb nicht angefahren werden. So stehen dann alle Informationen zur Haltestelle grundsätzlich zur Verfügung. (Arbeitsgruppe 29.6.2022)

Frage zur Abo-Handhabung bei Datendrehscheiben:

Wird ein Abo ungültig, wird normalerweise mit einer Erneuerung des Abonnements reagiert. Im laufenden Betrieb müssen Datendrehscheiben in der Lage sein die Erneue-rung eines eingehenden Abonnements zu verarbeiten, ohne dass der eigene StartDienstZst erneuert und abgehende Abos gelöscht und neu aufgebaut werden.

Antwort: Der Server sendet immer nur aktualisierte Fahrten an das Client-System. Das Erneuern eines Abonnements führt nicht mehr zur Meldung einer StatusAnt-wort mit aktualisierten StartDienstZst an ein Client-System.
Dies verhindert das Erneuern des Abonnements durch den Client und somit auch die Übertragung des aktuellen Gesamtdatenbestandes der Datendreh-scheibe für ein gebündeltes Client-Abonnement. Details
(Raffael Rittmeier, 29.6.2022)

Frage: Wieso fehlt "AufASB" in neueren Versionen (ab 2019) in der Struktur "ASBFahrplanlage" .

Antwort:  Das Element wurde entfernt, weil mit Einführung der neuen ASBMeldungsart "BereichErreicht" angenommen wurde, daß man den Fall, daß das Fahrzeug auf dem Anschlußbereich angekommen ist, gut abbilden kann.
Das ist bei DFI anders, weil dort ja ein Fahrzeug auf dem AZB stehen kann und weiter Prognosen sendet, während im ANS-Dienst nach Erreichen des ASB keine weiteren Meldungen mehr zu erwarten sind.
(Matthias Erven 10.2.2022)

Frage: Wurde mit dem FahrtVerband und der FahrtBeziehung (Trennung / Zusammenführung) nicht eine unnötiuge Variante in das Schema gebracht?

Antwort: Die Modellierungsvarianten haben die in ihrem Kontext auch ihre Daseinsberechtigung.
(AG / Juerg Wichtermann 19.6.2017)

Frage: Welcher Hersteller hat die aktuelle VDV-Schrift in welchem Umfang umgesetzt?

Antwort: Die Unterstützung der optionalen Felder in den Schnittstellen der Systemanbieter erfolgt im Rahmen von Projektanforderungen und unter Maßgabe des Leistungsumfangs des eigenen Systems. Hinweise welche Elemente genutzt werden sollen, müssen in der Ausschreibung für das jeweilige Projekt stehen! Alternativ muss die Funktionsbeschreibung definieren, was mit der Schnittstelle erreicht werden soll.
Bei Pflicht-Feldern kann man sich auf das Vorhandensein in der Schnittstelle verlassen. Was an Feldern im liefernden System inhaltlich da ist, wird in der Schnittstelle auch mitgeben.
(AG Ist-Daten-Schnittstellen 5.11.2015)

Frage zu VDV453-DFI und VDV454-AUS LinienID/RichtungsID in IstHalt bei Umleitung in Gegenrichtung in der Mitte des Fahrweges:
Was soll jetzt auf dem parallel befahrenen Abschnitt bei VDV453-DFI und VDV454-AUS für eine RichtungsID gesendet werden?

Antwort: Sowohl auf dem blauen als auch auf dem roten Abschnitt soll RichtungsID «B» gesendet werden. Der Anzeigenbesitzer muss mittels AZBID die Fahrten auf die Anzeiger verteilen.
(AG Ist-Daten-Schnittstellen 5.11.2015)

Frage zur Handhabung von «…PrognoseStatus»: Temporäres Verlassen des Fahrweges:
Nach der dritten Haltestelle positioniert sich der Fahrer plötzlich manuell auf die sechste Haltestelle.
Was soll für die fehlenden Haltestellen 4 und 5 bei Unterstützung des Elementes «IstAnkunft/AbfahrtPrognoseStatus» gesendet werden?

Antwort: Da die Wahrscheinlichkeit gross ist, dass die beiden Haltestellen angefahren wurden, soll in diesem Fall «Geschaetzt» gesendet werden.
(AG Ist-Daten-Schnittstellen 5.11.2015)

weitere Details aus der Sitzung der AG Ist-Daten-Schnittstellen vom 5.11.2015

Frage zu VDV-Schrift 454 (Version 1.1): Mehrfachanfahrt
Wie soll bei Mehrfachanfahrt einer Haltestelle innerhalb einer Fahrt der Halt eindeutig identifiziert werden? (Bei den Diensten (REF)DFI und (REF)ANS aus der VDV-Schrift 453 gibt es hier einen Haltestellensequenzzähler, bei (REF)AUS gibt es beim SollHalt wie beim IstHalt nur die haltID, die die Haltestelle identifiziert.)

Soll bei AUS nun der Haltestellensequenzzähler in die haltID sozusagen hineincodiert werden? (Dies würde allerdings bedeuten, dass verschiedene haltIDs auf die gleiche Haltestelle verweisen.)

Oder muss dann zur Identifizierung die Plan-Ankunft und -Abfahrtszeiten immer mit angegeben werden (Bei Start- bzw. Endhaltestelle natürlich jeweils nur die entsprechende Plan-Zeit)?

Antwort: Der Punkt, den Sie ansprechen, war damals Gegenstand von Diskussionen in der Gruppe. Man verzichtete dann auf einen Haltestellensequenzzähler, da im AUSREF-Dienst ohnehin die komplette Haltestellenfolge einer Fahrt übermittelt wird. Die korrekte Referenzierung der Haltestelle erfolgt dann – genau so wie Sie das selbst vorgeschlagen haben - durch Angabe der jeweiligen Soll-Zeit an der Haltestelle.
(Werner Kohl, MDV - 7/2006) 

Frage zu VDV-Schrift 454 "Fahrplansauskunft" (Version 1.2): Fahrweg 
Wie soll ich als Empfänger von AUS-Nachrichten eine Prognose korrekt fortsetzen, wenn der Fahrweg nicht eindeutig ist? 

Beispiel: 

• Haltestelle A Abfahrtszeit(soll) 10:05 
• Haltestelle B Abfahrtszeit(soll) 10:06 
• Haltestelle C Abfahrtszeit(soll) 10:06 
• Haltestelle D Abfahrtszeit(soll) 10:07 

Gleiche Angaben für Soll-Zeiten für zwei nahe beieinander liegende Haltestellen sind nicht ungewöhnlich, da die Angaben meist nur auf Minutenbasis vorliegen. Damit kann man dann aber nicht sicher entscheiden, in welcher Reihenfolge die Haltestellen B und C angefahren werden. Das kann zu Unsicherheiten bei der Fortsetzung einer Prognose führen (insbesondere bei Verfrühung). Kann man davon ausgehen, dass die Reihenfolge, in der die Haltestellen innerhalb einer Fahrt in der XML-Struktur stehen auch die Reihenfolge auf dem Fahrweg ist? 

Schwierig wird es dann immer noch, wenn ein Zusatzhalt eingeplant werden muss, der mit derselben Abfahrtszeit geliefert wird wie ein bereits vorhandener Halt. Wie erkennt man in diesem Fall die richtige Reihenfolge? 

Antwort: Im AUS-Dienst wird der Fahrweg immer als eindeutig, weil bekannt angenommen. Er ist deshalb auf beiden Seiten bekannt (und identisch), weil er ja für die fragliche Fahrt vorab im AUSREF-Dienst mitgeteilt wurde oder beiden Seiten wegen einer übereinstimmenden Fahrplan-Version (FahrplanVersionID) bekannt ist.´ 

Die Reihenfolge in der XML-Nachricht ist entscheidend für die Anordnung des Fahrwegs, falls die Sollzeit keinen Unterschied deutlich macht. (Bitte beachten Sie hier, dass die Schnittstelle in diesem Punkt von Linienverkehren ausgeht. Für flexible Bedienformen ist eine eingehendere Betrachtung notwendig.) 

Zusatzhalte dürfen immer nur im Kontext des (neuen) Gesamtfahrwegs übermittelt werden. In diesem Fall beinhaltet das Element Komplettfahrt den Wert true. Dadurch ist der Fahrweg wieder eindeutig. 
(Werner Kohl, MDV - 10/08) 

Frage zu VDV-Schrift 454 (Version 1.2): REF-AUS, Zeitfenster 

Bezieht sich das Zeitfenster auf die Abfahrtzeit an jeder Haltestelle einer Fahrt, oder nur auf die erste Abfahrt? 

Ich habe immer gedacht, die erste Abfahrt, weil es auch geschrieben ist: "Falls das Ende einer Fahrt außerhalb des angegebenen Zeitfensters liegt, wird dennoch die Daten der ganzen Fahrt übertragen." Es gibt keine solche Aussage über der Beginn der Fahrt. 

Antwort: Das Zeitfenster bezieht sich auf die Abfahrtszeit an der ersten Haltestelle einer Fahrt. Der entsprechende Passus findet sich in Abschnitt 5.1.1 auf Seite 24 in der neuen Version 1.2 der Schrift 454. 

Es sollen also nur Fahrten übertragen werden, deren Beginn (Fahrtantritt an der ersten Haltestelle) im Zeitintervall liegt. (Werner Kohl, MDV - 10/08) 

Frage zu VDV-Schrift 453 (Version 2.2): LinienID + LinienText sind Pflichtfelder 

Meiner Hinsicht sollte folgenderweise implementiert werden: 

LinienId sollte (immer) gebraucht werden für interne und externe Referenz zwecken. Es ist teil der Database Schlüssel der zusammen gesetzt ist von (AZBID, Fremdbetriebsschlüssel, LinienId, RichtungsId). 

Linientexst sollte immer gebraucht werden für Wiedergabezwecke, da dies der Repräsentation ist, die relevant ist für den Fahrgast. 

Unser System Lieferanten hat ein System gebaut, das leider nur eine Repräsentation (für LinienId und RichtungsId) behalten kann, die gebraucht werden muss für beide Zwecke. 

Ich denke, das dies nicht konform der VDV453 Standard ist. 

Antwort: Sowohl LinienID als LinienText sind Pflichtfelder, die in der jeweiligen XML-Datei enthalten und gefüllt sein müssen. Ein Lieferant, der dies nicht tut, hat ganz eindeutig nicht die Spezifikationen der VDV Schrift 453/454 erfüllt. Dies ist sowohl in der Schrift als auch im XML-Schema eindeutig vermerkt. Wobei in Zweifelsfällen immer das Schema (XSD) maßgeblich wäre. Es gibt nur wenige Stellen, an denen diese Felder optional sind. Dabei handelt es sich um die folgenden Strukturen: 

LinienText ist optional in: 

• IstFahrtTyp 
• LinienFahrplanTyp 
• SollFahrtTyp 

LinienID ist optional in: 

• AboASBRefType, AboAZBRefType 
• AboAZBtype, AboVISType 
• ZeitFilterType 

In allen anderen Fällen sind die Elemente LinenText und LinienID Pflichtfelder und sollten daher beide versorgt werden! 
(W. Bruns, 8.6.2007) 

Frage zu VDV-Schrift 453 (Version 2.3): ANS Rückkanal 

Wenn ich es richtig verstehe wird in einem existierenden Abonnement ein DatenBereit vom Client gesendet?
Und dann eine DatenAbrufenAnfrage vom Server? Also in die "Falsche" Richtung? Stimmt das? 

Antwort: Ja, das mit dem Rückkanal haben Sie genau richtig verstanden. 
(Daniel Rubli, Public Transit Solutions, Continental Automotive Switzerland AG - 10/2008) 

Verständnisfragen zu Hysterese, Zyklus und Ereignis

Verständnisfrage zur Hysterese (ANS, DFI, AUS Dienste):

Es soll vom Server eine Datenbereit gesendet werden wenn einer der Daten innerhalb des Filters die angefragte Hysterese überschreitet oder einer der Statuselemente eine Wertänderung bekommen hat.
Dieser Datenbereit Zustand im Server wird erst dann zurückgesetzt, wenn Daten vom Client abgerufen sind. Das heißt, wenn keine Daten vom Client abgerufen werden, werden keine Datenbereit Telegramme vom Server gesendet. In der Statusantwort wird in diesem Zustand immer Datenbereit=true gesendet.
Wenn der Client Daten abruft, bekommt er immer die aktuellsten Stand.

Antwort (31.10.2008/rud): Unsere Server-Implementierung sendet immer wieder eine neue Datenbereit, auch wenn die vorherigen Daten vom Client nicht abgerufen wurden. Die VDV-Schrift schliesst aus meiner Sicht ein jeweiliges Wiederholen der Datenbereit bei aktualisierten Daten nicht aus, ich persönlich finde es auch besser so. Die restlichen Aussagen stimmen genau so.

Verständnisfrage zum Zyklus (VIS Dienst): Es soll vom Server eine Datenbereit gesendet werden wenn es neue Fahrtupdates gibt und wenn die Zykluszeit abgelaufen ist. Im Gegensatz zur Hysterese Mechanismus bleibt der Server Datenbereit Telegramme senden, auch wenn der Client keine Daten abgerufen hat, damit der Takt einigermaßen konstant bleibt. Wenn in einem Zyklus keine neuen Daten vorhanden sind, wird in diesem Zyklus keine Datenbereit gesendet.

Antwort (31.10.2008/rud): Wir haben es genau so implementiert.

Verständnisfrage zu Ereignis (AND Dienst): Gleich wie Hysterese. Auch wenn neue Meldungen (oder Daten, z.B. SXD) vorhanden sind, aber der datenbereit Zustand noch nicht zurückgesetzt wurde durch Datenabruf der Client, werden keine Datenbreit Telegramme gesendet vom Server. In der Statusantwort wird in diesem Zustand immer Datenbereit=true gesendet.

Antwort 31.10.2008/rud: Auch da sendet unsere Server-Implementierung immer wieder eine neue Datenbereit, auch wenn die vorherigen Daten vom Client nicht abgerufen wurden.

VDV 453, Dienste DFI und ANS: „WartetBis“-Meldung

Feststellung: In der „WartetBis“-Meldung des ANS-Dienstes wird im Datenelement
„AbfahrtszeitASBPrognose“ die Rückhaltezeit (bis wann er auf den (die)
Zubringer wartet) kommuniziert.

Im DFI-Dienst ist dies aber nicht im Datenelement „AbfahrtszeitAZBPrognose“, sondern im Datenelement „AbfahrtszeitAZBDisposition“. Logischerweise müsste in der „WartetBis“-Meldung das Zeitelement „AbfahrtszeitASBDisposition“ heissen.

Antwort (16.10.2009/rud): Da hast du eigentlich recht, wird aber auf Grund der Abwärts-Kompatibilität so belassen.

Frage: In der WartetBis-Meldung ist noch eine Verlässlichkeit der Prognose definiert. Es fehlen aber in der Schrift Hinweise, welche betrieblichen oder sensorische Fakten zu welchem Verlässlichkeitswert führen. Gibt es da weitergehende Vorstellungen?

Antwort ( 16.10.2009/rud): Die in WartetBis ist dafür angedacht, das Zubringer-System früher als das Abbringer-Fahrzeug die Warte-Weisung technisch quittiert hat über den aktuellen Status der Anschlusssicherung zu informieren. Z.B. könnte sofort bei Beginn der Anschluss-Berechnung eine erste Abbringernachricht gesendet und diese dann laufend aktualisiert werden (WartetBis auch wenn Abbringer nicht zurückgehalten werden muss, siehe auch nächstes Kapitel). Dies sollte aber nur so gesendet werden, wenn es mit dem Schnittstellenpartner entsprechend abgesprochen ist. Das VDV-Gremium hat sich auch aus Gründen der Abwärts-Kompatibilität darauf geeinigt, ohne Absprachen nur WartetBis-Meldungen zu senden, wenn das Abbringer-Fahrzeug die Warte-Weisung technisch quittiert hat. So viel ich weiss gibt es noch keine weitergehende Vorstellungen. Sollte ein Hersteller ein entsprechendes Projekt haben, wäre aus meiner Sicht eine Umfrage im VDV-Gremium und eine anschliessende Publizierung auf der VDV-Website angebracht.



ANS-Rückkanal, problematische Abbringernachrichten

Feststellung: Einige RBL-Systeme melden die Abbringernachrichten aufgrund von Solldaten-Zubringernachrichten und nicht aufgrund von tatsächlichen Prognosen. Dies führt zu einer Mengenproblematik bei der Verarbeitung der Rückkanal-Nachrichten. (Andreas Huhn, DBSystel)

Antwort (AG Ist-Daten Schnittstellen, 11.11.2009):

Eigentlicher Grund für das Problem ist ein ungewöhnlich großer Prognosehorizont (4 Stunden). Aber auch in diesem Fall kann über das Attribut 'Verlässlichkeit' (1 für tatsächliche Prognosen) in der Rückkanal Nachricht übertragen werden, ob es sich um Ist- oder Sollzeiten handelt.

(Vgl. VDV 453 6.2.4.4.3 Wartezeitverlängerung)

MaxAnzFahrten in AboAZB, Interpretation wenn kein Linienfilter enthalten ist

• Interpretation 1: Es sollen für dieses AboAZB gleichzeitig total MaxAnzFahrten behandelt werden, in Summe über alle Linien/Richtungs-Kombinationen.
• Interpretation 2: Es sollen für dieses AboAZB gleichzeitig MaxAnzFahrten für jede Linien/Richtungs-Kombination gesendet werden. 

Interpretation 1 kann zu folgendem Problem führen: 

Wird z.B. für einen Anzeiger mit 8 Zeilen ein AboAZB mit MaxAnzFahrten=8 gesendet, werden um 11:55 vielleicht folgende Fahrten geliefert: 

• 12:00 A1 Ri_A 
• 12:00 A2 Ri_A 
• 12:05 B1 Ri_A 
• 12:10 A1 Ri_A 
• 12:10 A2 Ri_A 
• 12:15 C1 Ri_A 
• 12:20 A1 Ri_A 
• 12:20 A2 Ri_A 

Nicht geliefert:

• 12:21 D1 Ri_A
• 12:22 E1 Ri_A
• 12:23 F1 Ri_A
• 12:24 G1 Ri_A

Der Client will wegen der vielen vorbeifahrenden Linien auf seinen Anzeigern jeweils nur die nächste Fahrt jeder Linien/Richtungs-Kombination anzeigen und filtert deshalb die doppelten heraus.

Es werden also folgende Fahrten angezeigt:

• 12:00 A1 Ri_A
• 12:00 A2 Ri_A
• 12:05 B1 Ri_A
• 12:15 C1 Ri_A

Jetzt sind also 4 Zeilen leer, auf welchen die nicht gelieferten Fahrten schön Platz gehabt hätten.

Antwort (AG Ist-Daten-Schnittstellen, 11.11.2009): Wird ein Abonnement ohne LinienID und RichtungsID aufgesetzt, so bezieht sich MaxAnzahlFahrten auf die Summe aller Fahrten, nicht auf die einzelnen Linien-Richtungs-Kombinationen. 

Frage zu VDV-Schrift 454 zur Interpretation von Prognoseinformationen in IstHalt-Elementen im Dienst AUS. 

1. Aus der Beschreibung in Kapitel 5.2.2.3 schließe ich, dass für einen übertragenen IstHalt die Elemente Abfahrtszeit und Ankunftszeit immer angegeben werden müssen (außer bei Start- respektive Endhalt). 
2. Aus den Angaben zu den Prognose-Elementen im selben Kapitel schließe ich weiterhin, dass die Abwesenheit von IstAbfahrtPrognose bzw. IstAnkunftPrognose so interpretiert werden muss, dass die Zeiten in Abfahrtszeit bzw. Ankunftszeit gleichzeitig die aktuelle Prognose darstellen. Anders gesagt, sobald Zeiten im IstHalt angegeben werden habe ich automatisch eine Prognose. Dies wird meiner Meinung auch durch den letzten Absatz in Kapitel 6.1.1 bestätigt. 

Bei folgendem Beipiel hätte ich entsprechend eine prognostizierte Ankunftszeit von 16:31 Uhr, was der geplanten Zeit entspricht, und eine prognostizierte Abfahrtszeit von 16:34 Uhr, was einer 3-minütigen Verspätung entspricht. 
‹IstHalt› 
‹HaltID›8000986‹\HaltID› 
‹Abfahrtszeit›2010-02-18T16:31:00+01:00‹Abfahrtszeit› 
‹Ankunftszeit›2010-02-18T16:31:00+01:00‹\Ankunftszeit› 
‹IstAbfahrtPrognose›2010-02-18T16:34:00+01:00‹\IstAbfahrtPrognose› 
‹\IstHalt› 
Ist diese Interpretation der VDV-Norm korrekt? 

Antwort: Ich halte Ihre Interpretation für korrekt. Alle Implementierungen, die ich kenne, senden jedoch der Deutlichkeit halber auch im Fall einer pünktlichen Fahrt für einen IstHalt den Wert IstAbfahrtPrognose, selbst wenn er gar nicht von Abfahrtszeit abweicht. Dann gibt es keinen Zweifel. Ich würde das als "Best Practice" empfehlen. (Werner Kohl, MDV - 2/10) 

weitere Antwort zu IstHalt-Elementen im Dienst AUS 

Die Schlussfolgerung, dass die Ankunftsprognose in dem Beispiel als pünktlich zu interpretieren ist, stimmt. 

Die in der Frage geäußerte Interpretation der Angaben im Kapitel 5.2.2.3 ist jedoch nicht präzise wiedergegeben. Laut der VDV-Spezifikation (ebenda) entfällt die Angabe der Ankunftszeit nicht nur beim Starthalt. Auch im Falle, dass die Ankunftszeit der Abfahrtszeit entspricht, entfällt diese Angabe. 

Das angegebene Beispiel nutzt daher nicht im vollen Umfang die sinnvollen Regeln zur Datenreduktion. 

Bei vollständiger Anwendung der Reduktionsregeln würde sich der Umfang der auszutauschenden Nachricht um ca. 30% reduzieren, da die beiden Zeiten bzgl. der Ankunft in dem Beispiel redundant sind… 

8000986 
2010-02-18T16:31:00+01:00 
2010-02-18T16:34:00+01:00 

Aus unserer Erfahrung mit zahlreichen Herstellern von VDV454-Servern werden die Datenreduktionsregeln entsprechend der in diesem Punkt eindeutigen VDV-Spezifikation angewendet. Gerade in Hinblick auf die nicht unerhebliche Einsparung von redundanten Informationen würde ich die Umsetzung entsprechend der Spezifikation empfehlen. 
(Klaus Hoppe, Funkwerk-IT – 02/10) 

Frage zur Reihenfolge der Elemente in der Sequenz VisFahrplanlageType 

Tatsächlich wurde mit der Version 2.2 die Reihenfolge der Elemente geändert. Sie ist in der Version 2.1 von 2004 anders ist als in den nachfolgenden Schemaversionen (ab Oktober 2005). 
(Bruns, VDV, 2.2010) 

AboID 

Frage: Sind AboAZB und AboAZBRef als ein Dienst (Fahrgastinformation) zu verstehen? 

Antwort: Nein, AboAZB und AboAZBRef sind zwei getrennte Dienste. 

Frage: Könnte ein Client ein AboAZB-Abo mit Abo-ID=“1“ anlegen sowie ein AboAZBRef mit Abo-ID=“1“ ? 

Antwort: Ja! 

Eine AboID ist innerhalb eines jeden Dienstes eindeutig. Die Vergabe der AboIDs erfolgt durch den Client innerhalb der Anfrage nach einem Abonnement. 

Die Dienstkennung ist Teil der URL. Man kann also die Dienste schon über die URL eindeutig unterscheiden/ zuordnen. (WB/5.2010)

Reihenfolge der Fahrtelemente in AUS-/AUSREF (VDV 454)

Frage: Ist es laut VDV-Spezifikation zulässig, dass in AUS-/AUSREF die Fahrtelemente nicht in einer zeitlich aufsteigenden Reihenfolge übermittelt werden?

Antwort:
a) Die Reihenfolge von IstFahrt-Elementen in einem Element AUSNachricht halte ist irrelevant.
b) Die Reihenfolge von SollFahrt-Elementen in einem Element Linienfahrplan ist ebenfalls irrelevant.
c) Die Reihenfolge der SollHalt-Elemente in einem Element SollFahrt sollte sich jedoch strikt an den Fahrweg der Fahrt halten, genauso wie die Reihenfolge der IstHalt-Elemente in einem Element IstFahrt. 
(W. Kohl, MDV, 9.2010) 

Nutzung der optionalen Felder 

Frage: Im Abschnitt 4.6 „Nutzung der optionalen Felder“ wird darauf hingewiesen, dass beim erneuten Senden einer Botschaft die optionalen Felder weggelassen werden können mit der Folge, dass dann zuvor gesendete Werte ihre Gültigkeit behalten. Bei einzelnen Feldern sind in der VDV-Schrift jedoch abweichende Regelungen angegeben. Hierin könnte man Widersprüche in der VDV-Schrift sehen. 

Antwort: Dies ist aber ein Missverständnis. Vielmehr ist die Regelungen in 4.6 als Basisaussage zu verstehen, die immer dann gilt, wenn beim einzelnen Feld keine abweichende Regelung getroffen ist. 

Allgemeine Empfehlung, mit jeder Meldung in sich geschlossen den aktuellen Zustand zu übertragen, also nicht zur Reduktion von Last auf das Übertragen von optionalen Feldern zu verzichten. 
Arbeitsgruppe Ist-Daten-Schnittstellen, 3.11.2010 

Eindeutigkeit der FahrtID 

Frage: 

Ist bereits das Tripel Provider – Fahrtbezeichner – Betriebstag eindeutig? 

Oder erst das Quintupel? Provider – Fahrtbezeichner – LinienID – RichtungID – Betriebstag? 

Antwort: Es wird einstimmig beschlossen, dass bereits das Tripleprovider-Fahrtbezeichner-Betriebstag eine eindeutige Kennzeichnung der Fahrt ergeben muss. (Arbeitsgruppe Ist-Daten-Schnittstellen, 3.11.2010) 

Zusätzliches Feld 'VonRichtungsText' in künftiger Version der VDV-Schrift 453 

Frage: Beim ANS-Dienst wurde in der SBB-Schnittstellenspezifikation festgelegt, dass im Richtungs-Text die Herkunft des Verkehrsmittels eingetragen wird. (Begründung: Beim ANS-Dienst geht es konkret um Anschluss-Sicherung, deshalb steht die Herkunft der Fahrt im Fokus, d.h. der Disponent bzw. der Chauffeur will wissen, woher der Zubringer kommt.) Bei der IBN eines weiteren Schnittstel-len-Partners wurde nun bemängelt, dass diese Auslegung nicht der Norm 453 entspricht, bzw. die Norm dazu keine klaren Vorgaben macht. 

Antwort:  Aus demselben Grunde wurde ein Element „VonRichtungstext“ in die VDV-Schrift 454 eingefügt. Dies soll bei der nächsten Erarbeitung der VDV-Schrift 453 ebenfalls gemacht werden. Die Bedeutung des Element „Richtungstext“ bleibt aber unverändert "Ziel". (Arbeitsgruppe, 3.11.2010) 

Frage zur Interpretation der VDV-Schrift VDV454 V1.1 bzw. V1.2. im Zusammenhang mit einer Fahrtmeldung per AUS-Dienst 

Frage: Es werden Fahrtmeldungen ohne Angaben von Zeiten (weder Sollzeiten noch Prognosen) oder Haltestellen per AUS-Dienst übermittelt. 

Sind diese Fahrtmeldungen laut Spezifikation zulässig und wenn, wie sollen diese interpretiert werden?

Gilt die Fahrt dann als an allen Haltestellen (Fahrweg laut AUSREF) als pünktlich(Verspätungsfortschreibungsregel vorausgesetzt)? 

Wie verhält sich das im Falle 

• einer Fahrterstmeldung, d.h. der erstmaligen Meldung über AUS? 
• einer späteren Meldung, d.h. nach einer bereits erfolgten Meldung zur Fahrt über AUS? 

Antwort: Gemäß xsd ist die Meldung zulässig. 

Gemäß VDV454 v1.2, Kapitel 6.1.6 ist der Default von PrognoseMoeglich true, falls es nicht in der IstFahrt enthalten ist. 
Erfolgt also eine Erstmeldung ohne PrognoseMoeglich, kann das Auskunftssystem die Fahrt als pünktlich annehmen: 

• VDV454 v1.2, Kapitel 6.1.6, Erstmeldung und Vorschauzeit 
  

Das Auskunftssystem kann eine Fahrt dann als pünktlich annehmen, wenn eine Erstmeldung durch das RBL erfolgt ist und prognosemöglich nicht auf false gesetzt wurde. Ohne eine aktive Übermittlung dieser Informationen über die Schnittstelle schaltet das Fahrplanauskunftssystem auf die Rückfallebene Solldaten. 

Erfolgt eine Meldung ohne IstHalte nach einer bereits gemeldeten Verspätung, dann bleibt die zuvor gemeldete Prognose gültig.: 

• vgl. Hinweis "Nutzung der optionalen Felder" weiter oben auf dieser Seite und VDV454 v1.2, Definition IstHalt, IstAbfahrtPrognose 
• (optional) Prognose für die Abfahrtszeit. Keine Angabe: geplante Abfahrtszeit. 
  
  

(Daniel Rubli, Trapeze, 13.4.2011 / AG 21.6.2016) 

Fragen zu VDV-Version VDV454 V1.2 

Wie wirken sich beim AUS-Dienst die neuen Elemente IstAbfahrtDisposition und IstAnkunftDisposition auf die Verspätungsfortschreibungsregel aus? 

02.08.2011/rud: 

Definition IstHalt 

• Abfahrtszeit: (optional) Geplante Abfahrtszeit. Nicht gefüllt bei der Endhaltestelle.. 
• Ankunftszeit: (optional) Geplante Ankunftszeit. Nicht gefüllt falls gleich mit Abfahrtszeit oder bei der Starthaltestelle. 
• IstAbfahrtPrognose: (optional) Prognose für die Abfahrtszeit. Keine Angabe: geplante Abfahrtszeit. 
• IstAnkunftPrognose: (optional) Prognose für die Ankunftszeit. Keine Angabe: geplante Ankunftszeit. 
• IstAbfahrtDisposition: (optional) vorgesehene, durch aktive Dispositionsmaßnahmen von der prognostizierten Abfahrtszeit abweichende Abfahrtszeit 
• IstAnkunftDisposition: (optional) durch aktive Dispositionsmaßnahmen von der prognostizierten Ankunftszeit abweichende Ankunftszeit 

### 

Wird beim Vorliegen einer dispositiven Abfahrtszeit diese Verspätung (statt der Verspätung bzgl. der prognostizierten Abfahrtszeit) auf den nachfolgenden Halt fortgeschrieben? 

02.08.2011/rud: 

Auf alle nicht gesendeten Halts bis zum nächsten mitgesendeten Halt ja. Auf den nächsten mitgesendeten Halt würde ich das gemäss obiger Tabelle nicht tun. 

Wie steht es dann um eine mögliche (nicht) vorhandene dispositive Ankunftszeit am nachfolgenden Halt? 

02.08.2011/rud: 

Auf alle nicht gesendeten Halts bis zum nächsten mitgesendeten Halt fortschreiben. Nicht fortschreiben auf den nächsten mitgesendeten IstHalt, weil aus meiner Sicht jeder IstHalt die gesamte Information in sich geschlossen beinhalten sollte. 

Wird die Verspätung anhand der Disposition nur auf die Prognosen des nachfolgenden Halts fortgeschrieben? 

02.08.2011/rud: 

Auf alle nicht gesendeten Halts bis zum nächsten mitgesendeten Halt fortschreiben. Nicht fortschreiben auf den nächsten mitgesendeten IstHalt, weil aus meiner Sicht jeder IstHalt die gesamte Information in sich geschlossen beinhalten sollte. 

Das würde bedeuten, dass dispositive Zeiten selber nicht fortgeschrieben werden können und die Halts mit dispositiven Zeiten immer übermittelt werden müssen. 

02.08.2011/rud: 

Mit meiner oben beschriebenen Lösung nicht. Es werden nur IstHalts gesendet, wo sich eine der vier Prognosen um mehr als die Hysterese verändert. 

Dürfen IstAbfahrtDisposition/ IstAnkunftDisposition zusammen mit PrognoseMoeglich=false, FaelltAus und/oder PrognoseUngenau auftreten? 

02.08.2011/rud: 

Bei PrognoseMoeglich=false und FaelltAus werden wir wohl nie IstAbfahrtDisposition/IstAnkunftDisposition senden, weil dieses Fahrzeug an der Anschlusssicherung gar nicht mehr teilnimmt. PrognoseUngenau="dispositive Maßnahme" sollte aus meiner Sicht immer gesendet werden, wenn IstAbfahrtDisposition/IstAnkunftDisposition gesendet wird. 

Eine allgemeine Frage zu Fahrtausfallmeldungen per AUS: 

Kann ein und die selbe Fahrt (gleicher Fahrtbezeichner) nach einer Fahrtausfallmeldung „wiederbelebt“ werden? 

02.08.2011/rud: 

Ja. 

Genügt dazu eine erneute Fahrtmeldung zur Fahrt mit FaelltAus=false (bzw. default), d.h. ohne Komplettfahrtmeldung, da der Fahrweg sich nicht ändert? 

02.08.2011/rud: 

Aus meiner Sicht ja. Die Fahrt sollte vom Client nicht einfach gelöscht werden, sondern lediglich mit "fällt aus" gekennzeichnet und intern entsprechend behandelt werden. Aus meiner Sicht sollte es aber auch zulässig sein, dass der Server nochmals die komplette Fahrt sendet. 

Fragen bzgl. VDV454 V1.2. und gesicherten Anschlussbeziehungen (8.2011) 

1. Können AnschlussPlan- und AnschlussStatus-Informationen gleichzeitig(!) bei 
a. AUSREF (AnschlussStatus ist sicherlich nicht sinnvoll.) 
b. AUS 
übermittelt werden? 

rud: 

Da AnschlussPlan und AnschlussStatus als Choice definiert sind, können sie in einem Element GesAnschluss nicht gleichzeitig übertragen werden. Da es aus meiner Sicht jedoch Sinn macht, im Fall eines Anschlusses mit VDV453-Fremdzubringern beide Elemente gleichzeitig zu senden, werden wir bei unserer zukünftigen Implementierung sobald der Anschluss gebildet wird eine Meldung mit zwei Elementen GesAnschluss senden, das erste mit dem Unterelement AnschlussPlan, das zweite mit dem Unterelement AnschlussStatus. 

Wie sieht ein Betrieb ohne AUSREF aus? 

rud: 

Wenn AUSREF nicht verwendet wird oder bei Anschlüssen mit VDV453-Fremdzubringern werden wir bei unserer zukünftigen Implementierung eine Erstmeldung mit zwei Elementen GesAnschluss senden, das erste mit dem Unterelement AnschlussPlan, das zweite mit dem Unterelement AnschlussStatus. 

2. Wie wird die Übermittlung von AnschlussPlan bei AUS angefordert oder vermieden? 

rud: 

Die Übermittlung von AnschlussPlan bei AUS kann aus meiner Sicht weder angefordert noch vermieden werden. Wenn der Datenlieferant die Elemente implementiert hat, wird er sie senden, wenn der Client sie nicht implementiert hat, wird er sie ignorieren. Da für Anschlüsse mit VDV453-Fremdzubringern oft keine Sollanschlüsse für AUSREF zur Verfügung stehen, können diese Angaben nur über AUS übermittelt werden. 

3. Wann werden AnschlussPlan- und AnschlussStatus-Informationen bei AUS übermittelt (Stichwort: Vorschauzeit / frühzeitige Meldung)? 

rud: 

Wenn die Vorschauzeit im AUS grösser ist, dann wird AnschlussPlan und AnschlussStatus übermittelt, sobald das System den Anschluss mit dem VDV453-Fremdzubringer bildet. Wenn die Vorschauzeit im ANS grösser ist, dann wird AnschlussPlan und AnschlussStatus übermittelt, sobald die Fahrt ins Vorschauzeit-Fenster des AUS-Dienstes eintritt. 

Wird die Hysterese berücksichtigt? 

rud: 

Ja, andernfalls hätte das Auskunftssystem eine veraltete AbfahrtszeitAbbringerPrognose 

4. Kann AnschlussPlan bei AUS nachträglich und/oder erneut übermittelt werden? 

rud: 

Ja, Anschlüsse können dynamisch umgebildet werden. Wenn z.B. ein Abbringer nicht länger zurückgehalten werden kann, bildet das System vielleicht dynamisch einen neuen Anschluss mit dem folgenden Abbringer. 

5. Verwendung von HstSeqZaehler bei ges. Anschlüssen. 

In der Definition "AnschlussPlanType" wird "FahrtIDGlobalType" für Zubringer bzw. Abbringer genutzt. 

Und dort wiederum "FahrtIDExtType". 

Frage zur VDV453: Datenabruf mit DatensatzAlle=true 

Frage: Wie ist das zu erwartende Verhalten bzgl. DFI bei einem Datenabruf mit DatensatzAlle=true? 

Werden in diesem Fall beim Abruf AZBFahrtLoeschen (bzw. AZBLinienSpezialtextLoeschen) Elemente mit geliefert? 

Oder ist ein komplettes Abbild des momentanen AZB zu erwarten, wo AZBFahrtLoeschen nicht vorkommt, da keine Delta-Änderung kommuniziert wird? 
(Analog ANS) 

Antwort: Aus meiner Sicht sollte auf eine DatenAbrufenAnfrage mit DatensatzAlle='true' das komplette Abbild des momentanen AZB übermittelt werden, keine AZBFahrtLoeschen und keine AZBLinienSpezialtextLoeschen. 
(Daniel Rubli, Trapeze, 3.2012) 

Frage zu VDV454 Dienst AUS 

Frage: Sollen bei der Übertragung einer Komplettfahrt im Dienst AUS auch nicht befahrene Haltestellen übertragen werden? 

Antwort: Es sollen innerhalb der Komplettfahrt Informationen für alle Haltestellen gesendet werden. Für die Haltestellen, die nicht befahren werden, wird das Flag “Prognosemöglichkeit“ auf false gesetzt. Anschließend werden die Einzelhalte übertragen, für die eine Prognose möglich ist. 

Dieser Implementierungshinweis soll unter FAQ auf die Website gestellt werden. In der neuen Ausgabe der VDV-Schrift soll der aktuelle Stand der FAQ-Seite ins Dokument mit eingebunden werden.
(AG 11.2012) 

Alive-Handling der Datendrehscheibe (DDS) 

Frage: Bei durchleitender Betriebsform einer DAtendrehscheibe antwortet die DDS im Normalfall auf Status-Anfragen mit der Status-Antwort des angefragten Umsystems. Dies ist nicht möglich, wenn das angefragte Umsystem nicht ermittelbar oder nicht erreichbar ist. In diesem Fall sollte die DDS mit Ergebnis = „not ok“ und der momentanen Systemzeit als StartDienstZeit antworten. So kann das anfragende System erkennen, dass die DDS zwar grundsätzlich erreichbar ist, die Anfrage aber nicht weitergeleitet werden kann und eventuell vorhandene Abonnements neu aufgesetzt werden sollten (geänderte StartDienstZeit). 

Antwort: Wenn das angefragte Umsystem nicht erreichbar ist, sollte dieses transparent an das anfragende System zurückgemeldet werden. 

Timeouts würden z.B. ebenfalls als Timeout weitergeleitet (mittels http-Status). Es sollte bei einem Timeout nicht generell mit einem Neuaufsetzen der Abos reagiert werden. 

Das anfragende System kann wie bei einer direkten Verbindung entscheiden, ob es bei Timeouts die Abos neuaufsetzt oder stattdessen mit einem Datenabruf mit DatensatzAlle=true reagiert. Das Neuaufsetzen von Abos ist je nach Implementierung ein ggf. teurer Vorgang. 
(AG 11.2012) 

Ausfall von Datenanbietern bei Datendrehscheiben mit aktiv verarbeitender Betriebsform 

Frage: Bei der aktiv verarbeitenden Betriebsart einer Datendrehscheibe besteht grundsätzlich die Möglichkeit, dass die DDS Daten mehrerer Anbieter abonniert, und in einem gebündelten Dienst gemeinsam zur Verfügung stellt. Hier stellt sich die Frage, wie die DDS reagieren soll, wenn einer der Datenanbieter ausfällt. 

Antwort: Nach Ansicht der Arbeitsgruppe ist dies eine organisatorische Entscheidung und ist damit in der VDV-Mitteilung 7022 korrekt aufgehoben: 

Die abnehmenden Systeme werden vom Ausfall eines Datenanbieters durch Neusetzen der StartDienstZeit informiert. Sobald ein Datenanbieter ausfällt oder seinen Betrieb wieder aufnimmt, setzt die DDS die StartDienstZeit neu. In diesem Moment verlieren gemäß VDV-Schrift alle Abonnements abnehmender Systeme ihre Gültigkeit. Die abnehmenden Systeme verwerfen die alten Daten und setzen die Abonnements neu auf. Die DDS liefert nun keine Daten des ausgefallenen Anbieters mehr.
(AG 11.2012)

In der VDV-Spezifikation V453 V2.3.1 steht im Kapitel 5.1.2.1 „Abonnementanfrage“ folgender Satz:
"Wird eine AboAnfrage mit einer AboID gestellt und es existiert bereits ein Abonnement unter dieser Bezeichnung, so wird das bestehende Abonnement überschrieben."

Frage: Welche Wirkung hat nun das „Überschreiben“ eines bestehenden Abonnements im Detail?
(Man beachte, dass das bestehende Abonnement nicht zuvor durch eine Abonnementlöschen-Anfrage explizit gelöscht wird.)
A) Es wird das bestehende Abonnement implizit gelöscht und als neues Abonnement wieder neueingerichtet.
B) Es werden die Parameter des bestehenden Abonnements durch die neue Abonnementsanfrage überschrieben.
Dabei wird das Abonnement entsprechend der neuen Parameter „fortgeführt“.

Die Wirkungen von A bzw. B sind in der Hinsicht unterschiedlich, dass anschließend bei A sämtliche Daten
beim kommenden Datenabruf erneut übermittelt werden. Bei B werden bereits übermittelte Daten nicht nochmals übermittelt.

Antwort: Wenn sich das Abonnement so unterscheiden, dass das neue überhaupt nicht zu dem alten passt, z.B. das neue Abonnement hat andere AZB_IDs oder definiert andere Filter, Fahrtenanzahl usw. , dann beleibt dem Datenlieferanten nichts anderes, als das bestehende Abo ersatzlos zu löschen, das neue einrichten und komplette Daten zu senden.

Somit ist die Variante A ist die einzige sichere und klar definierte Variante. Sonst muss der Datenlieferant eine komplizierte und dazu noch undefinierte Logik implementieren um zu entscheiden, ob das Abo “überschreibar“ ist. Das führt meiner Meinung nach zu sehr viel Implementierungsspezifik und ausufernden Aufwänden bei der Abstimmung zwischen den Partnern.
(Waldemar Isajkin, init, 6.2013)

Fragen zu Abfahrt-/AnkunftDisposition

1. Habe ich es richtig verstanden, dass zwischen prognostizierter Zeit und disponierter Zeit (aufgrund von Warteanweisungen) unterschieden wird?
   Antwort: ja
2. Die Warteanweisung erzeugt ein (erstes) Update wegen der zusätzlichen DispoZeiten. Gilt dies auch, wenn die disponierte Verlängerung innerhalb der Hysterese liegt?
   Antwort: meiner Meinung nach ja
3. Habe ich folgendes richtig verstanden: Updates werden trotz disponierten Wartens aufgrund der verletzten Prognose gesendet (wenn die Hysterese überschritten ist).
   Ich halte dies jedenfalls für nachdenkenswert: Was passiert sonst, wenn die Warteanweisung aufgrund weiterer Erhöhung der Verspätung des Zubringers widerrufen wird?
   Antwort: ja, Änderungen der Prognose um mehr als die Hysterese sind weiterhin Trigger für Updates
4. Gibt es ein Update, wenn die Wartezeit dispositiv erhöht wird (weniger als vs. mehr als die Hysterese) oder die Warteanweisung widerrufen wird?
   Antwort: ja, meiner Meinung nach sollte man jedes Mal ein Update senden, wenn eine neue Weisung an den Abbringer gesendet wird, unabhängig von der Hysterese.
5. Ist folgendes korrekt: Generell stellen IstAnkDispo und IstAbfDispo keine Korrekturen der Sollzeiten dar (die mit Komplettfahrt=true übertragen werden müssten). Daher ist beim Widerruf der Warteanweisung auch keine Übertragung der Komplettfahrt notwendig
   Antwort: das sehe ich auch so
   (rud 10.11.2014)
   

---

weitere Informationen