IL:keyLockIL

Documentation

Syntax

Autoexport from the XML-Schema for element IL:keyLockIL of railML® version 3.2 UML-visualization of IL
Documentation	A device for locking a key which is released from interlocking or by using a master key.
Subschema	interlocking
Parents*	keyLocksIL
Children	acceptsKey (0..1), assetName (0..*), belongsToOperationalPoint (0..1), designator (0..*), hasCommand (0..*), hasIndication (0..*), hasInterface (0..1), hasSlaveLock (0..*), hasTvdSection (0..1), refersTo (0..1), takesControlOf (0..*)
Attributes: function: The functional element the keylock is controlling. (optional; xs:string; patterns: other:w{2,}) Possible values: handThrownSwitch: The key lock is used to control the position of a manually operated switch within a station sidingProtection: The key lock is used to control the position of a manually operated switch used to enter a siding from the open line. workZone: The key lock is used to control the status of a work zone., hasAutomaticKeyLock: The key may be automatically relocked when returned into the lock. Thus the key can be used only once. (optional; xs:boolean), hasAutomaticKeyRelease: The key of a siding on open line may be released automatically when the related TVD section (trigger) becomes occupied. (optional; xs:boolean), keyAuthoriseTime: The time period the key release is active after commanded by the operator. Afterwards a not removed key will be automatically relocked again. (optional; xs:duration), keyRequestTime: The time period a request for key release is indicated to the operator. (optional; xs:duration), description: Description of the logic. (optional; xs:string), elementNumber: element number for internal referencing in the engineering data (optional; xs:nonNegativeInteger), id: unique identifier (obligatory; xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.

Autoexport from the XML-Schema for element IL:keyLockIL of railML® version 3.1 UML-visualization of IL
Documentation	A device for locking a key which is released from interlocking or by using a master key.
Subschema	interlocking
Parents*	keyLocksIL
Children	acceptsKey (0..1), any (0..*), designator (0..1), hasInterface (0..1), hasSlaveLock (0..*), hasTvdSection (0..1), refersTo (0..1), takesControlOf (0..*)
Attributes: hasAutomaticKeyRelease: The key of a siding on open line may be released automatically when the related TVD section (trigger) becomes occupied. (optional; xs:boolean), hasAutomaticKeyLock: The key may be automatically relocked when returned into the lock. Thus the key can be used only once. (optional; xs:boolean), keyRequestTime: The time period a request for key release is indicated to the operator. (optional; xs:duration), keyAuthoriseTime: The time period the key release is active after commanded by the operator. Afterwards a not removed key will be automatically relocked again. (optional; xs:duration), description: Description of the logic. (optional; xs:string), id: unique identifier (optional; xs:ID; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.

Changes 3.1→3.2

The children have changed.

The attributes have been changed.

Best Practice / Examples

🗒️ There can be various logical devices like <keyLockIL> and <genericDetector>, which provide their state as input to the interlocking. Depending on their use it is also possible to send particular information from the interlocking to the logical device in order to provoke a specific reaction. It is an abstract class extended by the particular instances of it like keyLockIL or genericDetector. The common attributes and elements are: @elementNumber - A positive integer number unique within one <signalBox> to index the element in internal lists of engineering data. @id - The unique identifier used to reference this element within railML. @description – The string element takes a more detailed description of the logic. This is for information of the user only. <designator> - A coded name as per a specified register for the asset. <assetName> - A name for the asset in a given language. <belongsToOperationalPoint> - The reference to an <operationalPoint> this device belongs to from operational point of view. <hasCommand> - The reference to any predefined operator command, which can be used with this element. For details refer to <hasOperatorCommand>. <hasIndication> - The reference to any predefined indication on HMI, which is used with this element. For details refer to <hasHmiIndication>. <takesControlOf> – This is the reference to a movable element which can be controlled with the lock. In case of a detector, it is used as reference to any track asset, which is related to the logical device. <hasInterface> – The reference to the physical interface of the logical device to the interlocking. For details refer to <interface>. <refersTo> - The reference to the physical device like <keyLockIS> in the infrastructure. This element is optional as some detectors may not have a corresponding element in the infrastructure because they are not located at the track. The particular instantiation extends the abstract type of logicalDevice by some additional elements and attributes. There are further logical devices conceivable. Currently the <movableBridge> is implemented using this abstract class.

A key lock (de: Schlüsselschalter) is a mechanical device often electrically controlled from the interlocking. It is situated near the track and can have two basic positions. One of them is the key securely locked in and the other with the key released for removal. The key is a simple mean of authorisation transfer as its use allows the manual operation of a moveable element. The lock with control from the interlocking is called master lock, whereas the other locks being operable by the released key are the slave locks.

A key lock is used to request local control of a (group of) track assets from the interlocking without the need of expensive machines and control stuff. Commonly, railway staff requests local control from the interlocking via this device. Once granted, the key can be removed upon which the (group of) track asset is no longer under interlocking control. In reverse, the interlocking takes back control when the key is inserted and the staff acknowledged relinquishing control.

Note that the lock is a track asset defined in infrastructure namespace. The interlocking reads the state of the lock and returns permission to remove the key, i.e. levelOfControl=fullControl.

A combined lock has a master lock that controls a set of slave locks that can be operated with the key from the master lock but are not connected to the interlocking. Slave locks may have to be released in a well-defined sequence.

The master lock is a key release element that is operated directly from the interlocking. The key is electrically locked and released on operator command or trigger event from the interlocking. These locks are typically used for movable elements in route path, which are not operated directly from the interlocking like siding switches on open line or tunnel gates or bascule bridges.

The key lock is defined by the following attributes and elements:

• @hasAutomaticKeyRelease – The flag specifies whether the key shall be released (authorised) automatically when a triggering event occurs. This is used for key locks on open line for automatically release the key when the related TVD section is occupied, i.e. when the train arrives at the entry to the siding.
• @hasAutomaticKeyLock – The flag specifies whether the key shall be locked automatically when it is returned into the lock, i.e. only one time use is permitted.
• @keyRequestTime – The timer value for automatically revocation of the key request, i.e. the indication to the controller for key release request is automatically removed if not answered (key release commanded) in-between.
• @keyAuthoriseTime – The timer value for automatically revocation of the key release, i.e. the key is automatically relocked if not taken out in-between.
• <acceptsKey> – This is the reference to a key.
• <hasTvdSection> – This is the reference to a TVD section the lock might be related to. This is especially relevant for sidings with key lock on the open line where the key is released on occupation of the related TVD section in combination with a special route type.

• <hasSlaveLock> - This is the reference to any dependent lock that can be used once this master lock is released.