From railML 3 Wiki
Jump to navigation Jump to search




This element does not appear in railML® 3.2 within the IL subschema. It is available only in railML® 3.1. Do not hesitate to contact for further questions.

Autoexport from the XML-Schema for element IL:assetsForIL of railML® version 3.1

container for all asset elements needed for interlocking purpose




any (0..*), atpDevices (0..1), combinedRoutes (0..1), conflictingRoutes (0..1), dangerPoints (0..1), derailersIL (0..1), designator (0..1), destinationPoints (0..1), genericDetectors (0..1), interfaces (0..1), keyLocksIL (0..1), keys (0..1), levelCrossingsIL (0..1), localOperationAreas (0..1), movableCrossings (0..1), overlaps (0..1), permissionZones (0..1), powerSuppliesIL (0..1), routeRelations (0..1), routeReleaseGroupsAhead (0..1), routeReleaseGroupsRear (0..1), routes (0..1), shuntingZones (0..1), signalsIL (0..1), switchesIL (0..1), tvdSections (0..1), workZones (0..1)


  • 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
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

Removed with version 3.2.


Best Practice / Examples

The physical features of tracks and trackside components (“track assets”) are described in the infrastructure subschema, and these object’s identities are referenced from the interlocking schema. Examples of track assets are: signals, switches, and TVD sections. Whereas the infrastructure subschema focus on the characteristics of the hardware the interlocking subschema concentrate on the more logical characteristics relevant for interlocking issues. Thus the interlocking subschema adds more information to some infrastructure elements.

Within the entire railML schema there are no different namespaces used. Subsequently some elements (types) in interlocking subschema had to be renamed in order to avoid collision with already existing elements in infrastructure subschema. In such cases just the suffix “IL” was added to the name, e.g. signalIS vs. signalIL.

The element of <assetsForIL> is not only a collection of track assets but including some interlocking system components (“system assets”) and functional combinations like routes or restricted areas. Examples of system assets are anything not strictly related to track position like radio block centre, communication systems, power supply systems and diagnostic systems. The various kinds of assets have individual containers, which each hold an unlimited number of objects.

There can be only one collection of assets within one interlocking data set. Different states of network evolution would cause different objects due to requirements of uniqueness concerning ID.

Additional Information


This element was renamed in 3.2 to <assetsForInterlocking> to avoid abbreviations in element names.

Open Issues