IL:shuntingZone

From railML 3 Wiki
Jump to: navigation, search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element IL:shuntingZone of railML® version 3.2
Documentation Simple zone defined for shunting movements.
Subschema interlocking
Parents* shuntingZones
Children any (0..*), assetName (0..*), belongsToOperationalPoint (0..1), designator (0..*), hasCommand (0..*), hasIndication (0..*), isLimitedBy (0..*), trackAssetInArea (0..*)
Attributes:
  • elementNumber: element number for internal referencing in the engineering data (optional; xs:nonNegativeInteger),

  • id: unique identifier (optional; 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}\})
*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:shuntingZone of railML® version 3.1
Documentation Simple zone defined for shunting movements.
Subschema interlocking
Parents* shuntingZones
Children any (0..*), designator (0..1), isLimitedBy (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}\})
*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.

Semantics

Best Practice / Examples

In contrast to local operation area some operators need to define a more simple type of shunting zone for various purpose, e.g. for shunting of ETCS trains. Within ETCS a shunting area is used to limit an area for train movements without the need of MA. However, the train movement might be controlled by shunting routes or so. Subsequently the definition of such areas might not be known to an interlocking but it is needed inside RBC data.

The list of assets inside the area can be any net elements like TVD sections or balises. At least the list of balises permissible to pass in shunting mode is announced by the RBC to the train.

The limits of such an area are not necessarily train detection devices (end of TVD sections). However, the list shall refer to physical assets on the track like end of TVD sections, balises or fixed signals (boards).

The example shows the definition of an ETCS shunting zone including the entire station of Cstadt.

<shuntingZone id="rae01"> 
        <designator register="_SimpleRegister" entry="Cstadt RA1"/>
        <isLimitedBy ref="bus01"/>
        <isLimitedBy ref="bus02"/>
        <isLimitedBy ref="mb_sig03"/>
</shuntingZone>
Note.png
restrictedAreas

restrictedArea is an abstract class, which is instantiated for any kind of special controlled area within the network. It will be than enriched by the particular classes of the area. The elements available for each instantiation are:

  • <isLimitedBy> – This is the reference to track assets forming the limits of the defined area. The references shall be made preferable to interlocking elements.


Additional Information

Notes

Open Issues