| Re: Orientation of baliseGroup and validity direction of balise telegrams [message #3773 is a reply to message #3690] |
Mon, 27 October 2025 23:49   |
Karl-Friedemann Jerosch
Messages: 13
Registered: May 2020
|
Junior Member |
|
|
Dear Silvan,
thank you very much for the reported problems and suggested improvements.
Balise Group orientation
I recommend to implement proposal 1.) in the next railML version 3.4 which means:
- deletion of "baliseGroup@mileageDirection"
- update of the documentation in the xsd and wiki according to the provided explanation in 1.) for attribute @applicationDirection
By this, the balise group orientation is defined only in relation to the netElement orientation and avoid the inconsistencies described under 2.).
ETCS Packet Validity Direction
The optional element "functionalType" belonging to "baliseGroup" was defined to give information about the function(s) fulfilled by the balise group.
A balise group function requires usually the transmission of one specific ETCS packet (or a set of ETCS packets) by this balise group.
The validity direction of ETCS packets (given by the UNISIG variable Q_DIR) refers to the orientation of the balise group.
As the existing attribute "functionalType@mileageDirection" provides the values "nominal" or "reverse", but not the value "both",
I would recommend to create a new attribute (for example named "validityDirection") with the values "nominal", "reverse" and "both" (according to UNISIG SUBSET-026, section 7.5.1.103),
which shall substitute the attribute "functionalType@mileageDirection".
By this, the problem described in 3.) should be solved.
To be in line with SUBSET-026, the new attribute "functionalType@validityDirection" should refer to the balise group orientation as shown in the figure presented by Silvan (and should not refer to the netElement orientation).
kind regards
Karl Jerosch
|
|
|
|
Members
Search
Help
Login
Home
