Signals vs panels [message #330] |
Wed, 04 July 2012 19:34 |
pierre.simon
Messages: 8 Registered: July 2012
|
Junior Member |
|
|
There should be a discussion about the semantics of « signals » and
âpanelsâ / switchable or fixed aspects / distinction by an attribute
value or by by element names.
A future <panels> may hold all types of panels, e.g. speedPanels. Those
panels should get a trackside attribute (information important because
they are physically installed on the track).
- <LevelCrossingPanels>
- <catenarySectioningPanels>
- <currentPanels>
- <pantographPanels>
- <fixedSignalingChangePanels>
- <linePanels>
- <gsmPanels>
- <radioPanels>
New type of element should be added in the standard to describe the panels
from the infrastrucure of the railway.
[de: Wie koennen variable Signale und fixe Signaltafel in railML
unterschieden werden? Eine Liste moeglicher Signaltafeln wurde oben
vorgeschlagen. ]
--
----== posted via PHP Headliner ==----
|
|
|
|
Re: Signals vs panels [message #349 is a reply to message #345] |
Thu, 06 September 2012 10:25 |
Carsten Weber
Messages: 27 Registered: November 2011
|
Junior Member |
|
|
"Christian Rahmig" <coord(at)infrastructurerailmlorg> schrieb im Newsbeitrag
news:k1spas$1ro$1(at)sifaivifhgde...
> Hello Pierre,
>
>> There should be a discussion about the semantics of « signals » and
>> “panels” / switchable or fixed aspects / distinction by an attribute
>> value or by by element names.
>> A future <panels> may hold all types of panels, e.g. speedPanels. Those
>> panels should get a trackside attribute (information important because
>> they are physically installed on the track).
>> - <LevelCrossingPanels>
>> - <catenarySectioningPanels>
>> - <currentPanels>
>> - <pantographPanels>
>> - <fixedSignalingChangePanels>
>> - <linePanels>
>> - <gsmPanels>
>> - <radioPanels>
>>
>>
>> New type of element should be added in the standard to describe the
>> panels
>> from the infrastrucure of the railway.
>>
>> [de: Wie koennen variable Signale und fixe Signaltafel in railML
>> unterschieden werden? Eine Liste moeglicher Signaltafeln wurde oben
>> vorgeschlagen. ]
>
> yes, you are right. Currently, the panel elements are not modelled within
> the railML infrastructure schema. However, their functionality often
> relates to signals and therefore, panels should be added to the
> <ocsElements> container. Since several types of panels exist, I suggest to
> distinguish between them by using sub-elements. The syntax would be:
>
> <ocsElements>
> <panels>
> <speedPanels>
> <speedPanel id="pan1" />
> ...
> </speedPanels>
> </panels>
> </ocsElements>
>
> These may be panel types we may define:
> - <speedPanels>
> - <etcsPanels>
> - <levelCrossingPanels>
> - <gsmPanels>
> - <catenaryPanels>
> - <signalingSystemChangePanels>
>
> <catenaryPanels> may include the <currentPanels> and <pantographPanels>
> that you suggested, or what is your reason for distuingish between these
> types? Plese specify the content and the usage of <linePanels>.
>
> Because, <panels> will be an optional element within the <ocsElements>
> container, we may implement it with the upcoming railML 2.2. Therefore it
> is important to hear and read the other users' opinions on this topic and
> eventually extend this first approach. Any comments appreciated...
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.
Another thing is kept in the grouping of signal aspects. This might only be
useful if anybody defines it for RailML(R). Anything else might be a wild
mixture of positioning signal aspects into different groups as seen from the
software creator and not from a railway scope.
Best regards.
Carsten
|
|
|
|
|
Re: Signals vs panels [message #355 is a reply to message #354] |
Tue, 11 September 2012 12:25 |
Susanne Wunsch railML
Messages: 0 Registered: January 2020
|
|
|
|
Hello Carsten and Christian and all others,
"Carsten Weber" <weber(at)irfpde> writes:
> "Christian Rahmig" <coord(at)infrastructurerailmlorg> schrieb im Newsbeitrag
> news:k2f9fo$agl$1(at)sifaivifhgde...
>>> 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.
>> 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.
I like the idea to aggregate panels and signals. There are lots of
aspects that are sometimes shown with fixed panels and sometimes with
light signals but each time have the same influence on operation.
For offering special attributes in the appropriate context we should
group the signals into functional categories like catenarySignals,
speedSignals, levelCrossingSignals, radioSignals... Pierre Simon already
gave a starting point for this approach, I mean.
For light signal aspects we need an attribute like "switchable" - I
agree.
[interlocking related signal attributes snipped]
> 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).
One approach is the construction based. Another would be from the
GIS-related world: Define the signals by its types and function-based
attributes without saying how they look like and how they are joined on
the same pole (mast?). Then define the construction (assembling?) like
pole, hight, distance from track and refer the signals there. This is
just a thought and I would be interested in the pros and cons of both
approaches and totally different approaches.
I currently don't like to go to deep into the functionality of
interlocking related signals but to think more about a general approach
for defining special signals and panels as asked by Pierre Simon.
Any comments, questions, ideas appreciated...
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
Re: Signals vs panels [message #407 is a reply to message #355] |
Sat, 27 October 2012 10:20 |
Christian Rahmig
Messages: 151 Registered: January 2011
|
Senior Member |
|
|
Dear Susanne and other railML friends,
> [interlocking related signal attributes snipped]
>
>> 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).
>
> One approach is the construction based. Another would be from the
> GIS-related world: Define the signals by its types and function-based
> attributes without saying how they look like and how they are joined on
> the same pole (mast?). Then define the construction (assembling?) like
> pole, hight, distance from track and refer the signals there. This is
> just a thought and I would be interested in the pros and cons of both
> approaches and totally different approaches.
considering the discussion in this and related forum threads, I think
that the GIS-related solution of separating the signals' physical
assembling and their operational functionality is the best way of
implementation. Although this approach sounds like railML 3.0, I want to
give an idea of that separation regarding some of the discussed parameters:
[signal construction]
- position along the track
- coodinates
- type of assembling (pole, bridge...)
- height
[operational signal]
- reference to signal construction
- signalling system
- name of the signal (e.g. A12)
- signal frames (main, additional...) containing several signal
information elements
- signal information:
- switcheable vs. panel
- the shown signal aspect (e.g. speed=40)
- valid for train movements (train, shunting...)
- reference to infrastructure element (e.g. level crossing)
The original post opening this thread asked for a more detailed
definition of various types of signals, whereas the word "type" refers
to the operational view of a signal. As already mentioned by Carsten, it
is sometimes difficult to exactly define a signal type on a macroscopic
scale. At the level of "signal information" it should always be possible.
So, to summarize the problem: we either want to exactly distinguish
between different types of signals, which somehow require to define
operational signals, or we allow for interpretations of the
(macroscopic) signal types in combination with the current signal
implementation? What's your opinion, Susanne, Carsten, Pierre?
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|