View source for User:RailML Coord Documentation/Tutorial/State Space

{{head|State Space}}
=== AssetAndState ===

The railway network owns assets that can be associated with a state. This is expressed as a set of tuples, for instance, (signal<sub>i</sub> / aspect<sub>k</sub>). Other functional classes can make use of these tuples. The using of the state space is twofold:# <div style="margin-left:0.7cm;margin-right:0cm;">direct use of (asset, state) tuples with class {{doc|IL|assetAndState}} when just the state of the asset is needed
# <div style="margin-left:0.7cm;margin-right:0cm;">indirect use of (asset, state) tuples with class {{doc|IL|assetAndGivenState}} when additional the level of enforcement and its proving is needed because it is not obvious from the context.



Because of the construct of an abstract class the instances of {{doc|IL|assetAndState}} can use specific enumerations with the related states. The possible values in these enumerations are self-explanatory. In addition it can have the following attribute:
*{{@|isNegated}} – This Boolean value shall be used to express the inversion, i.e. all other possible states or positions are meant except the given one.
=== AssetAndGivenState ===

For a clear definition of a {{doc|IL|route}} it is necessary to have not only information about assets needed but also their state they shall assume during its use in the route. This is realised with elements like {{tag|IL|facingSwitchInPosition}} using the abstract class {{doc|IL|assetAndState}} or {{tag|IL|requiredSwitchPosition}} using the class {{doc|IL|assetAndGivenState}}. The latter one is similar build as {{doc|IL|assetAndState}} but including the information as child element {{tag|IL|relatedAssetAndState}}.

The class {{doc|IL|assetAndState}} is an abstract tuple of references to the asset and its related state. Depending on the particular instance the naming of these elements are varying.
*{{tag|IL|refersTo…}} – This is the reference to the particular asset in {{doc|IL|assetsForIL}}.
*{{tag|IL|inPosition}}, {{tag|IL|inState}}, {{tag|IL|showsAspect}} – This is the related position/state/aspect of the asset like {{enum|left}} for a switch.

There are several instantiations of the abstract class {{doc|IL|assetAndState}}. These are:
*{{doc|IL|crossingAndPosition}} – This combines a {{doc|IL|movableCrossing}} with a possible position.
*{{doc|IL|derailerAndPosition}} – This combines a {{doc|IL|derailerIL}} with a possible position.
*{{doc|IL|lockAndState}} – This combines a {{doc|IL|lockIL}} with a possible state.
*{{doc|IL|levelCrossingAndState}} – This combines a {{doc|IL|levelCrossingIL}} with a possible state.
*{{doc|IL|sectionAndVacancy}} – This combines a {{doc|IL|tvdSection}} with a possible vacancy state.
*{{doc|IL|signalAndAspect}} – This combines a {{doc|IL|signalIL}} with reference to an aspect as defined in {{doc|IL|genericTypes}}.
*{{doc|IL|swicthPointAndPosition}} – This combines a {{doc|IL|switchIL}} with a possible position.

The class {{doc|IL|assetAndGivenState}} adds information on the level of enforcement and the way of proving it.
*{{@|mustOrShould}} – This allows the definition how strong the state is required.
**{{enum|should}} – The state is the preferred one and should be used if possible (recommendation).
**{{enum|must}} – The state must be used in any case (obligation).
*{{@|proving}} – This describes the way the state is proven.
**{{enum|staffAcknowledged}} – The asset is proven by staff to have the required state. This is acknowledged by manual input action (command) to the interlocking.
**{{enum|continuously}} – The interlocking checks the asset state continuously as long as the asset is required.
**{{enum|oneOff}} – The interlocking checks the asset state only once when request for the asset is made.
*{{@|isNegated}} – This Boolean value shall be used to express the inversion, i.e. all other possible states or positions are meant except the given one.

The extract shows the sample definition of a particular switch position as used to describe the route path.
<syntaxhighlight lang=xml>
<facingSwitchInPosition id="rp_pt_swi01_li" inPosition="left">
        <designator register="_SimpleRegister" entry="pt01 in left"/>
        <refersToSwitch ref="pt_swi01"/>
</facingSwitchInPosition>
</syntaxhighlight>

The extended variant is shown here. The named track section must be occupied and is checked continuously for it.

<syntaxhighlight lang=xml>
<requiredSectionState mustOrShould="must" proving="continuously">
        <relatedSectionAndVacancy inState="occupied">
                <refersToSection ref="A02T" />
        </relatedSectionAndVacancy>
</requiredSectionState>
</syntaxhighlight>