| Re: SpeedChange : Protection system reference [message #433 is a reply to message #428] |
Sat, 10 November 2012 14:51   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Christian,
> But I am not sure about the 1:1 relation from the facility to the
> <speedChange>. Considering a signal, it may show different signal
> aspects, which relate to different <speedChange> elements then. If we
> want to implement the cross-reference at least on the same level, this
> would require to reference all (relevant) signal aspects from the
> <speedChange> and not the signals.
Of course there may be 1:n relations from a <trackElement> to a
<speedChange>. But this is mainly because of several speed profiles
overlaying each other but rarely because of speed aspects of a signal.
There is normally a 1:1 relation only from one <trackElement> to one
<speedChange> of one speed profile.
Main signals are not intended to create speed changes. Speed changes shall
define the maximum permitted speed considered as "basic infrastructure
property" - so the plainly physically permitted speed.
Main signals are intended to subset underlying speed profiles, so to
(reduce) the permitted speed of the speed profiles. So, the actual
permitted speed is the minimum of the speed of the profile and the main
signals (minimum of last speed change and last main signal where
appropriate).
The reasons why speed profiles and speed aspects of main signals are
handled independently in practice are:
1) The origins for speed profiles are considered to be "pure physical
infrastructure". The origins of speed aspects of main signals are
considered to be "additional interlocking matters" - security of
trains/vehicles against each other, routes through stations a. s. o.
2) A speed aspect of a main signal in general creates _two_ speed
changes: The beginning and the end of the speed reduction of the main
signal. So, one would have to assign two speed changes to each speed
aspect, which makes it a "1:n:2" relation. With a 1:n relation, one
wouldn't know which beginning belongs to which end. Here we are in the
interlocking scheme again, where we should leave it to be.
3) The positions of the theoretical speed changes of speed aspects cannot
be (always) determined in advance. They depend on the situation. Normally,
the beginning is fixed (but not necessarily at the signal as in Germany),
but the position of the end is very complicated. It may depend on the
route, the timetable, the train length and more. So, one wouldn't be able
to refer speed changes in the current RailML semantics.
For RailML, please consider:
Speed profiles already have their "reasons" packed in the speed profile
attributes. These speed aspects of main signals should have their
"reasons" packed in interlocking structures. The interlocking reasons are
either contrary or redundant to the reasons of the speed profile. In both
cases there is no need to reference the speed change from the signal. (If
contrary: Signal reduces the speed. If redundant: Signal corresponds to
the speed change but we already know that from the speed profile reasons.)
So, please do not provide more redundancy as necessary. To create
references from main signals to speed changes (for the rare cases that
they correspond) redundant at least to the interlocking background and
possibly also to the speed profile attributes.
If you plan to do so anyway, I would recommend to do it in a base type for
all <trackElements> with a kind of enumeration (1:n). Main signals then
inherit this enumeration from the base type - if they need it or not.
Hope I was able to clarify some background.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
