IL:genericDetector

From railML 3 Wiki
Jump to navigation Jump to search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element IL:genericDetector of railML® version 3.2
Documentation Device for detecting the exceeding of a particular characteristic.
Subschema interlocking
Parents* genericDetectors
Children assetName (0..*), belongsToOperationalPoint (0..1), designator (0..*), detectorType (1..1), hasCommand (0..*), hasIndication (0..*), hasInterface (0..1), refersTo (0..1), takesControlOf (0..*)
Attributes:
  • affectsRouteSignalling: indication whether the signalling of a related route is affected by the detector status (optional; xs:boolean),

  • allowsPermanentOverride: The detector output may be permanently overridden by special command. (optional; xs:boolean),

  • allowsSingleOverride: The detector output may be overridden once by special command. (optional; xs:boolean),

  • hasTriggeredSelfTest: The detector may have a self-test which is to be triggered from the interlocking. (optional; xs:boolean),

  • selfTestInterval: The interval at which the self-test is running, i.e. automatically initiated or triggered from interlocking. (optional; xs:duration),

  • selfTestToleranceTime: The time period for which the detector output shall be tolerated due to running self-test. (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:genericDetector of railML® version 3.1
Documentation Device for detecting the exceeding of a particular characteristic.
Subschema interlocking
Parents* genericDetectors
Children any (0..*), designator (0..1), detectorType (1..1), hasInterface (0..1), refersTo (0..1), takesControlOf (0..*)
Attributes:
  • affectsRouteSignalling: indication whether the signalling of a related route is affected by the detector status (optional; xs:boolean),

  • allowsSingleOverride: The detector output may be overridden once by special command. (optional; xs:boolean),

  • allowsPermanentOverride: The detector output may be permanently overridden by special command. (optional; xs:boolean),

  • hasTriggeredSelfTest: The detector may have a self-test which is to be triggered from the interlocking. (optional; xs:boolean),

  • selfTestToleranceTime: The time period for which the detector output shall be tolerated due to running self-test. (optional; xs:duration),

  • selfTestInterval: The interval at which the self-test is running, i.e. automatically initiated or triggered from interlocking. (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.

Semantics

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.
 

Detectors are devices that check for exceeding a particular characteristic and providing an output to the interlocking. Depending on the function it may influence the route signalling. The base types of such detectors are defined in the IM dependent section 1.13.

Independent of the particular detector type it can be described by the following attributes:

  • @affectsRouteSignalling – The Boolean value gives indication whether this detector is safety critical and its output influences the train routes.
  • @allowsSingleOverride – The Boolean value defines whether the particular command for single override shall be provided by the interlocking for this detector.
  • @allowsPermanentOverride – The Boolean value defines whether the particular commands for enabling and disabling of override shall be provided by the interlocking for this detector.
  • @hasTriggeredSelfTest – The Boolean value defines whether the interlocking needs to trigger a self-test of this detector in order to check its correct working.
  • @selfTestToleranceTime – The duration gives the time the self-test needs to run and any outputs from the detector during it shall be tolerated.
  • @selfTestInterval – The duration value gives the time interval at which the interlocking needs to trigger the self-test of the detector. It has to be used in combination with @triggeredSelfTest.
  • <detectorType> – This is the reference to the particular type of the detector.

Additional Information

Notes

Open Issues