| speed profiles and braking percentages [message #302] |
Thu, 26 April 2012 20:46  |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Hello to all,
Susanne wrote:
> [minimum percentage of brake power]
>
> At some railway infrastructure companies the minimum percentage of
> brake power can't be directly calculated by means of physics. It is
> somehow defined by some legal body.
>
> Therefore we would suggest an additional attribute
> "minimumBrakePercentage" for this value in the <speedProfile> element.
Sorry: It _can_ always be "directly calculated by means of physics" but it
is not done so because of arbitrariness... ;-)
Anyway, I know that there are such rules but it is not so easy at least
from a theoretical point of view.
There is a strong physical relation between
- the braking distance of a train,
- the braking power of the train (brake percentage, deceleration - anyway
in which unit),
- the gradient of the line at the braking distance,
- the current speed of the train.
By setting a "minimumBrakePercentage" to a <speedProfile> you skip the
other two of the above named values.
Therefore, this implies the assumptions
- of the (maximum) braking distance being constant for all the route of
the speed profile (which may be acceptable in many cases),
- of the gradient being constant for all the route of the speed profile
???
At least the last one is improbable and possibly a little bit too rough.
You may have a ruling gradient at a line but surely not a constant one.
This would mean that a train running a short section only (e. g. between
two stations) of a speed profile does need the brake percentage of the
steepest section of all the line even if it does not pass that steepest
section?
A more proper solution would be:
There is a "minimumBrakePercentage" for each section of a speed profile
between two places where trains can start or end (i. e. between two
stations).
However, I am aware that there are such "rough" rules in practice but I
think that this is "not the complete truth". There are also rules which
apply additionally to avoid that a train needs to run unnecessarily slow.
May be these additional rules are not obvious or not shown in the fist
place. To avoid mistakes which we can hardly correct only I would
recommend to think about "sectional minimum brake percentage" rather than
one for all the speed profile (which would lead to many many short speed
profiles).
---
At least, for completeness: If we add a "minimumBrakePercentage" to
<speedProfile> we also have to provide them with a brake type and a brake
switch position (rail:tAirBrakeApplicationPosition). The same brake
percentage can mean totally different braking power depending on the brake
position (G or P,...).
Best regards,
Dirk.
|
|
|
|
| Re: speed profiles and braking percentages [message #305 is a reply to message #302] |
Thu, 26 April 2012 23:15  |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hello Dirk and others,
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> Susanne wrote:
>> [minimum percentage of brake power]
>>
>> At some railway infrastructure companies the minimum percentage of
>> brake power can't be directly calculated by means of physics. It is
>> somehow defined by some legal body.
>>
>> Therefore we would suggest an additional attribute
>> "minimumBrakePercentage" for this value in the <speedProfile> element.
Thanks for your explanations.
> A more proper solution would be:
> There is a "minimumBrakePercentage" for each section of a speed
> profile between two places where trains can start or end
> (i. e. between two stations).
How about putting this attribute into the "speedChange"?
For sure, it messes up the code. :-(
But this allows for defining "sections of speed aspects" instead of
"lots of quite equal speed profiles".
> ---
> At least, for completeness: If we add a "minimumBrakePercentage" to
> <speedProfile> we also have to provide them with a brake type and a
> brake switch position (rail:tAirBrakeApplicationPosition). The same
> brake percentage can mean totally different braking power depending on
> the brake position (G or P,...).
Thanks again. That's a good point we should forseen.
--
Kind regards...
Susanne
|
|
|
|
| Re: speed profiles and braking percentages [message #369 is a reply to message #305] |
Sat, 22 September 2012 12:08 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Susanne, Dirk and anyone interested,
>>> [minimum percentage of brake power]
>>>
>>> At some railway infrastructure companies the minimum percentage of
>>> brake power can't be directly calculated by means of physics. It is
>>> somehow defined by some legal body.
>>>
>>> Therefore we would suggest an additional attribute
>>> "minimumBrakePercentage" for this value in the <speedProfile> element.
>> A more proper solution would be:
>> There is a "minimumBrakePercentage" for each section of a speed
>> profile between two places where trains can start or end
>> (i. e. between two stations).
>
> How about putting this attribute into the "speedChange"?
>
> For sure, it messes up the code. :-(
>
> But this allows for defining "sections of speed aspects" instead of
> "lots of quite equal speed profiles".
If the attribute "minimumBrakePercentage" is directly coupled with the
speed information and only used for speed profile purposes, I agree to
somehow implement it in connection with the <speedChange> element. But
if we can think of other usages of the "minimumBrakePercentage"
information, i prefer to put it in an extra element outside the
<speedProfile>.
Therefore my question to everyone: Are there any other applications for
the "minimumBrakePercentage" information, which are not connected to the
speed of the train?
>> At least, for completeness: If we add a "minimumBrakePercentage" to
>> <speedProfile> we also have to provide them with a brake type and a
>> brake switch position (rail:tAirBrakeApplicationPosition). The same
>> brake percentage can mean totally different braking power depending on
>> the brake position (G or P,...).
>
> Thanks again. That's a good point we should forseen.
At the moment, within the ongoing implementation of trac ticket [1] for
railML 2.2, we only defined the new attribute "minimumBrakePercentage"
of type "tBrakePercentage" for a <speedProfile>. Depending on the
comments on my above question, I would add the further attributes
mentioned there.
[1] https://trac.assembla.com/railML/ticket/41
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
| Re: speed profiles and braking percentages [message #377 is a reply to message #369] |
Tue, 02 October 2012 20:17 |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear Christian,
> Therefore my question to everyone: Are there any other applications for
> the "minimumBrakePercentage" information, which are not connected to the
> speed of the train?
To avoid a misunderstanding: The "minimumBrakePercentage" _depends_ on the
permitted speed! In one section of line, you have _many_ minimum brake
percentages - one for each possible permitted speed (normally from 20 km/h
until the maximum permitted speed in 5 km/h steps) and for each braking
switch and for each direction.
So, it may not be possible to have "minimumBrakePercentage" information
which are not connected to the (permitted) speed of the train.
>>> At least, for completeness: If we add a "minimumBrakePercentage" to
>>> <speedProfile> we also have to provide them with a brake type and a
>>> brake switch position (rail:tAirBrakeApplicationPosition).
> At the moment, within the ongoing implementation of trac ticket [1] for
> railML 2.2, we only defined the new attribute "minimumBrakePercentage"
> of type "tBrakePercentage" for a <speedProfile>.
Anyway - wherever you have an attribute "minimumBrakePercentage" you
_must_ also have the connected brake type and position - otherwise nobody
can know for which trains the "minimumBrakePercentage" applies.
I would strongly recommend not to make a half solution: Either you
introduce minimum brake percentage, brake type and position or you
introduce nothing.
Since we do know that we need the minimum brake percentages in practice, I
would prefer to define all the necessary attributes now.
Best regards,
Dirk-
|
|
|
|
| Re: speed profiles and braking percentages [message #388 is a reply to message #377] |
Thu, 18 October 2012 16:06 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Dirk and other railML users,
> Anyway - wherever you have an attribute "minimumBrakePercentage" you
> _must_ also have the connected brake type and position - otherwise
> nobody can know for which trains the "minimumBrakePercentage" applies.
>
> I would strongly recommend not to make a half solution: Either you
> introduce minimum brake percentage, brake type and position or you
> introduce nothing.
As described in the latest comment of trac ticket [1] I implemented the
missing attributes: The attributes "brakeType" (values: 'G', 'P', 'R',
'N/A') and "airBrakeApplicationPosition" (values: 'none',
'compressedAir', 'handBrake', 'vacuum', 'parkingBrake', 'cableBrake')
are used and combined in a container element <braking>. This container
is a child element of <speedProfile>. As already mentioned by Susanne,
it might be useful to put these braking information into the
<speedChange> element instead of the <speedProfile>.
Any comments appreciated...
[1] https://trac.assembla.com/railML/ticket/41
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
|
|
|
|
|
|
|
|
| Re: speed profiles and braking percentages [message #396 is a reply to message #395] |
Wed, 24 October 2012 10:04 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Dirk, Christian and others
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>> It seams to me that there are no attributes on whether a speed change is
>> signalled and pre-signalled? Two boolean attributes would be needed.
>> (Signalled: Is there any kind of sign at the place where the speed
>> change applies? Pre-signalled: Is there any kind of sign at a proper
>> pre-signalling distance before the place where the speed change applies?)
>
> If there is a sign at the place where the speed change applies, a
> <signal> element might be placed. The only thing missing in that
> concept at the moment is the reference from the <signal> to the
> <speedChange>.
>
> In [1] the proposed attribute "signalised" for the <speedChange> has
> been discarded after the discussion with the other coordinators on
> September 10.
>
> [1] https://trac.assembla.com/railML/ticket/41#comment:7
There are an ongoing discussions about the speed panels in special [1]
and panels in general [2] in other threads of this forum. That's the
reason for discarding the attribute "signalised" from the <speedChange>
element.
Kind regards...
Susanne
[1] http://www.railml.org/forum/ro/?group=1&id=149
[2] http://www.railml.org/forum/ro/?group=1&id=148
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: speed profiles and braking percentages [message #405 is a reply to message #395] |
Wed, 24 October 2012 18:00 |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear Christian,
in many countries we have to "highlight" or distinguish between line-side
shown speed changes and such speed changes which are not shown (no signal
panel and no main signal). The "highlighting" can be of very different
kinds, for instance in Germany the non-presignalised speed changes have to
be shown inverse.
> In [1] the proposed attribute "signalised" for the <speedChange> has
> been discarded after the discussion with the other coordinators on
> September 10.
Well: How should we describe (in RailML 2.2 ff.) whether a speed change is
(pre-)signalised or not - so whether it has to be shown "highlighted" or
not?
Will that be possible from RailML 3.0 on only?
Also, I want to point out that this is not only a matter of "describing
infrastructure". It is also a matter of describing timetables, here
especially Driver's Timetables. So let's imagine I have to transfer a kind
of Driver's timetable from a planning software to an on-board system
(EBuLa or such). Normally, I do not write much infrastructure in such
RailML files - normally not all track elements and only the really needed
speeds.
Is it really the intention of RailML that, in such a case, I have to
create "panel" track elements for most of the speed changes only to tell
that they are not to be printed inversely?
Please take also into account: To know whether a speed change has to be
"highlighted" I only have to know _whether_ it is (pre-)signalised or not
- I do not need to know _where_ it is (pre-)signalised. To place a "panel"
track element in the RailML file, I would have to know _where_ the speed
change is (pre-)signalised. This is a special problem if the "highlight
status" depends on the pre-signalisation ("announcementPanel" rather than
the "executionPanel") - of course this is the more important panel since
the driver virtually can do nothing if he arrives at a "reduce speed
execution" panel without pre-signalisation...
Also, please take into account that between the "reduce speed
announcement" panel and the "reduce speed execution" panel there may be
points, especially trailing points (in contrary to facing points). So it
can become very difficult for a reading software... to scan all possible
routes leading to the speed change: If there is at least one route without
pre-signalisation (where there is no announcement panel in a proper
distance?) the speed change has to be shown inversely... I think this is
not a practicable solution.
Rather, in my opinion the "is (pre-)signalised" attribute is a _status_ of
a speed change - may be sometimes a somewhat indiscriminately assigned
status which cannot always be deducted from the real infrastructure.
With best regards,
Dirk.
|
|
|
|
| Re: speed profiles and braking percentages [message #435 is a reply to message #405] |
Mon, 12 November 2012 10:55 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>> In [1] the proposed attribute "signalised" for the <speedChange> has
>> been discarded after the discussion with the other coordinators on
>> September 10.
> Is it really the intention of RailML that, in such a case, I have to
> create "panel" track elements for most of the speed changes only to
> tell that they are not to be printed inversely?
If you know about the position of the announcement panels it is really
the above mentioned intention of the current railML implementation.
> Please take also into account: To know whether a speed change has to
> be "highlighted" I only have to know _whether_ it is (pre-)signalised
> or not - I do not need to know _where_ it is (pre-)signalised.
Thanks for pointing out, that description does currently not fit into
the implementation.
I filed a separate Trac ticket for this aspect in order to find a
solution for railML 2.2.
http://trac.assembla.com/railML/ticket/190
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: speed profiles and braking percentages [message #437 is a reply to message #390] |
Mon, 12 November 2012 12:16 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>> As already mentioned by Susanne, it might be useful to put these
>> braking information into the <speedChange> element instead of the
>> <speedProfile>.
>
> So why don't you move it? We have already discussed it on 29.06.2012
> and 26.04.2012. Already then it was written: "So, I would prefer to
> add the above named triplet as attributes of a speed change: They are
> valid until the next speed change with such attributes."
I filed a Trac ticket for this issue in order to clarify it within
railML 2.2:
http://trac.assembla.com/railML/ticket/193
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| Re: speed profiles and braking percentages [message #508 is a reply to message #437] |
Tue, 08 January 2013 16:06 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Susanne, Dirk and other railML users,
Am 12.11.2012 12:16, schrieb Susanne Wunsch:
> Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>>> As already mentioned by Susanne, it might be useful to put these
>>> braking information into the <speedChange> element instead of the
>>> <speedProfile>.
>>
>> So why don't you move it? We have already discussed it on 29.06.2012
>> and 26.04.2012. Already then it was written: "So, I would prefer to
>> add the above named triplet as attributes of a speed change: They are
>> valid until the next speed change with such attributes."
>
> I filed a Trac ticket for this issue in order to clarify it within
> railML 2.2:
>
> http://trac.assembla.com/railML/ticket/193
after certain discussions I decided to leave the braking attributes in
the element <speedProfile>. This way, the speed profile is valid for a
train fulfilling the specified braking configuration. For another train
with a different braking configuration, a new speed profile needs to be
defined.
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
