Home » railML newsgroups » railML.infrastructure » Signals vs panels
Re: Signals vs panels [message #354 is a reply to message #351] Mon, 10 September 2012 16:34 Go to previous messageGo to previous message
Carsten Weber is currently offline  Carsten Weber
Messages: 27
Registered: November 2011
Junior Member
Hello Christian,

"Christian Rahmig" <coord(at)infrastructurerailmlorg> schrieb im Newsbeitrag
news:k2f9fo$agl$1(at)sifaivifhgde...
> Hello Carsten,
>
>> For me it looks better to implement the panels as signals too. So a
>> signal
>> should contain a subelement "signal aspect(s)" within an attribute
>> "switchable" which differes between aspects that are fix (and may be a
>> panel) or aspects which are shown in special situations. This way you can
>> easily change between panels or boards and switchable signal aspects
>> without
>> looking at different positions inside the scheme.
>> So a reading tool only needs to look into signals and it's subelements
>> signalaspects to find informations given to the driver/engine. In your
>> case
>> a reading tool has to look into panels and signals.

> Thank you for sharing your interesting idea of the signal aspects. Let me
> try to put it in a structured syntax for a simple example of a signal with
> a panel:
>
> <signal id="s01" pos="42.0" type="main">
> <signalAspect id="s01a01" switchable="true" type="block">
> </signalAspect>
> <signalAspect id="s01a02" switchable="false" type="speed">
> </signalAspect>
> </signal>
>
> Did I understand you correctly?

Nearly. No it looks the way I would prefer.

An important question resulting from
> this modelling brings us back to the initial point of the discussion: How
> do we model different (functional) types of panels (or signals)? In the
> example above I packed this information inside the type of the signal
> aspect. Any comments appreciated...

I think there should be an extension like:

<signal id="s01" pos="42.0" operationalType="main" visibleAtTrack="yes">
<signalInformation id="s01a010" switchable="true" block="stop"/>
<signalInformation id="s01a011" switchable="true" block="approach"/>
<signalInformation id="s01a012" switchable="true" block="clear"/>
<signalInformation id="s01a020" switchable="true" speed="40"/>
<signalInformation id="s01a021" switchable="true" speed="60"/>
<signalInformation id="s01a022" switchable="true" speed="80"/>
<signalInformation id="s01a023" switchable="true" speed="100"/>
<signalInformation id="s01a030" switchable="true" direction="F"/>
<signalInformation id="s01a031" switchable="true" direction="R"/>
...
</signal>

This makes it easy to handle the informations especially for timetable tools
(which might be the largest group in using RailML). You create a list of
possible aspects which can be given from this signal. And you can create a
reference from the train parts ocp sequence to this signal aspect to define
which speed is calculated for this slot at this signal. Another thing might
be to create the release point of this speed restriction.

In case of a certain signal it could be done like this:

<signal id="s01" pos="42.0" operationalType="main" visibleAtTrack="yes"
name="A12">
<signalInformation id="s01a010" signalAspect="Hl13" switchable="true"
block="stop"/>
<signalInformation id="s01a011" signalAspect="Hl10" switchable="true"
block="approach"/>
<signalInformation id="s01a012" signalAspect="Hl1" switchable="true"
block="clear"/>
<signalInformation id="s01a020" signalAspect="Hl2" switchable="true"
speed="100" block="clear"/>
<signalInformation id="s01a021" signalAspect="Hl3a" switchable="true"
speed="40" block="clear"/>
...
</signal>

Maybe the block attribute should be changed to
numberOfFreeBlocksInRegularBreakingDistance (or a little bit shorter)
because some signal systems give you more information than two block
distances behind the current signal. It might have been in Poland I think.
It might also be shortened as a second approach type e.g. "approach2".

Depending on the details you want to bring into RailML you might need a
third level of modelling signals. It is positioned between signal and
signalInformation and groups the signal informations into a "frame" (or
something like this).
So a signal of KS might be modelled like this:

<signal id="s01" pos="42.0" operationalType="main" visibleAtTrack="yes"
name="A12">
<signalFrames>
<signalFrame name="main">
<signalInformations>
<signalInformation id="s01a010" signalAspect="Hp0"
switchable="true" block="stop" runType="all"/>
<signalInformation id="s01a011" signalAspect="Ks1"
switchable="true" block="approach" runType="train"/>
<signalInformation id="s01a012" signalAspect="Ks2"
switchable="true" block="clear" runType="train"/>
<signalInformation id="s01a013" signalAspect="Zs1"
switchable="true" speed="45" runType="train"/>
<signalInformation id="s01a014" signalAspect="Sh1"
switchable="true" speed="25" runType="shunting"/>
</signalInformations>
</signalFrame>
<signalFrame name="additional">
<signalInformations>
<signalInformation id="s01a010" signalAspect="Zs3"
switchable="false" speed="80"/>
</signlInformations>
</signalFrame>
<signalFrame name="additional">
<signalInformations>
<signalInformation id="s01a010" signalAspect="Zs2"
switchable="false" direction="S"/>
<signalInformations>
</signalFrame>
</signalFrames>
</signal>

I hope it gets clear what would be done with this level inside of the signal
modeling. This opens also the way to create a model of fixing the signals
around the tracks.

Best regards.

Carsten

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: basic idea of the signal/panel enhancement
Next Topic: Alternative Stationsnamen (ocp, additionalName)
Goto Forum:
  

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

Current Time: Tue May 14 13:30:46 CEST 2024