User:David Lichti/UC:?:Possessions
| Possessions and Restrictions Subschema: Subschema missing! Reported by: HaCon | ||
| ||
| For general information on use cases see UC:Use cases |
Use case / Anwendungsfall
Possession and restriction information.
Description / Beschreibung
A possession is a temporary capacity reservation on some part of railway infrastructure for non-operational use. This causes restrictions for regular operations on and around the possessed infrastructure.
Possessions are usually planned and coordinated by the infrastructure manager. They receive and review possession requests related to track and maintenance works. Such a request usually contains the network portion that is being worked on, but also parts of the network that are affected by protective measures. This may include:
- closing operational points and lines.
- locking points and signals.
- disconnecting power transmission lines.
- reducing speeds.
- ...
Depending on the planning stage, the location information may be rather coarse and approximate, or very detailed and precise.
A request may be granted, altered or denied. If circumstances change, it may be necessary to update or cancel already planned possessions.
Train planners need to be aware of planned restrictions. During the planned times for a restriction, they may have to
- re-route trains.
- allow for longer running times.
- plan with different rollingstock.
- plan replacement services.
- cancel entire train runs or parts of it.
- ...
In a dynamic environment, they need to detect conflicts between planned restrictions and train runs. Conflict resolutions usually lead to changes that need to be communicated back to the orderer of the train service or possession.
Not all trains are affected by the restrictions of a possession. Depending on the type of work, trains may be used to move personel, equipment and/or material in and out of the working zone. These trains are related to a specific possession, and thus must be allowed to enter and leave the protected network area.
Train dispatchers and controllers need to be aware of the restrictions to implement the protective measures.
Train operators and drivers need to be aware of the restrictions that affect their respective trains and runs.
Timetable information providers need to be aware of restrictions and related service degradations.
Data Flows and Interfaces / Datenflüsse und Schnittstellen
Possession requests are sent from a possession owner to the infrastructure manager. They may come in via an ordering portal or other external interfaces. Each request may contain one or many related possessions.
The full possession plan with all planned possession on the entire network during an entire timetable period is exchanged alongside the timetable exchange.
Reports and notifications about possessions and restrictions may be restricted to the relevant data for a location, an operating day, and/or a train run. They may be bundled with the timetable exchange.
Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen
- IS for describing locations and impacts of possessions and restrictions.
- TT for referencing affected trains and services.
Characterizing Data / Charakterisierung der Daten
How often do the data change (update)?
Possession and restriction planning is part of the timetable construction starting at the LTP phase:
- LTP: yearly reports
- STP: regular updates
- VSTP: daily reports
How big are the data fragments to be exchanged (complexity)?
The scope of possession and restriction exchanges typically aligns to the timetable exchange:
- all available data for the entire network throughout a full timetable period.
- updated data since the last exchange, possibly restricted to a time period.
- all available data for the upcoming days.
Which views are represented by the data (focus)?
The data has two related aspects:
- Possessions: Locations and periods of planned track and maintenance work.
- Restrictions: Impacts of possessions on train operations.
Which specific data do you expect to receive/send (elements)?
Infrastructure location descriptions of varying granularity:
- <operationalPoint>
- <line>
- <signalIS>
- km positions and ranges
- ...
It should be possible to formulate restriction locations based on the functional infrastructure with little or no topology data.
Content of a possession:
- <restrictionArea>
- type and impact
- <validityTime>
- <organizationalUnit>
- contact data
- ...
Basic operational train data
If the possession and restriction data is bundled with timetable data, there may be more timetable elements.