UC:IS:PosessionManagement

From railML 2 Wiki
Jump to navigation Jump to search
🗒️ This page is mirrored from page UC:IS:PosessionManagement in The railML® 3 wiki.
Posession Management
Subschema: Infrastructure
Stift.png (version(s) not yet specified)
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

Posession Management
 

Description / Beschreibung

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:

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

Data Flows and Interfaces / Datenflüsse und Schnittstellen

Template:Tbd

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

Template:Tbd

Characterizing Data / Charakterisierung der Daten

How often do the data change (update)?

Template:Tbd

How big are the data fragments to be exchanged (complexity)?

Template:Tbd

Which views are represented by the data (focus)?

Template:Tbd

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

Template:Tbd