Dev:StateSpace

From railML 3 Wiki
Jump to: navigation, search

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, (signali / aspectk). Other functional classes can make use of these tuples. The using of the state space is twofold:

  1. direct use of (asset, state) tuples with class assetAndState when just the state of the asset is needed
  2. indirect use of (asset, state) tuples with class 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 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 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 <facingSwitchInPosition> using the abstract class assetAndState or <requiredSwitchPosition> using the class assetAndGivenState. The latter one is similar build as assetAndState but including the information as child element <relatedAssetAndState>.

The class 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.

There are several instantiations of the abstract class assetAndState. These are:

The class 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.
    • should – The state is the preferred one and should be used if possible (recommendation).
    • must – The state must be used in any case (obligation).
  • @proving – This describes the way the state is proven.
    • staffAcknowledged – The asset is proven by staff to have the required state. This is acknowledged by manual input action (command) to the interlocking.
    • continuously – The interlocking checks the asset state continuously as long as the asset is required.
    • 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.

<facingSwitchInPosition id="rp_pt_swi01_li" inPosition="left">
        <designator register="_SimpleRegister" entry="pt01 in left"/>
        <refersToSwitch ref="pt_swi01"/>
</facingSwitchInPosition>

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

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