Home » railML newsgroups » railml.infrastructure » last open points for speedProfiles in railML 2.2
last open points for speedProfiles in railML 2.2 [message #368] Sat, 22 September 2012 11:12 Go to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear railML users,

the release of the new version railML 2.2 is approaching...
One big issue of the new schema is the implementation of speed profiles
that will be referenced by the <speedChange> elements. Since speed
instructions depend on a lot of parameters resulting directly from the
train (e.g. braking configuration, load), from the track's geography
(e.g. slope) or from operation (e.g. route of the train), the
<speedProfile> element includes a lot of attributes. The details can be
found in trac ticket [1].

At the end of this trac ticket few open points are listed and I want to
put these open points here into the forum and ask for your comments:

1. What to do with the current "trainCategory" attribute in <speedChange>?

Marking as "deprecated" is an easy way, but there are nevertheless
international train categories for lines, e.g. "NC_Train" of the ETCS
domain. Therefore I suggest to introduce a new attribute
"etcsTrainCategory" and mark the other one as deprecated.

2. What to do with the current "status" attribute in <speedChange>?

It is possible to define a state of validity for a speed restriction
in the sense of 'planned' or 'active' or ... However, I think, it is
better to put this information inside the <speedProfile> instead of the
<speedChange>.

3. How to define the "blocking of a track"?

The speed restriction vMax="0" within a <speedChange> does not imply
a blocking of a track. In particular, it may be possible to order a
train to enter a blocked track with a speed of 25 km/h. Therefore, I
suggest to add another attribute "blocked" of type boolean within the
<speedProfile>.

4. How to define an "obligational stop" where all or only certain trains
have to stop prior going on with the same speed aspect as before?

A maximum speed vMax="0" within a <speedChange> can be interpreted
as a mandatory stop. If we want to qualify the information of vMax="0",
we need to add another attribute to the <speedChange> element, e.g.
"specialPurpose". Its enumeration values like 'mandatoryStop' or
'mandatoryBraking' may cover all cases of obligational stops.

[1] https://trac.assembla.com/railML/ticket/41

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Train category for speed changes/speed profiles (was: last open points for speedProfiles in railML 2.2) [message #514 is a reply to message #368] Mon, 11 March 2013 11:21 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Dear railML users,

as written in Christians posting some times ago, the aspect of train
categories for speed changes / speed profiles is not satisfactory
discussed.

Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
> the release of the new version railML 2.2 is approaching...
> One big issue of the new schema is the implementation of speed
> profiles that will be referenced by the <speedChange> elements. Since
> speed instructions depend on a lot of parameters resulting directly
> from the train (e.g. braking configuration, load), from the track's
> geography (e.g. slope) or from operation (e.g. route of the train),
> the <speedProfile> element includes a lot of attributes. The details
> can be found in trac ticket [1].
>
> At the end of this trac ticket few open points are listed and I want
> to put these open points here into the forum and ask for your
> comments:
>
> 1. What to do with the current "trainCategory" attribute in <speedChange>?
>
> Marking as "deprecated" is an easy way, but there are nevertheless
> international train categories for lines, e.g. "NC_Train" of the ETCS
> domain. Therefore I suggest to introduce a new attribute
> "etcsTrainCategory" and mark the other one as deprecated.
>
> [1] https://trac.assembla.com/railML/ticket/41

There was no response here!

We met in Berlin last week and had small discussion at the round table
about this issue. But these discussions did also not lead to a clear
change request. I summarized the open points in a new Trac ticket and
hope that this thread collects some statements about the wished and
needed implementation for the upcoming railML 2.2.

See Trac ticket #225 [2]:

At the railML conference in Berlin (2013-03-06) a bit confusion
raised around the train category for speed profiles and speed
changes. See also #41 for the speed profile implementations.

Current implementation:

* Attribute etcsTrainCategory in speedChange element.
* no general train category attribute in speedProfile element, use
other special characterization instead

Questions/requests:

* general train category attribute for the speedProfile element

* special train category attribute for the speedProfile element in
order to define "passenger" and "goods" trains

* special train category attribute for the speedProfile element in
order to define special vehicle family types, e.g. "Flirt"

Any comments* in short-term appreciated.

[2] http://trac.assembla.com/railML/ticket/225
* +1, -1, questions, hints, use cases...

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Mandatory braking in front of a steep gradient (was: last open points for speedProfiles in railML 2.2) [message #517 is a reply to message #368] Mon, 11 March 2013 16:20 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Dear railML users,

At the railML conference in Berlin, the issue of this thread was
discussed. A summarized Trac ticket text is copied at the end of this
posting.

I found no proper discussion thread about this issue in this forum but
the following mentioning.

Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
> 4. How to define an "obligational stop" where all or only certain
> trains have to stop prior going on with the same speed aspect as
> before?
>
> A maximum speed vMax="0" within a <speedChange> can be interpreted
> as a mandatory stop. If we want to qualify the information of
> vMax="0", we need to add another attribute to the <speedChange>
> element, e.g. "specialPurpose". Its enumeration values like
> mandatoryStop' or 'mandatoryBraking' may cover all cases of
> obligational stops.
>
> [1] https://trac.assembla.com/railML/ticket/41

I summarized the opinions from the conference in Trac ticket #227 [2]:

During the last railML conference (2013-03-06) in Berlin the
discussion came to this aspect of the current speedChange
implementation:

If a goods train driver has not used its train brakes during a
specified time (e.g. last hour) it should do an "operational
braking" - not until standstill, but to check, if the brakes work
properly.

This operation is indicated at the drivers timetable.

It seems, that the scenario is a very special German one, that is
covered by the German operational rules. Brake tests are done very
differently across other countries. It is not a general infrastructure
specific issue, but more an operational one.

Therefore the implementation of "mandatoryBraking" in the element
"speedChange" should be removed.

railML partners should use an "any"-Attribute as a short-term solution.

For re-inventing this feature it should be modeled in another way.
There were no further proposals.

Any comments* appreciated.

Kind regards...
Susanne

[2] http://trac.assembla.com/railML/ticket/227
* +1, -1, hints, questions...

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Train category for speed changes/speed profiles (was: last open points for speedProfiles in railML 2.2) [message #521 is a reply to message #514] Tue, 12 March 2013 20:20 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 239
Registered: August 2008
Senior Member
Dear Susanne,

> Questions/requests:
>
> * general train category attribute for the speedProfile element

Not from my side - see arguments on such an attribute at "Stop posts for
different train types". Infrastructure has to be independent from
operators. Please always try to describe the physical background / reason.

> * special train category attribute for the speedProfile element in
> order to define "passenger" and "goods" trains

Not from my side. Please always try to describe the physical background /
reason.

> * special train category attribute for the speedProfile element in
> order to define special vehicle family types, e.g. "Flirt"

"Flirt" is not a train category in this meaning, rather a vehicle family.
Please do not mix the terms. The best would be to describe the physical
background / reason. There must be a physical reason why a "Flirt" is
allowed to go quicker or slower there. From a neutral, general point of
view: This speeds should be allowed also for all other vehicles with the
same physical attributes but with different names than "Flirt". (The
speeds should not depend on the name of the vehicles...)

If there is a need for a less neutral way: A "vehicleRef" (enumerable)
would be acceptable.

Best regards,
Dirk.
Re: Train category for speed changes/speed profiles (was: last openpoints for speedProfiles in railML 2.2) [message #526 is a reply to message #521] Fri, 15 March 2013 16:45 Go to previous messageGo to next message
thomas.kauer is currently offline  thomas.kauer
Messages: 15
Registered: January 2004
Junior Member
Dirk Bräuer wrote:
>
> Dear Susanne,
>
>> Questions/requests:
>>
>> * general train category attribute for the speedProfile element
>
> Not from my side - see arguments on such an attribute at "Stop posts for
> different train types". Infrastructure has to be independent from
> operators. Please always try to describe the physical background / reason.
>
>> * special train category attribute for the speedProfile element in
>> order to define "passenger" and "goods" trains
>
> Not from my side. Please always try to describe the physical background /
> reason.
>
>> * special train category attribute for the speedProfile element in
>> order to define special vehicle family types, e.g. "Flirt"
>
> "Flirt" is not a train category in this meaning, rather a vehicle family.
> Please do not mix the terms. The best would be to describe the physical
> background / reason. There must be a physical reason why a "Flirt" is
> allowed to go quicker or slower there. From a neutral, general point of
> view: This speeds should be allowed also for all other vehicles with the
> same physical attributes but with different names than "Flirt". (The
> speeds should not depend on the name of the vehicles...)
>
> If there is a need for a less neutral way: A "vehicleRef" (enumerable)
> would be acceptable.
>
> Best regards,
> Dirk.
>
>
Dear Dirk

there is certainly a physical reason, but that's not all: You need also
the permission (for example from the EBA or the BAV). So that at the end
only some construction types like Flirt may be allowed to get faster).

Best regards
Thomas


--
----== posted via PHP Headliner ==----
Re: Mandatory braking in front of a steep gradient [message #529 is a reply to message #517] Sat, 16 March 2013 13:11 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Susanne,

Am 11.03.2013 16:20, schrieb Susanne Wunsch:
> I summarized the opinions from the conference in Trac ticket #227 [2]:
>
> During the last railML conference (2013-03-06) in Berlin the
> discussion came to this aspect of the current speedChange
> implementation:
>
> If a goods train driver has not used its train brakes during a
> specified time (e.g. last hour) it should do an "operational
> braking" - not until standstill, but to check, if the brakes work
> properly.
>
> This operation is indicated at the drivers timetable.
>
> It seems, that the scenario is a very special German one, that is
> covered by the German operational rules. Brake tests are done very
> differently across other countries. It is not a general infrastructure
> specific issue, but more an operational one.
>
> Therefore the implementation of "mandatoryBraking" in the element
> "speedChange" should be removed.
>
> railML partners should use an "any"-Attribute as a short-term solution.
>
> For re-inventing this feature it should be modeled in another way.
> There were no further proposals.

+1

> [2] http://trac.assembla.com/railML/ticket/227

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Re: Mandatory braking in front of a steep gradient [message #1542 is a reply to message #517] Wed, 05 April 2017 13:56 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 135
Registered: January 2016
Senior Member
Dear all,

the following topic about "mandatory braking" is still open. However, it
seems like the interest in having a solution available in railML is
quite small. So: in case you urgently need a solution for modelling
mandatory braking points in railML infrastructure, please comment here.
Otherwise, the issue will be closed.

Best regards
Christian

Am 11.03.2013 um 16:20 schrieb Susanne Wunsch:
> Dear railML users,
>
> At the railML conference in Berlin, the issue of this thread was
> discussed. A summarized Trac ticket text is copied at the end of this
> posting.
>
> I found no proper discussion thread about this issue in this forum but
> the following mentioning.
>
> Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>> 4. How to define an "obligational stop" where all or only certain
>> trains have to stop prior going on with the same speed aspect as
>> before?
>>
>> A maximum speed vMax="0" within a <speedChange> can be interpreted
>> as a mandatory stop. If we want to qualify the information of
>> vMax="0", we need to add another attribute to the <speedChange>
>> element, e.g. "specialPurpose". Its enumeration values like
>> mandatoryStop' or 'mandatoryBraking' may cover all cases of
>> obligational stops.
>>
>> [1] https://trac.assembla.com/railML/ticket/41
>
> I summarized the opinions from the conference in Trac ticket #227 [2]:
>
> During the last railML conference (2013-03-06) in Berlin the
> discussion came to this aspect of the current speedChange
> implementation:
>
> If a goods train driver has not used its train brakes during a
> specified time (e.g. last hour) it should do an "operational
> braking" - not until standstill, but to check, if the brakes work
> properly.
>
> This operation is indicated at the drivers timetable.
>
> It seems, that the scenario is a very special German one, that is
> covered by the German operational rules. Brake tests are done very
> differently across other countries. It is not a general infrastructure
> specific issue, but more an operational one.
>
> Therefore the implementation of "mandatoryBraking" in the element
> "speedChange" should be removed.
>
> railML partners should use an "any"-Attribute as a short-term solution.
>
> For re-inventing this feature it should be modeled in another way.
> There were no further proposals.
>
> Any comments* appreciated.
>
> Kind regards...
> Susanne
>
> [2] http://trac.assembla.com/railML/ticket/227
> * +1, -1, hints, questions...
>

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: Mandatory braking in front of a steep gradient [message #1586 is a reply to message #1542] Thu, 18 May 2017 18:48 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 239
Registered: August 2008
Senior Member
Dear Christian,

> Therefore the implementation of "mandatoryBraking" in the element
> "speedChange" should be removed.
>
> railML partners should use an "any"-Attribute as a short-term solution.

I agree with that solution.

Please care (with a lower priority) that there will be a "docking" place
for user-defined (country-specific) virtual track elements as
<any>-elements like "mandatoryBrakingPlace" or "signalViewingPlace" or such.

With best regards,
Dirk.
Re: Mandatory braking in front of a steep gradient [message #1703 is a reply to message #1586] Mon, 12 February 2018 14:42 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 135
Registered: January 2016
Senior Member
Dear Dirk,

thank you for your feedback. In general, there is a "docking place" for
user-defined extensions in <trackElements>, which could be used to
define <mandatoryBrakingPlace> etc.
Since there has not been a big interest into this topic, I close the
ticket #227 [1].

Best regards
Christian Rahmig

[1] https://trac.railml.org/ticket/227


Am 18.05.2017 um 18:48 schrieb Dirk Bräuer:
> Dear Christian,
>
>> Therefore the implementation of "mandatoryBraking" in the element
>> "speedChange" should be removed.
>>
>> railML partners should use an "any"-Attribute as a short-term solution.
>
> I agree with that solution.
>
> Please care (with a lower priority) that there will be a "docking" place
> for user-defined (country-specific) virtual track elements as
> <any>-elements like "mandatoryBrakingPlace" or "signalViewingPlace" or
> such.
>
> With best regards,
> Dirk.


--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: Mandatory braking in front of a steep gradient [message #1861 is a reply to message #1703] Mon, 02 July 2018 12:53 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 55
Registered: March 2016
Member
As this posting contains images and formating I find difficult to embed in the current forum I have made a link to the pdf version of the posting.
https://1drv.ms/b/s!Ar_YbBaAx1YzgV9WMjwkzzWuVoaK
Shortened posting without images and formatting bellow:

B - Hirachy of the speed profiles (Further development and definition of the speedprofiles)

I will here dicuss the following:
1. Hirachy of the speed profiles
2. Generic vs. National names
3. Suggestion for slight refactoring and extention of the speedprofiles.

Hirachy of the speed profiles
In Norway we have multiple speed profiles that are all NOT continous which overlay.

Trains in Norway are always certified for more than one speed profile. This as the minimum is the "basis" and the "temporary" speed profiles. Most passenger trains in Norway support at least also the "pluss" speed profile.
So the question is which one is the valid one at a certain point in the infrastructure/ which one to choose.

Conditional speed Profiles
The simples solution is to create specific speed profiles with a defined condition that are specifically referenced from a train under TT or a formation of vehicle under RS. I do not suggest to reference the trains, vehicles or formations from the speed profile as the profiles do not know about trains, vehicles or formations, but trains, vehicles or formations know about the speed profiles.
Alternatively a new attribute <speedProfile @type="conditional" would indicate that the conditions in the speed profile need to be mapped to the properties in the RS. This would require some additional extentions to cover all conditional properties in the speedProfile in Norway at least.
The conditional speedprofiles are for branch lines, section of lines or local speed restrictions that apply under the following different conditions:
• Direction
• Axleload
• vehicle id/name (but this is just instead of using a generic value like axelload - so mapping can be omited)
• If the train is a passenger or a freight train
• if the freight train is loaded or empty

These values are all already definable in railML with the usage of or the extention of:
Direction
use <speedChange @dir>

Axleload
use <speedProfile @maxAxleLoad>

vehicle id/name
not covered, but do not map to

passenger or a freight train
Create new sub element <speedProfile/trainCategoryRef @ref> and map in TT:category @trainUsage the trains in TT and/or the formations/vehicles in RS to the TT:category.
Alternative create <SpeedProfile @trainUsage> and <formation @trainUsage>

loaded or empty train
Create new subelement <speedProfile/trainCategoryRef @ref> and map in TT:category @deadrun the trains in TT and/or the formations/vehicles in RS to the TT:category.
Alternatively create <SpeedProfile @deadrun> and <formation @deadrun>. The added value of mapping the @deadrun is that the software will know if to use bruttoWeight or tareWeight for it's calculations.

As mentioned these extentions are not needed if we require the user to reference the speedProfile in the train under TT or a formation of vehicle under RS. Something that would be possible with the initial suggested extention in theis thread.

Further I suggest to move @etcsTrainCategory from <speedChange> to <speedProfile> as this is a generic property of the speedProfile and not each SpeedChange.
As earlier mentionend the need to clarify @etcsTrainCategory reference to name "international train category number"
Should there be and additional new attribute <speedProfile @etcsOperationalTrainCategory refering to ANNEX B - list of ETCS operational Train categories in addition to @etcsTrainCategory?
I suggest to add the attribute <speedProfile@cantDeficiency for clear definition of the requirements for the speedProfile when not using the ETCS categories (independent if they are written).
I also suggest to move the attribute <speedChange @signalised to <speedProfile @signalised>. Alternatively to create a copy <speedProfile @signalised> for a generic approach to the speedProfiles properties instead of each singe speedChange.

Lenght of a speedProfile
To the question how long does the speedProfile extent I would say to the next <speedChange> with the same profile. This either beeing a new @Vmax value of a changed speed value or the "end" value. With the "end" value the profile ends. It is resumed when a new <SpeedChange> with the same profile is present.
So we in Norway suggest to end speed changes for speed profiles that end/are not continous. Prevoiusly we continued the speed profiles by writing in the valid speed profile value for all speed profiles if they did not differ (for instance basis/pluss/krenge = 40/40/40).
This is somewhat in conflict with the latest implementation of the use off the values "end" under <speedChange @Vmax=>. As the development of the value was, in my opinion, not documented transparent (in forum, wiki or comunity), I deem it OK to suggest a refactoring before it's implementation. Alternative the now suggested meaning of "end" (end last speedChange and resume the SpeedChange before that) could still apply if used in the "basis" profile. The same function would, though, be available using an overlay speed profile (for instance in the levelCrossing temporary speed reduction example in the simple example).

Choice of overlying speedProfiles

As there is not nessesarry a given fixed hirachy in the overlaying speedprofiles. We need to define a hirachy rule for the software to choose the correct speedprofile if more than one is present. Example is a decreasing speedprofile for heavy freight trains of continous Vmax=60 on the line. If the basis speed profile is above 60 then the heavy freight train profile is valid and if the basis profile is bellow 60 then the basis profile is valid.

I suggest the following hirachy:

Selection of Vmax for a specific train at a specific point in the infrastructure:
1. Filter the valid speedprofiles present in infrastructure with the valid ones for RS and/or TT.
a. Check for all speedprofiles present in the curent position in the infrastructure.
b. Check for speedProfiles present in the RS of the formation
c. Check for speedProfiles present in the TT of the train
d. Make intersection (Schnittmenge) of IS, RS and TT speedProfiles
2. Of these remaining speedProfiles choose the following:
3. If one or multiple speedProfiles with influenc="decreasing" is present use the speedProfile with the lowest speed (the current speedChange value).
4. If no speedProfile with influence="decreasing" is present and if one speedProfile with influenc="increasing" is present use this.
5. If no speedProfile with influence="decreasing" is present and if multiple speedProfiles with influenc="increasing" is present use the speedProfile with the highest speed (the current speedChange value)
6. If no speedProfile with influence="decreasing" and "increasing" is present and there is only one speedProfile with no set @influence then use this.
7. If no speedProfile with influence="decreasing" and influenc="increasing" is present and there is multiple speedProfiles with no set @influence then use the speedProfile with the lowest speed (speedChange).


C - National vs. Generic speed profiles.
The wiki for <speedProfile> (https://wiki.railml.org/index.php?title=IS:speedProfile) shows a Best practice with the Speed profile names "basis", "tilting", "temporary" and "heavyLoad".
I understand them as international values as they are written in english and use generic terms. But as some of the values have conditions attached to them that might differ from nation to nation and even from line to line I sugest to use different terms here.

Thus I suggest the following clearer term development for <speedProfile @name>.

Stage 1: term recomendation in the wiki.
The profiles that have no conditions and are thus valid for all trains (certified on the line) for a continous present in time and distance for a baseline speed use the international term "basis". Norwegian example: "Normal hastighet"
The profiles that have no conditions and are thus valid for all trains (certified on the line) and are NOT continous present in time or distance use the international term "temporary". Norwegian example: "midlertidig hastighet".
All other speedProfile names us the national prefix and the national short name. For instance "nor:krenge" for norwegian tilting speed profile. This as a term recomendation in the wiki in a first stage. Also we should have a wiki page for the used values to create an enumeration list in stage 2.

Stage 2: use enumeration list
When we have mapped the internationaly used speedProfiles, we can add <speedProfile @type="enumeration list"> and use the valuelist for the international speed profiles as the enumeration list i addition to :other (for anything not mapped in stage 1) and the value "conditional" for conditional speed profiles.
Previous Topic: etcsTrainCategory
Next Topic: [railML3] Concept Location: RTM location association to railML entity
Goto Forum:
  


Current Time: Tue Jul 17 05:31:47 CEST 2018