| Re: SpeedChange : Protection system reference [message #416 is a reply to message #409] |
Thu, 01 November 2012 15:47   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Christian and others,
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>>> 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]
> 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".
A "speed change" is anyway _no_ "physical infrastructure object".
There are some objections pro and con your reversed reference direction.
It depends on the current task of handling the data.
* Referring all from the <speedChange> helps in all cases, where the
speed change itself changes. Then you find all needed train
protection elements and signals to change them the same way.
* Referring from the trainProtectionElement and from the signal to the
<speedChange> helps in all situations where you meet such a facility
on a track and need to know which speed aspect is valid there.
I see no problem in a too complex speed change element because this
models the real world in a good way. A speed change requires all these
dependencies.
How would you describe it in a semantic model? I think we would add both
relations: from the speedChange to the facilities (1:n) and back (1:1).
Why not to define both references like already done with the
<connection> elements? That can be easily assured by special
constraints. Both sights meet their requirements.
Any comments welcome...
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
