Introduction
Documentation
Syntax
Autoexport from the XML-Schema for element IL:interlocking of railML ® version 3.3 |
| Documentation
|
root element for railML3 interlocking model
|
| Subschema
|
interlocking
|
| Parents*
|
railML
|
| Children
|
assetsForInterlockings (0..1), controllers (0..1), objectControllers (0..1), radioBlockCentres (0..1), signalBoxes (0..1), specificInfrastructureManagers (0..1)
|
| Attributes:None
|
*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:interlocking of railML ® version 3.2 |
| Documentation
|
root element for railML3 interlocking model
|
| Subschema
|
interlocking
|
| Parents*
|
railML
|
| Children
|
assetsForInterlockings (0..1), controllers (0..1), radioBlockCentres (0..1), signalBoxes (0..1), specificInfrastructureManagers (0..1)
|
| Attributes:None
|
*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:interlocking of railML ® version 3.1 |
| Documentation
|
root element for railML3 interlocking model
|
| Subschema
|
interlocking
|
| Parents*
|
railML
|
| Children
|
assetsForIL (0..1), controllers (0..1), signalBoxes (0..1), specificIMs (0..1)
|
| Attributes:None
|
*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.
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.
Semantics
Best Practice / Examples
Additional Information
Notes
The railML interlocking subschema contains definitions of data describing railway signalling and the use of interlocking systems. There are lot of different objects which will appear in infrastructure and interlocking. As a rule all physical characteristics, which can be "touched" are in infrastructure. All things about function and usage from train control point of view are in interlocking. 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.
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.
Open Issues
3.1, 3.2
3.1, 3.2
