| speedProfile and rolling stock [message #1826] |
Mon, 04 June 2018 15:11  |
Torben Brand
Messages: 157
Registered: March 2016
|
Senior Member |
|
|
We need to map which <speedProfile> (https://wiki.railml.org/index.php?title=IS:speedProfile) the rolling stock can run under. This either or both for the individual vehicle or the whole formation.
It is today possible to define the properties of a speedProfile (like for instance tilting properties) and the same properties in the rolling stock. Those properties then could be mapped by the railML reading tool. The problem here is that not always are the properties mapped and more important the speedProfile is specifically assigned to a vehicle after a running capability test. So, it might be that a vehicle fulfils the criteria, but for railML unknown reasons is not qualified for the speedProfile.
A rolling stock can run under one or more speedProfile. In case the speedProfile under the infrastructure schema is in the same file it should be referenced by it's @id. But usually the two schemas are in separate files so the corresponding speedProfile should be referenced by it's @name attribute.
If no speedProfile is mapped under rolling stock the vehicle/formation can run under all defined speedProfiles?
How do you think this should be mapped? And would it be possible to be added still in railML2.4RS? If not we need to make an extention.
|
|
|
|
|
|
| Re: speedProfile and rolling stock [message #1836 is a reply to message #1829] |
Tue, 12 June 2018 18:20  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Torben,
I understand that you want to link speedProfiles with vehicles in railML. However, so far, the link between speedProfiles and vehicles has been seen by trains only, not directly. That's why there is a reference to a <speedProfile> from a <trainPart> but not from a <vehicle>.
From the current point of view, only the train determines which speedProfile its vehicles use. Without a train, the vehicles don't "know" about speedProfiles. For instance, an ICE-T (with tilting technology) is ready to run with or without increased tilting speeds. Only the actual planned train = timetable decides whether it uses tilting or not. A hybrid engine (Diesel+battery) is ready to run with Diesel or battery, only the timetable decides which is actually planned a.s.o.
I understand that you may want to encode the possible links between speedProfiles and vehicles _without_ having a timetable. And I have no objection against it in general.
However, please consider that this leads to a possible redundancy: In case there is a timetable in the railML file, there is possibly the already existing reference from <trainPart> to <speedProfile> and/or a future reference from <vehicle> to <speedProfile>.
Which one should be used?
Can I assume that my railML file is still valid when I have a <trainPart> referencing a <speedProfile> and a <vehicle>, but the vehicle does not reference the <speedProfile>? This should not lead to a conflict.
So, when extending the schemes in the suggested way, please keep in mind clarifying a distinct usage at least in Wiki.
With best regards,
Dirk.
---
Am 08.06.2018 um 14:57 schrieb Torben Brand:
> As I so faar have gotten no feedback from the community I
> will allow me to give a solution suggestgion.
>
> Please add the following new (in blue) optional elements and
> attributes to railML2.4RS:
>
> <vehicle><speedProfileRef>
> @ref="corresponding id in <infrastructure/speedProfile>in
> the same file" of type id and optional
> @name="corresponding name in <infrastructure/speedProfile>in
> another file" of type string and optional
>
> Usually the lowest comon denominator of the combination of
> vehicles will determin the speedProfile of the formation.
> But the formation can also reduce/determin the speedProfile
> in it's own right. Setting the speedProfile in the formation
> is also nessesary when not modelling the wagons as vehicles,
> but as just as increased weight, length and lower speed than
> the vehicle attached. So the same extention must be attached
> under formation.
> <formation><speedProfileRef>
> @ref="corresponding id in <infrastructure/speedProfile> in
> the same file" of type id and optional
> @name="corresponding name in <infrastructure/speedProfile>
> in another file" of type string and optional
>
|
|
|
|
| Re: speedProfile and rolling stock [message #1859 is a reply to message #1836] |
Mon, 02 July 2018 12:26 |
Torben Brand
Messages: 157
Registered: March 2016
|
Senior Member |
|
|
Thank you, Dirk, for valuable input and good questions.
It did not occur to me to consider the timetable schema. As I was just thinking of the capability of the rolling stock. So, thank you for pointing that out to me. As I wrote the extension is meant to describe the speedProfile(s) that the formation or vehicle can run on. Which speedProfile it will run on raises a few more questions. I have grouped these questions in four chapters:
A Hirachy between redundant information in different schemas (this issue)
B Hirachy of the speedprofiles. See reply to issue #368 and ref to issue #1643
C National vs. Generic speed profiles. See also reply to isuse #368 ( https://www.railml.org/forum/index.php?t=msg&goto=526&am p;&srch=speedProfile#msg_526)
D Use of @etcsTrainCategory. See issue #1655 ( https://www.railml.org/forum/index.php?t=msg&goto=1698&a mp;&srch=etcsTrainCategory#msg_1698) and extention suggestion bellow.
A- Hirachy between redundant information in different schemas
I suggest to be the hirachy:
1. If a timetable schema is present/used and the speedProfileRef(s) are defined there: use one of the defined SpeedProfile(s) in the TT. If there are more than one speedProfile defined, see see discussion in chapter B about which one to choose (is defined in infrastructure). The speedProfileRef(s) in the TT should be consistent with part of or all of the same speedProfileRef(s) being present for the same formation or vehicle in the rolling stock schema if written there. If TT refers to a speedProfile that is not refered in in the RS for the same formation the dataset is considered to be in different planning stages and is thus NOT considered invalid.
2. If a timetable schema is NOT present/used or it is present, but the speedProfileRef is NOT defined there and a speedProfileRef is available in rolling stock schema: use one of the defined SpeedProfile(s) in the RS. If there are more than one speedProfile defined, see see discussion in chapter B about which one to choose (is defined in infrastructure).
3. If no TT or RS schema is present/used or none of them contain a speedProfileRef, the correct speedProfile is today not defined/it is unclear which one to be used. This as a default in the infrastructure schema defined SpeedProfiles is not definable today. See discussion in chapter B about which one to choose (is defined in infrastructure).
In general TT taking presedence/detailing further the use of parameters set in RS, seems to be the case for a lot of parameters. Like under <formationTT> you can change the weight, length and speed of a formation. In <equipment> you can turn on or off equipment defined in rolling stock and in <passengerUsage> you can define which places and service are in use. So there seems to be a general rule in railML that timetable can be a more detailed specification of the rolling stock than is defined in the rolling stock schema/railML file. There should be a general definition about this in both the rollingstock wiki and the timetable wiki. I see both descriptions (RS/TT) as optional and if present in both schemas, TT takes precedence. So railML files with timetable/trains/train/trainPartSequence/speedProfileRef is always valid railML independent if rollingStock/formation/speedProfileRef or rollingStock/vehicle/speedProfileRef is set.
As vehicles are approved for one or more specific national speedProfile(s) I suggest to map to those. But in addition to the national mapping we need to do an international mapping as the @etcsTrainCategory has been intorduced (as defined in <speedChange> under <infrastructure> , Should be moved to <speedProfile>). This to know which other speedProfile(s), not specified explicit ly, a train could potentially run under (in another nation for instance). As the @etcsTrainCategory contains all potential categoriues in it's value, the attribute cannot be placed under the specific speedprofiles, but be placed higher in the hirachy as it is valid for all speedprofiles (it defines).
So I extend my extention request to be:
<rollingStock>
<vehicle @etcsTrainCategory="value(s) as defined in issue #1655">
<speedProfileRef @ref="corresponding id in <infrastructure/speedProfile>in the same file" of type id and optional
@name="corresponding name in <infrastructure/speedProfile>in another file" of type string and optional>
<rollingStock>
<formation @etcsTrainCategory="value(s) as defined in issue #1655">
<speedProfileRef @ref="corresponding id in <infrastructure/speedProfile>in the same file" of type id and optional
@name="corresponding name in <infrastructure/speedProfile>in another file" of type string and optional>
If a train can drive on more than one speedProfile map all capable speedprofiles by using multiple <speedProfileRef> elements. See discussion in chapter B about which one to choose (is defined in infrastructure).
See issue #1655 for example based on my suggestion.
|
|
|
|
|
|
|
|
Members
Search
Help
Login
Home
