|
|
| Line 1: |
Line 1: |
| {{UseCase|IS|2.3|title=Timetabling|TT=1|IL=1|RS=1|reporter=ProRail}} | | {{mirror}} |
| | |
| {{UC title}}
| |
| Timetabling; {{Deu|Fahrplan}}; {{Fra|nom descriptif en Francais}}
| |
| | |
| {{UC description}}
| |
| 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.
| |
| | |
| {{UC flows}}
| |
| 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
| |
| | |
| {{UC interference}}
| |
| * timetable
| |
| * interlocking
| |
| * rolling stock
| |
| * topology
| |
| | |
| {{UC data}}
| |
| 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.
| |
| | |
| {{UC update}}
| |
| * weekly
| |
| | |
| {{UC complexity}}
| |
| * huge (region)
| |
| * whole data set (network)
| |
| | |
| {{UC focus}}
| |
| * Signaling
| |
| * Geometry
| |
| * Energy
| |
| * Safety system / interlocking
| |
| | |
| {{UC 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.)
| |