| Track and switch locks (Befahrbarkeitssperren) [message #3606] |
Wed, 30 April 2025 10:29  |
Stéphane Kaloustian
Messages: 8
Registered: September 2024
|
Junior Member |
|
|
Dear IL specialists
According to swiss railway regulations, the signalling system must be able to prevent the setting of routes over "non-passable" track sections. Track sections may be "non-passable" due to ongoing maintenance work, defective equipment, accidents, or local natural disasters, for example. For this purpose, in Switzerland, appropriate track and switch locks are planned in the interlocking or control system's engineering data. Track and switch locks only exist in the interlocking and in the control system; no physical elements are used for track locking. Those track and switch locks are used by the dispatcher to selectively prevent route settings (preventing signal movement) over tracks and switches. They are also used to provide local control to the railway staff in case of maintenance for example.
We distinguish between six different types of track and switch locks. These differ in their impact on the train routes, some relate only to shunting routes, others only to train routes, for example.
Modeling in railML
In a broader sense, one could imagine using the keyLockIL element (railML3.x), without reference to a physical keyLockIS for this purpose. However, this element refers to a key, which doesn't exist in our use case. Because all attributes and child elements are optional, modeling with the keyLockIL element is conceivable in principle. The child element takesControlOf could be used to reference the corresponding element (track/switch) in the interlocking subschema.
Hoewever, regarding the different types of track and switch locks, the question arises, how the types should be represented. Since the child element typeDesignator can only be used in the keyLockIS element, it can not be used in this case. But it might be conceivable that the different types could be represented in the @function attribute.
From the community's point of view, would it be possible to use the keyLockIL element for the described use case, or would another element - probably derived from rail3:LogicalDevice - have to be defined?
Kind regards
Xenia Augustin, Silvan Gruber and Stéphane Kaloustian
SBB Swiss Railways
|
|
|
|
|
|
|
|
| Re: Track and switch locks (Befahrbarkeitssperren) [message #3925 is a reply to message #3617] |
Mon, 09 March 2026 05:21  |
Jörg von Lingen
Messages: 123
Registered: March 2016
|
Senior Member |
|
|
Dear all,
in railML3.4 there will be a new element <hasInhibitionType> in <specificInfrastructureManager>. This will allow the definition of general inhibition types for this IM with name, markerText, type and reference list to route types it will be valid for. At track sections, switches and signals a reference list to the possible inhibition types is possible.
It is also thought of a reference to valid train categories in case one will define inhibitions to be applied only for selected train categories. However, this not yet completely finalised. Are there needs from your side to have such inhibitions and what would be the related data?
An extract from schema is attached.
--
Best regards,
Joerg v. Lingen - Interlocking Coordinator
|
|
|
|
Members
Search
Help
Login
Home
