IL:shuntingZone

From railML 3 Wiki
Revision as of 19:39, 29 January 2020 by RailML Coord Documentation (talk | contribs) (→‎{{examples}}: Tutorial)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to 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 assetName (0..*), belongsToOperationalPoint (0..1), designator (0..*), hasCommand (0..*), hasIndication (0..*), isLimitedBy (0..*), trackAssetInArea (0..*)
Attributes:
  • belongsToParent: The reference to another RestrictedArea of the same type used as parent to group them together.

    - if some information exists in parent and child, then information in child overwrites it in child

    -if some information exists only in parent, then child inherits this information from parent (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}}),

  • 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.

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}}); 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 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>
🗒️
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.
  • <trackAssetInArea> - This is the reference to track assets located inside the defined area. The references shall be made preferable to interlocking elements. These elements give supplementary information for definition of the area as the pure limits might not be sufficient.
  • @belongsToParent - This optional attribute contains a reference to an element of the same type which is superior to this element, i.e. this is used for aggregation of several areas of same type.
 


Additional Information

Notes

Open Issues