| 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
|
|
|
|
Members
Search
Help
Login
Home
