Introduction
Documentation
Syntax
|
|
| Documentation
|
identifies the routes that may never be simultaneously allocated
|
| Subschema
|
interlocking
|
| Parents*
|
conflictingRoutes
|
| Children
|
belongsToOperationalPoint (0..*), conflictsWithRoute (1..*), designator (0..*), hasCommand (0..*), hasIndication (0..*), objectName (0..*), reasonForConflict (0..*), refersToRoute (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.
|
|
|
| Documentation
|
identifies the routes that may never be simultaneously allocated
|
| Subschema
|
interlocking
|
| Parents*
|
conflictingRoutes
|
| Children
|
any (0..*), conflictsWithRoute (1..*), designator (0..1), reasonForConflict (0..*), refersToRoute (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.
Semantics
Best Practice / Examples
In general the interlocking logic can identify and exclude any conflicts of route combinations which requires elements in contradicting way. However, there may be topologies and rules where such conflicts are not obvious from the physical data. Such conflicts shall be defined in particular.
The route conflict table identifies the routes that may never be simultaneously allocated, due to utilisation of common track elements. Conflicting routes are listed as part of the AssetsForIL container. The element <knowsConflictingRoute> is a tuple of references to both routes that cannot be used simultaneously plus a list of conflict reasons. In most cases there will be two entries for both views of the combination, which might be seen as duplicate information. However, it cannot be excluded that the combinations are not symmetrically. Therefore each conflict view shall be listed, especially the conflict reason may differ. The particular information is contained in:
- <refersToRoute> – This is the reference to the route that shall be established.
- <conflictsWithRoute> – This is the reference to the route that conflicts with the selected route. This can be more than one route. However, only the routes shall be listed that have the same combination of conflict reasons.
- <reasonForConflict> – This contains the pair of conflict reasons in @origin with the reference to the causing element in @refersTo. Both attributes are mandatory when listing a conflict. The list of possible conflict reasons is
- ConflictingOverlap – This value is set in case of the overlap of either route causes the conflict.
- ConflictingSwitchPosition – This value is used in case any movable element, not only switches, required by the route needs another position then the conflicting route.
- ConflictingStatus – This value is used in case the status of any element like logical device or signal is not in accordance with the needs of the route because of the conflicting route.
- OverlappingTVDsection – This value is used in case of any TVD section of the route is also used by the conflicting one.
- ConflictingHeadProtection – This value is used in case any signal that shall provide flank/head protection to either route is used as route destination for the other route, which is excluded to be simultaneously.
- other:… – There is another conflict reason. This is the optional extension of the list. Each entry needs to start with the string “other:” and shall have at least two letters in addition.
- @refersTo – This is the reference to the track asset causing the conflict. This is typically a tvdSection, movableElement, signalIL or logicalDevice.
The example shows the two exit routes from ARN station, which are obviously exclusive to each other. For such cases normally the conflict does not need to be defined explicitly. However, the example shows that more than one conflict reason may be named and both “sides” of the conflict shall be defined. Although not in the simple case here but the conflict reasons may differ when looking from the other side. It shall be noted that for simplification only one overlapping TVD section is named in the example.
<conflictingRoutes>
<conflictingRoute id="crt_01">
<designator register="_SimpleRegister" entry="conflict rt1-rt2"/>
<refersToRoute ref="rt_sig02_sig04"/>
<conflictsWithRoute ref="rt_sig01_sig04"/>
<reasonForConflict origin="conflictingSwitchPosition" refersTo="pt_swi01"/>
<reasonForConflict origin="overlappingTVDsection" refersTo="X01T"/>
</conflictingRoute>
<conflictingRoute id="crt_02">
<designator register="_SimpleRegister" entry="conflict rt2-rt1"/>
<refersToRoute ref="rt_sig01_sig04"/>
<conflictsWithRoute ref="rt_sig02_sig04"/>
<reasonForConflict origin="conflictingSwitchPosition" refersTo="pt_swi01"/>
<reasonForConflict origin="overlappingTVDsection" refersTo="X01T"/>
</conflictingRoute>
</conflictingRoutes>
Additional Information
Notes
Open Issues