Forum: railML.infrastructure » [railML3.3] Signal combinations

Home » railML newsgroups » railML.infrastructure » [railML3.3] Signal combinations

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

[railML3.3] Signal combinations [message #3112]

Sun, 20 August 2023 13:44

Jörg von Lingen
Messages: 126
Registered: March 2016

Senior 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&

Attachment: signal_combinations.png
(Size: 109.49KB, Downloaded 291 times)

Dr. Jörg von Lingen – Interlocking schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3.3] Signal combinations [message #3114 is a reply to message #3112]

Wed, 23 August 2023 06:20

Jörg von Lingen
Messages: 126
Registered: March 2016

Senior 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

Attachment: signal_combinations01.jpg
(Size: 165.11KB, Downloaded 312 times)
Attachment: signal_combinations02.jpg
(Size: 155.32KB, Downloaded 325 times)

Dr. Jörg von Lingen – Interlocking schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

[railML3] Re: Signal combinations [message #3142 is a reply to message #3114]

Mon, 16 October 2023 17:29

Michael Gruschwitz
Messages: 13
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.

In your first example, shouldn't the signalIS also have a <isSpeedSignal type="announcement/distant"/>?
What other values are available for the indicator types? Currently there only is "cautiousDriving" and "other" available in the standard?
Is the signalIL function always only related to the trainMovement signal aspect of the signalIS?
Will it be possible to specify the speed that an indicator can show? Like in the example shown in Wikipedia or below.
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

Attachment: SignalDifferentSpeedInidcator.png
(Size: 15.53KB, Downloaded 783 times)

[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

Jörg von Lingen
Messages: 126
Registered: March 2016

Senior 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

Attachment: interlocking3_dev.xsd
(Size: 276.78KB, Downloaded 1643 times)

Dr. Jörg von Lingen – Interlocking schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] Re: Signal combinations [message #3163 is a reply to message #3148]

Fri, 10 November 2023 13:19

Jörg von Lingen
Messages: 126
Registered: March 2016

Senior 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

Attachment: signal_combination02a.png
(Size: 102.21KB, Downloaded 244 times)
Attachment: signal_combination02b.png
(Size: 125.49KB, Downloaded 279 times)

Dr. Jörg von Lingen – Interlocking schema coordinator
railML.org (Registry of Associations: VR 5750)
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

Torben Brand
Messages: 225
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

Attachment: Signal combinations.pdf
(Size: 94.87KB, Downloaded 355 times)

Report message to a moderator

Re: [railML3] Re: Signal combinations [message #3207 is a reply to message #3202]

Tue, 12 March 2024 16:22

heidrun.jost@thalesgroup.
Messages: 6
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

Report message to a moderator

Re: [railML3] Re: Signal combinations [message #3223 is a reply to message #3207]

Mon, 08 April 2024 14:55

Larissa Zhuchyi
Messages: 116
Registered: November 2022

Senior 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

Report message to a moderator

Re: [railML3.3] Signal combinations [message #3225 is a reply to message #3112]

Wed, 10 April 2024 17:14

Jörg von Lingen
Messages: 126
Registered: March 2016

Senior 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

Attachment: SignalCombination.pdf
(Size: 48.66KB, Downloaded 361 times)

Dr. Jörg von Lingen – Interlocking schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3.3] Signal combinations [message #3230 is a reply to message #3225]

Tue, 23 April 2024 15:33

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)

Report message to a moderator

Re: [railML3.3] Signal combinations [message #4047 is a reply to message #3230]

Wed, 17 June 2026 10:12

Dominik Looser
Messages: 66
Registered: March 2020

Member

Dear all,

On behalf of Bane NOR, I have a question related to this rather old ticket.
Can we also define the order of the signals (e.g. from top to bottom) that are part of the combination? E.g. in Joerg's example from above [1]
- HS 4253 is the topmost signal
- FS 4253 is the second-topmost signal
- DS 4253 is the bottommost signal

Can we deduct this from the order of appearance in the file? Or is there another way to define it?

Thank you for an answer and best regards,
Dominik Looser, trafIT solutions gmbh

[1] https://www.railml.org/forum/index.php?t=getfile&id=147& amp;

Report message to a moderator

Re: [railML3.3] Signal combinations [message #4103 is a reply to message #4047]

Mon, 17 August 2026 18:17

Thomas Nygreen
Messages: 137
Registered: March 2008

Senior Member

Dear Dominik,

We have previously decided that orders shall be explicitly modelled (e.g. with @sequence), not inferred from the order in the file. Would a numerical @sequence work for your case, or do you need something else?

Best regards,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3.3] Signal combinations [message #4105 is a reply to message #4103]

Tue, 18 August 2026 10:58

Dominik Looser
Messages: 66
Registered: March 2020

Member

Hi Thomas,

Thank you the answer.
Yes, a @sequence attribute would work very well. We would have to define if it's bottom-up or top-down (no clear preference from my side).
Since you write "previously decided", will that be part of railML 3.4? On what element would that attribute be located?

Best regards,
Dominik Looser, trafIT solutions

Report message to a moderator

Re: [railML3.3] Signal combinations [message #4107 is a reply to message #4105]

Tue, 18 August 2026 16:22

Thomas Nygreen
Messages: 137
Registered: March 2008

Senior Member

Dear Dominik,

This decision was made after the 44th railML conference in Rome in November 2023, and applied in the modelling of railML 3.3.[1] If we discover cases relying on implicit ordering, we will introduce sequence numbers to make them explicit. For 3.4 the ETCS working group have recommended to make the previously optional linearLocation/associatedNetElement/@sequence required.[2]

[1] https://development.railml.org/railml/version3/-/work_items/ 520
[2] https://development.railml.org/railml/version3/-/work_items/ 714

Best regards,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3.3] Signal combinations [message #4110 is a reply to message #4107]

Wed, 19 August 2026 08:18

Dominik Looser
Messages: 66
Registered: March 2020

Member

Hi Thomas,

This is an example of how we export a combination of two signals (an ETCS marker board and a shunting signal) in railML 3.3, in accordance with [1].

<signalIS id="sig4_C">
  <spotLocation applicationDirection="normal" id="sig4_C_ips01" netElementRef="ne_3">
	<linearCoordinate lateralSide="right" measure="143.0" positioningSystemRef="ips01"/>
  </spotLocation>
  <spotLocation applicationDirection="normal" id="sig4_C_sloc01_km" netElementRef="ne_3">
	<linearCoordinate lateralSide="right" measure="143.0" positioningSystemRef="lps01"/>
  </spotLocation>
</signalIS>
<signalIS belongsToParent="sig4_C" id="sig4" isSwitchable="false">
  <name language="no" name="mb"/>
  <spotLocation applicationDirection="normal" id="sig4_ips01" netElementRef="ne_3">
	<linearCoordinate lateralSide="right" measure="143.0" positioningSystemRef="ips01"/>
  </spotLocation>
  <spotLocation applicationDirection="normal" id="sig4_sloc01_km" netElementRef="ne_3">
	<linearCoordinate lateralSide="right" measure="143.0" positioningSystemRef="lps01"/>
  </spotLocation>
  <typeDesignator entry="E35a" rulebook="TJN"/>
  <elementState value="planned"/>
  <isEtcsSignal/>
  <isTrainMovementSignal/>
</signalIS>
<signalIS belongsToParent="sig4_C" id="sig5" isSwitchable="true">
  <name language="no" name="sh"/>
  <spotLocation applicationDirection="normal" id="sig5_ips01" netElementRef="ne_3">
	<linearCoordinate lateralSide="right" measure="143.0" positioningSystemRef="ips01"/>
  </spotLocation>
  <spotLocation applicationDirection="normal" id="sig5_sloc01_km" netElementRef="ne_3">
	<linearCoordinate lateralSide="right" measure="143.0" positioningSystemRef="lps01"/>
  </spotLocation>
  <typeDesignator entry="skift" rulebook="_ETCS"/>
  <elementState value="planned"/>
  <isEtcsSignal/>
  <isTrainMovementSignal/>
</signalIS>

Having a @sequence on <linearLocation>, or having one on <spotLocation>, is not very helpful, since all signals of a combination have the same <spotLocation>.
I think we need something like @sequenceInCombination or @mountingOrder, which could be an attribute of <signalIS> or <signalIS>/<signalConstruction>

Best regards,
Dominik Looser, trafIT solutions gmbh

[1] https://www.railml.org/forum/index.php?t=getfile&id=147& amp;

Report message to a moderator

Re: [railML3.3] Signal combinations [message #4190 is a reply to message #4110]

Tue, 15 September 2026 15:18

Thomas Nygreen
Messages: 137
Registered: March 2008

Senior Member

Dear Dominik,

Apologies for the delay! I think we misunderstood each other slightly. When I wrote that "We have previously decided that orders shall be explicitly modelled (e.g. with @sequence), not inferred from the order in the file", this was a general railML-wide decision, as described by issue 520. I just stuck my head in to inform everyone of this general rule. When you wrote "will that be part of railML 3.4? On what element would that attribute be located?" I responded with an example, but it was not related to this thread's topic.

Specifying the order of signals in a combination (without knowing each signal's @verticalDistance) has *not* previously been identified as a need. This is Christian's domain, but it seems to me that a simple order attribute would solve it, like you suggest.

Best regards,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3.3] Signal combinations [message #4200 is a reply to message #4190]

Mon, 21 September 2026 10:55

christian.rahmig
Messages: 592
Registered: January 2016

Senior Member

Dear Thomas and Dominik,

thank you for your valuable input summarizing the requirement.

As a conclusion I suggest to introduce a new optional integer attribute @mountingOrder in element //signalIS/signalConstruction. Default value is "0", which corresponds to the highest position on the mast. Further values "1" and "2" would then indicate a lower position on the mast.

Dear community, what do you think about this proposal? Any kind of feedback is very much appreciated.

Best regards
Christian

Christian Rahmig – Infrastructure schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3.3] Signal combinations [message #4203 is a reply to message #4200]

Tue, 22 September 2026 09:20

Dominik Looser
Messages: 66
Registered: March 2020

Member

Hi Christian,

Thank you for the suggestion. This would work very well for our use-case.

Best regards,
Dominik Looser, trafIT solutions gmbh

Report message to a moderator

Previous Topic:	How do you model operational points inside operational points in mesoscopic topology?
Next Topic:	[railML3] @lateralSide and @verticalSide and distances

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

PDF

]

Current Time: Fri Oct 16 16:27:52 GMT+2 2026