Home » railML newsgroups » railML.infrastructure » basic idea of the signal/panel enhancement
basic idea of the signal/panel enhancement [message #406] Wed, 24 October 2012 20:39
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
This is about some current discussions on RailML infrastructure - Signals
vs panels, Speed Panels: types and reference to <speedChange>, and
especially on Christians newly created trac ticket [1].

Dear Christian and dear all,

> I created a trac ticket [1], which summarizes the basic idea of the
> signal/panel enhancement.

there are some very interesting aspects in that suggestion which will help
clarifying and generalisation.

I think it is a good approach not generally to distinguish between
"switchable" and "non-switchable" signals. I agree we should follow this
approach.

> A signal aspect may refer to a certain functionality. It is proposed to
> group these funcionalities into speed, etcs, levelCrossing, gsm,
> catenary and signalingSystem and to refer to these groups using the
> parameter type.

These "functionality groups" might have to be discussed. They seam to me a
little bit arbitrary and not very general. While "speed" and
"levelCrossing" seam to be basic railway elements, "etcs" and "gsm" can
probably be more generalised. Also, we have to be aware that in some cases
the "grouping" of the function may not be generally agreed. So, a speed
change signal (panel) near a level crossing may fall into the groups
"speed" and "levelCrossing" as well, and the grouping points of view may
depend on the usage of the RailML files...

So we probably should be "flexible" (diplomatic?) in such cases.

There are two general points of view on infrastructure: The "building" and
the "functional" view (meaning "orientating on what is built outside" and
"orientating on how a railway functions").

The <signal> element and the grouping of its functionalities should not
force the usage too much in one of the both views - especially not into
the more obvious "building" view. There are some easily deductible
consequences of this thesis:

- A <signal> may possibly be "virtual".

- A <signal> may have more than one "functionality" and even more
"functionalities" than obvious ("touchable") signs on it.

- The functions of some complex railway elements such as level crossings,
stations, train protection are possibly too complex to be assigned or
described as a sub-structure of a <signal>. For these functions, we should
consequently create own structures (as <speedProfiles> structure or even
the "Interlocking" scheme) and make cross-references between the <signals>
and the function describing structures. So please be careful not to create
too complex sub-structures for the "functionality" of <signals> which
should better (or may be later) be extracted into an own structure.

- It should be possible to define "functional links" - cross references -
between <signals> and other infrastructure elements and vice versa.

Christian already showed an example by mentioning a signal referring a
speed change. Also, most <signals> of "execution" aspect should refer to
one or more other <signals> or infrastructure elements which do the
appropriate pre-signalisation ("announcement" aspect). A main signal
(semaphore or colour light signal) refers to all other signals which may
act as distant signals to it, an "execute speed reduction" panel refers to
all responsible "speed reduction announcement" panels a. s. o.

With best regards,
Dirk.
Previous Topic: Identical signal representation [de:Gruppenausfahrsignal]
Next Topic: Signals vs panels
Goto Forum:
  


Current Time: Fri Mar 29 16:40:19 CET 2024