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
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 54
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 #2134 is a reply to message #2131] Sat, 09 February 2019 09:32 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 12
Registered: March 2016
Junior Member
Dear all,

we (IS/IL coordinators) have discussed the differences of <signalIS>@type and <signalIL>@signalFunction (may be renamed
to <signalIL>@function):

<signalIS>@type is about the physical types of objects one will call "signal"

<signalIL>@signalFunction is about the function of the signal as seen from the interlocking
"main" could be seen as a duplication but its meaning is more anything else but the specific uses - "The main signal is
a normal signal for train traffic protection which is neither used as block, entry, exit nor intermediate signal."

<signalIL>@isVirtual is especially considering ETCS systems were the interlocking in its data still has signals which
are switched to particular aspects. But on the outside there are only marker boards to identify the position of these
interlocking only signals. In that sense they are physical outside but virtual for the interlocking.
Whereas <signalIS>/<signalConstruction>@type="virtual" really means no physical object outside.

<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.


Regards,
Jörg von Lingen - Interlocking Coordinator
Re: [railml3] Signal types and functions [message #2138 is a reply to message #2131] Mon, 11 February 2019 15:51 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 205
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
Re: [railml3] Signal types and functions [message #2141 is a reply to message #2134] Mon, 11 February 2019 17:24 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 54
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
Non-switchable semaphore signals (was: Re: [railml3] Signal types and functions) [message #2144 is a reply to message #2141] Mon, 11 February 2019 21:07 Go to previous messageGo to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 16
Registered: June 2017
Junior Member
Dear Thomas!

Am 11.02.2019 um 19:24 schrieb Thomas Nygreen:> 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?
These types are not seldom in many railways all over the world as
operating rules may define that the end of a train's route shall be a
signal at any time. If usually the trains will not continue at all or
under normal operating conditions after the end of the trains route a
switchable signal makes no sense.

One example from Hungary: At all of the buffer stops of Budapest dead
end stations (e.g. Nyugati pályaudvar; West station) you will find a non
switchable light signal that will show only a red light to finalise the
route for the incoming train. See
https://media-cdn.tripadvisor.com/media/photo-s/01/42/28/f0/ west-station.jpg
for example, I think the same rule applies in a lot of other countries /
railways.

One example from Germany: The "Rurtalbahn" in Northwest beginning in
Düren (on the line between Cologne and Aachen) and ends in Heimbach with
an non switchable main signal to protect the switch/point and the
passenger level crossing at the end of the platform.
- Signal from the front, the line ends after 200 metres where the DMU is
stapled:
http://www.bahnbilder.de/1024/bahnhof-heimbach-gleisseite-am -streckenend-397150.jpg
- Signal from the back, there are no wires or cables to switch the
semaphore:
https://www.eisenbahn-stolberg.de/wp-content/uploads/2018/07 /Heimbach-Eifel-796.690-Regiosprinter-am-30.06.2018_Foto_Ste fan_Danners_F.jpg

Also in Germany such non-switchable main signals will be used often to
protect the danger points at the entry of stations if trains are
approaching from the track in the opposite driving direction (mainly:
left). To pass these signals the trains will get a written train order
via train radio from the dispatcher.

Hope this helps.
--
Best regards,

Tobias Bregulla
Bahnkonzept Dresden/Germany
Re: [railml3] Signal types and functions [message #2145 is a reply to message #2138] Tue, 12 February 2019 14:34 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 54
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
Previous Topic: Platform @belongsToParent and <ownsPlatformEdge>
Goto Forum:
  


Current Time: Sat Feb 16 15:05:44 CET 2019