| Hierarchy of overlaying speed profiles and National vs. Generic speed profiles. [message #1955] |
Thu, 06 September 2018 15:08  |
Torben Brand
Messages: 156
Registered: March 2016
|
Senior 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://forum.railml.org/userfiles/2018-07-02_jbd_speed-prof ile-hierachy-names-refactoring.pdf
Shortened posting without images and formatting bellow:
Further development and definition of the speedProfile
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.
etcsTraincatagory
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).
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.
|
|
|
|
| Re: Hierarchy of overlaying speed profiles and National vs. Generic speed profiles. [message #1956 is a reply to message #1955] |
Thu, 06 September 2018 17:16  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Torben,
thank you for your work on speed profiles. It is a very important topic also for us.
I would prefer if you could split the long post into several sub-topics because probably not many readers want to follow such long texts.
=================================
> Conditional speed Profiles
---------------------------------
> In Norway we have multiple speed profiles that are all NOT continous which overlay.
Yes, we too. We consider this as a ‘normal’ case.
> 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.
Currently I don’t see any reason for such a new attribute because from my understanding, all conditions of <speedProfile>s always must fit to the RS. No <speedProfile> is to be used if only one of its conditions does not fit to the RS.
> Direction: use <speedChange @dir>
I agree.
> Axleload: use <speedprofile @maxAxleLoad>
I agree.
> 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.
I agree. But I would prefer just an attribute <speedprofile @trainCategoryRef> as it already exists with <speedprofile @operatingPeriodRef>.
> 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.
I agree. But I would prefer… same as above.
> Further I suggest to move @etcsTrainCategory from <speedChange> to <speedprofile> as this is a generic
No objection.
> Should there be and additional new attribute <speedprofile @etcsOperationalTrainCategory refering to ANNEX B - list of ETCS operational Train categories in addition to @etcsTrainCategory?
I have no exact opinion but I doubt that this is useful for interoperability because from my opinion, ETCS still is a highly national different phenomenon with much depending on national values. So I cannot imagine an international agreed etcsTrainCategory nor etcsOperationalTrainCategory at the moment. Correct me in case I am wrong.
> 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).
Generally, I agree, but I would prefer a more generalised, physical value instead of @cantDeficiency. We have no @cantDeficiency at <speedProfile>.<tilting>, instead we have <speedProfile>.<tilting @maxTiltingAngle> etc. So, we should use a more SI-like (and gauge-independent) attribute like <speedprofile @maxSideAcceleration> or <speedprofile @maxSideForce>.
> I also suggest to move the attribute <speedChange @signalised to <speedprofile @signalised>.
I strongly disagree. We have speedProfiles with mixed signalised and non-signalised speedChanges.
> Alternatively to create a copy <speedprofile @signalised> for a generic approach to the speedprofiles properties instead of each singe speedChange.
No objection. It must be clarified that <speedChange @signalised> overwrites the parent <speedProfile @signalised>.
=================================
> 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.
No objection. It’s the natural approach, I would suppose.
> With the "end" value the profile ends. It is resumed when a new <SpeedChange> with the same profile is present.
I fully agree and think that there was never a different intention.
> So we in Norway suggest to end speed changes for speed profiles that end/are not continous.
I agree.
> Alternative the now suggested meaning of "end" (end last speedChange and resume the SpeedChange before that)…
As you do, I do also not like to see this interpretation. The “end” value was only introduced in r2.2 and it was done to allow a <speedProfile> to be ended finally. (I can prove this by referring to forum posts dealing with the introduction of that value.) It was never intended to resume the previous speed.
In Germany, we have speed profiles for tilting technology. When such a speed profile ends, the train has to resume with the conventional speed of the overlaying conventional (non-tilting) base profile. Of course, the train is not allowed to resume with the speed of the previous curve before the last curve!
=================================
> Choice of overlying speedprofiles / Hierarchy of speed profiles
---------------------------------
The “hierarchy rules” for speed profiles should already be considered by the attribute <speedProfile @influence>. So far, there was no need seen for a further definition.
> 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 current 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
I do not agree with your enumeration in detail. In particular, I see no need to make an intersection if you have a <train> referring to <speedProfile>s. The train is only allowed to enumerate exactly the <speedProfile> which apply for it’s timetable.
However, we can possibly leave this question to the use case. May be you see a different use case than I do.
> 2. Of these remaining speedprofiles choose the following:
I think your following enumeration is much more difficult than needed but it still may be right.
I would simply say: First find the highest increasing value and then find the lowest decreasing value. (Naturally this implies: If there is no decreasing profile, the highest increasing counts.)
> 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….
This cannot happen because in my opinion, @influence is not optional.
We assume that there is always at least one “base profile” for each <track>. The base profile is declared @influence=’increasing’ in railML.
=================================
National vs. Generic speed profiles.
---------------------------------
Taking the above mentioned (and in my opinion agreed) “hierarchy rules” for speed profiles, I see no reason why we need to distinguish between national and generic speed profile.
More, I would probably oppose against a <speedProfile @type> enumeration because the question arises: How should that fit into or influence the hierarchy? I think the hierarchy clarifies everything we need.
With best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
