IL:route: Difference between revisions

From railML 3 Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
No edit summary
(added link to forum)
 
Line 127: Line 127:


=={{Additional Information}}==
=={{Additional Information}}==
Flank protection must be represented by {{IL:Tag|routeRelation}} <ref>{{site|1=https://www.railml.org/forum/index.php?t=msg&goto=2629&&srch=flank#msg_2629|2=Flank protection {{rml}} forum post}}</ref>.
==={{Notes}}===
==={{Notes}}===
==={{Open issues}}===
==={{Open issues}}===
== References ==
<references />

Latest revision as of 10:30, 30 May 2024

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element IL:route of railML® version 3.3
    
Documentation path for train movements in railway network secured by interlocking system
Subschema interlocking
Parents*

routes

Children

additionalRelation (0..*), belongsToOperationalPoint (0..*), designator (0..*), elementState (0..*), facingSwitchInPosition (0..*), handlesRouteType (0..*), hasCommand (0..*), hasIndication (0..*), hasReleaseGroup (0..*), hasTvdSection (0..*), intermediateCodePoint (0..*), objectName (0..*), routeActivationSection (0..*), routeEntry (1..1), routeExit (1..1), switchPositionInDepartureTrack (0..*), trailingSwitchInPosition (0..*)

Attributes:
  • approachReleaseDelay: The delay between the request from signalman to release an already approached (definitely locked) route and the real release of associated elements of the route. (optional; xs:duration),

  • locksAutomatically: If true, the interlocking locks this route automatically and immediately after it was cleared. The operator has to intervene if he wishes to call another route. Automatikfahrstrasse in German, trace automatique in French. Note that this functionality is often part of the control system in which case this attribute should be omitted. (optional; xs:boolean),

  • priorityRank: Gives the priority of the route path in case there are several possible paths between entry and exit. The highest priority is 0. (optional; xs:nonNegativeInteger),

  • proceedAspectDelay: The delay for the signal before it will change from closed to any proceed aspect. (optional; xs:duration),

  • processingDelay: The delay in seconds between the moment the interlocking receives the route call and the moment the route the interlocking reports back that the route is locked, i.e. the processing time for setting that route. (optional; xs:duration),

  • residualRouteReleaseDelay: The delay after commanding the release of the remaining route parts until the route elements are finally released. (optional; xs:duration),

  • signalClosureDelay: The delay for the signal after the conditions for proceed aspect are removed and the physical closure of the signal. (optional; xs:duration),

  • elementNumber: element number of the object 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.

 

Autoexport from the XML-Schema for element IL:route of railML® version 3.2
    
Documentation path for train movements in railway network secured by interlocking system
Subschema interlocking
Parents*

routes

Children

additionalRelation (0..*), belongsToOperationalPoint (0..*), designator (0..*), facingSwitchInPosition (0..*), handlesRouteType (0..*), hasCommand (0..*), hasIndication (0..*), hasReleaseGroup (0..*), hasTvdSection (0..*), intermediateCodePoint (0..*), objectName (0..*), routeActivationSection (0..*), routeEntry (1..1), routeExit (1..1), switchPositionInDepartureTrack (0..*), trailingSwitchInPosition (0..*)

Attributes:
  • approachReleaseDelay: The delay between the request from signalman to release an already approached (definitely locked) route and the real release of associated elements of the route. (optional; xs:duration),

  • locksAutomatically: If true, the interlocking locks this route automatically and immediately after it was cleared. The operator has to intervene if he wishes to call another route. Automatikfahrstrasse in German, trace automatique in French. Note that this functionality is often part of the control system in which case this attribute should be omitted. (optional; xs:boolean),

  • priorityRank: Gives the priority of the route path in case there are several possible paths between entry and exit. The highest priority is 0. (optional; xs:nonNegativeInteger),

  • proceedAspectDelay: The delay for the signal before it will change from closed to any proceed aspect. (optional; xs:duration),

  • processingDelay: The delay in seconds between the moment the interlocking receives the route call and the moment the route the interlocking reports back that the route is locked, i.e. the processing time for setting that route. (optional; xs:duration),

  • residualRouteReleaseDelay: The delay after commanding the release of the remaining route parts until the route elements are finally released. (optional; xs:duration),

  • signalClosureDelay: The delay for the signal after the conditions for proceed aspect are removed and the physical closure of the signal. (optional; xs:duration),

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

 

Autoexport from the XML-Schema for element IL:route of railML® version 3.1
    
Documentation path for train movements in railway network secured by interlocking system
Subschema interlocking
Parents*

routes

Children

additionalRelation (0..*), any (0..*), designator (0..1), facingSwitchInPosition (0..*), handlesRouteType (0..*), hasReleaseGroup (0..*), hasTvdSection (0..*), routeActivationSection (0..*), routeEntry (1..1), routeExit (1..1), switchPositionInDepartureTrack (0..*)

Attributes:
  • locksAutomatically: If true, the interlocking locks this route automatically and immediately after it was cleared. The operator has to intervene if he wishes to call another route. Automatikfahrstrasse in German, trace automatique in French. Note that this functionality is often part of the control system in which case this attribute should be omitted. (optional; xs:boolean),

  • processingDelay: The delay in seconds between the moment the interlocking receives the route call and the moment the route the interlocking reports back that the route is locked, i.e. the processing time for setting that route. (optional; xs:duration),

  • proceedAspectDelay: The delay for the signal before it will change from closed to any proceed aspect. (optional; xs:duration),

  • signalClosureDelay: The delay for the signal after the conditions for proceed aspect are removed and the physical closure of the signal. (optional; xs:duration),

  • approachReleaseDelay: The delay between the request from signalman to release an already approached (definitely locked) route and the real release of associated elements of the route. (optional; xs:duration),

  • 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 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 children have been changed.

The attributes have been changed.

Semantics

Best Practice / Examples

A route is a central element to ensure traffic safety in railway networks. The basic definition is a predetermined path for a traffic movement. This path starts from a starting point (usually a signal) and ends at a destination point (usually a signal), univocally identified by the list of switches and their position included in the path. In addition there may be elements outside the (running) path of the route. These elements are overlap, flank protection, TVD sections, intermediate signals, movable elements, level crossings etc. Although they are naturally important to route setting, they are defined in separate elements, which are not necessarily sub-elements of the route itself. See the route control relations, control table, route activation and signal plan section below.

Route.png

A route in its purest form consists only of an entry and exit signal. If there are any switches on the route, their position is associated with the route. The interlocking need only be aware of “atomic” routes from one signal to the next. From a mathematical and modelling point of view, there’s no need to distinguish short “atomic” routes or “elementary” routes from concatenated paths or itineraries, however long.

Beside the physical track elements there are several elements in the <assetsForInterlocking> container, which may be needed for the complete definition of a route within the interlocking logic. These are:

  • <route> – This is the basic definition of the route itself.
  • partialRoute (<routeReleaseGroupAhead>, <routeReleaseGroupRear>) – These are the definitions of route parts especially for route release control.
  • <conflictingRoute> – This is the list of other routes conflicting with it.
  • <routeRelation> – This is the list of additional conditions required for route setting and supervision.
  • <combinedRoute> – This is the list of atomic routes combined to a long route activated by a single command.
  • <overlap> – This is the extension of the route beyond the route destination for safety purpose.
  • <dangerPoint> – This is the point beyond the route destination comprising a danger to the train if it would pass the destination.

When a route is requested, the interlocking sets and locks the objects that make the route safe. The interlocking will look up the objects associated with this route and set them accordingly.

The description of a route starts with the following information:

  • @locksAutomatically – This optional flag indicates whether the route is automatically and immediately re-established and locked after it was cleared by previous train.
  • @processingDelay – The delay time between the moment the interlocking receives the route call and the moment the interlocking reports back that the route is locked, i.e. the processing time for setting that route. There may be systems when the final route lock is only applied when a train is approaching the route. In that case this time is the minimum required before the final route lock can be applied.
  • @proceedAspectDelay – The time the opening of the start signal is delayed for operational reasons, i.e. to slow down an approaching train.
  • @signalClosureDelay – The time the closure of start signal is delayed after the train has passed it, i.e. did sequentially occupy the first route track.
  • @approachReleaseDelay – The delay time between the moment the interlocking receives the request to release an already approached (definitely locked) route and the interlocking really releases all associated elements from the route.
  • <handlesRouteType> – This is the reference to the predefined route type applicable.
  • <routeActivationSection> – This is the description of activation conditions for the route.
  • <facingSwitchInPosition> – This is the list of the switches and their position traversed from their top to define the running path of the route.
  • <routeEntry> – This defines the start of the route path, which is in most cases a signal.
  • <hasTvdSection>- The list of references to the TVD sections within the running path of this route. It is preferred to have an ordered list beginning at <routeEntry>, however this cannot be enforced by the schema.
  • <hasReleaseGroup> – This defines the parts of the route which are released automatically after being cleared by the train.
  • <switchPositionInDepartureTrack> – This is the list of switches and their position which are requested by the route.
  • <routeExit> – This defines the destination of the route path including any danger point or overlap related to the route end.
  • <additionalRelation>– The list of references to relations to elements with their position or state, which are relevant for the route.


Note that information about the route path, which is derivable by using the entry and exit objects together with the railway network, is left out of this definition. This includes TVD sections in the train path and movable objects in the train path.

The skeleton of a route definition is shown in the extract. It is a main route, which is not automatically set after first use. The time for route locking is given as 1 sec, which can only be achieved, if there are no movable elements to be switched. The remaining elements are detailed below. 

<route id="rt_sig02_sig04" locksAutomatically="false" processingDelay="PT1S" >
        <designator register="_SimpleRegister" entry="Route_68N1_69A"/>
        <handlesRouteType ref="rt_main"/>
        <routeActivationSection … />
        <facingSwitchInPosition … />
        <hasTvdSection … />
        <routeEntry … />
        <hasReleaseGroup … />
        <routeExit … />
        <additionalRelation ref="rtr01"/>
</route>

Complete Route

Finally this extract shows the complete definition of a route. The details were already explained above. 

<route id="rt_sig02_sig04" locksAutomatically="false" processingDelay="PT1S" >
        <designator register="_SimpleRegister" entry="Route_68N1_69A"/>
        <handlesRouteType ref="rt_main"/>
        <routeActivationSection id="rt_act01" delayForLock="PT2S" automaticReleaseDelay="PT5S">
                <designator register="_SimpleRegister" entry="activation Route_68N1_69A"/>
                <activationSection ref="A02T"/>
        </routeActivationSection>
        <facingSwitchInPosition id="rp_pt_swi01_li" inPosition="left">
                <designator register="_SimpleRegister" entry="pt01 in left"/>
                <refersToSwitch ref="pt_swi01"/>
        </facingSwitchInPosition>
        <hasTvdSection ref="A68W02T"/>
        <hasTvdSection ref="X01T"/>
        <hasTvdSection ref="LX2.5T"/>
        <hasTvdSection ref="X02T"/>
        <routeEntry id="rts_68N1">
                <designator register="_SimpleRegister" entry="Start 68N1"/>
                <refersTo ref="mb_sig02"/>
                <nonReplacement ref="A68W02T"/>
        </routeEntry>
        <hasReleaseGroup ref="prt02"/>
        <hasReleaseGroup ref="prt03"/>
        <hasReleaseGroup ref="prt04"/>
        <hasReleaseGroup ref="prt05"/>
        <hasReleaseGroup ref="prt06"/>
        <routeExit id="rtd_69A">
                <designator register="_SimpleRegister" entry="Dest 69A"/>
                <refersTo ref="ls_sig04"/>
                <hasDangerPoint ref="dp01" />
                <hasOverlap ref="ov01" />
        </routeExit>
        <additionalRelation ref="rtr01"/>
</route>
…
<overlap id="ov01" overlapValidityTime="PT60S" overlapSpeed="0.0">
        <designator register="_SimpleRegister" entry="Overlap 69A-P2"/>
        <activeForApproachRoute ref="rt_sig02_sig04"/>
        <requiresSwitchInPosition mustOrShould="should" proving="oneOff">
                <relatedSwitchAndPosition inPosition="left">
                        <refersToSwitch ref="pt_swi02" />
                </relatedSwitchAndPosition>
        </requiresSwitchInPosition>
        <hasTvdSection ref="B03T"/>
        <hasTvdSection ref="B69W03T"/>
        <isLimitedBy ref="tde07"/>
        <overlapRelease id="ov01_rl">
                <designator register="_SimpleRegister" entry="ov01 Release"/>
                <releaseTriggerSection ref="X02T"/>
                <overlapReleaseTimer timerValue="PT60S" overlapReleaseCondition="startTimerUponOccupation" />
        </overlapRelease>
</overlap>
…
<dangerPoint id="dp01" distance="300.0" releaseSpeed="0.0">
        <designator register="_SimpleRegister" entry="DPe69P2"/>
        <lastSupervisedSectionBeforeDP ref="B69W03T"/>
        <situatedAtTrackAsset ref="B01T"/>
</dangerPoint>

Additional Information

Flank protection must be represented by <routeRelation> [1].

Notes

Open Issues

References

  1. ↑ Flank protection railML® forum post (link to the railML® website)
Retrieved from "https://wiki3.railml.org/index.php?title=IL:route&oldid=9397"