Autoexport from the XML-Schema for element IL:controlsSystemAsset of railML® version 3.2 | |
Documentation | The references to the system assets the interlocking controls |
Subschema | interlocking |
Parents* | signalBox |
Children | connectedSystemAsset (1..*) |
Attributes:
| |
*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. |
IL:controlsSystemAsset
Jump to navigation
Jump to search
Introduction
Documentation
Syntax
Autoexport from the XML-Schema for element IL:controlsSystemAsset of railML® version 3.1 | |
Documentation | The references to the system assets the interlocking controls |
Subschema | interlocking |
Parents* | signalBox |
Children | any (0..*), connectedSystemAsset (1..1), designator (0..1) |
Attributes:
| |
*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
The interlocking knows an amount of track assets and routes, however, not for each and every element it has the full steering authority. Some elements just notify their status to the interlocking, e.g. an autonomous working level crossing. In order to mark this level of control authority the attribute @extentOfControl is combined with each asset reference. It can have the following values:
- steeringOnly – The control is one sided only in command (steering) direction, i.e. there is no feedback on the command actions foreseen.
- fullControl – The control covers both directions – commanding and status messages as feedback.
- notificationOnly – The control is one sided only in message (notification) direction, i.e. only the status messages can be received but no command action is possible.
- none – There is no control whatsoever possible. This will be used for any assets where the physical presence is needed as information.