[railML 3] railway signal modeling [message #3063] |
Fri, 24 March 2023 13:49 |
Larissa Zhuchyi
Messages: 49 Registered: November 2022
|
Member |
|
|
Dear all,
The discussion on the modelling of railway signals began in February 2019 [1]. With this post, we continue with the example of a "distant light signal with switchable speed announcement". Let's decompose this complex description point by point and try to represent it with railML 3.2 schema elements. Note that one of the purposes here is to use ONLY infrastructure schema.
This signal has four aspects to be represented by railML 3.2 which railML.org suggests doing in the following way:
• "light signal" ‒ <is:signal> @isSwitchable = 1, <signalConstruction> @type = light
• "distant" ‒ <isAnnouncementSignal>
• "with speed announcement" ‒ isSpeedSignal @type = announcement
• "switchable speed" ‒ and this is some discussion questions.
There are two options to handle a "switchable speed" aspect: add a @isSwitchable attribute to <isSpeedSignal> element or use a @belongsToParent attribute of a signal.
We would be grateful if you could communicate your ideas on the questions (1-5) so that we can clarify the principles of railway signal modelling using railML 3.2 or define the needed extensions to incorporate in railML 3.3.
(1) How should be the "switchable" aspect of a "speed" represented in railML 3.2?
(2) Is there a need to add the @isSwitchable attribute for <isSpeedSignal> child element in railML 3.3 to represent its switchable aspect?
(3) Should be the switchable aspect of a speed represented by a child signal?
(4) Is there any other way to represent a switchable aspect of a speed for a signal using only infrastructure elements of railML 3.2?
(5) As distant signal ONLY announces the aspect of a main or combined signal, but never commands stop to a train [2] (here I refer to railML 2 wiki as currently railML 3 wiki misses some of the definitions), should <isTrainMovementSignal> child element be used?
Next, I would like to extend a little bit on the @belongsToParent attribute. The problem is that the semantics of the @belongsToParent attribute is quite ambiguous. Currently, it is suggested that the @isSwitchable attribute of a child signal overwrites the @isSwitchable attribute of a parent, not adding any further info. This produces the following problem. In principle, it should be possible to mix any kind of signals with each other. In case the milepost has a switchable aspect of a speed (in the child element), this makes the milepost to be switchable. But milepost is meant to have zero value of @isSwitchable attribute.
[1] https://www.railml.org/forum/index.php?t=msg&th=648
[2] https://wiki2.railml.org/wiki/IS:signal
Next, I will present a source code for the second option.
<signalIS id="sig01" isSwitchable="true"> <!-- because sig01 is a LIGHT signal -->
<name .../>
<spotLocation ...>
...
</spotLocation>
<isTrainMovementSignal/> <!-- should be discussed -->
<isAnnouncementSignal/> <!-- because sig01 is a DISTANT signal -->
<signalConstruction type="light"/> <!-- because sig01 is LIGHT signal -->
</signalIS>
<signalIS id="sig02" isSwitchable="true"> <!-- because sig01 has SWITCHABLE speed announcement -->
<name .../>
<isSpeedSignal type="announcement"/> <!-- because sig01 has speed ANNOUNCEMENT -->
<belongsToParent="sig01"/> <!-- because sig01 and sig02 physically "the same" -->
</signalIS>
This post was inferred from the discussion with the timetable coordinator (Mr Wölke) and former railML.org intern (Mr Hlubuček).
Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Thu, 13 April 2023 16:26] Report message to a moderator
|
|
|
Re: railML 3.2 railway signal modeling [message #3066 is a reply to message #3063] |
Wed, 29 March 2023 02:07 |
Thomas Nygreen
Messages: 79 Registered: March 2008
|
Member |
|
|
Лариса Жучий wrote on Fri, 24 March 2023 13:49With this post, we continue with the example of a "distant light signal with switchable speed announcement".
Just to make sure that we are not interpreting this differently: This is a regular distant signal that communicates the current aspect of a following main signal. Additionally, it displays a speed, and this speed is switchable. Does the speed depend on the signalling aspect, so that each aspect has a matching speed? (A Norwegian example would be that the deflecting speed of the switches is shown, and can vary depending on route, through the use of a switchable display.)
Quote:Note that one of the purposes here is to use ONLY infrastructure schema.
If you are only using the infrastructure schema, you should not expect to be able to include information that is modelled in the interlocking schema. If you do want to include that, you have to use interlocking elements.
Quote:• "distant" ‒ <isAnnouncementSignal>
No, an announcement signal tells the train driver to blow the train's horn, as per your [1]. The property of being a distant signal has been placed in interlocking (signalIL@function="distant").
Quote:• "with speed announcement" ‒ isSpeedSignal @type = announcement
Note that type="announcement" here means that the given speed is valid from a point further down the track (e.g. at the main signal). If the speed would be valid from the speed signal, it would be type="execution".
Before going into each question, I find this an obvious case for splitting the signal into parts, and grouping them together with @belongsToParent.
Quote:(1) So how should be the switchable aspect of a speed represented in railML 3.2?
The fact that something is a switchable speed signal is conveyed by the combination of signal@isSwitchable and signal/isSpeedSignal. The aspects it can switch between belong in interlocking.
Quote:(2) Is there a need to add the @isSwitchable attribute for <isSpeedSignal> child element in railML 3.3 to represent its switchable aspect?
There is the second option here, namely the usage of the <belongsToParent> element. There is no need for an additional @isSwitchable attribute for <isSpeedSignal> as the @isSwitchable attribute is present in the child signal.
You answered this one yourself: there is no need.
Quote:Here the problem is that the semantics of the @belongsToParent attribute is quite ambiguous. Currently, it is suggested that the @isSwitchable attribute of a child signal overwrites the @isSwitchable attribute of a parent, not adding any further info. This produces the following problem. In principle, it should be possible to mix any kind of signals with each other. In case the milepost has a switchable aspect of a speed (in the child element), this makes the milepost to be switchable. But milepost is meant to have zero value of @isSwitchable attribute.
If you are referring to the semantic constraint on ocp@parentOcpRef introduced in railML 2, which should translate well to @belongsToParent, I understand the rule to just mean that the inheritance is broken when an attribute or child element is present both in the individual part and its referenced parent. It does not push properties back up to the parent. So, going along with a <signal id="sig1"><isMilepost/></signal> and a <signal id="sig2" belongsToParent="sig1" isSwitchable="true"><isSpeedSignal/></signal>, the milepost would still have its isSwitchable property unset.
Quote:(3) So should be the switchable aspect of a speed represented by a child signal? In case yes, this implies that the implicit semantics of @belongsToParent should be changed in railML 3.3.
Yes, if you want to clearly define that you have a combination of a switchable light signal and a switchable speed signal, you should model it with two signals, where one belongs to the other. I do not see that we need to change the semantics of @belongsToParent for that.
Quote:(4) Is there any other way to represent a switchable aspect of a speed for a signal using only infrastructure elements of railML 3.2?
See (1) and (3)
Quote:(5) As distant signal ONLY announces the aspect of a main or combined signal, but never commands stop to a train [2], should <isTrainMovementSignal> child element be used?
The distant signal still conveys information about the legal movement of the train. A closed distant signal communicates that the train must be able to stop before the main signal, possibly requiring the train driver to reduce the speed before seeing the main signal. Where train protection systems are in place, a coupled balise may force the train to slow down.
<signalIS id="sig01" isSwitchable="true"> <!-- because the light is SWITCHABLE -->
<name .../>
<spotLocation ...>
...
</spotLocation>
<isTrainMovementSignal/>
<signalConstruction type="light"/> <!-- because sig01 is LIGHT signal -->
</signalIS>
<signalIS id="sig02" isSwitchable="true"> <!-- because sig01 has SWITCHABLE speed announcement -->
<name .../>
<isSpeedSignal type="announcement"/> <!-- because sig01 has speed ANNOUNCEMENT -->
<belongsToParent="sig01"/> <!-- because sig01 and sig02 are physically connected -->
</signalIS>
<signalIL id="sigil01" function="distant"> <!-- because sig01 is a DISTANT signal -->
<refersTo ref="sig01"/>
</signalIL>
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: railML 3.2 railway signal modeling [message #3070 is a reply to message #3066] |
Wed, 05 April 2023 17:57 |
Milan Wölke
Messages: 153 Registered: April 2007
|
Senior Member |
|
|
Hello Thomas,
If I understood you correctly, you're saying that railML 3 doesn't allow for a clear distinction between a main signal and a distant signal, and that it's intended to be that way. I disagree with this viewpoint. The infrastructure schema should accurately describe the railway infrastructure, without including the logic of interlocking. Since a main signal and a distant signal are visibly different, their physical differences should be modeled in the infrastructure schema. The meaning of these differences can then be described in the interlocking schema. Do you agree with this approach of separating infrastructure and interlocking schemas?
Best regards,
Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: railML 3.2 railway signal modeling [message #3072 is a reply to message #3070] |
Tue, 11 April 2023 17:25 |
Thomas Nygreen
Messages: 79 Registered: March 2008
|
Member |
|
|
Dear Milan,
Yes, the current situation is that the only property designed to describe that a signal is a distant signal is signalIL@function. The same is the case for shunting signals. I refer to the forum thread from 2019 [1] already referenced by Larissa and myself. We should probably schedule this topic on the agenda of our next Technical Coordination Telco.
[1] https://www.railml.org/forum/index.php?t=msg&th=648
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: [railML 3] railway signal modeling [message #3098 is a reply to message #3063] |
Wed, 14 June 2023 18:18 |
Larissa Zhuchyi
Messages: 49 Registered: November 2022
|
Member |
|
|
Given the above clarification of Mr Nygreen (common coordinator of railML.org) and follow-up discussions of all the coordinators please provide your thoughts (agree, disagree, detailed answer) on these points.
The aim is to solve the distinction of the physical and the functional aspects of a signal. Functional aspects should go to the interlocking schema (see IL forum post [1]), while physical ones ‒ to the infrastructure.
Possible changes will be implemented in railML 3.3. Missing documentation will be added to railML 3.2 (railML 3.3 inherits).
Documentation for the schema.
(1) isAnnouncementSignal means that a train should announce itself (usually with a whistle, bell, or train horn) to warn about the train coming to e.g., level crossing. It does not mean that the signal announces the aspect of a following (main) signal.
Clarification for the wiki.
(2) /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/@isSwitchable does not automatically mean light signal. Please use /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/signalConstruction/@type= "light" to represent light signals.
This is due to the fact that light signals can be non-switchable [2]. Also, semaphores can be switchable as well.
Changes of schema to implement in railML 3.3.
(3) @bell, @horn and @whistle flags should be added to /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isAnnouncementSignal.
(4) /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isLevelCrossingSignal/@bell @whistle should be removed because covered by isAnnouncementSignal.
(5) @isShunting, @isRepeater flags should be added to /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isTrainMovementSignal.
(6) @type attribute with "main", "distant" enumeration should be added to /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isTrainMovementSignal.
(7) /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isLevelCrossingSignal/@announcing should be deprecated because covered by isTrainMovementSignal of @type="distant".
Please provide your thoughts (agree, disagree, detailed answer) on these points.
[1] https://www.railml.org/forum/index.php?t=msg&goto=3097&a mp;#msg_3097
[2] https://www.railml.org/forum/index.php?t=msg&th=648& goto=2144&#msg_2144
Sincerely, Larissa Zhuchyi
Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Wed, 14 June 2023 18:25] Report message to a moderator
|
|
|
Re: [railML 3] railway signal modeling [message #3124 is a reply to message #3098] |
Mon, 04 September 2023 10:40 |
christian.rahmig
Messages: 474 Registered: January 2016
|
Senior Member |
|
|
Dear all,
please let me remind you to provide us your feedback (agree / disagree / more detailed answer) on the approach of signal model clarification as described by Larissa.
Thank you very much and best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
Definition suggestion for isTrainMovementSignal and its suggested attributes [message #3201 is a reply to message #3194] |
Wed, 06 March 2024 09:33 |
Torben Brand
Messages: 169 Registered: March 2016
|
Senior Member |
|
|
As suggested in the previous post the SCTP working group should make definition proposals for the suggested IsTrainMovementSignal attributes. In SCTP meeting 1.3.2024 I was asked to publish a proposal here as a basis for discussion.
My proposals are.
1. Change definition of <IsTrainMovementSignal> element. This as the current definition is over defined and we need a system independent definition of isTrainMovementSignal.
Current definition is (only published the last few weeks on wiki):
IsTrainMovementSignal: "signal for transmitting a command from traffic control to the train driver by optical means for stopping or proceeding, e.g. main signal, distant signal, signal repeater, shunting signal"
This is over defined:
"from traffic control" is defined through signalIL@isWired (defined as is Central Controlled)
"by optical means" is defined through signalConstruction@type=light
So we suggest a new definition:
IsTrainMovementSignal: "signal for a command to the train driver for stopping or proceeding (a movement authority)"
For definition of @type we suggest to either use existing definitions for railML2 signal@type [1] or use these suggestions:
• main: signal with highest safety level for train movement authority
• distant: this signal indicates the aspect of an upcoming movement signal but gives no movement authority on it own.
• repeater: this signal repeats the aspect of a movement signal/the movement authority.
• shunting: signal for degraded safety level for train movement (secondary to "main", but with more flexible operations)
[1] https://wiki2.railml.org/wiki/IS:signal
[Updated on: Fri, 22 March 2024 12:28] Report message to a moderator
|
|
|
|
|
|
|
|
suggestion for new sub element <isLevelTransitionSignal> [message #3226 is a reply to message #3194] |
Fri, 19 April 2024 09:41 |
Torben Brand
Messages: 169 Registered: March 2016
|
Senior Member |
|
|
In my previous post (23.2.2024) I did an analysis of all signals in the Norwegian signal rule book [1]. All signals are grouped with the existing sub elements under signalIS [2], except the level transition signals. The level transition signals are signal system independent (ETCS, optical, semaphore etc.) and would be relevant for all nations. Examples would be:
- going from ETCS level 2 to conventional signalling (37A, 37B) [6]
- going from a depot to the supervised line (104A,104B) [3]
- work areas (105A-D) [4]
- ATC start/end signals (60F, 60G, 60H) [5]
Thus, I suggest to add the sub element <isLevelTransitionSignal> in railML3.3 under <signalIS>.
The definition could be "signal that defines the point at where the traffic rules change".
We could add an attribute to define the type, but the grouping through the element would be sufficient for our purpose. The individual types of level transition signals would then be defined through the use of <typeDesignator>.
[1] https://orv.banenor.no/orv/doku.php?id=tjn:Kapittel_8
[2] https://wiki3.railml.org/wiki/IS:signalIS
[3] https://orv.banenor.no/orv/doku.php?id=tjn:Kapittel_8#signal er_for_driftsbanegard
[4] https://orv.banenor.no/orv/doku.php?id=tjn:Kapittel_8#signal er_for_arbeid
[5] https://orv.banenor.no/orv/doku.php?id=tjn:Kapittel_8#skilt_ for_atc
[6] https://orv.banenor.no/orv/doku.php?id=tjn:Kapittel_8#signal _for_systemovergang_til_og_fra_niva_2
|
|
|
Re: suggestion for new sub element <isLevelTransitionSignal> [message #3337 is a reply to message #3226] |
Mon, 14 October 2024 12:08 |
christian.rahmig
Messages: 474 Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
your request for having a "level transition signal" resulted in a modelling proposal for signal subtype \\isLevelTransitionSignal that has been added in the "signal ticket" #533 [7]. This signal can refer to a \\etcsLevelTransition with optional attribute @etcsLevelTransitionRef. Please review the implementation in railML 3.3 beta 2 coming later today...
[7] https://development.railml.org/railml/version3/-/issues/533
Thank you very much and best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|