UC:IL:OperationAndControl: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
m (Ferri Leberl moved page IS:UC:OperationAndControl to IL:UC:OperationAndControl: Namenskonvention)
(Standardization)
Line 1: Line 1:
'''Use case / {{Deu|Anwendungsfall}} / {{Fra|Scénario d’utilisation}}:'''
{{UseCase|IL||title=Operation and Control}}


{{UC title}}
Operation and Control; {{Deu|Betrieb und Kontrolle}}; {{Fra|nom descriptif en Francais}}
Operation and Control; {{Deu|Betrieb und Kontrolle}}; {{Fra|nom descriptif en Francais}}


 
{{UC description}}
'''Description / {{Deu|Beschreibung}} / {{Fra|Description}}'''
 
The operation and control systems for one railway operating company are normally provided by one selected supplier in order to keep the various types to a minimum. However, the interlockings within the network are of different type and very often from different suppliers. Thus the configuration from these interlockings has to be incorporated into the operation and control systems. They uses the interlocking to  
The operation and control systems for one railway operating company are normally provided by one selected supplier in order to keep the various types to a minimum. However, the interlockings within the network are of different type and very often from different suppliers. Thus the configuration from these interlockings has to be incorporated into the operation and control systems. They uses the interlocking to  
* operate elements
* operate elements
Line 15: Line 14:
* diagnosis and maintenance management systems (collecting all network traffic of the interlocking plus converting it human readable)
* diagnosis and maintenance management systems (collecting all network traffic of the interlocking plus converting it human readable)


 
{{UC flows}}
'''Data Flows and Interfaces / {{Deu|Datenflüsse und Schnittstellen}} / {{Fra|Flux de données et interfaces}}'''
 
Station specific data are derived from the interlocking configuration and imported into the operation and control systems:
Station specific data are derived from the interlocking configuration and imported into the operation and control systems:
* Infrastructure elements (all elements which shall be operable: TVD sections, points, signals, level crossings etc.)
* Infrastructure elements (all elements which shall be operable: TVD sections, points, signals, level crossings etc.)
Line 23: Line 20:
* Routes
* Routes


 
{{UC interference}}
'''Interference with other railML<sup>®</sup> schemas / {{Deu|Interferenz mit anderen railML<sup>®</sup>-Schemen}} / {{Fra|Interaction avec autres schemas railML<sup>®</sup>}}'''
 
* infrastructure
* infrastructure


 
{{UC data}}
'''Characterizing Data / {{Deu|Charakterisierung der Daten}} / {{Fra|Caractérisation des données}}'''
 
This section serves to specify the required data regarding certain aspects.
This section serves to specify the required data regarding certain aspects.


<u>How often do the data change (update)?</u>
{{UC update}}
 
* only on configuration changes
* only on configuration changes


<u>How big are the data fragments to be exchanged (complexity)?</u>
{{UC complexity}}
 
* big (station/yard)
* big (station/yard)
* huge (region)
* huge (region)


<u>Which views are represented by the data (focus)?</u>
{{UC focus}}
 
* Signaling
* Signaling


<u>Which specific timetable data do you expect to receive/send (elements)?</u>
{{UC elements}}
 
Permission/operating zones:
Permission/operating zones:
* ID
* ID

Revision as of 15:26, 26 August 2016

Operation and Control
Subschema: Interlocking
Stift.png (version(s) )
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

Operation and Control; Betrieb und Kontrolle;

Description / Beschreibung

The operation and control systems for one railway operating company are normally provided by one selected supplier in order to keep the various types to a minimum. However, the interlockings within the network are of different type and very often from different suppliers. Thus the configuration from these interlockings has to be incorporated into the operation and control systems. They uses the interlocking to

  • operate elements
  • get element status
  • schedule and manage train operation

These systems are

  • remote control HMI of traffic control centers
  • train routing systems for automated traffic routing and train scheduling
  • diagnosis and maintenance management systems (collecting all network traffic of the interlocking plus converting it human readable)

Data Flows and Interfaces / Datenflüsse und Schnittstellen

Station specific data are derived from the interlocking configuration and imported into the operation and control systems:

  • Infrastructure elements (all elements which shall be operable: TVD sections, points, signals, level crossings etc.)
  • Permission/operating zones including shunting areas for temporary local operation
  • Routes

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

  • infrastructure

Characterizing Data / Charakterisierung der Daten

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

  • only on configuration changes

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

  • big (station/yard)
  • huge (region)

Which views are represented by the data (focus)?

  • Signaling

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

Permission/operating zones:

  • ID
  • type (normal operation, local shunting area etc.)
  • border elements

Routes:

  • ID
  • start
  • destination
  • mandatory point positions, if variations possible

Infrastructure elements:

  • ID
  • type

[…]