Home » railML newsgroups » railML.infrastructure » SpeedChange : Protection system reference
| SpeedChange : Protection system reference [message #334] |
Wed, 04 July 2012 20:25  |
pierre.simon
Messages: 8
Registered: July 2012
|
Junior Member |
|
|
In the Belgian railway, the speedChanges could be equipped with a
protection system (crocodile).
We suggest to add a reference from <speedChange> to the <trainProtection>
element.
[de: Es wird ein Attribut benoetigt, welches vom <speedChange> zum
<trainProtectionElement> (BE: 'Krokodil' / DE: Gleismagnet) verweist.]
--
----== posted via PHP Headliner ==----
|
|
|
|
|
|
| Re: SpeedChange : Protection system reference [message #342 is a reply to message #336] |
Thu, 05 July 2012 15:47  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Pierre and Christian,
we should not try to implement all cables or such which are in practice in
the RailML or at least in Infrastructure scheme of RailML. Rather, we
should as ourselves which function such a cross-reference should provide:
If there is a real and general function, we should implement the link. If
there is no objective or general function, we should leave it as a special
local case for adoption in local sub-schemes of RailML.
We should also consider the actual case as a property of RailML
Interlocking Scheme.
In my opinion, the speed change sign and the <trainProtectionElement> have
independent functions. (Of course they have the same origin or reason why
they are there but: If there would be a speed change without
<trainProtectionElement> or vice versa, each one would have to function
alone.)
Both should be implemented as single elements may be with the same
position (meter). A reading software can possibly expect that there should
be a <trainProtectionElement> at or near the position of a <speedChange>
but there is no _general_ (internationally accepted) necessity for that.
But if you decide to make that cross-reference anyway, as an optional
attribute - what objection should one have?
With best regards,
Dirk.
---
Am 05.07.2012, 06:12 Uhr, schrieb Christian Rahmig
<coord(at)infrastructurerailmlorg>:
> Hello Pierre,
>
>> In the Belgian railway, the speedChanges could be equipped with a
>> protection system (crocodile).
>>
>> We suggest to add a reference from <speedChange> to the
>> <trainProtection>
>> element.
>>
>> [de: Es wird ein Attribut benoetigt, welches vom <speedChange> zum
>> <trainProtectionElement> (BE: 'Krokodil' / DE: Gleismagnet) verweist.]
>
> This reference from a <speedChange> to a <trainProtectionElement> is a
> useful innovation, which may be implemented with railML 2.2, because the
> reference attribute will be optional. However, is it really the
> <speedChange> that needs to refer to the <trainProtectionElement> or is
> it the signal, which is connected to the magnet or the Belgian crocodile?
>
> Any comments appreciated...
>
> Regards
>
> ---
> Christian Rahmig
> railML.infrastructure coordinator
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
|
|
|
|
|
|
| Re: SpeedChange : Protection system reference [message #402 is a reply to message #399] |
Wed, 24 October 2012 16:30 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Christian, Dirk, Pierre and others,
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>> This reference from a <speedChange> to a <trainProtectionElement> is a
>> useful innovation, which may be implemented with railML 2.2, because the
>> reference attribute will be optional. However, is it really the
>> <speedChange> that needs to refer to the <trainProtectionElement> or is
>> it the signal, which is connected to the magnet or the Belgian crocodile?
>
> 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
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: SpeedChange : Protection system reference [message #403 is a reply to message #342] |
Wed, 24 October 2012 16:41 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Dirk, Christian, Pierre and others
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
As Dirk Bräuer wrote:
> In my opinion, the speed change sign and the <trainProtectionElement>
> have independent functions.
No, they have a strong dependence. I think of the German "GPA".
> (Of course they have the same origin or reason why they are there but:
> If there would be a speed change without <trainProtectionElement> or
> vice versa, each one would have to function alone.)
Yes, they do function alone. But if you remove the speed panel, you have
to remove or modify the magnets, too.
> Both should be implemented as single elements may be with the same
> position (meter).
Sure, they are already implemented this way.
> A reading software can possibly expect that there should be a
> <trainProtectionElement> at or near the position of a <speedChange>
> but there is no _general_ (internationally accepted) necessity for
> that.
I don't want the reading software to guess the above mentioned
dependence between the <speedChange> and the <trainProtectionElement>.
It may guess wrong! Maybe a train protection element is there for
another reason than the speed aspect, e.g. a signal in the other
direction.
Speed changes without such a link are surely the most common case and
will stay like they are now.
Besides this, it could be, that there are other facilities to ensure the
speed restriction than the above mentioned train protection elements,
e.g. highly equipped video cameras or laser devices with other
background systems? I don't know. We should leave an xs:any element
there. ;-)
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| 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
|
|
|
|
|
|
| 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
|
|
|
|
|
|
|
|
|
|
| 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.
|
|
|
|
| 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
|
|
|
|
| Re: SpeedChange : Protection system reference [message #453 is a reply to message #452] |
Tue, 13 November 2012 12:15 |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Susanne,
> 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.
Thank you for clarifying this, but it was Christian who brought the
discussion on signals, not me.
>> Considering a signal, it may show different signal aspects, which
>> relate to different <speedChange> elements then.
I am not sure whether you can cancel Christians thoughts in that way. ;-)
So the question still is whether the very important differences between
speedChanges and speedAspects should be "kept" anywhere, may be in Wiki.
If I get the agreement I would write it into Wiki.
---
Concerning the reference speedChange <-> trainProtectionElement:
- I would agree with the way via a 'trainProtectionGroup'.
- I agree the direction speedChange --> trainProtectionGroup (1:n) -->
trainProtectionElement (1:n) is the more reasonable one.
- Consider our discussion on cross-references in general: May be you want
to introduce both directions from the beginning.
Dirk.
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 04:43:30 CEST 2024
|
Members
Search
Help
Login
Home
