Introduction
Documentation
Syntax
Autoexport from the XML-Schema for element IL:controller of railML ® version 3.3 |
| 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..*), elementState (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: the identifier of the object; this can be either of type xs:ID or UUID (obligatory;
xs:ID); 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.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
There exists an overview of all changes between railML® 3.1 and railML® 3.2 on page Dev:Changes/3.2.
The parents have been changed.
The children have been changed.
The attributes have been changed.
Changes 3.2→3.3
There exists an overview of all changes between railML® 3.2 and railML® 3.3 on page Dev:Changes/3.3.
The parents have been changed.
The children have been 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