Home » railML newsgroups » railML.infrastructure » [railML 3] railway signal modeling (Need to discuss a way to represent railway signal aspects using railML 3.2)
[railML 3] railway signal modeling [message #3063] Fri, 24 March 2023 13:49 Go to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 37
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 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 68
Registered: March 2008
Member
Лариса Жучий wrote on Fri, 24 March 2023 13:49
With 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 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 141
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 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 68
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 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 37
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 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 437
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
Re: [railML 3] railway signal modeling [message #3164 is a reply to message #3124] Fri, 10 November 2023 13:35 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 87
Registered: March 2016
Member
Dear all,

I have suggested a solution how to model a signal with speed indicators in picture [1] in forum post [2]. In addition a more detailed proposal is included in the presentation "Improved Signal Modelling" as held recently in Rome.

Dr.-Ing. Jörg von Lingen - Interlocking scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 351 87759 40; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org

[1] https://www.railml.org/forum/index.php?t=getfile&id=119& amp;
[2] https://www.railml.org/forum/index.php?t=msg&th=916& goto=3114&#msg_3114
Re: [railML 3] railway signal modeling [message #3194 is a reply to message #3098] Fri, 23 February 2024 09:59 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 158
Registered: March 2016
Senior Member
Jernbanedirektoratet and Bane NOR has the need to specify the most important group of physical signal types in railML3. This is solved and in use today in railML2 (with the signal@type values).
Our list of the "most important" signal types are covered by the existing railML3 model with the suggested extension (5) and (6) in Larissas post 14.6.2023 here. Most important is the addition of the attribute value isTrainMovementSignal@type="main".

Is there a ticket created for this? We do however have three improvement suggestions:

I. We do not see any suggestion for a definition of the proposed signal type values (main, shunting, distant, repeater) in the forum post. I suggest using the existing ones in signalIL@function and adapt to a physical representation. I propose that a draft could be produced in the SCTP working group and be published for approval in this forum post.

II. Is it necessary to have @isShunting as a separate attribute? For instance @isShunting="true" in combination with type="main" (or "distant") does not seem logical. Would it not be better to have "shunting" as part of the isTrainMovementSignal@type enumeration?

III. Is the separation of ETCS signals in signalIS<isEtcsSignal> and optical signals in signalIS<isTrainMovementSignal> the right way to go?
The most important group of ETCS signal types listed in Norway's signal book [1] are (mapped to signalIS):
- Markerboards (are movement/"main" signals)
- Level crossing (existing sub-element: <isLevelCrossingSignal>)
- Level transition (missing sub-element? Should be extended also for optical systems? We also have for instance ATC level transition boards)
- Danger (avalanche and frostgate; existing sub-element: <isDangerSignal>)
- Speed signals (existing sub-element: <isSpeedSignal>)

To map those, we need to either:

A. Keep the separation and add isEtcsSignal@type="main" and "levelCrossing". In addition the sub elements <isLevelCrossingSignal>, <isDangerSignal> and <isSpeedSignal> must be duplicated under <isEtcsSignal>.

B. Change the definition of signalIS<isTrainMovementSignal> to be system independent. Then, if using both <isEtcsSignal> and <isTrainmovementSignal>@type="main" this will indicate a markerboard. Only using <isTrainmovementSignal>@type="main" will indicate a signal for transmitting a command from traffic control to the train driver by optical means for stopping or proceeding.

C. A combination of the two above? For instance, have a flagg isEtcsSignal@isMarkerBoard (aka "main") and use the other sub-elements in addition to defining an empty <isEtcsSignal> without the flagg?

[1] https://orv.banenor.no/orv/doku.php?id=tjn:Kapittel_8#vi_sae rlige_skilt_pa_strekning_med_ertms


Definition suggestion for isTrainMovementSignal and its suggested attributes [message #3201 is a reply to message #3194] Wed, 06 March 2024 09:33 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 158
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

Re: Definition suggestion for isMovementSignal and its suggested attributes [message #3205 is a reply to message #3201] Tue, 12 March 2024 08:57 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 87
Registered: March 2016
Member
Dear Torben,

I have two clarifications
> "from traffic control" is defined through signalIL@isWired
> (defined as is Central Controlled)
signalIL@isWired is just related electrical wiring.
"from traffic control" means really the command is initiated from a
(central) traffic controller.

> "by optical means" is defined through signalConstruction@type=light
"by optical means" is not necessarily a light signal. It can also be a
marker board (although it does not contain the explicite command
content). It shall be anything the driver can see outside at the track.


Dr.-Ing. Jörg von Lingen - Interlocking scheme coordinator
railML.org (Registry of Associations: VR 5750)
Re: Definition suggestion for isMovementSignal and its suggested attributes [message #3215 is a reply to message #3205] Fri, 22 March 2024 12:26 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 158
Registered: March 2016
Senior Member
Dear Jörg,

Thank you for this clarification!
As I see it this does not contradict the new more clear suggested definition for <isTrainMovementSignal>:
"signal for a command to the train driver for stopping or proceeding (a movement authority)"
Re: [railML 3] railway signal modeling [message #3217 is a reply to message #3164] Fri, 22 March 2024 13:19 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 37
Registered: November 2022
Member
Dear all

There is now a ticket / issue based on the suggestion of the IL coordinator [1]. Please let us know if it does not meet your expectations.

[1] https://development.railml.org/railml/version3/-/issues/345

Sincerely,


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Definition suggestion for isMovementSignal and its suggested attributes [message #3218 is a reply to message #3215] Fri, 22 March 2024 13:33 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 158
Registered: March 2016
Senior Member
Todays SCTP working group decided to go forward with the isTrainMovementSignal@type's as described above (main, distant, repater, shunting).
The last question now before modelling is how these types are combined in national systems.
For this purpose we are doing a mapping of a combination matrix of the 4 proposed types.
The matix is in the SCTP working group folder in the railML.org cloud:
https://cloud.railml.org/f/185215

A clarification: The type is for a physical individual signal, that is expected to have its own asset object id, and NOT a signal combinations on the same pole (like for instance: main+distant+shunting).

We ask all members of the railML community for feedback, but especially members of the SCTP and ETCS working groups.
Feedback by the end of April is apprechiated.
If you do not have access to the file please reach out to railML.org.
Re: Definition suggestion for isTrainMovementSignal and its suggested attributes [message #3219 is a reply to message #3201] Fri, 22 March 2024 13:36 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 37
Registered: November 2022
Member
Dear all

There is now a ticket / issue based on the suggestion of Mr Brand from Jernbanedirektoratet. Please let us know if it does not meet your expectations.

[1] https://development.railml.org/railml/version3/-/issues/533

Sincerely,


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
suggestion for new sub element <isLevelTransitionSignal> [message #3226 is a reply to message #3194] Fri, 19 April 2024 09:41 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 158
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

Previous Topic: Export linear location information for switch tip/left/right branch and crossings
Next Topic: [railML3.3] Signal combinations
Goto Forum:
  


Current Time: Thu May 30 00:20:56 CEST 2024