IL:routeRelation

Documentation

Syntax

Autoexport from the XML-Schema for element IL:routeRelation of railML® version 3.3 UML-visualization of IL
Documentation	states the conditions that must be fulfilled for a given signal to be open
Subschema	interlocking
Parents*	routeRelations
Children	belongsToOperationalPoint (0..*), designator (0..*), elementState (0..*), hasCommand (0..*), hasIndication (0..*), objectName (0..*), requiredCrossingPosition (0..*), requiredDerailerPosition (0..*), requiredDetectorState (0..*), requiredKeyLockState (0..*), requiredLevelCrossingState (0..*), requiredSectionState (0..*), requiredSignalAspect (0..*), requiredSwitchPosition (0..*), requiredTunnelGateState (0..*)
Attributes: elementNumber: element number of the object for internal referencing in the engineering data (optional; xs:nonNegativeInteger), 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:routeRelation of railML® version 3.2 UML-visualization of IL
Documentation	states the conditions that must be fulfilled for a given signal to be open
Subschema	interlocking
Parents*	routeRelations
Children	belongsToOperationalPoint (0..*), designator (0..*), hasCommand (0..*), hasIndication (0..*), objectName (0..*), requiredCrossingPosition (0..*), requiredDerailerPosition (0..*), requiredDetectorState (0..*), requiredKeyLockState (0..*), requiredLevelCrossingState (0..*), requiredSectionState (0..*), requiredSignalAspect (0..*), requiredSwitchPosition (0..*), requiredTunnelGateState (0..*)
Attributes: elementNumber: element number of the object for internal referencing in the engineering data (optional; xs:nonNegativeInteger), 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:routeRelation of railML® version 3.1 UML-visualization of IL
Documentation	states the conditions that must be fulfilled for a given signal to be open
Subschema	interlocking
Parents*	routeRelations
Children	any (0..*), designator (0..1), requiredCrossingPosition (0..*), requiredDerailerPosition (0..*), requiredDetectorState (0..*), requiredKeyLockState (0..*), requiredLevelCrossingState (0..*), requiredSectionState (0..*), requiredSignalAspect (0..*), requiredSwitchPosition (0..*)
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 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 children have been changed.

The attributes have been changed.

Best Practice / Examples

A route relation states the conditions that must be fulfilled for the route start signal to be open. The relation consists of the affected route and any track asset with its related state. Subsequently the signal may only open when the relation is fulfilled. One possible use is for definition of specific flank protection conditions.

Note that these relations may well be captured in a control table, once it is implemented in the schema. Therefore, the use is optional.

The relationship is described in <routeRelation> for the various types of assets. For details refer chapter 1.1.15above.

• <requiredSwitchPosition> – This is the reference to the related switch, its position and the level of enforcement.
• <requiredDerailerPosition> – This is the reference to the related derailer, its position and the level of enforcement.
• <requiredCrossingPosition> – This is the reference to the related movable crossing, its position and the level of enforcement.
• <requiredDetectorState> – This is the reference to the related detector, its state and the level of enforcement.
• <requiredSignalAspect> – This is the reference to the related signal, the aspect it shows and the level of enforcement.
• <requiredSectionState> – This is the reference to the related TVD section, its state and the level of enforcement.
• <requiredKeyLockState> – This is the reference to the related key lock, its state and the level of enforcement.

• <requiredLevelCrossingState> – This is the reference to the related level crossing, its state and the level of enforcement.

The extract shows the relationship between the occupation status of the start track A02T and the route from start signal 68N1 to destination signal 69A.

<routeRelation id="rtr01">
        <requiredSectionState mustOrShould="must" proving="continuously">
                <relatedSectionAndVacancy inState="occupied">
                        <refersToSection ref="A02T" />
                </relatedSectionAndVacancy>
        </requiredSectionState>
</routeRelation>