UC:IS:PosessionManagement: Difference between revisions

From railML 3 Wiki
Jump to navigation Jump to search
[unchecked revision][checked revision]
(Versionfix)
mNo edit summary
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{UseCase|IS|title=Posession Management|reporter=}}
{{UseCase|IS|title=Posession Management|reporter=|abbr=POMA}}
 
{{UC title}}
{{UC title}}
{{head|Posession Management}}
 
{{head|Posession Management}}Management of restrictions and possessions in the railway network.
 
{{UC description}}
{{UC description}}
Possession is a takeover of responsibility for a part of railway network from the “train operator” to the PICOP (Person In Charge Of Possession).
The objective of a possession is to ensure '''safe''' construction/maintenance works on the railway infrastructure. The '''safety''' is ensured by a set of '''safety measures''':
* Temporal speed restrictions around the construction work (including neighbour tracks if needed)
* Closed tracks for most of the trains except the specific once.
* Specific position of the switches (similar to flank protection)
Possession management is safety relevant as any failure could result e. g. in a collision of passenger train with a construction train with > 1000 involved people.
Possession undergoes a specific life cycle (here the default “path”):
* It is planned by the maintenance system, defining elements to be worked on and additional definitions (e. g. used machines) which could influence the required safety measures.
* The safety measures are planned by a signalling specialist.
* Timetable planning department defines time intervals for activation, as well as rules for disturbed case (e. g. let Train 1002 pass if delayed less than 5 minutes).
* Train operator modifies planned time intervals according to the expected traffic situation, e. g. by postponing start of possession.
* When the PICOP and his team arrive at possession area
** He safely identifies his location, to prevent activation of wrong possession
** Requests the activation of Possession
** The train operator verifies,
*** That timetable requirements for disturbed case are implemented (train 1002 has passed)
*** No unexpected trains are inside of the possession area
** Train operator activates the speed restrictions defined in Possession.SafetyMeasures
** Train operator puts switches in positions defined in Possession.SafetyMeasures
** Train operator verifies all the safety requirements defined in Possession are fulfilled
** Train operator notifies the PICOP about the possession activation
** PICOP and his team start working
* After PICOP finished the work
** He ensures, that his team has left the possession area and it is ready for operations
** He requests the train operator to finish possession
** Train operator
*** releases blocked switches
*** removes temporal speed restrictions
*** closes the possession


To make the life more complicated, the lifecycle of possessions can vary:
Whenever non-nominal conditions occur on a right-of-way, it may be necessary to impose ''restrictions'' on the local rail network capacity. These conditions may arise from maintenance or construction activities on the right-of-way itself, or due to exceptional events in the vicinity of the tracks. Ideally these restrictions are planned and coordinated ahead of time. But even restrictions due to unforeseen events need to be managed for the time of their effectiveness.
* possession can be stopped and reinstated later
 
* two possessions can be assigned to one PICOP
The ''impact'' of a restriction heavily depends on the disturbance that causes it. It may range from a speed reduction, to the deactivation of track side systems, or to the complete closure of a track section. A single restriction may have different impacts on different parts of the network. And each of these impacts may apply on different time intervals. It is part of the restriction planning process to negotiate the protective safety requirements and the operational availability demands. This may require several exchanges and updates of restriction and impact data between maintenance planning and capacity planning systems.
* one big possession could be split into two small once, without deactivation/reactivation phase
 
* PICOP could require to move possessed switches to check their proper function.
This restriction data is also of special interest to train operators: If a restriction affects one of their routes, they may have to adjust schedules to account for reduced speeds or increased runtimes. Deactivation of overhead wires or other track side system restrictions may require re-planning rollingstock to keep running on the impacted routes. If this is not possible, they may have to re-route their trains to avoid the restriction area altogether. In a later stage, the information about restrictions along the route are also relevant to train drivers, as they may have to follow specific rules of operations in the impacted areas.
 
In case of construction and maintenance work with on-site personal, it may be necessary to plan and implement a ''possession''. This means that a ''Person in Charge of Possession'' (PICOP) takes over the responsibility for a part of the network from the network operator. They activate the possession by implementing and verifying the planned safety measures before work starts. When the work has ended, they deactivate the possession by releasing the safety measures. It is important, that the network operator and the PICOP have up-to-date information about the location and time interval of these restrictions, what protective measures are planned, and how they impact train operations.
 
Especially in the context of construction and maintenance work, there may be work-related trains that are not affected by the restriction in the same way. For example, they may be allowed to enter a track section, that is otherwise closed to regular traffic. For proper planning and safe dispatching of these trains, it is important that these trains are clearly specified.
 
{{UC flows}}
{{UC flows}}
{{tbd|2022-01-10}}
 
Restrictions may be ordered by the construction and maintenance planning systems. They interface with the capacity planning system.
 
The capacity planning system needs to inform
 
* the train planning systems about new or updated capacity restrictions and availabilities.
* the train management system and train operators about effective restriction impacts and security measures.
 
{{UC interference}}
{{UC interference}}
{{tbd|2022-01-10}}
 
Organizational units are specified by references into the common schema.
 
Work trains are specified by reference into the timetable schema.
 
{{UC data}}
{{UC data}}
The data belongs mostly to the infrastructure. It should be possible to describe restrictions and their impacts in terms of functional infrastructure objects, without the need of a microscopic network topology.
The planning aspect requires the description of temporal validities.
Some administrative data is necessary to track and manage restrictions throughout their life cycle.
{{UC update}}
{{UC update}}
{{tbd|2022-01-10}}
 
Possession and restriction planning is part of the timetable construction starting at the LTP phase:
 
* '''LTP:''' yearly reports
* '''STP:''' regular updates
* '''VSTP:''' daily reports
 
{{UC complexity}}
{{UC complexity}}
{{tbd|2022-01-10}}
 
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.
 
{{UC focus}}
{{UC focus}}
{{tbd|2022-01-10}}
 
The data has two related aspects:
 
* '''Restrictions:''' Locations and periods of capacity reductions.
* '''Impacts:''' Impacts of restrictions on train operations.
 
{{UC elements}}
{{UC elements}}
{{tbd|2022-01-10}}
 
Infrastructure location descriptions of varying granularity:
 
* <code><[[IS:operationalPoint|operationalPoint]]></code>
* <code><[[IS:line|line]]></code>
* <code><[[IS:signalIS|signalIS]]></code>
* mileage 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 restriction:
 
* <code><[[IS:restrictionArea|restrictionArea]]></code>
* type and impact
* <code><[[CO:validityTime|validityTime]]></code>
 
* <code><[[CO:organizationalUnit|organizationalUnit]]></code>
* contact data
* ...
 
Basic operational train data
 
* <code><[[TT:operationalTrain|operationalTrain]]></code>
 
If the possession and restriction data is bundled with timetable data, there may be more timetable elements.{{interwiki}}

Latest revision as of 11:50, 3 June 2024

Posession Management
(POMA)
Subschema: Infrastructure
Stift.png (version(s) not yet specified)
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

Posession Management
 
Management of restrictions and possessions in the railway network.

Description / Beschreibung

Whenever non-nominal conditions occur on a right-of-way, it may be necessary to impose restrictions on the local rail network capacity. These conditions may arise from maintenance or construction activities on the right-of-way itself, or due to exceptional events in the vicinity of the tracks. Ideally these restrictions are planned and coordinated ahead of time. But even restrictions due to unforeseen events need to be managed for the time of their effectiveness.

The impact of a restriction heavily depends on the disturbance that causes it. It may range from a speed reduction, to the deactivation of track side systems, or to the complete closure of a track section. A single restriction may have different impacts on different parts of the network. And each of these impacts may apply on different time intervals. It is part of the restriction planning process to negotiate the protective safety requirements and the operational availability demands. This may require several exchanges and updates of restriction and impact data between maintenance planning and capacity planning systems.

This restriction data is also of special interest to train operators: If a restriction affects one of their routes, they may have to adjust schedules to account for reduced speeds or increased runtimes. Deactivation of overhead wires or other track side system restrictions may require re-planning rollingstock to keep running on the impacted routes. If this is not possible, they may have to re-route their trains to avoid the restriction area altogether. In a later stage, the information about restrictions along the route are also relevant to train drivers, as they may have to follow specific rules of operations in the impacted areas.

In case of construction and maintenance work with on-site personal, it may be necessary to plan and implement a possession. This means that a Person in Charge of Possession (PICOP) takes over the responsibility for a part of the network from the network operator. They activate the possession by implementing and verifying the planned safety measures before work starts. When the work has ended, they deactivate the possession by releasing the safety measures. It is important, that the network operator and the PICOP have up-to-date information about the location and time interval of these restrictions, what protective measures are planned, and how they impact train operations.

Especially in the context of construction and maintenance work, there may be work-related trains that are not affected by the restriction in the same way. For example, they may be allowed to enter a track section, that is otherwise closed to regular traffic. For proper planning and safe dispatching of these trains, it is important that these trains are clearly specified.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

Restrictions may be ordered by the construction and maintenance planning systems. They interface with the capacity planning system.

The capacity planning system needs to inform

  • the train planning systems about new or updated capacity restrictions and availabilities.
  • the train management system and train operators about effective restriction impacts and security measures.

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

Organizational units are specified by references into the common schema.

Work trains are specified by reference into the timetable schema.

Characterizing Data / Charakterisierung der Daten

The data belongs mostly to the infrastructure. It should be possible to describe restrictions and their impacts in terms of functional infrastructure objects, without the need of a microscopic network topology.

The planning aspect requires the description of temporal validities.

Some administrative data is necessary to track and manage restrictions throughout their life cycle.

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:

  • Restrictions: Locations and periods of capacity reductions.
  • Impacts: Impacts of restrictions on train operations.

Which specific data do you expect to receive/send (elements)?

Infrastructure location descriptions of varying granularity:

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

Content of a restriction:

Basic operational train data

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