|Documentation||Container with the generic classification of types used by a specific infrastructure manager.|
|Children||any (0..*), designator (0..1), ownsSetsOfAssets (0..*), usesTypes (1..1)|
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.
Deprecated 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.
<specificIM id="BaneNor"> <designator register=„_SimpleRegister“ entry="BaneNor (JBV)"/> <ownsSetsOfAssets ref="ass_simpex_v0.9"/> …… </specificIM>
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.