Home » railML newsgroups » railml.rollingstock » need for new element stopingActivity time (stopingActivity)
need for new element stopingActivity time [message #1961] Fri, 14 September 2018 10:54 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 58
Registered: March 2016
Member
The Norwegian sector has a last request to fill a need for a new element in railML2.4.
Would this be possible to add in railML2.4? If not we need to make an extension for the Norwegian sector.
But as we probably will find further needs later with a subsequent need for an extension, this is not a problem.

New element <stopActivities>

For timetable planning purposes we need to know the minimal technical times for the following stopActivities (I'm using values from the new railML2.4 TT:stopActtivity list for common compliance; https://wiki.railml.org/index.php?title=TT:stopActivity). The list might become longer in the future...

• join: collect motor unit Stärken/Vereinigen
Couple vehicles / train parts - intended for self-propelling train parts. Please consider relation to formations (as far as used)
Vereinigen von Zugteilen vorgesehen für selbstfahrende Zugteile. Zusammenhang zur konkreten Formation beachten (sofern verwendet)
• split: drop motor unit Schwächen/Trennen
Uncouple vehicles / train parts - intended for self-propelling train parts. Please consider relation to formations (as far as used)
Trennen („Flügeln") von Zugteilen vorgesehen für selbstfahrende Zugteile. Zusammenhang zur konkreten Formation beachten (sofern verwendet)
• reverse: Richtungswechsel
Stop to change driving direction of train. Consider relation to @formationReversed
Halt zum Fahrtrichtungswechsel des Zuges. Zusammenhang beachten zu @formationReversed

As mentioned we need the technical times. Not the complete operational. So for a "reverse" the time duration would be from stand still of the train over shut down the drivers cabin for the initial train driver to the time a second train driver in the opposite drivers cabin has initiated the train and is ready for departure. Normal the train driver would walk to the other drivers cabin, but this would be considered an operational time. As the times are technical I suggest to place the element under <vehicle>.

We might consider to add also other variants of the times as well like combinations of "operational" and "maximum" and "average" .
So a possible implementation would look something like this:

<vehicle>
<stopActivities>
<stopActivity
@type=reverse,...(list from TT:StopActivity)
@time=xs:duration (usually in seconds)
@scope="technical", "operational"
@range="minmum","maximum", "average", "median"
@state="planned", "scheduled", "calculated", "measured"

I am a bit uncertain about the correct terms here.
Instead of using @scope="operational" the element could be duplicated under <formation>.
For the time we can skip the attributes @scope, @range @state as we only use the values @scope=technical @range=minimum and @state=planned.

If not implemented the norwegian sector will make the extention:
<vehicle>
<nor:stopActivities>
<nor:stopActivity
@type=reverse,...(list from TT:StopActivity)
@time=xs:duration (usually in seconds)

[Updated on: Fri, 14 September 2018 10:59]

Report message to a moderator

Re: need for new element stopingActivity time [message #1962 is a reply to message #1961] Fri, 14 September 2018 22:28 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 251
Registered: August 2008
Senior Member
No objections from my side.

I agree that it would be fine to have the _technical_ (minimum) times for split/join/reverse of a <vehicle> and possibly a <formation>.

I see some need for clarifications additional to that what Torben already mentioned:

- For join/split, we should make these times independent of the shunting distance (the distance both trains stopped from each other when arriving before a join) and independent from the local interlocking technology (kind of signals, whether the second train stops in front of a flag, a main signal, a shunting signal or simply by the buffers of the train in front). This probably means to encode a theoretical-only time value which must be raised by the shunting and/or interlocking time.

- For reverse, the same applies for the walking time between the two cabs (reversing time must be raised by the walking time in case there is only one driver). But please consider that there may be engines with only one cab (centre cab) where even one driver can simply turn around. So it may be the easiest solution to provide two times (reversing with the same driver, reversing with change of drivers) and set these times equal in case the engine has only one cab. This saves encoding the number of and distance of the cabs.

Concerning @scope and @range, I would like to limit it to "technical" and "minimum" and to avoid "operational", "average" a.s.o. Operational and average times may depend on the local rules, authorities, state, Infrastructure Manager and therefore cannot be given at the <vehicle>. And more, to enumerate too many overlapping values here makes it very difficult to import such railML files in future as one possibly needs a "conversion matrix". So I vote for limiting this only to the really necessary aspects or limit it for certain use cases.

Dirk.
Re: need for new element stopingActivity time [message #1963 is a reply to message #1962] Sun, 16 September 2018 14:14 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 83
Registered: May 2011
Member
Thanks to Dirk and Torben for detailed discussion of the idea.

On the rolling stock side one can only specify technical dependent times as
highlighted by Dirk. However, such times are only useful for formations which
are the technical representation of a train. A formation can even consist of a
single vehicle in case of a EMU/DMU.

1) for join/split the time shall include:
- shutdown of one or both cabs, if needed
- coupling/uncoupling process
- reconfiguration of cab with new train data

2) for reverse the time shall include:
- shutdown of leading cab
- driver transfer to other cab in case of "reverse-one driver"
- startup of now leading cab
In case of a single cab even the shutdown and startup might be unnecessary.

The TT:StopActivity is an enumeration with lot of entries not applicable for use
on rolling stock. Therefore, I would not re-use it here. Instead I suggest an
enumeration with "join", "split", "reverse-one driver", "reverse-two drivers".

Do we need in addition the time needed for a formation to perform cold/warm startup?

Best regards,
Joerg v. Lingen

Rollingstock Coordinator

On 14/09/2018 22:28, Dirk Bräuer wrote:
> I agree that it would be fine to have the _technical_ (minimum) times for split/join/reverse of a <vehicle> and possibly a <formation>.
>
> I see some need for clarifications additional to that what Torben already mentioned:
>
> - For join/split, we should make these times independent of the shunting distance (the distance both trains stopped from each other when arriving before a join) and independent from the local interlocking technology (kind of signals, whether the second train stops in front of a flag, a main signal, a shunting signal or simply by the buffers of the train in front). This probably means to encode a theoretical-only time value which must be raised by the shunting and/or interlocking time.
>
> - For reverse, the same applies for the walking time between the two cabs (reversing time must be raised by the walking time in case there is only one driver). But please consider that there may be engines with only one cab (centre cab) where even one driver can simply turn around. So it may be the easiest solution to provide two times (reversing with the same driver, reversing with change of drivers) and set these times equal in case the engine has only one cab. This saves encoding the number of and distance of the cabs.
>
> Concerning @scope and @range, I would like to limit it to "technical" and "minimum" and to avoid "operational", "average" a.s.o. Operational and average times may depend on the local rules, authorities, state, Infrastructure Manager and therefore cannot be given at the <vehicle>. And more, to enumerate too many overlapping values here makes it very difficult to import such railML files in future as one possibly needs a "conversion matrix". So I vote for limiting this only to the really necessary aspects or limit it for certain use cases.
Re: need for new element stopingActivity time [message #1965 is a reply to message #1962] Sun, 16 September 2018 14:26 Go to previous message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 83
Registered: May 2011
Member
The request was placed in TRAC https://trac.railml.org/ticket/342.

Best regards,
Joerg v. Lingen

Rollingstock Coordinator

On 14/09/2018 22:28, Dirk Bräuer wrote:
> No objections from my side.
>
> I agree that it would be fine to have the _technical_ (minimum) times for split/join/reverse of a <vehicle> and possibly a <formation>.
>
> I see some need for clarifications additional to that what Torben already mentioned:
>
> - For join/split, we should make these times independent of the shunting distance (the distance both trains stopped from each other when arriving before a join) and independent from the local interlocking technology (kind of signals, whether the second train stops in front of a flag, a main signal, a shunting signal or simply by the buffers of the train in front). This probably means to encode a theoretical-only time value which must be raised by the shunting and/or interlocking time.
>
> - For reverse, the same applies for the walking time between the two cabs (reversing time must be raised by the walking time in case there is only one driver). But please consider that there may be engines with only one cab (centre cab) where even one driver can simply turn around. So it may be the easiest solution to provide two times (reversing with the same driver, reversing with change of drivers) and set these times equal in case the engine has only one cab. This saves encoding the number of and distance of the cabs.
>
> Concerning @scope and @range, I would like to limit it to "technical" and "minimum" and to avoid "operational", "average" a.s.o. Operational and average times may depend on the local rules, authorities, state, Infrastructure Manager and therefore cannot be given at the <vehicle>. And more, to enumerate too many overlapping values here makes it very difficult to import such railML files in future as one possibly needs a "conversion matrix". So I vote for limiting this only to the really necessary aspects or limit it for certain use cases.
>
> Dirk.
>
Previous Topic: new values for places and service
Goto Forum:
  


Current Time: Thu Sep 20 23:57:49 CEST 2018