Home » railML newsgroups » railML.infrastructure » [railML3.3] Signal combinations
Re: [railML3] Re: Signal combinations [message #3202 is a reply to message #3163] Fri, 08 March 2024 09:57 Go to previous messageGo to previous message
Torben Brand is currently offline  Torben Brand
Messages: 161
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

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [railML 3] railway signal modeling
Next Topic: [railML3] electrification is IS, RS and CO
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Jul 27 20:38:48 CEST 2024