|
|
| (2 intermediate revisions by one other user not shown) |
| Line 11: |
Line 11: |
| =={{examples}}== | | =={{examples}}== |
|
| |
|
| Infrastructure managers use different types of detectors to monitor for unwanted or dangerous situations related to the interlocking operation. The outputs of such detectors are fed into the {{doc|IL|signalBox}} (interlocking) or the {{doc|IL|controller}} to react accordingly. Dependent on the purpose there can be the following base types classified:
| | A {{tag|IL|controller}} is the element in a signalling control system that is used for operation of the railway system. It can be an individual terminal, commonly a workstation, which can control the interlocking. It can be also an automatic dispatch system commanding the interlocking for automatic train routing. The {{tag|IL|controller}} is normally situated in a control centre. railML provides a logical link between an interlocking and the individual controller. The user can attach useful data to this link, such as addresses that may be granted control over this interlocking. |
| *{{enum|avalanche}} – The detector detects avalanches, which may endanger the railway traffic.
| |
| *{{enum|cranks}} – The detector detects the presence of cranks for switch actuators at their normal location, e.g. in a special cabinet at the stationmaster.
| |
| *{{enum|derailment}} – The detector detects any derailed railway vehicle. It is often used in rear of tunnels or bridges to reduce the damages by derailed vehicles.
| |
| *{{enum|doors}} – The detector monitors the entry doors of equipment rooms.
| |
| *{{enum|fire}} – The detector detects fire or smoke in equipment cabinets or rooms.
| |
| *{{enum|flatWheel}} – The detector detects any flat wheel of a railway vehicle.
| |
| *{{enum|gas}} – The detector detects the excessive concentration of a particular gas in the vicinity.
| |
| *{{enum|hotWheelBox}} – The detector detects any hot axle box of railway vehicles.
| |
| *{{enum|intrusion}} – The detector monitors the access doors to any equipment cabinet or room in order to detect unauthorised access.
| |
| *{{enum|landSlide}} – The detector detects landslides or rockfalls, which may endanger the railway traffic.
| |
| *{{enum|loadingGauge}} – The detector detects any railway vehicle exceeding the loading gauge due to replaced goods or similar.
| |
| *{{enum|weighing}} – The detector checks the axle load of any railway vehicle against a pre-set limit.
| |
|
| |
|
| *{{enum|other:…}} – The detector is of another type. This is the optional extension of the list. Each entry needs to start with the string “other:” and shall have at least two letters in addition.
| | railML will not define the nature of the addresses, i.e IP-addresses or hexadecimal address of terminals that communicate with the interlocking via some serial bus. The protocol (IP, UDP, serial, parallel) is irrelevant to railML. Note that a Control Centre (DE: Leitstelle, FR: Poste de controle, NL: VL-post) is likely to control multiple interlockings and vice versa, one interlocking can be controlled from multiple control centres, an n:m relation. |
|
| |
|
| | This implies that a control centre can have multiple controllers, defined as a terminal from which a signalman controls an interlocking. The interlocking is unaware of the control centre but aware of the controller. |
|
| |
|
| | | The associations for a controller are defined with these elements: |
| <div>
| | *{{tag|IL|controlledAssets}} – This is the container with the lists of all assets, which can be controlled from this {{tag|IL|controller}}. There are the two possible types of child element: |
| | **{{tag|IL|controlledInterlocking}} - This is the reference to any {{tag|IL|signalBox}} (interlocking), which can be controlled from this {{tag|IL|controller}}. Additionally the extent of control according chapter 1.33is to be given. |
| | **{{tag|IL|controlledSystemAsset}} – This is the reference to any {{tag|IL|systemAsset}}, which can be controlled from this {{tag|IL|controller}}. This will especially cover any system assets, which are only controlled from here but not from any interlocking. Additionally the extent of control according chapter 1.33is to be given. |
| | *{{tag|IL|itineraries}} – This is the container for all route combinations as {{tag|IL|itinerary}} this {{tag|IL|controller}} has available to dispatch any train on its way from starting OCP to the destination OCP. Per route combination the start and destination point is referred and each single route forming the continuous path are referred. The principle is similar to combined routes as described in chapter 1.31. Within such {{tag|IL|itinerary}} there are no alternative sections defined. ONLY in railML3.1! |
| | *{{tag|IL|routeSequences}} – This is the container for all route combinations as {{tag|IL|routeSequence}} this {{tag|IL|controller}} has available to dispatch any train on its way from starting OCP to the destination OCP. Per route combination the start and destination point is referred and each single route forming the continuous path are referred. The principle is similar to combined routes as described in chapter 1.31. Within such {{tag|IL|routeSequence}} there are no alternative sections defined. |
|
| |
|
| =={{Additional Information}}== | | =={{Additional Information}}== |
| ==={{Notes}}=== | | ==={{Notes}}=== |
| ==={{Open issues}}=== | | ==={{Open issues}}=== |
Introduction
Documentation
Syntax
Autoexport from the XML-Schema for element IL:controller of railML ® version 3.2 |
| Documentation
|
Container with reference to connected interlockings and system assets controlled by this operational terminal.
|
| Subschema
|
interlocking
|
| Parents*
|
controllers
|
| Children
|
belongsToInfrastructureManager (0..1), belongsToOperationalPoint (0..*), controlledAssets (1..1), designator (0..*), hasCommunicationSettings (0..*), hasName (0..1), routeSequences (0..1)
|
Attributes:
- elementNumber: element number of the asset for internal reference in engineering data (optional;
xs:nonNegativeInteger),
- model: The model name of the asset from the supplier. (optional;
xs:string),
- softwareVersion: The specific software version of the asset itself. (optional;
xs:string),
- id: unique identifier (obligatory;
xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
|
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
Autoexport from the XML-Schema for element IL:controller of railML ® version 3.1 |
| Documentation
|
Container with reference to connected interlockings and system assets controlled by this operational terminal.
|
| Subschema
|
interlocking
|
| Parents*
|
controllers
|
| Children
|
any (0..*), controlledAssets (1..1), designator (0..1), itineraries (0..1)
|
Attributes:
- id: unique identifier (optional;
xs:ID; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
|
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
Changes 3.1→3.2
The children have changed.
The attributes have been changed.
Semantics
Best Practice / Examples
A <controller> is the element in a signalling control system that is used for operation of the railway system. It can be an individual terminal, commonly a workstation, which can control the interlocking. It can be also an automatic dispatch system commanding the interlocking for automatic train routing. The <controller> is normally situated in a control centre. railML provides a logical link between an interlocking and the individual controller. The user can attach useful data to this link, such as addresses that may be granted control over this interlocking.
railML will not define the nature of the addresses, i.e IP-addresses or hexadecimal address of terminals that communicate with the interlocking via some serial bus. The protocol (IP, UDP, serial, parallel) is irrelevant to railML. Note that a Control Centre (DE: Leitstelle, FR: Poste de controle, NL: VL-post) is likely to control multiple interlockings and vice versa, one interlocking can be controlled from multiple control centres, an n:m relation.
This implies that a control centre can have multiple controllers, defined as a terminal from which a signalman controls an interlocking. The interlocking is unaware of the control centre but aware of the controller.
The associations for a controller are defined with these elements:
- <controlledAssets> – This is the container with the lists of all assets, which can be controlled from this <controller>. There are the two possible types of child element:
- <controlledInterlocking> - This is the reference to any <signalBox> (interlocking), which can be controlled from this <controller>. Additionally the extent of control according chapter 1.33is to be given.
- <controlledSystemAsset> – This is the reference to any <systemAsset>, which can be controlled from this <controller>. This will especially cover any system assets, which are only controlled from here but not from any interlocking. Additionally the extent of control according chapter 1.33is to be given.
- <itineraries> – This is the container for all route combinations as <itinerary> this <controller> has available to dispatch any train on its way from starting OCP to the destination OCP. Per route combination the start and destination point is referred and each single route forming the continuous path are referred. The principle is similar to combined routes as described in chapter 1.31. Within such <itinerary> there are no alternative sections defined. ONLY in railML3.1!
- <routeSequences> – This is the container for all route combinations as <routeSequence> this <controller> has available to dispatch any train on its way from starting OCP to the destination OCP. Per route combination the start and destination point is referred and each single route forming the continuous path are referred. The principle is similar to combined routes as described in chapter 1.31. Within such <routeSequence> there are no alternative sections defined.
Additional Information
Notes
Open Issues