Home » railML newsgroups » railML.infrastructure » [railML 3] railway signal modeling (Need to discuss a way to represent railway signal aspects using railML 3.2)
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 previous 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
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Export linear location information for switch tip/left/right branch and crossings
Next Topic: [railML3.3] Signal combinations
Goto Forum:
  


Current Time: Sun Jun 16 04:06:06 CEST 2024