railML3: definition of vehicle [message #2518] |
Tue, 25 August 2020 05:20 |
Joerg von Lingen
Messages: 149 Registered: May 2011
|
Senior Member |
|
|
Dear all,
the existing classification of formation and vehicle is rather loco hauled focused, i.e. clear for a formation with a
locomotive and individual carriages. However, there is uncertainty on how to model one of the various multiple units.
Therefore I suggest the following definition:
A vehicle is one which may consist even of more than one single car body and cannot be split for operational purpose but
only in a workshop or depot.
Thus any multiple unit is one vehicle. In order to get information of its parts for passenger information or reservation
issues we will introduce the <vehiclePart>. Subsequently each vehicle will have at least one vehiclePart.
This proposed concept was already described in the Norway extensions for railML2. Looking on the attached picture one
DMU type 93 will be a single vehicle with two vehicleParts. The combination of two DMU are a formation.
--
Regards,
Jörg von Lingen - Rollingstock Coordinator
|
|
|
Re: railML3: definition of vehicle [message #2524 is a reply to message #2518] |
Wed, 26 August 2020 13:50 |
Dirk Bräuer
Messages: 313 Registered: August 2008
|
Senior Member |
|
|
Dear Jörg,
I agree that the definition "cannot be split for operational purpose but only in a workshop" is practical for vehicles vs. vehicle parts _if_ such a distinction has to be made.
But be careful with the statement "any multiple unit is one vehicle". I could imagine you rather refer to railcars than to the original MUs where the term comes from.
For instance, from your definition the German DB-Baureihe VT 24 (624/634, 614) should be regarded as separated vehicles since they can be split in operation (automatic Scharfenberg couplers also connecting air brake tube and remote control cables). Despite that, I think that many people would regard one set (with two end cars) as one multiple unit.
In general, I think that railML should stay a bit more flexible and leave it to the use case. If passenger information is involved, it may be practical to define such rules. But for instance for rather long-term scenarios, vehicle studies or pure energy calculations, I see no reason why to force users to a certain definition of a vehicle. When we make long-term vehicle scenarios, we often want to make flexible assumptions on possible vehicle combinations such as ICx with 7 vs. 11 parts or ICE1 with 8/12/14 parts etc. We don't define a new vehicle for each assumption; we rather combine "small" vehicles. We do it like the workshop would do it, with an open-end wrench... ;-)
So if you would limit the definition of a vehicle, I'm afraid this could be too much interference into the freedom of users and internal belongings of software tools, leading to low acceptance of railML - or uncontrolled growth usage...
Best regards,
Dirk.
|
|
|