Home » railML newsgroups » railML.infrastructure » More detailed 'speed change' definitions
| Re: More detailed 'speed change' definitions [message #279 is a reply to message #278] |
Mon, 23 January 2012 17:02   |
Carsten Weber
Messages: 27
Registered: November 2011
|
Junior Member |
|
|
Hi,
"Susanne Wunsch" <coord(at)commonrailmlorg> schrieb im Newsbeitrag
news:bb2ty3ztd6efsf(at)remiheepsaxde...
> Hi,
>
> The current thread evolves to some really fundamental discussion about
> future infrastructure (track layout) definitions in railML.
>
> Anybody who already uses railML infrastructure or plans to implement
> it, please feel personally invited for taking part in this
> discussion. Any questions, comments, opinions are highly appreciated.
>
It seems to be a dialque and not a discussion. :/
> "Carsten Weber" <weber(at)irfpde> writes:
>> "Susanne Wunsch" <coord(at)commonrailmlorg> schrieb im Newsbeitrag
>> news:bb28vlg7rymfsf(at)remiheepsaxde...
>>> Hi Carsten, and all who are interested,
>>>
>>> "Carsten Weber" <weber(at)irfpde> writes:
>>>> "Susanne Wunsch" <coord(at)commonrailmlorg> schrieb im Newsbeitrag
>>>> news:bb2ty4a74xnfsf(at)remiheepsaxde...
>>>> > "Carsten Weber" <weber(at)irfpde> writes:
>>>
>>> If your track may be operated in both directions - yes. I try to put a
>>> small example here, hope it helps.
>>>
>>> <speedChange pos="10" dir="up" vMax="40"/>
>>> <speedChange pos="10" dir="down" vMax="60"/>
>>> <speedChange pos="200" dir="both" vMax="80"/>
>>>
>>> pos 10 200
>>> track dir ------------------------------------------------------------ >
>>> vMax -> 40-> 80->
>>> vMax <- <-? <-60 <-80
>>>
>>> The <speedChange> information defines the maximum speed aspect for the
>>> next track section, means up to the next <speedChange> element in the
>>> track definition direction. A <speedChange> for both directions means,
>>> that the speed aspect at the next track section is the same for both
>>> train running directions. It is _not meant_ to be the same speed aspect
>>> from this point in both directions - that is really misleading!
>>>
>> So it becomes tricky to use this structure.
>
> Yes. That may be current practice.
>
> Nevertheless I asked some current railML IS user for their current
> practice and opinion about the above issue. Most of them appreciated a
> clearer structure without the possibility to define speed aspects for
> both directions changing at a certain "point". That's really too much
> confusing.
>
> If nobody disagrees with good reasons I would file a Track ticket for
> "deprecating" the "both" enumeration value from the "dir" attribute in
> all "*Change" elements.
>
> New or already used practice is to define seperate elements for each
> running direction. The above example would be:
>
> <speedChange pos="10" dir="up" vMax="40"/>
> <speedChange pos="200" dir="up" vMax="80"/>
> <speedChange pos="2xx" dir="down" vMax="80"/>
> <speedChange pos="200" dir="down" vMax="60"/>
>
> That means that the semantic for the same XML content changes. That is a
> very hard cut that can't be recognized by any parser!
>
It is a question of your position. Do I have to combine two speed
restrictions which are shown at the same position to differnt dircetions
into one element? I do not think so. So I can keep both of them in two
elements and do not do any mistake in RailML-useage. So for me the cut looks
not so heavy.
[...]
>>> If you have a speed restriction along a bridge, you may define different
>>> <speedChange> elements in each direction refering to the same speed
>>> profile with different speed aspects. The <speedChange> elements already
>>> need the direction attribute. Why do we need to duplicate it?
>>>
>>
>> Because of more clearance.
>> In my sight a speedChange should be a child of a speedProfile.
>> <speedProfile direction="up" ...>
>> <speedChange position="0" speed="60" .../>
>> <speedChange position="5" speed="120" .../>
>> <speedChange position="123" speed="100" .../>
>> <.../>
>> </speedProfile>
>>
>> So you can see: the speedChanges if you run the track in one direction in
>> a
>> line.
>> But this structure requires a break in downward compatibility which is
>> not
>> leagl at the moment.
>
> The compatibility break is only one side effect of the above mentioned
> example. Another aspect is that speed profiles are much more general
> definitions than the detailed speed changes along the tracks.
>
> You may define some speed profiles for different axle weights that are
> referenced at multiple tracks. If you would define these speed profiles
> at each track you get heavy redundancies and may "lose track of the big
> picture".
>
> What's the difference between these two approaches from the timetable
> point of view?
>
> Let's define a train (part sequence) that goes along three tracks
> deploying two speed profiles.
>
> (pos) 0 150 345 468 768 1035
> track t1-> t2-> t3->
> vMax sp1 80-> 80-> 80->
> vMax sp2 40-> 40-> 40-> end
>
> That means the train (part sequence) deploying both speed profiles is
> restricted to the following speed profile:
>
> (pos) 0 150 345 468 768 1035
> vMax 80->40-> 40-> 40-> 80->
>
> Now let's have a look at your approach (how I understood):
>
> <track id="t1">
> <trackTopology>...(pos=0..345)
> <trackElements>
> <speedProfile id="sp1" description="Default" dir="up"
> influence="increasing">
> <speedChange id="sc1" pos="0" vMax="80"/>
> </speedProfile>
> <speedProfile id="sp2" description="temporary restriction" dir="up"
> influence="reducing">
> <speedChange id="sc2" pos="150" vMax="40"/>
> </speedProfile>
> </trackElements>
> </track>
> <track id="t2">
> <trackTopology>...(pos=0..123)
> <trackElements>
> <speedProfile id="sp3" description="Default" dir="up"
> influence="increasing">
> <speedChange id="sc3" pos="0" vMax="80"/>
> </speedProfile>
> <speedProfile id="sp4" description="temporary restriction" dir="up"
> influence="reducing">
> <speedChange id="sc4" pos="0" vMax="40"/>
> </speedProfile>
> </trackElements>
> </track>
> <track id="t3">
> <trackTopology>...(pos="0..567)
> <trackElements>
> <speedProfile id="sp5" description="Default" dir="up"
> influence="increasing">
> <speedChange id="sc5" pos="0" vMax="80"/>
> </speedProfile>
> <speedProfile id="sp6" description="temporary restriction" dir="up"
> influence="reducing">
> <speedChange id="sc6" pos="0" vMax="40"/>
> <speedChange id="sc7" pos="300" vMax="end"/>
> </speedProfile>
> </trackElements>
> </track>
>
> Reference from within the timetable:
>
> <trainPartSequence>
> <trainPartRef ref="tp1"/>
> <trainPartRef ref="tp2"/>
> <trainPartRef ref="tp3"/>
> <speedProfileRef ref="sp1"/>
> <speedProfileRef ref="sp2"/>
> <speedProfileRef ref="sp3"/>
> <speedProfileRef ref="sp4"/>
> <speedProfileRef ref="sp5"/>
> <speedProfileRef ref="sp6"/>
> </trainPartSequence>
>
> <trainPart id="tp1">
> ...
> <sectionTT>
> <trackRef ref="t1" dir="up"/>
> ...
> <trainPart id="tp2">
> ...
> <sectionTT>
> <trackRef ref="t2" dir="up"/>
> ...
> <trainPart id="tp3">
> ...
> <sectionTT>
> <trackRef ref="t3" dir="up"/>
>
> Now let's have a look at my approach:
>
> <speedProfile id="sp1" description="Default" influence="increasing"/>
> <speedProfile id="sp2" description="temporary restriction"
> influence="reducing"/>
> ...
> <track id="t1">
> <trackTopology>...(pos=0..345)
> <trackElements>
> <speedChange id="sc1" pos="0" dir="up" profileRef="sp1" vMax="80"/>
> <speedChange id="sc2" pos="150" dir="up" profileRef="sp2" vMax="40"/>
> </trackElements>
> </track>
> <track id="t2">
> <trackTopology>...(pos=0..123)
> <trackElements>
> <speedChange id="sc3" pos="0" dir="up" profileRef="sp1" vMax="80"/>
> <speedChange id="sc4" pos="0" dir="up" profileRef="sp2" vMax="40"/>
> </trackElements>
> </track>
> <track id="t3">
> <trackTopology>...(pos="0..567)
> <trackElements>
> <speedChange id="sc5" pos="0" dir="up" profileRef="sp1" vMax="80"/>
> <speedChange id="sc6" pos="0" dir="up" profileRef="sp2" vMax="40"/>
> <speedChange id="sc7" pos="300" dir="up" profileRef="sp2"
> vMax="end"/>
> </trackElements>
> </track>
>
> Suppose the following reference from within the timetable.
>
> <trainPartSequence>
> <trainPartRef ref="tp1"/>
> <trainPartRef ref="tp2"/>
> <trainPartRef ref="tp3"/>
> <speedProfileRef ref="sp1"/>
> <speedProfileRef ref="sp2"/>
> </trainPartSequence>
>
> The <trainPart>... definitions are the same as in your approach.
>
Ok. Now I understand. Your approach looks quite heavy. So the exclusion of
common information is quite good if you have a lot of information the
exclude but I think this does not appear in this situation.
[...]
>>> 0° .. 3.4° 80 km/h
>>> 3.5° .. 5.4° 90 km/h
>>> 5.5° .. 8° 100 km/h
>>>
>> Yes. So you would have to define 3 different speed profiles. A speed
>> profile
>> without any data to tiliting or a tilting angle of "0", a second one with
>> tilting angles higher than 3.5° and a third one for tilting angles higher
>> than 5.5°.
>
> If that definition satifies all needs of railML users - let's do it this
> way. Prior to fixing this issue to your clarification I would like to
> ask for some Swiss, Austrian... experiences with tilting speed profiles.
>
Ok. Let me know the answer(s).
>>>> >> <xs:element name="tiltingSpeed" minOccurs="0" maxOccurs="1">
>>>> >> <xs:annotation>
>>>> >> <xs:documentation>Tilting parameters for which this speed
>>>> >> profile
>>>> >> is
>>>> >> calculated.</xs:documentation>
>>>> >> </xs:annotation>
>>>> >> </xs:element>
>>>> >
>>>> > The terminus "speed" may be a bit misleading. I suppose, that is not
>>>> > related to the "train speed" but to the "rate/speed of tilting", that
>>>> > means the value of tilting degrees per second. I would call this
>>>> > attribute "rate". Are there any other ideas?
>>>> >
>>>> > This attribute may be bound to the railML type
>>>> > "tSpeedDegreesPerSecond".
>>>> >
>>>> > There is another kind of information related to the tilting that comes
>>>> > to my mind: the method of tilting. It could go into an attribute
>>>> > "method" that is bound to an enumeration of "active", "passive",
>>>> > "rollCompensation", "unknown", "other:anything".
>>>> >
>>>> I know this. But is it really important here? Do I need to know which
>>>> way
>>>> the vehicle tilts?
>>>
>>> I thought that it is another type of speed restriction. If you go with
>>> "roll compensation" you may increase your speed, if you support "active
>>> tilting", you have to switch the system off and go with default speed
>>> aspect. This may be a Swiss use case, I mean.
>>>
>> Yes and no. So you need a speed profile for tilting angles up to 2° (or
>> something like that) and you may have a second one for higher tilting
>> angles. So if your vehicle is only able to do a tilting up to 2° you can
>> only run the "slow" profile. The way you reach the tilting angle is not
>> really important. It is more a question of the tilting speed but it is
>> also
>> not important there.
>
> Are there any different speed profiles for the same tilting angle
> depending on the tilting method?
>
I do not think so. But maybe anybody else has an opposite example.
>>>> By the way: We need to define an "endOfSpeedList". So for example if
>>>> you
>>>> have to run slow with a train e.g. above a bridge the allowed speed
>>>> goes
>>>> back to track speed after you left the bridge. So you need an option to
>>>> say:
>>>> the speed profile ends here. Other speed profiles are now in progress.
>>>> So
>>>> you can use speed profiles along the whole train run but they have one
>>>> one
>>>> speed limitation at a short bridge or something like this.
>>>
>>> No, that use case is covered by allowing multiple speed profiles that
>>> overlap each other. The software export has to ensure that there are
>>> valid speed definitions for all sections of the track.
>>>
>> This maybe a missunderstanding.
>> For example the bridge with there speed limit. So you define a
>> speedProfile
>> for a high axleLoad or something like this and say at the beginning of
>> the
>> bridge: maxSpeed="60". So what do you write at the end of the bridge
>> where
>> the speed raises up to a minimum of all the other speedProfiles?
>
> +1
>
> I really missed this issue. We need some "end of speed restriction"
> indication. That may be defined as additional fixed string allowed for
> the "vMax" attribute, e.g.
>
> <speedChange id="sc7" pos="300" dir="up" profileRef="sp2" vMax="end"/>
>
Yes, sSomething like this.
So it can be mixed up with another speed information.
When will the preview be available?
Best regards.
|
|
|
|
Current Time: Thu Apr 25 12:03:46 CEST 2024
|
Members
Search
Help
Login
Home
