UC:IS:PassengerInformationSystem

From railML 2 Wiki
Revision as of 10:02, 7 October 2015 by RailML Orga Governance (talk | contribs) (insert of content)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Use case / Anwendungsfall / :

Passenger Information System; Passagierinformationssystem;


Description / Beschreibung /

The application focuses the transfer of timetable, traction and topology information from the resource planning system of the railway infrastructure manager to the passenger information system of the same (or another) infrastructure manager.


Data Flows and Interfaces / Datenflüsse und Schnittstellen /

The data flow is one-directional: It goes from the resource planning system to the passenger information system. There are two types of data flows:

  • Scenario 1: Bulk transfer of all (updated) timetable, traction and topology data: 5-6 times per year.
  • Scenario 2: Incremental transfer of short-term timetable, traction and topology data: Once a day.


Figure 1: Data flows for the Passenger Information System use case


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

  • rolling stock
  • timetable


Characterizing Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

  • Bulk transfer: regular changes 5-6 times a year
  • Daily changes for incremental transfers

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

  • Granularity of data: macro-level (operational points, lines)
  • Complexity of data: railway line

Which views are represented by the data (focus)?

  • Construction, more generally spoken "passenger information". Like construction areas and possible by-passes on the journey.

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

  • Macroscopic topology:
    • Lines
    • Operational points (stations)