| Re: need for new element stopingActivity time [message #1963 is a reply to message #1962] |
Sun, 16 September 2018 14:14   |
Joerg von Lingen
Messages: 148
Registered: May 2011
|
Senior 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.
|
|
|
|
Members
Search
Help
Login
Home
