UC:TT:SlotOrdering

Timetable Information Subschema: Timetable and Rostering   Related subschemas: IS RS

(version(s) )

For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Slot Ordering ; Trassenbestellung;

Description / Beschreibung

This use case covers the ordering of slots by Railway Undertakings from Infrastructure Manager(s) and other managers of capacity. A related use case will be the slot offer by the Infrastructure Manager.

Characterizing Data / Charakterisierung der Daten

The data has to be provided by the Railway Undertaking to the relevant Infrastructure Managers.

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

• infrastructure: <ocp>
• rolling stock: <formation> (?)
• interlocking: -

Characterizing Data / Charakterisierung der Daten

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

How often do the data change (update)?

• yearly for VLTP planning of frame contracts
• yearly for LTP planning the regular timetable
• regular changes for STP planning, e.g. for engineering infrastructure works, special event trains
• daily for VSTP planning, e.g. strike, ad hoc freight trains

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

• Typically one train per order
• Maximum complexity is full timetable

Which views are represented by the data (focus)?

• Could be any of VLTP, LTP, STP, VSTP
• Covers the full train information, but for certain time periods

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

• Workflow information
  • Not part of the timetable data
• Trains
  • Identifier, e.g. <train>.trainNumber
• Operating periods
• Train run <trainPart>
  • Earliest arrival
  • Latest arrival
  • Earliest departure
  • Latest departure
  • Minimum stop time
  • Stop type, stop description
  • Commercial connections
• Infrastructure <ocpTT>
  • Ordered stops
• Rolling stock {{TT:Tag|formationTT}
  • Loco types
  • Weight
  • Length
  • Maximum speed
  • Infrastructure restrictions

Further Issues

Handling of connections for partial exports

Depending on the process in the receiving system it might be necessary to provide only a single train with all the relevant connections. However, without the connected trains the current connection element is not valid and the referenced IDs cannot be used to map the connected trains/trainParts.

Referencing platforms in the timetable

Currently the track and platform information shall be provided via the trackRef attribute linking the corrosponding element in the infrastructure. However, this requires quite a detailed infrastructure export. It should be possible to provide the commercial stations and platforms needed for the timetable export only.

Handling of cancellations, partial cancellations, extra trains

Relevant changes to existing trains need to be represented in the export file. A complete list of changes needs to be defined. This will include the following changes:

• full cancellation of a train
• partial cancellation - i.e. of a trainPart
• extra train or trainPart
• cancelled stop
• extra stop
• etc.

Discussion

• Minor changes to the <formationTT> are not necessarily relevant and could be ignored (only the category is relevant) or should the formationTT element be optional?

Terms and Expressions

• VLTP =very long term planning (>2 years)
• LTP = long term planning: the yearly timetable(s)
• STP = short term planning: < 1 year before operation
• VSTP = very short term planning: few days before operation