Home » railML newsgroups » railml.interlocking » New area types for railML 3.3
New area types for railML 3.3 [message #3190] Wed, 07 February 2024 14:23 Go to previous message
Terje Nordal is currently offline  Terje Nordal
Messages: 9
Registered: December 2023
Junior Member
Dear railML experts,

Referring to previous posts on the forum discussing avalanche and derailment detection ( https://www.railml.org/forum/index.php?t=msg&goto=3006&a mp; amp;#msg_3006) and suggestions of new Emergency Stop Areas (ESA) for railML 3.3 ( https://www.railml.org/forum/index.php?t=rview&goto=3167 &th=927) Bane NOR have had some internal discussions, accompanied by the Norwegian Jernbanedirektoratet, on suggestions for implementation.

We agree to the suggestion of letting ESA use a similar definition to workZone or localOperationArea. We also suggest an additional area type to allow definitions of Danger Areas (IL:dangerArea), to allow definitions of avalanche areas. Both areas need the ability to reference a detector for activation of the area. For the differentiation between conditional and uncontitional ESA we suggest having a isConditional(0..*) (true/false).

For Bane NOR the typical use cases would be:

dangerArea: An area that may be activated by a sensor (typically one or more avalanche detectors), resulting in the trains typically having to run slowly in case of dangerous conditions ahead.
(unconditional)emergencyStopArea (isConditional=false): An area that may be activated either by a dispatcher or by a sensor (typically a derailment indicator), resulting in all trains inside and outside the area having to stop.
(conditional)emergencyStopArea (isConditional=true): An area that may be activated by a sensor (for instance a fire alarm in a tunnel, to avoid trains outside the tunnel entering), resulting in trains already inside the area (and close to entering) being allowed to continue while trains that are able to stop before entering will be stopped.

These three scenarios are pretty similar, but would affect the interlocking (train movements authorities) differently. That is the reasoning for needing the differentiation.

Our suggestion is therefore the following area definitions:
- IL:dangerArea using the following children: assetName (0..*), belongsToOperationalPoint (0..1), designator (0..*), detectorInState (0..*), hasCommand (0..*), hasIndication (0..*), isLimitedBy (0..*), signalWithAspect (0..*), trackAssetInArea (0..*).
- IL:emergencyStopArea using the following children: assetName (0..*), belongsToOperationalPoint (0..1), designator (0..*), detectorInState (0..*), hasCommand (0..*), hasIndication (0..*), isLimitedBy (0..*), isConditional(0..*)1), signalWithAspect (0..*), trackAssetInArea (0..*).

Best regards
Terje Nordal

[Updated on: Wed, 07 February 2024 14:36]

Report message to a moderator

 
Read Message
Read Message
Read Message
Previous Topic: Release triggers for routes in railML 3.2
Next Topic: [railML3]: signal lamps
Goto Forum:
  


Current Time: Sat Jul 13 09:05:46 CEST 2024