E Anlage 17_Anhang 5 - VDV_453_v3.1.0_08-2024_MVU 250422.pdf

[Seite 1]

rbl

VDV-Schrift 453

08/2024

Ist-Daten-Schnittstelle – Version 3.1.0

ANS Anschlusssicherung

DFI Dynamische Fahrgastinformation

VIS Visualisierung

AND Allgemeiner Nachrichtendienst

Gesamtbearbeitung

Ausschuss für Kunden-Service,-Information und -Dialog (K3)

Ausschuss für Telematik und Informationssysteme (ATI)

[Seite 3]

VDV-Schrift 453

Ist-Daten-Schnittstelle – Version 3.1.0

ANS Anschlusssicherung

DFI Dynamische Fahrgastinformation

VIS Visualisierung

AND Allgemeiner Nachrichtendienst

Fachbearbeitung Zum Zeitpunkt der Erstellung dieser Version waren Mitglied in der Arbeitsgruppe VDV-Arbeitsgruppe Beckert, Anke, Verkehrs- u. Tarifverbund Stuttgart GmbH, Stuttgart "Ist-Daten- Baumann, Mathias, Interautomation, Berlin Schnittstellen" Bratta, Tino, BLIC GmbH, Berlin Dohmen, Claus, VDV, Köln Eckardt, Frithjof, Eckardt Software Management GmbH, Hannover Erven, Matthias, MENTZ GmbH, München Fiekert, Wolfram, HaCon Ingenieurgesellschaft mbH, Hannover Geilmann, Kathrin, IVU Traffic Technologies AG, Aachen Gujo, Oleg, Verkehrsautomatisierung Berlin GmbH, Berlin Grimme, Korbinian, init GmbH, Karlsruhe Hesse, Roland, MENTZ GmbH, München Hollenstein, Daniel, Schweizerische Bundesbahnen SBB, Bern Iffländer, Helmut, Iffländer – Consulting for Public Transport, Riehen Kehren, Peter, IVU Traffic Technologies AG, Aachen Kerk, Jürgen, DB Systel GmbH, Frankfurt am Main Kluge, Wolfgang, Dilax Intelcom GmbH, Berlin Kozuhovskij, Sergej , Verkehrsverbund Bremen/Nieders. GmbH, Bremen Leitritz, Fabian, HaCon Ingenieurgesellschaft mbH, Hannover Lenzen, Karl Horst, T-Systems GEI GmbH, Mülheim Möller, Mathias, PSI Transcom GmbH, Berlin Rittmeier, Raffael, Rhein-Main-Verkehrsverbund Servicegesellschaft mbH, Frankfurt Rubli, Daniel, Trapeze Switzerland GmbH, Neuhausen am Rheinfall Roth, Marius, National Express Rail GmbH, Köln Siaden Ortega, Ute, Eckardt Software Management GmbH, Hannover Sielaff, David, Verkehrsverbund Rhein-Sieg GmbH, Köln Stimmerling, Rainer, Verkehrsautomatisierung Berlin GmbH, Berlin Wichtermann, Jürg, Schweizerische Bundesbahnen, Bern Thiesing, Gustav, BLIC GmbH, Berlin Zilgens, Wolfgang, Ingenieurgruppe IVV, Aachen

[Seite 4]

Die Ausgangsversion der Schnittstelle wurde mit Mitteln des Bundesministeriums für Verkehr, Bau- und Wohnungswesen (BMVBW) durch den Auftragnehmer Beratungsgesellschaft für Leit-, Informations- +Computertechnik GmbH (BLIC) erstellt. Daher ist diese Spezifikation frei verfügbar.

Der Anwender ist für die sorgfältige und ordnungsgemäße Anwendung der Schrift verantwortlich. Stellt der Anwender Gefährdungen oder Unregelmäßigkeiten im Zusammenhang mit der Anwendung dieser Schrift fest, wird eine unmittelbare Benachrichtigung an den VDV erbe- ten. Eine Haftung des VDV oder der Mitwirkenden an der Schrift ist, soweit gesetzlich zulässig, ausgeschlossen.

© Verband Deutscher Verkehrsunternehmen e. V. Köln 2024 | Alle Rechte, einschließlich des Nachdrucks von Auszügen, der fotomechani- schen oder datenverarbeitungstechnischen Wiedergabe und der Übersetzung, vorbehalten.

[Seite 5]

Inhaltsverzeichnis VDV 453

1 Vorbemerkung ................................................................................................. 14 2 Einleitung ......................................................................................................... 16 3 Einführung und Grundbegriffe ....................................................................... 17 3.1 Anschlusssicherung (ANS) ....................................................................................17 3.1.1 Aufgaben und Ziele ............................................................................................17 3.1.2 Zubringer-Abbringer-Prinzip ...............................................................................17 3.1.3 Definition der betriebsübergreifenden Anschlusssicherung ................................19 3.1.4 Betriebsausprägungen .......................................................................................19 3.1.4.1 Bahnhof ......................................................................................................19 3.1.4.2 Mehrfachanschlüsse ...................................................................................19 3.1.5 Mehrfach angefahrene Haltestellen ....................................................................20 3.1.6 Fahr- und Anschlussplanung (Sollfahrplan) ........................................................20 3.1.7 Anschlussbereiche .............................................................................................21 3.1.8 Fahrgastinformation Innenanzeige .....................................................................21 3.1.9 Fahrtbezogene Anschlusssicherung ...................................................................21 3.1.10 Zeitbezogene Anschlusssicherung .....................................................................22 3.2 Dynamische Fahrgastinformation (DFI) ................................................................22 3.2.1 Aufgaben und Ziele ............................................................................................22 3.2.2 Datenversorgung und Ansteuerung ....................................................................22 3.2.3 Anzeigerbereiche ...............................................................................................24 3.3 Visualisierung von Fremdfahrzeugen (VIS) ..........................................................24 3.3.1 Aufgaben und Ziele ............................................................................................24 3.3.2 Visualisierungsbereiche .....................................................................................24 3.4 Allgemeiner Nachrichtendienst (AND) ..................................................................25 3.4.1 Aufgaben und Ziele ............................................................................................25 3.4.2 Nachrichtenkanäle .............................................................................................25 3.4.3 Nachrichtenformate ............................................................................................25 4 Architektur ....................................................................................................... 26 4.1 Kommunikation vs. fachliche Dienste ...................................................................26 4.2 Referenz- vs. Prozessdaten ...................................................................................26 4.3 Verwendete Protokolle ...........................................................................................27 5 Schnittstellenbeschreibung "Basisinfrastruktur" ........................................ 28 5.1 Abonnement-Verfahren ..........................................................................................28 5.1.1 Überblick ............................................................................................................28 5.1.2 Abonnements einrichten .....................................................................................29 5.1.2.1 Abonnementsanfrage (AboAnfrage) ............................................................29 5.1.2.2 Abonnementsbestätigung (AboAntwort) ......................................................31 5.1.3 Daten bereitstellen .............................................................................................32 5.1.3.1 Datenbereitstellung signalisieren (DatenBereitAnfrage) ..............................32 5.1.3.2 Datenbereitstellung bestätigen (DatenBereitAntwort) ..................................33 5.1.4 Daten abrufen ....................................................................................................33 5.1.4.1 Datenübertragung anfordern (DatenAbrufenAnfrage) .................................33

VDV 453 Version 3.1.0 - 5 - 23.09.2024

[Seite 6]

Inhaltsverzeichnis VDV 453

5.1.4.2 Daten übertragen (DatenAbrufenAntwort) ...................................................34 5.1.4.2.1 Handhabung DatensatzAlle .................................................................36 5.1.5 Datenabonnements löschen (AboLoeschen/Alle) ...............................................36 5.1.6 Wiederaufsetzen nach Unterbrechung ...............................................................37 5.1.7 Wiederaufsetzen nach Absturz ...........................................................................38 5.1.8 Alive-Handling ....................................................................................................38 5.1.8.1 Anfrage (StatusAnfrage) .............................................................................38 5.1.8.2 Antwort (StatusAntwort, Status) ..................................................................38 5.1.8.3 ClientStatusAnfrage ....................................................................................40 5.2 Http-Bindung ...........................................................................................................43 5.2.1 Verfahren ...........................................................................................................43 5.2.2 Zeichensatz ........................................................................................................43 5.2.3 Dienstekennungen .............................................................................................44 5.2.4 Anfrage-URL ......................................................................................................44 5.2.5 Fehlerbehandlung ..............................................................................................46 5.3 Sicherheit ................................................................................................................46 6 Schnittstellenbeschreibung "Fachliche Dienste" ......................................... 47 6.1 Allgemeine Festlegungen .......................................................................................47 6.1.1 Betriebstage .......................................................................................................47 6.1.2 Datum- und Zeitformat .......................................................................................48 6.1.3 Leitstellenkennung .............................................................................................48 6.1.4 Ortsbezüge ........................................................................................................48 6.1.4.1 HaltID ..........................................................................................................49 6.1.5 Fahrtbezug (FahrtID) ..........................................................................................51 6.1.6 Linien- und Richtungsbezüge .............................................................................51 6.1.7 Produkttypen ......................................................................................................52 6.1.7.1 Werteliste ProduktID ...................................................................................52 6.1.8 Stichfahrten ........................................................................................................53 6.1.9 ServiceAttribute ..................................................................................................53 6.1.10 Fehler in der fachlichen Schicht .........................................................................53 6.1.11 Optionale Felder .................................................................................................55 6.1.12 Texte für die Publikation .....................................................................................55 6.1.13 Latenz- und Verarbeitungsanalysen mit Hilfe des Elements Protokolleintrag .....55 6.1.13.1 Definition .....................................................................................................55 6.1.13.2 Implementierungshinweise ..........................................................................57 6.1.13.3 Interpretationshinweise ...............................................................................59 6.1.14 PrognoseUngenau-Elemente .............................................................................60 6.1.15 Prognosequalität (IstAnkunftPrognoseQualitaet und IstAbfahrtprognoseQualitaet): (ZeitQualitaet) ................................................................62 6.1.16 Verwendung von PrognoseUngenau und PrognoseQualitaet .............................62 6.1.17 Sprache ..............................................................................................................63 6.2 Anschlusssicherung (REF-ANS, ANS) ..................................................................65 6.2.1 Einleitung ...........................................................................................................65 6.2.2 Betriebliche Datenversorgung und –pflege .........................................................66

VDV 453 Version 3.1.0 - 6 - 23.09.2024

[Seite 7]

Inhaltsverzeichnis VDV 453

6.2.3 Referenzdatendienst (REF-ANS) .......................................................................67 6.2.3.1 Datenaustausch ..........................................................................................68 6.2.3.1.1 Aktualisierung ......................................................................................68 6.2.3.2 Bereichsfahrpläne anfragen (AboASBRef) ..................................................69 6.2.3.3 Linienorientierte Bereichsfahrpläne übermitteln (ASBLinienFahrplan) .........70 6.2.3.3.1 Einzel-Ankunftsdaten (ASBSollFahrt) ..................................................71 6.2.3.3.2 Verfügbarkeitshorizont (Zeitfenster) .....................................................72 6.2.3.3.3 Zusatzinformationen zur Fahrt (Fahrtinfo) ............................................73 6.2.3.3.4 Informationen zur Direktkommunikation (Direktruf) ..............................75 6.2.4 Prozessdatendienst (ANS) .................................................................................76 6.2.4.1 Datenaustausch ..........................................................................................76 6.2.4.1.1 Aktualisierung/Hysterese .....................................................................77 6.2.4.1.2 Vorschauzeit........................................................................................77 6.2.4.2 Anschlussdaten abonnieren (AboASB) .......................................................78 6.2.4.2.1 Fahrtbezogene Daten (Fahrtfilter) ........................................................78 6.2.4.2.2 Zeitbezogene Daten (Zeitfilter) ............................................................79 6.2.4.2.3 Zusatzinformation zum Abbringer (AbbringerInfo) ...............................81 6.2.4.3 Nachrichten des Zubringers (Zubringernachricht) .......................................82 6.2.4.3.1 Anschlussdaten übermitteln (ASBFahrplanlage) ..................................82 6.2.4.3.2 Zubringerausfall ...................................................................................87 6.2.4.4 Nachrichten des Abbringers (Abbringernachricht) .......................................89 6.2.4.4.1 Änderung der Halteposition (HaltepositionsAenderung) ......................89 6.2.4.4.2 Referenzierung von Fahrten (FahrtIDExt) ............................................90 6.2.4.4.3 Wartezeitverlängerung (WartetBis) ......................................................91 6.2.4.4.4 Abbringerausfall (AbbringerFahrtLoeschen) ........................................93 6.3 Dynamische Fahrgastinformation (REF-DFI, DFI) ................................................95 6.3.1 Einleitung ...........................................................................................................95 6.3.2 Betriebliche Datenversorgung und –pflege .........................................................95 6.3.3 DFI-Systeme mit Schlüsselansteuerung .............................................................96 6.3.4 DFI-Systeme mit anzeigenautonomer Prognose ................................................97 6.3.5 Scharfe Abmeldung ............................................................................................97 6.3.6 Traktionen/Kurswagen/Flügelfahrten ..................................................................98 6.3.7 Referenzdatendienst (REF-DFI) .........................................................................99 6.3.7.1 Datenaustausch ..........................................................................................99 6.3.7.1.1 Aktualisierung ......................................................................................99 6.3.7.2 DFI-Referenzdaten anfragen (AboAZBRef).................................................99 6.3.7.3 Linienorientierte DFI-Referenzdaten übermitteln (AZBLinienFahrplan) ..... 101 6.3.7.3.1 Einzelne DFI-Ankunfts-/Abfahrtsdaten (AZBSollFahrt) ...................... 102 6.3.7.3.2 Verfügbarkeitshorizont (Zeitfenster) ................................................... 102 6.3.7.3.3 HaltInfoSollMitAusfallGroup ............................................................... 103 6.3.7.3.4 HaltSollGroup .................................................................................... 103 6.3.7.3.5 Informationen zum Service der Fahrt oder am Halt (ServiceAttribut) . 104 6.3.7.3.6 AbfahrtSollMitAusfallGroup ................................................................ 104 6.3.7.3.7 AbfahrtSollGroup ............................................................................... 104

VDV 453 Version 3.1.0 - 7 - 23.09.2024

[Seite 8]

Inhaltsverzeichnis VDV 453

6.3.7.3.8 AbfahrtAusfallGroup .......................................................................... 105 6.3.7.3.9 AnkunftSollMitAusfallGroup ............................................................... 105 6.3.7.3.10 AnkunftSollGroup ............................................................................ 105 6.3.7.3.11 AnkunftAusfallGroup ........................................................................ 106 6.3.8 Prozessdatendienst (DFI) ................................................................................. 106 6.3.8.1 Datenaustausch ........................................................................................ 106 6.3.8.2 DFI-Daten anfragen (AboAZB) .................................................................. 109 6.3.8.3 Nachrichten des Anzeigerbenutzers (AZBNachricht) ................................ 111 6.3.8.3.1 Prognosedaten übermitteln (AZBFahrplanlage) ................................. 112 6.3.8.3.2 Traktion im Verbund (Traktion) .......................................................... 119 6.3.8.3.3 Linienspezialtexte übermitteln (AZBLinienspezialtext) ....................... 121 6.3.8.3.4 Sondertexte übermitteln (AZBSondertext) ......................................... 122 6.4 Visualisierung von Fremdfahrzeugen (VIS) ........................................................ 124 6.4.1 Einleitung ......................................................................................................... 124 6.4.2 Betriebliche Datenversorgung und –pflege ....................................................... 124 6.4.3 Prozessdatendienst .......................................................................................... 125 6.4.3.1 Ablauf ....................................................................................................... 125 6.4.3.2 Visualisierungsdaten anfragen (AboVIS) ................................................... 125 6.4.3.3 Nachrichten des Visualisierungsdienstes (VISNachricht) .......................... 126 6.4.3.3.1 Visualisierungsdaten übermitteln (VISFahrplanlage) ......................... 126 6.5 Allgemeiner Nachrichtendienst (AND) ................................................................ 130 6.5.1 Einleitung ......................................................................................................... 130 6.5.2 Nachrichtenformate .......................................................................................... 130 6.5.3 Betriebliche Datenversorgung und –pflege ....................................................... 131 6.5.4 Prozessdatendienst .......................................................................................... 131 6.5.4.1 Nachrichten anfragen (AboAND) ............................................................... 131 6.5.4.2 Nachrichten im Nachrichtendienst (ANDNachricht) ................................... 132 6.5.4.2.1 Nachrichten übermitteln (ANDMeldung) ............................................ 132 7 Glossar ........................................................................................................... 136 8 Verweise ......................................................................................................... 138 9 Englische Alias-Bezeichner .......................................................................... 139 9.1 Dienste ................................................................................................................... 139 9.2 Root-Elemente und komplexe Subelemente ....................................................... 139 9.3 Weitere Elemente .................................................................................................. 141 10 Anhang: Übertragung der Prognosequalität ............................................... 143 10.1 Begriffsdefinitionen .............................................................................................. 143 10.2 Stufendefinition, Grenzwerte ............................................................................... 144 10.3 Fortschreibungsregel ........................................................................................... 145

VDV 453 Version 3.1.0 - 8 - 23.09.2024

[Seite 9]

Inhaltsverzeichnis VDV 453

Änderungshistorie

VDV 453 Version 3.1.0 - 9 - 23.09.2024

[Seite 10]

Inhaltsverzeichnis VDV 453

VDV 453 Version 3.1.0 - 10 - 23.09.2024

[Seite 11]

Inhaltsverzeichnis VDV 453

VDV 453 Version 3.1.0 - 11 - 23.09.2024

[Seite 12]

Inhaltsverzeichnis VDV 453

VDV 453 Version 3.1.0 - 12 - 23.09.2024

[Seite 13]

Inhaltsverzeichnis VDV 453

Änderungshistorie von V 3.0 zu 3.1

VDV 453 Version 3.1.0 - 13 - 23.09.2024

[Seite 14]

Inhaltsverzeichnis VDV 453

VDV 453 Version 3.1.0 - 14 - 23.09.2024

[Seite 15]

Inhaltsverzeichnis VDV 453

VDV 453 Version 3.1.0 - 15 - 23.09.2024

[Seite 16]

Vorbemerkung VDV 453

1 Vorbemerkung

Die erste Version der VDV-Schrift 453 wurde 2001 unter dem Titel "Integrationsschnittstelle Rechnergestützter Betriebsleitsysteme" im Rahmen des Forschungsprojektes Stadtverkehr (FOPS) 70.0701/2002 des Bundesministeriums für Verkehr Bau, und Wohnungswesen (BMVBW) durch die Firmen BLIC, IAV und unter fachlicher Begleitung des VDV erarbeitet. Gleichfalls waren Partner aus ITCS-Industrie und Verkehrsunternehmen an der Spezifikation der Schrift beteiligt.

Folgende Dienste werden spezifiziert:

Tabelle 1 - Übersicht der Dienste

Als Referenz für die Implementierung der Dienste gilt jeweils das aktuelle XML-Schema (siehe VDV-Internetseite www.vdv.de/i-d-s-downloads.aspx), es enthält neben den o.g. Diensten auch den Referenz- und den Prozessdatendienst Fahrplanauskunft REF-AUS und AUS.

Der jeweilige Textband ist als Erläuterung für die jeweilige Anwendung zu verstehen.

Einen ähnlichen Funktionsumfang für die einzelnen Dienste mit teilweise etwas anderem Fo- kus stellt der SIRI-Standard EN 15531 zur Verfügung, der aus einem älteren Stand der VDV- Schrift entwickelt worden ist. Bei Anforderungen zum Datenaustausch, die über die Spezifika- tionen der vorliegenden Schrift hinausgehen, ist daher zunächst zu prüfen, ob diese Anforde- rungen durch den CEN-Standard erfüllt werden. In diesem Fall sollte eine Schnittstelle auf Basis des SIRI-Standards an Stelle einer proprietären Lösung realisiert werden.

Die vorliegende Version 3.X ist nicht in jedem Detail abwärtskompatibel zu den Vorgän- gerversionen 2.X

Eine Wandlung von 2.X auf 3.X in einer Datendrehscheibe ist immer möglich. Fehlende Infor- mationen sind dabei natürlich nicht verfügbar.

VDV 453 Version 3.1.0 - 14 - 23.09.2024

[Seite 17]

Vorbemerkung VDV 453

Wesentliche Neuerung ab Version 3.0 sind:

Mit der neuen Struktur der HaltID ist es möglich, unterschiedliche Aggregationsniveaus zu übertragen. Daher ist die Struktur inkompatibel zur Struktur der Vorgängerversion.

In der Version 3.0 der VDV-Schrift 453 wurden die Löschen-Meldungen geändert. Sie sind jetzt robuster und klarer strukturiert.

Kompatibilität zwischen DFI und AUS-Dienst wurde erreicht, um die Information für den Fahr- gast identisch zu halten und aus dem einen Dienst den anderen abbilden zu können. Dadurch ist zumindest teilweise keine Abwärtskompatibilität vorhanden.

Ein Verweis auf die VDV-Schriften 432/433 wurde eingefügt und die Abbildung von DHID, DFID, DLID, DTID beschrieben.

Die Dienste ANS und DFI können nun für ortsbezogene Informationen (Anschlussknoten und Anzeigen mit haltestellenbezogener Fahrplaninformationen) genutzt werden.

VDV 453 Version 3.1.0 - 15 - 23.09.2024

[Seite 18]

Einleitung VDV 453

2 Einleitung

Als wesentliche "weiche" Anforderungen an die zwischenbetriebliche Organisation der Ver- kehrsunternehmen, die ein solches Konzept einführen wollen, wurden die Aspekte

• des zwischenbetrieblichen Einvernehmens,

• der zwischenbetrieblichen kommerziellen Abstimmung

• sowie einer zwischenbetrieblichen abgestimmten (Teil-) Datenbasis

erkannt.

VDV 453 Version 3.1.0 - 16 - 23.09.2024

[Seite 19]

Einführung und Grundbegriffe VDV 453

3 Einführung und Grundbegriffe

3.1 Anschlusssicherung (ANS)

3.1.1 Aufgaben und Ziele

Eine direkte bzw. umsteigefreie Bedienung aller gewünschten Fahrtrelationen ist gerade in größeren Städten und Ballungsräumen praktisch unmöglich und für eine wirtschaftliche Be- triebsführung nicht sinnvoll. Ein Verkehrsunternehmen muss im Rahmen der Angebots-, Netz- und Fahrplanung, entsprechend vorherrschender Verkehrsströme, Umsteigebeziehungen zwi- schen einzelnen Linien im Sollfahrplan in Form der Anschlussplanung berücksichtigen.

Grundproblem bei der Anschlussplanung ist, dass für den Fahrgast im "gebrochenen Verkehr", d. h. in der Fahrtrelation mit Umsteigezwang, die Umsteigezeiten eine wesentliche Komfort- bzw. Akzeptanzgröße darstellen. Es besteht also der Anspruch, für jede Fahrtrelation mög- lichst minimale Wartezeiten beim Umsteigevorgang zu gewährleisten. Bei zu langen Umstei- gezeiten besteht die Gefahr, dass die so geplante Fahrtrelation nicht von den Fahrgästen an- genommen wird. Des Weiteren sind bei der Definition eines Anschlusses die zeitlichen und örtlichen Randbedingungen (Wegezeiten zwischen der Ankunftshaltestelle und der neuen Ab- fahrtshaltestelle) und die für den überwiegenden Teil aller Anschlüsse betrieblichen und zu bestimmten Tagesperioden gültigen allgemeinen Vorgaben zu berücksichtigen.

Dieses für zwei Linien und einem Umsteigepunkt noch weitestgehend beherrschbare Problem, führt bei einer Vielzahl von Umsteigepunkten und daran beteiligten Linien zu der Tatsache, dass nur ausgewählte Umsteige- bzw. Fahrtrelationen adäquat im Sollfahrplan als geplanter Anschluss berücksichtigt werden können.

Für einen Anschluss sind immer zwei Kursfahrzeuge notwendig: Der "Zubringer" und der "Ab- bringer".

3.1.2 Zubringer-Abbringer-Prinzip

Die betriebsinterne Anschlusssicherung ist bereits eine etablierte Dispositionsfunktion. Durch den Vergleich von mindestens zwei Fahrplanlagen zu einer festgelegten und von den Fahr- gästen benötigten Übergangszeit an der Anschlusshaltestelle kann das Abbringerfahrzeug in einer definierten Zeitspanne angewiesen werden, auf das Zubringerfahrzeug zu warten.

Die angestrebte Lösung zur Umsetzung der Anschlusssicherung folgt dem Zubringer-Abbrin- ger-Prinzip. Dabei bilden jeweils zwei Fahrzeuge eine Anschlussbeziehung. Durch den gegen- seitigen Verweis von Zubringer-Abbringer-Beziehungen (d. h. Zubringer ist auch gleichzeitig Abbringer) sind damit auch Mehrfach- und Blockanschlüsse zu realisieren.

VDV 453 Version 3.1.0 - 17 - 23.09.2024

[Seite 20]

Einführung und Grundbegriffe VDV 453

Fahrten F1 F2

Umsteige- haltestelle

Zeit

Übergangszeit

Abbildung 1: Zubringer-Abbringer-Anschluss

Fahrten F1 F2

Umsteige- haltestelle

Zeit

gemeinsamer Aufenthalt

Abbildung 2: Blockanschluss

Fahrten F1 F2 F3

Umsteige- haltestelle

Zeit

Übergangszeit 1

Übergangszeit 2

Abbildung 3: Mehrfachanschluss

VDV 453 Version 3.1.0 - 18 - 23.09.2024

[Seite 21]

Einführung und Grundbegriffe VDV 453

3.1.3 Definition der betriebsübergreifenden Anschlusssicherung

Wie auch die betriebsinterne Anschlusssicherung soll die betriebsübergreifende Anschlusssi- cherung möglichst automatisch durch den Datenaustausch zwischen den Dispositions- systemen der Verkehrsunternehmen erfolgen und nur in Zweifelsfällen (Verletzung einer Randbedingung) dem Disponenten zur manuellen Entscheidung überlassen werden. Grund- voraussetzung für eine automatisierte Anschlusssicherung ist es, dass das ITCS, das auf ei- nen Abbringer Einfluss nehmen soll (z.B. Anweisung zum Warten auf einen verspäteten Zu- bringer) über derartige Dispositionshilfen und Funktionen in der ITCS-Software verfügt. Das Zubringer-ITCS muss diese Funktionalität nicht aufweisen, es sei denn, es übernimmt im um- gekehrten Fall selbst Abbringerfunktionen.

Der Abstimmungsprozess zwischen den Verkehrsunternehmen muss eine einheitliche, bilate- rale Definition der Anschlüsse beinhalten.

3.1.4 Betriebsausprägungen

3.1.4.1 Bahnhof

Bahnhöfe besitzen in der Regel mehrere Gleise. Den gesamten Bahnhof als Haltestelle zu definieren hat den Nachteil, dass keine separaten Umsteigezeiten von einem Gleis etwa zu einer Bushaltestelle auf dem Bahnhofsvorplatz angegeben werden können. Besser erscheint hier die Modellierung des einzelnen Gleises als "Haltestelle". Hier stellt sich jedoch das Prob- lem, dass Züge aus betrieblichen Gründen das Einfahrtgleis wechseln können und somit den eigentlich definierten Anschlussbereich nicht erreichen. Hier ist eine entsprechende Logik im zubringenden System zu implementieren, die eine Gleisänderung für den Abbringer transpa- rent erscheinen lässt. Das zubringende System meldet also weiterhin Prognosen für den ur- sprünglich geplanten Anschlussbereich an den Abbringer, obwohl der Zubringer den eigentli- chen ASB nicht erreicht. Intern wird dies durch ein Mapping der "alten" Zubringerhalte- stelle/Gleis zur neuen Haltestelle/Gleis durchgeführt.

3.1.4.2 Mehrfachanschlüsse

Viele ITCS-Systeme erlauben die Definition von sogenannten Block- oder Systemanschlüssen (n:m-Relationen). Hier sind mehrere Fahrten an mehreren Haltestellen beteiligt, die unterei- nander verschiedene Zu- und Abbringerfunktionalität besitzen.

Bei der fahrtbezogenen Anschlusssicherung (s. Kapitel 3.1.9) müssen diese Anschlüsse in Einzelanschlüsse (1:1-Relationen) aufgelöst werden. Einem Abbringer wird genau ein Zubrin- ger zugeordnet.

Bei der zeitbezogenen Anschlusssicherung (s. Kapitel 3.1.10) kann ein Abbringer mehrere Zubringer haben (n:1-Relation).

VDV 453 Version 3.1.0 - 19 - 23.09.2024

[Seite 22]

Einführung und Grundbegriffe VDV 453

3.1.5 Mehrfach angefahrene Haltestellen

Wird eine Haltestelle während einer Fahrt mehrfach angefahren, sind Ort und Fahrtbezeichner nicht ausreichend, um eine Einfahrt eindeutig zu identifizieren. Aus diesem Grund wird ein zusätzlicher Zähler mitgeführt. Dabei gilt, dass eine Einfahrt an einer Haltestelle einen kleine- ren Zähler-Wert besitzt als eine spätere Einfahrt. Der Zähler muss nicht fortlaufend zählen. So können entweder die Anschlusszeit (als Ganzzahl kodiert) oder der Haltestellenindex direkt verwendet werden.

3.1.6 Fahr- und Anschlussplanung (Sollfahrplan)

Die vorliegende Schrift beschreibt die technische Schnittstelle der Anschlusssicherung. Diese technische Realisierung ersetzt keine vorher zu führenden innerbetrieblichen Abstimmungen sowie betriebsübergreifende Vereinbarungen zwischen den Verkehrsunternehmen. Für die Planung und Durchführung der Anschlusssicherung sind alle betrieblichen und verkehrlichen Randbedingungen im Vorfeld festzulegen.

Anhand der erstellten Sollfahrpläne können mögliche Anschlusspunkte identifiziert und zwi- schenbetrieblich bzw. als überbetriebliche Vorgabe z.B. durch Verbünde vorgegeben werden.

Es sind die beteiligten Linien und ihre Funktionen (Zu- oder Abbringer) festzuhalten.

Schließlich ist der Zeitbereich (z.B. über Uhrzeiten oder Fahrtbezeichner) zu benennen, in welchem dieser Anschluss gesichert werden soll. Hintergrund ist die sinnvolle Beschränkung auf – aus Fahrgastsicht – wichtige Anschlusszeiten, insbesondere also Tagesrandlagen oder Zeitbereiche mit großen Taktzeiten. In diesem Zusammenhang ist zu berücksichtigen, was passiert, wenn ein Anschluss gehalten wird und dadurch mögliche Folgeanschlüsse gefährdet werden.

Abhängig von den örtlichen Begebenheiten sind die für den Umstieg der Fahrgäste notwendi- gen Übergangszeiten zwischen den Haltestellen zu benennen.

VDV 453 Version 3.1.0 - 20 - 23.09.2024

[Seite 23]

Einführung und Grundbegriffe VDV 453

Verkehrsbetrieb 1 Verkehrsbetrieb 2

Personal Fahrzeuge

Ressourcen

Bediengebiet Verkehrsangebot Verkehrsangebot Einwohner Verkehrs-

Modalsplit nachfrage

bestellte Leistungen Sollfahrplan Sollfahrplan

Anschluss- definition

Abbildung 4: Sollfahrplan und Anschlussdefinition

3.1.7 Anschlussbereiche

Anschlussbereiche dienen der Vereinbarung von Umsteigebeziehungen. Sie ersetzen die di- rekte Abbildung interner Haltestellenbezeichner der jeweiligen Systeme. Dadurch wird die Da- tenhaltung der Systeme entkoppelt. Zugleich findet eine Abstraktion von der Bedeutung des internen Schlüssels statt. Es können so auch direkt ganze Haltestellenbereiche zweier Be- triebe miteinander in eine Umsteigebeziehung gesetzt werden.

3.1.8 Fahrgastinformation Innenanzeige

Der ANS-Dienst stellt auch einen sogenannten "Rückkanal" bereit. Über diesen ist es möglich, dem Zubringer mitzuteilen, ob und ggf. wie lange die Abfahrt des Abbringers herausgezögert wird. Diese Information könnte den Fahrgästen in Fahrzeug-Innenanzeigen dargestellt wer- den.

3.1.9 Fahrtbezogene Anschlusssicherung

Die fahrtbezogene Anschlusssicherung entspricht dem Ansatz der Anschlusssicherung der VDV453 Version 1.0. Dabei werden zu Beginn des Betriebstages Sollfahrpläne (Referenzda- ten) ausgetauscht. In der anschließenden Phase des Prozessdatenaustausches werden nur noch aktuelle Verspätungslagen kommuniziert.

Ab der VDV453 Version 2.0 sind auch Aktualisierungen der Solldaten möglich. So können zusätzliche Fahrten auch kurzfristig kommuniziert werden.

Die Einbeziehung stark verspäteter Fahrten (Ersatz für Folgefahrt) ist nach wie vor nicht mög- lich.

Vorteil dieses Verfahrens stellt die frühe Definition der Anschlüsse dar. Somit können die Fahr- gäste bereits im Vorfeld über stattfindende Anschlüsse informiert werden.

VDV 453 Version 3.1.0 - 21 - 23.09.2024

[Seite 24]

Einführung und Grundbegriffe VDV 453

3.1.10 Zeitbezogene Anschlusssicherung

Die zeitbezogene Anschlusssicherung ist gegenüber Version 1.0 eine neue Variante der An- schlusssicherung. Sie ermöglicht es, dass ohne vorherigen Austausch von Referenzdaten An- schlusssicherung gesichert werden können. Dabei erfolgt die Anfrage an das zubringende System bei tatsächlichem Zulauf eines Abbringers auf einen Anschlussbereich. Die Anfrage definiert dabei einen Ort und Zeitbereich, der die Menge der Fahrten auf Basis ihrer prognos- tizierten Ankunftszeit am Anschlussbereich beschränkt. Zugleich können Linien- und Rich- tungsfilter die Datenmenge begrenzen.

Die zeitbezogene Anschlusssicherung kann somit auch alle dispositiven Maßnahmen abde- cken, die zu einer Abweichung der Ankunftstafel an der Zubringerhaltestelle führen. Auch stark verspätete Fahrzeuge können so Zubringern werden.

Ein möglicher Nachteil stellt die späte Bekanntgabe der Anschlussdefinition dar. Durch geeig- nete Definitionen in der Datenpflege kann aber eine gleichwertige Planbarkeit in der Definition der Anschlüsse erreicht werden.

3.2 Dynamische Fahrgastinformation (DFI)

3.2.1 Aufgaben und Ziele

Ziel des Dienstes "Dynamische Fahrgastinformation (DFI)" ist es, die Möglichkeit zu schaffen, Fremdfahrten an eigenen, gemeinsam bedienten Haltestellen anzuzeigen. Der Datenaus- tausch erfolgt dabei ortsbezogen, d. h. es werden Abfahrtstafeln für zuvor gemeinsam defi- nierte Orte übermittelt.

Zu unterscheiden sind dabei Fahrgastinformationen im Fahrzeug und an der Haltestelle. Die Anschlussinformation in Zubringerfahrzeugen wird innerhalb des Dienstes Anschlusssiche- rung realisiert. Die optische und dynamische Fahrgastinformation an Haltestellen ist inzwi- schen ein wesentliches Element rechnergestützter Betriebsleitsysteme.

Mit folgenden Eigenschaften lässt sich der DFI-Dienst beschreiben:

→ Einzelprognosen für jeden Anzeiger (ortsbezogene Prognosen)

→ Scharfe und unscharfe Abmeldung (Funk oder ITCS-Nachricht)

→ Start/Ziel/Via-Texte (Kürzel und Volltext)

→ Fahrtspezialtexte

→ Linienspezialtexte

→ Textlängenspezifikation

→ Vorschauzeiten zur bedarfsgerechten Kommunikation

3.2.2 Datenversorgung und Ansteuerung

Der fachliche Dienst DFI adressiert die gemeinsame Benutzung von DFI-Anzeigern. Ein Fremdunternehmen möchte die Ankunft/Abfahrt eines Fahrzeuges auf einem Anzeiger eines

VDV 453 Version 3.1.0 - 22 - 23.09.2024

[Seite 25]

Einführung und Grundbegriffe VDV 453

anderen Verkehrsunternehmens anzeigen. Das System, welches den Anzeiger ansteuert, wird "Anzeigerbesitzer" genannt. Das System, welches ein Fahrzeug auf einem fremden Anzeiger darstellen möchte, wird "Anzeigerbenutzer" genannt.

Zwei unterschiedliche Verfahren werden durch den fachlichen Dienst DFI abgedeckt bzw. spe- zifiziert:

→ Ansteuerung einzelner Anzeiger mit Volltext-Informationen

→ Ansteuerung einzelner Anzeiger mit Schlüsselwerten anstelle von Volltexten

Das Volltextverfahren stellt die einfachste Möglichkeit dar, Anzeiger mit Daten zu versorgen. Es ist besonders geeignet, wenn wenige Anzeiger angesteuert werden sollen und die verfüg- bare Übertragungskapazität zwischen ITCS und Anzeiger dies zulässt.

Die Variante mit Schlüsselversorgung kann eingesetzt werden, wenn die Übertragungskapa- zität zwischen ITCS und Anzeiger kritisch ist. Durch die Verwendung von Schlüsseln kann der Kapazitätsbedarf entsprechend reduziert werden.

Die Fahrgastinformation benötigt in ihrer einfachsten Form keinen Austausch von Referenz- daten. Relevant ist ausschließlich der Datenaustausch zur Laufzeit. Vorausgesetzt wird aller- dings, dass eine Liste von Anzeigerbereichen vorhanden ist, anhand deren das ITCS erkennen kann, wo "fremde" Anzeiger vorhanden sind, auf denen etwas angezeigt werden soll. Manche Systeme benötigen jedoch trotzdem den Zugriff auf Plandaten, um Fremdfahrten operativ ver- arbeiten zu können. Für diese Systeme gibt es eine zusätzliche Referenzdatenschnittstelle, welche die benötigten Fahrplaninformationen bereitstellt.

Vom Grundsatz her trägt der "Anzeigerbesitzer" die Verantwortung dafür, welche Informatio- nen angezeigt werden. Das fremde ITCS liefert hierfür eine Anzeigebereichs-Information, die folgende Angaben enthält:

→ Fahrt-ID

→ Ankunftszeit und/oder Abfahrtszeit

→ Linien- und Richtungstext

→ Steig (z.B. Gleis 5, Bahnsteig C, o. ä.)

→ Fahrtziel

→ Via-Angaben

→ Bemerkungen

→ Linienspezialtexte

→ Fahrtspezialtexte

Die Ansteuerung von Anzeigersystemen auf Schlüsselbasis erfordert eine gemeinsame be- triebliche Datenversorgung. (Fremd-)Texte und zugehörige Schlüssel müssen dem anzeiger- besitzenden System bekannt gemacht werden. Über die Schnittstelle werden nach wie vor Volltexte übermittelt. Durch die Verfügbarkeit von Tabellen auf Seiten des Anzeigerbesitzers

VDV 453 Version 3.1.0 - 23 - 23.09.2024

[Seite 26]

Einführung und Grundbegriffe VDV 453

kann über einen Textvergleich der zugehörige Schlüssel ermittelt und zum Anzeiger gesendet werden.

3.2.3 Anzeigerbereiche

Analog zur Anschlusssicherung erfordert die gemeinsame Benutzung von Anzeigern zunächst eine gemeinsame Referenzierung derselben. Für jeden gemeinsam benutzten Anzeiger (bzw. eine zusammengehörige Gruppe) wird ein sogenannter Anzeigerbereich mit zugehörigem ein- deutigem Schlüssel (AZBID) definiert.

Das anzeigerbenutzende System verknüpft die eigenen, am Anzeigerbereich befindlichen Hal- testellen mit dem Schlüssel des Anzeigerbereichs und kann so Ankünfte oder Abfahrten an einer Haltestelle mit einem Fremd-Anzeiger in Verbindung setzen. Der Anzeigerbesitzer wie- derum verknüpft die internen Schlüssel seiner Anzeiger mit denen der gemeinsam definierten Anzeigerbereiche. Somit ist die Referenzierungskette vom Anzeigerbenutzer zum Anzeiger- besitzer geschlossen. (Näheres siehe 6.3.2)

3.3 Visualisierung von Fremdfahrzeugen (VIS)

3.3.1 Aufgaben und Ziele

Der Dienst "Visualisierung von Fremdfahrzeugen" (VIS) unterstützt Leitstellenmitarbeiter bei der Beobachtung und Disposition von Fremdfahrzeugen im eigenen ITCS. Dazu bietet der Dienst die Funktion, Informationen über fremde Fahrzeuge zu übermitteln, um diese in den Betriebsdarstellungen des eigenen Systems anzeigen zu können. Weitere Nutzungsmöglich- keiten wie für GPS-Positionen für Kartendarstellung sind denkbar.

Der Dienst stellt folgende Daten zur Verfügung:

• Geo-Position des Fahrzeuges (Kartendarstellung)

• Position des Fahrzeuges bezogen auf seine Route (Linienband-Darstellung)

• Anzeige in einer Fahrzeugliste

• Weitere Informationen zur Fahrt (Start- und Ziel-Haltestelle, ServiceAttribute, etc.)

Schematische Linienbanddarstellungen benötigen zur Anzeige ein hinterlegtes Routenmodell der Fahrt. Dies kann durch die Pflege von Dummy-Routen innerhalb des eigenen Systems geschehen. Funktionen zur direkten Disposition werden über diese Schnittstelle nicht bereit- gestellt. Hierfür sind andere Kanäle (Funk) zu nutzen. Zudem wird für eine Linienband-Dar- stellung eine gemeinsame Routenversorgung vorausgesetzt. Dies wird ebenfalls nicht durch die Schnittstelle abgedeckt und muss daher auf anderem Wege erfolgen, wenn eine solche Darstellungsform gewünscht wird.

3.3.2 Visualisierungsbereiche

Da in der Regel die Darstellung von Fremdfahrzeugen selektiv (z.B. bezogen auf Liniengrup- pen) erfolgen wird, bietet die Schnittstelle die Möglichkeit, die Daten auch dementsprechend

VDV 453 Version 3.1.0 - 24 - 23.09.2024

[Seite 27]

Einführung und Grundbegriffe VDV 453

anzufordern. Dazu werden sogenannte Visualisierungsbereiche gebildet. Dies sind abstrakte Mengenbezeichner, die Art und Menge der anzufordernden Daten definieren.

In der Regel wird ein Visualisierungsbereich linienbezogen definiert sein. Ein Visualisierungs- bereich wird einer oder mehreren Linien zugeordnet. Somit werden auf eine Anfrage die Daten der dem Visualisierungsbereich zugeordneten Linien ausgetauscht. Alternativ kann ein Visua- lisierungsbereich auch räumlich (Umkreis) oder fahrtbezogen definiert sein. Dies erfordert al- lerdings ggf. eine aufwändige Laufzeitprüfung, die die Fahrzeuge einem Visualisierungsbe- reich zuordnen.

Visualisierungsbereiche sind zwischen den beteiligten Systemen bilateral gemäß den betrieb- lichen Vorgaben abzustimmen.

3.4 Allgemeiner Nachrichtendienst (AND)

3.4.1 Aufgaben und Ziele

Der "Allgemeine Nachrichtendienst (AND)" dient dem Austausch von betrieblichen Informatio- nen zwischen den Mitarbeitern der beteiligten Leitstellen. Er stellt die Möglichkeit zur Verfü- gung, textuelle Botschaften zwischen den Leitstellen auszutauschen. Dieser Dienst kann somit ein Ersatz für Informationsmittel wie Fax oder E-Mail darstellen. Die Vorteile gegenüber diesen Lösungen stellen die sofortige Übermittlung sowie die einfache Integration in die Leitstel- lensoftware dar.

Nachrichten können verschickt, aber auch wieder zurückgezogen (beim Empfänger gelöscht) werden. Nachrichten besitzen neben dem eigentlichen Inhalt zusätzlich eine Gültigkeit.

Hinweis: Der VDV AK Umgang mit Störungsmeldungen (UmS) hat die VDV-Schrift 736 erar- beitet, um für die Übermittlung von Störungsmeldungen den Dienst SIRI-SX (statt AND) zu nutzen.

3.4.2 Nachrichtenkanäle

Im Nachrichtendienst ist jede Leitstellennachricht einem sogenannten Nachrichtenkanal zuge- ordnet. Der Nachrichtenkanal stellt eine bilaterale Vereinbarung hinsichtlich der Klassifizierung der Inhalte dar.

So können die Nachrichten entsprechend den Bedürfnissen der Leitstellenmitarbeiter struktu- riert angezeigt und verwaltet werden.

3.4.3 Nachrichtenformate

Über den Nachrichtendienst können sowohl unstrukturierte, als auch strukturierte Informatio- nen (CSV, XML, etc.) geschickt werden. Das XML-Content-Modell lässt eine freie Ausgestal- tung zu.

Zusätzlich gibt es ein Format-Attribut, welches die automatische Erkennung verschiedener Formate erlaubt.

VDV 453 Version 3.1.0 - 25 - 23.09.2024

[Seite 28]

Architektur VDV 453

4 Architektur

4.1 Kommunikation vs. fachliche Dienste

Die Schnittstelle besteht aus zwei Schichten.

1. Kommunikationsschicht

2. Schicht der fachlichen Dienste

Die Kommunikationsschicht definiert ein einheitliches Verfahren, Daten anzufordern und an- schließend auszutauschen. Dieses Verfahren wird im weiteren Abonnement-Verfahren ge- nannt. Dabei erzeugt das datenkonsumierende System sogenannte Abonnements, die Art und Menge der auszutauschenden Daten definieren. Diese Definition ist fachlich spezifisch und somit bereits in der fachlichen Schicht anzusiedeln. Das Kommunikationsverfahren ist für alle fachlichen Dienste gleich und stellt somit die Infrastruktur für die Schnittstelle dar (Botschafts- referenzierung, Fehlerbehandlung, Wiederaufsetzverhalten). Durch die Wiederverwendung für die verschiedenen fachlichen Dienste ist eine kostengünstige Implementierung und Erweite- rung der Schnittstelle möglich.

Die fachlichen Dienste wiederum setzen auf der Kommunikationsschicht auf und adressieren verschiedene Anwendungsbereiche wie Anschlusssicherung, DFI, etc.. Die Dienste besitzen untereinander keine Abhängigkeit, so dass jede beliebige Untermenge von fachlichen Diens- ten implementiert werden kann. Eine anwendungsfallbezogene Realisierung ist somit sicher- gestellt.

4.2 Referenz- vs. Prozessdaten

Die in den fachlichen Diensten ausgetauschten Daten lassen sich in zwei Klassen einteilen:

• Referenzdaten (Soll-Daten)

• Prozessdaten (Ist-Daten)

Jeder fachliche Dienst (Anschlusssicherung, DFI, etc.) muss in jedem Fall den Prozessdaten- austausch realisieren, da es ja um den Austausch von aktuellen Informationen zwischen zwei Leitsystemen geht. Der Austausch von Referenzdaten ist nur dann notwendig, wenn die Pro- zessdaten nicht alleinig verwendet werden können, sondern zuvor auf Referenzdaten bezo- gen/verrechnet werden müssen, um einen Mehrwert zu generieren.

Der Austausch von Referenzdaten stellt in der Regel eine Alternative zu einem Austausch von Daten auf Ebene der Datenpflege dar. Die Implementierung und Verwendung eines Referenz- datendienstes ist also abhängig vom Anwendungsfall sowie von den technisch-betrieblichen Voraussetzungen. Jeder fachliche Dienst kann somit aus zwei technischen Diensten beste- hen. Der Prozess- und Referenzdatenaustausch werden innerhalb der Schnittstelle jeweils als eigenständige technische Dienste realisiert.

VDV 453 Version 3.1.0 - 26 - 23.09.2024

[Seite 29]

Architektur VDV 453

4.3 Verwendete Protokolle

Es werden zwei Protokolle in der Schnittstelle verwendet:

1. HTTP/1.1 oder HTTPS als Transportprotokoll

2. XML 1.0 zur Auszeichnung der fachlichen Daten

Die XML-Spezifikation erfolgt mittels XML Schema Version 1.0.

VDV 453 Version 3.1.0 - 27 - 23.09.2024

[Seite 30]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

5 Schnittstellenbeschreibung "Basisinfrastruktur"

5.1 Abonnement-Verfahren

5.1.1 Überblick

Das sogenannte Abonnement-Verfahren definiert eine einheitliche Basis-Kommunikations- struktur, auf der alle fachlichen Dienste aufsetzen. Das Abonnement-Verfahren besteht aus einem Satz von Anfrage- und Antwort-Botschaften, die eine asynchrone Kommunikations- struktur definieren.

Das Konzept folgt dem Client-Server-Modell. Ein System A (Server) kann einem anderen Sys- tem B (Client) Daten zur Verfügung stellen.

Das verwendete Konzept ist ereignisorientiert. Aufgrund einer Aktion innerhalb des Server- Systems (A) ändern sich Daten, die dann zum Client-System (B) kommuniziert werden (siehe Abbildung 5: Kommunikationsablauf des Abonnement-Verfahrens).

Zunächst vereinbaren Client und Server, welche Informationen ausgetauscht werden sollen. Dies erfolgt durch sogenannte Abonnements. Abonnements werden clientseitig definiert. Der Client schickt eine Abonnements-Anfrage zum Server und registriert sich somit als Interessent für bestimmte Daten (Schritt 1). Um welche Daten es sich dabei handelt wird fachspezifisch innerhalb der eigentlichen Abonnement-Anfrage definiert. Nach einer Bestätigung durch den Server kann der Client von einer anschließenden Datenversorgung ausgehen.

Anschließend benachrichtigt der Server (A) den Client (B) mittels einer Botschaft über neue oder veränderte Daten (Schritt 2). Der Client (B) kann darauf explizit die Daten vom Server (A) abholen (Schritt 3).

Um Ausfälle des Servers festzustellen, können periodisch Statusanfragen an den Server ge- stellt werden. Mit einer Statusantwort erklärt der Server seine Funktionstüchtigkeit (Schritt 4).

Abonnements besitzen eine vom Client definierte Lebensspanne und werden nach Ablauf au- tomatisch vom Server gelöscht. Das Löschen kann vorzeitig auch explizit durch den Client erfolgen (Schritt 5).

Die Verwaltung der Dienste erfolgt fachspezifisch. Abonnements werden durch sogenannte AboIDs referenziert. Eine AboID ist innerhalb eines jeden Dienstes eindeutig. Die Vergabe der AboIDs erfolgt durch den Client innerhalb der Anfrage nach einem Abonnement.

VDV 453 Version 3.1.0 - 28 - 23.09.2024

[Seite 31]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Abbildung 5: Kommunikationsablauf des Abonnement-Verfahrens

5.1.2 Abonnements einrichten

Sofern Daten von einem externen System angefordert werden sollen, sind zu diesem Zweck Abonnements einzurichten. Dieses geschieht durch das Senden sogenannter AboAnfragen durch den Client.

5.1.2.1 Abonnementsanfrage (AboAnfrage)

Eine AboAnfrage definiert ein Abonnement (= Subelement). Jedes Abonnement besitzt eine für den Dienst eindeutige Identifikation (AboID). Diese wird durch den Client generiert und verwaltet.

Innerhalb des Abonnements definiert ein dienstspezifisches Subelement die möglichen Ant- worten. Alle Botschaften zur Definition eines Abonnements folgen der Namenskonvention AboXYZ, wobei "XYZ" für das jeweilige Dienstbezeichnerkürzel (ASB, AZB, VIS, …), bzw. für die entsprechende Aktion steht.

VDV 453 Version 3.1.0 - 29 - 23.09.2024

[Seite 32]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Folgende Abonnements-Anfragen sind definiert:

• Anschlusssicherung Abonnieren von Zubringerdaten (AboASBRef 6.2.3.2, AboASB 6.2.4.2)

• Fahrgastinformation Abonnieren von Daten für auf DFI-Anzeiger zulaufende Fahrten von Fremdbetrieben. (AboAZBRef 6.3.7.2, AboAZB, 6.3.8.2)

• Visualisierung Abonnieren von Fahrtdaten für Visualisierungsbereiche (AboVIS 6.4.3.2)

• Nachrichtendienst Abonnieren von allgemeinen Textmeldungen aus der Fremdleitstelle (AboAND 6.5.4.1)

• Löschen Löschen eines oder aller Abonnements (AboLoeschen/Alle 5.1.4.2.1)

Eine AboAnfrage bezieht sich dabei immer auf genau einen fachspezifischen Dienst. Wird eine AboAnfrage mit einer AboID gestellt und es existiert bereits ein Abonnement unter dieser Be- zeichnung, so wird das bestehende Abonnement überschrieben.

VDV 453 Version 3.1.0 - 30 - 23.09.2024

[Seite 33]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Jedem Abonnement wird beim Einrichten ein Verfallszeitstempel (VerfallZst) durch den Client mitgegeben. Dieser definiert, wie lange der Server die Abonnements speichern und verwalten muss. Der Zeitstempel ist daher so zu wählen, dass er hinter dem letzten, potenziellen Daten- meldezeitpunkt liegt. Abonnements sollten keine längere Gültigkeit erhalten, als unbedingt not- wendig, da für jedes Abonnement Ressourcen vorgehalten werden müssen. Abonnements können Gültigkeit über die Grenzen des eigenen Betriebstages besitzen. Mit dem Attribut XSDVersionID gibt der Client an, welche Schnittstellenversion er benutzt. Siehe auch Kapitel 5.1.2.2.

In der Erstmeldung nach jeder AboAnfrage müssen generell alle zum Abo passenden Daten gesendet werden (sie können bei Verwendung von WeitereDaten=true in mehreren Paketen geliefert werden). Ausnahmen: AboAZB oder AboAUS mit dem Element 'NurAktualisierung'.

Folgendes Beispiel zeigt verallgemeinert die Anfrage von ITCS A auf Einrichtung eines Abon- nements mit der ID 25 mit einer Gültigkeit von einer Stunde.

5.1.2.2 Abonnementsbestätigung (AboAntwort)

Nachdem der Datenproduzent (Server) die Anfrage entgegengenommen hat, bestätigt er mit einer AboAntwort.

Mit dem optionalen Element XSDVersionID in AboAnfrage und AboAntwort tauschen Client und Server die Versionskennung der Schnittstelle aus, die jeder von ihnen verwendet. Damit können beide Seiten Kompatibilitätsprüfungen vornehmen. Die aktuelle Version ist im XML- Schema im Attribut Version angegeben (Dateiname des XSD-Files, z.B. "xsd_2017.a"). Es wird an dieser Stelle nicht zwingend gefordert, dass beide Seiten dieselbe Version verwenden. Für bestimmte Anwendungsfälle bleibt zwischen zwei Schnittstellenversionen unter Umstän- den genug Abwärtskompatibilität, um ein Funktionieren des Datenaustauschs im spezifischen Kontext zu ermöglichen. In gleicher Weise ist bei unterschiedlichen Schnittstellenversionen auch keiner der Partner verpflichtet, Kompatibilitätskonvertierungen bereitzustellen. Der

VDV 453 Version 3.1.0 - 31 - 23.09.2024

[Seite 34]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Umgang mit unterschiedlichen Schnittstellenversionen und mögliche Migrationspfade müssen projektspezifisch geklärt werden.

Ist die Bestaetigung beim Datenkonsumenten (Client) mit "ok" eingegangen, kann er sicher sein, dass das Abonnement eingerichtet wurde. Ansonsten ist die Anfrage erneut zu stellen. Eventuell auf Serverseite eingerichtete Abonnements werden dabei überschrieben.

Folgendes Beispiel zeigt eine Bestätigung, wenn das Abo erfolgreich eingerichtet werden konnte:

Das Element Bestaetigung liefert Informationen, ob die Anfrage bearbeitet werden konnte, eventuelle Fehlercodes und -beschreibungen sowie eine Information über die maximal mögli- che Aktualisierungsrate des Datenproduzierenden (s. Kapitel 6.1.1).

5.1.3 Daten bereitstellen

5.1.3.1 Datenbereitstellung signalisieren (DatenBereitAnfrage)

Ist das Abonnement eingerichtet und sind die Daten bereitgestellt, wird der Datenkonsument durch eine DatenBereitAnfrage über das Vorhandensein aktualisierter Daten informiert. Dies geschieht bei jeder Änderung der Daten, die dem Abonnement zugeordnet sind. Die Signali- sierung bezieht sich auf alle Abonnements eines Dienstes.

VDV 453 Version 3.1.0 - 32 - 23.09.2024

[Seite 35]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Folgendes Beispiel zeigt die Signalisierung neuer Daten in einem Dienst des ITCS A:

5.1.3.2 Datenbereitstellung bestätigen (DatenBereitAntwort)

Der Datenkonsument (Client) bestätigt den Erhalt der Signalisierung durch eine Nachricht vom Typ DatenBereitAntwort. Diese Botschaft enthält ein Element vom Typ Bestaetigung:

Folgendes Beispiel zeigt eine mögliche Antwort auf die obige Anfrage:

Die Daten können nun vom Client abgeholt werden. Möchte der Client in diesem Moment keine Daten abfordern, so kann er dies auf einen späteren Zeitpunkt verschieben. Das Abrufen der Daten erfolgt unabhängig von der Änderungssignalisierung.

5.1.4 Daten abrufen

Das Abrufen der Daten erfolgt auf Initiative des Datenkonsumenten (Client). Übertragen wer- den ausschließlich die aktuellen Ist-Informationen. Eine Historie ist nicht verfügbar.

5.1.4.1 Datenübertragung anfordern (DatenAbrufenAnfrage)

Die Abfrage erfolgt üblicherweise nach der Signalisierung aktualisierter Daten (DatenBereit- Anfrage), kann aber zu beliebiger Zeit nach Einrichten des Abonnements stattfinden. Der Cli- ent schickt eine Botschaft vom Typ DatenAbrufenAnfrage, welche den Server auffordert, die seit der letzten DatenAbrufenAnfrage aktualisierten Daten zurückzuliefern:

VDV 453 Version 3.1.0 - 33 - 23.09.2024

[Seite 36]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Folgendes Beispiel zeigt das Abholen nur der aktualisierten Daten:

Wird DatensatzAlle auf true gesetzt, werden nicht nur die seit der letzten Abfrage aktualisierten Daten kommuniziert, sondern die Datensätze aller aktiven Abonnements. (mehr Details dazu siehe 5.1.4.2.1).

Implementierungshinweis:

Erfolgt eine DatenAbrufenAnfrage ohne dass vorher mindestens ein Abonnement eingerichtet worden ist, muss der Server einen Fehler melden. Eine 'leere' DatenAbrufenAntwort ist nicht zulässig.

Wurde bereits eine DatenAbrufenAnfrage vom Client an den Server versandt, so ist für diese vom Client eine DatenAbrufenAntwort abzuwarten (Antwort, oder Timeout), bevor erneut eine DatenAbrufenAnfrage versandt wird. Es wird daher empfohlen keine weitere DatenAbrufen- Anfrage zu stellen, solange noch eine DatenAbrufenAnfrage aktiv ist.

5.1.4.2 Daten übertragen (DatenAbrufenAntwort)

Der Server antwortet mit den aktualisierten Datensätzen innerhalb einer Nachricht vom Typ DatenAbrufenAntwort. Der Inhalt ist dienstspezifisch.

Mittels des Elementes WeitereDaten wird angezeigt, ob der Inhalt von DatenAbrufenAntwort alle aktualisierten Daten enthält oder ob aus technischen Gründen die Übermittlung in mehrere Pakete aufgeteilt wurde. Diese Daten können durch den Datenkonsumenten durch weitere DatenAbrufenAnfragen beim Produzenten abgeholt werden. Beim letzten Datenpaket ist das Element WeitereDaten auf "false" gesetzt. WeitereDaten hat den Default-Wert "false". Ein feh- lendes Element WeitereDaten zeigt also an, dass die Datenübertragung vollständig mit diesem Paket abgeschlossen wird.

Die in einem Datenpaket enthaltene Nachricht muss in sich ein valides XML-Dokument dar- stellen, das der XML-Schema-Definition genügt.

VDV 453 Version 3.1.0 - 34 - 23.09.2024

[Seite 37]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Mit der DatenAbrufenAntwort erhält der Server die Berechtigung, die Aktualisierungsflags der Abonnements zurückzusetzen, für die Daten gesendet wurden. Eine erneute DatenAbrufen- Anfrage wird daher die Daten der gerade abgefragten Abonnements nicht mehr gemeldet be- kommen.

Folgendes Beispiel zeigt (dienstunabhängig) eine mögliche Antwort des Servers auf die obige Anfrage:

Implementierungshinweis

Innerhalb einer Datenlieferung (einzelne DatenAbrufenAntwort oder mehrere Datenabrufen- Antworten verbunden mit WeitereDaten=true) darf der gleiche Schlüssel pro Abo nur einmal enthalten sein:

• REF-ANS: FahrtID, HstSeqZaehler

• ANS-Zubringernachricht: FahrtID, HstSeqZaehler

• ANS-Abbringernachricht: ASBID, FahrtID, HstSeqZaehler, FahrtIDExt

• REF-DFI: FahrtID, HstSeqZaehler

• DFI: FahrtID, HstSeqZaehler

• REF-AUS: Nur ein Linienfahrplan pro Schlüssel. Der Schlüssel besteht aus: LinienID, BetreiberID, RichtungsID. Die gleiche FahrtID darf in einer Datenlieferung nur einmal enthalten sein.

• AUS: FahrtID oder (FahrtStartEnde und LinienID und RichtungsID gemeinsam)

VDV 453 Version 3.1.0 - 35 - 23.09.2024

[Seite 38]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

• VIS: FahrtID

5.1.4.2.1 Handhabung DatensatzAlle Bei DatenAbrufenAnfrage mit DatensatzAlle='true' werden folgende Daten gesendet:

• Bei allen Diensten muss es das Ziel sein, dass ein Datenkonsument im Prinzip alle bisher empfangenen Daten löschen und durch die neu empfangenen Daten ersetzen kann. • Es werden alle Daten gesendet, welche die Bedingungen der aktiven Abos erfüllen. • Bei den Referenzdiensten werden alle Daten des in der AboAnfrage abonnierten Zeit- bereiches möglichst nochmals komplett gesendet. Ist der Datenlieferant dazu nicht mehr in der Lage, signalisiert er dies mittels angepassten Zeitfenstern in den Linien- fahrplänen (REF-ANS: 6.2.3.3.2; REF-DFI: 6.3.7.3.2; REF-AUS: 5.1.3). Falls ein Datenlieferant eine DatenAbrufenAnfrage erhält, die Daten aber noch nicht bereit hat, soll eine leere DatenAbrufenAntwort (das verpflichtende Element Bestaeti- gung ist enthalten, das optionale Element Zubringernachicht/AZBNachricht/AUSNach- richt fehlt jedoch) gesendet werden. Der Datenkonsument darf in diesem Fall keine Rückschlüsse auf irgendwelche Linienfahrpläne ziehen, weil die Antwort darüber nichts aussagt. • Beim ANS werden zusätzlich noch ASBFahrplanlagen (s. 6.2.3.1.1 ASBZubringerMel- dungsart) für alle Zubringer gesendet, welche bereits angekommen sind, aber deren VerfallZst noch nicht abgelaufen ist (falls die Partner keine andere Dauer vereinbaren). Darunter können auch Ankunftsmeldungen für Zubringer sein, welche den Anschluss- bereich bereits wieder verlassen haben, deren Umsteiger jedoch noch immer unter- wegs zu einem Abbringer sein könnten, welcher für sie zurückgehalten werden muss. • Folgende Meldungen, die über reine Fahrplanlagen hinausgehen, sollten nochmals ge- sendet werden (möglichst komplett, damit die Daten auf die allenfalls vorhandenen Solldaten abgebildet werden können): o AZBFahrplanlage der AZBMeldungsart «BereichVerlassen» für verfrüht abge- fahrene Fahrten, wo Soll noch nicht erreicht ist, o Meldungen der Meldungsart «Ausfall» bzw. AbbringerFahrtLoeschen (wenn möglich mit Ursache) für ausgefallene Fahrten im Rahmen der Gültigkeit des aktiven Abos.

5.1.5 Datenabonnements löschen (AboLoeschen/Alle)

Abonnements werden nach Ablauf der Gültigkeit durch den Server automatisch gelöscht. Soll ein Abonnement durch den Client vorzeitig gelöscht werden, so ist eine erneute AboAnfrage (s. Kapitel 5.1.2) zu stellen, die Subelemente vom Typ AboLoeschen enthält, von denen jedes ein Abonnement löscht.

Folgendes Beispiel löscht die Abonnements "12" und "5":

VDV 453 Version 3.1.0 - 36 - 23.09.2024

[Seite 39]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Um alle Abonnements eines Dienstes zu löschen, ist anstelle der AboLoeschen-Unterele- mente genau ein Element AboLoeschenAlle mit dem Wert true anzugeben:

5.1.6 Wiederaufsetzen nach Unterbrechung

Erfolgt eine Unterbrechung der Datenverbindung, so kann dies durch Timeout-Meldungen des HTTP-Protokolls erkannt werden. In diesem Moment können folgende Fehlerzustände einge- treten sein:

Tabelle 2 - Fehlerzustände und –maßnahmen bei Verbindungsunterbrechung

VDV 453 Version 3.1.0 - 37 - 23.09.2024

[Seite 40]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

5.1.7 Wiederaufsetzen nach Absturz

Verliert der Client seine Abonnement-Daten – etwa nach Absturz – so müssen die Abonne- ments neu aufgesetzt werden. Dazu sind zunächst alle Abonnements beim Server zu löschen (AboLoeschenAlle). Anschließend sind die Abonnements neu zu vereinbaren.

Verliert der Server seine Abonnement-Daten, so ist dies zunächst vom Client aus nicht fest- stellbar. DatenBereitAnfragen bleiben zwar aus, aber dies kann nicht vom normalen Betrieb unterschieden und somit der Absturz des Servers nicht festgestellt werden. Um diesen Fall zu erkennen, sind zusätzliche, zyklische Anfragen vom Typ StatusAnfrage (5.1.8.1) zum Server zu senden. Innerhalb der StatusAntwort (5.1.8.2) gibt der Server den Zeitstempel des Dienst- starts an. Fand der Dienststart nach der Einrichtung der Abonnements statt, so muss vom Verlust der Abonnements ausgegangen werden. Es ist nun zu verfahren wie beim Client-Da- tenverlust: Löschen und Neueinrichtung aller Abonnements.

5.1.8 Alive-Handling

Die Statusabfrage dient dem Feststellen der Verfügbarkeit von Diensten. Dazu werden zwei spezielle Informationskanäle verwendet (Ziel-URL status.xml, clientstatus.xml), die jeder Dienst bereitstellen muss.

5.1.8.1 Anfrage (StatusAnfrage)

Möchte der Client feststellen, ob ein Dienst noch "am Leben" ist, schickt er eine StatusAnfrage an den Server und wartet auf eine Antwort (StatusAntwort).

5.1.8.2 Antwort (StatusAntwort, Status)

Kehrt die Antwort ein und ist sie positiv, so ist der Dienst verfügbar. Die StatusAntwort be- schreibt die Gesamtverfügbarkeit aller Informationskanäle eines Dienstes. Ist ein Kanal ge- stört, so ist der gesamte Dienst nicht mehr verfügbar.

Implementierungshinweis:

Wird eine StatusAnfrage vom Server nicht oder mit dem Status = "nok" beantwortet, so muss der Client davon ausgehen, dass der gesamte Dienst nicht verfügbar ist. Der Client sendet in diesem Fall weiterhin StatusAnfragen an den Server, um zu prüfen, wann der Dienst wieder verfügbar ist.

Solange der Client keine StatusAntwort mit dem Status = "ok" erhält, sollte dieser keine ande- ren Anfragen (z.B. AboAnfragen, DatenBereitAnfragen, DatenAbrufenAnfragen) an den Ser- ver schicken, um diesen im Fall eines Systemproblems nicht zusätzlich zu belasten und mit Anfragen zu überfluten

VDV 453 Version 3.1.0 - 38 - 23.09.2024

[Seite 41]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Das Element Status enthält neben dem Erstellungszeitstempel nur ein Ergebnis-Element, wel- ches ok liefert, wenn der Dienst verfügbar ist.

Des Weiteren ermöglicht die StatusAnfrage dem Client zu erkennen, ob ein Dienst zwischen- zeitlich neu gestartet wurde und ob die Datenversion sich geändert hat. Innerhalb von Sta- tusAntwort gibt der Server den letzten Start des Dienstes an. Fand der Start nach dem Ein- richten eines Abonnements statt, wurde der Dienst zwischenzeitlich neu gestartet (s. Kapitel 5.1.7).

Sobald der Server in einer StatusAntwort einen aktualisierten Wert von StartDienstZst mitteilt und die DatenVersionID sich geändert hat oder fehlt (weil es z.B. vom System noch nicht un- terstützt wird), muss der Client davon ausgehen, dass der Server-Dienst neu gestartet wurde und die Datenversorgung inkl. der Abonnements verloren gegangen ist.

Wenn der Server eine neue Datenversion signalisieren will, muss er dies dem Client durch eine gleichzeitige Aktualisierung von StartDienstZst und DatenVersionID mitteilen. In diesem Fall muss der Client die alten Daten löschen und damit rechnen, dass sich die Fahrtbezeichner geändert haben.

Sobald der Server in einer StatusAntwort einen aktualisierten Wert des StartDienstZst mitteilt, die DatenVersionID jedoch unverändert bleibt, kann der Client davon ausgehen, dass der Ser- ver-Dienst neu gestartet wurde, die bestehende Datenversorgung aber weiterhin vorliegt.

Handhabung der DatenVersionID bei den Referenzdiensten

Der Client muss die auf diesen Dienst bezogenen Referenzdaten nicht löschen, wenn die Da- tenVersionID unverändert ist, ein erneutes Abrufen der Daten ist in diesem Fall nicht notwen- dig.

Vorgehen, falls der Referenzdienst-Client die Abos nach Empfang der Daten aktiv lässt

Nach einem Neustart des Datenlieferanten muss der Client das Abo des Referenzdienstes wieder neu aufsetzen und die Referenzdaten abholen. Wenn alle folgenden Bedingungen er- füllt sind, kann der Client auf die Verarbeitung der Erstmeldung verzichten:

VDV 453 Version 3.1.0 - 39 - 23.09.2024

[Seite 42]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

• der Client hat das AboAUSRef wieder mit dem gleichen Zeitraum gesendet wie das vorherige AboAUSRef,

• der Server hat in der AboAntwort den gleichen Zeitraum bestätigt wie in der vorherigen AboAntwort,

• DatenVersionID hat sich nicht geändert.

Folgendes Beispiel zeigt eine StatusAnfrage mit einer entsprechenden (erfolgreichen) Sta- tusAntwort:

Anfrage des Client (ITCS A):

Antwort des Servers: Dienst verfügbar, es liegen Daten zur Abholung bereit:

5.1.8.3 ClientStatusAnfrage

Möchte der Server den Status vom Client überprüfen, schickt er eine ClientStatusAnfrage an den Client und wartet auf eine Antwort (ClientStatusAntwort). Dazu muss der Server des Dienstes gestartet sein, sodass in der Anfrage der StartDienstZst einen eindeutigen Wert hat.

Der Server kann in der Anfrage spezifizieren, ob er die Liste der für den Dienst aktiven Abon- nements erhalten möchte. Somit wird dem Server ermöglicht, den Datenabgleich zwischen der Client- und Serversicht vorzunehmen.

Gleichzeitig sendet der Server in der Anfrage seinen StartDienstZst und seine Datenversion mit und gibt dem Client so die Chance, auf Änderungen sofort zu reagieren:

Sobald der Server in einer ClientStatusAnfrage einen aktualisierten Wert von StartDienstZst mitteilt und die DatenVersionID sich geändert hat oder fehlt (weil es z.B. vom System noch nicht unterstützt wird), muss der Client davon ausgehen, dass der Server-Dienst neu gestartet wurde und die Datenversorgung inkl. der Abonnements verloren gegangen ist.

VDV 453 Version 3.1.0 - 40 - 23.09.2024

[Seite 43]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Wenn der Server eine neue Datenversion signalisieren will, muss er dies dem Client durch eine gleichzeitige Aktualisierung von StartDienstZst und DatenVersionID mitteilen.

Sobald der Server in einer ClientStatusAnfrage einen aktualisierten Wert des StartDienstZst mitteilt, die DatenVersionID jedoch unverändert bleibt, kann der Client davon ausgehen, dass der Server-Dienst neu gestartet wurde, die bestehende Datenversorgung aber weiterhin vor- liegt. Der Client muss die auf diesen Dienst bezogenen Daten und Abonnements daher nicht löschen. Eine Erneuerung der Abonnements und neu Abrufen der Daten ist in dem Fall nicht notwendig.

Das Element Status enthält neben dem Erstellungszeitstempel nur ein Ergebnis-Element, wel- ches ok liefert, wenn der Dienst verfügbar ist.

Des Weiteren, wenn in der ClientStatusAnfrage durch MitAbos angefragt wurde, beinhaltet das Element AktiveAbos die Liste aller aktiven Abos des in der Anfrage-URL referenzierten Dienstes. Die Abos anderer Dienste dürfen nicht aufgelistet werden..

Stellt der Server einen Unterschied zwischen seiner Abonnementliste und der Liste vom Client fest, kann der Server entweder stillschweigend den Unterschied beseitigen, indem er die nicht aus der Clientsicht aktiven Abonnements löscht und die aus der Clientsicht aktiven Abonne- ments registriert und anfängt für diese Daten bereitzustellen oder er setzt den StartDienstZst in seiner StatusAntwort auf die aktuelle Zeit und erzwingt somit die Neuinitialisierung des Cli- ents. Der zweite Weg wird empfohlen.

Ist die Struktur AktiveAbos leer, hat der Client keine aktiven Abonnements. Falls der Server doch welche kennt, sollen diese stillschweigend deaktiviert werden.

Sollte sich der Client in einer Initialisierungsphase befinden, d.h. Abonnements löschen oder aufsetzen, dann soll er das Element AktiveAbos komplett auslassen. Der Server soll daraufhin keinen Abgleichsvorgang starten.

VDV 453 Version 3.1.0 - 41 - 23.09.2024

[Seite 44]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Folgende Beispiele zeigen eine StatusAnfrage mit einer entsprechenden (erfolgreichen) Cli- entStatusAntwort:

Anfrage des Servers (ITCS A):

Beispiel 1: Antwort des Clients: Dienst verfügbar, die Liste der aktiven Abonnements ist dabei:

Beispiel 2: Antwort des Clients: Dienst verfügbar, keine Abonnements sind aktiv und es sollen auch keine aktiv sein:

Beispiel 3: Antwort des Clients: Dienst verfügbar, Client initialisiert gerade und will keine Aus- kunft zu den aktiven Abonnements geben:

VDV 453 Version 3.1.0 - 42 - 23.09.2024

[Seite 45]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

5.2 Http-Bindung

5.2.1 Verfahren

Der Nachrichtenaustausch über HTTP oder HTTPS erfolgt über die Methode POST. Damit können Daten in Form von Anfragen von einem Client zu einem Server übertragen werden. In der Antwort auf die Anfrage werden die vom Server bereitgestellten Daten übertragen.

Beispiel HTTP-POST:

POST /leitsystem1/ans/status.xml HTTP/1.1 Host: test1:1111 Content-Type: text/xml Charset="utf-8" Content-Length: 64

Beispiel einer HTTP-Antwort:

HTTP/1.1 200 OK Content-Type: text/xml Charset="utf-8" Content-Length: 87

5.2.2 Zeichensatz

Es wird ausschließlich der Zeichensatz UTF-8 verwendet.

VDV 453 Version 3.1.0 - 43 - 23.09.2024

[Seite 46]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

5.2.3 Dienstekennungen

Die Bereitstellung bestimmter Daten und deren leitsystemübergreifende Verarbeitung werden in diesem Dokument als Dienst bezeichnet.

Zurzeit werden durch die Online-Schnittstelle die folgenden Dienste unterstützt:

Tabelle 3 - HTTP-Dienstkennungen

5.2.4 Anfrage-URL

Alle Anfragen müssen an bestimmte Ziel-URLs gerichtet werden. Die Anfrage-URL ist sowohl vom Dienst als auch vom Typ der Anfrage abhängig.

VDV 453 Version 3.1.0 - 44 - 23.09.2024

[Seite 47]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

Tabelle 4 - HTTP-Anfrage-URL

Die URL, an die obige Anfragen gerichtet werden ist wie folgt definiert:

HTTP_URL = "http:" "//" host [ ":" port ] abs_path

"http:" "//" Bezeichner für das verwendete Protokoll

host Bezeichnet den HTTP-Server an den die Anfrage gerichtet ist.

":"port Gibt das Port an über das die TCP/IP Verbindung laufen soll. Diese Angabe ist nicht nötig, falls das Defaultport (80) verwendet wird.

abs_path Gibt den Pfad der Anfrage an.

Definition abs_path für die Online-Schnittstelle: abs_path = "/" leitstellenkennung "/" dienstkennung "/" anfragekennung

Die Leitstellenkennung muss durch die Schnittstellenpartner festgelegt werden. Die Angabe der Leitstellenkennung des anfragenden Systems innerhalb des Gesamtpfades ermöglicht spezifische Implementierungen der Schnittstelle je nach Partner. Die Dienstkennung wird bei der Realisierung eines Dienstes festgelegt und die Anfragekennung kann der obigen Tabelle entnommen werden.

Die Anfragen für die verschiedenen Dienste unterscheiden sich also im Pfad der URL. Die Anfragen werden immer durch den Dienst interpretiert, an den sie gerichtet wurden. Dienste- übergreifende Anfragen sind nicht möglich.

Beispiel für eine Status-Anfrage (Port 8080) des Systems A an den Anschlusssicherungsdienst des Systems B: http://serverhostsystemb:8080/leitstellenkennungsystema/ans/status.xml

VDV 453 Version 3.1.0 - 45 - 23.09.2024

[Seite 48]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 453

5.2.5 Fehlerbehandlung

Auf der Ebene des HTTP-Protokolls werden die protokolleigenen Status-Codes unterstützt. Die wichtigsten Codes sind in der folgenden Tabelle aufgeführt:

Tabelle 5 - HTTP-Fehlermeldungen

Für die Online-Schnittstelle genügt es, wenn auf der Clientseite der Status-Code 200 (OK) von den übrigen Codes unterschieden wird. Dieser zeigt die erfolgreiche Entgegennahme der An- frage an. Alle anderen durch den HTTP-Server gelieferten Codes müssen als Ablehnung der Anfrage interpretiert werden. Der gelieferte Status-Code liefert weitere Informationen zur Ur- sache der Ablehnung.

Antwortet der Server nicht innerhalb der vorgegebenen Timeout-Zeit, so muss dies ebenfalls als Ablehnung der Anfrage interpretiert werden.

Fehler der fachlichen Schichten werden im Rahmen der Botschaftsbestätigung mittels defi- nierter Felder gemeldet (Fehlernummer, Fehlertext).

5.3 Sicherheit

ITCS-Systeme sind in der Regel in ein Unternehmensnetzwerk eingebunden. Da die Verbin- dung interner Systeme über das Internet ein Sicherheitsrisiko darstellt, wird für die Abwicklung des Datenverkehrs die Einrichtung eines VPN (virtual private network) vorgeschlagen. Dieses verbindet Rechner oder Teilnetze unterschiedlicher Unternehmensnetzwerke so, dass ein vir- tuelles, abgesichertes Netzwerk entsteht, auf welches nur die beteiligten Rechner Zugriff ha- ben. Die Daten innerhalb des virtuellen Netzwerkes werden verschlüsselt übertragen und kön- nen daher über unsichere Verbindungen (Internet) geleitet werden.

Der Einsatz des verschlüsselten https statt http wird empfohlen.

Es wird zusätzlich empfohlen, die zentralen Leitsysteminfrastruktur von der VDV-Kommunika- tion abzusichern. Die Verlagerung der VDV-Kommunikationsdienste in eine DMZ (Kommuni- kationsaufbau nur vom Leitsystem zum VDV-Kommunikationsdienst) schafft eine zusätzliche Sicherheitsbarriere um Übergriffe zu verhindern

VDV 453 Version 3.1.0 - 46 - 23.09.2024

[Seite 49]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6 Schnittstellenbeschreibung "Fachliche Dienste"

Die fachlichen Dienste setzen auf dem generischen Abonnement-Konzept auf. Sie ergänzen die Anfragen und Antworten um die fachlichen Daten, die zur Erbringung der Dienste notwen- dig sind. Die Bearbeitung der Botschaften ist dabei in Bezug auf die Abonnements einheitlich.

Im Folgenden werden die fachlichen Dienste 'Anschlusssicherung (ANS)', 'Dynamische Fahr- gastinformation (DFI)', 'Visualisierung von Fremdfahrzeugen (VIS)' und der 'Allgemeine Nach- richtendienst (AND)' beschrieben.

6.1 Allgemeine Festlegungen

Im Rahmen eines zwischenbetrieblichen Austausches von Daten stellen sich einige grundle- gende Probleme: Wie kann ein gemeinsames Verständnis über ein Objekt (z.B. Haltestelle) gefunden werden? Wie können diese auf eine gemeinsame Bezugsbasis gestellt werden? Wie lange "leben" diese Objekte, bzw. wie muss mit der Datenpflege zeitlich verfahren werden? Das folgende Kapitel beschreibt die grundlegenden Festlegungen, auf deren Basis die Model- lierung erfolgt. Die Festlegungen schlagen sich in Datendefinitionen in den Datenhaltungssys- temen der ITCS nieder. Diese Daten werden im folgenden Metadaten genannt.

6.1.1 Betriebstage

Der gesamte Datenaustausch erfolgt auf Basis der aktuell im ITCS vorliegenden Betriebsda- ten. Da die Vorhaltezeiträume für Planungsdaten in den ITCS unterschiedlich sein können, beschränkt sich die vorliegende Spezifikation auf den Austausch tagesaktueller Daten (Aus- nahme: Übermittlung disponierter Fahrten Tage im Voraus, siehe VDV454-Schrift, Kapitel 5.1.4).

Daraus resultiert das Problem, dass die Betriebszeiträume der ITCS-Systeme unterschiedli- cher Betriebe in der Regel differieren. Manche Systeme weisen eine Betriebspause auf, in der die Systeme reinitialisiert werden und die Datenübernahme aus der Fahrplanung abläuft. An- dere Systeme wiederum kennen keine Betriebspause und fahren einen 24-Stunden-Verkehr. Dabei ist zu beachten, dass es nicht unbedingt einen scharfen Umschaltpunkt der Datenver- sorgung geben muss. Mehrere Fahrplanversionen können dabei innerhalb eines definierten Übergangszeitraumes nebeneinander existieren. Daraus leitet sich ab, dass es keinen zeitlich klar zu definierenden Zeitraum gibt, in dem sichergestellt werden kann, dass beide beteiligten Systeme eine volle Datenverfügbarkeit aufweisen können. Die Regel stellt eine Teilverfügbar- keit dar, bei der ein System die angefragten Daten nicht in vollem Umfang zur Verfügung stel- len kann. Dies trifft natürlich insbesondere auf den Austausch von Referenzdaten zu. Aber auch bei kurzfristig angefragten Prozessdaten kann die Verfügbarkeit nicht sichergestellt wer- den.

Aus diesem Grund sieht die Spezifikation einen Anfragezeitraum vor, welcher den Zeitraum der Anfrage definiert. Die Zeitfenster in den übermittelten Linienfahrplänen beinhalten dann jeweils den Datenhorizont des Datenproduzenten. Somit kann der Konsument prüfen, ob seine Anfrage vollständig beantwortet werden konnte. Andernfalls muss er die Anfrage zu einem späteren Zeitpunkt für den zeitlichen Restbereich wiederholen.

VDV 453 Version 3.1.0 - 47 - 23.09.2024

[Seite 50]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.1.2 Datum- und Zeitformat

Jede Zeitinformation bezieht sich auf die sogenannte UTC (Coordinated Universal Time). Ab- weichungen von dieser Zeitzone werden gemäß ISO 8601 kodiert:

Beispiel: 2000-04-07T18:39:00+01:00.

Ohne Angabe der zeitlichen Abweichung ist die Zeitangabe bereits in UTC. In diesem Fall kann auch ein abschließendes Z folgen

Beispiel: 2002-04-30T12:00:00 entspricht 2002-04-30T12:00:00Z.

Anders ausgedrückt, die ersten 19 Zeichen sind obligatorisch und entsprechen der lokalen Zeit oder bereits der UTC.

Es werden keine weiteren Zeiteinheiten jenseits der Sekunde, also 1/10-, 1/100-Sekunden verwendet. Ist dies der Fall, so werden sie beim Import ignoriert.

Mit dieser Zeitdarstellung können Probleme bei der Sommerzeitumstellung vermieden werden.

6.1.3 Leitstellenkennung

Um Botschaften verschiedener Kommunikationspartner innerhalb eines Dienstes unterschei- den zu können, enthält jede Nachricht eine eindeutige Leitstellenkennung (Attribut Sender) des nachfragenden Systems. Alle weiteren bilateral abgestimmten Meta-Daten sind auf die Leitstellenkennung zu beziehen.

6.1.4 Ortsbezüge

Neben den tagesaktuellen Planungsdaten müssen zwischen zwei Systemen mit zwischenbe- trieblicher Anschlusssicherung weitere Plandaten vorliegen, die es erlauben, über die jeweili- gen Ortsbezüge ein gemeinsames Verständnis herzustellen. Dazu könnten die jeweiligen in- ternen Ortsbezüge (Haltestellenreferenz, Anzeigerreferenz, etc.) gegenseitig gepflegt werden.

Diese Art der Definition hat jedoch einen grundlegenden Nachteil: Durch die direkte Verknüp- fung der eigenen Ortsschlüssel mit denen des Fremdbetriebes, sind die Datenhaltungen ge- koppelt. Änderungen im Grunddatenbestand können schnell zu Inkonsistenzen führen.

Daher wird ein betriebsunabhängiger Ortsbezeichner eingeführt, der die Datenhaltungssys- teme entkoppelt. Die Grundidee: Durch die Vereinbarung von "gemeinsamen" Bezeich- nern/Schlüsseln wird die direkte Verknüpfung obsolet. Es erfolgt jeweils nur eine Teilverknüp- fung der eigenen Daten mit den "Meta-Daten". Dabei kann die Abbildung sowohl auf Orts- punkte (z.B. Haltestelle, Mast) oder auch Ortsbereiche (Haltstellenbereich) erfolgen. Welche Abbildung geeignet ist, hängt vom Datenmodell des ITCS, als auch von den örtlichen Situati- onen ab (Umsteigezeiten).

Im Bereich des Nachrichtendienstes gibt es keine Ortsbezüge, aber auch hier erfolgt die An- forderung von Daten aus Basis bilateral abgestimmter IDs, die die Systeme entkoppeln. Die Bezeichner werden Kanäle genannt und unterteilen die Menge der möglichen Meldungen in Klassen. Der Kanal stellt somit das Äquivalent der Ortsbezüge im Nachrichtendienst dar.

Folgende Bezüge sind in den jeweiligen Diensten zu definieren:

VDV 453 Version 3.1.0 - 48 - 23.09.2024

[Seite 51]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Tabelle 6 - Ortsbezüge in den fachlichen Diensten

Die Vereinbarung gemeinsamer Bezeichner kann in Fahrplankonferenzen oder ähnlichen Gre- mien erfolgen. Die Vereinbarung sollte mittel- oder langfristig sein, um die Notwendigkeit von Datenänderungen zu minimieren.

Die Abstimmungen können ausschließlich bilateral erfolgen. Innerhalb des Datenaustausches ist immer der Bezug zum Kommunikationspartner bestimmbar. Daher müssen alle Bezeichner nur eindeutig bezogen auf einen jeweiligen Kommunikationspartner sein. Eine regionale Ab- stimmung von Bezeichnern zwischen mehreren Betrieben mag daher hilfreich sein, ist aber nicht notwendig.

Sämtliche Bezugsdaten innerhalb dieser Spezifikation müssen über dieses Konzept mit den betriebseigenen Daten verknüpft werden. Eine gemeinsame Datenversorgung über diese Meta-Daten hinaus ist nicht notwendig.

Hinweis: Um Änderungen im Vorfeld pflegen zu können, erfordert die Datenhaltung zusätzlich eine auf jeden Kommunikationspartner ausgelegte Versionierung der Metadaten.

6.1.4.1 HaltID

Für die Referenzierung von Haltestellen oder ihrer Teile wird die HaltID verwendet. Auch bei der HaltID handelt es sich um ein Metadatum, das grundsätzlich vereinbart werden muss.

Struktur der HaltID (HaltIDType)

VDV 453 Version 3.1.0 - 49 - 23.09.2024

[Seite 52]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Wenn diese Struktur übermittelt wird, muss immer mindestens eine der oben aufgeführten IDs (HaltestellenID, BereichsID oder SteigID) mitgegeben werden. Weitere Elemente dürfen mit- gegeben werden.

Die HaltID wird als Ganzes als Schlüssel benutzt. Wenn also bei der ersten Verwendung einer HaltID für eine Fahrt an einer Haltestelle eine HaltID mit z.B. zwei der drei genannten IDs verwendet wird, dann muss sie immer mit diesen beiden IDs verwendet werden, solange sich die HaltID nicht explizit ändert.

Beispiel: In einer HaltID für Bahnhöfe werden die HaltestellenID mit einer ID für den Bahnhof und die SteigID mit einer ID fürs Gleis gefüllt. Damit wird es Abnehmern ermöglicht, zwei un- terschiedliche Haltestellenmodelle umzusetzen. Es ist sowohl möglich, die Daten gleisscharf zu verarbeiten, als auch, sie nur bahnhofscharf zu verwenden. Der Lieferant muss in diesem Fall auch für eine nicht von dispositiven Maßnahmen betroffene Fahrt immer in der HaltID die HaltestellenID und die SteigID füllen, um auszudrücken, dass die Daten unverändert sind. Es darf z.B. nicht die SteigID weggelassen werden, weil sie unverändert ist. Im Gegenteil würde das Weglassen der SteigID bedeuten, dass der Steig ab sofort unbekannt ist und die Fahrt über eine veränderte HaltID verkehrt.

Wenn an eine Datendrehscheibe Lieferanten angeschlossen sind, die Daten in Version 2.x liefern, und sie selbst Daten in Version 3.x ausliefern soll, dann muss der einzelne Wert aus der HaltID des Lieferanten auf (mindestens) eine der drei IDs übertragen werden. Wenn dies durch Vereinbarungen oder anderes Wissen eindeutig möglich ist, dann soll die zugelieferte HaltID in eine neue HaltID nach Version 3.x kopiert oder unter Zuhilfenahme von Umschlüs- selungstabellen umgeschrieben werden.

Es ist aber auch denkbar, dass die eindeutige Zuordnung z.B. aus organisatorischen Gründen nicht möglich ist. In diesem Fall wird das Element AbgeleitetAusClassicHaltID verwendet. Die zugelieferte HaltID wird dann (umgeschlüsselt oder nicht) in alle plausiblen IDs der auszulie- fernden HaltID übernommen und zusätzlich das Element AbgeleitetAusClassicHaltID auf true gesetzt.

Ist das Element AbgeleitetAusClassicHaltID nicht angegegeben oder false, so müssen alle gefüllten Sub-IDs innerhalb der HaltID unterschiedlich sein. Dies bedeutet dann auch, dass sich die Namensräume der Bezeichner für HaltestellenIDs, BereichsIDs und SteigIDs nicht überlappen sollten.

Umgekehrt kann an eine Datendrehscheibe ein Lieferant angeschlossen sein, der Daten ge- mäß Version 3.x der Schnittstelle liefert, bei dem aber bekannt ist, welche der IDs innerhalb der HaltID in einer HaltID nach Version 2.x abgefüllt würde. In diesem Fall sollte der Lieferant im Element ElementFuerUmwandlungInClassicHaltID vermerken, welche ID der HaltID nach

VDV 453 Version 3.1.0 - 50 - 23.09.2024

[Seite 53]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Version 2.x entsprechen würde. Eine abnehmende Datendrehscheibe kann in diesem Fall für Abnehmer der Schnittstellenversion 2.x den Wert entsprechend übernehmen.

Um die Vereinbarung der Metadaten für HaltIDs landesweit einheitlich zu halten, ist es emp- fehlenswert, sich an die Vorgaben der landesweit eindeutigen Bezeichnungen zu halten. Für die HaltID in Deutschland ist das die DHID (siehe VDV-Schrift 432). In diesem Fall sollte die HaltestellenID gefüllt werden mit der Haltestelle, die BereichsID mit dem Bereich und die Stei- gID mit dem Mast der DHID.

6.1.5 Fahrtbezug (FahrtID)

Vergleichbar mit dem Problem der Ortsbezüge muss die Referenzierung von Fremdfahrten betrachten werden. Die betrieblich verwendeten Begriffe wie Linie/Umlauf/Kurs besitzen keine einheitliche Semantik. Die geforderte Eindeutigkeit ist ebenfalls nicht sichergestellt.

Innerhalb eines ITCS gibt es daher einen internen Bezeichner, der die Fahrt eindeutig referen- ziert (innerhalb des eigenen Datenhorizontes). Da aber der Datenhorizont des Fremdbetriebes nicht bekannt ist, kann nicht ausgeschlossen werden, dass zwei Fahrten eines Fremdbetriebes innerhalb des eigenen Betriebstages die gleiche interne Fahrtbezeichnung besitzen (im Fremd-ITCS sind es unterschiedliche Betriebstage).

Für die Verwendung der ITCS-internen Fahrtbezeichner als übergreifendes Meta-Datum ist daher die Ergänzung um das Betriebstagsdatum in der Schnittstelle nötig:

Wie der Betriebstag intern betrieblich definiert wird, ist unerheblich. Entscheidend ist die Ein- deutigkeit des zusammengesetzten Elementes FahrtID.

Um die Vereinbarung der Metadaten für FahrtIDs landesweit einheitlich zu halten, ist es emp- fehlenswert, sich an die Vorgaben der landesweit eindeutigen Bezeichnungen zu halten. Für die FahrtID in Deutschland ist das die deutsche Fahrt ID DFID (siehe VDV-Schrift 433).

6.1.6 Linien- und Richtungsbezüge

Um die Datenhaltung auch bezüglich der Linien- und Richtungsbezeichnungen zu entkoppeln, werden in der Schnittstelle betriebsunabhängige Linien- und RichtungsIDs verwendet. Wenn es landesweite Empfehlungen gibt, ist es empfehlenswert sich an die Vorgaben der landesweit eindeutigen Bezeichnungen zu halten.".

Die Werte für die RichtungsID sollten möglichst kurz gewählt werden und möglichst nur zwei Richtungen unterscheiden, da die RichtungIDs zur Filterung verwendet werden, z. B. 1/2, ost/west.

VDV 453 Version 3.1.0 - 51 - 23.09.2024

[Seite 54]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Innerhalb der Datenpflege muss ein Bezug einer Linien- oder RichtungsID zu einer eigenen Linie bzw. Richtung hergestellt werden. Identifikatoren fremder Unternehmen finden Eingang in die Anschlussdefinition.

Um die Vereinbarung der Metadaten für LinienIDs landesweit einheitlich zu halten, ist es emp- fehlenswert, sich an die Vorgaben der landesweit eindeutigen Bezeichnungen zu halten. Für die LinienID in Deutschland ist das die deutsche Teillinien-ID DTID (siehe VDV-Schrift 433).

6.1.7 Produkttypen

Produkttypen dienen innerhalb der Schnittstelle der Klassifizierung von Qualitätsmerkmalen für Fahrten. So sind Produkte wie "ICE", "Regionalbahn", "Expressbus" oder ähnliche betrieb- liche Klassifizierungen denkbar. Eine betrieblich einheitliche Vorgabe zur Produktklassifizie- rung existiert bisher nicht.

Um dennoch dem Fahrgast auch bei zwischenbetrieblicher Anschlusssicherung und bei der dynamischen Fahrgastinformation einheitliche Produktbezeichner (Texte, Icons) präsentieren zu können, muss auch hier eine Meta-Datenpflege stattfinden. Dabei ist eine Abbildung der zwischenbetrieblich zu vereinbarenden ProduktIDs und eigenen Qualitätsklassen herzustel- len. Die Vereinbarung erfolgt – analog zu allen anderen Meta-Daten – bilateral.

In Kapitel 6.1.7.1 findet sich zur Orientierung eine Liste von vordefinierten Produkttypen. Ist die ProduktID nicht bekannt, so wird der Wert Unbekannt übermittelt.

6.1.7.1 Werteliste ProduktID

Die folgende Tabelle zeigt zur Orientierung die vordefinierten ProduktIDs.

Tabelle 7 - Vordefinierte ProduktIDs

VDV 453 Version 3.1.0 - 52 - 23.09.2024

[Seite 55]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.1.8 Stichfahrten

Die Bekanntgabe von Plan- und Prozessdaten erfordert eine eindeutige Referenzierung einer Anfahrt eines Zubringers an eine Haltestelle. Das Tupel aus FahrtID und ASBID ist allerdings nicht in allen Fällen eindeutig. Fährt eine Fahrt eine Haltestelle mehrfach an, so kann eine Unterscheidung zwischen der ersten und zweiten Anfahrt nicht getroffen werden. Zu diesem Zwecke dient zusätzlich der sogenannte Haltestellensequenzzähler (HstSeqZaehler) als Ent- scheidungskriterium.

Für den Haltestellensequenzzähler müssen positive Ganzzahlen verwendet werden, welche das mehrfache Anfahren einer Haltestelle (ASBID, AZBID) bei einer Fahrt in eine aufsteigende Reihenfolge bringen. Die Verwendung von Null ('0') ist - abweichend von der Typ-Spezifikation im XSD-Schema als nonNegativeInteger - nicht zugelassen.

Der HstSeqZaehler muss nicht fortlaufend, aber streng monoton steigend sein.

Datenproduzierende Systeme, die anstelle eines Zählers andere Verfahren zur Stichfahrten- unterscheidung benutzen (geplante Ankunftszeit, Routenpunktzähler), können diese Daten – als Ganzzahl kodiert – direkt verwenden, sofern die Monotonie beachtet wird.

6.1.9 ServiceAttribute

Um betriebliche Serviceattribute wie Schülerfahrt, behindertengerechte Fahrt usw. abzubilden, müssen in beiden Systemen Abbildungen auf gemeinsame, betriebsübergreifende Meta-Da- ten stattfinden. Dies geschieht im Rahmen der betrieblichen Datenpflege:

Tabelle 8 - Definition zwischenbetrieblicher Serviceattribute

6.1.10 Fehler in der fachlichen Schicht

Neben den allgemeinen Fehlern, die aufgrund der fehlenden Verfügbarkeit von Client/Ser- ver/Netzwerk und somit auf der Ebene von HTTP auftreten, gibt es Fehler innerhalb der fach- lichen Botschaften. Wenn z.B. ein Bezug auf ein Meta-Datum (z.B. ASBID) nicht verfügbar ist, so kann der geforderte Dienst nicht erbracht werden und es muss eine Fehlermeldung an den Client erfolgen. Dies geschieht innerhalb des Elementes Bestaetigung, welches Unterelement jeder Antwort-Botschaft ist. Darin ist das Element Fehlernummer enthalten, welches eine Feh- lerkategorie angibt:

VDV 453 Version 3.1.0 - 53 - 23.09.2024

[Seite 56]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Tabelle 9 - Fachliche Fehlertypen

Wenn die Kommunikation über eine DDS in der durchleitenden Betriebsform stattfindet, ist es für die Fehlersuche sehr hilfreich erkennen zu können, ob ein Fehler vom Umsystem ausgelöst wurde oder von der DDS selbst. Diese Fallunterscheidung hilft dem Betreiber des anfragenden Systems zu entscheiden, ob für die Analyse des Fehlverhaltens zunächst der Betreiber der DDS oder der Betreiber des angefragten Systems kontaktiert werden sollte.

Fehler, die vom Umsystem (dem angefragten System) ausgelöst werden, sollen wie bisher mit einem Fehlercode aus dem Nummernbereich 100-499 von der DDS transparent weitergeleitet werden.

Nur in den Fällen, in denen die DDS den Fehler auslöst, sollte der folgende Nummernbereich (500-599) gewählt werden. Mögliche Fehlerzustände sind:

500-529 Fehler in der Anfrage, also wie 100-499 aber diesmal gleich von der DDS "erkannt" • XML-Fehler • Referenzdatenverletzung • Übrige Fehler in der Anfrage (Die Zustände treten nur dann auf, falls die DDS eine Validierung der Nachrichten macht, bevor sie weitergeleitet werden.)

VDV 453 Version 3.1.0 - 54 - 23.09.2024

[Seite 57]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Zur genaueren Spezifikation des Fehlers steht zusätzlich ein Element namens Fehlertext zur Verfügung, welcher die textuelle Beschreibung erlaubt. Die textuelle Beschreibung muss min- destens das fehlerhafte Element (Tag) inklusive seines Werts enthalten. Generell sollte die Meldung sehr ausführlich ausfallen, da sie die einzige Möglichkeit zur Fehlersuche darstellt.

Tritt ein Fehler innerhalb einer AboAnfrage auf, so ist die gesamte Anfrage ungültig und zu verwerfen. Es dürfen weder Abonnements eingerichtet noch gelöscht werden, wenn die syn- taktische und semantische Prüfung fehlschlägt. Die Prüfung der Meta-Daten sollte daher vorab erfolgen, bzw. ein transaktionelles System eingesetzt werden.

6.1.11 Optionale Felder

Innerhalb der Nachrichten sind viele Informationen optional. Dies bedeutet, dass der Empfän- ger nicht mit der Verfügbarkeit dieser Daten rechnen darf, wenn das datenproduzierende Sys- tem die Informationen aus technischen oder betrieblichen Gründen nicht bereitstellen kann. Aus diesem Grund können Default-Belegungen für optionale Felder nicht verwendet werden.

Ausnahmen von diesem Verhalten sind explizit beschrieben (siehe Traktion, WeitereDaten).

6.1.12 Texte für die Publikation

Innerhalb der Nachrichten sind bestimmte Informationstexte explizit zum Zwecke der Publika- tion gegenüber dem Reisenden angedacht. Die betreffenden Elemente sind im Elementnamen mit dem Postfix "Text" gegenzeichnet (z.B. "LinienText").

Die in diesen Elementen enthaltenen Informationen wurden durch den Datenproduzenten ex- plizit zur Beauskunftung des Reisenden erstellt und sind im Fall einer Kommunikation unver- ändert zu verwenden.

6.1.13 Latenz- und Verarbeitungsanalysen mit Hilfe des Elements Proto- kolleintrag

6.1.13.1 Definition

Durch die zunehmende Verbreitung von Datendrehscheiben gibt es immer häufiger Daten- flüsse, in denen das Daten-erzeugende System nicht direkt mit dem Endabnehmer der Daten kommuniziert. Vielmehr werden die Daten über eine oder mehrere Datendrehscheiben geleitet und dabei teilweise mit anderen Datenströmen gebündelt und harmonisiert, letzteres zum Bei- spiel durch Umschlüsselungen von Metadaten, siehe Abbildung 6.

VDV 453 Version 3.1.0 - 55 - 23.09.2024

[Seite 58]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Abbildung 6 Beispiel für einen Datenfluss, bei dem die Daten mehrerer ITCS (früher als RBL be- zeichnet) über zwei Datendrehscheiben laufen, bevor sie in eine Fahrplanauskunft gelangen

Das optionale Element Protokolleintrag ermöglicht den beteiligten Systemen, relevante Ereig- nisse in der Verarbeitungskette zu protokollieren. Dies soll die Analyse vor allem unter den folgenden beiden Gesichtspunkten ermöglichen:

• Woher kommt eine Information und welchen Weg hat sie von der ursprünglichen Quelle bis hierher genommen?

• Wie lange hat es gebraucht vom Erzeugen der Information, bis sie den Abnehmer erreicht hat, und wie verteilen sich die Latenzen auf die Zwischensysteme?

Da die Aggregation der Echtzeitinformation zu xml-Nachrichten ("DatenAbrufenAntworten") auf Zwischensystemen nicht beibehalten werden muss und in Datendrehscheiben Informati- onen aus verschiedenen Abonnements auch gebündelt weitergegeben werden können, sind die Protokolleinträge nicht auf Ebene der xml-Nachrichten, sondern auf Ebene der Datenob- jekte (z.B. ASBFahrplanlage, 6.2.4.3.1, oder IstFahrt, VDV 454) angesiedelt. Dies wird bei der Beschreibung der jeweiligen Dienste in den späteren Abschnitten bzw. der VDV-Schrift 454 näher erläutert.

Während der Informationsverarbeitung gibt es verschiedene Aktionen, die zur Erfassung ei- nes Protokolleintrags führen können. Für das Attribut Aktion sind folgende Werte vorgesehen:

VDV 453 Version 3.1.0 - 56 - 23.09.2024

[Seite 59]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Tabelle 10 – mögliche Werte des Attributs Aktion

6.1.13.2 Implementierungshinweise

Das Element Protokolleinträge ist für Analysezwecke gedacht. Deshalb wird es vor allem bei der Etablierung neuer Datenflüsse oder der Untersuchung von Fehlern in bestehenden Da- tenflüssen benötigt. Das Element ist optional, eine ständige Protokollierung würde zu viele nicht benötigte Daten erzeugen.

Ebenso wird auf einen automatischen Mechanismus zum Ein- und Ausschalten der Protokol- lierung verzichtet, da dies gerade bei längeren Lieferketten sowieso einen Abstimmungs- und Konfigurationsaufwand bei allen Beteiligten zur Folge hätte. Vielmehr ist der Gedanke, dass sich die relevanten Beteiligten projektbezogen auf einen Zeitraum einigen, in dem die Proto- kollierung angeschaltet wird. Hinweis: Um aus den Zeitstempeln der Protokolleinträge ver- schiedener Systeme verlässliche Erkenntnisse zu gewinnen, ist es sinnvoll, dass die beteilig- ten Systeme regelmäßig ihre Uhren mit einem Zeitserver abgleichen.

Von Systemen, die AUS-Daten beziehen, wird erwartet, dass sie Nachrichten, die Proto- kolleinträge enthalten, zumindest entgegennehmen können, auch wenn letztere nicht ausge- wertet werden. Datendrehscheiben sollten darüber hinaus in der Lage sein, die empfangenen Protokolleinträge auch an die Datenabnehmer weiterzugeben.

Erzeugt ein System Protokolleinträge, so werden diese sequentiell pro Aktion aneinander an- gehängt, d.h. neuere Einträge finden sich unter den älteren Einträgen.

Folgende Hinweise gelten für die an einem Datenfluss beteiligten Systeme je nach Rolle, die sie einnehmen: • Liefernde Systeme (also die Daten erzeugenden System wie z.B. ITCS-Systeme) fügen zu jedem erstmals oder aufgrund der Hysteresevorschriften erneut zu übermittelnden Datenobjekt folgende Protokolleinträge hinzu: o einen Protokolleintrag mit dem Zeitstempel der Auslösung, ihrer Systemkennung und der Aktion "AUSLOESUNG" sowie ggf. dem Grund der Auslösung (z.B. "Überschreitung Hysterese") im Attribut "Details"

VDV 453 Version 3.1.0 - 57 - 23.09.2024

[Seite 60]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

o einen Protokolleintrag mit dem Zeitstempel, an dem die Daten abgeholt werden, ihrer Systemkennung und der Aktion "AUSGANG". • Durchleitende Systeme (z.B. Datendrehscheiben im durchleitenden Modus): Sofern das durchleitende System die Inhalte der Nachrichten ohnehin modifiziert (z.B. Wand- lung von Metadaten oder Schnittstellenversionen) sollte es eigene Protokolleinträge für Eingang und Ausgang der Nachricht hinzufügen. Bleiben die Inhalte der Nachrichten bis- lang unangetastet, so soll durch die Einführung der Protokolleinträge nun keine Ver- pflichtung entstehen, dieses grundsätzliche Verhalten zu verändern. In solchen Fällen sollen nur die bestehenden Protokolleinträge weitergeleitet werden. • Weiterverarbeitende Systeme (z.B. Datendrehscheiben im weiterverarbeitenden Mo- dus): o Weiterverarbeitenden Systeme hängen mindestens je einen Protokolleintrag für das Eintreffen ("EINGANG") und das Ausliefern ("AUSGANG") jedes Basisob- jekts an. Möglicherweise werden dazwischen noch weitere Protokolleinträge ge- schrieben, zum Beispiel für das Lesen des Basisobjekts aus der Datenbank. o Es kann vorkommen, dass ein weiterverarbeitendes System die in einer Nach- richt enthaltenen Meldungen nicht sofort weitergeben kann, so dass die Inhalte mehrerer eingegangenen Nachrichten am Ausgang aggregiert weitergegeben werden müssen. Bei der Aggregation werden die von der Quelle gelieferten Pro- tokolleinträge jeweils "en bloc" sequentiell ergänzt (und nicht nach Zeitstempeln sortiert). In Fall der Aggregation finden sich dann unter den Protokolleinträgen eines Basisobjekts mehrere EINGANG-Protokolleinträge vor dem AUSGANG- Protokolleintrag, siehe dazu auch das Beispiel weiter unten. o Bei der Übermittlung eines Datenobjektes an einen Abnehmer sollen nur diejeni- gen Protokolleinträge übertragen werden, die seit dem letzten Übermitteln neu hinzugekommen/entstanden sind. Achtung: im Fall von langen Lieferketten kön- nen einige dieser Einträge durchaus Zeitstempel tragen, die vor der letzten Über- mittlung an den Abnehmer liegen – einfach deshalb, weil zum Beispiel ein ITCS schon eine Information auf den Weg gebracht haben kann, die zum Zeitpunkt der Übermittlung an den Abnehmer noch nicht in der Datendrehscheibe angekom- men ist. • Abnehmende Systeme am Ende der Lieferkette (z.B. Auskunftssysteme) müssen keine Protokolleinträge hinzufügen. Grund: Abnehmende Systeme modifizieren VDV- Nachrichten nicht, vielmehr werden hier die Inhalte ausgelesen und anderweitig weiter- verarbeitet. Üblicherweise können die Nachrichten dort aber zu Debugging-Zwecken z.B. auf der Festplatte abgelegt werden ("Logging"). Anhand der dort vermerkten Zeitstempel lässt sich der Eingang der Nachrichten dann nachvollziehen, so dass ein eigener Eintrag im Feld Protokolleinträge nicht als notwendig erachtet wird.

Das folgende Beispiel illustriert, wie eine aus einer DDS an einen Abnehmer gesendete AZB- Fahrplanlage aussehen könnte, zu der von einem ITCS (früher mit RBL bezeichnet) eine Ak- tualisierung hereinkam, bevor noch die Meldung an den Abnehmer erfolgen konnte:

VDV 453 Version 3.1.0 - 58 - 23.09.2024

[Seite 61]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

<AZBFahrplanlage Zst="2017-10-20T12:17:38Z VerfallZst="2017-10-20T12:18:48Z "> ... ...

6.1.13.3 Interpretationshinweise

Bei der Übertragung von Informationen über mehrere Systeme hinweg können verschiedene Situationen auftreten (zum Beispiel Neuaufsetzen von Abonnements, Kommunikationsabbrü- che, ein Datenabruf mit DatensatzAlle=true), die durch die hier definierten Protokolleinträge nicht alle eindeutig nachvollziehbar gemacht werden können. Unterschiedliche Implementie- rungen können außerdem zu unterschiedlichen Protokollierungen führen. Insofern sind die Protokolleinträge in einer Information lediglich als Hinweisgeber anzusehen, für Detailanaly- sen wird es nötig sein, sich mit den Betreibern der am Datenfluss beteiligten Systeme ausei- nanderzusetzen.

Insbesondere gilt Folgendes: • Bei der Festlegung, zu welchem Zeitpunkt genau ein Protokolleintrag zu erfolgen hat, wurde bewusst Interpretationsspielraum gelassen, um den unterschiedlichen Imple- mentierungen auf dem Markt gerecht zu werden. Bedeutet zum Beispiel der Zeitstem- pel eines Protokolleintrags "AUSGANG", dass das auszuliefernde Datenpaket zu die- sem Zeitpunkt vorbereitet wurde oder dass die DatenAbrufenAnfrage zu diesem Zeit- punkt beantwortet wurde? Diese Unschärfen werden in Kauf genommen und sind im Zweifel mit dem Betreiber des protokollierenden Systems zu klären. • Insbesondere im AUS-Dienst (siehe VDV 454) kann es Elemente geben, die nur bei Änderungen oder initialen Lieferungen gesendet werden müssen. Weiterverarbei- tende Datendrehscheiben können diese Informationen aggregieren und dann, zum Beispiel bei einem Datenabruf mit DatensatzAlle=true, erneut versenden. Ein Proto- kolleintrag des Typs EINGANG bedeutet also nicht zwangsläufig, dass alle Informati- onen im betreffenden Objekt zu diesem Zeitpunkt in das protokollierende System ge- flossen sind. Er deutet vielmehr auf die zuletzt erfolgte Aktualisierung hin. • Bei Lieferketten über mehrere Systeme hinweg kann es vorkommen, dass Aktualisie- rungen die ursprüngliche Information "einholen", bevor diese vom Abnehmer

VDV 453 Version 3.1.0 - 59 - 23.09.2024

[Seite 62]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

abgerufen wird. Dies kann zu einer langen Serie von Protokolleinträgen an einem Da- tenobjekt führen, die nicht einmal chronologisch geordnet sein müssen. Dies wird im folgenden Beispiel illustriert, in dem das System RBL bereits eine neue Datenliefe- rung an DDS1 ausgelöst hat, bevor die erste von DDS1 an DDS2 übermittelt wurde. In DDS 2 wurden beide Meldungen aggregiert, bevor sie an den Abnehmer gesendet wurden:

6.1.14 PrognoseUngenau-Elemente

Stellt das Rechnergestützte Betriebsleitsystem (ITCS) fest, dass es für eine Fahrt keine valide Prognose mehr abgeben kann, so kann es für die betreffende Fahrt das Feld PrognoseUnge- nau aktivieren. Ist die Prognose nur auf Abschnitten der Fahrt ungenau, weil man zum Beispiel weiß, dass im späteren Fahrtverlauf die Weiterfahrt vorerst nicht möglich sein wird wegen einer blockierten Strecke, so kann dies übermittelt werden, indem für die jeweiligen Ankünfte und Abfahrten die Felder IstAnkunftPrognoseUngenau/IstAbfahrtPrognoseUngenau aktiviert wer- den. Infolgedessen hat der Datenempfänger von einer unbestimmten Verspätung auszuge- hen, da bis auf Weiteres keine neue valide Prognose mehr bereitgestellt werden kann und mit weiteren Verspätungen zu rechnen ist.

Als Grund für die PrognoseUngenau können folgende Werte angegeben werden:

a) "Fahrzeug im Stau" bedeutet, dass das Fahrzeug äußerst langsam oder nicht mehr vorankommt.

VDV 453 Version 3.1.0 - 60 - 23.09.2024

[Seite 63]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

b) "technisches Problem" besagt, dass z.B. bei der Übermittlung der Fahrzeugdaten ein Problem besteht und daher keine aktuellen Informationen vorliegen

c) "dispositive Maßnahme" besagt, dass dispositiv eingegriffen wird, um z.B. einen An- schluss zu sichern und daher keine sichere Prognose erfol- gen kann

d) "fehlende Aktualisierung" besagt, dass zwar eine Prognose vorliegt, diese aber wegen einer Kommunikationsstörung nicht aktualisiert werden konnte.

e) "unbekannt" bedeutet, dass der Grund für eine unbestimmte Verspätung (ungenaue Prognose) nicht bekannt ist.

Implementierungshinweis:

Im Fall einer ungenauen Prognose sollte das ITCS die ihm zuletzt vorliegende Prognosezeit zusammen mit dem Element PrognoseUngenau und dem jeweiligen Wert für die Ursache (z.B. "fehlende Aktualisierung") senden.

Abbildung 7: Exemplarisches Meldeverhalten bei PrognoseUngenau (gilt für alle Dienste)

Der letzte Prognosezeitwert verbunden mit PrognoseUngenau kann im Auskunftssystem dazu verwendet werden, um dem Reisenden eine unbestimmte Verspätung zu kommunizieren z.B. "unbestimmte Verspätung", oder "Verspätung X Min - Mit weiteren Verspätungen ist zu rech- nen".

Im Gegensatz zu einem Kommunikationsausfall geht das Auskunftssystem bei PrognoseUn- genau nicht auf die Rückfallebene der Solldaten zurück, sondern es wird der zuletzt gelieferte Prognosezeitwert verwendet. (Es wird dabei davon ausgegangen, dass die letzte bekannte Prognose "im Zweifel" genauer ist, als z.B. die Zeiten auf den Soll-Wert zurückzusetzen, ins- besondere dann, wenn bereits eine Verspätung der Fahrt vorliegt.)

Mit dem Senden einer neuen aktuellen Prognose ohne das Element PrognoseUngenau hebt das ITCS den PrognoseUngenau-Zustand auf.

VDV 453 Version 3.1.0 - 61 - 23.09.2024

[Seite 64]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Erklärung "Unbestimmte Verspätung":

Bei einer "Unbestimmten Verspätung" handelt es sich grundsätzlich um eine Prognose, deren Verlässlichkeit auf Grund eines eingetroffenen Ereignisses (z.B. Störung) sehr gering resp. eine konkrete Prognosezeit nicht genau bestimmt werden kann. Es kann in Folge zu größeren Schwankungen in Bezug auf die, dem Reisenden zuletzt kommunizierten, Ankunfts-/Abfahrts- zeit kommen. Die zuletzt übermittelte Prognosezeit kann in diesem Fall "unbestimmt" abwei- chen.

Zusatz für VDV 454 bezüglich der Abgrenzung PrognoseStatus="unbekannt":

Der PrognoseStatus="unbekannt" ist nicht für die Übermittelung einer unbestimmten Ver- spätung geeignet und darf hierfür nicht verwendet werden. Dies, da bei PrognoseStatus="un- bekannt" zum einen grundsätzlich auf Soll-Zeiten zurückgesprungen wird und dabei die zuletzt bekannten Prognosen verloren gehen. Zum anderen werden dabei alle vorangehende Halte auf Sollzeiten zurückgesetzt. Bei einer unbestimmten Verspätung ab einem konkreten Halt liegen jedoch in der Regel Prognose, Geschaetzt und Real Zeiten vorgängiger Halte vor.

6.1.15 Prognosequalität (IstAnkunftPrognoseQualitaet und IstAbfahrt- prognoseQualitaet): (ZeitQualitaet)

6.1.16 Verwendung von PrognoseUngenau und PrognoseQualitaet

Wenn möglich sollte zur Übermittelung die neue Struktur PrognoseQualität verwendet werden.

Finden beide Elemente PrognoseUngenau und PrognoseQualität gleichzeitig Anwendung, so sind die Informationen zur Prognosequalität als höherwertig zu betrachten, da diese eine fei- nere Differenzierung in Bezug auf die erwartete Qualität der zeitlichen Prognosen ermöglichen (Mit PrognoseUngenau lässt sich praktisch nur die PrognoseQualitätsstufe 5 abbilden, nicht jedoch die Stufen 1-4).

Beide Elemente unterscheiden sich insofern, dass bei Verwendung von PrognoseUngenau dem Datenempfänger oft bis auf Weiteres keine neuen zeitlichen Prognosen mehr bereitge- stellt werden können, wohingegen dies bei Verwendung von PrognoseQualität nur bei Quali- tätsstufe 5 der Fall ist. Bei den Qualitätsstufen 1-4 ist die Bereitstellung von zeitlichen Progno- sen weiterhin möglich.

VDV 453 Version 3.1.0 - 62 - 23.09.2024

[Seite 65]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Für die gleichzeitige Verwendung von PrognoseUngenau und PrognoseQualität ergeben sich daraus folgende Regeln:

• Die Angabe von PrognoseUngenau entspricht der PrognoseQualitätsstufe 5. Wird diese Stufe mittels der PrognoseQualität angegeben, könnte PrognoseUngenau ge- nutzt werden, um einen Grund für die ungenaue Prognose zu übertragen.

• Werden mittels PrognoseQualität die Qualitätsstufen 1-4 verwendet, darf nicht gleich- zeitig das Element PrognoseUngenau gesetzt sein, da dies ansonsten einen Wider- spruch darstellt und zu inkonsistenten Informationen führt.

• Werden beide Elemente gleichzeitig verwendet, ist zu beachten, dass die Information PrognoseQualität im Vergleich zu PrognoseUngenau auf die nächsten Halte fortge- schrieben wird. Die Werte für PrognoseUngenau hingegen sind explizit für jeden Halt einzeln zu setzen.

Weitere Informationen zu PrognoseUngenau sind in der VDV-Schrift 453, Kapitel 6.1.14 fest- gehalten.

6.1.17 Sprache

Der Sprachcode folgt dem Standard ISO 639-1:2002 (http://www.iso.org/iso/home/stan- dards/language_codes.htm und aktuelle Liste auf der Sprachcodes auf http://en.wikipe- dia.org/wiki/List_of_ISO_639-1_codes). Der Sprachcode besteht aus zwei kleingeschriebenen Buchstaben, identisch gemäß ISO 639-1.

Beispiele:

Tabelle 11 – Beispiele Sprachcode

Bekommt ein Abnehmer bei denjenigen Elementen, bei denen es fachlich erlaubt ist, mehrere Einträge in unterschiedlichen Sprachen, so ist es für den Abnehmer sprachübergreifend nicht ersichtlich, welche Einträge inhaltlich zusammengehören. Beispiel: an einer IstFahrt werden fünf FahrtHaltspezialText-Elemente geliefert, zwei davon sind mit dem Attribut "Englisch" ver- sehen, drei mit dem Attribut "Deutsch". Da der Abnehmer nicht feststellen kann, ob und für welchen deutschen Hinweis eine Übersetzung fehlt, wird er auf Englisch voraussichtlich nur die zwei englischen Hinweise darstellen. Im Interesse einer vollständigen Auskunft sollte also die Quelle dafür sorgen, möglichst alle Texte mehrsprachig zu pflegen und zu übermitteln.

In welcher Sprache ist ein Text formuliert, bei dem kein Sprachattribut gesetzt ist? Dies wird bewusst offengelassen, um Quellen nicht dazu zu zwingen, auf jeden Fall eine Sprache zu unterstützen. Im Umkehrschluss bedeutet dies, dass ein Abnehmer aber bei Elementen ohne Sprachmarkierung nicht wissen kann, in welcher Sprache sie formuliert sind. Werden zum Beispiel zwei FahrtHaltspezialText-Elemente an einer Fahrt übertragen, wobei eines keine

VDV 453 Version 3.1.0 - 63 - 23.09.2024

[Seite 66]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Sprachattributierung besitzt und das andere als "Französisch" markiert ist, wird der Abnehmer bei einer Beauskunftung auf französisch den explizit als solchermaßen markierten Hinweis anzeigen, bei Beauskunftungen in allen anderen Sprachen auf das nicht markierte Element zurückgreifen.

Anmerkung: Im XSD wird der Datentyp xsd:language verwende. Dieser Typ regelt aber nur das Format (gültige Werte wären: en, en-US, fr-FR, etc.). Eine Enumeration ist nicht hinterlegt, daher orientiert sich VDV453/454 an ISO 639-1:2002 (gültige Werte: de, fr, it, etc.).

Im nachfolgenden Beispiel wurde der sprachneutrale Text (ohne Angabe einer Sprache) für den FahrtHaltspezialText in Deutsch verfasst. Hat der Abnehmer keinen Sprachvorgabe, so wird er die drei Elemente vom Deutschen Text anzeigen. Hat er aber als Sprachvorgabe Fran- zösisch, so wird er lediglich alle mit dem Sprachcode=fr gekennzeichnete Elemente anzeigen. In diesem Fall wäre es nur ein Element mit dem Inhalt "Le train a 20 minutes de retard.".

Für die Haltestelle wurde der sprachneutrale Text (ohne Angabe einer Sprache) für die Halte- stelle in Französisch verfasst. Mit der Sprachwahl "fr" und ohne Sprachwahl wird der Text "Neuchâtel" ausgegeben, mit der Sprachwahl "de" wird "Neuenburg" ausgegeben.

Tabelle 12 – Beispiele Auswirkung Sprachcodes

Folgendes ist bei der Definition von mehrsprachigen Elementen zu beachten:

• Bei allen mehrsprachigen Elementen muss in der VDV-Schrift angegeben werden, ob pro Sprache eine oder mehrere Ausprägungen übermittelt werden dürfen (das Element "FahrtHaltspezialText" darf in jeder Sprache mehrfach übermittelt werden, das Element "Zugname" nur einmal).

Folgendes ist zu beachten:

• Der sprachneutrale Text kann in jeder Meldung in einer anderen Sprache übermittelt werden. Daher ist es wichtig, dass ein übermitteltes Element in einer Meldung alle vor- her übermittelten Werte für dieses Element überschreibt.

VDV 453 Version 3.1.0 - 64 - 23.09.2024

[Seite 67]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.2 Anschlusssicherung (REF-ANS, ANS)

6.2.1 Einleitung

Eine zwischenbetriebliche Anschlusssicherung setzt voraus, dass beide Betriebe über ITCS- Systeme verfügen, die interne Anschlussfunktionalitäten bereitstellen. Der in diesem Kapitel beschriebene Datenaustausch versetzt die Systeme in die Lage, alle notwendigen Daten über Zubringerfahrzeuge zu erhalten, so dass eine Anschlussüberwachung und -disposition durch- geführt werden kann. Die betrieblichen Verfahrensweisen der Disposition bleiben dabei unbe- rührt.

Es werden durch die Schnittstellen zwei Dienste zur Verfügung gestellt. Der Referenzdaten- dienst Anschlusssicherung (REF-ANS) stellt Funktionen zur Übermittlung von geplanten An- kunftszeiten an Anschlussbereichen zur Verfügung.

Der Prozessdatendienst Anschlusssicherung (ANS) bietet Funktionen zum Austausch von Ist- daten (Fahrplanlagen, Auswirkungen dispositiver Maßnahmen) zur Verfügung.

Der Prozessdatendienst kann in zwei Ausprägungen benutzt werden:

1. Fahrtbezogener Austausch von Prozessdaten

Entspricht dem Verfahren in VDV453, Version 1.0. Hier werden Prozessdaten zuvor be- kannter Fahrten ausgetauscht. Die Bekanntmachung erfolgt durch gemeinsame Fahrpla- nung oder durch die Benutzung des Referenzdatendienstes Anschlusssicherung (REF- ANS). Dadurch kann die Anschlussvereinbarung direkt im Anschluss an die Übernahme des tagesaktuellen Fahrplans in das ITCS-System begonnen werden. Die Menge der An- schlüsse ist also im Vorfeld bekannt.

2. Zeitbezogene Anschlusssicherung

Dieses Verfahren wurde in der Version 2.0 der VDV453 neu eingeführt. Es gestattet An- schlusssicherung ohne vorherigen Austausch von Referenzdaten. Die Anschlussverein- barung erfolgt hier kurzfristig.

Innerhalb des Dienstes Anschlusssicherung ist sowohl eine Nachrichtenübermittlung vom Zu- bringer zum Abbringer (Zubringernachricht) wie auch – für den Prozessdatendienst – vom Ab- bringer zum Zubringer (Abbringernachricht) definiert.

1. Zubringernachrichten

Alle Nachrichten, die vom Zubringer zum Abbringer laufen, werden innerhalb eines Ele- mentes Zubringernachricht (Kapitel 6.2.4.3) gekapselt. Die Zubringernachricht wird sowohl im Referenz- als auch im Prozessdatendienst verwendet.

Im Rahmen des Referenzdatendienstes Anschlusssicherung besteht die Zubringernach- richt ausschließlich aus Fahrplaninformationen (Kapitel 6.2.3.3.).

Im Prozessdatendienst kann die Zubringernachricht aus einer beliebigen Kombination von Fahrplanlageinformationen (ASBFahrplanlage, Kapitel 6.2.4.3.1) bestehen.

2. Abbringernachrichten

VDV 453 Version 3.1.0 - 65 - 23.09.2024

[Seite 68]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Neben den Botschaften, die vom Zubringer zum Abbringer kommuniziert werden, gibt es im Prozessdatendienst weitere Nachrichten (Abbringernachricht, Kapitel 6.2.4.4), die den umgekehrten Weg, vom Abbringer zum Zubringer nehmen. Sie dienen der Fahrgastinfor- mation in den Zubringerfahrten. Alle Rückkanal-Botschaften sind optional. Ob ein System diese Nachrichten sendet, bleibt einer zwischenbetrieblichen Vereinbarung überlassen. Eine Unterscheidung je nach Partner wird über die Pflege von Meta-Daten geregelt.

6.2.2 Betriebliche Datenversorgung und –pflege

Für den einfachsten Fall des Referenzdatenaustausches zur Anschlusssicherung ist nur die vorgeschriebene Versorgung mit gemeinsamen Anschlussbereichs-Bezeichnern (ASBIDs) notwendig. Es wird eine Abbildungstabelle der abstrakten Ortsbezeichner (Anschlussberei- che) zu den internen Ortsbezeichnern (Haltestellen oder -bereichen) erstellt (6.1.4). Auf der Seite des Abbringersystems ist zusätzlich die Umsteigezeit zu pflegen.

Eine Definition dieser Art könnte in beiden Systemen folgendermaßen aussehen:

Tabelle 13 - Abbildung der Anschluss-Ortsbezeichner beim Zubringer (ITCS A)

Tabelle 14 - Abbildung der Anschluss-Ortsbezeichner beim Abbringer (ITCS B)

Bereits hiermit ist es möglich, Anfragen für Zubringerdaten zu stellen. Allerdings ist keinerlei Auswahl aufgrund bestimmter Umsteigebeziehungen von Linien, Richtungen oder Tageszei- ten möglich. Dies erfordert eine erweiterte Datenpflege, die zusätzlich Umsteigebeziehungen definiert. Die Datenpflege wird aus Abbringersicht vorgenommen.

VDV 453 Version 3.1.0 - 66 - 23.09.2024

[Seite 69]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Tabelle 15 – Definition von Umsteigebeziehungen beim Abbringer

Hier wurde definiert, dass Fahrten zweier Richtungen (Zoo, Bahnhof) einer Linie (10) des Fremdbetriebes ITCS A potenzielle Zubringer sein können, allerdings nur zwischen 10:00 und 12:00 Uhr, bzw. zwischen 10:00 und 14:00 Uhr und wenn das Abbringerfahrzeug des eigenen Unternehmens sich auf Linie 12 in Richtung Hbf. bewegt.

Erkennbar ist hier, dass neben der ASBID die Fremdlinie bzw. -richtung als Meta-Daten mit gepflegt werden müssen. Auch die eigenen Linien- und Richtungsinformationen müssen als Meta-Daten gepflegt werden, da für Botschaften des Rückkanals, bzw. beim Abonnieren Ab- bringer-Informationen zur Verfügung gestellt werden müssen.

Zubringerseitig müssen Metadaten von Linien oder Richtungen des Abbringers nicht gepflegt werden.

Sofern weitere Daten als Kriterium (ServiceAttribut, Produkttyp) für die Anschlussfindung rea- lisiert werden sollen, sind diese Daten im Rahmen der Definition der Umsteigebeziehungen zu definieren. Es ist allerdings zu beachten, dass das ServiceAttribut optional ist. Näheres zur Definition von ServiceAttributen siehe Abschnitt 6.1.9. Die ServiceAttribute einer Fahrt sind optionaler Inhalt der FahrtInfo (siehe Kapitel 6.2.3.3.3).

Ebenso sind Produkttypen (ProduktID) zwischenbetrieblich abzustimmen.

Soll die im Ist-Datendienst VDV 454 AUS beschriebene Struktur GesAnschluss genutzt wer- den, muss der Zubringer neben der ASBID auch die HaltID für den Ort des Anschlusses über- mitteln, da den Auskunftssystemen keine ASBIDs bekannt sind.

6.2.3 Referenzdatendienst (REF-ANS)

Der Referenzdatendienst dient zum Austausch von Planungsdaten für potenzielle Zubringer- fahrten. Der Dienst ist ortsbezogen, d.h. alle Anfragen und Antworten beziehen sich auf kon- krete Anschlussbereiche.

Der Austausch von Referenzdaten ist nur im Zusammenhang mit der fahrtbezogenen An- schlusssicherung sinnvoll. Die fahrtbezogene Anschlusssicherung setzt die Kenntnis der Zu- bringerfahrten voraus. Dies kann sowohl durch eine gemeinsamen Fahrplanversorgung ge- schehen als auch durch den Austausch mittels des Referenzdatendienstes.

Der Referenzdatendienst wird durch den Abbringer eingeleitet. Er fragt beim Zubringer Fahrten für einen definierten Anschlussbereich an. Die Anfrage kann – soweit eine betriebliche Meta- Datenpflege vorhanden – auf Fremdlinien und -richtungen beschränkt werden.

Der Zubringer erfüllt die Anfrage, indem er ASBLinienFahrpläne mit den zugehörigen Zubrin- gerankünften für die gewünschten Anschlussbereiche zurückliefert. Die zu jeder Fahrt

VDV 453 Version 3.1.0 - 67 - 23.09.2024

[Seite 70]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

gelieferte FahrtID dient der späteren Referenzierung im Abonnement des Prozessdatendiens- tes Anschlusssicherung.

Der Referenzdatendienst erfüllt somit zwei Zwecke:

• Vorbereiten des Abonnierens von Prozessdaten (fahrtbezogen)

• Anschlussfindung im weiten Vorfeld

Änderungen im Fahrplan durch dispositive Maßnahmen werden im Rahmen des Abo-Verfah- rens ebenfalls kommuniziert. (Kapitel 6.2.3.1.1). Diese Funktion ist serverseitig optional. Cli- ents müssen Aktualisierungen in jedem Fall formell entgegennehmen und bestätigen können.

6.2.3.1 Datenaustausch

Die Initiative des Referenzdatendienstes erfolgt durch den Abbringer. Das Abbringer-System generiert für jede definierte Umsteigebeziehung (Tabelle 15) eine AboAnfrage (und mit ihr eine diensteindeutige AboID). Die Anfrage besteht aus der ASBID des Anschlussortes und den weiteren (optionalen) Filtern Linie und Richtung. Es können mehrere Anfragen innerhalb einer AboAnfrage definiert werden.

Die fachlichen Daten der Anfrage sind in einem Element namens AboASBRef gekapselt, wel- ches den dienstspezifischen Rahmen darstellt. Der Anfragezeitraum erstreckt sich dabei übli- cherweise auf den gesamten Verfügbarkeitshorizont des eigenen Systems (bis zum Ende des Betriebstages, bzw. zum Ende des Betriebstages auf der Abbringerlinie).

Das Zubringersystem bestätigt nach Erhalt der Botschaft und Überprüfung der Gültigkeit der Metadaten mittels einer Bestaetigung-Antwort.

Anschließend durchsucht das Zubringersystem den eigenen Solldatenbestand (einschließlich der aktuellen Dispositionen) und stellt die Zubringerankünfte zusammen. Die Bereitstellung der Daten wird durch eine entsprechende DatenBereit-Meldung an den Abbringer signalisiert.

Der Abbringer kann nun alle zusammengestellten Daten abfordern (DatenAbrufenAnfrage- Botschaft). Das Zubringersystem antwortet mit einer DatenAbrufenAntwort-Meldung, die die fachlichen Daten (Zubringerankünfte) enthält.

6.2.3.1.1 Aktualisierung

Der Abbringer erhält nach Stellen der Anfrage recht zeitnah die Antwort mit den Zubringeran- künften gebündelt in ASBLinienFahrplänen. Ändern sich diese, so werden erneute DatenBe- reitAnfragen an den Abbringer gesendet, um anzuzeigen, dass sich die Daten geändert haben.

Als Änderung wird jeweils immer ein kompletter ASBLinienFahrplan übermittelt. Die Ursache ist dabei ohne Belang (Verfügbarkeit neuer Daten, Verstärker, SEV, Umleitungen anderer Li- nien über ASB).

Änderungen der Fahrt selbst (Starthaltestelle, Abfahrtszeit, Transportgefäß, Produkt) bleiben verborgen, bzw. werden im Rahmen des Prozessdatenaustausches kommuniziert. Fahrten, die aufgrund einer dispositiven Maßnahme den Anschlussbereich nicht mehr erreichen,

VDV 453 Version 3.1.0 - 68 - 23.09.2024

[Seite 71]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

werden über eine explizite Meldung (ASBZubringerMeldungsart="Ausfall") aus der Anschluss- sicherung entfernt.

Ersatzfahrten für ausfallende Fahrten sollten transparent ausgetauscht werden (Implementie- rungsempfehlung). Hierbei handelt sich also um die gleiche Fahrt mit anderem Fahrzeug.

Aktualisierungen sind serverseitig optional. Clients müssen Aktualisierungen in jedem Fall ent- gegennehmen können.

6.2.3.2 Bereichsfahrpläne anfragen (AboASBRef)

Das Abonnieren von Fahrplandaten erfolgt über eine AboAnfrage mit einem eingebetteten Element vom Typ AboASBRef.

Das Element vom Typ AboASBRef spezifiziert dabei den Anschlussbereich, optionale Filter- kriterien sowie den Anfragezeitraum, für welchen Daten geliefert werden sollen.

LinienID und RichtungsID sind unabhängig voneinander optional. Es ist also möglich, eine Anfrage zu spezifizieren, die nur einen Richtungsfilter besitzt und keinen Linienfilter definiert.

Das Element FruehesteAnkunftszeit sollte nicht vor den Beginn des eigenen Datenhorizontes gesetzt werden, SpaetesteAnkunftszeit nicht nach dem Ende des Horizontes. Das Attribut Ver- fallZst sollte zeitgleich oder später SpaetesteAnkunftszeit sein.

Das folgende Beispiel beschreibt eine Referenzdatenanfrage ("ITCS A" ist Abbringer) für den Anschlussbereich "12345". Es sollen nur Zubringerdaten der Linie 100 in Richtung "Zoo" ge- liefert werden. Das Abbringer-ITCS, welches die Anfrage stellt, hat einen Datenhorizont vom 5:00 Uhr bis 23:00 Uhr, 8.8.2001. Das Zubringer-ITCS seinerseits hat nur einen Datenhorizont bis 22:00 Uhr.

VDV 453 Version 3.1.0 - 69 - 23.09.2024

[Seite 72]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Vom Zubringer erfolgt eine Antwort vom Typ Bestaetigung innerhalb der Botschaft AboAnt- wort. Erst im Zeitfenster des übermittelten ASBLinienFahrplans wird der eingeschränkte Da- tenhorizont signalisiert (6.2.3.3.2):

6.2.3.3 Linienorientierte Bereichsfahrpläne übermitteln (ASBLinienFahrplan)

Nachdem die Referenzdaten-Abonnements eingerichtet sind (Kapitel 6.2.3.2), ermittelt das Zubringersystem die Zubringerankünfte und signalisiert diese mit der initialen DatenBereitAn- frage-Meldung:

Der Empfang wird durch den Abbringer mit einer Bestaetigung innerhalb der Botschaft DatenBereitAntwort beantwortet:

Anschließend erfolgt durch den Abbringer das Abrufen der Daten mit einer DatenAbrufenAnfrage:

Der Zubringer beantwortet diese Botschaft mit den gewünschten Daten innerhalb von Elemen- ten vom Typ ASBLinienFahrplan. Dieser wiederum ist Unterelement der sogenannten

VDV 453 Version 3.1.0 - 70 - 23.09.2024

[Seite 73]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Zubringernachricht (Kapitel 6.2.4.3) und gruppiert pro Linien-Richtungs-Kombination alle An- künfte (ASBSollFahrt) an einem Anschlussbereich. Der ASBLinienFahrplan beinhaltet außer- dem die BetreiberID und die Quittierung des abonnierten Zeitbereichs.

Die Ankunftstafeln entstehen durch Zusammenfügen von mehreren Elementen vom Typ ASBLinienFahrplan.

6.2.3.3.1 Einzel-Ankunftsdaten (ASBSollFahrt)

Jeder ASBLinienFahrplan beinhaltet seine Liste von ASBSollFahrt-Elementen.

VDV 453 Version 3.1.0 - 71 - 23.09.2024

[Seite 74]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.2.3.3.2 Verfügbarkeitshorizont (Zeitfenster)

Da das Ende des Betriebstages des eigenen ITCS in der Regel nicht dem Ende des Betrieb- stages eines Fremd-ITCS gleicht, muss davon ausgegangen werden, dass eine Bereitstellung von Daten nicht für den gesamten Anfragezeitraum erfolgen kann. Damit der Datenkonsument (Abbringer) Kenntnis von dieser Situation erhält, muss im ASBLinienFahrplan zwingend mittels der Struktur Zeitfenster bestätigt werden, welcher Teil des abonnierten Zeitbereiches auch wirklich geliefert werden kann.

Liegt der Anfragezeitraum so weit in der Vergangenheit, dass der Datenlieferant keine Daten des angefragten Zeitbereiches mehr zur Verfügung hat, sendet er entweder keine Daten für dieses Abo oder er quittiert bereits das AboASBRef mit "notok" und einer Fehlernummer aus dem Bereich 300-399.

Liegt der Anfragezeitraum so weit in der Zukunft, dass der Datenlieferant noch keine Daten des angefragten Zeitbereiches zur Verfügung hat, sendet er vorerst noch keine Daten und liefert sie nach, sobald sie verfügbar sind.

Sobald der Datenlieferant neue Daten zur Verfügung hat, sendet er einen aktualisierten ASBLinienFahrplan mit dem möglichst kompletten abonnierten Zeitraum.

VDV 453 Version 3.1.0 - 72 - 23.09.2024

[Seite 75]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.2.3.3.3 Zusatzinformationen zur Fahrt (Fahrtinfo)

Informationen des Elementes FahrtInfo besitzen keine Funktionalität im Rahmen der An- schlusssicherung. Sie sind daher alle optional und dienen primär dem Disponenten als zusätz- liche Informationen, ggf. für eine telefonische Absprache mit einer anderen Leitstelle bzw. zu Protokollierungszwecken.

VDV 453 Version 3.1.0 - 73 - 23.09.2024

[Seite 76]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Die anzugebenden ServiceAttribute dienen der Auszeichnung von Schülerfahrten, Behinder- tengerechten Fahrzeugen und anderen Qualitätsmerkmalen.

Der RichtungsText ist dasjenige Feld, welches zur Publikumsanzeige gebracht wird. Es ist deswegen ein Pflichtfeld und existiert so auch in der VDV 454. Beim RichtungsText ist ein Text zu liefern, der von den Zielsystemen 1:1 zur Anzeige gebracht werden darf.

Die Felder ZielHstnameKurz und ZielHstnameLang existieren nur in der VDV 453 und sind nicht zur Publikation gedacht. Sie werden in den meisten Systemen auch nicht verwendet, nur vereinzelt zum Matching, und sie wurden deshalb bisher nicht aus der Schrift gestrichen. Es ist aber beabsichtigt, in der nächsten Version dieser Schrift zumindest ZielHstnameKurz in AZBFahrplanlage zu streichen.

Vorsicht: ZielHstnameKurz enthält oft auch interne Bezeichnungen oder Abkürzungen. Des- halb dieses Feld nicht zur Publikumsausgabe verwenden, um sich Peinlichkeiten zu erspa- ren.Eine Beispielantwort gemäß Anfrage 6.2.3.2 könnte lauten:

VDV 453 Version 3.1.0 - 74 - 23.09.2024

[Seite 77]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Zoo Zoologischer Garten 2001-08-08T06:10:00 34567 10 Bus BVG +4917633445566 Schuelerfahrt behindertengerecht klimatisiert 12345 de:vbb:11000000|Bus|100:2:44347 2001-08-08 1 de:vbb:11000000|Bus|100:2 X10 Zoo Zoologischer Garten 2001-08-08T06:20:00</AnkunftszeitAS- BPlan>

In diesem Fall werden genau zwei Fahrten geliefert, jeweils Linie X10 Richtung Zoologischer Garten mit den Ankunftszeiten 6:10 Uhr und 6:20 Uhr.

6.2.3.3.4 Informationen zur Direktkommunikation (Direktruf)

Das Element Direktruf enthält Informationen zu aktuellen Möglichkeiten der direkten Kommu- nikation mit dem Fahrzeug resp. Fahrer. Damit kann z.B. bei Betriebsschluss der verantwort- lichen Leitstelle oder bei kurzfristigen Erfordernissen eine Fremdleitstelle direkt mit einem Fahrzeug resp. Fahrer kommunizieren. Bei Änderungen, z.B. Fahrerwechsel, sind die Daten zu aktualisieren. Damit bedeutet ein leerer Direktruf das Löschen der bisherigen Daten (keine aktuelle Kommunikationsmöglichkeit bekannt).

Definition Direktruf:

VDV 453 Version 3.1.0 - 75 - 23.09.2024

[Seite 78]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.2.4 Prozessdatendienst (ANS)

Der Prozessdatendienst Anschlusssicherung dient dem Austausch von aktuellen Fahrplanla- gen und fahrgastrelevanten Ereignissen im Zusammenhang mit der Disposition von Anschlüs- sen. Innerhalb des Prozessdatendienstes müssen die Verfahren

• fahrtbezogene Anschlusssicherung

• zeitbezogene Anschlusssicherung

unterschieden werden.

Die fahrtbezogene Anschlusssicherung ermöglicht die Anforderung und den Austausch von Daten für genau einen, zuvor bekannten Zubringer.

Die zeitbezogene Anschlusssicherung dient der Anforderung und dem Austausch von Daten von einem oder mehreren Fahrzeugen, die als potenzielle Zubringer auf einen Anschlussbe- reich zulaufen. Die Begrenzung der Daten erfolgt dabei über Linie, Richtung und ein Zeitfens- ter, in welchem die Ankünfte der zulaufenden Fahrten liegen müssen.

Beide Verfahren werden innerhalb dieses Dienstes mit unterschiedliche Filteranfragen reali- siert. Der Austausch der Daten erfolgt mittels identischer Botschaften und Datenstrukturen. Unterschiede im Verhalten und in den Ergebnismengen resultieren aus den unterschiedlichen Anforderungen der beiden Anschlusssicherungsverfahren.

6.2.4.1 Datenaustausch

Der Datenaustausch im Prozessdatendienst wird durch das Abbringer-System eingeleitet. Es erstellt ein Abonnement, welches die Daten der Fahrten spezifiziert, die es zu erhalten wünscht. Dies kann entweder eine einzelne Fahrt sein (fahrtbezogene Anschlusssicherung) oder ein Pulk von Fahrten, die innerhalb eines Zeitfensters laut Prognose den Anschlussbe- reich erreichen.

Ist das Abonnement beim Zubringer-Server eingerichtet, antwortet dieser sofort mit der Ver- sendung der aktuellen Daten für das Abonnement (Ankündigung durch DatenBereitAnfrage, Lieferung per ASBFahrplanlage als Antwort auf eine DatenAbrufenAnfrage). Diese Daten sind Prognosen, bzw. Plandaten, wenn noch keine Prognosen vorliegen.

Ändern sich die Prozessdaten der dem Abonnement zugeordneten Fahrten (Fahrplanlagen der Zubringer, dispositive Maßnahmen), erfolgt eine Bekanntgabe über das Vorliegen neuer Daten durch den Zubringer (DatenBereitAnfrage).

Der Abbringer kann nun die aktualisierten Daten (nur diese werden gesendet) explizit anfor- dern (DatenAbrufenAnfrage). Nach Datenverlust kann optional der gesamte Datenbestand er- neut abgefragt werden (DatensatzAlle, mehr Details dazu siehe 5.1.4.2.1).

VDV 453 Version 3.1.0 - 76 - 23.09.2024

[Seite 79]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Darüber hinaus existiert die Möglichkeit, den Informationsfluss umzukehren und im Rahmen eines Abonnements Rückmeldungen vom Abbringer zum Zubringer zu kommunizieren (6.2.4.4).

6.2.4.1.1 Aktualisierung/Hysterese

Ein Prozessdaten-Abonnement gilt im Zusammenhang mit der Anschlusssicherung als geän- dert, wenn mindestens eines der folgenden Daten sich ändert:

• Fahrplanabweichung

• Anschluss kann nicht stattfinden (Zubringer erreicht Anschlussbereich gar nicht oder kei- nesfalls mehr rechtzeitig)

• Erreichen des Anschlussbereiches

Eine Änderung bleibt solange aktiv, bis ein explizites Abholen der dem Abonnement zugeord- neten Daten diesen Zustand zurücksetzt.

Um ständige Aktualisierungen aufgrund von minimalen Änderungen der prognostizierten An- kunftszeit zu vermeiden, kann innerhalb der Abonnements ein gewünschter Hysterese-Wert dem Zubringer übergeben werden. Dieser definiert die Zeitspanne, ab wann eine Änderung vom System als signifikant gewertet werden soll und eine Kommunikation stattfinden muss. Bei einem Hysteresewert von z.B. 120 Sekunden werden Änderungen gemeldet, die 2 oder mehr Minuten von der zuletzt gesendeten Ankunftszeit abweichen. Der Hysteresewert dient allerdings nur als Empfehlung, kann also durch das datenproduzierende System ignoriert wer- den.

Die Aktualisierung endet mit dem Verfall (Verfallszeitstempel überschritten) oder dem explizi- ten Löschen des Abonnements.

6.2.4.1.2 Vorschauzeit

Neben der Hysterese beschränkt bei der fahrtbezogenen Anschlusssicherung ein weiterer Pa- rameter – die Vorschauzeit – die Versendung von Daten zu einem Abonnement. Sie be- schränkt die Datenübermittelung auf denjenigen Zeitraum, in dem die Anschlussüberwachung für den Abbringer aktiv ist. Dies spielt insbesondere für langlaufende Fahrten (z.B. Fernver- kehr) eine wichtige Rolle.

Die Vorschauzeit definiert das Zeitfenster vor dem tatsächlichen Eintreffen des Zubringers am Anschlussbereich, innerhalb dessen Fahrplanlageinformationen gesendet werden sollen. Be- findet sich das Fahrzeug zu diesem Zeitpunkt noch nicht auf der Strecke, so handelt es sich um Plan-Informationen.

Die Vorschauzeit ist optional. Wird sie nicht angegeben, gelten die Zeitpunkte des Abo-Ein- richtens (fahrtbezogen), bzw. fruehesteAnkunftszeit.

VDV 453 Version 3.1.0 - 77 - 23.09.2024

[Seite 80]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.2.4.2 Anschlussdaten abonnieren (AboASB)

Das Abonnieren von Prozessdaten erfolgt in der Regel frühestmöglich nach dem Erhalt der Fahrplandaten aus dem Referenzdatendienst (sofern Referenzdatendienst – z.B. für fahrtbe- zogene Anschlusssicherung - benötigt).

Die Kommunikation wird durch den Abbringer eingeleitet. Er erstellt eine AboAnfrage mit ei- nem eingebetteten Element AboASB. Innerhalb des Elementes AboASB gibt es die Unterele- mente FahrtFilter und Zeitfilter, welche die entsprechenden Filter definieren. Innerhalb von AboASB kann entweder genau ein ZeitFilter oder ein oder mehrere FahrtFilter definiert wer- den. Beides zugleich ist nicht zulässig. Es ist mindestens ein Filter anzugeben.

6.2.4.2.1 Fahrtbezogene Daten (Fahrtfilter)

Das Element Fahrtfilter selbst spezifiziert nur den Zubringer, sowie die geplante Ankunftszeit (Stichfahrtproblematik, 6.1.8). Mit Erreichen der Vorschauzeit und bei jeder Änderung werden Fahrplanlagen der angeforderten Fahrzeuge gesendet (ASBFahrplanlage).

VDV 453 Version 3.1.0 - 78 - 23.09.2024

[Seite 81]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Im folgenden Beispiel fordert ein Betrieb (ITCS A) Daten der Zubringerfahrt "7748" am An- schlussbereich "12345" für die Abbringerfahrt "2208" an. Der Verfallszeitstempel wird dabei auf die geplante Abfahrtszeit des Abbringers (16:00 Uhr) zuzüglich der maximalen Wartezeit (10 Minuten) gesetzt. So ist eine Datenversorgung auch bei starker Verspätung des Abbrin- gers gewährleistet. Mit dem Senden der Fahrplanlagen soll 30 Minuten vor Eintreffen der Fahrt am Anschlussbereich begonnen werden.

Der Zubringer bestätigt den Erhalt der Nachricht mit einer Bestaetigung in AboAntwort.

6.2.4.2.2 Zeitbezogene Daten (Zeitfilter)

Das Anfragen zeitbezogener Anschlussabonnements erfolgt analog zu fahrtbezogenen Abon- nements. Der einzige Unterschied besteht in der Angabe genau eines Zeitfilters. Dieser defi- niert die Zubringerlinien/-richtungen, für deren Fahrten Fahrplanlagen und Meldungen zu lie- fern sind. Die Filterkriterien sind optional, d.h. es können auch alle Richtungen einer Linie, alle Linien in einer Richtung, bzw. alle zulaufenden Fahrten an einem Anschlussbereich angefor- dert werden. Die beiden Zeiten innerhalb des Filters definieren das Zeitfenster, innerhalb des- sen Fahrten den Anschlussbereich erreichen müssen, um gemeldet zu werden. Einmal ge- sendete Fahrten werden auch in Folge gesendet, wenn sie nicht mehr in das Zeitfenster fallen.

VDV 453 Version 3.1.0 - 79 - 23.09.2024

[Seite 82]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Vorschauzeit:

Ohne Angabe der Vorschauzeit beginnt das Senden der zum Zeitbereich passenden Fahr- planlagen zeitnah nach dem Einrichten des Abonnements im Zubringersystem. Abonniert ein Abbringersystem einen sehr großen Zeitbereich (z.B. täglich um 03:30 für 25 Stunden), so ist es fraglich, wann genau der Datenlieferant mit dem Senden der Zubringerdaten beginnen soll. Viele Hersteller senden Prognosen, sobald sie diese im System zur Verfügung haben.

Durch die Übermittlung der Vorschauzeit wird die Zeit in Minuten vor geplanter oder prognos- tizierter Ankunftszeit der Zubringerfahrt angegeben, ab der mit dem Senden von Zubringer- prognosen begonnen werden soll. Fahrplanlagen werden in diesem Fall frühstens mit dem Erreichen der Vorschauzeit sowie folgend bei jeder Änderung der Zubringerfahrt gesendet.

Implementierungshinweis:

Eine erste Zubringermeldung sollte gesendet werden, wenn folgende Bedingungen erfüllt sind:

• wenn die geplante Ankunft des Zubringers innerhalb des abonnierten Zeitbereiches liegt,

• wenn die geplante Ankunft des Zubringers ins Vorschaufenster eintritt, falls das Abo eine Vorschauzeit enthielt.

Um auch Anschlüsse sichern zu können, die erst zufällig durch Verspätungen entstehen, sollte eine erste Zubringermeldung außerdem gesendet werden, wenn die gleichen Bedingungen für die prognostizierte Ankunft erfüllt sind.

Im folgenden Beispiel sollen für eine auf einen Anschlussbereich zulaufende Fahrt (ITCS A), Zubringerdaten der Fahrten auf Linie 200, Richtung "Hauptbahnhof" abonniert werden. Es sol- len nur Daten für Fahrzeuge gesendet werden, die zwischen 15:50 und 16:10 Uhr laut aktueller Prognose den Anschlussbereich erreichen.

VDV 453 Version 3.1.0 - 80 - 23.09.2024

[Seite 83]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

HBF 2001-08-08T15:50:00 2001-08-08T16:10:00 120

Es sollen nur dann Fahrplanlagen gesendet werden, wenn die Änderung der Verspätung min- destens 120 Sekunden beträgt.

6.2.4.2.3 Zusatzinformation zum Abbringer (AbbringerInfo)

Das optionale Element AbbringerInfo dient der Solldaten-Versorgung von Innenanzeigern in Zubringerfahrzeugen (Abbringeranzeiger).

VDV 453 Version 3.1.0 - 81 - 23.09.2024

[Seite 84]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.2.4.3 Nachrichten des Zubringers (Zubringernachricht)

Alle Nachrichten, die vom Zubringer zum Abbringer laufen, werden innerhalb des Elementes Zubringernachricht gekapselt. Dieses Element besitzt selbst keine Datenelemente, sondern gruppiert logisch alle Nachrichtenelemente, die vom Zubringer an den Abbringer gesendet werden.

Folgende Meldungen können innerhalb der Zubringernachricht gemeldet werden:

Im Referenzdatendienst:

• Bereichsfahrplandaten (ASBFahrplanlage)

Im Prozessdatendienst:

• Aktuelle Fahrplanlagen, Ankunft auf ASB und Ausfall einer Fahrt (ASBFahrplanlage)

6.2.4.3.1 Anschlussdaten übermitteln (ASBFahrplanlage)

Nachdem das Abonnement eingerichtet ist, ermittelt der Zubringer initial die Daten für die ge- wünschte Fahrt (fahrtbezogene Abonnements), bzw. für das gewünschte Zeitfenster (zeitbe- zogene Abonnements). Er signalisiert die Bereitschaft Daten zu versenden mit einer DatenBe- reitAnfrage, deren Erhalt der Abbringer durch eine Bestaetigung in DatenBereitAntwort quittiert (s. Kapitel 6.2.3.3). Der Zeitpunkt der initialen Signalisierung ist bei der zeitbezogenen An- schlusssicherung zeitnah nach der Einrichtung des Abonnements zu erwarten. Bei fahrtbezo- genen Abonnements erfolgt die erstmalige Benachrichtigung erst nach Erreichen der Vor- schauzeit.

Der Abbringer fordert nun die seit der letzten DatenBereitAnfrage geänderten Daten aller Abonnements explizit an:

VDV 453 Version 3.1.0 - 82 - 23.09.2024

[Seite 85]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Als Antwort erhält der Abbringer eine DatenAbrufenAntwort, in der sich je geändertem Abon- nement ein Element vom Typ Zubringernachricht befindet. In die Zubringernachricht ist eine Element ASBFahrplanlage eingebettet, welches die Statusinformationen zur Fahrt enthält:

VDV 453 Version 3.1.0 - 83 - 23.09.2024

[Seite 86]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Das Element SpaetesteAbbringerInfo dient dazu, dem Abbringer-System mitzuteilen, wann das Zubringer-System die Informationen aus dem Rückkanal für die Fahrgastinformation ver- wenden will. Darüber kann dem Abbringer-System eine Information für die Dispositionsent- scheidung zur Verfügung gestellt werden, um z.B. den spätesten Zeitpunkt für einen manuel- len Eingriff des Disponenten festzulegen.

Beispiel Fahrtbezogenes Abonnement

Das folgende Beispiel zeigt die Antwort auf ein fahrtbezogenes Abonnement für einen Zubrin- ger mit der geplanten Ankunftszeit 15:58 Uhr (zugehöriges Abonnement-Beispiel siehe Kapitel 6.2.4.2.1). Mit Erreichen der 30-minütigen Vorschauzeit wird erstmalig ein Fahrplanlagetele- gramm gesendet. Eine Prognose ist zum Zeitpunkt des Sendens der Fahrplanlage (15:28 Uhr) nicht möglich, da sich das Fahrzeug noch nicht auf der Strecke befindet (PrognoseMoeglich = "false", Prognose = Plan).

VDV 453 Version 3.1.0 - 84 - 23.09.2024

[Seite 87]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Fahrplanlage 12345 de:vbb:11000000|Bus|100:2:7748 2001-08-08 1 de:vbb:11000000|Bus|100:2 X10 Zoo Zoologischer Garten 2001-08-08T15:58:00 false

Wird die Fahrt angetreten und überschreitet die Fahrplanabweichung 120 Sekunden (ge- wünschte Hysterese in AboASB), wird dies vom Zubringer signalisiert (DatenBereitAnfrage). Die Abfrage erfolgt wieder über DatenAbrufenAnfrage durch den Abbringer. Eine mögliche Antwort könnte folgendermaßen aussehen:

VDV 453 Version 3.1.0 - 85 - 23.09.2024

[Seite 88]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Dieses Verfahren wird so lange wiederholt, bis das Fahrzeug die Haltestelle erreicht hat (letzte Meldung mit ASBZubringerMeldungsart="BereichErreicht"), bzw. der Abbringer das Abonne- ment explizit löscht.

Implementierungshinweis:

Wenn der VerfallZst erreicht ist, sind die Fahrten aus der Anschlusssicherung herauszuneh- men, auch wenn dieser Zeitpunkt vor der AnkunftszeitASBPrognose liegt.

Implementierungshinweis:

Das Zubringersystem ist auf jeden Fall gehalten, die letzte Meldung mit ASBZubringerMel- dungsart="BereichErreicht" zu senden. Wenn eine tatsächliche Erkennung, dass das Fahr- zeug die Halteposition erreicht hat, technisch nicht möglich ist (z.B. im Eisenbahnbereich), soll eine robuste Prognose durch das Zubringersystem erstellt und übermittelt werden, da das Zu- bringersystem besser als das Abbringersystem zu einer Schätzung in der Lage ist.

Beispiel Zeitbezogenes Abonnement

Im folgenden Beispiel antwortet der Zubringer im Rahmen eines zeitbezogenen Abonnements auf die DatenAbrufenAnfrage mit den Fahrplanlagen zwei Fahrten (zugehöriges Abonnement- Beispiel siehe Kapitel 6.2.4.2.2):

VDV 453 Version 3.1.0 - 86 - 23.09.2024

[Seite 89]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Hauptbahnhof 2001-08-08T15:48:00 2001-08-08T15:53:00 false de:11000:900023201 Bussteig 3 Fahrplanlage 12345 de:vbb:11000000|Bus|200:26611 2001-08-08 1 de:vbb:11000000|Bus|200:2 200 HBF Hauptbahnhof 2001-08-08T16:05:00 2001-08-08T16:06:00 false

Fahrt 7748 ist ein Beispiel für eine Fahrt, die nur aufgrund ihrer starken Verspätung in das Zeitfenster fällt.

Änderungsmeldungen erfolgen analog zur fahrtbezogenen Anschlusssicherung. Zu beachten ist, dass einmal in das Zeitfenster gefallene Fahrten über die gesamte Lebenszeit des Abon- nements aktualisiert und gesendet werden. Die Zahl der gemeldeten Fahrplanlagen über die Lebenszeit des Abonnements kann also ansteigen (s. Kapitel 3.1.10).

6.2.4.3.2 Zubringerausfall

Der Ausfall des Zubringers kann aus mehreren Gründen erfolgen:

• Ausfall des Zubringerfahrzeuges

• Umleitung der Zubringerlinie/-richtung

VDV 453 Version 3.1.0 - 87 - 23.09.2024

[Seite 90]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

• Störung eines Linienabschnittes

• Vorzeitige Wende

Ein Zubringerausfall bezeichnet also den nicht mehr oder nicht rechtzeitig stattfindenden Halt an der Anschlusshaltestelle. Dies führt ggf. zur Aufgabe des Anschlusses seitens des Abbrin- gers.

Die Bekanntgabe erfolgt mittels Übertragung einer ASBFahrplanlage (6.2.4.3.1). Hierbei wird das Element ASBZubringerMeldungsart auf "Ausfall" gesetzt.

Da die eindeutige Referenzierung der Fahrt über die FahrtID nicht immer möglich ist, sollen die optionalen Strukturen und Felder VonRichtungsText, AnkunftHaltID, AnkunftssteigText und FahrtInfo nach Möglichkeit befüllt werden.

Folgendes Beispiel zeigt eine mögliche Botschaft, die ein Zubringer bei einem Ausfall der Fahrt 7748 am Anschlussbereich AB3 um 15:58 Uhr der Linie X10 meldet:

VDV 453 Version 3.1.0 - 88 - 23.09.2024

[Seite 91]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Es ist zu beachten, dass mit der Ausfallmeldung des Zubringers die Fahrt selbst nicht aus dem Abonnement gelöscht werden darf. Nach einem Wiederaufsetzen des Abbringers nach Daten- verlust (DatenAbrufenAnfrage) muss die Ausfallmeldung erneut initial innerhalb einer ASB- Fahrplanlage gesendet werden.

6.2.4.4 Nachrichten des Abbringers (Abbringernachricht)

Neben den Botschaften, die vom Zubringer zum Abbringer kommuniziert werden, gibt es wei- tere Nachrichten, die den umgekehrten Weg vom Abbringer zum Zubringer nehmen.

Die Botschaften des Rückkanals werden mit der Kennung einer oder mehrerer Zubringerfahr- ten versehen, so dass eine gezielte Benachrichtigung möglich ist.

Diese Abbringernachrichten müssen nicht explizit abonniert werden, sondern stellen einen Rückkanal bei einem bestehenden Abonnement dar.

Folgende Abbringernachrichten sind vorgesehen:

• Änderung des Abfahrtsortes am Anschlussbereich

• Änderung des Abbringer-Dispositionszustandes (Wartezeit)

• Ausfall des Abbringers

Der Abbringer signalisiert die Änderung der dem Abonnement zugeordneten Prozessdaten mittels einer DatenBereitAnfrage. Der Zubringer bestätigt und fragt seinerseits mit DatenAbru- fenAnfrage die Daten ab.

Der Abbringer liefert nun innerhalb von DatenAbrufenAntwort/Abbringernachricht ein oder mehrere Elemente der oben angeführten Abbringernachrichten.

6.2.4.4.1 Änderung der Halteposition (HaltepositionsAenderung)

Ändert der Abbringer seine geplante Halteposition innerhalb des Anschlussbereiches, so ist dies u. U. fahrgastrelevant. Diese Funktion dient dazu, Fahrgästen Daten über den neuen Umsteigeweg bereit zu stellen.

Basis ist ein bestehendes Abonnement (AboASB), welches Zubringerdaten abonniert. Mittels der FahrtIDExt wird die Nachricht an einen oder mehrere Zubringer adressiert. Dabei dient die

VDV 453 Version 3.1.0 - 89 - 23.09.2024

[Seite 92]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

FahrtID des Abbringers als Bezug. Somit ist sichergestellt, dass auch die Innenanzeigen in den Zubringern mit der neuen Halteposition des Abbringers aktualisiert werden können.

6.2.4.4.2 Referenzierung von Fahrten (FahrtIDExt)

Das Element FahrtIDExt dient bei Abbringernachrichten dazu, um im Fall einer für mehrere Zubringerfahrten gültigen Abbringernachricht die betroffenen Zubringerfahrten über FahrtID resp. FahrtBezeichner sowie Betriebstag und HstSeqZaehler eindeutig zu identifizieren.

Das folgende Beispiel zeigt die vom Abbringer im Rahmen des Abonnements mit der AboID 25 adressierte Nachricht, dass der Abbringer (FahrtID 6612, Linie M48, Richtung Schloss- straße) seine Halteposition im Anschlussbereich (ASBID 12345) auf "Steig 3" wechselt. Die Nachricht ist an die Zubringerfahrt 5467 adressiert.

VDV 453 Version 3.1.0 - 90 - 23.09.2024

[Seite 93]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

de:vbb:11000000|Bus|M48:2 M48 SCHLS Schlossstrasse 2001-08-08T16:00:00 Steig 3 de:vbb:11000000|Bus|200:2:5467 2001-08-08 1 </ HaltepositionsAenderung >

6.2.4.4.3 Wartezeitverlängerung (WartetBis)

Eine wesentliche Funktion der Anschlusssicherung ist das Aufhalten des Abbringers, um Fahr- gästen aus verspäteten Zubringern das Umsteigen zu ermöglichen. Diese sogenannte An- schlussdisposition entscheidet über die Dauer eines außerplanmäßigen Wartens des Abbrin- gers am Anschlussbereich.

Diese Information sollte zum Zubringer kommuniziert werden, um den Fahrgästen die aktuel- len Abfahrtszeiten der Abbringer präsentieren zu können (Innenanzeiger im Fahrzeug).

Eine Wartezeitverlängerung wird durch die Nachricht WartetBis innerhalb einer Abbringer- nachricht dem Zubringer gemeldet.

VDV 453 Version 3.1.0 - 91 - 23.09.2024

[Seite 94]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Implementierungshinweise:

Wenn ein Abbringer auf mehrere Zubringer wartet, so wird ein WartetBis mit mehrfachem Un- terelement FahrtIDExt gesendet. Verspätet sich jetzt einer dieser Zubringer so sehr, dass für ihn der Abbringer nicht mehr zurückgehalten werden kann, so wird ein AbbringerFahrtLo- eschen mit der entsprechenden FahrtIDExt gesendet.

Wenn ein ITCS-System partiell ohne Solldatenversorgung arbeitet, kann es aus Gründen der Eindeutigkeit sinnvoll sein, auch für im Plan liegende Abbringer, für die keine Zurückhaltung erforderlich ist, ein WartetBis mit der aktuellen AbfahrtszeitASBPrognose zu senden. Das glei- che gilt auch, wenn ein Anschluss gehalten werden kann, weil beide Anschlussbeteiligte gleich verspätet sind.

Im unten angeführten Beispiel meldet der Abbringer 6612 der Linie M48 Richtung Schloss- straße eine neue Abfahrtszeit am Anschlussbereich 12345 für 16:02 Uhr zum Zubringer 5467.

VDV 453 Version 3.1.0 - 92 - 23.09.2024

[Seite 95]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.2.4.4.4 Abbringerausfall (AbbringerFahrtLoeschen)

Der Ausfall eines Abbringers bedeutet zugleich ein Nicht-Zustandekommen des zugehörigen Anschlusses. Für das Signalisieren dieses Ereignisses für Fahrgäste im Zubringerfahrzeug (Innenanzeige) dient die Meldung AbbringerFahrtLoeschen, ähnlich (6.2.4.3.2), diesmal aller- dings in anderer Richtung verwendet.

Um das Weitersenden der Fahrplanlage von Zubringern zu unterbinden, ist zusätzlich das zu- gehörige Abonnement seitens des Abbringers explizit zu löschen.

Implementierungshinweis:

Ändert sich bei einer dynamischen Anschluss-Sicherung die Abbringerfahrt, so sollte Abbrin- gerFahrtLoeschen zusammen mit der Information über den neuen Abbringer (WartetBis) in einer Abbringernachricht gesendet werden, um einen ungewollten Anschlussbruch zu vermei- den.

Folgendes Beispiel zeigt die Meldung des Ausfalls eines Abbringers (7712) der Linie M48 um 16:00 Uhr am Anschlussbereich 12345 zum Zubringer "7748", dessen Zubringerdaten unter der AboID 25 abonniert worden waren.

VDV 453 Version 3.1.0 - 93 - 23.09.2024

[Seite 96]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

2001-08-08T16:00:00 /AbbringerInfo> de:vbb:11000000|Bus|100:2:7748 2001-08-08 1

VDV 453 Version 3.1.0 - 94 - 23.09.2024

[Seite 97]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3 Dynamische Fahrgastinformation (REF-DFI, DFI)

6.3.1 Einleitung

Der Dienst Dynamische Fahrgastinformation dient der Vereinbarung und Übermittlung von Da- ten zum Betrieb gemeinsamer Fahrgastinformationsanzeiger an den Haltestellen. Die folgende Spezifikation beschreibt den Austausch von Volltext-Informationen für die Beschickung frem- der DFI-Anzeiger. (Ein optimierter Datenaustausch unter Verwendung von Text-Schlüsseln anstelle der Volltexte ist durch zwischenbetriebliche Vereinbarungen möglich.) Dabei gilt die Festlegung, dass einer der beiden beteiligten Betriebe die Hoheit über den Anzeiger besitzt (Anzeigerbesitzer) und ihn demzufolge ansteuert.

Der Betrieb, der eine Fahrgastinformation auf einem fremden Anzeiger anzeigen möchte, wird als Anzeigerbenutzer bezeichnet.

Der Datenaustausch innerhalb der Schnittstelle erfolgt mittels Volltexten (Ziel, Via-Stationen). Muss der Anzeiger aufgrund geringer Übertragungskapazität in der Datenversorgung mit Schlüsseln angesteuert werden, so sind die Schlüssel betrieblich abzustimmen und im Rah- men der Datenpflege auszutauschen. Auf der Seite des anzeigerbesitzenden Systems müs- sen die Volltexte auf Schlüssel abgebildet werden (Kapitel 6.3.3).

Da einige Systeme die Verarbeitung von Prozessdaten nur erlauben, wenn entsprechende Solldaten bereitstehen, existiert optional ein Referenzdatendienst für die Fahrgastinformation (REF-DFI). Dieser erlaubt bei Bedarf den Austausch von ortsbezogenen Sollfahrplänen für die Fahrgastinformation.

6.3.2 Betriebliche Datenversorgung und –pflege

Ähnlich wie bei der Anschlusssicherung ist zunächst eine zwischenbetriebliche Vereinbarung von Ortsbezeichnern notwendig (Kapitel 6.1.3), hier Anzeigerbereich (AZB) genannt. Verein- bart werden eindeutige, bilaterale Schlüssel, sogenannte AZBIDs. Diese werden auf Seiten des Anzeigerbesitzers auf die Schlüssel der eigenen Anzeiger (oder einer Anzeigergruppe) abgebildet:

Tabelle 16 - Definition von DFI-Ortsbezeichnern beim Anzeigerbesitzer

Empfohlen wird die Verwendung der DHID (oder in anderen Ländern deren Äquivalent) als AZBID. Dadurch würde eine generelle Metadaten-Absprache erfolgen, und die aufwändige Metadaten-Absprache zwischen allen Partnern für jede einzelne Haltestelle entfällt.

Als weiterer Vorteil können dann je nach Erfordernis wahlweise nur Fahrten je Halte- punkt/Steig, je Bereich oder für die ganze Haltestelle abonniert werden. Dies wird in mehreren Regionen bereits erfolgreich praktiziert.

VDV 453 Version 3.1.0 - 95 - 23.09.2024

[Seite 98]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Beispiel: Tübingen Hauptbahnhof

Wenn Abo mit de:08416:11000 in AZBID, bekommt man alle Fahrten Tü. Hbf (Bahn + Bus)

Wenn Abo mit de:08416:11000:1 in AZBID, bekommt man alle im Bereich 1 = Bus, keine Bahndaten

Wenn Abo mit de:08416:11000:1:B in AZBID, bekommt man nur die Fahrten vom Bussteig B

Auf der Seite des Anzeigerbenutzers erfolgt die Abbildung nicht auf die Anzeiger, sondern auf die eigenen Haltestellen. Somit entsteht eine Gesamtabbildung einer Fremdhaltestelle zu ei- nem zugehörigen Anzeiger. Bei der Definition der AZBIDs ist auf die eventuelle Verwendung innerhalb von Abmeldetelegrammen für die scharfe Haltestellenabmeldung zu achten (6.3.5)

Sofern nicht alle an einem Anzeiger vorbeifahrenden Linien zur Anzeige kommen sollen, ist zusätzlich eine Tabelle zu pflegen, die einem Anzeiger anzuzeigende Fremdlinien zuordnet:

Tabelle 17 - Definition von anzuzeigenden Linien

Zusätzlich muss auch hier eine Vereinbarung auf Produkttypen erfolgen. Dies kann relevant sein, um Betriebsbereiche oder Verkehrsmittel der Fahrten mittels Symbole auf dem Anzeiger zu repräsentieren. Die Abbildung der Produkttypen sollte gerade unter diesen Gesichtspunk- ten erfolgen.

Ein Problem stellen unterschiedlich Feldlängen (z.B. für Ziel- oder Via-Texte) auf den Anzei- gern dar. Es ist nicht davon auszugehen, dass es ausreicht, nur eine Feldlänge zu pflegen. Es muss für jede Anzeigervariante eine entsprechende Versorgung mit Volltexten vorgehalten werden. Die Schnittstelle sieht eine Funktion vor, die es erlaubt, eine Maximallänge (MaxText- Laenge) zu spezifizieren, die im Falle mehrerer gepflegter Längen die optimale Länge liefert. Aber auch diese Funktion ist in gewissem Maße unvollständig, da auf Anzeigern häufig Pro- portionalzeichensätze zum Einsatz kommen. Ein Anzeiger besitzt dann keine einheitliche Text- länge pro Zeile, sondern Punkte pro Zeile, die Texte in variabler Länge abbilden können. Die Pflege der Volltexte erfordert somit eine intensive Absprache und Prüfung der Texte.

6.3.3 DFI-Systeme mit Schlüsselansteuerung

DFI-Systeme, denen nur wenig Übertragungskapazität in der Datenversorgung via Funk zur Verfügung stehen, verwenden häufig anstelle der Ansteuerung mit Volltexten (Richtung, Via- Stationen) vordefinierte Texte, denen Schlüssel zugeordnet sind. Bei der Kommunikation zwi- schen ansteuerndem Leitsystem und Anzeiger werden nur die kürzeren Schlüssel verwendet.

Innerhalb der Schnittstelle wird ausschließlich mit Volltexten gearbeitet. Soll eine Schlüssel- ansteuerung auch für Fremdfahrzeuge erfolgen, müssen zuvor alle vordefinierten Texte ein- schließlich derer des Anzeigerbenutzers importiert und mit Schlüsseln versehen werden. Diese sind dann im Rahmen der Datenversorgung den Anzeigersystemen bekannt zu machen.

VDV 453 Version 3.1.0 - 96 - 23.09.2024

[Seite 99]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Die Umsetzung der Volltexte erfolgt beim Anzeigerbesitzer durch Textvergleich des Volltextes mit der Texte-/Schlüsseltabelle des Fremdbetriebes.

6.3.4 DFI-Systeme mit anzeigenautonomer Prognose

Häufig stellt der physikalische Nachrichtenkanal zwischen ITCS und den DFI-Anzeigern eine stark limitierte Ressource dar (z.B. schmalbandiges Funknetz). Der Referenzdatendienst für DFI stellt Informationen bereit, um diese begrenze Ressource besser auszunutzen. Die Idee besteht darin, redundante Informationen, die aus der Einzelansteuerung jedes einzelnen An- zeigers resultieren, zu eliminieren. Dazu versorgt man die Anzeiger zu Beginn des Betriebs- tags mit Fahrplaninformationen. Während des Betriebes werden anstelle von Abfahrtszeitprog- nosen für die von einer Fahrt angefahrenen Anzeiger nur die Verspätungsinformationen im Broadcast-Modus versendet. Der Anzeiger filtert die für ihn relevanten Datenpakete aus dem Datenstrom und erstellt aus dem Solldatenbestand und der aktuellen Ist-Fahrplanlage die An- kunftszeitprognose. Man spricht hier auch von "intelligenten Anzeigern".

Für die Ansteuerung autonomer Anzeiger werden sowohl fahrtbezogene Soll- als auch Ist- Daten benötigt. Die DFI-Schnittstelle stellt jedoch nur ortsbezogene Soll- oder Ist-Informatio- nen bereit, ist also daher nicht in der Lage, Systeme zur Ansteuerung autonomer Anzeiger zu bedienen.

Für solche DFI-Systeme kann auf die Fahrplanauskunftsschnittstelle (VDV-Schrift 454) zu- rückgegriffen werden, da diese Schnittstelle fahrt- bzw. linienbezogene Daten bereitstellen kann.

6.3.5 Scharfe Abmeldung

Um auf einem Anzeiger dargestellte Fahrtinformationen zeitnah mit dem Verlassen der Halt- stelle des Anzeigers entfernen zu können, wird die sogenannte "scharfe Abmeldung" verwen- det. Dazu müssen Haltestelle/Anzeiger und das Fahrzeug direkt miteinander kommunizieren können. Üblicherweise kommt dabei LSA-Funktechnik zum Einsatz.

Verlässt das Fahrzeug die Haltestelle, sendet es eine Funkmeldung mit der Kennung der Fahrt. Der Anzeiger löscht daraufhin die zugehörigen Informationen zur Fahrt.

Der innerhalb der Schnittstelle zur Fahrtidentifikation benutze Schlüssel (FahrtID) kann dabei in der Regel nicht verwendet werden: Es handelt sich um einen ITCS-internen Schlüssel, der nicht in der Datenversorgung des Fahrzeuges vorliegt.

Um dennoch eine scharfe Abmeldung realisieren zu können, wird in allen relevanten Botschaf- ten eine sogenannte AbmeldeID zur FahrtID mitgesendet. Diese ist im Fahrzeug des anzei- gerbenutzenden Systems bekannt und wird vom Anzeigerbesitzer nach Erhalt dem Anzeiger im Rahmen seiner Fahrplanversorgung bekannt gemacht.

Im Gegensatz zur FahrtID ist die AbmeldeID nur eindeutig auf den Betriebstag des anzeiger- benutzenden Systems. Der Anzeiger muss daher Grenzfälle durch zusätzliche Logik ausglei- chen. So könnte der Anzeiger Fahrten mit gleicher AbmeldeID anhand der Ist-Zeit und der geplanten Abfahrtszeit zuordnen.

VDV 453 Version 3.1.0 - 97 - 23.09.2024

[Seite 100]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Neben der AbmeldeID, die das Fahrzeug, bzw. die Fahrt identifiziert, wird häufig zusätzlich eine Ortsreferenz benötigt, die den Anzeiger definiert, auf dem die Fahrt abgemeldet werden soll. Diese Unterscheidung ist notwendig, wenn sich mehrere Anzeiger im Funkbereich des Fahrzeuges befinden. Für diese Zwecke sollte standardmäßig die AZBID verwendet werden. Kann diese aufgrund von Vorgaben bestehender Systeme nicht verwendet werden (Typ, For- mat, Größe), so muss parallel zur AZBID die im Abmeldeverfahren verwendete Anzeigerrefe- renz des Anzeigerbesitzers in der betrieblichen Datenpflege des Anzeigerbenutzers vorgehal- ten werden (Tabelle 18). Diese muss in Rahmen der Fahrzeugdatenversorgung zusätzlich auf den Bordrechner geladen werden. Es ist daher zu empfehlen, sich bei der Definition der AZBID auf das verwendete, physikalische Datenformat der scharfen Abmeldung abzustützen. An- dernfalls ist zusätzlich betriebliche Datenpflege – wie beschrieben – notwendig.

Tabelle 18 - Datenpflege von Fremdanzeigerreferenzen zur scharfen Abmeldung

6.3.6 Traktionen/Kurswagen/Flügelfahrten

Der Begriff Traktion beschreibt die Verbindung von Einzelfahrten zu einem Verbund. Verbünde können auf der Strecke zusammengeführt oder getrennt werden (Flügelfahrten), können aber auch die gesamte Fahrtroute gemeinsam befahren.

Aus Sicht des Fahrgastes sollen diese Verbünde im Rahmen der DFI je nach Situation als eine Fahrt, bzw. als Einzelfahrten angezeigt werden. Darüber hinaus ist für einige Systeme die Position innerhalb des Verbundes relevant, um die Zielanzeiger je nach Haltesektion mit den jeweiligen Fahrweginformationen der Einzelfahrt zu beschicken.

Um dies zu ermöglichen, wird im Rahmen der DFI-Meldungen eine Referenz auf eine beste- hende Traktion mitgesendet (TraktionsID). Diese ermöglicht es, die Teile eines Verbundes zu identifizieren. Weitere optionale Elemente erlauben es, die Gesamtzahl und die Position der Einzelfahrten zu bestimmen (AnzahlFahrten, Position).

Die Angabe von Traktionsdaten ist optional. Abweichend vom Standardverhalten optionaler Elemente geben anwesende Traktionsdaten einen Hinweis darauf, dass sich eine Fahrt an einem Haltepunkt in einer Traktion befindet.

Das Senden von Traktionsdaten beginnt einschließlich des Haltepunktes, an dem der Verbund gekoppelt wird, und endet einschließlich des Haltepunktes, an dem der Verbund aufgetrennt wird bzw. die Fahrt den Verbund verlässt. Fahrten können Traktionen wechseln und mehrere Traktionen zu einer neuen Traktion vereinigt werden.

VDV 453 Version 3.1.0 - 98 - 23.09.2024

[Seite 101]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.7 Referenzdatendienst (REF-DFI)

6.3.7.1 Datenaustausch

Der Austausch von Solldaten für die DFI dient dem Erstellen von Bezugsdaten innerhalb des datenkonsumierenden Systems (Anzeigerbesitzer). Nicht alle Systeme benötigen solche Be- zugsdaten, um die zugehörigen Prozessdaten verarbeiten zu können. Der Austausch von Re- ferenzdaten für die DFI kann dann entfallen.

Der Referenzdatendienst REF-DFI ist in großen Teilen identisch mit dem Referenzdatendienst REF-ANS. In beiden Fällen geht es um den Austausch von Sollzeiten von Fahrzeugen an einer Fremdhaltestelle/-anzeiger. Unterschiede bestehen in der Nomenklatura (Anzeigerbereich/An- schlussbereich), sowie in der Ausprägung der Daten, die ausgetauscht werden.

6.3.7.1.1 Aktualisierung

Der Anzeigerbesitzer erhält nach Stellen der Anfrage recht zeitnah die Antwort mit den An- kunfts-/Abfahrtszeiten gebündelt in AZBLinienFahrplänen. Ändern sich diese, so werden er- neute DatenBereitAnfragen an den Abbringer gesendet, um anzuzeigen, dass sich die Daten geändert haben.

Als Änderung wird jeweils immer ein kompletter AZBLinienFahrplan übermittelt. Die Ursache ist dabei ohne Belang (Verfügbarkeit neuer Daten, Verstärker, SEV, Umleitungen anderer Li- nien über AZB, ...).

Änderungen der Fahrt selbst (Starthaltestelle, Abfahrtszeit, Transportgefäß, Produkt) bleiben verborgen, bzw. werden im Rahmen des Prozessdatenaustausches kommuniziert. Fahrten, die aufgrund einer dispositiven Maßnahme den Anzeigerbereich nicht mehr erreichen, werden über eine explizite Meldung (AZBMeldungsart="Ausfall") vom Anzeiger entfernt.

Ersatzfahrten für ausfallende Fahrten sollten transparent ausgetauscht werden (Implementie- rungsempfehlung). Hierbei handelt sich also um die gleiche Fahrt mit anderem Fahrzeug.

Aktualisierungen sind serverseitig optional. Clients müssen Aktualisierungen in jedem Fall ent- gegennehmen können.

6.3.7.2 DFI-Referenzdaten anfragen (AboAZBRef)

Das Abonnieren von Fahrplandaten erfolgt über eine AboAnfrage mit einem eingebetteten Element vom Typ AboAZBRef. Das Element AboAZBRef spezifiziert dabei den Anzeigerbe- reich, optionale Filterkriterien sowie den Anfragezeitraum.

VDV 453 Version 3.1.0 - 99 - 23.09.2024

[Seite 102]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Die Struktur Linienfilter ist folgendermaßen definiert:

Das Element FruehesteAbfahrtszeit sollte nicht vor den Beginn des eigenen Datenhorizontes gesetzt werden, SpaetesteAbfahrtszeit nicht nach dem Ende des Horizontes. Das Attribut Ver- fallZst sollte zeitgleich oder später dem Element SpaetesteAbfahrtszeit sein.

Das folgende Beispiel beschreibt eine Referenzdatenanfrage ("ITCS A" ist Anzeigerbesitzer) für den Anzeigerbereich "12345". Es sollen nur Daten der Linie 100 in Richtung "Zoo" geliefert werden. Das anzeigerbesitzende ITCS, welches die Anfrage stellt, hat einen Datenhorizont vom 5:00 Uhr bis 23:00 Uhr, 8.8.2001. Das Fremd-ITCS seinerseits hat nur einen Datenhori- zont bis 22:00 Uhr.

VDV 453 Version 3.1.0 - 100 - 23.09.2024

[Seite 103]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Vom Zubringer erfolgt eine Antwort vom Typ Bestaetigung innerhalb der Botschaft AboAnt- wort. Erst im Zeitfenster (s. Kapitel 6.3.7.3.2) des übermittelten AZBLinienFahrplans wird der eingeschränkte Datenhorizont signalisiert:

6.3.7.3 Linienorientierte DFI-Referenzdaten übermitteln (AZBLinienFahrplan)

Nachdem die Referenzdaten-Abonnements eingerichtet sind (6.3.7.2), ermittelt das anzeiger- benutzende System die Ankunfts-/Abfahrtstafeln am Anzeigerbereich der eigenen Fahrzeuge und signalisiert dies mit der initialen DatenBereitAnfrage-Meldung.

Nach Empfang und Bestätigung der Bereit-Meldung ruft das anzeigerbesitzende System die Daten mit einer DatenAbrufenAnfrage ab.

Das anzeigerbenutzende System beantwortet diese Botschaft mit den gewünschten Daten innerhalb von Elementen vom Typ AZBLinienFahrplan. Dieser wiederum ist Unterelement der sogenannten AZBNachricht (6.3.8.3) und gruppiert pro Linien-Richtungs-Kombination alle An- künfte und Abfahrten (AZBSollFahrt) an einem Anzeigerbereich. Der AZBLinienFahrplan be- inhaltet außerdem die BetreiberID und die Quittierung des abonnierten Zeitbereichs.

Die Ankunfts-/Abfahrtstafeln entstehen durch Zusammenfügen von mehreren Elementen vom Typ AZBLinienFahrplan.

VDV 453 Version 3.1.0 - 101 - 23.09.2024

[Seite 104]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.7.3.1 Einzelne DFI-Ankunfts-/Abfahrtsdaten (AZBSollFahrt) Jeder AZBLinienFahrplan beinhaltet seine Liste von AZBSollFahrt-Elementen.

6.3.7.3.2 Verfügbarkeitshorizont (Zeitfenster)

Da das Ende des Betriebstages des eigenen ITCS in der Regel nicht dem Ende des Betrieb- stages eines Fremd-ITCS gleicht, muss davon ausgegangen werden, dass eine Bereitstellung von Daten nicht für den gesamten Anfragezeitraum erfolgen kann. Damit der Datenkonsument (Anzeigenbesitzer) Kenntnis von dieser Situation erhält, muss im AZBLinienFahrplan zwin- gend mittels der Struktur Zeitfenster bestätigt werden, welcher Teil des abonnierten Zeitberei- ches auch wirklich geliefert werden kann.

Liegt der Anfragezeitraum so weit in der Vergangenheit, dass der Datenlieferant keine Daten des angefragten Zeitbereiches mehr zur Verfügung hat, sendet er entweder keine Daten für dieses Abo oder er quittiert bereits das AboAZBRef mit "notok" und einer Fehlernummer aus dem Bereich 300-399.

Liegt der Anfragezeitraum so weit in der Zukunft, dass der Datenlieferant noch keine Daten des angefragten Zeitbereiches zur Verfügung hat, sendet er vorerst noch keine Daten und liefert sie nach, sobald sie verfügbar sind.

Sobald der Datenlieferant neue Daten zur Verfügung hat, sendet er einen aktualisierten AZ- BLinienFahrplan mit dem möglichst kompletten abonnierten Zeitraum.

VDV 453 Version 3.1.0 - 102 - 23.09.2024

[Seite 105]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.7.3.3 HaltInfoSollMitAusfallGroup

6.3.7.3.4 HaltSollGroup

VDV 453 Version 3.1.0 - 103 - 23.09.2024

[Seite 106]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.7.3.5 Informationen zum Service der Fahrt oder am Halt (ServiceAttribut)

Die Struktur ServiceAttribut kennzeichnet Service-Attribute für die entsprechende Fahrt:

Einzelne Name-Wert-Pärchen werden jeweils für sich aktualisiert. Die Zurücknahme erfolgt durch einen leeren Wert im Name-Wert-Pärchen.

6.3.7.3.6 AbfahrtSollMitAusfallGroup

6.3.7.3.7 AbfahrtSollGroup

VDV 453 Version 3.1.0 - 104 - 23.09.2024

[Seite 107]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.7.3.8 AbfahrtAusfallGroup

6.3.7.3.9 AnkunftSollMitAusfallGroup

6.3.7.3.10 AnkunftSollGroup

VDV 453 Version 3.1.0 - 105 - 23.09.2024

[Seite 108]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.7.3.11 AnkunftAusfallGroup

6.3.8 Prozessdatendienst (DFI)

6.3.8.1 Datenaustausch

Der Austausch von Prozessdaten für die DFI liefert dem Anzeigerbesitzer Informationen über die auf den Anzeiger zulaufende Fahrt eines Fremdunternehmens. Die Bereitstellung von In- formationen erfolgt innerhalb eines gewissen Vorschauzeitfensters. Die Zahl der zu liefernden Fahrtinformationen kann zusätzlich auf die auf dem Anzeiger darstellbare Menge von Informa- tionen begrenzt werden.

Der Ablauf des Datenaustausches gestaltet sich wie in Abbildung 8 dargestellt.

VDV 453 Version 3.1.0 - 106 - 23.09.2024

[Seite 109]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Der Anzeigerbesitzer abonniert zunächst Daten für auf den Anzeiger zulaufende Fahrten be- stimmter Linien und Richtungen (AboAZB). Dabei kann er eine sogenannte Vorschauzeit an- geben, die angibt, wie lange vor Eintreffen oder Abfahrt der Fahrzeuge am Anzeiger mit dem Senden der Fahrplanprognosen begonnen werden soll. Mit Erreichen der Vorschauzeit und bei jeder Änderung werden Fahrplanlagen der zulaufenden oder startenden Fahrzeuge ge- sendet (AZBFahrplanlage). Die Erkennung der Änderung einer Verkehrslage kann wiederum durch Angabe einer Hysterese gesteuert werden. Das Erreichen des Anzeigerbereiches wird ebenfalls als Änderung betrachtet (DatenBereitAnfrage2). Das Senden von Daten für ein Abonnement erfolgt mit dem Erreichen der Vorschauzeit.

Innerhalb des Abonnements wird ebenfalls definiert, wie viele Fahrzeuge maximal gemeldet werden dürfen. So kann die Datenmenge z.B. auf die Zahl von Fahrten beschränkt werden, die ein Anzeiger in der Lage ist darzustellen.

VDV 453 Version 3.1.0 - 107 - 23.09.2024

[Seite 110]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Anzeigerbesitzer Anzeigerbenutzer (Client) (Server)

AboAnfrage1

DatenBereitAnfrage1 Fahrt5 DatenAbrufenAnfrage1

DatenAbrufenAntwort1

tie Ankunftszeit z u a h c s DatenBereitAnfrage2 ro V DatenAbrufenAnfrage2

DatenAbrufenAntwort2

Soll Abfahrtszeit

Fahrweg Haltestelle Fahrt5 Zeitachse

Abbildung 8: Ablauf des Datenaustausches bei der DFI

Das Abonnieren erfolgt frühestmöglich (Beginn des eigenen Betriebstages) und endet mit ihm. Wie bei dem Referenzdatendienst Anschlusssicherung muss davon ausgegangen werden, dass nicht der gesamte Zeitbereich bedient werden kann. Daher erfolgt auch hier eine Rück- meldung in Bestaetigung über das Ende des Zeithorizontes des datenliefernden Systems.

VDV 453 Version 3.1.0 - 108 - 23.09.2024

[Seite 111]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.8.2 DFI-Daten anfragen (AboAZB)

Das Abonnieren von DFI-Daten wird durch den Anzeigerbesitzer initiiert. Er stellt eine AboAn- frage, welche ein Unterelement vom Typ AboAZB enthalten muss.

Der LinienFilter ist optional. Es ist also auch möglich, eine Anfrage gänzlich ohne Filter zu setzen. MaxAnzahlFahrten dient zur Optimierung des Datenverkehrs. Der Anzeigerbesitzer kann damit die Zahl der in einer AZBFahrplanlage zu liefernden Fahrten beschränken. Somit

VDV 453 Version 3.1.0 - 109 - 23.09.2024

[Seite 112]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

kann die Zahl der Meldungen auf die auf dem Anzeiger darstellbare Anzahl von Meldungen beschnitten werden. Es werden diejenigen Fahrten geliefert, die den Anzeigerbereich als nächstes erreichen. Wie bei der zeitbezogenen Anschlusssicherung gilt, dass einmal gesen- dete Fahrplanprognosen für Fahrten auch weiterhin gesendet werden müssen. Zusätzlich dis- ponierter Verkehr kann also dazu führen, dass mehr als die in MaxAnzahlFahrten definierten Fahrplanprognosen versendet werden. Folgende Tabellen verdeutlichen dieses Verfahren:

Tabelle 19 zeigt eine Abfahrtstafel (des Anzeigerbenutzer) der auf den Anzeigerbereich zulau- fenden Fahrten. Sei MaxAnzahlFahrten im Abonnement mit dem Wert 3 definiert. So werden nach Erreichen der Vorschauzeit nur die grau unterlegten Fahrten gemeldet.

Tabelle 19 - Durch MaxAnzahlFahrten beschränkte Abfahrtstafel

Wird nun eine Verstärkerfahrt 566 mit prognostizierter Abfahrtszeit 13:05 disponiert, so "ver- drängt" diese die Fahrt 125 vom dritten Platz. Trotzdem wird die Fahrt 125 weiterhin gesendet (siehe Tabelle 20), da sie bereits kommuniziert wurde.

In einer AZBNachricht können also nun maximal vier AZBFahrplanlagen auftauchen.

Tabelle 20 - Ausnahme der Beschränkung durch Verstärkerfahrt

VDV 453 Version 3.1.0 - 110 - 23.09.2024

[Seite 113]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

Implementierungsempfehlungen:

Sind auf einem Anzeiger feste Bereiche für Linien/Richtungen vorgesehen oder soll jeweils die nächste Fahrt je einer Linie/Richtung angezeigt werden, so sollten die Abonnements linien- /richtungsbezogen aufgesetzt werden.

Wenn der angegebene Hysteresewert nur bei einem Teil der vorher übertragenen Fahrten erreicht oder überschritten worden ist, brauchen nur deren Daten übertragen zu werden.

In folgendem Beispiel sollen Daten für einen Anzeiger (Besitzer ist ITCS A) mit der AZBID "12345" abonniert werden. Es sollen Daten mit einer Vorschauzeit von 30 Minuten gesendet werden. Die Textfelder sollen eine Maximallänge von 30 Zeichen aufweisen (MaxTextLaenge). Der Anzeigerbenutzer soll maximal 3 Fahrten der Linie "M48" in allen Richtungen melden:

Der Anzeigerbenutzer bestätigt die Entgegennahme des:

6.3.8.3 Nachrichten des Anzeigerbenutzers (AZBNachricht)

Liegen Aktualisierungen vor, so antwortet der Anzeigerbenutzer mit dem Erreichen der Vor- schauzeit mit einer sogenannten AZBNachricht. Dieses Element bildet mit Bezug auf ein Abon- nement den Rahmen für Ergebnisse dispositiver Maßnahmen bzw. von Fahrplanlagen.

Folgende Meldungen können innerhalb von AZBNachricht gemeldet werden:

Referenzdatendienst:

• Fahrplandaten (AZBLinienFahrplan)

Prozessdatendienst:

• Prognosen von Fahrplanlagen, Ausfall einer Fahrt, Abfahrt am Anzeiger (AZBFahrplan- lage)

• Erstellen und Löschen eines Linienspezialtextes (AZBLinienspezialtext)

VDV 453 Version 3.1.0 - 111 - 23.09.2024

[Seite 114]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

• Erstellen und Löschen von Sondertexten (AZBSondertext)

Pro AZBNachricht können beliebig viele Unterelemente angeben werden.

6.3.8.3.1 Prognosedaten übermitteln (AZBFahrplanlage)

Mit Erreichen der Vorschauzeit beginnt die Übermittlung aktueller Prognosedaten für eine Fahrt.

Im obigen Beispiel sind dies 30 Minuten bevor das Fahrzeug (Linie 8) den Anzeigerbereich erreicht. Es wird eine initiale Fahrplanprognose vom Anzeigerbenutzer erstellt und zum Abho- len bereit signalisiert (DatenBereitAnfrage). Der Anzeigerbesitzer bestätigt (DatenBereitAnt- wort/Bestaetigung) und fragt die Daten des Abonnements ab (DatenAbrufenAnfrage). Der An- zeigerbenutzer antwortet mit einer zu dem Abo gehörigen AZBNachricht.

Diese gruppiert die zum Abo gehörigen Fahrplanprognosen (AZBFahrplanlage) aller zuführen- den Fahrten.

VDV 453 Version 3.1.0 - 112 - 23.09.2024

[Seite 115]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.8.3.1.1 HaltInfoDfiGroup

VDV 453 Version 3.1.0 - 113 - 23.09.2024

[Seite 116]

Schnittstellenbeschreibung "Fachliche Dienste" VDV 453

6.3.8.3.1.2 HaltGroup

6.3.8.3.1.3 Zusatzinformationen (StoerungsInfo)

Mit der Struktur Stoerungsinfo werden verschiedene Möglichkeiten bereitgestellt, Zusatzinfor- mationen, z.B. über die Ursache einer Störung, zu übermitteln.

Diese Informationen können sowohl in Form von Freitexten wie auch als codierte Informatio- nen, die anschließend automatisch weiterverarbeitet werden können, übertragen werden.

TpegReasonGroup und SituationBaseIdentiyGroup sind Elemente, die im SIRI Situation Exchange Service spezifiziert sind bzw. auf eine Meldung des SIRI Situation Exchange Ser- vice referenzieren.

Hinweis: Diese Struktur ist nur in der Version "mit SIRI" des XML-Schemas enthalten.

6.3.8.3.1.4 AbfahrtDfiGroup