Re: SpeedChange : Protection system reference [message #409 is a reply to message #402] |
Sat, 27 October 2012 11:42 |
Christian Rahmig
Messages: 151 Registered: January 2011
|
Senior Member |
|
|
Dear Susanne and other railML users,
>> I added the request for an (optional) reference from a <signal> to a
>> <trainProtectionElement> as a comment to trac ticket [1].
>>
>> [1] https://trac.assembla.com/railML/ticket/173
>
> That's only one part of the idea.
>
> There are also speed changes that are ensured by train protection
> elements, such as PZB-magnets. [1]
>
> Sure, not all speed changes have such restrictions, it should be an
> optional addition to the current <speedChange> element.
>
> Moreover there should be more than one such a reference to different
> <trainProtectionElement>s. The Germans use up to three magnets for one
> speed aspect. [1]
>
> [1] https://de.wikipedia.org/wiki/Geschwindigkeitspr%C3%BCfabsch nitt
How about turning the direction of reference resulting in the following
scenario: The basis is provided by the <speedChange>. This speed change
is an oriented point on the track. Signals (including panels) refer to
the speed change and the same is done by train protection elements like
magnets. And of course, several magnets as well as several signals can
refer to the same speed change.
The disadvantage of this approach is the fact, that "child elements"
refer to "parent elements" and it's difficult to collect all
dependancies of a speed change.
If we want to avoid this turning of the reference direction, we will end
up with the request for a more complex modellation of a <speedChange>.
First, a speed change needs to refer to signals, announcing, executing
or reminding the connected speed information. And second, a speed change
needs to refer to train protection elements assuring the speed
restriction. Plus the already implemented reference from a <speedChange>
to a <speedProfile>, the speed change becomes more an "operational
element" instead of a "physical infrastructure object".
Any comments on this idea?
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|