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:specificIM of railML® version 3.1
Documentation Container with the generic classification of types used by a specific infrastructure manager.
Subschema interlocking
Parents* specificIMs
Children any (0..*), designator (0..1), ownsSetsOfAssets (0..*), usesTypes (1..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 very first step for setting up an interlocking file is the definition of the generic types. Although virtually depicted in the bottom of the schema these generic types come first as they are referenced by the more detailed data later on. The container <specificIMs> takes the data of the individual <specificIM>. It shall be noted although the type is named GenericIM the instantiation as element is named <specificIM>.

Each infrastructure manager (IM) has a couple of rather specific items, which have impact on interlocking issues and functions. In order to achieve a common exchange format it is vital to define such specific items within a fixed generic structure still allowing the individual characteristics. This is the purpose of the generic types. They are providing a mean of common classification of functions being rather individual for any IM. However, these types do not specify the operational rules of that IM.

Beside the <designator> and @id it comprises a reference to the related set of assets in <ownsSetsOfAssets>.

<specificIM id="BaneNor">
        <designator register=„_SimpleRegister“ entry="BaneNor (JBV)"/>
        <ownsSetsOfAssets ref="ass_simpex_v0.9"/>

The object <specificIM> is filled with the data of items specific for this IM. Such specific items are typical items like signal aspects or route handling.

Additional Information


Open Issues