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

[Seite 1]

VDV-Schrift 454

08/2024

Ist-Daten-Schnittstelle – Fahrplanauskunft

Version 3.1.0

auf Basis VDV-Schrift 453 (v3.1.0)

REF-AUS Referenzdaten Fahrplanauskunft

AUS Fahrplanauskunft

Gesamtbearbeitung

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

Ausschuss für Telematik und Informationssysteme (ATI)

[Seite 2]

VDV 454 Version 3.1.0 2 23.09.2024

[Seite 3]

VDV-Schrift 454 08/2024

Ist-Daten-Schnittstelle – Version 3.1.0

REF-AUS Referenzdaten Fahrplanauskunft

AUS Fahrplanauskunft

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

VDV 454 Version 3.1.0 3 23.09.2024

[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.

VDV 454 Version 3.1.0 4 23.09.2024

[Seite 5]

Inhaltsverzeichnis VDV 454

Inhaltsverzeichnis

1 Vorbemerkungen ............................................................................................................. 11 2 Einführung ....................................................................................................................... 13 2.1 Allgemeine Aufgabenstellung .....................................................................................13 2.2 Anforderungen zum Datenaustausch ..........................................................................13 2.2.1 Übermittlung von aktualisierten Planungs- und Betriebsdaten .............................13 2.2.2 Referenzierung der Istdaten.................................................................................14 2.2.3 Solldatenversorgung ............................................................................................14 2.2.4 Definition von einheitlich zu verwendenden Werten .............................................15 3 Einführung und Grundbegriffe ....................................................................................... 16 3.1 Struktur der Schnittstelle .............................................................................................16 3.1.1 Kommunikation- vs. Diensteschicht .....................................................................16 3.1.2 Referenz- vs. Prozessdaten .................................................................................17 3.1.3 Gesteuertes Abonnementsverfahren ...................................................................17 3.2 Datendienst Fahrplanauskunft AUS ............................................................................18 3.2.1 Übersicht .............................................................................................................18 3.2.2 Fachdienste REF-AUS und AUS .........................................................................18 3.2.3 Funktionsumfang REF-AUS .................................................................................20 3.2.4 Funktionsumfang AUS .........................................................................................20 3.2.5 Abgrenzung zum Fachdienst DFI .........................................................................21 3.3 Meta-Daten, Abbildung der Haltestellen und Linien ....................................................22 3.4 Abschätzung der Datenmengen..................................................................................24 3.4.1 Allgemeine Abschätzung der Datenmengen ........................................................24 3.4.1.1 Annahmen ....................................................................................................24 3.4.1.2 Abschätzung der Datenmengen ....................................................................25 3.4.1.3 Übertragungskapazitäten ..............................................................................26 3.4.2 Abschätzung der Datenmengen für Formationsdaten ..........................................27 3.5 Abschätzung der Datenaktualität ................................................................................27 3.6 Zeitformatierung .........................................................................................................28 4 Schnittstellenbeschreibung "Basisinfrastruktur" ......................................................... 29 4.1 Vorbemerkung ............................................................................................................29 4.2 Abonnement-Verfahren ..............................................................................................29 4.3 Protokolle ...................................................................................................................30 4.4 Dienstekennung/Anfrage-URL ....................................................................................30 4.5 Wiederverwendete Datentypen ...................................................................................31 4.6 Nutzung der optionalen Felder ....................................................................................32 4.6.1 Richtlinie zur Definition von optionalen Elementen ...............................................33 4.7 Generischer Verarbeitungsprozess im Auskunftssystem ............................................33 4.7.1 Standard-Verarbeitungsreihenfolge .....................................................................34 4.7.2 Hierarchie der Elemente ......................................................................................34 4.7.3 Aktualisierungsregeln für Auskunftssysteme ........................................................37 5 Fachliche Dienste ............................................................................................................ 40

VDV 454 Version 3.1.0 5 23.09.2024

[Seite 6]

Inhaltsverzeichnis VDV 454

5.1 Solldatendienst REF-AUS ...........................................................................................40 5.1.1 Fahrplandaten-Anfrage (AboAUSRef) ..................................................................40 5.1.1.1 Beschränkung der Daten nach Zeitbereich (Zeitfenster) ...............................43 5.1.1.2 Beschränkung der Daten nach Linien (LinienFilter) .......................................44 5.1.1.3 Beschränkung der Daten nach Betreibern (BetreiberFilter) ...........................44 5.1.1.4 Beschränkung der Daten nach Produkten (ProduktFilter) .............................45 5.1.1.5 Beschränkung der Daten nach VerkehrsmittelIDs (VerkehrsmittelIDFilter) ....45 5.1.1.6 Beschränkung der Daten nach HaltIDs (HaltFilter) ........................................46 5.1.2 Daten übermitteln (AUSNachricht) .......................................................................47 5.1.3 Linienorientierte Fahrplandatenübermittlung (LinienFahrplan) .............................48 5.1.3.1 Einzelfahrtdaten (SollFahrt) ...........................................................................51 5.1.3.2 Informationen zum Halt (SollHalt) ..................................................................55 5.1.3.2.1 HaltInfoSollGroup ...................................................................................55 5.1.3.2.2 Geplante Anschlüsse (SollAnschluss) ....................................................55 5.1.3.3 Informationen zu betrieblichen Fahrtidentifikatoren (BetrieblicheFahrtnummern) .....................................................................................57 5.1.3.3.1 BetrieblicheFahrtnummerFahrtAbschnitt ................................................58 5.1.3.4 Informationen zur Formation der SollFahrt (SollFormation) ...........................59 5.1.3.5 Übermittlung der Zeitfenster, Erstmeldung, Aktualisierungen ........................60 5.1.3.5.1 Übermittlung des abonnierten Zeitfensters .............................................61 5.1.3.5.2 Zusätzliche Übermittlung von Zeitfenstern mit disponierten Fahrten .......63 5.1.4 Übermittlung disponierter Fahrten Tage im Voraus ..............................................64 5.2 Istdatendienst AUS .....................................................................................................66 5.2.1 Ist-Daten Anfrage (AboAUS) ................................................................................66 5.2.2 Ist-Daten übermitteln............................................................................................68 5.2.2.1 Istdaten einer Fahrt (IstFahrt) ........................................................................69 5.2.2.1.1 Originalsollfahrtverlauf (OriginalSollFahrtverlauf) ...................................73 5.2.2.1.2 OriginalSollHalt ......................................................................................73 5.2.2.2 Referenzierung der Fahrtdaten (FahrtRef) ....................................................73 5.2.2.2.1 Alternative Referenzierungsinformation (FahrtStartEnde).......................74 5.2.2.3 Informationen zum Halt (IstHalt) ....................................................................76 5.2.2.3.1 AbfahrtAusGroup ...................................................................................76 5.2.2.3.2 AbfahrtStatusGroup ................................................................................77 5.2.2.3.3 AnkunftAusGroup ...................................................................................77 5.2.2.3.4 AnkunftStatusGroup ...............................................................................78 5.2.2.4 Formation der IstFahrt (IstFormation) ............................................................78 5.2.2.4.1 Fahrzeuge der Formation (FoFahrzeuge) ...............................................79 5.2.2.4.2 FremdFahrzeuge der Formation (FoFremdFahrzeuge) ..........................83 5.2.2.4.3 Fahrzeuggruppen der Formation (FoFahrzeugGruppen) ........................84 5.2.2.4.4 Fahrtabschnitte für Fahrzeuggruppen (FoFahrzeugGruppenFahrtAbschnitte) ..................................................................87 5.2.2.4.5 Fahrtabschnitte für Fahrzeugausstattungen (FoFahrzeugAusstattungFahrtAbschnitte) .............................................................93 5.2.2.4.6 FahrtAbschnitte für FahrzeugZustände (FoFahrzeugZustandFahrtAbschnitte) ...................................................................95

VDV 454 Version 3.1.0 6 23.09.2024

[Seite 7]

Inhaltsverzeichnis VDV 454

5.2.2.4.7 FahrtAbschnitte für FahrzeugBelegungen (FoFahrzeugBelegungFahrtAbschnitte) ................................................................96 5.2.2.4.8 Formationen am Halt (FoHalte) ..............................................................99 5.2.2.5 Mehrfach verwendete Element-Strukturen innerhalb der IstFormation ........ 114 5.2.2.5.1 Beschreibung von Abschnitt (FoAbschnitt) ........................................... 114 5.2.2.5.2 Beschreibung von Änderungen gegenüber dem Soll (FoAenderungen) ........................................................................................................................... 116 5.2.2.5.3 Beschreibung von Zuständen (FoZustand) ........................................... 117 5.2.2.5.4 Beschreibung struktureller Einstiegspunkte für Erweiterungen (FoErweiterung) .................................................................................................. 119 5.2.2.6 Referenz auf weitere beteiligte Fahrten (FahrtBeziehung)........................... 119 5.2.2.6.1 Beziehungen zwischen Fahrten (BeziehungsTypen) ............................ 121 5.2.2.6.2 Beziehung zu einer Strecke (Streckenbezug) ....................................... 135 5.2.2.6.3 Beziehung zu Fahrt (BeziehungZuFahrt) .............................................. 135 5.2.2.6.4 Beispiel Streckensperre ....................................................................... 135 5.2.2.6.5 Beispiel Fahrzeugersatz ....................................................................... 138 5.3 Gesicherte Anschlussbeziehungen ........................................................................... 141 5.3.1 Anschlussdatenübermittlung (GesAnschluss) .................................................... 141 5.3.2 Planungdaten einer Anschlussbeziehung (AnschlussPlan) ................................ 141 5.3.2.1 Zu- und Abbringerfahrtinformationen (Zubringer, Abbringer) ....................... 142 5.3.3 Statusdaten einer Anschlussbeziehung (AnschlussStatus) ................................ 142 5.3.3.1 Information über die Abbringerzurückhaltung (WarteInfo) ........................... 143 5.4 Übermittlung von Formationsinformationen .............................................................. 143 5.5 Übermittlung von Fahrtverbänden (Verbinden von VM-Fahrten) ............................... 144 5.5.1 Anwendungsbeispiele ........................................................................................ 145 5.5.1.1 "Flügelbetrieb" ............................................................................................. 145 5.5.1.2 FahrtVerband, FahrtVerbandsAbschnitt und FahrtInAbschnitt ..................... 147 5.5.1.3 "Verstärkung" und "Schwächung" ............................................................... 148 6 Handhabung des Ist-Datendienstes AUS .................................................................... 149 6.1 Implementierungshinweise und Regelungen ............................................................ 149 6.1.1 Prognosekompetenz des ITCS .......................................................................... 149 6.1.2 Ergänzungsregel zum Verspätungsprofil............................................................ 150 6.1.3 Beispiel "Durchfahren an einer Haltestelle" (Attributänderung) .......................... 156 6.1.4 Beispiel "Bedienung einer Bedarfsverkehrshaltestelle" ...................................... 158 6.1.5 Beispiel "Fahrwegänderung" .............................................................................. 158 6.1.6 Erstmeldung und Vorschauzeit .......................................................................... 161 6.1.7 Zeitliches Meldeverhalten - Hysterese ............................................................... 164 6.1.8 Rücknahme der Prognosen/Rücksetzung der Fahrt ........................................... 165 6.1.9 Tatsächliche Ankunfts- und Abfahrtszeiten ........................................................ 165 6.1.9.1 Tatsächliche Ankunfts- und Abfahrtszeiten ................................................. 166 6.1.9.2 Geschätzte und prognostizierte Ankunfts- und Abfahrtszeiten .................... 166 6.1.10 Fahrtausfälle .................................................................................................... 167 6.1.11 Zusätzliche Fahrten ......................................................................................... 168 6.1.12 Implementierung bei Bahnanwendungen ......................................................... 168 6.1.13 Sicherstellung plausibler Prognosen ................................................................ 168

VDV 454 Version 3.1.0 7 23.09.2024

[Seite 8]

Inhaltsverzeichnis VDV 454

6.2 Anschlussinformationen ............................................................................................ 169 6.2.1 Situationsbeschreibung ...................................................................................... 169 6.2.2 Anwendungsfälle ............................................................................................... 169 6.2.3 Anschlussinformationen im Fahrplanauskunftssystem ....................................... 170 6.2.4 Nachrichteninhalte ............................................................................................. 171 6.2.5 Sitzenbleiber ...................................................................................................... 172 7 Glossar ........................................................................................................................... 173 8 Englische Alias-Bezeichner .......................................................................................... 175 8.1 Dienste ..................................................................................................................... 175 8.2 Root-Elemente und komplexe Subelemente ............................................................. 175 8.3 Weitere Elemente ..................................................................................................... 176 9 Anhang: Werte Listen (ENUM) ...................................................................................... 178 9.1 FoFahrzeugTyp ........................................................................................................ 178 9.2 FoFahrzeugAusstattungsCode ................................................................................. 178 9.3 Sprachcode .............................................................................................................. 180 9.4 FoTechnischesAttributCode ...................................................................................... 180 9.5 FoAenderungsCode & FoAenderungsCodeAmHalt .................................................. 181 9.6 FoZustandsCode ...................................................................................................... 182 9.7 FoOrientierung .......................................................................................................... 183 9.8 FoFahrtrichtung ........................................................................................................ 183 10 Anhang: XML Beispiele ............................................................................................... 184 10.1 Beispiel für die Übertragung von Formationen (IstFahrt) ......................................... 184 10.2 Hinweis für den ITCS-Anwender ............................................................................. 185

VDV 454 Version 3.1.0 8 23.09.2024

[Seite 9]

Inhaltsverzeichnis VDV 454

VDV 454 Version 3.1.0 9 23.09.2024

[Seite 10]

Inhaltsverzeichnis VDV 454

VDV 454 Version 3.1.0 10 23.09.2024

[Seite 11]

Inhaltsverzeichnis VDV 454

VDV 454 Version 3.1.0 11 23.09.2024

[Seite 12]

Inhaltsverzeichnis VDV 454

VDV 454 Version 3.1.0 12 23.09.2024

[Seite 13]

Inhaltsverzeichnis VDV 454

Änderungshistorie von V 3.0 zu 3.1

VDV 454 Version 3.1.0 13 23.09.2024

[Seite 14]

Inhaltsverzeichnis VDV 454

VDV 454 Version 3.1.0 14 23.09.2024

[Seite 15]

Inhaltsverzeichnis VDV 454

VDV 454 Version 3.1.0 15 23.09.2024

[Seite 16]

Inhaltsverzeichnis VDV 454

VDV 454 Version 3.1.0 16 23.09.2024

[Seite 17]

Vorbemerkungen VDV 454

1 Vorbemerkungen

Diese VDV-Schrift beschreibt einen zusätzlichen Fachdienste zur Fahrplanauskunft auf der Grundlage der in der VDV-Schrift 453 beschriebenen Kommunikationsstruktur.

Die grundlegende Schrift VDV453 verfolgt den Ansatz, eine universelle Schnittstelle zum Aus- tausch von Ist-Daten zu schaffen, die es den anwendenden Verkehrsunternehmen erlaubt, eine solche Funktionalität zu vertretbaren Kosten zu realisieren. Die technische Umsetzung basiert dabei auf Standardtechnologien (http/XML). Es werden einheitliche Rahmenanforde- rungen an die Gestaltung der Schnittstelle definiert und der Datenaustausch detailliert be- schrieben (Abonnement-Verfahren).

Zusammen mit den hier spezifizierten Schnittstellen werden insgesamt folgende betriebsüber- greifende Fachdienste ermöglicht:

Tabelle 1 – Übersicht der Dienste

Die Ausgangsschrift VDV454 entstand auf Basis eines Vorschlags, der unter Federführung des FAW Ulm von den Partnern des BMBF-geförderten Projekts RUDY erstellt wurde.

Diese Dokumentation wiederholt nicht die in VDV453 dargelegte Grundkommunikation, son- dern wird lediglich auf wichtige Teile referenzieren.

Als Referenz für die Implementierung der Dienste gilt jeweils das aktuelle XML-Schema (siehe VDV-Internetseite https://www.vdv.de/i-d-s-downloads.aspx),

Der Text der VDV-Schrift ist als als ergänzende, ausführliche Erläuterung für die jeweilige An- wendung der XSD-Schemata zu verstehen. Sollte es Widersprüche zwischen Text und XSD- Schema geben, gilt das Schema.

VDV 454 Version 3.1.0 11 23.09.2024

[Seite 18]

Vorbemerkungen VDV 454

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.

Bei Nutzung der Formation sind die Versionen 3.0 und 3.1 nicht kompatibel.

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.

Eine Weitergabe von Meldungen für Folgetage mit REF-AUS wurde ermöglicht.

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

Der AUS-Dienst kann auf Grund des technischen Fortschritts mit der Version 3 auch für An- zeigen mit haltestellenbezogener Fahrplaninformationen genutzt werden. Damit können In- konsistenzen von Anzeigern und Auskunftssystemen eliminiert werden.

Überarbeitung der Formationen zur Übertragung der Auslastungsstufe gemäß der Mobilitäts- datenverordnung und auch differenzierbar nach Ausstattungsmerkmalen.

VDV 454 Version 3.1.0 12 23.09.2024

[Seite 19]

Einführung VDV 454

2 Einführung

2.1 Allgemeine Aufgabenstellung

Ein Fahrplanauskunftssystem muss Kundenanfragen zu Abfahrtszeiten, Ankunftszeiten und Verbindungen mit unterschiedlichen zeitlichen Planungshorizonten befriedigen:

• Langfristig: "Wie plane ich meine Reise nächste Woche nach X?"

• Mittelfristig: "Wie komme ich heute Abend am besten in die Oper?"

• Kurzfristig: "Wann fährt der nächste Bus an der Haltestelle gegenüber ab?

In der Regel stehen dem Auskunftssystem für alle Anfragehorizonte lediglich die für längere Zeitperioden gültigen und veröffentlichten Sollfahrpläne zur Verfügung. Zum Zwecke einer län- gerfristigen Reiseplanung stellen diese Daten die Grundlage dar. Eine Berücksichtigung der betriebstäglichen Änderungen in der Fahrplanung sowie von Ereignissen des gerade ablau- fenden Betriebsgeschehens in der Auskunft ist auf Basis dieser langfristigen Daten allerdings nicht möglich. Es ist daher offensichtlich, dass die Auskunftsqualität bei mittel- und kurzfristi- gen Anfragen durch eine erhöhte Datenaktualität erheblich verbessert werden kann. Für mit- telfristige Auskünfte sollte der für den Betriebstag gültige Fahrplan übertragen werden und für kurzfristige Auskünfte die aktuellen Fahrplandaten.

Aktuelle betriebstägliche Solldaten, wie gegenüber dem langfristigen Fahrplan zusätzliche Fahrten oder Streichungen, werden in der betrieblichen Fahrplanung erstellt und in das Rech- nergestützte Betriebsleitsystem (ITCS) vor Betriebsbeginn eingespielt (z. B. Dienst REF-AUS). Ist-Informationen aus dem Betriebsgeschehen wie aktuelle Verspätungen, Fahrtausfälle oder kurzfristig notwendige Dispositionen auf Grund von Störungen liegen hingegen nur im ITCS vor und werden durch den Dienst AUS bereitgestellt.

2.2 Anforderungen zum Datenaustausch

2.2.1 Übermittlung von aktualisierten Planungs- und Betriebsdaten

Innerhalb des Gültigkeitszeitraums eines normalen Periodenfahrplans, den das Fahrplanplan- auskunftssystem besitzt, werden durch die folgenden Stellen kundenrelevante Änderungen vorgenommen:

• Betriebliche Fahrplanung In der betriebstäglichen Fahrplanung werden ausschließlich Sollfahrplandaten erzeugt, die a priori zum Betriebstag relativ zeitunkritisch übertragen werden können. Sie können also als Referenzdaten herangezogen werden.

• Betriebsleitzentrale

VDV 454 Version 3.1.0 13 23.09.2024

[Seite 20]

Einführung VDV 454

In der ITCS-Zentrale werden kurzfristige Fahrplanprognosen errechnet oder kurzfristig wirksame Dispositionsmaßnahmen festgelegt. Hierbei handelt es sich um Ist-Daten aus dem Prozessgeschehen (Prozessdaten).

Dem Auskunftssystem müssen also Änderungsdaten zweier Quellen kommuniziert werden. Der tägliche Betriebsfahrplan liegt nicht nur in der Fahrplanung, sondern auch in der ITCS- Zentrale vor. Umgekehrt ist es sehr unüblich, dass Disponentenänderungen aus dem ITCS wieder ins Planungssystem oder eine periphere Schicht zum ITCS zurückgespielt werden.

Darüber hinaus haben beide Datensätze einen unterschiedlichen Zeithorizont ihrer Wirksam- keit. Weiter müssen die Solldaten aufgrund ihrer Funktion als Referenz für die Ist-Daten im Auskunftssystem anders gehandhabt werden (s. u.). Es ist daher sinnvoll, die Daten der be- trieblichen Fahrplanung und die Ist-Daten deutlich getrennt voneinander zu übertragen.

2.2.2 Referenzierung der Istdaten

Zur Erzeugung einer aktualisierten Information muss das Auskunftssystem stets unter zeitkri- tischen Bedingungen die online übermittelten Ist-Daten auf seinen Solldatenbestand beziehen und einordnen. Dies beinhaltet:

a) Fahrtidentifikation b) Differenzbildung: Feststellen, ob und was sich geändert hat

Ausschlaggebend für eine exakte Referenzierbarkeit ist, dass die übertragenen Ist-Daten auf die dem Auskunftssystem bereits vorliegenden Solldaten abgestimmt sind. Die Qualität der dynamischen Auskunft ist hiervon enorm abhängig, wie Erfahrungen mit Realisierungen sol- cher Schnittstellen belegen. Oft treten bei einem nicht zu vernachlässigenden Prozentsatz der Fälle Schwierigkeiten bei der Abbildung der Ist- auf die Solldaten auf, die analysiert und im Laufe des Projektes behoben werden müssen.

2.2.3 Solldatenversorgung

In Bezug auf die Solldatenversorgung existieren in der Realität unterschiedliche Gegebenhei- ten, die im Folgenden typisiert dargestellt werden:

• Identischer Datenbestand (Idealfall) ITCS und Auskunftssystem besitzen eine gemeinsame Grunddatenversorgung mit dem Periodenfahrplan. Durch proprietäre update-Mechanismen werden auch Entscheidungen, die den folgenden Betriebstag beeinflussen, kommuniziert.

• Partiell identischer Datenbestand ITCS- und Auskunftssystem besitzen lediglich einen gemeinsamen Stand des Perioden- fahrplans. Weitere Aktualisierungen werden normalerweise nicht vorgenommen.

VDV 454 Version 3.1.0 14 23.09.2024

[Seite 21]

Einführung VDV 454

• Inkonsistente Quellenlage Das Auskunftssystem kann nicht sicher sein, im Besitz eines identischen Perioden- und betriebstäglichen Sollfahrplans des ITCS-Schnittstellenpartners zu sein. Diese Inkonsis- tenz ist bedingt durch organisatorische Randbedingungen wie geographische Überlappun- gen, mehrere Zuständigkeiten zwischen Betrieben und Verbünden, Verbindungsprobleme oder anderem. Darüber hinaus können technische Umstände eine Konsistenz der Daten- grundlagen erschweren: In der Regel werden in der Fahrplanung, im ITCS und im Aus- kunftssystem unterschiedliche IDs verwendet. Dieses Referenzierungsproblem wird durch die Aufstellung von Konversionstabellen gelöst (siehe Abschnitt 3.3 ), die allerdings per- manenter Pflege bedürfen.

Vor dem Hintergrund der Bedeutung abgestimmter Sollfahrplandaten als Referenz resultieren für diese Fälle unterschiedliche Forderungen an den Solldatenaustausch:

Tabelle 2

2.2.4 Definition von einheitlich zu verwendenden Werten

Zur Vermeidung von unnötigen Daten-Mappings zwischen den Partnern sowie zur Gewähr- leistung der Durchgängigkeit und Konsistenz der Daten ist es sinnvoll, als Empfehlung für be- stimmte Elemente Wertelisten zu führen, die in allen Systemen möglichst einheitlich zur An- wendung kommen.

Die betroffenen Elemente sind in den einzelnen Kapiteln im Anschluss an ihre Bezeichnung mit dem Zusatz "[WL]" sowie einem Verweis auf die jeweilige Werte-Liste gekennzeichnet.

Die einzelnen Wertelisten können im Anhang der vorliegenden Schrift eingesehen werden (s. Anhang: Werte Listen, Kapitel 9 ).

VDV 454 Version 3.1.0 15 23.09.2024

[Seite 22]

Einführung und Grundbegriffe VDV 454

3 Einführung und Grundbegriffe

3.1 Struktur der Schnittstelle

3.1.1 Kommunikation- vs. Diensteschicht

Die Schnittstelle besteht aus zwei Schichten (Abbildung 1: Gesamtarchitektur).

• Kommunikationsschicht

• Schicht der fachlichen Dienste

Abbildung 1: Gesamtarchitektur

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.

VDV 454 Version 3.1.0 16 23.09.2024

[Seite 23]

Einführung und Grundbegriffe VDV 454

3.1.2 Referenz- vs. Prozessdaten

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

• Referenzdaten (Soll-Daten)

• Prozessdaten (Ist-Daten)

Der Austausch von Referenzdaten dient in den Diensten der VDV453 (ANS, DFI) zur Grund- datenversorgung für den nachfolgenden Prozessdatenaustausch.

Der Austausch von Referenzdaten stellt damit eine Alternative zu einem Austausch von Daten auf Ebene der Datenpflege dar. Die Implementierung und Verwendung eines Referenzdaten- dienstes ist also vom Anwendungsfall sowie von den technisch-betrieblichen Voraussetzun- gen abhängig. Jeder fachliche Dienst kann somit aus zwei technischen Diensten bestehen. Der Prozess- und Referenzdatenaustausch werden innerhalb der Schnittstelle jeweils als ei- genständige, technische Dienste realisiert.

Der Referenzdatendienst (REF-AUS) aktualisiert durch den Austausch tagesaktueller Fahr- pläne den im Auskunftsdienst vorliegenden Periodenfahrplan um angepasste Planungsdaten, womit die Auskunftsqualität bereits erhöht werden kann, auch dann, wenn aus Störungsgrün- den keine Ist-Daten bereitgestellt werden können.

3.1.3 Gesteuertes Abonnementsverfahren

Dies bedeutet zuerst eine beidseitige Steuerungsmöglichkeit des Datenverkehrs. Hier kann das Abonnementverfahren seine Stärken bei Handling der Übertragung großer Datenmengen (Segmentierung, Limitierung) ausspielen. Die durch das Abonnementverfahren auch gege- bene Selektionsmöglichkeit interessierender Daten aus großen Mengen, ist im Gegensatz zu den Fachdiensten zur Anschlusssicherung und DFI bei der Schnittstelle zum Auskunftssystem sekundär, da die Betreiber von Auskunftssystemen in der Regel an allen verfügbaren aktuellen Daten interessiert sind (außer sie beziehen Daten von sich überlappenden Quellsystemen).

Weiter lassen sich die Schnittstellen in bestehende Konfigurationen der technischen Anlagen integrieren. Eine modulare Ausgestaltung und damit schrittweise Realisierung der angestreb- ten Ziele ist prinzipiell möglich. Dies erweist sich als Kostenvorteil für die ITCS-Betreiber, die eine bereits für die Dienste der ITCS-Kopplung vorhandene Infrastruktur für REF-AUS und AUS mitnutzen können und hierfür keine Neuimplementierung benötigen und auch im Betrieb kein vollkommen andersartiges Handling praktizieren müssen. Bei Fahrplanauskunftssyste- men ist die Kommunikationsinfrastruktur allerdings neu zu installieren. Kostenvorteile ergeben sich jedoch auch hier durch die Mehrfachverwendbarkeit für viele Datenquellen. Die in dieser Schrift beschriebene Schnittstelle ermöglicht es, dass mehrere ITCS mit mehreren Auskunfts- systemen gleichzeitig Daten austauschen können und umgekehrt (m-zu-n-Beziehung).

Das Aufsetzen der benötigen Basiskommunikation nach dem Abonnementverfahren wird in Abschnitt 4.2 behandelt. Um dem Auseinanderlaufen des Standards vorzubeugen, referenziert dieses Dokument in seinen Erläuterungen lediglich auf VDV453 und beschreibt die Methodik somit nicht neu.

VDV 454 Version 3.1.0 17 23.09.2024

[Seite 24]

Einführung und Grundbegriffe VDV 454

3.2 Datendienst Fahrplanauskunft AUS

3.2.1 Übersicht

Mit dieser Schrift wird eine Schnittstelle zwischen Rechnergestützten Betriebsleitsystemen (ITCS) und Auskunftssystemen zur weitgehend automatischen Übermittlung aktueller Fahr- plan- und Betriebslagedaten beschrieben.

Sie ist als fachdienstliche Erweiterung der ITCS-Integrationsschnittstelle nach VDV453 aus- gelegt und besteht aus zwei aufeinander abgestimmten Teildiensten:

REF-AUS: Fahrplanauskunft Soll-Datendienst (Referenz für AUS) tagesaktuelle Soll-Fahrpläne für mittelfristige Auskünfte (Betriebstag)

AUS: Fahrplanauskunft Ist-Datendienst Ist-Daten aus dem Betriebsgeschehen für kurzfristige Auskünfte

Die beiden Dienste REF-AUS und AUS werden als Module auf der Kommunikationsinfrastruk- tur nach dem Abonnementverfahren realisiert und stellen somit im Sinne der VDV453 ergän- zende fachliche Dienste im Rahmen der allgemeinen Basisinfrastruktur dar. Sie passen sich in das Gesamtkonzept der ITCS-Universalschnittstelle ein und besitzen daher alle Vorteile dieser neuen Technik.

Die gemeinsame Architektur der VDV453 und VDV454 stellt sich, wie in Abbildung 1: Gesamt- architektur gezeigt, dar. Der Auskunftsdienst kann unabhängig von den fachlichen Diensten der VDV453 implementiert werden. Er stellt also ebenfalls ein eigenständiges Implementie- rungsmodul im Sinne der VDV-Schnittstellenarchitektur dar.

3.2.2 Fachdienste REF-AUS und AUS

Die Funktionalitäten der beiden Dienste REF-AUS und AUS wurden aufeinander abgestimmt entwickelt. REF-AUS transportiert die Sollfahrplandaten (Betriebstag), AUS die Ist-Daten der Betriebslage. Beide Fachdienste können aus technischer Sicht einzeln eingesetzt werden, aus fachlicher Sicht s. Kapitel 2.2.3 .

Der Referenzdatendienst (REF-AUS) kommuniziert die Daten aus der betrieblichen Fahrpla- nung, der Prozessdatendienst (AUS) die Ist-Daten und Dispositionen aus dem aktuellen Be- triebsgeschehen der ITCS-Zentrale. Wenn der Betriebsfahrplan laufend aktualisiert wird, kön- nen der Referenzdatendienst und der Prozessdatendienst parallel zum Tagesbetrieb mitlau- fen. Beim Referenzdatendienst ist dies insbesondere für die Übermittlung zusätzlicher dispo- nierter Fahrten empfehlenswert (s. Kapitel 5.1.3.5.2 ).

Beide Dienste nehmen sowohl Streichungen als auch den Einsatz zusätzlicher Fahrten oder Änderungen von Fahrten und deren Attributen vor. Da das Auskunftssystem typischerweise nur die für den Fahrgast relevanten Fahrtanteile kennt, darf das ITCS dem Auskunftssystem

VDV 454 Version 3.1.0 18 23.09.2024

[Seite 25]

Einführung und Grundbegriffe VDV 454

auch nur die produktiven Anteile übermitteln. Andernfalls würden in der Fahrplanauskunft Ver- kehre angeboten, bei denen keine Fahrgastbeförderung stattfindet.

Abbildung 2: Einsatzbereich von REF-AUS und AUS

Die funktionale Systemarchitektur mit den beiden Schnittstellen REF-AUS und AUS zeigt Ab- bildung 2.

REF-AUS kann für sich eingesetzt werden, falls den Anwendungspartnern eine betriebstägli- che Aktualität des Auskunftssystems genügt.

Der Fachdienst AUS ist technisch ebenfalls unabhängig von REF-AUS ausgelegt, so dass projektbezogen bei idealer Solldatenversorgung, oder wenn ausschließlich Ist-Daten aus dem Betriebsgeschehen für kurzfristige Auskünfte benötigt werden, auch auf REF-AUS verzichtet werden kann.

In der Regel wird REF-AUS für den Dienst AUS jedoch die Funktion übernehmen, die Sollda- tengrundlage zur Referenzierung zu verbessern und damit die Qualität der dynamischen Aus- künfte zu sichern. Die Qualität der Referenzdatenversorgung des Auskunftssystems ist von den eingesetzten Systemen und organisatorischen Gegebenheiten abhängig und muss pro- jektbezogen geprüft werden. Aus Sicht der Systempartner wird eine Anwendung von REF- AUS dringend empfohlen.

Für die Übermittlung von betrieblichen Freitext-Meldungen wird auf den Allgemeinen Nach- richtendienst der VDV453 verwiesen bzw. auf die VDV736, die insbesondere auch die Bereit- stellung von fahrgastrelevanten Störungsinformationen beinhaltet. Insgesamt trägt die Ausge- staltung des Fachdienstepaars REF-AUS und AUS der Vielgestaltigkeit der praktischen

VDV 454 Version 3.1.0 19 23.09.2024

[Seite 26]

Einführung und Grundbegriffe VDV 454

Randbedingungen der Anwendungspartner Rechnung. Dadurch sind die technischen Voraus- setzungen für eine weite Verbreitung gegeben.

3.2.3 Funktionsumfang REF-AUS

Im Referenzdatendienst REF-AUS wird die Aktualisierung des tagesaktuellen Sollfahrplanes im ITCS gegenüber dem im Auskunftssystem vorliegenden Periodenfahrplans (Jahresfahrpla- nes) kommuniziert. Es ist optional auch möglich, nicht nur den Betriebsfahrplan des aktuellen Tages zu übermitteln, sondern auch disponierte Fahrten, die erst an späteren Tagen stattfin- den werden (s. Kapitel 5.1.4 ).

Hinweis: Als Konsequenz aus der Streichung der FahrplanversionsID können REF-AUS Daten nicht als differenzielle Datenlieferungen betrachtet werden, da das Auskunftssystem nicht fest- stellen kann, ob die Datenlieferungen der ITSC Systeme auf der gleichen Version des Perio- denfahrplanes beruhen, wie der des Auskunftssystems. Ohne eine eindeutige Referenzver- sion und gemeinsame Fahrplanbasis, sind die übertragenen Änderungen zum Periodenfahr- plan nicht verlässlich und können in Folge zu einer fehlerhaften und inkonsistenten Kundenin- formation führen.

Der Referenzdatenaustausch erfolgt daher immer vollständig im Rahmen der Abodefinition und mit Hilfe des LinienFahrplans.

Beim vollständigen Datenaustausch wird der komplette Tagessollfahrplan (Im Rahmen der Abodefinition) in Form von nach Richtungen aufgetrennten, vollständigen Linienfahrplänen zum Auskunftssystem übertragen. Dieser LinienFahrplan aktualisiert die Planungsdaten aus dem Periodenfahrplan.

Wird für eine Linie kein LinienFahrplan übertragen, so ist in diesem Zeitraum kein Tagesfahr- plan für die Linie verfügbar und es gilt für die betreffenden Fahrten weiterhin der Periodenfahr- plan (Jahresfahrplan).

Der Solldatendienst REF-AUS aktualisiert nicht nur die Daten des Auskunftssystems, sondern schafft zugleich ein Referenzierungssystem, durch das die folgenden Ist-Daten leichter und schneller in den Gesamtdatenbestand des Auskunftssystems eingepflegt werden können.

3.2.4 Funktionsumfang AUS

Der Ist-Datenaustausch aktualisiert den Tagessollfahrplan um Informationen, die sich kurzfris- tig aus der verkehrlichen oder betrieblichen Situation ergeben. Es handelt sich dabei um fahrt- bezogene Informationen. Diese können Ergebnisse der verkehrlichen Lage (Verspätungen, Stau) oder dispositiver Maßnahmen sein (Umleitung, Verstärker, Wende). Ergebnisse dispo- sitiver Maßnahmen werden betrieblich als kurzfristige Planungsdaten verstanden, werden aber innerhalb der Prozessdatenschnittstelle übermittelt.

Dabei gilt, dass die Informationshoheit beim ITCS verbleibt. So werden z.B. keine Verspätun- gen, sondern Prognoseprofile ausgetauscht.

VDV 454 Version 3.1.0 20 23.09.2024

[Seite 27]

Einführung und Grundbegriffe VDV 454

Generell gilt folgende Gültigkeitsreihenfolge bei der Auswertung der zur Verfügung stehenden Informationen:

• Prozessdaten

• Referenzdaten

• Periodenfahrplandaten

Neben der Ergänzung um reine Ist-Daten (z.B. Fahrplanlage) "überschreibt" der Prozessda- tendienst also Planungsdaten (z.B. Fahrwegänderungen) aus dem Referenzdatendienst bzw. aus dem Periodenfahrplan, wenn der Referenzdatenaustausch nicht vorgenommen wurde.

Konkret handelt es sich dabei um:

• Erstmeldung (einschließlich neuer Planungs- und Prognosezeiten)

• Ausfall einer Fahrt, zusätzliche Fahrt

• Änderung des Fahrwegs, Haltestellensperrung

• Änderung des Transportgefäßtyps/Fahrzeugausstattung

• Gleis-/Steigänderung

• Fahrplanabweichungen (Verspätung/Verfrühung) bei Überschreiten eines Schwellwerts, haltestellenscharf spezifisch

• Stausituation

• Fahrzeugauslastung

• Änderungen von Attributen (Durchfahrt, Ausstiegsverbot, Einsteigeverbot FahrradMit- nahme, Zusatzfahrt, Zusatzhalt, FahrtspezialText, etc.)

• Formationen einer Fahrt (Fahrzeuggruppierung, Fahrzeugbelegung, Fahrzeugausstat- tung und Zustände, Fahrzeugposition am Halt)

3.2.5 Abgrenzung zum Fachdienst DFI

Für Auskunftssysteme ist es wichtig, dass die Ist-Datenlage nicht nur für einzelne Haltestellen, Anschluss- oder Anzeigebereiche vorliegt, sondern möglichst für alle Linien und Haltestellen, die dem ITCS unterliegen. Nur so kann ein Auskunftssystem Verbindungen auf dem Liniennetz unter Berücksichtigung von Echtzeitdaten berechnen. Einen Teil dieser Anforderungen könnte auch durch die bereits in VDV453 existenten Fachdienste REF-DFI und DFI abgedeckt wer- den. Für eine effiziente Verarbeitung der Daten in Auskunftssystemen von großer Bedeutung ist jedoch, dass diese in einer adäquaten Struktur nach Fahrten zusammengefasst sind, so auch übergeben werden und nicht als Summe der DFI an einzelnen Haltestellen vorliegen. Das Handling dieser Datenmengen mit dem DFI wäre daher extrem unkomfortabel für beide Schnittstellenpartner. Der DFI-Dienst betrachtet die Übertragung von Echtzeitinformationen somit aus dem Blickwinkel Haltestelle, der Dienst AUS hat seinen Einsatzbereich bei Anwen- dungen aus Netz-Sicht.

VDV 454 Version 3.1.0 21 23.09.2024

[Seite 28]

Einführung und Grundbegriffe VDV 454

3.3 Meta-Daten, Abbildung der Haltestellen und Linien

Da ein Auskunftssystem die Daten verschiedener Betriebe und mitunter sogar verschiedener Verbünde zu einem Gesamtdatenbestand integrieren muss, kann nicht davon ausgegangen werden, dass im ITCS und im Auskunftssystem identische Schlüssel für identische Haltestel- len und Linien verwendet werden.

Haltestellen, Linien und weitere Daten werden somit zu Meta-Daten. Die IDs, die hierfür ver- wendet werden, müssen bilateral vereinbart werden. Häufig sind Zuordnungstabellen zwi- schen den Meta-IDs und den lokal bekannten IDs erforderlich. Die Meta-Daten sind jeweils zwischen den beiden Kommunikationspartnern abzustimmen.

Es wird empfohlen, für stark vernetzte Systemlandschaften (mehrere ITCS, DDS und Aus- kunftssysteme) für alle beteiligten Systeme übergreifend eine eindeutige Handhabung und Verwendung der Meta-Daten zu vereinbaren, um den Pflegeaufwand und mögliche Fehler- quellen im Gesamten zu minimieren. Zur eindeutigen Identifizierung von ÖV Objekten sollten die jeweils landesweit eindeutigen IDs verwendet werden. In Deutschland sind das für Halte- stellen die DHID gemäß VDV-Schrift 432, für Fahrten die DFID und für (Teil-)Linien die DTID/DLID gemäß VDV-Schrift 433.

VDV 454 Version 3.1.0 22 23.09.2024

[Seite 29]

Einführung und Grundbegriffe VDV 454

Es gibt folgende Arten von Meta-Daten:

• HaltID (HaltestellenID, BereichsID, SteigID):

Die Feinheit der Haltestellengliederung (z.B. Bahnhof oder Haltepunkt) auf beiden Seiten muss nicht übereinstimmen. Wichtig ist nur, dass das Meta-Datum auf beiden Seiten auf ein lokal bekanntes Objekt abgebildet werden kann.

Beispiel:

Unter der SteigID 4712 kann das ITCS den Haltepunkt "Hauptbahnhof Trambahn-Gleis 2" verstehen. Das Auskunftssystem hingegen kann das Meta-Objekt auf seinen Haltestellen- bereich Nr. 5 "Trambahn" der Haltestelle 2011 "Hauptbahnhof" abbilden.

Die Verwendung der HaltID wird bereits in der VDV-Schrift 453 in der Version 3.x ausführ- lich beschrieben. An dieser Stelle soll aber noch einmal ausdrücklich erwähnt werden, dass jede Veränderung an einem der Elemente der HaltID (also z.B. auch das Weglassen oder Hinzufügen einer HaltestellenID, BereichsID oder SteigID) zu einer Änderung der HaltID und damit zu einem geänderten Laufweg der entsprechenden Fahrt führt. Solche Ände- rungen müssen daher immer in einer Komplettfahrt-Lieferung erfolgen.

• LinienID (Linie):

Die Meta-Linie muss auf beiden Seiten in die lokal bekannte Linie abgebildet werden.

Die Linien-IDs, welche die am Datenaustausch beteiligten Systeme verwenden, müssen von sich aus global eindeutig sein. Ist dies nicht der Fall, muss die Transportunternehmung zwingend in der BetreiberID angegeben werden, bei Teillinien kann zusätzlich die Aus- fuehrenderID angegeben werden. In Deutschland werden IDs analog VDV-Schrift 433 ver- wendet, ist hier die DTID einzufüllen. Die Struktur einer DTID muss auch verwendet wer- den, wenn es (aktuell) keine unterschiedlichen Teillinien gibt.

• RichtungsID:

Je Linie werden Fahrten in eine oder mehrere Richtungen gebündelt (z.B. "Hin", "Rück"). Mit Hilfe der RichtungsID wird eine Abbildung in die lokal bekannte Richtung ermöglicht.

• ProduktID:

Die ProduktID erlaubt eine Klassierung der Verkehrsmittel (z.B. Zug) und der Angebote (z.B. ICE). (s. Kapitel 6.1.7.1 in der VDV-Schrift 453).

Das Meta-Produkt muss in das lokal bekannte Produkt abgebildet werden.

• FahrzeugTypID:

Der Fahrzeugtyp dient zur Beschreibung der Ausstattung eines Fahrzeugs. Innerhalb einer Stadtbuslinie beispielsweise können die einzelnen Fahrten von Bussen mit ganz unter- schiedlicher Ausstattung durchgeführt werden. Für Rollstuhlfahrer oder Fahrgäste mit Kin- derwägen ist es aber entscheidend zu wissen, ob es sich um ein Niederflurfahrzeug han- delt oder ob eine Rampe oder ein Lift vorhanden ist.

VDV 454 Version 3.1.0 23 23.09.2024

[Seite 30]

Einführung und Grundbegriffe VDV 454

• BetreiberID: Die BetreiberID ist ein Code, der das konzessionierte Verkehrsunternehmen bezeichnet. Mit seiner Hilfe lassen sich Verkehre (Linien) ausfiltern, die von bestimmten Unterneh- men durchgeführt werden. Über die BetreiberID kann man auch Zuständigkeiten für wei- tere Funktionen wie z.B. Buchung und Sitzplatzreservierung ermitteln.

• AusfuehrenderID: Die AusfuehrenderID ist ein Code, der das Unternehmen bezeichnet, das die Fahrt mit seinen Fahrzeugen ausführt.

3.4 Abschätzung der Datenmengen

Limitierungen der ausgetauschten Datenmenge durch XML-Parser und Verbindungsleitungen stellen unter Umständen eine Herausforderung für den Spezifikationsvorschlag dar. Deswe- gen wurden hierfür Festlegungen zur Begrenzung des Datenvolumens getroffen und auf dieser Basis Abschätzungen durchgeführt.

3.4.1 Allgemeine Abschätzung der Datenmengen

3.4.1.1 Annahmen

Die generische Struktur von "LinienFahrplan" besteht aus n Strukturen "SollFahrt", die wiede- rum aus m Strukturen "SollHalt". Hierbei besteht die Möglichkeit, in den Unterstrukturen An- gaben der darüber liegenden Kategorie zu überschreiben. Dabei wird folgende Vereinbarung festgelegt: Die Felder in den Unterstrukturen sind optional und sollen auch nur im Falle abwei- chender Informationen gefüllt und gesendet werden. Damit wird die Übertragung redundanter Informationen vermieden. Informationen, die die gesamte Fahrt oder sogar die Linie betreffen, sind somit möglichst weit oben zu senden.

Bei einer Modellrechnung wurde davon ausgegangen, dass das Auskunftssystem bei einer Änderung der Verspätung über 2 Minuten benachrichtigt wird. Bei einer reinen Änderung der Verspätung werden gemäß der Fortschreibungsregel nur die Haltestellen gemeldet, an denen sich die Fahrplanlage ändert (Annahme: jede 10. Haltestelle). Das Auskunftssystem schreibt die zuletzt gemeldete Verspätung entlang der Route bis zur nächsten gemeldeten Verspätung fort. Bei dispositiven Maßnahmen wird der komplette Fahrplan übermittelt.

Aufgrund von betrieblichen Erfahrungswerten wurden für den "Regelfall" wie für den Extremfall "Schneechaos" der %-Anteil verspäteter Fahrten für diskrete Verspätungsschritte geschätzt, bei denen das ITCS nach der Hystereseeinstellung von 2 min eine Meldung an das Auskunfts- system absetzt.

VDV 454 Version 3.1.0 24 23.09.2024

[Seite 31]

Einführung und Grundbegriffe VDV 454

Tabelle 3 Änderungsmeldungen mit x min Verspätung (AUS) bei % aller Fahrten

Dabei wurde für die Berechnung angenommen, dass im Regelfall die Verspätung auch voll- ständig wieder abgebaut wird, d. h., dass jede Fahrt pünktlich begonnen und beendet wird. Eine mehr als 10 min verspätete Fahrt im Regelfall leistet in der Tabelle daher in allen Ver- spätungszeilen zweimal einen "Beitrag". Dahingegen wurde beim Berechnen der Datenmen- gen beim Schneechaos angenommen, dass eine Fahrt zwar pünktlich begonnen wird aber keine Verspätungen abgebaut wird. Beide Verfahren entsprechen nicht exakt dem tatsächli- chen betrieblichen Verhalten, werden aber als gute Annäherung für die Abschätzung der aus- getauschten Datenmenge angesehen. Charakteristisch für das Verhalten des Systems bei ei- nem extrem gestörten Verkehrsgeschehen ist zum einen, dass deutlich mehr (fast alle) Fahr- ten verspätet sind, dass aber auch zum anderen etliche Fahrten mit erheblicher Verspätung stattfinden und somit der notwendige Nachrichtenaustausch pro Fahrt zunimmt, da die Ver- spätung kontinuierlich aufgebaut wird.

Nicht berücksichtigt wurde:

• Anschlussübermittlung (REF-AUS)

• zusätzlicher Umfang der fahrtspezifischen bzw. haltestellenspezifischen Informationen (s. Bemerkung zu optionale Felder)

• Zusätzliche Attribute bei den einzelnen XML-Tags (Es wurde mit 30 Byte pro Datenele- ment gerechnet)

• http Protokoll-Overhead

3.4.1.2 Abschätzung der Datenmengen

Daraus ergibt sich bei einem großen Unternehmen (60.000 Fahrten/Tag, 40 Haltestel- len/Fahrt): tägl. Gesamtdatenmenge REF-AUS: 300 MB tägl. Gesamtdatenmenge AUS: 90 MB (Regelfall) 270 MB (Schneechaos)

VDV 454 Version 3.1.0 25 23.09.2024

[Seite 32]

Einführung und Grundbegriffe VDV 454

Daraus ergibt sich bei einem mittelgroßen Unternehmen (10.000 Fahrten/Tag, 30 Haltestel- len/Fahrt): tägl. Gesamtdatenmenge REF-AUS: 38 MB tägl. Gesamtdatenmenge AUS: 12 MB (Regelfall) 36 MB (Schneechaos)

Die Datenmengen wurde mit Abostellung ohne MitRealZeiten=true gerechnet. Heute wird die- ses Element häufig gesetzt, was eine deutlich höhere Datenmenge erzeugt. Außerdem ist die Hysterese oft auf 30 Sekunden und nicht 2 Minuten definiert.

Die Datenmengen wurde mit Abostellung ohne MitRealZeiten=true gerechnet. Heute wird die- ses Element häufig gesetzt, was eine deutlich höhere Datenmenge erzeugt. Außerdem ist die Hysterese oft auf 30 Sekunden und nicht 2 Minuten definiert.

3.4.1.3 Übertragungskapazitäten

Wenn man davon ausgeht, dass sich beim Prozessdatendienst AUS der Datenaustausch auf ca. 8 h am Tag gleichmäßig verteilt, ist für ein großes/mittelgroßes Unternehmen als Mini- malanforderung eine Verbindung mit einer Nettoübertragungsrate von 9,4 kB/s bzw. 1,4 kB/s für den Prozessdatenaustausch ausreichend. Bei extrem gestörten Verkehrsverhältnissen ist jedoch damit zu rechnen, dass es durch eine ungleichmäßige Verteilung der Nachrichten zu Spitzenzeiten mit verzögerten Aktualisierungen des Auskunftssystems kommen kann. Aller- dings können durch den Einsatz von Datenkompression die sehr voluminösen XML-Files auf ca. 10-20% ihrer ursprünglichen Größe komprimiert werden und damit Leitungskapazitäten eingespart werden. Dies wurde bei der Angabe der oben genannten Datenmengen nicht be- rücksichtigt. Bei Verwendung von Datenkompression muss jedoch im Gegenzug ausreichend Rechnerleistung bei den beteiligten Partnern zur Verfügung stehen, um die Datenkomprimie- rung und –dekomprimierung ohne nennenswerte Zeitverzögerung durchführen zu können.

Beim Referenzdatendienst REF-AUS wird in der Regel 1-2 Mal täglich der gesamte Betriebs- fahrplan ausgetauscht. Dieser Austausch erfolgt zwar zu betriebsschwachen Zeiten, dennoch sollte eine Übermittlung an das Auskunftssystem im schlechtesten Falle max. 1 Stunde dau- ern. Daher ist hier die Verwendung einer Datenkompression angebracht. Mit Datenkompres- sion ergibt sich als Mindestanforderung an die Verbindung für ein großes/mittelgroßes Unter- nehmen eine Nettoübertragungsrate für den Referenzdatenaustausch von ca. 16,7 kB/s bzw. 2,2 kB/s. Da bei diesem Dienst große Datenmengen zusammenhängend übertragen werden und damit die Übertragungszeiten eine signifikante Rolle spielen, hat die Bandbreite des zur Verfügung stehenden Übertragungsweges einen unmittelbaren Einfluss auf die zum Abgleich des Auskunftssystems benötigte Zeit.

VDV 454 Version 3.1.0 26 23.09.2024

[Seite 33]

Einführung und Grundbegriffe VDV 454

3.4.2 Abschätzung der Datenmengen für Formationsdaten

Für ein großes Unternehmen wird von 60.000 Fahrten pro Tag, bei 40 Haltestellen je Fahrt ausgegangen:

tägl. Gesamtdatenmenge REF-AUS: 11.1 GB tägl. Gesamtdatenmenge AUS: 5 GB (Regelfall) 8 GB (Schneechaos)

Für ein mittelgroßes Unternehmen wird von 10.000 Fahrten pro Tag, bei 10 Haltestellen je Fahrt ausgegangen:

tägl. Gesamtdatenmenge REF-AUS: 980 MB tägl. Gesamtdatenmenge AUS: 450 MB (Regelfall) 500 MB (Schneechaos)

3.5 Abschätzung der Datenaktualität

Die Prozessinformationen, mit denen ein Auskunftsdienst Fahrplanauskünfte erstellt, sind auf- grund der schrittweisen Verarbeitung durch verschiedene Systeme grundsätzlich veraltet.

Eine Standortmeldung eines Fahrzeuges wird in der Regel in Zyklen vom ITCS verarbeitet, dort zu Prognosen verarbeitet und anschließend zum Auskunftsdienst weitergeleitet.

Insbesondere für den Prozessdatendienst AUS stellt sich also die Frage, wie alt die Daten tatsächlich sind, und inwiefern dieses Alter im Rahmen der Auskunftserteilung berücksichtigt werden muss.

Dazu müssen die einzelnen Verarbeitungsschritte analysiert und die entstehenden Zeiten ak- kumuliert werden.

Folgende Zahlen sind Schätzungen, die auf Erfahrungen der ITCS- und Auskunftssystemher- steller basieren.

Folgende Schritte und Zeiten sind als Verzögerungen zu erwarten:

• Erfassung und Übermittlung des Fahrzeugstandortes (ITCS)

Fahrzeuge werden üblicherweise in sogenannten Pollingzyklen erfasst. Dabei werden die Fahrzeuge der Reihe nach angefragt und ihre Daten verarbeitet. Je nach Netzkapazität und Zahl der Fahrzeuge ergibt sich dabei ein minimaler Abfragezyklus. Dieser beträgt im heutigen System üblicherweise 15-90 Sekunden.

Alternativ zu diesem Verfahren kommunizieren einige ITCS-Systeme ereignisgesteuert mit ihren Fahrzeugen. Hier ermittelt das Fahrzeug eigenständig die Fahrplanlage und meldet nach Erreichen eines Veränderungsschwellwertes diese an das ITCS. Hier liegen die Ver- zögerungen typischerweise bei 5-15 Sekunden.

VDV 454 Version 3.1.0 27 23.09.2024

[Seite 34]

Einführung und Grundbegriffe VDV 454

• Errechnung der Prognosedaten

Die Errechnung der Prognose erfolgt typischerweise im ITCS in einem zyklischen Prozess oder ereignisgesteuert durch neue Position des Fahrzeugs. Verschiedene Qualitäten die- ser Berechnung sind im Einsatz (Nur aktuelle Fahrplanlage berücksichtigen, auch Puffer- zeiten berücksichtigen oder gar historische Daten und aktuelle Verkehrsdaten auf dem Fahrweg berücksichtigen). Wird nur die aktuelle Fahrplanlage fortgeschrieben, entfällt die- ser Schritt allenfalls und ist Teil des nächsten Schrittes. Eine genaue Schätzung ist hier schwer möglich.

• Übermittlung an den Auskunftsdienst (Transfer via VDV454)

Hierbei handelt es sich um die Zeit, die nötig ist, eine Meldung vom ITCS zum System des Auskunftsdienstes zu übertragen. Dazu zählt zunächst die Verpackung der Informationen in die Strukturen der VDV454, das Senden über eine Datenleitung sowie das Auspacken aus XML zurück in Binärdaten. Eine genaue Schätzung ist hier schwer möglich, da die Beschaffenheit der Systeme, sowie das aktuelle Datenaufkommen einen sehr großen Spielraum zulässt.

Es sind Werte im einstelligen Sekundenbereich zu erwarten.

• Einpflegen in den Datenbestand (Auskunftssystem)

Sind die Daten auf Seiten der Schnittstelle des Auskunftssystems verfügbar, dann müssen sie in den Gesamtdatenbestand eingepflegt werden. Dazu sind die notwendigen Bezugs- daten aufzufinden und zu ergänzen bzw. zu ändern. Schätzungen der Hersteller gehen hier in den Bereich von 3-10 Sekunden, je nach Umfang der Datenänderung.

Somit ist eine Gesamtverzögerung innerhalb der Informationskette um die 2 Minuten zu erwarten. Hinzu kommen weitere Verzögerungen auf Seiten des Auskunftsdienstes, z.B. Versenden einer SMS. Insgesamt sind die Verzögerungen gering genug, um kurzfristige Auskünfte geben zu können.

3.6 Zeitformatierung

Da das ISO Format 8601 mehrere Darstellungen unterstützt, wird für die Dienste REF-AUS und AUS dieselbe Lösung wie in VDV453 Kap. 6.1.2 festgelegt:

Jede Zeitinformation bezieht sich auf die sogenannte UTC (Universal Time Coordinated). 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 (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.

Mit dieser Zeitdarstellung können Probleme bei der Sommerzeitumstellung vermieden wer- den.

VDV 454 Version 3.1.0 28 23.09.2024

[Seite 35]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

4 Schnittstellenbeschreibung "Basisinfrastruktur"

4.1 Vorbemerkung

Die in diesem Dokument beschriebene Spezifikation ergänzt die VDV453 um einen weiteren fachlichen Dienst. In den folgenden Kapiteln werden das Grundprinzip sowie die notwendigen Ergänzungen bzw. Anpassungen beschrieben. Darüber hinaus gelten die in der VDV453 ge- troffenen Festlegungen zu den Bereichen "Architektur" und "Basisinfrastruktur" auch innerhalb der VDV454.

4.2 Abonnement-Verfahren

Das sogenannte Abonnement-Verfahren definiert eine einheitlich 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 3).

Zunächst vereinbaren Client und Server, welche Informationen ausgetauscht werden sollen. Dies erfolgt durch sogenannte Abonnements. Abonnements werden client-seitig 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).

Um Ausfälle des Clients festzustellen, können periodisch ClientStatusAnfragen an den Client gestellt werden. Mit einer ClientStatusAntwort erklärt der Client seine Funktionstüchtigkeit (Schritt 5)

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 6).

VDV 454 Version 3.1.0 29 23.09.2024

[Seite 36]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

Abbildung 3: Kommunikationsablauf des Abonnementverfahrens

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.

Eine detaillierte Beschreibung des Abonnementverfahrens sowie auch der Abläufe nach Ver- bindungsunterbrechung oder im Fehlerfall findet sich in der VDV-Schrift 453.

4.3 Protokolle

Siehe VDV453, Kap. 4.3

4.4 Dienstekennung/Anfrage-URL

Jeder fachliche Dienst der VDV453 besitzt eine eindeutige Kennung (siehe VDV453, Kapitel 5.2.3). Für den Auskunftsdienst der VDV454 werden folgende Kennungen ergänzt:

• "ausref" für den Referenzdatendienst der Auskunftsschnittstelle

VDV 454 Version 3.1.0 30 23.09.2024

[Seite 37]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

• "aus" für den Prozessdatendienst

Gemäß der Konvention von Zieladressen (Anfrage-URL, VDV453, Kapitel 5.2.4) lautet z.B. eine Statusanfrage an den Prozessdatendienst der Auskunftsschnittstelle:

http://serverhostsystemb:8080/leitstellenkennungsystema/aus/status.xml

4.5 Wiederverwendete Datentypen

Ein Großteil der Datentypen der VDV453 wird auch innerhalb der VDV454 verwendet. Die Datentypen der VDV454 sind dazu in das Schema der VDV453 integriert.

Folgende Datentypen finden Wiederverwendung innerhalb der VDV454 und werden daher in diesem Dokument nicht weiter beschrieben. Enthalten die Datentypen weitere Untertypen, so werden diese ebenfalls wiederverwendet.

Die englischen Alias-Bezeichner (siehe Abschnitt 8 ) behalten ebenfalls ihre Gültigkeit.

VDV 454 Version 3.1.0 31 23.09.2024

[Seite 38]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

Tabelle 4

4.6 Nutzung der optionalen Felder

Bereits die fachlichen Dienste der VDV 453 verwenden optionale Elemente, insbesondere um den jeweils spezifischen Funktionsumfang einzelner Systeme zu berücksichtigen, sowie zur Sicherstellung der Abwärtskompatibilität. In der VDV 454 wurde die Nutzung von optionalen Elementen zusätzlich ausgebaut, um die erheblich größere Datenmenge zu reduzieren.

Es lassen sich damit folgende drei Einsatzfelder von optionalen Elementen unterscheiden:

• Unterschiedlicher Funktionsumfang: Die VDV 453- und 454-Dienste sind sehr umfang- reich und übertragen eine Vielzahl von Informationen. Gleichzeitig sollen sie breit ein- gesetzt werden können. Dank der optionalen Elemente können die VDV-Dienste je- weils passend zum Funktionsumfang und den Anforderungen eines Systems umge- setzt werden.

• Abwärtskompatibilität: Seit der ersten Version haben sich die VDV-Dienste erheblich weiterentwickelt. Zur Sicherstellung der Abwärtskompatibilität werden neue Elemente in der Regel als optional definiert.

• Reduzierung der Datenmenge: Die Datenmengen, die im Rahmen einer Auskunfts- schnittstelle transportiert werden müssen, übersteigen die der fachlichen Dienste der VDV453 erheblich. Um eine Reduzierung der Datenmenge zu erreichen, wurde daher die Verwendung von optionalen Elementen verstärkt. Diese sollen demnach nur ge- nutzt werden, um Änderungen gegenüber dem bekannten Datenstand mitzuteilen

Diese drei unterschiedlichen Einsatzfelder führen zu einer höheren Komplexität bei der Daten- verarbeitung im Auskunftssystem. Generelle Regeln dazu werden in den Kapiteln 4.6.1 und 4.7 aufgestellt, zusätzliche Hinweise und Ausnahmen finden sich einerseits bei den einzelnen Elementen, andererseits im Kapitel 6.

VDV 454 Version 3.1.0 32 23.09.2024

[Seite 39]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

4.6.1 Richtlinie zur Definition von optionalen Elementen

Wird im AUS ein optionales Element nicht angegeben, dann gilt bei einer Änderungsmeldung der zuletzt übermittelte Wert im AUS und es wird davon ausgegangen, dass betreffend dieses Elements keine Änderung zur letzten Meldung vorliegt. Bei einer Komplettfahrt gilt in diesem Fall der Wert aus dem REF-AUS oder Periodenfahrplan. Kann aus diesen Quellen kein Wert entnommen werden, oder stehen diese Quellen nicht zur Verfügung, so ist der Wert gemäß den bei den Elementbeschreibungen definierten Verarbeitungsregel zu ermitteln, ist keine sol- che Verarbeitungsregel definiert wird der (systeminterne) Vorgabewert verwendet.

Bei gewissen optionalen Elementen, z.B. vom Typ Boolean (Einsteigeverbot, Aussteigeverbot, Durchfahrt, Zusatzhalt, Zusatzfahrt, FaelltAus, FahrradMitnahme, etc.), kann der Wert aber nicht einfach weggelassen oder auf "unbekannt" gesetzt werden, da in diesem Fall das Ver- halten im Auskunftssystem nicht klar wäre.

Es ist nun sehr verlockend, für solche Elemente, wie z.B. Einsteigeverbot einen Default-Wert (in diesem Fall "false") zu definieren, um den Wert "unbekannt" zu verhindern. Dies führt aber dazu, dass der Wert aus dem Periodenfahrplan oder aus einer früheren Meldung immer über- schrieben würde. Kann aber ein ITCS grundsätzlich kein Einsteigeverbot liefern, würde unge- wollt ein Wert "true" aus dem Periodenfahrplan mit dem Default-Wert "false" überschrieben, aus diesem Grund ist ein Default-Wert für optionale Elemente nicht sinnvoll. Das in der XSD weggelassenem Element würde immer zumindest den Default-Wert übermittelt, was nicht ge- wollt ist.

Als einzige Lösung bietet sich eine Verarbeitungsregel für das Auskunftssystem an: Wenn wir das Standardverhalten gemäß Kapitel 4.7 immer als Grundlage nehmen, kann die Implemen- tierungsvorschrift auf den nachfolgenden Text reduziert werden:

Keine Angabe: Kann bei Komplettfahrt=true kein Wert in den Ist- und Solldaten ermittelt werden, dann ist der Wert für dieses Element gemäß der Vorgabe in der Verarbeitungsregel zu set- zen.

Mit dieser Verarbeitungsregel wird bei der Definition von optionalen Elementen vom Typ Boolean im Zusammenhang mit Komplettfahrt in einer AUS-Meldung erst als letzte Möglichkeit ein vorgegebener Wert angenommen. Ist keine Verarbeitungsregel definiert, wird der (system- interne) Vorgabewert verwendet. Die Verarbeitungsregel bzw. der Vorgabewert muss pro Ele- ment definiert werden.

Bei Komplettfahrt=false wird der Wert aus der vorangehenden AUS-Meldung entnommen.

4.7 Generischer Verarbeitungsprozess im Auskunftssystem

Das vorliegende Kapitel beschreibt die Verarbeitung der von REF-AUS und AUS unter Einbe- zug des Periodenfahrplans die vom Sender zum Empfänger übermittelten Daten. Die aufge- stellten Regeln sind eine Zusammenfassung von weiter unten in der Schrift spezifizierten Vor- gaben sowie von Erfahrungen aus Umsetzungsprojekten.

VDV 454 Version 3.1.0 33 23.09.2024

[Seite 40]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

4.7.1 Standard-Verarbeitungsreihenfolge

Im Auskunftssystem werden typischerweise Daten aus verschiedenen Quellsystemen zusam- mengefügt (siehe dazu die Beschreibung in der Einführung, Kapitel 2.1 sowie 2.2.1 ): Perio- denfahrplan aus der längerfristigen Fahrplanung, REF-AUS aus der betrieblichen Planung so- wie AUS vom Leitsystem. Dabei gibt es eine typische Verarbeitungsreihenfolge der erwähnten Datenpakete:

1. Als Grundlage und über längere Zeit vorhanden ist der Periodenfahrplan.

2. Vor der Übermittlung der AUS-Daten werden in der Regel die REF-AUS-Daten über- mittelt. Diese aktualisieren den Periodenfahrplan mit neuen Informationen und es wird zu jeder übertragenen Fahrt ein neuer Basiszustand gesetzt. Nicht übertragene Ele- mente werden aus dem Periodenfahrplan übernommen.

3. Spätestens mit Erreichen der Vorschauzeit (für Ausnahmen s. Kapitel 6.1.6 ) wird im AUS eine Erstmeldung (als Komplettfahrt) übertragen. Diese aktualisiert die vorhan- denen Daten, also Periodenfahrplan und REF-AUS und es wird zu jeder übertrage- nen Fahrt ein neuer Basiszustand gesetzt. Nicht übertragene Elemente werden aus dem REF-AUS oder Periodenfahrplan übernommen.

4. Beim Überschreiten der Hysterese oder Attributänderungen werden im AUS Aktuali- sierungsmeldungen übertragen. Diese aktualisieren wiederum die vorhandenen AUS- Daten, REF-AUS-Daten, sowie den Periodenfahrplan, ohne einen neuen Basiszu- stand zu setzen. Nicht übertragene Elemente werden der letzten AUS-Meldung ent- nommen.

5. Bei Bedarf wird durch eine Komplettfahrt im AUS ein neuer Basiszustand zu einer Fahrt gesetzt, fehlende Elemente werden soweit möglich aus dem REF-AUS und dem Periodenfahrplan komplettiert. Bisherige AUS-Meldungen werden nicht mehr be- rücksichtigt.

4.7.2 Hierarchie der Elemente

Innerhalb der einzelnen Datenpakete Periodenfahrplan, REF-AUS und AUS gibt es eine Viel- zahl von optionalen Elementen. Es gibt aber auch einige Elemente, welche in mehreren Struk- turen vorhanden sein können. So kann es Elemente geben, welche im Periodenfahrplan, im REF-AUS (in den Strukturen LinienFahrplan, SollFahrt und SollHalt) und im AUS (in den Struk- turen IstFahrt sowie IstHalt) übermittelt werden können. Im Auskunftssystem gilt dabei die fol- gende Hierarchie, wie sich die Werte von in mehreren Datenpaketen gelieferten Elementen übersteuern:

AUS

• Gleichnamige Elemente aus IstHalt überschreiben Elemente aus IstFahrt

REF-AUS

• Gleichnamige Elemente aus SollHalt überschreiben Elemente aus SollFahrt.

VDV 454 Version 3.1.0 34 23.09.2024

[Seite 41]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

• Gleichnamige Elemente aus SollFahrt überschreiben Elemente aus dem LinienFahr- plan.

• Gleichnamige Elemente aus dem LinienFahrplan überschreiben für den übermittelten Gültigkeitszeitraum die Elemente aus dem Periodenfahrplan.

AUS > REF-AUS

• Gleichnamige Elemente aus IstHalt überschreiben Elemente aus SollHalt.

• Gleichnamige Elemente aus IstFahrt überschreiben Elemente aus SollFahrt.

REF-AUS > Periodenfahrplan

• Gleichnamige Elemente aus dem LinienFahrplan überschreiben für den übermittelten Gültigkeitszeitraum die Elemente aus dem Periodenfahrplan.

Hinweis für die Verarbeitung mehrerer Aktualisierungsmeldungen im AUS

Im Zusammenhang mit der Fortschreibungsregel müssen in den Aktualisierungsmeldungen des AUS nur gewisse Halte übermittelt werden, insbesondere solche mit Änderungen des Ver- spätungsprofils und solche mit weiteren Attributänderungen (s. Kapitel 6.1.2 ). Dabei stellt sich für Elemente, welche auf mehreren Hierarchiestufen vorkommen, das im folgenden Beispiel gezeigte Problem:

• Ausgangslage: Mittels Komplettfahrt = true wurde zu einer Fahrt ein neuer Basiszu- stand gesetzt. Dabei ist auf Stufe IstFahrt ein VonRichtungsText = "Zürich" enthalten, welcher für den Halt 4 auf Stufe IstHalt mit "Zürich, Oerlikon" überschrieben wird.

• Aktualisierung: Mit einer nachfolgenden Aktualisierungsmeldung werden die Prog- nosewerte aktualisiert, unter anderem für Halt 4. Falls im IstHalt der VonRichtungs- Text weggelassen wird (keine Änderung), bleibt der Wert aus der letzten AUS-Mel- dung erhalten, er wird nicht auf den VonRichtungsText auf Stufe IstFahrt gesetzt.

Um unklare Datenlagen im Auskunftssystem zu vermeiden, sollten bei Aktualisierungsmeldun- gen stets alle relevanten optionalen Elemente übermittelt werden (im Zweifelsfall eher ein Ele- ment zu viel übermitteln).

Einige Elemente kommen in mehreren Strukturen vor. Ist ein Wert im IstHalt vorhanden, so werden gleichnamige Elemente in IstFahrt/SollHalt/SollFahrt und im LinienFahrplan über- schrieben. Abweichungen vom Standardverhalten werden direkt bei den Elementen definiert.

Daraus lässt sich folgendes Standardverhalten von gleichnamigen Elementen, die in den Strukturen IstHalt, IstFahrt, SollHalt, SollFahrt, LinienFahrplan vorkommen, ableiten:

VDV 454 Version 3.1.0 35 23.09.2024

[Seite 42]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

Tabelle 5

Einsteigeverbot oder Durchfahrt kommen in mehreren Strukturen vor. Ist ein Wert im IstHalt vorhanden, so wird der Wert im SollHalt überschrieben.

Daraus lässt sich folgendes Standardverhalten von gleichnamigen Elementen in den Struktu- ren IstHalt, SollHalt vorkommen ableiten:

Tabelle 6

FahrradMitnahme kommt in mehreren Strukturen vor. Ist ein Wert in der IstFahrt vorhanden, so wird der Wert in der SollFahrt und im LinienFahrplan überschrieben.

Daraus lässt sich folgendes Standardverhalten von gleichnamigen Elementen, die in den Strukturen IstFahrt, SollFahrt, LinienFahrplan vorkommen, ableiten:

VDV 454 Version 3.1.0 36 23.09.2024

[Seite 43]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

Tabelle 7

4.7.3 Aktualisierungsregeln für Auskunftssysteme

Implikationen von Referenz- und Prozessdiensten auf die Verarbeitung

Bei der Verarbeitung der Daten im Auskunftssystem muss unterschieden werden, ob die emp- fangenen Meldungen einen neuen Basiszustand zu einer Fahrt setzen oder die Fahrt nur be- züglich der in der Meldung enthaltenen Merkmalen ändern. Generell gilt hier, dass Referenz- dienste stets einen neuen Basiszustand setzen und Prozessdienste in der Regel nur einzelne Merkmale ändern. Die Ausnahme im Prozessdienste AUS ist eine Fahrt mit Komplett- fahrt=true, welche ebenfalls einen neuen Basiszustand setzt.

Diese Unterscheidung wirkt sich auf die Anwendung der Standard-Verarbeitungsreihenfolge im Auskunftssystem aus, weshalb zwei Aktualisierungsregeln unterschieden werden müssen.

Standardverarbeitung Referenzdienste

Die neu übermittelten Daten ersetzen die zuvor übermittelten Daten im gleichen Zeitbereich vollständig:

• Ein Periodenfahrplan ersetzt im übermittelten Zeitbereich den zuvor übermittelten Pe- riodenfahrplan.

• Ein LinienFahrplan ersetzt im übermittelten Zeitbereich den zuvor übermittelten Linien- Fahrplan.

Bei der Verarbeitung im Auskunftssystem nach der Standard-Verarbeitungsreihenfolge gelten folgende Aktualisierungsregeln.

1. Ein übermitteltes Element übersteuert alle entsprechenden Elemente (auch Listen und Substrukturen) vollständig, welche früher durch den gleichen oder einem ande- ren Dienst übermittelt wurden (siehe Regeln in Kapitel 4.7.2).

VDV 454 Version 3.1.0 37 23.09.2024

[Seite 44]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

2. Ein leeres Element unterdrückt alle entsprechenden Elemente (auch Listen und Sub- strukturen) vollständig, welche früher durch den gleichen oder einem anderen Dienst übermittelt wurden (siehe Regeln in Kapitel 4.7.2).

3. Ein nicht übermitteltes Element führt zu keiner Änderung am Wert welche früher durch den gleichen oder einem anderen Dienst übermittelt wurde (siehe Regeln in Kapitel 4.7.2):

a) Kann für ein Element kein Wert ermittelt werden, wird die bei der Element-Be- schreibung definierte Verarbeitungsregel angewendet.

b) Ist keine Verarbeitungsregel definiert, wird der (systeminterne) Vorgabewert verwendet.

4. Abweichungen vom Standardverhalten werden direkt bei den Elementen definiert.

Standardverarbeitung Prozessdienste

Bei der Verarbeitung im Auskunftssystem nach der Standard-Verarbeitungsreihenfolge (s. 4.7.1 gelten folgende Aktualisierungsregeln.

1. Ein übermitteltes Element ersetzt auf der gleichen Hierarchiestufe den vorhandenen Wert vollständig (auch Strukturen oder Listen)

2. Ein leeres Element löscht auf der gleichen Hierarchiestufe den vorhandenen Wert vollständig (auch Strukturen oder Listen)

3. Ein nicht übermitteltes Element

a. übernimmt als neue Basis im Zusammenhang mit Komplettfahrt=true den Wert aus den zugrundeliegenden Ebenen gemäß Kapitel 4.7.2, ist kein Soll- zustand vorhanden wird die Verarbeitungsregel ausgeführt, falls keine Verar- beitungsregel vorhanden ist, wird das Element auf den systeminternen Vorga- bewert zurückgesetzt.

b. führt in allen anderen Fällen zu keiner Änderung an einem zuvor übermittel- ten Wert. Hinweis: Dies gilt auch für Elemente, welche in mehreren Strukturen vor- kommen.

4. Abweichungen bestehen insbesondere bei den Zeiten sowie im Zusammenhang mit der "Ergänzungsregel zum Verspätungsprofil".

5. Abweichungen vom Standardverhalten werden direkt bei den Elementen definiert.

Die folgende Grafik von links nach rechts gelesen illustriert die aufgestellten Regeln. Dabei stehen die einzelnen farbigen Striche für verschiedene Elemente, die Länge für den jeweiligen Wert.

VDV 454 Version 3.1.0 38 23.09.2024

[Seite 45]

Schnittstellenbeschreibung "Basisinfrastruktur" VDV 454

Abbildung 4

Der Ablauf beginnt mit dem Periodenfahrplan. Darin sind die drei Elemente Blau, Grün und Rot vorhanden. Als Ergebnis der Verarbeitung werden nur diese drei Elemente angezeigt. Der REF-AUS übermittelt für den Betriebstag die Elemente Blau, Rot sowie zusätzlich Lila, wobei der Wert von Rot geändert hat. Als Ergebnis der Verarbeitung werden alle vier Elemente an- gezeigt, wobei der Wert von Rot entsprechend angepasst wird.

Die Verarbeitung der AUS-Erstmeldung sowie der Aktualisierung I und II erfolgen analog.

VDV 454 Version 3.1.0 39 23.09.2024

[Seite 46]

Fachliche Dienste VDV 454

5 Fachliche Dienste

5.1 Solldatendienst REF-AUS

Dieser Dienst hat die Aufgabe, tagesaktuelle Soll-Fahrpläne aller dem ITCS bekannten Linien an das Auskunftssystem zu übertragen. Auf diese Weise wird die mittelfristige Auskunftsqua- lität verbessert sowie die Referenzierung der Ist-Meldungen im AUS-Dienst auf den Soll-Fahr- plan erleichtert. Dennoch ist er für das Funktionieren des Ist-Daten-Dienstes nicht zwingend notwendig.

Da das Auskunftssystem typischerweise nur die für den Fahrgast relevanten Fahrtanteile kennt, darf das ITCS dem Auskunftssystem auch nur die produktiven Anteile übermitteln.

Auch Informationen über die geplanten Anschlüsse und die Verknüpfung von Fahrten, bei de- nen der Fahrgast im Fahrzeug sitzen bleiben kann, werden mit Hilfe des REF-AUS-Dienstes transportiert.

Wegen der zu erwartenden Vorteile sollten Systeme, die den REF-AUS-Dienst technisch be- reitstellen können, diesen unbedingt implementieren. Gerade die Zusammenarbeit von neuen, leistungsfähigen ITCS- und Auskunftssystemen wird davon profitieren.

Sendet der Datenlieferant WeitereDaten="true", dann signalisiert er, dass er aktuell noch wei- tere Daten zum Abo vorliegen hat.

Seit VDV454 v3.0 wird das AboAUSRef bis zum Erreichen des VerfallZst aktiv gehalten. So lange das Abonnement aktiv ist, kann der Datenlieferant laufend neue oder aktualisierte Lini- enfahrpläne nachliefern. Wie das genau gemacht werden soll, ist in folgenden Kapiteln be- schrieben:

• 5.1.3.5 Übermittlung der Zeitfenster, Erstmeldung, Aktualisierungen

• 5.1.4 Übermittlung disponierter Fahrten Tage im Voraus

5.1.1 Fahrplandaten-Anfrage (AboAUSRef)

Die Abonnement-Anfrage nach Soll-Daten wird durch die Struktur AboAUSRef dargestellt und enthält folgende Elemente:

VDV 454 Version 3.1.0 40 23.09.2024

[Seite 47]

Fachliche Dienste VDV 454

VDV 454 Version 3.1.0 41 23.09.2024

[Seite 48]

Fachliche Dienste VDV 454

Kombination von Abofilter und Kriterien

Filterkriterien können bei Bedarf angegeben und beliebig miteinander kombiniert werden, um den erwarteten Umfang der Daten für das gestellte Abo festzulegen.

Diesbezüglich gelten die folgenden Regeln:

• Bei Kombination von Filtern unterschiedlichen Typs (z.B. LinienFilter und BetreiberFil- ter) handelt es sich um eine UND-Verknüpfung.

• Bei Angabe mehrerer Filter gleichen Typs (z.B. LinienFilter) handelt es sich um eine ODER-Verknüpfung. D.h. eines der angegebenen Kriterien muss in den Fahrplandaten enthalten sein.

• Bei Filterangaben innerhalb eines einzelnen Filters handelt es sich um UND-Verknüp- fungen (z.B. Angabe mehrerer "HaltIDs" im HaltFilter)

Beispiel:

VDV 454 Version 3.1.0 42 23.09.2024

[Seite 49]

Fachliche Dienste VDV 454

Anwendung von Wildcards für Abofilter

Die Verwendung von Wildcards (z.B. "%", "*", "?", "#") muss zwischen den Partnern vereinbart werden.

5.1.1.1 Beschränkung der Daten nach Zeitbereich (Zeitfenster)

Die Zeitpunkte in der Struktur Zeitfenster beziehen sich jeweils auf die Abfahrtszeit an der Starthaltestelle.

Es werden auch solche Fahrten als zum Zeitfenster gehörend betrachtet, die zwar selbst au- ßerhalb des Zeitfensters liegen, die aber in einem unmittelbaren verkehrlichen Zusammen- hang zu anderen Fahrten innerhalb des Zeitfensters stehen. Ein Beispiel dafür ist eine Flügel- fahrt, die sich von einem Zug abspaltet. Die Zugfahrt liegt innerhalb des Zeitfensters, dann gehören auch alle Flügelzüge zum Zeitfenster – auch wenn die Flügelfahrten selbst außerhalb des Zeitfensters liegen. Durch diese Regel werden Inkonsistenzen zwischen den einzelnen

VDV 454 Version 3.1.0 43 23.09.2024

[Seite 50]

Fachliche Dienste VDV 454

Zugteilen vermieden. Ein anderes Beispiel sind Züge, die ihre Gattungsbezeichnung oder Pro- duktbezeichnung unterwegs ändern und daher oft als zwei Einzelfahrten dargestellt werden. Aus verkehrlicher Sicht handelt es sich aber um eine durchgehende Fahrt. Weitere Gründe müssen zwischen den Partnern vereinbart werden.

5.1.1.2 Beschränkung der Daten nach Linien (LinienFilter)

Die Struktur LinienFilter gibt dem Auskunftssystem die Möglichkeit, einzelne Linien des ITCS zu selektieren. Wird kein LinienFilter für das Abonnement angegeben, wird implizit die Über- tragung der Daten für alle dem ITCS bekannten Linien gewünscht. D. h. das ITCS kann ent- scheiden, für welche Linien es Daten senden will.

Im folgenden Beispiel fordert das Auskunftssystem Fahrplansolldaten vom ITCS für die Linie "10" in allen Richtungen an. Es sollen Daten für 24 Stunden, beginnend vom 21.7.2001/9:30 Uhr, gesendet werden.

Beispiel:

5.1.1.3 Beschränkung der Daten nach Betreibern (BetreiberFilter)

VDV 454 Version 3.1.0 44 23.09.2024

[Seite 51]

Fachliche Dienste VDV 454

Beispiel:

5.1.1.4 Beschränkung der Daten nach Produkten (ProduktFilter)

Beispiel:

5.1.1.5 Beschränkung der Daten nach VerkehrsmittelIDs (VerkehrsmittelIDFilter)

Beispiel:

VDV 454 Version 3.1.0 45 23.09.2024

[Seite 52]

Fachliche Dienste VDV 454

5.1.1.6 Beschränkung der Daten nach HaltIDs (HaltFilter)

Beispiel:

UND-Verknüpfung (alle angegebenen Halte müssen im Fahrtverlauf vorkommen z.B. Lan- desgrenzen überschreitend)

ODER-Verknüpfung (mind. einer der angegebenen Halte muss im Lauf vorkommen)

Eine angegebene HaltID innerhalb eines HaltFilters lässt alle Fahrten mit HaltIDs zu, bei denen alle im Filter angegebenen Sub-IDs (HaltestellenID, BereichsID, SteigID und SektorenID) auch in einer HaltID der Fahrt vorkommen. Zusätzliche Sub-IDs in der HaltID der Fahrten sind zu- lässig (siehe nachfolgende Beispiele). Die Elemente ElementFuerUmwandlungInClassicHal- tID und AbgeleitetAusClassicHaltID sollten im HaltFilter weggelassen werden und werden beim Vergleich ignoriert.

VDV 454 Version 3.1.0 46 23.09.2024

[Seite 53]

Fachliche Dienste VDV 454

Beispiel:

Der Filter

passt auf die HaltIDs

Istfahrt 1 de:11000:900023201 de:11000:900023201:1:50 … Istfahrt 2 de:11000:900023201 de:11000:900023201:1 de:11000:900023201:1:50

nicht aber auf die HaltIDs Istfahrt 3 de:11000:900023201 … Istfahrt 4 de:11000:900023201:1:50

5.1.2 Daten übermitteln (AUSNachricht)

Alle Datenübermittlungen zu einem Abonnement (Planungdaten, Istdaten und Anschlussinfor- mationen) werden in dem Element AUSNachricht übermittelt.

VDV 454 Version 3.1.0 47 23.09.2024

[Seite 54]

Fachliche Dienste VDV 454

Die Informationen sind in der Antwortstruktur LinienFahrplan linienbezogen gebündelt.

Falls ein Datenlieferant eine DatenAbrufenAnfrage erhält, die Daten aber noch nicht bereit hat, soll eine leere DatenAbrufenAntwort (das verpflichtende Element Bestaetigung ist enthalten, das optionale Element AUSNachricht fehlt jedoch) gesendet werden. Der Datenkonsument darf in diesem Fall keine Rückschlüsse auf irgendwelche Linienfahrpläne ziehen.

5.1.3 Linienorientierte Fahrplandatenübermittlung (LinienFahrplan)

In einem Element AUSNachricht können sich mehrere Elemente des Typs LinienFahrplan be- finden.

Ein LinienFahrplan enthält immer alle Fahrten einer Linie eines Betreibers in einer bestimmten Richtung von einem Datenlieferanten (ITCS) im in der Lieferung angegebenen Zeitraum.

Es gelten folgende Grundsätze:

• Der LinienFahrplan ersetzt den Periodenfahrplan anhand der Kriterien "LinienID", "Betrei- berID" und "RichtungsID".

• Wenn ein LinienFahrplan bestimmte SollFahrten nicht enthält, dann finden diese Soll- Fahrten nicht statt.

• Wenn ein LinienFahrplan keine SollFahrten enthält, dann finden in diesem Zeitraum keine Fahrten der Linie statt.

• Wenn ein LinienFahrplan die Alternative Zuruecksetzen enthält, dann wird der Linienfahr- plan gezielt auf den im Auskunftssystem bekannten Linienfahrplan des Periodenfahrplans zurückgesetzt, ohne dass dafür das komplette AboAUSRef neu aufgesetzt werden muss.

• Wenn ein LinienFahrplan die Alternative Zuruecksetzen enthält, dann wird der Linienfahrplan gezielt auf den im Auskunftssystem bekannten Linienfahrplan des Periodenfahrplans zurückgesetzt, ohne dass dafür das komplette AboAUSRef neu aufgesetzt werden muss. Dies gilt für die bestätigten abonnierten Zeitfenster und die zusätzlich übermittelten Zeitfenster.

VDV 454 Version 3.1.0 48 23.09.2024

[Seite 55]

Fachliche Dienste VDV 454

VDV 454 Version 3.1.0 49 23.09.2024

[Seite 56]

Fachliche Dienste VDV 454

VDV 454 Version 3.1.0 50 23.09.2024

[Seite 57]

Fachliche Dienste VDV 454

Alle im LinienFahrplan als optional gekennzeichneten Elemente können durch entsprechende Einträge in der Struktur "SollFahrt" überschrieben werden (Mit Ausnahme der BetreiberID und der AusfuehrenderID).

Bündelung von REF-AUS-Daten durch eine Datendrehscheibe (DDS):

Fahrten von unterschiedlichen ITCS (Datenlieferant) dürfen nicht in einem LinienFahrplan ge- bündelt werden und sind daher in verschiedenen Linienfahrplänen abzubilden

• Grund: Fällt ein Datenlieferant aus, so werden für diesen Lieferanten keine LinienFahr- pläne geliefert, die Daten der übrigen Lieferanten können aber trotzdem ausgeliefert werden.

Fahrten von unterschiedlichen Transportunternehmungen dürfen nicht in einem LinienFahr- plan gebündelt werden und sind daher in verschiedenen Linienfahrplänen abzubilden.

• Grund: Können für eine Transportunternehmung (Betreiber) keine Linienfahrpläne ge- liefert werden, so können aber die Linienfahrpläne der übrigen Transportunternehmun- gen ausgeliefert werden.

Empfehlung: Die LinienID, die BetreiberID und die AusfuehrenderID sollen nicht nur innerhalb eines ITCS, sondern über alle am Datenaustausch beteiligten Systeme hinweg eindeutig sein (ITCS, DDS, Auskunftssysteme). Ziel ist, dass Im Feld LinienID eine landesspezifisch eindeu- tige Id, in Deutschland aufgrund der Vorgabe der VDV433, die DTID verwendet wird.

5.1.3.1 Einzelfahrtdaten (SollFahrt)

In jeder Struktur LinienFahrplan gibt es null, eine oder mehrere Strukturen SollFahrt mit fol- gendem Inhalt:

VDV 454 Version 3.1.0 51 23.09.2024

[Seite 58]

Fachliche Dienste VDV 454

VDV 454 Version 3.1.0 52 23.09.2024

[Seite 59]

Fachliche Dienste VDV 454

VDV 454 Version 3.1.0 53 23.09.2024

[Seite 60]

Fachliche Dienste VDV 454

Implementierungshinweise:

Sobald eine SollFahrt im REF-AUS übermittelt wurde, gelten die in der SollFahrt angegebenen SollHalte als neue Fahrtroute. Ein ITCS kann nicht gezwungen werden im Falle eines Fahrt- ausfalls oder einer Zusatzfahrt gegenüber dem Jahresfahrplan (Periodenfahrplan) das Ele- ment "FaelltAus" bzw. das Element "Zusatzfahrt" zu liefern, da für ITCS, DDS und Auskunf- tysteme unterschiedliche Versionen des Periodenfahrplanes existieren können.

Liegt ein Fahrtausfall vor, kann dies durch das Auskunftssystem über zwei Wege festgestellt werden:

• Die ausgefallene SollFahrt wird im LinienFahrplan nicht übertragen.

• Die ausgefallene SollFahrt wird im LinienFahrplan übertragen und mit "FaelltAus" ge- kennzeichnet.

Im letzten Fall besitzt das Element "FaelltAus" steuernden Charakter in Bezug auf die Fahr- planauskunft. Das Auskunftssystem entscheidet dann, ob die ausgefallene Fahrt aus dem Fahrplan entfernt wird, oder dem Reisenden aktiv ein Fahrtausfall kommuniziert wird. Fahrten, die gegenüber dem Jahresfahrplan (Periodenfahrplan) entfallen, sollen daher, wenn immer möglich, mittels "FaelltAus" deklariert werden. Auf diese Weise kann man die Fahrtausfälle von zeitlichen Fahrtverschiebungen unterscheiden, die u.U. dazu führen, dass eine Fahrt über das Ende des Zeitfensters einer AUSRef-Lieferung geschoben wird und daher irrtümlich als Fahrtausfall betrachtet wird.

Liegt eine Zusatzfahrt vor, kann diese durch das Liefersystem über zwei Wege gekennzeichnet werden:

• Die zusätzliche SollFahrt wird im LinienFahrplan übertragen.

• Die zusätzliche SollFahrt wird im LinienFahrplan übertragen und das Element "Zusatz- fahrt" ist angegeben.

In beiden Fällen wird die Sollfahrt als zusätzliche Fahrt im Fahrplan hinzugefügt, wenn die Zusatzfahrt eindeutig als solche erkennbar ist. Die Angabe des Elementes Zusatzfahrt ist für das Auskunftssystem dennoch nicht von rein informativem Charakter und sollte wenn mög- lichst immer erfolgen: Im Fall, dass Sollfahrplan und Referenzdienst in der Fahrplanauskunft abgeglichen werden, um die Zusatzinformationen des Sollfahrplans zu erhalten, und der Ab- gleich dabei unscharf erfolgen muss, weil z.B. die Sollzeiten im ITCS und der Fahrplanauskunft

VDV 454 Version 3.1.0 54 23.09.2024

[Seite 61]

Fachliche Dienste VDV 454

nicht exakt übereinstimmten, hilft die Markierung Zusatzfahrt dabei, Zusatzfahrten sicher als solche zu verarbeiten.

5.1.3.2 Informationen zum Halt (SollHalt)

Die Struktur SollHalt kann mehrfach in einer SollFahrt vorkommen.

5.1.3.2.1 HaltInfoSollGroup

5.1.3.2.2 Geplante Anschlüsse (SollAnschluss)

Die Information darüber, welche Anschlüsse im Laufe des Betriebstags bei normalen Bedin- gungen zustande kommen sollen, ist für das Auskunftssystem interessant. Daher sollen diese Fahrtenpaare mit den Solldaten an das Auskunftssystem übertragen werden. Das Auskunfts- system kennzeichnet solche Anschlüsse gegenüber dem Benutzer mit Texten der Art "An- schluss wird in der Regel abgewartet".

Die geplanten Anschlüsse werden in der Struktur SollAnschluss übermittelt:

VDV 454 Version 3.1.0 55 23.09.2024

[Seite 62]

Fachliche Dienste VDV 454

Die Struktur SollAnschluss kann (auch mehrfach) als Unterelement der Struktur SollHalt auf- treten. Durch die Angaben in SollHalt sind die Zubringerdaten des Anschlusses gegeben, die Daten der Abbringerfahrt finden sich in SollAnschluss.

Implementierungshinweis:

Wenn für Anschlussinformationen sowohl Planungs-wie auch Prozessdaten übertragen wer- den, sollten ausschließlich die Elemente AnschlussPlan (für die Planungsdaten) und An- schlussStatus (für die Prozessdaten) verwendet werden (vgl. Kapitel 0).

Bei ausschließlicher Übertragung der Planungsinformation kann auch weiterhin das Element SollAnschluss verwendet werden.

Folgendes Beispiel zeigt einen Sollfahrplan der Linie 100, bestehend aus nur einer Fahrt mit sechs Haltepunkten und einem geplanten Sollanschluss am zweiten Haltepunkt, wobei der Abbringer am selben Haltepunkt abfährt.

<AUSNachricht AboID = "25> de:vbb:11000000|Bus|100:2 HIN de:vbb:11000000|Bus|100:2:123 2001-07-21 de:11000:900023175 2001-07-21T09:30:00 de:11000:900023176 2001-07-21T09:35:00 2001-07-21T09:36:00 2A de:vbb:11000000|Bus|100:2:123

VDV 454 Version 3.1.0 56 23.09.2024

[Seite 63]

Fachliche Dienste VDV 454

5.1.3.3 Informationen zu betrieblichen Fahrtidentifikatoren (BetrieblicheFahrtnum- mern)

Über das Element BetrieblicheFahrtnummern lassen sich die für manche Infrastruktureinrich- tungen, wie z.B. Gleisanzeigern, betrieblich notwendige Identifikatoren komplett unabhängig vom Fahrtbezeichner übertragen.

VDV 454 Version 3.1.0 57 23.09.2024

[Seite 64]

Fachliche Dienste VDV 454

Abbildung 5 Element "BetrieblicheFahrtnummer"

Das Element "BetrieblicheFahrtnummern" ist als "optional" gekennzeichnet, da nicht für jede Fahrt die Übermittlung der betrieblichen Fahrtidentifikatoren sinnvoll ist. Sobald jedoch ein betrieblicher Identifikator übertragen werden soll, müssen zwingend die Elemente "Betriebli- cheFahrtnummern" und "BetrieblicheFahrtnummer", einschließlich der Unterelemente, ange- geben werden.

5.1.3.3.1 BetrieblicheFahrtnummerFahrtAbschnitt

Die Eckdaten des Fahrtabschnitts - erster und letzter Halt des Fahrtabschnitts jeweils mit den Sollzeiten an diesen Halten - sind zusammengefasst in der Struktur BetrieblicheFahrtnummer- FahrtAbschnitt:

VDV 454 Version 3.1.0 58 23.09.2024

[Seite 65]

Fachliche Dienste VDV 454

5.1.3.4 Informationen zur Formation der SollFahrt (SollFormation)

Die Struktur "SollFormation" innerhalb der "SollFahrt" umfasst alle für den Tagesfahrplan be- kannten Formationsinformationen.

Abbildung 6 Element "SollFormation"

Alle Formationsinformationen, die abhängig von der SollFahrt sind, sind dem Element "Soll- Formation" zugeordnet:

VDV 454 Version 3.1.0 59 23.09.2024

[Seite 66]

Fachliche Dienste VDV 454

5.1.3.5 Übermittlung der Zeitfenster, Erstmeldung, Aktualisierungen

Im VDV454 REF-AUS dient die mehrfache Struktur Zeitfenster zwei Zwecken:

• Übermittlung des abonnierten Zeitfensters (5.1.3.5.1 )

• Übermittlung zusätzlicher Zeitfenster mit disponierten Fahrten (5.1.3.5.2 )

Alle übermittelten Zeitfenster beschreiben auf Seite des Datenkonsumenten Bereiche, in wel- chen alle darin startenden Fahrten des Periodenfahrplans durch die neu übermittelten Fahrten ersetzt werden. Dies muss vom Datenlieferanten beim Setzen von GueltigVon und GueltigBis entsprechend beachtet werden, weil es sonst vorkommen kann, dass der Datenkonsument fälschlicherweise Fahrten als ausfallend markiert (mehr Details folgen).

Vorerst ohne Betrachtung der disponierten Fahrten unterscheiden sich das bestätigte abon- nierte Zeitfenster und die zusätzlich übermittelten Zeitfenster grundsätzlich in folgendem Punkt:

Im bestätigten abonnierten Zeitfenster werden folgende Fahrten geliefert:

• Fahrten, welche innerhalb des bestätigten abonnierten Zeitfensters starten.

• Fahrten, welche vor GueltigVon des bestätigten abonnierten Zeitfensters starten und bei welchen die Ankunftszeit von mindestens einem SollHalt nach GueltigVon des

VDV 454 Version 3.1.0 60 23.09.2024

[Seite 67]

Fachliche Dienste VDV 454

bestätigten abonnierten Zeitfensters liegt. Diese Fahrten werden der Einfachheit halber im Rest des Dokumentes "Fahrten, welche vor GueltigVon beginnen" genannt (seit VDV454 v3.0 steht das Element MitBereitsAktivenFahrten im AboAUSRef nicht mehr zur Verfügung, jetzt müssen im bestätigten abonnierten Zeitfenster immer alle "Fahr- ten, welche vor GueltigVon beginnen", mitgesendet werden).

Im Umkehrschluss bedeutet das, dass der Abnehmer Fahrten, die laut Jahressollfahr- plan zwar vor dem bestätigten abonnierten Zeitfenster starten und bei welchen die An- kunftszeit von mindestens einem SollHalt nach GueltigVon des bestätigten abonnierten Zeitfensters liegt, als ausfallend annehmen muss, wenn sie in der Lieferung nicht ent- halten sind.

In zusätzlich übermittelten Zeitfenstern werden folgende Fahrten geliefert:

• Fahrten, welche innerhalb des zusätzlich übermittelten Zeitfensters starten.

• Es werden keine Fahrten geliefert, welche vor dem zusätzlich übermittelten Zeitfenster starten.

Betrachtung von disponierten Fahrten bezüglich GueltigVon und GueltigBis:

Folgende Fahrten müssen möglichst mitgesendet werden, weil sonst vom Datenkonsumenten fälschlicherweise die ganze Fahrt als ausfallend markiert wird:

• Fahrten, bei welchen der ursprünglich geplante Start vor GueltigBis liegt, der neu dis- ponierte Start jedoch nach GueltigBis.

• Fahrten, bei welchen das ursprünglich geplante Ende nach GueltigVon liegt, das neu disponierte Ende jedoch vor GueltigVon (nur im bestätigten abonnierten Zeitfenster).

Folgende Fahrten müssen möglichst mitgesendet werden, weil sonst dem Datenkonsumenten beim Empfang dieser IstFahrt im AUS die entsprechende SollFahrt fehlt

• Fahrten, bei welchen der ursprünglich geplante Start nach GueltigBis liegt, der neu disponierte Start jedoch vor GueltigBis, darf es gar nicht geben, weil in diesem Fall GueltigBis auf die ursprünglich geplante Start-Sollabfahrtszeit dieser Fahrt gesetzt wer- den muss (siehe 5.1.3.5.2 ).

• Fahrten, bei welchen das ursprünglich geplante Ende vor GueltigVon liegt, das neu disponierte Ende jedoch nach GueltigVon (nur im bestätigten abonnierten Zeitfenster).

5.1.3.5.1 Übermittlung des abonnierten Zeitfensters

Da das Ende des Betriebstages des eigenen ITCS in der Regel nicht mit dem Ende des Be- triebstages eines Fremd-ITCS übereinstimmt, muss davon ausgegangen werden, dass eine Bereitstellung von Daten nicht für den gesamten Anfragezeitraum erfolgen kann. Damit der Datenkonsument (Datendrehscheibe oder Auskunftssystem) Kenntnis von dieser Situation

VDV 454 Version 3.1.0 61 23.09.2024

[Seite 68]

Fachliche Dienste VDV 454

erhält, muss im LinienFahrplan zwingend mittels der Struktur Zeitfenster bestätigt werden, wel- cher Teil des abonnierten Zeitbereiches auch wirklich geliefert werden kann.

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.

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 AboAUSRef mit "notok" und einer Fehlernummer aus dem Bereich 300-399 (falls MitZusaetzlichenZeitfenstern in AboAUSRef nicht gesetzt ist, an- dernfalls bleibt das Abo eingerichtet für den Fall von kommenden Fahrwegdispositionen, siehe 5.1.4 ).

Erstmeldung

In der Erstmeldung unmittelbar nach dem Aufsetzen von AboAUSRef müssen immer möglichst alle Fahrten des abonnierten Zeitfensters übermittelt werden mit der Angabe, welcher Zeitbe- reich des abonnierten Zeitfensters abgedeckt werden kann (mit GueltigVon und GueltigBis bestätigtes abonniertes Zeitfenster).

Aktualisierungen

Seit VDV454 v3.0 wird das AboAUSRef bis zum Erreichen des VerfallZst aktiv gehalten. So lange das Abonnement aktiv ist, kann der Datenlieferant laufend neue oder aktualisierte Lini- enfahrpläne nachliefern. Sendet der Datenlieferant eine Aktualisierung des gesamten Linien- fahrplans, kann er beim bestätigten abonnierten Zeitfenster GueltigVon auf die aktuelle Zeit nach hinten schieben (falls die aktuelle Zeit zwischen den im AboAUSRef geforderten Guel- tigVon und GueltigBis liegt), dann müssen jedoch die "Fahrten, welche vor GueltigVon begin- nen" (siehe 5.1.3.5 ), mitgesendet werden.

Wann soll der Datenlieferant eine Aktualisierung eines Linienfahrplans übermitteln?

• Eine Aktualisierung wird z.B. gesendet, wenn der Datenlieferant weitere Daten für den abonnierten Gültigkeitszeitraum vorliegen hat.

• Werden nur Fahrten des aktuellen Betriebstages disponiert, welche in einer vorherigen Meldung innerhalb des bestätigten abonnierten Zeitfensters gesendet wurden, wird empfohlen, diese Aktualisierungen nur im AUS über die abonnierte AUS-Vorschauzeit hinaus mittels Komplettfahrten unter Verwendung von OriginalSollFahrtverlauf vorzu- nehmen. Der Datenlieferant kann dies je nach Implementierung auch zum Anlass neh- men, eine Aktualisierung des Linienfahrplans zu versenden. Dies entbindet den Daten- lieferanten jedoch nicht davon, diese Dispositionen auch im AUS-Dienst bekanntzuge- ben.

• Werden Fahrten von zukünftigen Betriebstagen disponiert und im AboAUSRef war Mit- ZusaetzlichenZeitfenstern='true' gesetzt, sendet der Datenlieferant eine Aktualisierung des gesamten Linienfahrplans beim Aufsetzen, Ändern oder Löschen einer Disposition.

VDV 454 Version 3.1.0 62 23.09.2024

[Seite 69]

Fachliche Dienste VDV 454

Beispiel

Der Abnehmer hat Daten von 06:00 bis 06:00 Folgetag abonniert. Bei Beginn des Abos kann der Datenlieferant nur Daten von 06:00 bis 03:00 Folgetag bereitstellen.

Um 15:30 wird eine Disposition für kommende Woche aufgesetzt. Der Datenlieferant sendet eine Aktualisierung des gesamten Linienfahrplans, vom abonnierten Zeitfenster den Teil ab 15:30 bis 03:00 Folgetag inklusive "Fahrten, welche vor GueltigVon beginnen" (siehe 5.1.3.5 ) und (falls abonniert) das zusätzliche Zeitfenster für den disponierten Zeitraum der kommen- den Woche.

Um Mitternacht werden Daten für den neuen Betriebstag geladen, wodurch der Datenlieferant nun auch die zuvor fehlenden abonnierten Daten vom Zeitraum 03:00 bis 06:00 hat. Er sendet wieder eine Aktualisierung des gesamten Linienfahrplans, vom abonnierten Zeitfenster den Teil ab Mitternacht diesmal bis 06:00 inklusive "Fahrten, welche vor GueltigVon beginnen" (siehe 5.1.3.5 ) und (falls abonniert) das zusätzliche Zeitfenster für den disponierten Zeitraum der kommenden Woche.

5.1.3.5.2 Zusätzliche Übermittlung von Zeitfenstern mit disponierten Fahrten

Falls das AboAUSRef mit dem Element MitZusaetzlichenZeitfenstern='true' eingerichtet wurde, wird bei jeder Änderung einer Fahrwegdisposition der bestätigte Teil des abonnierten Zeitfensters und alle wegen Fahrwegdispositionen zusätzlich benötigten Zeitfenster des be- troffenen Linienfahrplans neu übermittelt, mehr Details dazu s. Kapitel 5.1.4 .

VDV 454 Version 3.1.0 63 23.09.2024

[Seite 70]

Fachliche Dienste VDV 454

5.1.4 Übermittlung disponierter Fahrten Tage im Voraus

Mit einer Reihe von Anpassungen werden ab VDV453/VDV454 v3.0 folgende Anforderungen erfüllt:

• Neu können über die VDV454-Schnittstellen auch Fahrten der folgenden Betriebstage übermittelt werden (falls im AboAUSRef MitZusaetzlichenZeitfenstern auf ‘true’ gesetzt war, siehe 5.1.1 ). Wenn ein Disponent eine Fahrwegdisposition für die folgenden Tage aufsetzt, dann ist es den Auskunftssystemen ein großes Anliegen, die Fahrgäste bei ihrer Reiseplanung sofort über die angepassten Fahrtverläufe zu informieren, was so- mit ermöglicht wird.

• Bisher haben viele Datenlieferanten im REF-AUS Fahrwegdispositionen nicht berück- sichtigt, weil sonst der Datenkonsument die empfangenen disponierten Fahrten nicht

VDV 454 Version 3.1.0 64 23.09.2024

[Seite 71]

Fachliche Dienste VDV 454

mehr seinen vorliegenden geplanten Fahrten zuordnen konnte. Durch die Möglichkeit, jeweils den originalen Sollfahrtverlauf mitzusenden, kann diese Zuordnung jetzt ermög- licht werden. Bei allen Fahrten mit geändertem Fahrtweg, sollte möglichst der Original- SollFahrtverlauf mitgeliefert werden.

• Neu wird das REF-AUS-Abo nach der Übermittlung der ersten Daten nicht mehr ge- löscht, sondern bleibt aktiv, damit bei Änderungen von Fahrwegdispositionen laufend Aktualisierungen gesendet werden können. Deshalb wird der abonnierte Zeitbereich auch nicht mehr in der AboAntwort quittiert, sondern erst mittels Zeitfenster im Linien- Fahrplan. Dies bringt auch den großen Vorteil mit sich, dass die Datendrehscheiben REF-AUS-Daten mit unterschiedlichen Zeitfenstern empfangen und weiterleiten kön- nen. Aus diesem Grund werden auch bei AboASBRef und AboAZBRef die abonnierten Zeitbereiche nicht mehr in der AboAntwort quittiert, sondern erst mittels Zeitfenster in der neu eingeführten Zwischenebene ASBLinienFahrplan/AZBLinienFahrplan.

• Damit bei einer kleinen Fahrwegdisposition in ferner Zukunft nicht der komplette Be- reich ab jetzt bis zu diesem Zeitpunkt übermittelt werden muss, können mehrere klei- nere Zeitfenster übermittelt werden.

• Beim Aufsetzen, Löschen oder Ändern einer Fahrwegdisposition müssen immer alle Zeitfenster eines LinienFahrplans komplett übermittelt werden, mit allen disponierten und nicht disponierten Fahrten (inklusive dem möglichst kompletten abonnierten Zeit- fenster). Die Lücken zwischen den übermittelten Zeitfenstern müssen vom Datenkon- sumenten jeweils auf die ursprünglich geplanten Fahrten aus dem Periodenfahrplan zurückgesetzt werden.

• Damit die gleiche Fahrt nicht mehrfach übermittelt werden muss, wird sie einmal für einen bestimmten Betriebstag angegeben zusammen mit der Struktur WeitereBetrieb- stage, welche die Liste der Betriebstage beinhaltet, an welchen diese Fahrt auch noch stattfindet.

• Optional können zu einer disponierten Fahrt die DispoIDs aller Fahrwegdispositionen angeben werden, welche die Fahrt betreffen (hilft z.B. bei Log-Analyse).

• Nach jedem Neustart eines Schnittstellenpartners wird das AboAUSRef neu aufgesetzt und es werden die Linienfahrpläne mit dem möglichst kompletten abonnierten Zeitfens- ter und allen zusätzlichen disponierten Zeitfenstern übermittelt.

• Die Struktur LinienFahrplan beinhaltet neu zwei Alternativen:

o Die eine Alternative Zuruecksetzen (ermöglicht ein Zurücksetzen eines Linien- fahrplans, ohne dass dazu ein neuer StartDienstZst gesetzt werden muss)

o Die andere Alternative mit der ursprünglichen Sequenz für die Übermittlung ei- nes LinienFahrplans.

• In der Lieferung eines LinienFahrplans dürfen sich dessen Zeitfenster nicht überlap- pen.

VDV 454 Version 3.1.0 65 23.09.2024

[Seite 72]

Fachliche Dienste VDV 454

• Über den AUS-Dienst empfangene Fahrten haben immer Priorität gegenüber Fahrten aus nachgelieferten REF-AUS-Daten.

• Wenn ein leerer LinienFahrplan übermittelt wird, werden sämtliche Fahrten inkl. der disponierten Fahrten gelöscht.

Beispiel

Angenommen, alle Fahrten der Werktage der nächsten drei Wochen seien mit der gleichen Tagesart "Mo-Fr" versorgt, im AboAUSRef mit Zeitfenster 03:00 bis 06:00 Folgetag war Mit- ZusaetzlichenZeitfenstern auf 'true' gesetzt und am Donnerstag um 16:00 Uhr wird eine Fahr- wegdisposition für die Werktage der nächsten zwei Wochen jeweils von 18:00 bis 03:00 Fol- getag aufgesetzt.

In diesem Fall sendet der Datenlieferant den aktualisierten LinienFahrplan mit dem bestätigten abonnierten Zeitfenster von 16:00 bis 06:00 Folgetag inklusive "Fahrten, welche vor Gueltig- Von beginnen" (siehe 5.1.3.5 ) und zusätzlich die zehn disponierten Zeitfenster. Da die Fahrten des abonnierten Zeitfensters nicht disponiert sind, werden diese einmal mit dem aktuellen Be- triebstag in der FahrtID gesendet und für die disponierten Fahrten werden die Fahrten vom ersten Montag von 18:00 bis 03:00 Folgetag mit dessen Betriebstag in der FahrtID gesendet, jeweils mit den neun weiteren Betriebstagen in WeitereBetriebstage.

Der Datenlieferant muss gewährleisten, dass in der Datenlieferung alle Fahrten der aufgelis- teten Zeitfenster komplett enthalten sind.

5.2 Istdatendienst AUS

Mit diesem Dienst teilt das ITCS dem Auskunftssystem den aktuellen Zustand aller bekannten Fahrten mit. Damit wird das Auskunftssystem in die Lage versetzt, sehr zeitnah Auskünfte für kurzfristige Reiseplanungen zu erteilen.

Wie beim Solldatendienst darf das ITCS dem Auskunftssystem auch nur die produktiven An- teile der Fahrten übermitteln.

5.2.1 Ist-Daten Anfrage (AboAUS)

Mit der AboAUS-Anfrage abonniert das Fahrplanauskunftssystem beim ITCS oder einer DDS Ist-Daten für alle oder einige Linien, oder einzelne Fahrten (für die keine Liniendefinition exis- tiert).

AboAUS enthält folgende Elemente:

VDV 454 Version 3.1.0 66 23.09.2024

[Seite 73]

Fachliche Dienste VDV 454

VDV 454 Version 3.1.0 67 23.09.2024

[Seite 74]

Fachliche Dienste VDV 454

Werden keine Filter als Abonnement-Filter angegeben, wird implizit die Übertragung der Daten für alle dem ITCS bekannten Fahrten gewünscht.

5.2.2 Ist-Daten übermitteln

Die Ist-Daten werden in der Antwortstruktur IstFahrt übertragen. Diese Elemente sind einge- bettet in das Element AUSNachricht, welches alle Rückantworten des Auskunftsdiensts zu- sammenfasst (vgl. Kapitel 5.1.2 ).

Bei Beginn des Abonnements ist das ITCS dafür zuständig, dem Auskunftssystem den aktu- ellen Gesamtzustand zu übermitteln.

VDV 454 Version 3.1.0 68 23.09.2024

[Seite 75]

Fachliche Dienste VDV 454

Um die Unabhängigkeit der Dienste AUS und REF-AUS zu wahren, müssen einmal Informa- tionen für die komplette Fahrt einschließlich neuer Planungs- und Prognosezeiten gesendet werden.

Bei gleichzeitiger Anwendung des REF-AUS Dienstes kann das ITCS alternativ nur die Ist- Daten senden, welche zum Abonnementstart vom Tagessollfahrplan abweichen.

Meldungen zur Ist-Datenlage können folgende logische Inhalte haben:

1. Fahrplanabweichungen mit Prognose für in der Zukunft liegende Streckenabschnitte (ein- schließlich der Abfahrt am aktuellen Halt),
2. Ausfall einer Fahrt,
3. Änderung der Fahrzeugauslastung
4. Änderung des Transportgefäßtyps/Fahrzeugausstattung,
5. Gleisänderung,
6. Haltestellensperrung,
7. Fahrwegabweichungen,
8. Formationen einer Fahrt (Fahrzeuggruppierung, Fahrzeugbelegung, Fahrzeugausstat- tung und Zustände, Fahrzeugpositionen am Halt)

Kurz: Jede Änderung gegenüber dem übertragenen Soll-Fahrplan ist darstellbar und kann dem Auskunftssystem mitgeteilt werden.

5.2.2.1 Istdaten einer Fahrt (IstFahrt)

Eine Änderungsmeldung wird in der Struktur IstFahrt innerhalb von AUSNachricht mitgeteilt. Es können mehrere Fahrten angegeben werden.

VDV 454 Version 3.1.0 69 23.09.2024

[Seite 76]

Fachliche Dienste VDV 454

VDV 454 Version 3.1.0 70 23.09.2024

[Seite 77]

Fachliche Dienste VDV 454

VDV 454 Version 3.1.0 71 23.09.2024

[Seite 78]

Fachliche Dienste VDV 454

Implementierungshinweis: Der Mittelabschnitt einer Fahrt wird durch eine dispositive Mass- nahme so verlängert, dass es bei der Eintritts-Haltestelle zu überlappenden Sollzeiten kommt. Wie soll jetzt die komplette IstFahrt übermittelt werden?

Wenn der alternative Fahrweg länger als der ursprüngliche dauert, wird die Fahrzeit für diesen Abschnitt künstlich gestrafft, um auf jeden Fall chronologisch monoton steigende Werte an das Auskunftssystem zu übermitteln.

VDV 454 Version 3.1.0 72 23.09.2024

[Seite 79]

Fachliche Dienste VDV 454

5.2.2.1.1 Originalsollfahrtverlauf (OriginalSollFahrtverlauf)

In der Struktur OriginalSollFahrtverlauf werden alle Informationen zum ursprünglichen Fahrt- verlauf (alle Sollhalte aus REF-AUS od. Periodenfahrplan) übermittelt. Zusätzlich können Aus- fälle und deren Ursachen übermittelt werden.

Die disponierten Zeiten werden in der Ankunftszeit und Abfahrtszeit im IstHalt eingetragen. Dispositionen einer Fahrt verändern die ursprünglichen Sollhalte daher nicht, mit Ausnahme der Ausfallmarkierung und der Ausfallursache.

Das Matching auf die Sollfahrt und die Verlinkung zwischen Sollfahrten (GesAnschluss, Fahrt- beziehung, etc.) erfolgen bei Verwendung dieses Elements über die Struktur OriginalSollFahrt- verlauf.

5.2.2.1.2 OriginalSollHalt

Der Originalsollhalt entspricht fachlich demjenigen, der unter REF-AUS übermittelt wird. Zu- sätzlich kann jeder Halt als Ausfall markiert und begründet werden.

5.2.2.2 Referenzierung der Fahrtdaten (FahrtRef)

Damit die Ist-Daten-Meldungen im Auskunftssystem auf den Soll-Fahrplan bezogen werden können, kann bei Einrichtung des Referenzdatendienstes REF-AUS die FahrtID der Struktur LinienFahrplan aus Kapitel 5.1.3 zur Identifikation einer Fahrt innerhalb einer Linie herange- zogen werden.

Für Installationen, bei denen auf den Soll-Datenaustausch mittel des REF-AUS-Dienstes ver- zichtet wird, können die Eckdaten einer Fahrt, nämlich erster und letzter Halt der Fahrt jeweils mit den Sollzeiten an diesen Halten verwendet werden, um einen Bezug zum Sollfahrplan herzustellen. Damit ist die Verwendung des REF-AUS-Dienstes nicht zwingend erforderlich. (5.2.2.2.1 Alternative Referenzierungsinformation (FahrtStartEnde)

Beide Informationen sind in der Struktur FahrtRef zusammengefasst:

VDV 454 Version 3.1.0 73 23.09.2024

[Seite 80]

Fachliche Dienste VDV 454

Beide Elemente sind aus historischen Gründen optional. Mindestenes eine von beiden Infor- mationen muss allerdings angegeben werden, entweder FahrtID oder FahrtStartEnde.

Vom VDV-Gremium wird jedoch dringend empfohlen, immer beide Elemente FahrtID und FahrtStartEnde zu übermitteln. Es ist beabsichtigt, zukünftig beide Elemente verpflichtend zu fordern.

Werden IDs analog VDV433 verwendet, ist im Feld Fahrtbezeichner die DFID einzufüllen.

5.2.2.2.1 Alternative Referenzierungsinformation (FahrtStartEnde)

Die Eckdaten einer Fahrt - erster und letzter Halt der Fahrt jeweils mit den Sollzeiten an diesen Halten - sind zusammengefasst in der Struktur FahrtStartEnde:

FahrtStartEnde der jeweiligen SollFahrt, sowie der darauf referenzierenden IstFahrt darf nach der ersten Erfassung der SollFahrt nicht mehr verändert werden, da ansonsten die Referen- zierung mittels FahrtStartEnde nicht mehr möglich ist.

Für jede SollFahrt kann es jeweils nur genau eine referenzierende IstFahrt geben.

VDV 454 Version 3.1.0 74 23.09.2024

[Seite 81]

Fachliche Dienste VDV 454

Beispiel:

Abbildung 7

Bei Zusatzfahrten gelten für FahrtStartEnde ebenfalls die Angaben betreffend der ersten Er- fassung dieser Zusatzfahrt.

Beispiel:

Wird z.B. eine Kürzung des Fahrtweges der IstFahrt gegenüber der ursprünglichen SollFahrt durchgeführt, behält die angepasste IstFahrt die Werte des Elementes FahrtStartEnde der SollFahrt bei. Eine ggf. zur Abdeckung des Restfahrweges eingesetzte Zusatzfahrt, muss dann mit einem neuen FahrtStartEnde (Restfahrweg) versehen werden.

Hinweis: Nur mit dieser Fahrtidentifikation alleine sind nicht mehrere Fahrten abbildbar, bei denen sowohl Start und Ende örtlich und zeitlich identisch sind. Solche Fahrten sind mit der FahrtStartEnde-Identifikation nicht unterscheidbar, können aber in einem ITCS unter verschie- denen FahrtIDs geführt werden und unterschiedliche Prognosen aufweisen

VDV 454 Version 3.1.0 75 23.09.2024

[Seite 82]

Fachliche Dienste VDV 454

5.2.2.3 Informationen zum Halt (IstHalt)

Die Struktur IstHalt umfasst mögliche Änderungen gegenüber dem planmäßigen SollHalt:

5.2.2.3.1 AbfahrtAusGroup

VDV 454 Version 3.1.0 76 23.09.2024

[Seite 83]

Fachliche Dienste VDV 454

5.2.2.3.2 AbfahrtStatusGroup

5.2.2.3.3 AnkunftAusGroup

VDV 454 Version 3.1.0 77 23.09.2024

[Seite 84]

Fachliche Dienste VDV 454

5.2.2.3.4 AnkunftStatusGroup

5.2.2.4 Formation der IstFahrt (IstFormation)

Die Struktur IstFormation innerhalb der IstFahrt umfasst mögliche Änderungen gegenüber der planmäßigen SollFormation aus der SollFahrt.

Abbildung 8 Element "IstFormation"

VDV 454 Version 3.1.0 78 23.09.2024

[Seite 85]

Fachliche Dienste VDV 454

Alle Formationsinformationen, die abhängig von der IstFahrt sind, sind dem Element "IstFor- mation" zugeordnet:

5.2.2.4.1 Fahrzeuge der Formation (FoFahrzeuge)

Das Element kann sowohl innerhalb der "IstFormation" als auch innerhalb der "SollFormation" verwendet werden.

VDV 454 Version 3.1.0 79 23.09.2024

[Seite 86]

Fachliche Dienste VDV 454

Abbildung 9 Element "FoFahrzeuge"

Sowohl das Element "FoFahrzeuge" als auch "FoFahrzeug" müssen zwingend angegeben werden, sobald Formationselemente über die VDV454 Schnittstelle übertragen werden.

VDV 454 Version 3.1.0 80 23.09.2024

[Seite 87]

Fachliche Dienste VDV 454

5.2.2.4.1.1 Ausstattungen von Fahrzeugen (FoFahrzeugAusstattungen)

Abbildung 10 Element "FoFahrzeugAusstattungen"

Das übergeordnete Element "FoFahrzeugAusstattungen" ist optional. Sobald dies jedoch ver- wendet wird, ist zwingend ein Unterelement ("FoFahrzeugAusstattung") anzugeben.

5.2.2.4.1.2 Technische Attribute von Fahrzeugen (FoTechnischeAttribute)

Definition FoTechnischeAttribute

VDV 454 Version 3.1.0 81 23.09.2024

[Seite 88]

Fachliche Dienste VDV 454

Abbildung 11 Element "FoTechnischeAttribute"

Das übergeordnete Element "FoTechnischeAttribute" ist optional. Sobald dies jedoch verwen- det wird, ist zwingend ein Unterelement "FoTechnischesAttribut" anzugeben.

5.2.2.4.1.3 Fahrzeugbereiche (FoFahrzeugBereich)

VDV 454 Version 3.1.0 82 23.09.2024

[Seite 89]

Fachliche Dienste VDV 454