| Extending IS:functionalType for unique derivation of ETCS balise telegrams (SUBSET-026) [message #4004] |
Mon, 11 May 2026 16:28  |
Lukas Affolter
Messages: 4
Registered: May 2026
|
Junior Member |
|
|
Dear railML community,
Since it is my first post in the railML forum I want to introduce myself.
After studying Electrical Engineering, I worked several years on the development and integration of ETCS On-board Units into rail vehicles. 2019 I joined SBB Infrastructure and worked on ETCS L2 trackside projects. I was involved in system development, testing and monitoring. Between 2024 and 2026 I left SBB to travel around the world.
Since February 2026, I am back at SBB Infrastructure and once again working on ETCS L2 projects. For the new generation of IXL/RBC, SBB intends to use railML when exchanging engineering data with suppliers. This is the field where I am currently active.
We plan to provide the high-level engineering data for ETCS balises in railML format. The balise supplier has to implement the detailed engineering data (production of the balise telegrams in accordance with SRS SUBSET-026). The goal is that the supplier is able to derive all the telegram content clearly and automatically from the high-level engineering data.
With railML3.3, we currently use the element IS:functionalType (https://wiki3.railml.org/wiki/IS:functionalType) to describe the balise functionality. In its current form, this element is unfortunately not sufficient to fully and unambiguously represent the information required for the SUBSET-026 telegrams. In particular, we lack the ability to describe packet or telegram-specific parameters in a structured, standardised manner.
Specific examples of currently missing content that could lead to ambiguity:
- Packet 41: Mandatory information for D_LEVELTR and L_ACKLEVELTR required for Level Transition and Acknowledgement logic is missing.
- Packet 42: The information about the RBC is missing, especially the NID_RBC, NID_C and NID_RADIO, relevant for connecting to the RBC.
- Packet 3 and Packet 203 (National Values): There is no reference to the National Value Set to be used, i.e. which set of configuration to apply.
- Packet 45: The Network ID information (NID_MN) is missing.
These examples show that, in its current form, IS:functionalType is too limited to carry the information needed to create the telegram content in an unambiguous way. As a result, the balise supplier would have to make assumptions or ask questions, increasing the effort and the potential for errors.
Proposal / need for discussion
We would like to suggest extending railML3.3 for balise functionalities such that there is a possibility to model these in a future railML version.
Questions to the community
Are there already existing proposals or extensions in the railML environment that address similar requirements?
What is your current approach to the modelling of specific information for ETCS balises?
In your view, are the specific fields D_LEVELTR, L_ACKLEVELTR (for packet 41), NID_RBC, NID_C, NID_RADIO , Q_SLEEPSESSION (for packet 42), D_VALIDNV, referenceToNationalValuesSet (for packet 3 / 203) and NID_MN (for packet 45) useful additions?
From a practical point of view, what other ETCS packets do you think are necessary engineering data?
Thank you for your feedback and your experiences!
Best regards
Lukas Affolter
SBB AG
Infrastruktur - Netzdesign, Anlagen und Technologien - Bahnsteuerung
Hilfikerstrasse 3, 3000 Bern 65
+41 79 904 77 32
lukasaffolter(at)sbbch / www.sbb.ch
|
|
|
|
| Re: Extending IS:functionalType for unique derivation of ETCS balise telegrams (SUBSET-026) [message #4016 is a reply to message #4004] |
Fri, 22 May 2026 12:56  |
christian.rahmig
Messages: 566
Registered: January 2016
|
Senior Member |
|
|
Dear Lukas,
welcome to the railML community and thanking for your input and requirements for updating the railML balise/baliseGroup model w.r.t. ETCS engineering. I think, that our ETCS use case working group is able and willing to answer your specific questions. Therefore, I suggest, that you bring up this topic in our next ETCS meeting on June 1, 12:30-13:30 CEST. Until then, of course, any feedback from the community is very much appreciated here in the thread, too...
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
Members
Search
Help
Login
Home
