UC:TT:PassengerInformationAtStations

From railML 2 Wiki
Jump to navigation Jump to search
🗒️ This page is mirrored from page UC:TT:PassengerInformationAtStations in The railML® 3 wiki.
Passenger information at stations
(PISY)
Subschema: Timetable and Rostering
 
Related subschemas: IS RS 
Reported by: PSI
Finish.png (version(s) 3.2)
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

Passenger information at stations / Fahrgastinformation am Bahnhof

Allgemein

Ein Fahrgastinformationssystem dient der Darstellung von fahrplanbezogenen Informationen auf Anzeigern und in Form von Ansagen zu

  • Zügen: nächste abfahrende Zügen, anbekommende Züge
  • Fahrplanänderungen: Soll-Fahrplan und Ist-Fahrplan (Verspätungslage), Zugausfälle, Zielwechsel (Zug fahrt nicht bis zur letzte Station)
  • Formationen: Umgekehrte Reihung, Fehlende Wagen, Ersatz Wagen (IC statt ICE), fehlender Bordbistro
  • Haltepositionen: Gleiswechsel, Sektoren der verschiedene Wagen und Richtung bei Flügelzüge
  • Anschlüssen: Ansage, dass den Zug nach XX nicht gewartet hat und die nächste Reisemöglich nach XX
  • Zug Durchfahrt ansagen (Güterzüge oder ICE der nicht überall hält) zu Fahrgastsicherheit

Da FGI-Systeme Informationen zur unmittelbaren Zukunft darstellen, werden diese Daten nur mit kurzem Planungshorizont benötigt. Typischerweise werden einzelne Betriebstage oder Teile davon importiert. Das FGI System kann entweder die Prognose selbst berechnen oder importieren. In diesem letzten Fall werden vor allem Echtzeit Daten benötigt.

Infrastruktur

FGI Systeme setzen oft auf mesoskopischen Infrastrukturdaten auf. Es wird ein Netz der Verbindungen zwischen Station und Blockstellen importiert. Innerhalb der Stationen sind Informationen zu den Gleisen erforderlich, sowie zu Haltpositionen. Auch die Beziehung zwischen Gleisen und Bahnsteig kann für FGI Systeme relevant sein. Diese Daten sind Voraussetzung für u. a. folgende Funktionen:

  • Gleiswechsel und deren Ankündigung
  • Sonderzüge, die im FGI System direkt eingegeben werden können
  • Spontane Streckenstörungen und Gleissperrungen, die im FGI System eingerichtet werden können (Personenschaden, Unfälle mit Straßenfahrzeugen)
  • Sektorgenaue Ankündigung der Halteposition von Zügen bzw. Zugteilen

Blockstellen werden durch ein FGI System dazu benötigt, um die Fahrzeuge genauer orten zu können und darauf basierend präzisere Prognosen errechnen zu können. Es sind natürlich auch FGI Systeme vorstellbar, die diese Berechnung nicht selber durchführen; Für diese Systeme sind Infrastrukturdaten bis auf Blockstellenebene dann nicht notwendig.

Detaillierterer Infrastrukturinformationen wie Neigungswinkel, Kurvenradien o. ä. sind in der Regel für FGI Systeme nicht erforderlich. Ausnahme stellen Systeme dar, die Ortung auf Basis von GPS Koordinaten vornehmen. In diesem Fall sind genaue Angaben zum Verlauf der Strecke natürlich unerlässlich.

Rollingstock

Um Eigenschaften von Fahrzeugen an den Fahrgast kommunizieren zu können sind Daten zu den Fahrzeugen und Formationen erforderlich. Folgende Informationen von Fahrzeugen sind u. a. relevant:

  • 1. Klasse/2.Klasse
  • Speisewagen
  • Fahrradmitnahme
  • Güterwagen
  • Lokomotive ohne Fahrgastraum
  • Länge der Fahrzeuge (um auf Basis der Halteposition des Zuges die Sektoren zu errechnen)

Auf Basis dieser Daten können durch das FGI System Wagenstandanzeigen generiert werden, und auf den Displays die Haltepositionen der Zugteile abgebildet werden, was speziell bei der Anzeige von Flügelzügen oder solchen, die später im Zuglauf geschwächt werden sollen, von großer Bedeutung ist.

Genauere Informationen zu den Fahrzeugen, wie das Gewicht, die Bremskraft o. ä. werden für den Betrieb eines FGI-Systems am Bahnhof nicht benötigt.

Timetable

Für den Betrieb eines FGI Systems werden Fahrplandaten mit kurzem Planungshorizont benötigt. Häufig werden nur die Daten für den aktuellen und den folgenden Betriebstag in das System importiert (der folgende Betriebstag wird dabei oft dazu verwendet am Vortag bereits anzuzeigende Sonderinformationen in das System einzupflegen). Benötigt werden die betrieblichen und kommerziellen Züge um flügelnde und kuppelnde Züge abbilden zu können. Es muss für das FGI System möglich sein, zu bestimmen, welche Züge am zu importierenden Betriebstag unterwegs sein werden und in welcher Konfiguration. Folgende Informationen werden benötigt:

  • Zugnummer
  • Linie
  • Zuggattung
  • Gültigkeit (Operating Period) und Ausfallinformationen
  • Formation
  • Zugbehandlungen (Flügeln, Kuppeln, Schwächen, Verstärken, Zugtausch – wie bildet man eigentlich einen Zugtausch in railML 2 ab?)
  • Ursprungs und Zielort (sofern nicht aus dem Zuglauf bekannt – Stichwort „Einbrechende und ausbrechende Verkehre“)
  • Zuglauf mit jeweils:
    • Geplanter Ankunft und Abfahrtszeit
    • Gleisinformationen
    • Haltepunktinformationen
    • Bedarfshalt, Durchfahrt, Halt
    • Mindesthaltezeiten und Mindestfahrzeiten
    • Betriebshalt/kommerzieller Halt
    • Anschlussinformationen
    • Wendeinformationen
  • Umlaufinformationen (um Auswirkungen von Verspätungen auf Folgefahrten prognostizieren zu können)
  • Fahrplanänderungen (Änderungen der Kurzfristplanung im Vergleich zur Langfristplanung)

Zusätzlich könnten natürlich auch weitere Daten, die sich direkt auf die anzukündigenden Informationen beziehen importiert werden. So könnten etwa pro Station Ziel- oder Viatexte importiert werden, die für den entsprechenden Zug an einem Bahnhof anzuzeigen sind. Das ist z. B. dann sinnvoll, wenn für einen Fernzug an Bahnhöfen im Ausgangsgebiet nur eine Region als Ziel angekündigt werden oder eine Ringlinie beauskunftet werden soll. Ebenso könnten geplante Sondertexte bereits aus railML importiert werden, etwa solche, die auf einen besonderen Zuschlag für den Zug hinweisen, oder Werbung beinhalten, die im Kontext des Zuges zu Anzeige gebracht werden soll.