Introduction
Documentation
Syntax
Autoexport from the XML-Schema for element IL:interface of railML ® version 3.2 |
| Documentation
|
Description of a physical interface with definition of the information to be exchanged in which direction.
|
| Subschema
|
interlocking
|
| Parents*
|
interfaces
|
| Children
|
assetName (0..*), belongsToOperationalPoint (0..1), command (0..*), designator (0..*), hasCommand (0..*), hasIndication (0..*), initStatus (0..1), message (0..*)
|
Attributes:
- invalidTolerationTime: The time period for which an invalid status of the received messages is tolerated. (optional;
xs:duration),
- switchoverTolerationTime: The time period for which the received messages are not considered stable due to switching process. (optional;
xs:duration),
- 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:interface of railML ® version 3.1 |
| Documentation
|
Description of a physical interface with definition of the information to be exchanged in which direction.
|
| Subschema
|
interlocking
|
| Parents*
|
interfaces
|
| Children
|
any (0..*), command (0..*), designator (0..1), initStatus (0..1), message (0..*)
|
Attributes:
- invalidTolerationTime: The time period for which an invalid status of the received messages is tolerated. (optional;
xs:duration),
- switchoverTolerationTime: The time period for which the received messages are not considered stable due to switching process. (optional;
xs:duration),
- 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
An interlocking can have several interfaces of different type with field elements and neighbouring interlockings. If the connecting components are from the same supplier, their interfaces to the interlocking do not need to be defined in a special way. Third party components usually have interfaces with rather individual features. Thus it needs to be defined which information is exchanged and in which way to allow a clear description of the interface. The information may be transferred by particular telegrams, bit masks and/or relays. Independent of the physical implementation it ends up with a list of commands/messages send in either direction as well as the related initial status assumed on start-up.
Per definition “commands” is named anything send from the interlocking to the connecting component via the interface, i.e. orders to the field. On the other side “messages” is named anything received at the interface for the interlocking, i.e. notifications from the field.
The interface is described by the following attributes and elements
- @invalidTolerationTime – This is the time an invalid status of commands or messages is tolerated before a failure action is performed.
- @switchoverTolerationTime – This is the time it will take for a command or message to switch over before a stable status is expected.
- <command> – This contains the description of a command send from the interlocking to the field element.
- @bitNr – This is the order number of the command in the list. In case of transmission as complete bitmask it defines the bit position in the byte.
- @description – This is just the description/meaning of the command send.
- @normalState – This gives the normal state of the command when not energised. The values are derived from relay contacts. Thus open means open contact, inactive command state or false depending on the particular technology. In contrast closed stands for a closed contact, an active command state or true.
- @pulseDuration – This is the time for the related command being in the reverse state if no permanent switchover is done.
- <message> – This contains the description of a message received by the interlocking from the field element. The attributes are the same as for a <command>.
- <initStatus> – This is the description of the interface status in command and message direction which is assumed in start-up cases, i.e. when both sides of the system are just powered up.
- @comString – The states of the single commands are represented within one bitmask string. Their order is related to the @bitNr defined in the command description. The allowed values within the string are 0 for inactive command, 1 for active command and x for command does not matter.
- @messString – This is the representation of the single messages status. The use is the same as for the @comString.
Additional Information
Notes
Open Issues