User:David Lichti/UC:?:Possessions

Possessions and Restrictions Subschema: Subschema missing! Reported by: HaCon

(version(s) 3.3)

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.
• ...

A request may be granted, altered or denied. If circumstances change, it may be necessary to make changes to already planned possessions.

Train planners need to be aware of planned restrictions. During the planned times for a restriction, they may have to

• use a different route.
• allow for longer running times.
• plan with different rollingstock.
• 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.

Timetable information providers need to be aware of restrictions and related service degradations

Train operators and drivers need to be aware of the restrictions that affect their respective trains.== 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 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)?

• 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>
• km positions and ranges
• ...

It should be possible to formulate restriction locations with little or no infrastructure topology data.

Content of a possession:

• <restrictionArea>
• type and impact
• <validityTime>

• <organizationalUnit>
• contact data
• ...

Basic operational train data

• <operationalTrain>

If the possession and restriction data is bundled with timetable data, there may be more timetable elements.