UC:TT:LongTermCirculationPlanning

Long Term Circulation Planning (LTCP) Subschema: Timetable and Rostering   Related subschemas: IS RS

(version(s) <version>)

For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Long Term Circulation Planning

Description / Beschreibung

Exchange of planning results from long-term timetable planning in the railway sector with other systems, such as personnel planning, scheduling or passenger information systems, etc. Other timetable planning systems are also envisioned as consuming systems and must be taken into account accordingly with regard to the necessary data. The basis for planning would be a timetable, or possibly even a rough timetable concept.

As part of this use case, data that has been determined as the results of circulation planning in corresponding systems is to be exchanged with other systems that further enrich, refine or process it. The focus here is on the so-called planning aspect. This means that no assignment of specific vehicles to journeys is to be exchanged. Instead, an assignment based on vehicle types is to be described, whereby abstract vehicle types are also possible. An assignment of the circulations described like this to specific vehicles is regarded as a possible result of processing in consuming systems.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

The data exchanged as part of this use case is usually based on that of the timetable that is also exchanged. Typically, the data is planned for the long term, for example for an entire timetable period or for a seasonal timetable. Shorter periods are also conceivable in principle but should not be treated differently in structural terms.

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen

Reference must be made to rolling stock elements in order to describe which vehicle types a rostering refers to. Furthermore, reference is made to trains, i.e. timetable data, in order to be able to integrate them into a circulation.

Reference can also be made to elements of the infrastructure, e.g. to describe the location of an activity if it is not apparent from the reference to other timetable data. It shall be possible to describe the circulation data exchanged for this use case even without reference to the timetable. This would be the case in a very early stage of planning.

Characterizing Data / Charakterisierung der Daten

Which views are represented by the data (focus)?

For the purposes of this use case, vehicle scheduling describes a set of activities (blocks) that are carried out by a group of vehicles in a unit of time. Such a vehicle group is a sequence of vehicles, at least a single vehicle. The activities mentioned can be carried out one after the other. Description of parallel work is not included in this use case.

For the purposes of this use case, the vehicle group is represented by vehicle types that are bundled into formations.

The blocks in question are primarily operational journeys, but also other railway operations tasks. It should be possible to describe the following tasks:

• Operational train journey (with range option on formation)
• Preheating/cooling of a vehicle assembly
• Refuelling
• Shunting
• Parking/(turning)
• Cleaning (stationary)
• Maintenance
• Inspections
• Start up/shut down
• Loading and unloading
• Time slots not yet planned (not to be confused with buffers in the planning (white areas in the plan))

For each of these tasks, it must be possible to record at least the following data:

• Type of task
• Start time
• End time
• Any existing buffer times (e.g. to be able to derive minimum turning times)
• Place where the task is to be started
• Place where the task is completed
• Operational train journey or part of train journey, if applicable

The blocks described in this way are compiled into sequences within the framework of the cycle planning, which can extend over one or more days. It should be possible to describe circulations that start and end at the same location (closed circulation) and those that do not (open circulation). Circulations must contain corresponding identification information so that importing systems can assign the corresponding entities.

Circulations can be combined into so-called circulation chains, which are carried out one after the other by vehicles of the same type. The start and end points of such a circulation chain are often the same.

Courses, i.e. the description of a sequence of journeys carried out by different vehicles on the same line (service), should not be considered within the scope of this use case.

When describing the data, care must be taken to ensure that itineraries and circulation chains that are repeated within the period described do not have to be described several times. Instead, a compact type of description should be found that allows the data to be transferred with little redundancy.