Home » railML newsgroups » railml.common » Possession Mgmt Use-Case
Possession Mgmt Use-Case [message #2843] Fri, 29 October 2021 17:14 Go to previous message
Stefan Wegele is currently offline  Stefan Wegele
Messages: 4
Registered: November 2016
Junior Member
Dear all,

in IS-workgroup we collect use-cases for TrafficManagementSystems. One of them is "management of possessions" with the description below.
Here we are interested in feedback on how to organize this in context of RailML: ignore, IS, or a dedicated domain.

Best regards

Use-Case 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
o He safely identifies his location, to prevent activation of wrong possession
o Requests the activation of Possession
o 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
o Train operator activates the speed restrictions defined in Possession.SafetyMeasures
o Train operator puts switches in positions defined in Possession.SafetyMeasures
o Train operator verifies all the safety requirements defined in Possession are fulfilled
o Train operator notifies the PICOP about the possession activation
o PICOP and his team start working
- After PICOP finished the work
o He ensures, that his team has left the possession area and it is ready for operations
o He requests the train operator to finish possession
o Train operator
* releases blocked switches
* removes temporal speed restrictions
* closes the possession

To make the life more complicated, the lifecycle of possessions can vary:
- possession can be stopped and reinstated later
- two possessions can be assigned to one PICOP
- 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.
Read Message
Read Message
Read Message
Read Message
Previous Topic: [railML2/3] creating a new element to describe the project metadata
Next Topic: [railML3] status and life cycle (Common)
Goto Forum:

Current Time: Sun May 29 04:54:47 CEST 2022