From railML 3 Wiki
Jump to navigation Jump to search
Passenger Information Inside the Train
Subschema: Timetable and Rostering
Related subschemas: IS IL RS 
Reported by: Interautomation
Stift.png (version(s) not yet specified)
For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Passenger Information Inside the Train; Fahrgastinformation im Zug

Description / Beschreibung

The use case describes the data of the timetable, which will be imported in a real time passenger information system (RTPIS) or Automatic Vehicle Monitoring System (AVMS) and will be used for generating passenger information inside the trains.

The RTPIS, which imports the timetable is also responsible for the monitoring and the data supply of the trains with passenger information data. The trains connected with the RTPIS will be described as "RTPIS-own trains" in the following chapters.

The imported timetable is used

  • to show the progress of the journeys and
  • to show the punctuality in comparison between the planned and the esti-mated arrival and departure times for RTPIS-own journeys.

Additionally it is used as the data base to supply extended information for passengers like connections/transfers at stations for RTPIS-own journeys. Commonly connections/transfers are not part of the imported timetable. These information belong to the responsibility of another RTPIS or an AVMS. Typically these information will be collected from a public transport cloud service by using a standardized interface, for example according to VDV-DFI (VDV-453).

The quality and the completeness of the timetable import are significant for the actuality and the accuracy of the passenger information inside the train, which will be generated by the RTPIS.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

The use case describes the data exchange between a planning system (for time-tables, rosterings and vehicle deployment) and a RTPI or an AVMS. For further usage the data has to be imported in the RTPIS or the AVMS.

According to the data contained in the timetable import, data amount and data complexity can vary.

At least this use case needs the following elements:

  • the elements <train> and <trainPart> to supply information about line, direction and relevant information from the timetable to match the display content inside the train correctly to the other information
  • <ocp> elements to refer to the infrastructure

Different levels of complexity of the data import are possible.

  • a minimal level of information corresponding to the infrastructure (only the identification number of the ocp) or an extended level of information (e.g. short name, longer name, geo location data)
  • the element <category> is used to decide between journeys with or with-out a relevance for passengers (e.g. operating drives)
  • with or without <rostering>, but if <rostering> is included, the element <rollingstock> is also required

The elements <infrastructure> and <rollingstock> are master data for the use case "passenger information inside the train".

The information from the <timetable> are data which will be used individually for every train number and every vehicle circulation.

The usage of the <rostering> information is optional. If the system is provided with these information, no manually input action by the train conductor is required to show the correct passenger information on the displays.

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen

  • Infrastructure is referenced:
    • from <ocpTT>.ocpRef to <ocp>.id (mandatory)
  • Rolling stock is referenced:
    • from <formationTT>.formationRef to <formation>.id (optional)
    • from <rostering>.formationRef to <formation>.id (optional)
    • from <rostering>.vehicleRef to <vehicle>.id (optional)

Characterizing Data / Charakterisierung der Daten

How often do the data change (update)?

  • daily
  • sometimes possibly several times on a day (short-term changes)

How big are the data fragments to be exchanged (complexity)?

The size of the data varies depending to the usage of the data. On the one hand there is the general data supply with the timetable e.g. for the next seven days in advance.

On the other hand there is the data supply for the next two days, which optionally also contains the vehicle deployment information to ensure the automated journey detection for automated passenger information inside the train.

Typically the data source is the commercial view of the timetable, which is also used in the AVMS of the public transport operator (PTO). It will be the basis data for generating real time information. These information will also be delivered to the public transport cloud service.

  • infrastructure: medium (region), macroscopic
  • timetable: medium (region; several up to some hundred trains)
  • rolling stock: small (none, one or a few vehicles and formations) – kann für mittelfristigen Horizont entfallen, wenn keine Fahrzeugeinsatzplanung (ros-tering) vorhanden ist.
Size of Dataset (very) short-term planning (next 2 days) short-term planning (next week)
<infrastructure> Medium Medium
<timetable> Medium Medium
<rostering> Included (optional) Not relevant
<rollingstock> Small (nur wenn <rostering>) Not relevant

Which views are represented by the data (focus)?

  • Short-term planning (up to a week)

Which specific TT data do you expect to receive/send (elements)?

Element Mandatory/Optional
<infrastructure>.<operationsControlPoints>.<ocp>.id x
<infrastructure>.<operationsControlPoints>.<ocp>.number x (railML 2.1)
<infrastructure>.<operationsControlPoints>.<ocp>.<designator register="IBNR">.entry x (railML 2.3)
<infrastructure>.<operationsControlPoints>.<ocp>.code (railML 2.1)
<infrastructure>.<operationsControlPoints>.<ocp>.<designator register="RL100">.entry (railML 2.3)
<timetable>.<timetablePeriods>.<timetablePeriod>.id x
<timetable>.<timetablePeriods>.<timetablePeriod>.startDate x
<timetable>.<timetablePeriods>.<timetablePeriod>.endDate x
<timetable>.<operatingPeriods>.id x
<timetable>.<operatingPeriods>.<operatingPeriod>.startDate x
<timetable>.<operatingPeriods>.<operatingPeriod>.endDate x
<timetable>.<operatingPeriods>.<operatingPeriod>.bitMask x
<timetable>.<categories>.<category>.id x
<timetable>.<trainparts>.<trainPart>.id x
<timetable>.<trainparts>.<trainPart>.line x
<timetable>.<trainparts>.<trainPart>.trainNumber x
<timetable>.<trainparts>.<trainPart>.categoryRef x
<timetable>.<trainparts>.<trainPart>.<operatingPeriodRef>.ref x
<timetable>.<trainparts>.<trainPart>.<ocpsTT> x
<timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT> x
<timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT>.ocpType x
<timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT>.<times> x
<timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT> x
<timetable>.<trainparts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT>.distance x
<timetable>.<trains>.<train> x
<timetable>.<trains>.<train>.id x
<timetable>.<trains>.<train>.type x
<timetable>.<trains>.<train>.trainNumber x
<timetable>.<trains>.<train>.<trainPartSequence> x
<timetable>.<trains>.<train>.<trainPartSequence>.sequence x
<timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef> x
<timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef>.ref x
<timetable>.<rosterings>.<rostering>.id x
<timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.begin x
<timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.beginDay x
<timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.end x
<timetable>.<rosterings>.<rostering>.<blockParts>.<blockPart>.endDay x
<timetable>.<rosterings>.<rostering>.<blocks>.<block>.id x
<timetable>.<rosterings>.<rostering>.<blocks>.<block>.<blockPartSequence>.sequence x
<timetable>.<rosterings>.<rostering>.<blocks>.<block>.<blockPartSequence>.<blockPartRef>.ref x
<timetable>.<rosterings>.<rostering>.<circulations>.blockRef x
<timetable>.<rosterings>.<rostering>.<circulations>.startDate x