UC:TT:SlotOrdering: Difference between revisions
(insert of content) |
(No difference)
|
Revision as of 19:45, 17 September 2016
Timetable Information Subschema: Timetable and Rostering Related subschemas: IS RS | ||
| ||
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
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