UC:TT:LongTermCirculationPlanning
| Long Term Circulation Planning (LTCP) Subschema: Timetable and Rostering Related subschemas: IS RS | |||
| |||
| 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.
Dependent railML® domains / Abhängige railML®-Domänen
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
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.
Closed circulation diagram. Provided by railML.org partner iRFP (link to the railML® website)
Open circulation diagram. Provided by railML.org partner iRFP (link to the railML® website)
Simple (closed) rostering plan Monday-Friday. Provided by railML.org partner iRFP (link to the railML® website)
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.
Sub-use cases / Teil - Usecases
A distinction is made between two partial use cases that build on each other. On the one hand, the data described above should be exchanged in order to be processed by the consuming system and then output to a third system in an enriched form. For example, specific vehicles could be allocated or a duty scheduling system could create shift plans. A complete planning status would be exchanged in each case, replacing an existing one.
Another use case is the exchange of changed planning data. For example, if a route cannot be travelled due to construction work and trips that were assigned to vehicle groups are cancelled as a result, then this information should be able to be communicated to the downstream systems. This would allow the downstream systems to update the status of the previously received and processed data. In general, however, the circulation data should also be exchanged in the case of this sub-use case via structures that correspond to those of the first sub-use case. In addition, a reference to the original data should be included in the description of changed data. This should allow reading systems to easily adapt their own stored data.
Additional remarks / Zusätzliche Bemerkungen
None
References / Verweise
None