UC:TT:CapacityReservationForTracks

Capacity Reservation for Tracks (CARE) Subschema: Timetable and Rostering

DRAFT railML® version TBD

For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Capacity Reservation for Tracks

Description / Beschreibung

The aim of this use case is to describe how booked stationary capacity can be represented in railML^®. If, for example, part of a track has been reserved for parking, this should be represented in railML^®. This means that the track is occupied without a timetable existing for it. This information is important for timetable planning systems and for TMS. It should also be possible to support the process of booking such track capacity. So it should also be possible to encode track capacities that have only been requested so far, as well as such capacities that have been booked and then canceled.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

Reserved capacities may be short-term or long-term. Accordingly, it must be assumed that the relevant information is also included in the exchange of short-term schedule data and may also change there

Dependent railML^® domains / Abhängige railML^®-Domänen

The use case focuses on timetable data. Infrastructure data is only required in a reduced form, although a detailed mapping of infrastructure is not excluded by the use case. Rolling stock data is also typically described in a rather basic form. Interlocking data is generally not exchanged within the scope of this use case.

Characterizing Data / Charakterisierung der Daten

A capacity reservation should be able to belong to a category. Categories should be freely configurable and, in addition to a name, have an identity extending across documents. A capacity reservation always focuses on an operational point that must be able to be coded. It should be possible to record the validity of the reservation. It should as well be possible to code validities that cover less than a whole day, if necessary also on a regular basis (every Wednesday, 8:00 a.m. to 4:00 p.m.). The following additional data should be recorded for each booking:

• Formation
• Track(s) reserved, or track section(s) reserved
• Requested track or requested track section
• What facilities are needed on the track.
• Status (should be based on the status of slot ordering), booking status, reason for cancellation if applicable.
• Who requested the reservation