Home » railML newsgroups » railML.infrastructure » [railml3] Signal types and functions
[railml3] Signal types and functions [message #2131] |
Fri, 08 February 2019 20:38 ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Thomas Nygreen JBD
Messages: 68 Registered: February 2017
|
Member |
|
|
Dear all,
Note that this post also concerns IL.
In railML3.1rc2 <signalIS>@type values overlapping with <signalIL>@signalFunction have been removed. While I agree that the enumeration lists for these (and other parallel properties in IS and IL) should not overlap, I think that the issue runs deeper in this case.
The remaining values for <signalIS>@type are
- "foulingPoint": a fouling point that marks the begin of an intersection of different tracks' loading gauges
- "departure": A signal indicating that a passenger train is ready to leave the station.
- "snowplow": a snowplow signal
- "stop": In general, this sign marks a position on a track, where a train needs to stop. In most cases it indicates the position where a passenger train should stop at a platform (stopPost). On branch lines with simplified operational rules, this signal may also be used to mark a position where a train has to stop to wait for a permission to proceed. Made redundant by <isStopPost>.
- "levelCrossing": a level crossing signal Made redundant by <isLevelCrossingSignal>.
- "electricity": A sign/board for electric locomotives indicating when and where the pantograph or other collector needs to be lowered. Made redundant by <isCatenarySignal>.
- "radio": A sign/board providing instructions on train radio usage.
- "speed": a speed sign/board Made redundant by <isSpeedSignal>.
The remaining values for <signalIS>@type seem quite arbitrary and oddly specific while still missing information necessary for a meaningful interpretation. My best suggestion is to replace the attribute with a structured variant of the 2.x @ruleCode (<designator>?), and create further isXXX where necessary.
The values for <signalIL>@signalFunction (which should be shortened to @function to avoid repeating the element name, or renamed to @type) are:
- "main"
- "repeater"
- "distant"
- "shunting"
- "barrage"
- "block"
- "junction"
- "exit"
- "intermediateStop"
- "intermediate"
- "entry"
This list mixes two separate sets of values, as one signal can be for instance a main exit signal. While "main", "repeater", "distant" and "shunting" are hierarchical types of signals, "block", "exit", "intermediate" and "entry" describe the role or function of a (main) signal (in a route). (I am not familiar with the three remaining values.) The first set of values should be assigned to a separate attribute. Since these are normally physically different signal types, maybe they also belong in IS?
Furthermore, <signalIS>@virtual was moved to a new enumeration value in <signalIS>/<signalConstruction>@type (with values "virtual", "semaphore" and "light"), but there is also still a <signalIL>@isVirtual attribute. So one of these is probably still redundant.
Additionally, <signalIS>@switchable is also related to <signalConstruction>@type as it is "set TRUE if the signal is able to show several signal aspects, set FALSE if the signal is a static panel that always shows the same signal aspect" (my emphasis). To me it seems even more logical to include "board" than "virtual" in the list, and consequently remove @switchable.
Lastly, according to the annotation on <signalIL>@isVirtual "boards that are not wired to the interlocking can be labelled virtual." As virtual means "not physically existing", an actual board is not virtual. If the attribute is supposed to specify if the signal is wired to the interlocking or not the attribute should be renamed. Alternatively a new attribute can be added, or the information can be determined from the properties of the referenced <signalIS>.
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
|
Re: [railml3] Signal types and functions [message #2138 is a reply to message #2131] |
Mon, 11 February 2019 15:51 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
christian.rahmig
Messages: 458 Registered: January 2016
|
Senior Member |
|
|
Dear Thomas,
dear all,
Am 08.02.2019 um 20:38 schrieb Thomas Nygreen:
> [...] The remaining values for <signalIS>@type are
> "foulingPoint": a fouling point that marks the begin of an
> intersection of different tracks' loading gauges"departure":
> A signal indicating that a passenger train is ready to leave
> the station."snowplow": a snowplow signal"stop": In general,
> this sign marks a position on a track, where a train needs
> to stop. In most cases it indicates the position where a
> passenger train should stop at a platform (stopPost). On
> branch lines with simplified operational rules, this signal
> may also be used to mark a position where a train has to
> stop to wait for a permission to proceed. Made redundant by
> <isStopPost>."levelCrossing": a level crossing signal Made
> redundant by <isLevelCrossingSignal>."electricity": A
> sign/board for electric locomotives indicating when and
> where the pantograph or other collector needs to be lowered.
> Made redundant by <isCatenarySignal>."radio": A sign/board
> providing instructions on train radio usage."speed": a speed
> sign/board Made redundant by <isSpeedSignal>.
You are right, there is some kind of redundancy. The idea was to provide
the information on two levels:
- high level (only one word): using attribute <signalIS>@type
- detailed level: using child element <signalIS><is*Signal>
Depending on the requirements resulting from the use case, the
information about the signal shall be modelled either in one way or the
other.
> The remaining values for <signalIS>@type seem quite
> arbitrary and oddly specific while still missing information
> necessary for a meaningful interpretation. My best
> suggestion is to replace the attribute with a structured
> variant of the 2.x @ruleCode (<designator>?), and create
> further isXXX where necessary.
Yes, <signalIS>@type is far away from being complete. But the list can
be extended due to the "otherEnumerationValue" extension. Apart from
this, a @ruleCode may be a good solution that can be integrated into the
<designator> element.
> [...] Furthermore, <signalIS>@virtual was moved to a new
> enumeration value in <signalIS>/<signalConstruction>@type
> (with values "virtual", "semaphore" and "light"), but there
> is also still a <signalIL>@isVirtual attribute. So one of
> these is probably still redundant.
As Jörg already wrote: we used two different definition of "virtual".
Therefore, we decided to remove the IS based "virtual" (a signal is not
physically present outside at the track) and put it into the
<signalConstruction> child element.
> Additionally, <signalIS>@switchable is also related to
> <signalConstruction>@type as it is "set TRUE if the signal
> is able to show several signal aspects, set FALSE if the
> signal is a static panel that always shows the same signal
> aspect" (my emphasis). To me it seems even more logical to
> include "board" than "virtual" in the list, and consequently
> remove @switchable.
"board" can be considered as a new value for
<signalIS><signalConstruction>@type. It will be defined as a
"non-switchable semaphore signal". The enumeration value "semaphore"
would be used for switchable semaphore signals. Are there any examples
for non-switchable virtual signals?
Any feedback is highly appreciated...
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: [railml3] Signal types and functions [message #2141 is a reply to message #2134] |
Mon, 11 February 2019 17:24 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Thomas Nygreen JBD
Messages: 68 Registered: February 2017
|
Member |
|
|
Dear Jörg,
Thank you for your replies, which helped me untangle some of the IS and IL issues from each other. I will therefore reply to the IL issues in the interlocking thread.
Jörg von Lingen wrote on Sat, 09 February 2019 09:32
<signalIS>@type is about the physical types of objects one will call "signal"
I agree, but the remaining <signalIS>@type values describe a small minority of signals. The remaining attribute values in IS are insufficient for describing the majority of signals. The @type values that were removed with RC2 describe signal types that are normally physically different. My first reaction was therefore that it was odd to move this physical description from IS to IL.
There are many possible ways to draw the border between IS and IL, and I am more concerned with the available modelling space as a whole and not with exactly where the border is drawn. Signals are especially tricky, as some of the physical differences we are used to are only there to make it easy to distinguish different functional types of signals. So I am reconsidering my initial reaction.
Still, we need a way to generically describe the physical type of a signal. I suggest that we fully embrace the approach of using subelements for different types of signals, and <signalConstruction>@type to categorise the physical type of signal. Consequently I also suggest to remove <signalIS>@type. The functional role of a signal is specified in IL.
Quote:
<signalIS>@switchable is a real addition to <signalConstruction>@type because there are signals of type "semaphore"
which may be switchable or not, e.g. electrification signals like "main switch off". Of course, with "light" signals one
can assume they are always switchable.
I find it hard to believe that you have semaphore signals where the arms cannot be moved to display different aspects, unless this is just a matter of the signal being out of service (disabled). Do you have a visual example of a non-switchable semaphore signal?
I think the list of types should be extended with (at least) "board", "pole" and "other:*", and maybe also "lamp" and "flag" (which are movable and therefore harder to model). Switch indicators, like semaphores, are mechanical signals, so maybe it is better to replace "semaphore" with "mechanical"? Should we also distinguish between light signals that switch colour, light signals that turn on and off, and other (positional or shaped) light signals?
Looking at railML2.4nor, there are also two attributes that I hope can be included in railML 3.1, with adjustments of the implementation if necessary: @nor:lamps (integer number of [independent] lamps a signal has) and @nor:mounted (enumerated list of possible mounts for a signal, currently "pole", "gantry" and "other:*", could also include "wall", "ground" etc.).
Suggestions:
- Create element <signalIS>/<isFoulingPoint> with reference to corresponding <switchIS> or <crossing>.
- Create element <signalIS>/<isRadioSignal> which also describes what kind of radio signal this is (i.e. what instructions it provides).
- Add optional (and repeatable?) <signalIS>/<ruleCode> (feel free to suggest better name), of type rail3:Designator.
- Add <signalConstruction>@type values "board", "pole", "lamp", "flag" and rail3:tOtherEnumerationValue. Rename "semaphore" to "mechanical".
- Add new optional attribute <signalConstruction>@numberOfLamps describing the number of individual lamps in a light signal (one lamp may consist of several bulbs for redundancy).
- Add new optional attribute <signalConstruction>@mountedOn with enumerated values "pole", "gantry", "wall", "ground" and rail3:tOtherEnumerationValue.
- Remove <signalIS>@type
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
|
Re: [railml3] Signal types and functions [message #2145 is a reply to message #2138] |
Tue, 12 February 2019 14:34 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Thomas Nygreen JBD
Messages: 68 Registered: February 2017
|
Member |
|
|
Dear Christian and Tobias,
christian.rahmig wrote on Mon, 11 February 2019 15:51
The idea was to provide
the information on two levels:
- high level (only one word): using attribute <signalIS>@type
- detailed level: using child element <signalIS><is*Signal>
Depending on the requirements resulting from the use case, the
information about the signal shall be modelled either in one way or the
other.
In my opinion the combined approach leaves the type attribute completely redundant. As posted above I suggest to remove it and only use the child elements. If more detailed information is not available, the element may be empty. Keeping both leaves two separate ways to model the same information, increasing the load on both reading and writing systems.
christian.rahmig wrote on Mon, 11 February 2019 15:51
Yes, <signalIS>@type is far away from being complete. But the list can
be extended due to the "otherEnumerationValue" extension.
Yes it can be extended but those values will not have a coordinated interpretation. Now that the most important values have found other homes, I think the attribute can be removed, as already suggested.
christian.rahmig wrote on Mon, 11 February 2019 15:51
"board" can be considered as a new value for
<signalIS><signalConstruction>@type. It will be defined as a
"non-switchable semaphore signal". The enumeration value "semaphore"
would be used for switchable semaphore signals. Are there any examples
for non-switchable virtual signals?
I do not understand why you consider a board to be a semaphore signal. A semaphore, by definition, conveys its meaning using the positions of its arms. A board is a separate signal type. It has no arms and does not fit the definition of a semaphore. Is this a German generalisation? Also, Tobias shows an example of a non-switchable semaphore (which is not a board).
Even if only one of Tobias' examples is a semaphore, he illustrates well the use of different types of non-switchable and non-board signals. In Norway these would be separate signal types, but I agree that there is a use case for @switchable. This probably also removes the need for a <signalConstruction>@type="lamp" value. However, the documentation has to be amended so that @switchable="false" does not necessarily imply a panel/board.
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
Re: [railml3] Signal types and functions [message #2146 is a reply to message #2145] |
Mon, 18 February 2019 11:26 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Torben Brand
Messages: 162 Registered: March 2016
|
Senior Member |
|
|
I would like to suggest an extension to the signal model in railML3.
It is good that we have the sub element designator with the register + entry attributes. Thus, we can always uniquely define a national signal.
But the generic signal model seems to be very underwhelming. Leaving everything undefined for international interoperability. I would suggest grouping all signal in standard sub elements. These can of course be extended. Based on a quick analysis of the Norwegian signals viewed in a generic manner I would suggest 14 groups of signals. 4 of those are already defined in RC2. I suggest adding the following sub elements (bold are existing). See the following link ( https://forum.railml.org/userfiles/2019-02-18_jbd_signal-mod el-suggestion.pdf) for full value table for the types.
I also suggest adding the @system attribute. Then the signal sub elements and their types are truly generic. They can then be interchangeable for different types of signalling systems (ATC, CTC, ETCS, Conventional/optical). See example for border.
Suggested signal sub elements (groups of signals):
• Announcement: Announcement by the train of its presence. Can be with different signals. Usually blowing the whistle (boolean value). Can be defined for one or multiple purpose (boolean: levelCrossing, halt, etc.)
• Border: Indicating a level transition. Type start/end. The system attribute defines the type of level transition (ATC,CTC, ETCS, Conventional/optical).
• catenary
• danger: grouping all types of warning signals: avalanche, wind, frost gate, bridge, etc.
• gradient: indicating falling/rising gradient and other info.
• Info: general design info. Like arrows, invalid boards, and info panels.
• level crossing
• main: all route related signals
• movement: all signals giving an indication of the movement that are not main or shunting signals (line signals, derailers, switch and crossing indicators)
• plow: orders for handling the equipment on the train. Here the plow.
• Position: mileposts and distance signals (f.i. to level crossings)
• Shunting: shunting related signals
• Speed
• stop post
It would be interesting to see how other nations signal models would map to this. This would bring us closer to a unified solution. My suggestion is only a simple attempt on a unified mapping.
[Updated on: Mon, 18 February 2019 12:32] by Moderator Report message to a moderator
|
|
|
Re: [railml3] Signal types and functions [message #2147 is a reply to message #2146] |
Mon, 18 February 2019 14:36 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
christian.rahmig
Messages: 458 Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
Am 18.02.2019 um 11:26 schrieb Torben Brand:
> [...] I would suggest grouping all signal in
> standard sub elements. These can of course be extended.
Sounds good, let's have a look at the issue in detail and combine it
with a proposal:
> [...]
> Suggested signal sub elements (groups of signals):
> • Announcement: Announcement by the train of its
> presence. Can be with different signals. Usually blowing the
> whistle (boolean value). Can be defined for one or multiple
> purpose (boolean: levelCrossing, halt, etc.)
<isAnnouncementSignal>
@type = {"whistle", "horn", ...}
@refersToElement = {reference to level crossing, halt, etc.}
> • Border: Indicating a level transition. Type start/end.
> The system attribute defines the type of level transition
> (ATC,CTC, ETCS, Conventional/optical).
<isSystemBorderSignal>?
> • catanary
<isCatenarySignal>
.... have it already
> • danger: grouping all types of warning signals:
> avalanche, wind, frost gate, bridge, etc.
<isDangerSignal>
Is a fouling point (clearance post) also a danger signal?
> • gradient: indicating falling/rising gradient and other
> info.
> • Info: general design info. Like arrows, invalid boards,
> and info panels.
summarize both in <isInformationSignal>
> • level crossing
<isLevelCrossingSignal>
.... have it already
> • main: all route related signals
> • movement: all signals giving an indication of the
> movement that are not main or shunting signals (line
> signals, derailers, switch and crossing indicators)
<isTrainMovementSignal>
This includes main signals, distant signals, repeaters...
> • plow: orders for handling the equipment on the train.
> Here the plow.
<isVehicleEquipmentSignal>?
@type = {snowplowUp, snowplowDown, ...}
> • Position: mileposts and distance signals (f.i. to level
> crossings)
<isPositionSignal>
@refersToPositioningSystem
@isMilepost
> • Shunting: shunting related signals
integrate in <isTrainMovementSignal>
Some countries don't distinguish between shunting and train movements.
> • Speed
<isSpeedSignal>
.... have it already
• stop post
<isStopPost>
.... have it already
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: [railml3] Signal types and functions [message #2148 is a reply to message #2145] |
Mon, 18 February 2019 14:55 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
christian.rahmig
Messages: 458 Registered: January 2016
|
Senior Member |
|
|
Dear Thomas,
Am 12.02.2019 um 14:34 schrieb Thomas Nygreen:
> [...]
>
> christian.rahmig wrote on Mon, 11 February 2019 15:51
>> The idea was to provide the information on two levels:
>>
>> - high level (only one word): using attribute
>> <signalIS>@type
>> - detailed level: using child element
>> <signalIS><is*Signal>
>>
>> Depending on the requirements resulting from the use
>> case, the information about the signal shall be modelled either in
>> one way or the other.
>
> In my opinion the combined approach leaves the type
> attribute completely redundant. As posted above I suggest to
> remove it and only use the child elements. If more detailed
> information is not available, the element may be empty.
> Keeping both leaves two separate ways to model the same
> information, increasing the load on both reading and writing
> systems.
You are right. If we allow empty child elements, the attribute @type
won't be necessary. So, are there any other opinions from the community?
> [...]
>
> christian.rahmig wrote on Mon, 11 February 2019 15:51
>> "board" can be considered as a new value for
>> <signalIS><signalConstruction>@type. It will be defined
>> as a "non-switchable semaphore signal". The enumeration value
>> "semaphore" would be used for switchable semaphore signals. Are
>> there any examples for non-switchable virtual signals?
>
>
> I do not understand why you consider a board to be a
> semaphore signal. A semaphore, by definition, conveys its
> meaning using the positions of its arms. A board is a
> separate signal type. It has no arms and does not fit the
> definition of a semaphore. Is this a German generalisation?
> Also, Tobias shows an example of a non-switchable semaphore
> (which is not a board).
My proposal: extend <signalConstruction>@type with value "board".
Together with existing values "light", "semaphore" and "virtual" we
should have a complete picture, haven't we?
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Re: [railml3] Signal types and functions [message #2152 is a reply to message #2147] |
Mon, 18 February 2019 23:26 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Thomas Nygreen JBD
Messages: 68 Registered: February 2017
|
Member |
|
|
christian.rahmig wrote on Mon, 18 February 2019 14:55
> My proposal: extend <signalConstruction>@type with value "board".
> Together with existing values "light", "semaphore" and "virtual" we
> should have a complete picture, haven't we?
I have also suggested "pole" and rail3:tOtherEnumerationValue (and "flag" and "lamp", but ignore them for now).
At least in Norway we have several signal poles (or posts), that do not have a board on them, but instead a colour pattern along the pole/post. So I still suggest to add "pole" (or "post").
I think we can ignore "flag" for now, and consider "lamp" a light signal. They are both used in Norway by local dispatchers, train staff and during maintenance. They can both be handheld, mounted in a support on the platform or in the tracks. But as they are movable, I do not know how to properly model their use. So we will probably have to continue modelling their effect virtually.
But I still strongly suggest to add rail3:tOtherEnumerationValue.
christian.rahmig wrote on Mon, 18 February 2019 14:36
> <isAnnouncementSignal>
> @type = {"whistle", "horn", ...}
> @refersToElement = {reference to level crossing, halt, etc.}
One board can refer to more than one element, so <refersToElement> should be a repeatable child element. One example is the Norwegian signal 67D which refers to both a level crossing and a halt. One level crossing announcement signal (67B) can also refer to multiple level crossings (we have lines with more than two level crossings per kilometre, on average).
> <isDangerSignal>
> Is a fouling point (clearance post) also a danger signal?
In Norway, this is signal 64A (a pole/post). In Torben's table, this signal is listed as a border signal. But this signal can be used for multiple purposes:
- end (i.e. border) of allowed shunting area outside of the outer switch in a station
- border of a stabling or maintenance yard
- clearance point between tracks
- position of track circuit activating level crossing protection
My question is: should this signal use different types depending on the use?
> <isVehicleEquipmentSignal>?
> @type = {snowplowUp, snowplowDown, ...}
Can we separate type of equipment and action? That would make it easier to categorise and to filter on all signals relevant for a given equipment kind.
Torben Brand wrote on Mon, 18 February 2019 11:26
> It is good that we have the sub element designator with
> the register + entry attributes. Thus, we can always uniquely define
> a national signal.
The way that <designator> is used on <ocp> in railML2.x is as an identifier of the element, not of the type. The parallel for a signal is something like <designator register="BaneData" entry="SA-SIG-010898"/>. That is why I suggest a separate child element like <ruleCode> (if we want to keep the name from 2.x), which uses the same structure: <ruleCode register="TJN" entry="67D"/>
I would also like to reiterate my following suggestions:
> * Add new optional attribute <signalConstruction>@numberOfLamps describing the number of individual lamps in a light signal (one lamp may consist of several bulbs for redundancy).
> * Add new optional attribute <signalConstruction>@mountedOn with enumerated values "pole", "gantry", "wall", "ground" and rail3:tOtherEnumerationValue.
Also remember to create child elements for signal types we do not have in Norway. From the current @type list, at least <isRadioSignal> seems relevant.
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
Re: [railml3] Signal types and functions [message #2154 is a reply to message #2146] |
Thu, 21 February 2019 06:13 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) |
Jörg von Lingen
Messages: 89 Registered: March 2016
|
Member |
|
|
Dear Torben,
thanks for your detailed proposal
Torben Brand wrote on 18.02.2019 11:26:
> But the generic signal model seems to be very underwhelming.
> Leaving everything undefined for international
> interoperability. I would suggest grouping all signal in
> standard sub elements. These can of course be extended.
> Based on a quick analysis of the Norwegian signals viewed in
> a generic manner I would suggest 14 groups of signals. 4 of
> those are already defined in RC2. I suggest adding the
> following sub elements (bold are existing). See the
> following link
> (http://cloud.railml.org/index.php/s/4fwsqGFkreMNkeP) for
> full value table for the types.
I have added the interlocking view for some of your signals in https://cloud.railml.org/index.php/s/xMtAoYGcFsZrjF8
Please bear in mind that "combined" in the IL sense is related to the aspect which combines several informations in a
single aspect (but maybe realised with more than one lamp). A entry/exit/../main signal with a distant signal on the
same post is not combined in that sense. The interlocking would see them as two separate signals.
The various signals used to stop a train in front of an unsecure section would be seen as "barrage" signals having only
two possible aspects - stop/clear.
Another case is the "clearance signal"/"Middelkontrollampe" which is always mounted at the main signal post. The
interlocking will use it as a "supplementary" aspect together with the main aspect.
> I also suggest adding the @system attribute. Then the signal
> sub elements and their types are truly generic. They can
> then be interchangeable for different types of signalling
> systems (ATC, CTC, ETCS, Conventional/optical). See example
> for border.
>
> Suggested signal sub elements (groups of signals):
> • Announcement: Announcement by the train of its
> presence. Can be with different signals. Usually blowing the
> whistle (boolean value). Can be defined for one or multiple
> purpose (boolean: levelCrossing, halt, etc.)
> • Border: Indicating a level transition. Type start/end.
> The system attribute defines the type of level transition
> (ATC,CTC, ETCS, Conventional/optical).
> • catanary
> • danger: grouping all types of warning signals:
> avalanche, wind, frost gate, bridge, etc.
> • gradient: indicating falling/rising gradient and other
> info.
> • Info: general design info. Like arrows, invalid boards,
> and info panels.
> • level crossing
> • main: all route related signals
> • movement: all signals giving an indication of the
> movement that are not main or shunting signals (line
> signals, derailers, switch and crossing indicators)
> • plow: orders for handling the equipment on the train.
> Here the plow.
> • Position: mileposts and distance signals (f.i. to level
> crossings)
> • Shunting: shunting related signals
> • Speed
> • stop post
>
> It would be interesting to see how other nations signal
> models would map to this. This would bring us closer to a
> unified solution. My suggestion is only a simple attempt on
> a unified mapping.
Yes, this kind of mapping would be the community input we need.
Regards,
Jörg von Lingen - Interlocking Coordinator
|
|
|
Goto Forum:
Current Time: Sun Sep 01 02:47:28 CEST 2024
|