Home » railML newsgroups » railML.infrastructure » [railML3|alpha] Missing track conditions
[railML3|alpha] Missing track conditions [message #1434] Mon, 31 October 2016 14:43 Go to next message
Martin Karlsson is currently offline  Martin Karlsson
Messages: 14
Registered: October 2016
Junior Member
The ETCS language, according to Subset 26 chapter 7, allows sending information to a train about a number of different track conditions. railML does not, in version 3.0.is4, support defining all of these.

railML covers definition of traction power (ETCS packet 39). It can be discussed if the ERA list of traction codes should be used instead of explicitly defining voltage and frequency, but the current way is certainly more informative.

railML also covers the route suitability information (packet 70), i.e. loading gauge profile, max axle load and (again) traction power.

railML is currently missing possibilities to define "big metal masses" (packet 67) and the ten different track conditions of packet 68: three types of non stopping areas, two types of powerless sections, radio hole, air tightness and commands to switch off three types of brakes.

I suggest to add one or more new classes to the "operation" section, to model the missing track conditions.


-------------------------
Martin Karlsson
Bombardier Transportation
Rail Control Solutions
EAPD/ECC
S-405 02 Göteborg, Sweden
Visiting address: Polhemsplatsen 5
Tel.: +46 70 6667615
martinkarlsson(at)railbombardiercom
Re: [railML3|alpha] Missing track conditions [message #1440 is a reply to message #1434] Tue, 08 November 2016 10:26 Go to previous messageGo to next message
Vasco Paul Kolmorgen
Messages: 55
Registered: November 2004
Member
Dear Martin,

thank you for your post and the active and open participation in the railML® 3 development.

Martin Karlsson/SE
The ETCS language, according to Subset 26 chapter 7, allows sending information to a train about a number of different track conditions. railML does not, in version 3.0.is4, support defining all of these.


For the railML 3 development railML.org follows the way of strict use case based modelling. This should ensure that the modelled exchange scheme is maintainable and understandable for the developers and uses (and railML.org coordinators too).
You will find a list of infrastructure use cases in the railML wiki. Even if European Train Control System (ETCS) is in the focus of the railML development for sure, there is no dedicated use case for ETCS up to now defined and on the current focus.
We will integrate the ETCS track conditions if there are well defined requests by the community. We're counting your post as such a request and will discuss this in the IS- and IL-working groups.
We would be very happy if you could define such a use case (take notice of the How to ... please) in the next months.

Martin Karlsson/SE
railML covers definition of traction power (ETCS packet 39). It can be discussed if the ERA list of traction codes should be used instead of explicitly defining voltage and frequency, but the current way is certainly more informative.


Yes, this could be a short time solution.
But if we focus on this ETCS packet 39 only the we're depending of the ERA's list of traction power (and the changes and versioning of this list too!).
What about railways who are not defined in this list like railways with 50 kV voltage or other not defined electric systems?
May be railML.org could predefine a list of most common electric networks which could be translated by the reading and writing programme in this ETCS definition of traction power ID? I will let our scheme coordinators decide about this.

Martin Karlsson/SE
railML also covers the route suitability information (packet 70), i.e. loading gauge profile, max axle load and (again) traction power.


You are right, these elements are essential for any railway usage. But as these values are used outside the ETCS range too (e.g. for route and slot finding procedures or timetabling) we should define them not only inside the ETCS packets. In no case railML.org will model them twice in the railML 3 domain as this will destroy the interoperability of railML data.

Martin Karlsson/SE
railML is currently missing possibilities to define "big metal masses" (packet 67) and the ten different track conditions of packet 68: three types of non stopping areas, two types of powerless sections, radio hole, air tightness and commands to switch off three types of brakes.


Same here as with the electric network IDs. The Non Stopping Areas is one of the oldest tickets in our railML trac system (see Override of the Emergency Brake (de: Notbremsüberbrückung)) but where never modelled as there was no request by the community. We will take them into consideration for railML 3 surely!

Martin Karlsson/SE
I suggest to add one or more new classes to the "operation" section, to model the missing track conditions.


We will add these values for sure, but have to discuss the way of modelling to ensure the maximum interoperable wway for railML® 3 data worldwide. Your and the community support will help us to do so!

Best regards,
--
DI Vasco Paul Kolmorgen
railML.org - Coordinator
Phone: +49-351-47582911
Dresden; Germany www.railml.org
Re: [railML3|alpha] Missing track conditions [message #1441 is a reply to message #1440] Tue, 08 November 2016 15:19 Go to previous message
Martin Karlsson is currently offline  Martin Karlsson
Messages: 14
Registered: October 2016
Junior Member
Thanks for your reply. I will consider to enter a use case when time permits. Just a couple of short comments for now:

About electrification, I think after reading your comment that it is best left as it is. It is fully flexible also outside the ERA list. When it does match a list entry, it can easily be translated.

I agree that data should not be modelled twice. In my opinion, data should be decoupled from the function(s) using it, i.e. there should ideally be no ETCS specific objects. A non stopping area is an operational restriction of interest, regardless if it is realised through an ETCS message, a sign post or a written instruction to the driver.


-------------------------
Martin Karlsson
Bombardier Transportation
Rail Control Solutions
EAPD/ECC
S-405 02 Göteborg, Sweden
Visiting address: Polhemsplatsen 5
Tel.: +46 70 6667615
martinkarlsson(at)railbombardiercom
Previous Topic: [railML3|alpha] Modelling of track conditions
Next Topic: railML 2.3 infrastructure extension for capacity planning and network statement usecases
Goto Forum:
  


Current Time: Thu Mar 28 22:05:12 CET 2024