Home » railML newsgroups » railml.rollingstock » Extension rolling stock for capacity planning (Resistance factors, Minimum time to hold speed and Deceleration table per brake supervision)
Extension rolling stock for capacity planning [message #1565] Wed, 10 May 2017 11:36 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
For the use case capacity planning we need to have unambiguous defined rolling stock. This has become ever so more important as we now have a more fragmented sector with legally binding values between the entities. Rolling stock capabilities therefore must be precisely and efficiently defined. A railML file describing the rolling stock can solve this need.

As far as I can see the following elements are available in the software tools Opentrack and Treno. The values are necessary for an adequate precise running time calculation. As far as I can see I cannot find them in railML 2.3.

• Resistance factors for calculating train resistance
• Minimum time to hold speed
• Deceleration table for formations and per brake supervision type


Resistance factors for calculating train resistance

According to the Wiki:
"The sum of vehicle resistances is not the total of train resistance due to aerodynamic effects of vehicle formations. Therefore the resistance value is preferable given for the entire formation of the train. Dependent on the purpose there are different formulas used for the calculation of speed related values. RailML offers two basic possibilities of train resistance value representation - valueTable oder mathml."

As we have well established formulas in the sector (Strahl, Sauthoff and Davies) that are used directly in the calculation/simulation tools. I suggest to add the factors (Koefizienten) for these three most common resistance equations in/of the formation. It would still be possible to add either values in value tables or define other formulas by way of mathML. It needs to be made clear in the documentation that only either one of the three should/can be modelled.

Strahl/Sauthoff (Strahl for locomotives and freight wagons and Sauthoff for passenger wagons)
Davies formula (mass dependent) [F=m*g/1000*(A+B*v+C*v^2]
Davies formula (mass independent) [F=A+B*v+C*v^2]

I suggest extending the rolling stock schema with the following elements, this first in the Norwegian extension railML2.3NO: and if the community and RS coordinator agrees later in railML 2.4:

<formation><trainResistance>@strahlFactor [N]
<formation><trainResistance>@daviesMassdependant [bolean] (YES=mass dependent formula, NO=mass independent formula)
<formation><trainResistance>@daviesFactorA [kN]
<formation><trainResistance>@daviesFactorB [kN]
<formation><trainResistance>@daviesFactorC [kN]

I suggest to be more precise in the documentation/wiki to define if the existing attribute <vehicle>@resistanceFactor can also be applied in the Strahl formula for locomotives in a formation.

Minimum time to hold speed

Some railways have rules specifying that a train may only increase its speed if it can maintain this
speed for a specified time (e.g., 30 seconds) before it must brake. This rule only applies for punctual trains traveling over 40 km/h. This rule gives a more energy efficient and passenger comfortable driving style.

I suggest extending the rolling stock schema with the following elements, this first in the Norwegian extension railML2.3NO: and if the community and RS coordinator agrees later in railML 2.4:

<formation><trainEngine>@trainMinTimeHoldSpeed


Deceleration table for formations and per brake supervision type


In railML2.3 it is possible to describe the brake under:
<vehicle><vehicleBrakes><vehicleBrake>@meanDeceleration
or
<vehicle><vehicleBrakes><vehicleBrake><rail:valueTable>
From [km/h] - to [km/h] - Deceleration [m/s^2]
Or under
<formation><trainBrakes>@meanDeceleration

A vehicle or formation can have a technical @vehicleBrake capability according to @brakeType. This braking capability is taken advantage of differently by the driver under different situations and under different train protection regimes (line side) modeled as @trainProtectionElements in railML IS. This needs to be reflected according to the capacity planning use case. This as the normal driving behaviour is calculated in run time calculations and simulations.
Thus we will get a @vehicleBrake per @brakeSupervision value available in the train.
I suggest if no @brakeSupervision is set the described @vehicleBrake values are the trains technical/emergency brake capabilities.

I suggest extending the rolling stock schema with the following elements, this first in the Norwegian extension railML2.3NO: and if the community and RS coordinator agrees later in railML 2.4:

<vehicle><vehicleBrakes><vehicleBrake>@brakeSupervision:"none/ATP/ETCS/other:" (The values must match the values used under IS:@trainProtectionElement)
<vehicle><vehicleBrakes><vehicleBrake>@decelerationDelay [s] (average brake application time)
<vehicle><vehicleBrakes><vehicleBrake>@releaseSpeed [km/h] (for a generic default none lineside value. Lineside values override this value. For a speed below release speed the applied @vehicleBrake value table is always applied for the value "none")

The same needs to be defined under formation. This as a formation may have different braking values than the sum of its vehicles.

<formation><trainBrakes><trainBrake>@brakeSupervision:"none/ATP/ETCS/other:" (The values must match the values used under IS:@trainProtectionElement)
<formation><trainBrakes><trainBrake><rail:valueTable>
<formation><trainBrakes><trainBrake>@decelerationDelay (average brake application time)
<formation><trainBrakes><trainBrake>@releaseSpeed [km/h] (for a generic default none lineside value. Lineside values override this value. For a speed below release speed the applied @vehicleBrake value table is always applied for the value "none")

Re: Extension rolling stock for capacity planning [message #1567 is a reply to message #1565] Wed, 10 May 2017 13:41 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
• Resistance factors for calculating train resistance
see https://trac.railml.org/ticket/312

• Minimum time to hold speed
see https://trac.railml.org/ticket/311

• Deceleration table for formations and per brake
see https://trac.railml.org/ticket/313

--
Dr.-Ing. Jörg von Lingen - Rollingstock scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 351 87759 40; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: Extension rolling stock for capacity planning [message #1568 is a reply to message #1567] Fri, 12 May 2017 05:58 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
We have already the description of the physical brake characteristics <vehicleBrake> respectively <trainBrakes>. Thus my
suggestions is to add in parallel a new element <vehicleBrakeOperation> // <trainBrakeOperation> for description of the
operational use of the physical system.
See attached diagrams

--
Dr.-Ing. Jörg von Lingen - Rollingstock scheme coordinator

Joerg von Lingen wrote on 10.05.2017 13:41:

> • Deceleration table for formations and per brake
> see https://trac.railml.org/ticket/313
>
Re: Extension rolling stock for capacity planning [message #1570 is a reply to message #1568] Fri, 12 May 2017 12:28 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
I thank the RS coordinator for quick and thoughtful work. I have these additional comments:

There is sometimes a need to define the mean deceleration differently over different speed bands. For instance 0,6 m/s^2 from 0 to 70 km/h and 0,4 m/s^2 from 71 to 200 km/h. The amount of bands is not defined. Thus we also need to allow a function table to describe multiple mean deceleration values.

The suggested element <VehicleBrakeOperation> needs to be defined both under vehicle and formation.

The brakes deceleration values under <VehicleBrakeOperation> are the drivers normal behaviour under the different train protective systems. The question is if we need to define what braking curve a "normal" driving behaviour corresponds to? For instance at Jernbanedirektoratet we assume the driver drives according to the permitted curve (P) under ETCS and the blink indicator curve in ATC under normal behaviour. When the train is considered delayed the driver drives 100% according to the "normal" curve. If the train is not delayed the train driver drives more relaxed to arrive on time to the next OCP. This is either calculated in the simulation tool or there is a relaxation value in form of a percent performance value of the "normal" deceleration values (for instance 90%).

I suggest to add a further attribute @brakingCurveType under <VehicleBrakeOperation>. Set values are "Indication", "Permitted","SBI","EBI" and "other:" (SBI:Service brake intervention, EBI: Emergency brake intervention)
Alternatively the braking curve modeled can be under a @description attribute.
Re: Extension rolling stock for capacity planning [message #1572 is a reply to message #1570] Fri, 12 May 2017 16:18 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
see directly below

Best regards,
Joerg v. Lingen

Rollingstock Coordinator

On 12.05.2017 12:28, Torben Brand wrote:
> I thank the RS coordinator for quick and thoughtful work. I
> have these additional comments:
>
> There is sometimes a need to define the mean deceleration
> differently over different speed bands. For instance 0,6
> m/s^2 from 0 to 70 km/h and 0,4 m/s^2 from 71 to 200 km/h.
> The amount of bands is not defined. Thus we also need to
> allow a function table to describe multiple mean
> deceleration values.
The idea was to use the <decelerationTable> which is a sub-element of
<vehicleBrakeOperation>. The type "tCurve" allows a valueTable y=f(x,z) to just
include such information.

>
> The suggested element <VehicleBrakeOperation> needs to be
> defined both under vehicle and formation.
Indeed. The idea was to have the same type at both parts. But during the
discussion I only implemented one.

>
> The brakes deceleration values under <VehicleBrakeOperation>
> are the drivers normal behaviour under the different train
> protective systems. The question is if we need to define
> what braking curve a "normal" driving behaviour corresponds
> to? For instance at Jernbanedirektoratet we assume the
> driver drives according to the permitted curve (P) under
> ETCS and the blink indicator curve in ATC under normal
> behaviour. When the train is considered delayed the driver
> drives 100% according to the "normal" curve. If the train is
> not delayed the train driver drives more relaxed to arrive
> on time to the next OCP. This is either calculated in the
> simulation tool or there is a relaxation value in form of a
> percent performance value of the "normal" deceleration
> values (for instance 90%).
Again, the suggested <decelarationTable> allows description of a
three-dimensional function. Its parent element <vehicleBrakeOperation> shall
appear per each @brakeSupervision value.

> I suggest to add a further attribute @brakingCurveType under
> <VehicleBrakeOperation>. Set values are "Indication",
> "Permitted","SBI","EBI" and "other:" (SBI:Service brake
> intervention, EBI: Emergency brake intervention) Alternatively the braking curve
> modeled can be under a
> @description attribute.
In case other decelaration curves are needed it would be better to enhance the
tBrakeSupervision type. Otherwise there has to be the full
<VehicleBrakeOperation> for each combination of @brakeSupervision and
@brakingCurveType.
Re: Extension rolling stock for capacity planning [message #1577 is a reply to message #1565] Thu, 18 May 2017 15:16 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Torben,

Concerning:
Resistance factors for calculating train resistance,
well established formulas in the sector (Strahl, Sauthoff and Davies)

I agree from the basics.

But I am not convinced that including directly such rather
"old-fashioned" formulas like Strahl and Sauthoff into railML. At least,
if we do so, we should first provide more general formulas before the
specials.

Strahl, Sauthoff and Davies include a combination of several different
resistances in their formulas and lack other resistances. So, for
instance, they normally include air resistance and head wind but only in
"open air" much by empiric.

There is already a solution to provide general formulas in railML:
mathml. So if necessary, to keep railML as the general exchange format
it is intended to be, Strahl, Sauthoff and Davies with their
coefficients could be written in mathml. Everything else would be a
redundancy, wouldn't it?

We also have such values and a <railML> implementation of it. It
produces <railML> with formulas in mathml. If now there will be a
special solution for Strahl, Sauthoff and Davies, I would
- add some more general formulas from my side,
- like to have a very conscious decision to avoid "uncontrolled growth",
- ask what we should do with our implementation: Change to special
solution, import redundantly both mathml and special solution or only
support mathml.

---
Concerning
<formation><trainEngine>@trainMinTimeHoldSpeed

Again, I agree from the basics.

But I do not see that this depends on certain rolling stock. From my
experience, it is a general value, may be network-wide or depending on
certain lines but not vehicles.

We would use a kind of @minimumSpeedMaintainingTimeDelay as a
network-wide default value and in <train>.<trainPartSequence> to
optionally overwrite the default value but currently there is no demand
for it in <railML>.

If such a value will be introduced, I want to suggest there should be
- a default value for all <railML> file,
- a value per <line> or <track> in infrastructure to overwrite the
default value,
- a value per vehicle or formation if this will be agreed as necessary,
- a value per <trainPartSequence> to overwrite the value coming from
default, infrastructure or vehicle.

The priority shall be from to to bottom of my list.

---
Concerning

<vehicle><vehicleBrakes><vehicleBrake>@brakeSupervision:"none/ATP/ETCS/other: "

Such an attribute would be useful in general. Please consider that
braking does not only depend on the vehicle properties. It also depends
on the line-side infrastructure and possibly on operation rules. So, the
same vehicle may have different @brakeSupervision (along with other
brake-related properties) depending on the line and train it operates.
It would be desirable to have
- an enumeration of such attributes at vehicles with a priority,
- the same basic types for <infrastructure>, <rollingStock> and
<timetable>.

I agree with you and with Jörg von Lingen concerning
> In case other decelaration curves are needed it would be better to enhance the tBrakeSupervision type.

For the sake of completeness I want to add:

Currently there is a differentiation between emergency brake values and
regular (operational) brake values in
<train>.<trainPartSequence>.<brakeUsage> and
<rollingStock>...<vehicleBrakes>.

The intention is that regularBrakePercentage, regularBrakeMass,
meanDeceleration a.s.o. define the behaviour of the train when either
@brakeSupervision=none or in all other cases as the maximum possible
regular brake acting. (@brakeSupervision=ATP/ETCS/other can only
_reduce_ the brake acting, not raise it as long as we keep in planning
and do not plan emergency brakes).

With best regards,
Dirk.
Previous Topic: railML 2.3: Formation attributes shall have values > 0
Next Topic: Floor height
Goto Forum:
  


Current Time: Thu Mar 28 19:24:54 CET 2024