IL:destinationPoint

Documentation

Syntax

Autoexport from the XML-Schema for element IL:destinationPoint of railML® version 3.2 UML-visualization of IL
Documentation	destination point of a secured running path
Subschema	interlocking
Parents*	destinationPoints
Children	belongsToOperationalPoint (0..*), designator (0..*), hasCommand (0..*), hasDangerPoint (0..1), hasIndication (0..*), hasIndicator (0..1), hasOverlap (0..*), objectName (0..*), refersTo (1..1)
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:destinationPoint of railML® version 3.1 UML-visualization of IL
Documentation	destination point of a secured running path
Subschema	interlocking
Parents*	destinationPoints
Children	any (0..*), designator (0..1), hasDangerPoint (0..1), hasOverlap (0..*), refersTo (1..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.

Best Practice / Examples

Especially for systems without explicit routes but limited running path handling like RBC of ETCS, there may be definitive destination points related to a physical track asset without a particular route but with the definition of overlaps and/or danger points. Therefore it is possible to have a list of such destination points within <assetsForIL>. The container <knowsDestinationPoint> has the same structure as <routeExit>. Refer also chapter 1.26above.

• <refersTo> – This is the reference to the physical end of the route path. This is can be any physical track asset from infrastructure marking the path end.
• <hasDangerPoint> – This is the reference to the danger point in advance of the destination point. For details refer chapter 1.1.18above.
• <hasOverlap> – This is the reference to the path in advance of the destination point as a safety precaution. For details refer chapter 1.1.19above.

The example shows a destination point at signal 69A. It shall be noted the reference sig04 does not refer to the <signalIL> element in the interlocking but the <signalIS> element in infrastructure.

<destinationPoint id="dstp_69A1">
        <designator register="_SimpleRegister" entry="Dest 69A"/>
        <refersTo ref="sig04"/>
        <hasDangerPoint ref="dp02" />
        <hasOverlap ref="ov02" />
</destinationPoint>