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  |
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  |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
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 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
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: Mandatory braking in front of a steep gradient [message #1542 is a reply to message #517] |
Wed, 05 April 2017 13:56 |
christian.rahmig
Messages: 463
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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
| Re: Mandatory braking in front of a steep gradient [message #1703 is a reply to message #1586] |
Mon, 12 February 2018 14:42 |
christian.rahmig
Messages: 463
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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Goto Forum:
Current Time: Wed Sep 18 09:41:13 CEST 2024
|
Members
Search
Help
Login
Home
