IL:interface

From railML 3 Wiki
Jump to navigation Jump to search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element IL:interface of railML® version 3.3
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..*), elementState (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: the identifier of the object; this can be either of type xs:ID or UUID (obligatory; xs:ID); 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.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

There exists an overview of all changes between railML® 3.1 and railML® 3.2 on page Dev:Changes/3.2.

The children have been changed.

The attributes have been changed.

Changes 3.2→3.3

There exists an overview of all changes between railML® 3.2 and railML® 3.3 on page Dev:Changes/3.3.

The children have been changed.

The attributes have been changed.

Semantics

Best Practice / Examples

Generic I/O-Interface

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.

Sample Interface for NOR Level Crossing

A level crossing is a typical field element with a special interface to the interlocking. Here is the example of a particular level crossing type as used in Norway. The first picture show the signal flow in an overview.

Interface1.png

The signal flow is amended by the detailed list of inputs and outputs whereas input is seen as command to the level crossing side. This is because the interface lists are typically provided by the supplier of the level crossing.


Input Function Normal state Name (Command)
I 14 Remote deactivation, ch.1 NOT active, open circuit Deactivate 1 (C1)
I 15 Remote deactivation, ch.2 NOT active, open circuit Deactivate 2 (C1 / C2 )
I 16 Activation, both directions NOT active, closed circuit Activate (C3)
I 19 Activation direction A NOT active, closed circuit Enable A (C4)
I 20 Activation direction B NOT active, closed circuit Enable B (C5)


Output Function Normal state Name (Message)
O 05 (V) LC not activated, both directions active, closed circuit Opened (M1)
O 06 (SR.W) Train signals cleared NOT active, open circuit Protected (M2)


Finally the detailed list of inputs and outputs are transformed into the equivalent in railML as shown below.

<interface id="int01" invalidTolerationTime="PT0.5S" switchoverTolerationTime="PT0.8S">
        <designator register="_SimpleRegister" entry="Level crossing Norge"/>
        <command bitNr="1" description="Remote deactivation, ch.1" id="I14" normalState="open">
                <designator register="_SimpleRegister" entry="deactivate1"/>
        </command>
        <command bitNr="2" description="Remote deactivation, ch.2" id="I15" normalState="open">
                <designator register="_SimpleRegister" entry="deactivate2"/>
        </command>
        <command bitNr="3" description="Activation, both directions" id="I16" normalState="closed">
                <designator register="_SimpleRegister" entry="activate"/>
        </command>
        <command bitNr="4" description="Activation direction A" id="I19" normalState="closed">
                <designator register="_SimpleRegister" entry="enableA"/>
        </command>
        <command bitNr="5" description="Activation direction B" id="I20" normalState="closed">
                <designator register="_SimpleRegister" entry="enableB"/>
        </command>
        <message bitNr="1" description="LC not activated, both directions" id="O05" normalState="closed">
                <designator register="_SimpleRegister" entry="Opened"/>
        </message>
        <message bitNr="2" description="Train signals cleared" id="O06" normalState="open">
                <designator register="_SimpleRegister" entry="Protected"/>
        </message>
        <initStatus comString="00111" messString="10"/>
</interface>

Interlocking Interface

At the border of one interlocking system’s authority there are interfaces to other interlocking systems for exchange of train control information. For each interlocking it is necessary to define the location of the interface and what particular information is transmitted in which direction. Thus it is important to know from which of the both sides the interface viewed by the interlocking. Otherwise the interfaces would need to be defined twice. The elements and attributes of the physical interface shall be considered according to the view of the interlocking onto the interface, i.e. the value of @isOnCommandSide within the <signalBox> definition.

Interface2.png

The above figure illustrates the situation of an interlocking interface with some information transmitted between both interlocking. The elements and attributes used for description of the interface are:

  • @interfaceLocation – This is the specification of the topological location of the interface. It determines the base type of interface instantiation for the interlocking.
    • inStation – The interface between two interlockings is located in station area and no block routes are related to this interface, i.e. two stations bordering directly to each other without open line in-between.
    • atStationBorder – The interface between two interlockings is located at the border of one station with open line on the other side.
    • onOpenLine – The interface between two interlockings is located on the open line with only block routes related to the interface.
  • @isOnCommandSide – This is flag gives the information how to read the physical interface information.
    • true – If the flag is true then any <command> in the physical interface is a real command for this interlocking.
    • false – If the flag is false then any <message> in the physical interface is a command for this interlocking, i.e. the interface is viewed from the opposite side.
  • <lastOwnTvdSection> – This is the reference to the last TVD section in front of the interface that the interlocking has full control of.
  • <firstRemoteTvdSection> – This is the reference to the first TVD section beyond the interface the interfacing interlocking has full control of but may be notify its status to the interlocking.
  • <incomingRoute> – This is the reference to all routes the interlocking knows that start at the interface location or in rear of it in direction towards the interlocking.
  • <outgoingRoute> – This is the reference to all routes the interlocking knows that end at the interface location or in advance of it in direction towards the other interlocking.
  • <hasInterface> – This is the reference to the description of the physical interface with commands and messages transmitted.

Additional Information

Notes

Open Issues