| [railML 3] railway signal modeling [message #3063] |
Fri, 24 March 2023 13:49  |
Larissa Zhuchyi
Messages: 34
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 |
|
|
|
Members
Search
Help
Login
Home
