| [railML3.4] References between RBC and Balises [message #4141] |
Tue, 01 September 2026 04:51  |
Jörg von Lingen
Messages: 126
Registered: March 2016
|
Senior Member |
|
|
Dear all,
at the moment we have the RBC in IL domain with element
<containsTrackAsset> to refer to the elements known to the RBC. However,
this reference would be only to track assets in IL domain like signals,
tracks or switches.
On the other side we have the balises only in IS domain as there is
normally no direct/physical connection to an interlocking or RBC. For
switchable balises the connection is via LEU.
The RBC shall also know all related balises. Thus there have to be a
reference element in RBC. I see two possible ways to realise this.
1. We introduce a balise element in IL domain as track asset. Then we
can refer from RBC using <containsTrackAsset>. However, this would arise
the question what functional data we currently have in IS:balise shall
be transferred to IL:balise.
2. We introduce an additional element <containsBalise> with reference to
any IS:balise.
Please give me your opinion which solution you would prefer.
--
Best regards,
Joerg v. Lingen - Interlocking Coordinator
Dr. Jörg von Lingen – Interlocking schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
| Re: [railML3.4] References between RBC and Balises [message #4202 is a reply to message #4141] |
Mon, 21 September 2026 13:07  |
Silvan Gruber
Messages: 14
Registered: July 2024
|
Junior Member |
|
|
Dear all,
from SBB's point of view, we do not see the need to introduce a new dedicated element for referencing balises or balise groups, such as <containsBalise> or <containsBaliseGroup>.
We already use the element IL:containedTrackAssets for this purpose, listing all elements that are known to the RBC. In our opinion, this reference list should not be restricted to elements from the interlocking subschema.
An RBC does not only need to know classical interlocking objects such as signals, switches or track sections. It also needs information from the infrastructure subschema, for example:
- baliseGroups
- gradientCurves
- speedSections
- etcsLevelTransitions
- restrictionAreas
- and other ETCS- or line-related infrastructure information.
These elements are relevant for the RBC, for example for calculating and supervising Movement Authorities, speed profiles, level transitions or restriction areas. Therefore, they should also be referenceable via containedTrackAssets.
We do not understand why containedTrackAssets should be restricted to elements from the IL subschema. The relevant criterion should not be whether the referenced object is defined in the interlocking or infrastructure subschema, but whether this object has to be known by the RBC.
If the term containedTrackAssets is considered too narrow, we would rather suggest broadening/generalising the allowed reference targets instead of introducing new dedicated reference elements for individual object types such as balises or balise groups.
In short:
No new specific element for balises/balise groups is needed. Instead, containedTrackAssets should be open to all RBC-relevant objects, including objects from the infrastructure subschema.
Best regards
Silvan
|
|
|
|
Search
Help
Members
Login
Home
