IL:permissionZone

From railML 3 Wiki
Jump to: navigation, search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element IL:permissionZone of railML® version 3.2
Documentation A set of track assets inside a station which can have different operating permissions (being controlled from a different controller) as the rest of the station
Subschema interlocking
Parents* permissionZones
Children any (0..*), assetName (0..*), belongsToOperationalPoint (0..1), canBeControlledBy (1..*), controlledElement (1..*), designator (0..*), hasCommand (0..*), hasIndication (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:permissionZone of railML® version 3.1
Documentation A set of track assets inside a station which can have different operating permissions (being controlled from a different controller) as the rest of the station
Subschema interlocking
Parents* permissionZones
Children any (0..*), canBeControlledBy (1..*), controlledElement (1..*), designator (0..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 order to have clear command path only one operator/controller is exclusively allowed to operate assets by the interlocking. However, the permission to operate assets can be shifted to another predefined operator/controller. Subsequently zones have to be defined, describing the set of assets for which the permission is transferred. In the simple case the permission can only be changed for the entire station or interlocking. Then no particular definition of affected assets might be necessary.

Although a permission zone might appear as another type of restrictedArea on the first glance the way of defining the zone is different.

  • <canBeControlledBy> – This is the reference to any controller, i.e. operator/train dispatcher place, which can use the zone for manual commands.
  • <controlledElement> - This is the reference to any element which belong to the area and will have the same operating permissions.
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