| Re: SpeedChange : Protection system reference [message #452 is a reply to message #433] |
Tue, 13 November 2012 11:25   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Dirk, Christian, and others,
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>> 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.
Thanks, Dirk, for focussing the discussion by clarifying some background.
We don't try to find a solution for signals/panels in this thread. It is
more about a reference from speed changes to its "securing" train
protection elements never mind if there are speed panels or signals at
all. That may be ensured with magnets, crocodiles...
The remark by Carsten is of some importance, maybe we should create an
intermediate container element that will be referred to for enabling
grouping of train protection elements.
My proposal (speedChange -> trainProtectionElement, 1:n):
* Multiple references from 'speedChange' to certain "train protection
group"s (regarding several "GPA"s at distinct positions along the
announcement and execution way)
* New element 'trainProtectionGroup' with multiple, at minimum one,
'trainProtectionRef' element(s) for referring to single
trainProtectionElements.
Alternatively (trainProtectionElement -> speedChange, 1:n):
* New element 'trainProtectionGroup' with multiple, at minimum one,
'trainProtectionRef' element(s) for referring to single
trainProtectionElements.
* Multiple references from 'trainProtectionGroup' to certain
'speedChange's (regarding different speed profiles)
The first approach sounds more straight forward for me.
I hope to also clarified the focus of the RFE.
I filed a Trac ticket for this issue:
http://trac.assembla.com/railML/ticket/199
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
