Home » railML newsgroups » railML.infrastructure » SpeedChange : Protection system reference
Re: SpeedChange : Protection system reference [message #409 is a reply to message #402] Sat, 27 October 2012 11:42 Go to previous messageGo to previous message
Christian Rahmig is currently offline  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
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Alternative Stationsnamen (ocp, additionalName)
Next Topic: Tools zum Erstellen der Topologie / Tools for creating the topology
Goto Forum:
  


Current Time: Fri May 17 05:59:33 CEST 2024