| 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 #3617 is a reply to message #3616] |
Wed, 07 May 2025 13:46  |
Jörg von Lingen
Messages: 102
Registered: March 2016
|
Senior Member |
|
|
Dear Stéphane,
some infrastructure managers have predefined areas which are secured
with special (physical) key locks. Such areas can be modelled in railML
using the <WorkZone> element.
This is the physical locking varaint against the pure logical one as
described below.
On 07.05.2025 13:39, Joerg von Lingen wrote:
> Dear Stéphane,
>
> the use of elments temporarily inhibited for use is a dynamic state
> which the signalling system keeps in the memory. In former (mechanical)
> times a marker plate was put on the lever in order not to operate
> particular elements.
>
> As it is a dynamic state the current state is not part of exchanging
> infrastructure and signalling data. However, it might be considered to
> define special commands per element (<hasCommand>) for setting and
> removing such inhibitions. The set inhibitions are then evaluated by
> interlocking logic when operating the element or setting a route.
>
> Such inhibitions are distinguished as block against moving (= switch
> inhibition), e.g. switching a point machine, or against usage in routes
> (= route inhibition). With the command definitions various marker
> representing the inhibition reason are possible.
>
--
Best regards,
Joerg v. Lingen - Interlocking Coordinator
|
|
|
|
Members
Search
Help
Login
Home
