UC:IS:Timetabling
| Timetabling Subschema: Infrastructure Related subschemas: IL TT RS Reported by: ProRail | |||
| |||
| For general information on use cases see UC:Use cases |
Use case / Anwendungsfall
Timetabling; Fahrplan
Description / Beschreibung
Each RU has to provide a timetable for their train- and shunting movements in a coming time period. Besides the RU itself the involved IM‘s have to supply an accurate and actual dataset about the rail infrastructure on which these trains will run in the corresponding period. At a certain level the IM’s also are part of the timetable, regarding the availability and capacity of their network, both for the train movements and the maintenance . Timetabling includes also runningtime calculations and offline simulation for capacity management. Implicitly, train dispatching is seen as a logical prolongation of a detailed timetable. At disruptions during operations, adjustments of the timetable have to be made accordingly.
The required infra-data comes from an engineerings department and their design tooling (most of the time CAD) and data-extracts from those drawings. The required data concerns topology (OP’s and SoL’s, mostly in 2 or 3 layers: micro, meso, macro), speed profiles, utilization restrictions (5 - 7 topics), energy supply, platform- and track lengths, distances, locations of several objects (incl. OP’s). For runningtime calculations also some rollingstock characteristics are required like train lengths, weights, tractive power, braking characteristics. These data comes from the wagon keepers.
Data Flows and Interfaces / Datenflüsse und Schnittstellen
Data flows:
- Basic infra data: Engineering dept -> timetabling and capacity management
- Basic rollingstock: Keeper / owner -> timetabling dept.
- Capacity management IM’s -> RU: capacity distribution per RU per period
- Timetable per RU -> capacity management IM’s
- Integrated timetable -> train dispatcher(s) at IM’s
- Timetable subsets -> TAF/TAP CI
- Integrated timetable -> publication media
Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen
- timetable
- interlocking
- rolling stock
- topology
Characterizing Data / Charakterisierung der Daten
Infrastructure data has to be valid for the time period (in the future) of the timetable horizon. Details: for conflict detection on micro-level of the topology, routes and route-dependancies (flank-protections) are required for both safety and capacity management. Utilization restrictions concern topics like gauges, speed, train-types, traffic-types, gradients.
How often do the data change (update)?
- weekly
How big are the data fragments to be exchanged (complexity)?
- huge (region)
- whole data set (network)
Which views are represented by the data (focus)?
- Signaling
- Geometry
- Energy
- Safety system / interlocking
Which specific data do you expect to receive/send (elements)?
Topology, Geometry (Location points, node-centre, node-ports), interlocking, 10 – 15 RINF parameter types for utilization restrictions, all along with a determined time validity.)