IL:controlledInterlocking

From railML 3 Wiki
Jump to navigation Jump to search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element IL:controlledInterlocking of railML® version 3.2
Documentation The reference to a signalBox (interlocking) controlled from this unit.
Subschema interlocking
Parents* controlledAssets
Children connectedSignalBox (1..1)
Attributes:
  • extentOfControl: The control level (optional; xs:string)
Possible values:
  • fullControl: The control of an element is in both directions, i.e. sending commands and receiving element status
  • none: There is no control at all, i.e. the element is static
  • notificationOnly: The control of an element allows only for receiving the element status
  • steeringOnly: The control of an element allows only for sending commands
*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:controlledInterlocking of railML® version 3.1
Documentation The reference to a signalBox (interlocking) controlled from this unit.
Subschema interlocking
Parents* controlledAssets
Children any (0..*), connectedSignalBox (1..1), designator (0..1)
Attributes:
  • extentOfControl: The control level (optional; xs:string)
Possible values:
  • steeringOnly
  • none
  • notificationOnly
  • fullControl,

  • 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

Additional Information

Notes

Open Issues