UC:IS:Timetabling

Timetabling Subschema: Infrastructure   Related subschemas: IL TT RS  Reported by: ProRail

DRAFT railML® version TBD

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:

1. Basic infra data: Engineering dept -> timetabling and capacity management
2. Basic rollingstock: Keeper / owner -> timetabling dept.
3. Capacity management IM’s -> RU: capacity distribution per RU per period
4. Timetable per RU -> capacity management IM’s
5. Integrated timetable -> train dispatcher(s) at IM’s
6. Timetable subsets -> TAF/TAP CI
7. 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.)