| Re: [railml3] Signal types and functions [message #2154 is a reply to message #2146] |
Thu, 21 February 2019 06:13   |
Jörg von Lingen
Messages: 87
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
|
|
|
|
Members
Search
Help
Login
Home
