User:RailML Coord Documentation/Tutorial/Interlocking schema of railML 3
Interlocking schema of railML® 3
Overview
The railML interlocking subschema contains definitions of data describing railway signalling and the use of interlocking systems. Interlockings in strict sense are control systems using movable elements, signals, detectors, and other components in combinations and sequences that hinder collision and derailment of trains. Although the entire subschema is called “interlocking” the term “interlocking” is mainly used in this document for the equipment of the interlocking logic.
An interlocking description consists mainly of:
- Track and trackside signalling components,
- Route control logic,
- Interfaces,
- Control system, and
- Controllers.
Each of these categories are described in more detail in sections below.
Modelling Patterns
According to the modelling patterns agreed for railML the domain <interlocking> is divided in the views
These views have containers, except <assetsForIL>, to collect data for objects of same type, i.e. such container cannot be empty if present but can take unlimited number of objects. Similar as the views and containers the majority of elements and attributes for the objects are optional, i.e. they shall be used only if the information is known. The XML feature of default values is not used within railML.
Common Types
The interlocking schema is modelled in UML with Enterprise Architect (EA). The model is designed in that way the tool can directly generate the XSD files. Thus no dependency on third party tools exists except EA.
The XSD generated from UML produces just one global element for the root class in the domain <interlocking>. All other classes/types are used with local elements only. This is known as the Venetian Blind design pattern. Because the majority of elements are not mandatory in the schema the factoring of railML into separate files containing only a small extract from the whole tree is possible. However, any references may be formally not checkable by the schema validator in such cases. The particular use of elements and attributes is to be defined in associated use case descriptions.
Cross-referencing between objects is done through IDIDREF constructs that underlines the importance of unique identifiers. Alternatively the use of UUID for references is also possible. Despite the option to select an arbitrary amount of elements for an XML snippet the data of one project shall be stored within one XML file in normal case having the root <railML> and the domain <interlocking>. There might be other domains present in the same file but this does not affect the following description. At least the <infrastructure> domain is needed for reference targets from <interlocking> elements.
Within the schema the base types as defined in the common module (common3.xsd) are used. In addition two basic types were created for use in interlocking subschema – entityIL and entityILref. They give the elements in the subschema a standard set of features. The first type entityIL gives every derived type the attribute @id and the child element <designator> with the attributes @entry and @register. The common type <designator> is used in railML to allow the attribution of the typical object identifiers of railway world. These designators often use a naming code as defined in the associated register. They can be in normal language but are not having different expressions for one particular object that is dependent on the language. In fact these are a kind of “human readable id”. The mandatory attributes @entry and @register take the particular identifying name and the name of the associated register used. In case there is no officially used register the project-specific one shall be named with a leading underscore. The @id attribute is the “machine readable id” of the item. Although it can make use of the coded name it is not limited to. However, it has to follow the syntax of ID in XML-context.
In addition the type entityIL allows the possibility of user-defined extensions with @anyAttribute and anchors for <any>-Elements. The latter one requires a user-defined namespace with the associated schema provided, i.e. [[IL:{{{2}}}|{{{2}}}]]. The second type entityILref is the counterpart providing just the attribute @ref to point to the @id of another item plus the possibility for @anyAttribute.
Having the possibility for @anyAttribute at almost every element gives one the opportunity to add specially agreed information as bespoken features without violating the railML schema. For additions that are more extensive, the anchors for <any>-Elements are provided. Last but not least some of the enumerations in the domain <interlocking> offer the use of other:… entries.
There is only one additional rule with any-extensions in railML. They shall not be used for information, which can be represented with the features of railML.Simple Example
The learning of the features of the freshly developed railML schema is best with an example using them. This example has to be simple to allow easy manually checks and reviews. With this purpose in mind, a small railway network was designed comprising major railway components. From the graphical version the infrastructure was deducted as XML file. This was the basis for building up a similar XML file with the interlocking features.
The drawing as used for the infrastructure was enhanced by the yellow boxes containing the important ID from the infrastructure elements. The enhancement was purely for convenience as all these ID were needed to use the correct references. Although rather cryptic values could be used as ID a “speaking” style was preferred to not complicate manual work with the example. In later use with software applications the ID could be even UUID or similar.
For developing the interlocking part of the simple example the ID of track assets depictured in the yellow boxes and the names of the TVD sections in the bottom part of the drawing were used. It shall be noted that the picture above is based on v10 of the Simple Example drawing. The changes to the current v11 are not relevant for the interlocking part as described here.
In the following chapters the population of the XML related to the above simple example is explained as step by step description. The document structure follows these steps. However, the simple example does not provide the possibility to include everything what is in the interlocking schema. Thus the aim of the document is also to describe all elements and attributes developed into the schema. It will continue the “railML® 3.1 Tutorial Part1: Infrastructure” without repeating the basics of XML.Syntax Guide
In the text, railML <elements> are put into XML specific brackets <>. railML @attributes can be recognized via the @-symbol before the attribute name. Attribute values are framed by quotation marks.
Source code examples are written in grey boxes:
<railML sourcecode="example">
……
</railML>
Open Issues
Yellow – text not yet finalised
Magenta – text marks future features as open issue