From railML 2 Wiki
Revision as of 12:03, 18 July 2022 by RailML Coord Documentation (talk | contribs) (+mirror)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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


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


Characterizing Data / Charakterisierung der Daten

How often do the data change (update)?


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


Which views are represented by the data (focus)?


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