Introduction
Documentation
Syntax
|
|
| Documentation
|
Crossings are a special item for interlockings as a position is required for them even if there is no really movable item trackside. Here the functional aspects for interlocking operation are considered.
Here both simple crossings and crossings with movable frog are considered.
|
| Subschema
|
interlocking
|
| Parents*
|
movableCrossings
|
| Children
|
assetName (0..*), belongsToOperationalPoint (0..1), branchDownLeft (0..1), branchDownRight (0..1), branchUpLeft (0..1), branchUpRight (0..1), connectedToPowerSupply (0..1), designator (0..*), elementState (0..*), hasCommand (0..*), hasFoulingTrainDetectors (0..*), hasGaugeClearanceMarker (0..*), hasIndication (0..*), hasTvdSection (0..1), refersTo (1..2), relatedMovableElement (0..1)
|
Attributes:
- preferredPosition: This is the preferred position of the crossing which it is switched to when not in use. (optional;
xs:string)
- Possible values:
- downleft-rightup: Description of a logical position of a simple crossing within a route path from the lower left to upper right
- indifferent: The position does not matter for the use.
- upleft-rightdown: Description of a logical position of a simple crossing within a route path from the upper left to lower right,
- isKeyLocked: One of boolean true or false. True means that the switch is clamped either mechanically or by any electric or electronic means. The interlocking shall never attempt to throw a clamped switch. (optional;
xs:boolean),
- localOperated: This gives information, whether the derailer is locally operated independent of any <signalBox>. (optional;
xs:string; patterns: other:w{2,}; consider Dev:UsingAny too.)
- Possible values:
- electrical: For the local operation an electrical drive is used.
- mechanical: The local operation is made by means of mechanics, e.g. lever with counterweight.
- none: There is no possibility of local operation of this device.,
- maxThrowTime: Maximum time in milliseconds during which the IL can drive the element. If it has not reached end-position before this timer expires, the interlocking stops throwing as to prevent damage. (optional;
xs:duration),
- numberOfBladeSwitchActuators: number of switch actuators controlled from interlocking to throw the switch blades, 0 means no direct operation from the interlocking (optional;
xs:nonNegativeInteger),
- numberOfFrogSwitchActuators: number of switch actuators controlled from interlocking to throw the frog nose(s), 0 means no movable frog (optional;
xs:nonNegativeInteger),
- returnsToPreferredPosition: The automatic normalisation attribute is closely related to the preferred position. Whether or not the IL returns the element to its preferred position depends on this parameter. E.g. a derailer that is modelled as ... preferredPosition=engaged autoNormalisation=true ... will return to its engaged position when released. A switch modelled as preferredPosition=right autoNormalisation=false... will not automatically return to the right position when released. This combination of attributes is useful for geographical interlockings that automatically determine the preferred routes given the preferred position of intervening switches. (optional;
xs:boolean),
- typicalThrowTime: typical throw time is the average time it takes between the moment the IL receives the call and the element reaches the new position. Switch throwing adds a delay to route setting that is of great interest to the use case simulation. For this purpose, we add an attribute typicalThrowTime that allows capacity planners to estimate the influence of slow throwing switches on train traffic. Note that this excludes controller (OCS) processing time and communication between controller (OCS) and interlocking. (optional;
xs:duration),
- elementNumber: element number 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.
|
|
|
| Documentation
|
Crossings are a special item for interlockings as a position is required for them even if there is no really movable item trackside. Here the functional aspects for interlocking operation are considered.
|
| Subschema
|
interlocking
|
| Parents*
|
movableCrossings
|
| Children
|
assetName (0..*), belongsToOperationalPoint (0..1), branchDownLeft (1..1), branchDownRight (1..1), branchUpLeft (1..1), branchUpRight (1..1), connectedToPowerSupply (0..1), designator (0..*), hasCommand (0..*), hasFoulingTrainDetectors (0..*), hasGaugeClearanceMarker (0..2), hasIndication (0..*), hasTvdSection (0..1), refersTo (1..2), relatedMovableElement (0..1)
|
Attributes:
- preferredPosition: This is the preferred position of the crossing which it is switched to when not in use. (optional;
xs:string)
- Possible values:
- downleft-rightup: Description of a logical position of a simple crossing within a route path from the lower left to upper right
- upleft-rightdown: Description of a logical position of a simple crossing within a route path from the upper left to lower right,
- isKeyLocked: One of boolean true or false. True means that the switch is clamped either mechanically or by any electric or electronic means. The interlocking shall never attempt to throw a clamped switch. (optional;
xs:boolean),
- localOperated: This gives information, whether the derailer is locally operated independent of any <signalBox>. (optional;
xs:string; patterns: other:w{2,}; consider Dev:UsingAny too.)
- Possible values:
- electrical: For the local operation an electrical drive is used.
- mechanical: The local operation is made by means of mechanics, e.g. lever with counterweight.
- none: There is no possibility of local operation of this device.,
- maxThrowTime: Maximum time in milliseconds during which the IL can drive the element. If it has not reached end-position before this timer expires, the interlocking stops throwing as to prevent damage. (optional;
xs:duration),
- numberOfBladeSwitchActuators: number of switch actuators controlled from interlocking to throw the switch blades, 0 means no direct operation from the interlocking (optional;
xs:nonNegativeInteger),
- numberOfFrogSwitchActuators: number of switch actuators controlled from interlocking to throw the frog nose(s), 0 means no movable frog (optional;
xs:nonNegativeInteger),
- returnsToPreferredPosition: The automatic normalisation attribute is closely related to the preferred position. Whether or not the IL returns the element to its preferred position depends on this parameter. E.g. a derailer that is modelled as ... preferredPosition=engaged autoNormalisation=true ... will return to its engaged position when released. A switch modelled as preferredPosition=right autoNormalisation=false... will not automatically return to the right position when released. This combination of attributes is useful for geographical interlockings that automatically determine the preferred routes given the preferred position of intervening switches. (optional;
xs:boolean),
- typicalThrowTime: typical throw time is the average time it takes between the moment the IL receives the call and the element reaches the new position. Switch throwing adds a delay to route setting that is of great interest to the use case simulation. For this purpose, we add an attribute typicalThrowTime that allows capacity planners to estimate the influence of slow throwing switches on train traffic. Note that this excludes controller (OCS) processing time and communication between controller (OCS) and interlocking. (optional;
xs:duration),
- elementNumber: element number 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
|
Crossings are a special item for interlockings as a position is required for them even if there is no really movable item trackside. Here the functional aspects for interlocking operation are considered.
|
| Subschema
|
interlocking
|
| Parents*
|
movableCrossings
|
| Children
|
any (0..*), branchDownLeft (1..1), branchDownRight (1..1), branchUpLeft (1..1), branchUpRight (1..1), connectedToPowerSupply (0..1), designator (0..1), hasFoulingTrainDetectors (0..*), hasGaugeClearanceMarker (0..2), hasTvdSection (0..1), refersTo (1..1), relatedMovableElement (0..1)
|
Attributes:
- preferredPosition: This is the preferred position of the crossing which it is switched to when not in use. (optional;
xs:string)
- Possible values:
- upleft-rightdown
- downleft-rightup,
- maxThrowTime: Maximum time in milliseconds during which the IL can drive the element. If it has not reached end-position before this timer expires, the interlocking stops throwing as to prevent damage. (obligatory;
xs:duration),
- typicalThrowTime: typical throw time is the average time it takes between the moment the IL receives the call and the element reaches the new position. Switch throwing adds a delay to route setting that is of great interest to the use case simulation. For this purpose, we add an attribute typicalThrowTime that allows capacity planners to estimate the influence of slow throwing switches on train traffic. Note that this excludes controller (OCS) processing time and communication between controller (OCS) and interlocking. (optional;
xs:duration),
- returnsToPreferredPosition: The automatic normalisation attribute is closely related to the preferred position. Whether or not the IL returns the element to its preferred position depends on this parameter. E.g. a derailer that is modelled as ... preferredPosition=engaged autoNormalisation=true ... will return to its engaged position when released. A switch modelled as preferredPosition=right autoNormalisation=false... will not automatically return to the right position when released. This combination of attributes is useful for geographical interlockings that automatically determine the preferred routes given the preferred position of intervening switches. (optional;
xs:boolean),
- isKeyLocked: One of boolean true or false. True means that the switch is clamped either mechanically or by any electric or electronic means. The interlocking shall never attempt to throw a clamped switch. (optional;
xs:boolean),
- numberOfBladeSwitchActuators: number of switch actuators controlled from interlocking to throw the switch blades, 0 means no direct operation from the interlocking (optional;
xs:nonNegativeInteger),
- numberOfFrogSwitchActuators: number of switch actuators controlled from interlocking to throw the frog nose(s), 0 means no movable frog (optional;
xs:nonNegativeInteger),
- 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 parents have been changed.
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 element documentation has been changed.
The parents have been changed.
The children have been changed.
The attributes have been changed.
Semantics
Best Practice / Examples
A crossing is described as element of the track network, where two tracks are crossing at the same height without having the possibility to change between the two tracks. Such elements are often called “diamond crossing” or “simple crossing” because of their shape. They shall not be mixed up with single or double slip switches, which are a combination of switches with a crossing within one element.
In majority of cases such crossings are just passive, i.e. there is nothing moving on its trackwork. Thus the “movable” in the element name seems to be incorrect. However, modern interlockings needs to assign a particular position to a crossing whether this is physically needed or not. Subsequently the crossing as represented in the interlocking can have a position. In case of switch actuators connected to the crossing for changing its position the attribute @numberOfFrogSwitchActuators shall be used to identify their number. Otherwise the value “0” shall be set or the attribute not used at all.
The picture shows the typical representation of a crossing in a schematic track plan. Therefore its configuration is always considered diagonal when describing its features.
Note: The above picture shows the often-used combination of four switches with a diamond crossing to interconnect two parallel tracks. This complete arrangement of four switches and the crossing is called “scissor crossing” or “scissor crossover”. Refer also to https://dccwiki.com/Crossing (external link).
With the presumption of the crossing can have a position for the interlocking system, virtual or in reality, it is modelled as movable element. The instantiation extends the abstract type of movableElement by some additional elements and attributes.
- <refersTo> – This is the reference to the track asset <crossing> from the infrastructure part.
- <branchUpLeft> – This the reference to the underlying track element in infrastructure forming its upper left branch.
- <branchUpRight> – This the reference to the underlying track element in infrastructure forming its upper right branch.
- <branchDownLeft> – This the reference to the underlying track element in infrastructure forming its lower left branch.
- <branchDownRight> – This the reference to the underlying track element in infrastructure forming its lower right branch.
Note: The references to the branches are needed to determine the orientation of the crossing in the track network and which neighbouring element is located at which branch. The reference to <track> would follow the general practice to refer from interlocking to functional infrastructure. However, there may be the <track> element defined across the entire crossing or no <track> defined at all. Thus in this special case the reference would be preferable to the <netElement> in the topology.
- <hasFoulingTrainDetectors> – This is the reference to the train detectors delimiting the TVD section of this crossing, which are too close and cannot guarantee a clear gauge of the set track.
- @preferredPosition – This marks the switch position, which the crossing shall have when not in use of a route. The possible positions can be downleft-rightup and upleft-rightdown where the combination between up and down indicates the branches of the crossing a train would drive on.
Simple Crossing
Because the simple example as shown in chapter 1.4does not contain any special trackwork elements like crossings or slip switches there is the need for special examples. It shall be noted that the representation in infrastructure is given here just as base for the interlocking element example. However, it is not yet approved by infrastructure community and may be subject to alterations.
The physical appearance of the simple crossing with its components is shown above. Based on the extract from a real plan in chapter 1.1.3the track plan just for a crossing with neighbouring tracks is shown in the figure below.
The related representation in infrastructure topology could be sketched like in the figure below. Only the <netElement> and <netRelation> instances are drawn.
Transferring this topology into railML we need first the four instances of <netElement>.
<netElements>
<netElement id="ne_a01">
<name name="branch322-822" language="en"/>
<associatedPositioningSystem id="pos01">
<intrinsicCoordinate intrinsicCoord="0.0" id="a01.0" />
<intrinsicCoordinate intrinsicCoord="1.0" id="a01.1" />
</associatedPositioningSystem>
</netElement>
<netElement id="ne_a02">
<name name="branch331-822" language="en"/>
<associatedPositioningSystem id="pos02">
<intrinsicCoordinate intrinsicCoord="0.0" id="a02.0" />
<intrinsicCoordinate intrinsicCoord="1.0" id="a02.1" />
</associatedPositioningSystem>
</netElement>
<netElement id="ne_a03">
<name name="branch324-822" language="en"/>
<associatedPositioningSystem id="pos03">
<intrinsicCoordinate intrinsicCoord="0.0" id="a03.0" />
<intrinsicCoordinate intrinsicCoord="1.0" id="a03.1" />
</associatedPositioningSystem>
</netElement>
<netElement id="ne_a04">
<name name="branch333-822" language="en"/>
<associatedPositioningSystem id="pos04">
<intrinsicCoordinate intrinsicCoord="0.0" id="a04.0" />
<intrinsicCoordinate intrinsicCoord="1.0" id="a04.1" />
</associatedPositioningSystem>
</netElement>
</netElements>
Although the figure above shows only the two navigable relations in railML we shall list all possible combinations in the <netRelations>.
<netRelations>
<netRelation id="nr_a01a02" navigability="None" positionOnA="1" positionOnB="0">
<name name="rel322-822-331" language="en"/>
<elementA ref="ne_a01" />
<elementB ref="ne_a02" />
</netRelation>
<netRelation id="nr_a01a03" navigability="None" positionOnA="1" positionOnB="1">
<name name="rel322-822-324" language="en"/>
<elementA ref="ne_a01" />
<elementB ref="ne_a03" />
</netRelation>
<netRelation id="nr_a01a04" navigability="Both" positionOnA="1" positionOnB="0">
<name name="rel322-822-333" language="en"/>
<elementA ref="ne_a01" />
<elementB ref="ne_a04" />
</netRelation>
<netRelation id="nr_a02a04" navigability="None" positionOnA="0" positionOnB="0">
<name name="rel331-822-333" language="en"/>
<elementA ref="ne_a02" />
<elementB ref="ne_a04" />
</netRelation>
<netRelation id="nr_a03a02" navigability="Both" positionOnA="1" positionOnB="0">
<name name="rel324-822-331" language="en"/>
<elementA ref="ne_a03" />
<elementB ref="ne_a02" />
</netRelation>
<netRelation id="nr_a03a04" navigability="None" positionOnA="1" positionOnB="0">
<name name="rel324-822-333" language="en"/>
<elementA ref="ne_a03" />
<elementB ref="ne_a04" />
</netRelation>
</netRelations>
Finally the <topology> element requires the collection of these information within a <network>.
<networks>
<network id="netw_01">
<level id="netlv_01">
<networkResource ref="ne_a01"/>
<networkResource ref="ne_a02"/>
<networkResource ref="ne_a03"/>
<networkResource ref="ne_a04"/>
<networkResource ref="nr_a01a02"/>
<networkResource ref="nr_a01a03"/>
<networkResource ref="nr_a01a04"/>
<networkResource ref="nr_a02a04"/>
<networkResource ref="nr_a03a02"/>
<networkResource ref="nr_a03a04"/>
</level>
</network>
</networks>
In the infrastructure the various objects needs to be defined in <functionalInfrastructure>. Just for the sake of limiting the viewed area of the example the <borders> are needed.
<borders>
<border type="area" id="brd01">
<spotLocation id="sl_brd01" netElementRef="ne_a01" pos="0.0" applicationDirection="both"/>
</border>
<border type="area" id="brd02">
<spotLocation id="sl_brd02" netElementRef="ne_a02" pos="1.0" applicationDirection="both"/>
</border>
<border type="area" id="brd03">
<spotLocation id="sl_brd03" netElementRef="ne_a03" pos="0.0" applicationDirection="both"/>
</border>
<border type="area" id="brd04">
<spotLocation id="sl_brd04" netElementRef="ne_a04" pos="1.0" applicationDirection="both"/>
</border>
</borders>
As the interlocking needs also information to the neighbouring relations of track elements <tracks> are needed. In infrastructure a <track> can be a part of just one <netElement> or span over several <netElements>. For simplicity the four tracks are comprising the complete <netElement> from the <border> to the <crossing>. It would be also possible to use other limits like the <trainDetectionElements>.
<tracks>
<track type="mainTrack" id="trk01">
<linearLocation id="ltrk01" applicationDirection="both">
<associatedNetElement keepsOrientation="true" netElementRef="ne_a01" />
</linearLocation>
<trackBegin ref="brd01" />
<trackEnd ref="crx01" />
<length type="operational" value="100" />
</track>
<track type="mainTrack" id="trk02">
<linearLocation id="ltrk02" applicationDirection="both">
<associatedNetElement keepsOrientation="true" netElementRef="ne_a02" />
</linearLocation>
<trackBegin ref="crx01" />
<trackEnd ref="brd02" />
<length type="operational" value="100" />
</track>
<track type="mainTrack" id="trk03">
<linearLocation id="ltrk03" applicationDirection="both">
<associatedNetElement keepsOrientation="true" netElementRef="ne_a03" />
</linearLocation>
<trackBegin ref="brd03" />
<trackEnd ref="crx01" />
<length type="operational" value="100" />
</track>
<track type="mainTrack" id="trk04">
<linearLocation id="ltrk04" applicationDirection="both">
<associatedNetElement keepsOrientation="true" netElementRef="ne_a04" />
</linearLocation>
<trackBegin ref="crx01" />
<trackEnd ref="brd04" />
<length type="operational" value="100" />
</track>
</tracks>
For the definition of <tvdSections> in interlocking the <trainDetectionElements> needs to be listed. We assume axle counter detection points naming them according the related sections.
<trainDetectionElements>
<trainDetectionElement id="ax_dp01" type="axleCounter">
<name name="ax322_822" language="en"/>
<spotLocation netElementRef="ne_a01" id="ax_dpp01" pos="0.5" applicationDirection="both"/>
</trainDetectionElement>
<trainDetectionElement id="ax_dp02" type="axleCounter">
<name name="ax822_331" language="en"/>
<spotLocation netElementRef="ne_a02" id="ax_dpp02" pos="0.5" applicationDirection="both"/>
</trainDetectionElement>
<trainDetectionElement id="ax_dp03" type="axleCounter">
<name name="ax324_822" language="en"/>
<spotLocation netElementRef="ne_a03" id="ax_dpp03" pos="0.5" applicationDirection="both"/>
</trainDetectionElement>
<trainDetectionElement id="ax_dp04" type="axleCounter">
<name name="ax822_333" language="en"/>
<spotLocation netElementRef="ne_a04" id="ax_dpp04" pos="0.5" applicationDirection="both"/>
</trainDetectionElement>
</trainDetectionElements>
The <crossing> itself looks rather simple as infrastructure element. It is mainly defined by the reference to the <netRelations> of the straight branches.
<crossing id="crx01">
<name name="cr822" language="en"/>
<straightBranch netRelationRef="nr_a01a04" />
<straightBranch netRelationRef="nr_a03a02" />
</crossing>
In the interlocking part the <assetsForIL> shall contain the interlocking known elements. For the example only the <tvdSection> of the crossing and the crossing itself is required. Beside the limiting train detectors, the relation to the infrastructure <tracks> is needed.
<tvdSection residualRouteCancellationDelay="PT90S" partialRouteReleaseDelay="PT60S" isBerthingTrack="false" id="tvd_01">
<designator register="_SimpleRegister" entry="ts_cr822"/>
<hasDemarcatingTraindetector ref="ax_dp01" />
<hasDemarcatingTraindetector ref="ax_dp02" />
<hasDemarcatingTraindetector ref="ax_dp03" />
<hasDemarcatingTraindetector ref="ax_dp04" />
</tvdSection>
The crossing is described as movable element with references to the <tvdSection> and the references to the adjacent <tracks>.
<movableCrossing maxThrowTime="PT10S" id="mov_01" numberOfFrogSwitchActuators="0">
<designator register="_SimpleRegister" entry="cr822"/>
<refersTo ref="crx01" />
<hasTvdSection ref="tvd_01" />
<branchUpLeft ref="trk01" />
<branchUpRight ref="trk02" />
<branchDownLeft ref="trk03" />
<branchDownRight ref="trk04"/>
</movableCrossing>
Additional Information
Notes
Open Issues
