| [IL] Signal Aspects [message #172] |
Wed, 23 November 2005 16:02 |
Gregor Theeg
Messages: 3
Registered: September 2005
|
Junior Member |
|
|
Dear railML partners,
here I want to send an approach for defining signal aspects in railML. I
analyzed the various European Signal systems and tried to find a
structure which can be used for all systems. Of course, not all
specialities are defined yet, but I hope it will be possible to define
everything which is necessary by extending the schema.
I suggest to make another wiki for discussing the signal aspects. Maybe
also my syntax in xml can be improved by somebody who can deal better
with the xml-spy than me.
Where to place the signals? My idea is to place them in:
railML --> infrastructure --> lines --> line --> tracks --> track -->
track elements --> signals --> signal --> signalAspects
About the structure of signalAspects: First you can distinguish between
- train aspects (regular operation)
- shunting aspects
- auxilary aspects (Ersatzsignal, Hilfssignal, Befehlssignal or
whichever name you want to give them).
The train aspects are a bit difficult to describe because there are many
different aspects in the world.
The most common solution is to give a speed for the section beginning at
the signal ("main") and a speed announcement for the section beginning
next signal ("distant1"), independent from wheather the signals are main
or distant signals.
Some railways also use signal aspects giving information over three
sections, like the "Preliminary warning" which means that the second
next signal shows "Stop" and the distance from the next to the second
next is not enough to brake. This is done in Switzerland (yellow light
with a "V" below), France (yellow flashing), Britain (double yellow) and
Belgium (green above yellow), for example.
To make the file shorter, it is possible to write several "main" and
"distant1" into one signal aspect (which should better be called aspect
group" in this case. An example:
<sectionAspect>
<main>Proceed</main>
<main>60</main>
<distant>Proceed</distant>
<distant>40</distant>
</sectionAspect>
would mean that each main aspect can be combined with each distant
aspect. Following aspects can be shown:
- "Proceed and expect Proceed"
- "Proceed and expect 40"
- "60 expect Proceed"
- "60 expect 40"
The "60 and expect Proceed" does not always make sence, therefore some
signal systems don't announce the "Proceed" in this case. That could be
distinguished by the attribute "increase" (Yes/No).
The attribute "speedTo" is to define until where the speed restriction
is valid (next signal / last point / etc).
Of course, "Stop" is not the same as "Stop". The most important Stop
aspects are the Absolute Stop and the Permissive Stop (Stop and Proceed
on sight; used at block signals).
"Proceed" permits the maximum speed which is allowed on this line using
lineside signals.
"Continue" means that driver is allowed to continue at the speed he has
seen at the signal in rear. This would be used for distant signals which
give no information about the section beginning at the signal, but only
for the next. But also in some signal systems (France, Belgium, Denmark)
a reduced speed is not repeated at the exit signal of a station. The
driver has to remember the speed seen at the entry signal and obey this,
even if the exit signal shows just green. Such a signal would be able to
give the "main" information "Continue" and "StopAbsolute", in some cases
(France) also "StopPermissive" if the route is set but occupied by
another train.
It would be too easy if all signal systems in the world would follow the
principle "this section --> next section". Some railways also have a
signal aspect which means: "When passing the signal, start braking until
you have reached a certain speed, then keep this speed." This we have in
the Netherlands and in Portugal, for example. This certain speed can
also be a Permissive Stop, like at the "Disque" signal in France.
By how, the route principle which exists in Britain, Spain and others
where the driver is informed about the route the train is going to take
and then has to conclude the speed, has not been defined. This should be
added later if required.
Well, I'm waiting for the discussion.
Regards
--
Dipl.-Ing. Gregor Theeg
wissenschaftlicher Mitarbeiter
Professur für Verkehrssicherungstechnik
der TU Dresden
Tel.: +49 (351) 463 36542
Fax: +49 (351) 463 36644
http://vsite.tu-dresden.de
|
|
|
|
Members
Search
Help
Login
Home
