UC:TT:PassengerInformationAtStations: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[unchecked revision][checked revision]
No edit summary
(integrated feedback from init review)
(16 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{useCase|TT|2.4|title=Passenger information at stations|IS=1|RS=1|reporter=PSI}}


'''Use case / {{Deu|Anwendungsfall}} / {{Fra|Scénario d’utilisation}}: '''
{{UC title}}
Passenger information at stations / {{Deu|Fahrgastinformation am Bahnhof}} / {{Fra|Information voyageurs en station}}


''Passenger information at stations / {{Deu|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.


'''Description / {{Deu|Beschreibung}} / {{Fra|Description}} '''
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.


This use case describes the exchange of data between a system for providing passenger information at a railway station and a timetable planning system. The PIS allows for display of the current schedule including information about the current state of operation such as delays, cancelation or additional trains. In order to do so the schedule as published to the passenger for the current day of operation is necessary. The completeness of this timetable information limits the accuracy of the information available to the passenger by means of the PIS. The mandatory data can be limited to the services run on the current operation day, including all stops of a train with the according arrival and departure times. Additional information for can be provided to model blocks of services (can be used to increase accuracy of forecast information), planned interconnection with other services, planned construction sites with impact on the services, etc.
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==
'''Data Flows and Interfaces / {{Deu|Datenflüsse und Schnittstellen}} / {{Fra|Flux de données et interfaces}} '''
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:
A PIS is a pure railML consumer.
*Zugnummer
 
*Linie
Mandatory information imported from timetable system includes:
*Zuggattung
 
*Gültigkeit (Operating Period) und Ausfallinformationen
* <train>
*Formation
* <trainPart>
*Zugbehandlungen (Flügeln, Kuppeln, Schwächen, Verstärken, Zugtausch – wie bildet man eigentlich einen Zugtausch in railML 2 ab?)
* <category>
*Ursprungs und Zielort (sofern nicht aus dem Zuglauf bekannt – Stichwort „Einbrechende und ausbrechende Verkehre“)
* <ocp>
*Zuglauf mit jeweils:
 
**Geplanter Ankunft und Abfahrtszeit
Optionally imported information includes:
**Gleisinformationen
 
**Haltepunktinformationen
* <track>
**Bedarfshalt, Durchfahrt, Halt
* <formation>
**Mindesthaltezeiten und Mindestfahrzeiten
* <annotation>/<annotationRef>
**Betriebshalt/kommerzieller Halt
* <rostering>
**Anschlussinformationen
* <connection> (in order to provide and manage connection information for internal or external services)
**Wendeinformationen
* <statistics>
*Umlaufinformationen (um Auswirkungen von Verspätungen auf Folgefahrten prognostizieren zu können)
 
*Fahrplanänderungen (Änderungen der Kurzfristplanung im Vergleich zur Langfristplanung)
If the topology is not imported from railML it is assumed that it is imported from a different source including an appropriate mapping to the ocp’s imported from railML.
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.
 
'''Interference with other railML® schemas / {{Deu|Interferenz mit anderen railML®-Schemen}} / {{Fra|Interaction avec autres schemas railML®}} '''
 
* Mandatory: infrastructure
* Optionally: rolling stock
 
'''Characterizing Data / {{Deu|Charakterisierung der Daten}} / {{Fra|Caractérisation des données}} '''
 
This section serves to specify the required data regarding certain aspects.
 
<u>How often do the data change (update)?</u>
 
* yearly
* regular changes
* daily
 
<u>How big are the data fragments to be exchanged (complexity)?</u>
 
* Huge - whole data set
 
<u>Which views are represented by the data (focus)?</u>
 
* Mid term planning (eg. for yearly timetable disposition)
* Short term planning (eg. for trackworks)  
* Passenger information
 
<u>Which specific timetable data do you expect to receive/send (elements)?</u>
 
{| class="prettytable"
|-
|
Element
 
|
Mandatory
 
|
Remarks
 
|-
|
Infrastructure/operationControlPoints/ocp
 
|
X
 
|
Used for referencing with the PIS topology
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:timetablePeriods|<timetablePeriods>]]/[[TT:timetablePeriod|<timetablePeriod>]]
 
|
X
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:operatingPeriods|<operatingPeriods>]]/[[TT:operatingPeriod|<operatingPeriod>]]
 
|
X
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:categories|<categories>]]/[[TT:category|<category>]]
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:annotations|<annotations>]]/[[TT:annotation|<annotation>]]
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/formationTT
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/operatingPeriodRef
 
|
X
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT
 
|
X
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/times
 
|
X
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/connections
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/connections/connection
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/connections/connection/annotationRef
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/statistics
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/sectionTT/runTimes
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/stopDescription
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/stopDescription/stopTimes
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/ocpsTT/stopDescription/annotationRef
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/[[TT:trainParts|<trainParts>]]/[[TT:trainPart|<trainPart>]]/annotationRef
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/trains/train
 
|
X
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/trains/train/trainPartSequence
 
|
X
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/trains/train/trainPartSequence/trainPartRef
 
|
X
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/rosterings/rostering/blockParts/blockPart
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/rosterings/rostering/blocks/block
 
|
 
 
|
 
 
|-
|
[[TT:timetable|<timetable>]]/rosterings/rostering/blocks/block/blockPartSequence/blockPartRef
 
|
 
 
|
 
 
|}
 
 
Mit Blick auf den Usecase Fahrgastinformation im Fahrzeug sollte <annotation> u. U. erweitert werden, um das Zielsystem der Sonderinformation zu bestimmen.
Ausserdem sollte m. E. nach im rostering der Übergangstyp hinterlegt werden. Das hat Einfluss auf die Prognoseberechnung, sowie die berechnung von Via Zieltexten.
 
Reminder: geocoordinaten am ocp sollten u.U. auch den Kodierungsstandard enthalten (WGS84, CHxxx).

Revision as of 14:59, 26 June 2019

Passenger information at stations
Subschema: Timetable and Rostering
 
Related subschemas: IS RS 
Reported by: PSI
Stift.png (version(s) 2.4)
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.