Home » railML newsgroups » railML.infrastructure » Balise group values for IS:functionalType
Balise group values for IS:functionalType [message #3174] Thu, 14 December 2023 15:16 Go to next message
Terje Nordal is currently offline  Terje Nordal
Messages: 9
Registered: December 2023
Junior Member
Dear railML experts,

I have just recently gotten access to post on the forum, and as requested by the administrators at railML.org I will start my first post with a brief introduction of myself. In the context of railML I represent Bane NOR (part of the railway administration in Norway), working as one of our technical in-house admins for the NRV tool (delivered to us by TrafIT solutions). I work on developing new functionality in the tool, mainly to help our engineers in their day-to-day work and for the tool to process and export data that let's us work with our signalling system suppliers in the best way possible. Other than that I work as a user of the same tool, doing signalling system design and other project related work in that regard, with 10 years of experience from that field.

Moving on to the reason for posting. Referring to https://wiki3.railml.org/wiki/IS:functionalType for balises, several values are possible. In our signalling design we have tried to map our different balise types. So far we have been able to find mapping for four of these, using the values networkRegistration, sessionEstablishment, sessionTermination and announcementLevelTransition. For the case of a level transition scenario, we have an additional two balise functions that we want to map, making a total of three balise functions for a successful level transition implementation.

Our names for these three balise groups are LTA (Level Transition Announcement), which is the one we have already mapped to announcementLevelTransition, LTC (Level Transition Cancellation) and LTO (Level Transition Order). LTC is located in diverging tracks where the Level Transition shall not take place, between the Level Transition Announcement balise group and the signaling system border. It's function is to cancel the transition to another level, in cases where the announcement has already been received by the train. LTO is located at the signaling system border, ordering the transition to the signaling system on the opposite side of the border. I have attached an image to hopefully explain the scenario and functions.

The question is, are there any values in IS:functionalType meant to handle these LTC and LTO balise groups? I have tried reading the value descriptions, but I could not find a perfect match in these cases.
Re: Balise group values for IS:functionalType [message #3182 is a reply to message #3174] Fri, 05 January 2024 13:27 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 465
Registered: January 2016
Senior Member
Dear Terje,

welcome to the railML community and Happy New Year!

The question that you raised concerning the mapping of different ETCS balise group types w.r.t. their functional type, is best being answered by the railML ETCS use case working group. Therefore, I will take this request with me and bring it up in the next ETCS use case working group meeting on January 22, 2024.

From the railML schema perspective, it seems to be a minor change to extend the baliseGroup functional type enumeration list with the missing entries, but maybe there are other ideas as well...

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Balise group values for IS:functionalType [message #3188 is a reply to message #3182] Wed, 31 January 2024 08:32 Go to previous messageGo to next message
Terje Nordal is currently offline  Terje Nordal
Messages: 9
Registered: December 2023
Junior Member
Dear Christian,

Sorry for the late reply on this topic. I understand, from Georg Boasson, that this topic was not discussed on Jan 22. Our input to the topic would be two new possible values for the element IS:functionalType;
- levelTransitionCancellation
- levelTransitionOrder

That way we should be able to handle different scenarios for Level Transition on ETCS lines.

Best regards
Terje
Re: Balise group values for IS:functionalType [message #3193 is a reply to message #3174] Tue, 13 February 2024 09:39 Go to previous messageGo to next message
Georg Boasson is currently offline  Georg Boasson
Messages: 18
Registered: October 2020
Junior Member
Short description of the new values:

LevelTransitionCancellation: This balise group transmit at least UNISIG Packet 41 (Level Transition Order) with immediate transition to level 2. This cancels the announced transition to level STM

LevelTransitionOrder: This balise group transmit at least Packet 41 (Level Transition Order) with immediate transition to level STM.
Re: Balise group values for IS:functionalType [message #3239 is a reply to message #3193] Fri, 03 May 2024 14:58 Go to previous messageGo to next message
Martin Zien is currently offline  Martin Zien
Messages: 14
Registered: December 2021
Junior Member
Dear all,

after alignment with one of our ETCS-experts in the company, I can confirm that the additional attributes make sense.
But we would recommend to introduce slightly different naming to make this matter more definitly:

1. Please replace inside the descriptions the term "STM" by "NTC". ("STM" was valid up to BL 2, is now replaced by "NTC")

2. rename "LevelTransitionCancellation" -> „Level2TransitionOrder"

3. "LevelTransitionOrder" -> „LevelNtcTransitionOrder"

4. Since railML V3.3 should be ready for ETCS L1 too, it would be consequent to introduce a thrid new entry to the enumeration:
"Level1TransitionOrder": This balise group transmits at least Packet 41 (Level Transition Order) with immediate transition to ETCS Level 1.


Please let us know, what you think of this proposal.


Best regards

Martin Zien
Siemens Mobility
Re: Balise group values for IS:functionalType [message #3257 is a reply to message #3239] Fri, 21 June 2024 13:05 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 465
Registered: January 2016
Senior Member
Dear Martin and Terje,

thank you very much for your input. As already indicated at the last railML conference on June 6, 2024, the extension of the baliseGroup functionalType will be implemented with upcoming railML 3.3. I filed a ticket for this issue [1].

[1] https://development.railml.org/railml/version3/-/issues/550

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [raillML3] Mounting information of signals
Next Topic: [railML3] Restricting aggregation of RailTopoModel
Goto Forum:
  


Current Time: Fri Oct 04 13:15:02 CEST 2024