Home » railML newsgroups » railML.infrastructure » [railML3.3] Signal combinations
[railML3.3] Signal combinations [message #3112] Sun, 20 August 2023 13:44 Go to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 87
Registered: March 2016
Member
Dear all,

especially with UC Scematic track plan the question arose how to model signals with different functions. For most infrastructure managers these signals are represented on the plan with different symbols depending on the parts installed on that pole. Here I suggest to make use of the functional information placed in the interlocking subschema.
With the latest extensions in the schema there can be several <signalIL> and <signalIndicator> referring to the same physical <signalIS>. From these relation the signal function (in interlocking domain), the possible aspects and the number of installed lamps [1] can be retrieved.
As illustration I have attached a sketch showing the reletions for a German Ks-signal as example. A signal with a main, distant and shunting signal on the same pole can be moddelled in similar way.

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] Proposal for signal lamps https://www.railml.org/forum/index.php?t=msg&th=786& start=0&
Re: [railML3.3] Signal combinations [message #3114 is a reply to message #3112] Wed, 23 August 2023 06:20 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 87
Registered: March 2016
Member
Short correction: in first picture the closing tag shall be "</signalIL>"

Here now a corrected picture plus an additional one for combination of main, distant and shunting signal on the same pole.

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
[railML3] Re: Signal combinations [message #3142 is a reply to message #3114] Mon, 16 October 2023 17:29 Go to previous messageGo to next message
Michael Gruschwitz is currently offline  Michael Gruschwitz
Messages: 12
Registered: May 2020
Junior Member
Dear all,

in general that solution looks intriguing. It will allow us to encode a lot more detail into the signals than before. Looking through your proposal, however, we came up with a couple of question, we were hoping you could answer.
  1. In your first example, shouldn't the signalIS also have a <isSpeedSignal type="announcement/distant"/>?
  2. What other values are available for the indicator types? Currently there only is "cautiousDriving" and "other" available in the standard?
  3. Is the signalIL function always only related to the trainMovement signal aspect of the signalIS?
  4. Will it be possible to specify the speed that an indicator can show? Like in the example shown in Wikipedia or below.
    /forum/index.php?t=getfile&id=137&private=0
  5. Is there a preview XSD available, so that we can look into it a little more detailed?
Thanks in advance for the clarification and thank you for your work.

With regards,
--
Michael Gruschwitz
Bahnkonzept Dresden/Germany

Am 23.08.2023 um 06:20 schrieb Jörg von Lingen:
> Short correction: in first picture the closing tag shall be
> "</signalIL>"
>
> Here now a corrected picture plus an additional one for
> combination of main, distant and shunting signal on the same
> pole.
>
> 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

[Updated on: Mon, 16 October 2023 17:40] by Moderator

Report message to a moderator

Re: [railML3] Re: Signal combinations [message #3148 is a reply to message #3142] Sun, 22 October 2023 07:21 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 Michael,

to answer your questions:
1) A SpeedSignal is a signal which just shows the defined speed for the section ahead. They are in most cases fixed boards. However, in case of a TrainMovementSignal with a speed indicator this does not apply as the speed indicator is a supplementary signal aspect. The speed aspect is only shown together with a signal aspect for train movement.
2) The list of possible indicators was extended for cautiousDriving, directionIndicator, distantDirectionIndicator, distantJunctionIndicator, distantShortBrakingDistance, distantSpeedIndicator, junctionIndicator, shortBrakingDistance, speedIndicator, wrongTrackDriving.
3) The signalIL function is related to the aspects used by the interlocking.
4) Yes, it shall be possible to specify the aspects the indicator can show. This will be done similar as for the normal aspects of any signal.
5) A preview version of the interlocking XSD is attached.

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
Re: [railML3] Re: Signal combinations [message #3163 is a reply to message #3148] Fri, 10 November 2023 13:19 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,

in my presentation in Rome I unfortunately couldn't go into much details of the signal combinations. There are two items which needs your opinion. Basically it is possible in infrastructure to define several SignalIS which are then grouped together using the @belongsToParent attribute. When looking into the examples I did attach to my post of 23. August they show two situations:

1) signal_combinations01 shows a signal with additional indicators. Here I suggest to have only one SignalIS element representing the signal itself which is then referred to from interlocking part. Thus the SignalIndicators would not have an individual counterpart SignalIS.

2) signal_combinations02 shows three signals at one mast. Thus they could be defined as three different SignalIS grouped then together to one parent-SignalIS. In this situation the three SignalIL elements might refer to the parent-SignalIS as shown in the picture (signal_combination02a.png) or the might refer to each individual SignalIS (signal_combination02b.png). I suggest to do the latter one.

Please tell us your preferred way to model such signals.

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

[Updated on: Fri, 10 November 2023 13:56]

Report message to a moderator

Re: [railML3] Re: Signal combinations [message #3202 is a reply to message #3163] Fri, 08 March 2024 09:57 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 158
Registered: March 2016
Senior Member
Both suggested models for signal combinations (with use of signalIL and signal IS) has its limitations and/or would need extensions. As a solution I suggest a third option, that is in line with the latest modelling decisions [2],[1] (also see attached illustration):

Options (1 and 2 as described in previous post):
1. As suggested in Jörg's example in Rome (also option 1 in previous post by Jörg)
Signals are combined through reference from separate signalIL signals to signalIS<isMovemetSignal> for the complete combination of signals. Missing <typeDesignator> in signalIL to declare the individual signals.

2. Use of todays model with combinations for minimum change. (also option 2 in previous post by Jörg)
As option 3, but with empty <isMovementSignal> element and use signalIL@function to define the movement signal type with existing value interpretation.

3. Modelling principle where all physical aspects are in signalIS and all interlocking in signalIL.
Make new @type attributes in <isMovemetSignal>. This is already an ongoing task. [1] Then the individual signals of the signals combination can be defined in signalIS and the combination made with the attribute signalIS@belongsToParent

Pro/con analysis:
I would recommend solution 3.

1. This would break with the principle that physical characteristics are in signalIS and also have the <typeDesignator> for signals at two different locations in the schema. Also "repeater" and "distant" are both signalIL@function values. So for a combination og repeater and distant (de:"Vorsignalwiederholer") you would need to deprecate the "repater" value and add new attribute @isRepeater. So I would not recommend this solution
2. Same arguments as for solution A) except the need to make new <typeDesignator>. So I would not recommend this solution
3. Is in line with the decision [1] and [2] to have the physical aspects in signalIS and the additional interlocking attributes in signalIL and minimize new extensions (beyond those already agreed in <isMovementSignal>)

[1] https://www.railml.org/forum/index.php?t=msg&th=899& goto=3201&#msg_3201
[2] https://www.railml.org/forum/index.php?t=msg&th=649& goto=3200&#msg_3200
Re: [railML3] Re: Signal combinations [message #3207 is a reply to message #3202] Tue, 12 March 2024 16:22 Go to previous messageGo to next message
heidrun.jost@thalesgroup. is currently offline  heidrun.jost@thalesgroup.
Messages: 5
Registered: December 2022
Junior Member
Dear all,

in ERTMS there are marker boards in role for main and shunting signals.
Both signals are on the same mast.
For both signals we have only one SCI-CC Id defined.

Therefore I would propose to have only one signalIS which supports multiple roles (e.g. main and shunting).

Best regards,
Heidrun
Re: [railML3] Re: Signal combinations [message #3223 is a reply to message #3207] Mon, 08 April 2024 14:55 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 31
Registered: November 2022
Member
Dear all

There are now two issues / tickets in the GitLab repository on the changes of the railway signal model of railML3 IS and IL subschemas [1, 2]. Please let us know if they do not meet your requirements.

See also related forum posts [3, 4].

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

[3] https://www.railml.org/forum/index.php?t=msg&th=899& start=0&
[4] https://www.railml.org/forum/index.php?t=rview&goto=3216 &th=786#msg_3216

Sincerely,


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3.3] Signal combinations [message #3225 is a reply to message #3112] Wed, 10 April 2024 17:14 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,

the modelling of several signals at one position (one pole) shall be as in the attached graphic.
In interlocking there is one SignalIL element for each different signal referring to an individual counterpart in infrastructure.
In infrastructure there is one SignalIS element for each different signal type. Each is referring with "belongsToParent" to a SIgnalIS element as the container for all signals at this point. The container carries the information of the mechanical construction and the position which is common for all the signals at this mount point.

As explained in https://development.railml.org/railml/version3/-/issues/533 the basic signal type is included in isTrainMovementSignal element. Whereas the interlocking function is defined in SignalIL.

There is the proposal to add attribute "withShuntingFunction" as boolean in SignalIL. This shall be used as a marker that this signal (IS type=main, IL function=entry|exit|intermediate|group|junction) can be start or end of a shunting route, i.e. shows a shunting aspect. This is especially useful for ETCS markerboards for main and shunting routes as we decided to deprecate the function "main+shunting" in SignalIL.
--
Best regards,
Joerg v. Lingen - Interlocking Coordinator
Re: [railML3.3] Signal combinations [message #3230 is a reply to message #3225] Tue, 23 April 2024 15:33 Go to previous message
Francesca Iannaccone is currently offline  Francesca Iannaccone
Messages: 3
Registered: October 2023
Junior Member
Dear all,

I think that the proposed solution should work and cover all the different requirements.

Kind regards,
Francesca Iannaccone (NEAT)
Previous Topic: [raillML3] Mounting information of signals
Next Topic: [railML3] Restricting IS:line and RTM:linearPositioningSystem
Goto Forum:
  


Current Time: Sun Apr 28 07:56:04 CEST 2024