UC:TT:LongTermStrategicTimetabling

From railML 2 Wiki
Revision as of 15:12, 3 February 2020 by RailML Coord Documentation (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
🗒️ This page is mirrored from page UC:TT:LongTermStrategicTimetabling in The railML® 3 wiki.
Long Term Strategic Timetabling
(LTST)
Subschema: Timetable and Rostering
 
Related subschemas: IS IL RS 
Reported by: SMA
Stift.png (version(s) not yet specified)
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

Long Term Strategic Timetabling; Langfristfahrplanerstellung

Description / Beschreibung

The timetable data prepared in this use case is not formally linked to the production process of the LTP yearly timetable. It is typically produced more than two years in advance of operation (VLTP), and may be used for purposes including: infrastructure design and evaluation, socio-economic analyses and service planning (where it forms the basis of the LTP yearly timetable).

The data from this use case does not need to form a full production timetable, but contain sufficient information about trains to identify them, route them through the infrastructure and state their validity.

The infrastructure used in this use case is not based on the current infrastructure but an agreed future infrastructure state.

It is important that any structure (such as repeating train patterns or direct connections between trains) in the timetable is maintained in the data.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

Typically, the data produced in this use case is transferred to LTP systems using a file based interface or to another VLTP system for special studies.

Examples:

  • VLTP system-> VLTP system
  • VLTP system-> LTP production system
  • VLTP system-> consumers of study information (i.e. authorities)
  • VLTP system-> VLTP vehicle rostering

The frequency of this data flow is not defined by any process, but as required. Typically this is low frequency: once per study, several times per year, etc.

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

Characterizing Data / Charakterisierung der Daten

How often do the data change (update)?

  • Production by the user on demand (ad-hoc), infrequent.

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

  • Whole data set: provide the full timetable
  • Selected trains: provide the timetable entries for a subset of trains, for further special analysis

Which views are represented by the data (focus)?

  • Macroscopic infrastructure
  • Interval trains / train groups
  • Regular validity (daily or fixed weekday patterns)
  • Operational and commercial trains as well as commercial schedulings (mapping between commercial and operational trains)
  • Arrival and departure times
  • Connections (which train connects to another)
  • Optionally rolling stock requirements (specific train types if known, otherwise max speed, seat capacity, braking capabilities, propulsion and max length of the train)

The data contains information about the validity and trains paths in the proposed timetable. While it is not a prerequisite, it is likely that the timetable contains repeating patterns of trains within a train family sharing common characteristics allowing the user to efficiently create and manage timetable data that in railML 2.x is grouped using the <trainGroup> element. In other words it should be possible to exchange information about the intended temporal distribution of a group of trains, so with what interval is there a train connection on a certain line. In railML 2.5 we introduced the <patternTrain> and <distribution> based on this requirement, however grouping of trains may carry a similar information.

Validity data should be optional allowing the user to plan generic days which may later be enriched to include dated validities.

Commercial (published) and operational (scheduled) <times> may be relevant.

Additional information for filtering purposes

  • train types <category>
  • railway undertaking (<ordererRef>, <operatorRef>, <slotHolderRef> -> references to organizational units that are marked as railway undertakings (//organizationalUnit/isRailWayUndertaking))
  • stop types (<stop>/<pass>)
  • train status, information about the planning state of the train

Terms and Expressions

  • LTP = Long Term Planning: the yearly timetable(s)
  • VLTP = Very Long Term Planning (>2 years)