Dev:StateSpace

State Space
 

The railway network owns assets that can be associated with a state. This is expressed as a set of tuples, for instance, (signal_i / aspect_k). Other interlocking entities can use these tuples to describe a required state of a related entity. The state space is used in two ways, as described below.

AssetAndState

When just a related asset and its state is needed, types are based on the abstract class AssetAndState directly, and extend it with a suitable reference to an asset as well as a property describing the state.

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 documented separately for each element.

Depending on the particular instance the naming of these elements are varying.

• <refersTo…> – This is the reference to the particular asset in assetsForIL.
• @inPosition, @inState, <showsAspect> – This is the related position/state/aspect of the asset like left for a switch.

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.

There are several types extending AssetAndState. These are, with the elements using them:

• CrossingAndPosition – This combines a movableCrossing with a possible position.
  • <relatedCrossingAndPosition>
• DerailerAndPosition – This combines a derailerIL with a possible position.
  • <relatedDerailerAndPosition>
  • <relatedDerailerInPosition>
• DetectorAndState - This combines a genericDetector with a possible state.
  • <relatedDetectorAndState>
• LevelCrossingAndState – This combines a levelCrossingIL with a possible state.
  • <relatedLevelCrossingAndState>
• LockAndState – This combines a keyLockIL with a possible state.
  • <relatedLockAndState>
• SectionAndVacancy – This combines a tvdSection with a possible vacancy state.
  • <relatedSectionAndVacancy>
• SignalAndAspect – This combines a signalIL with reference to an aspect as defined in hasAspect.
  • <distantAspect>
  • <masterAspect>
  • <relatedSignalAndAspect>
  • <slaveAspect>
• SwitchAndPosition – This combines a switchIL with a possible position.
  • <facingSwitchInPosition>
  • <relatedSwitchAndPosition>
  • <relatedSwitchInPosition>
  • <switchPositionInDepartureTrack>
  • <trailingSwitchInPosition>
• TunnelGateState - This combines a tunnelGateIL with a possible state.
  • <relatedToTunnelGateAndState>

AssetAndGivenState

When the level of enforcement and the way the state is proven is also needed, types are basted on the abstract class AssetAndGivenState, and extend it with an element of another type extending AssetAndState as described above.

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.

Examples

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> of type SwitchAndPosition extending AssetAndState and <requiredSwitchPosition> of type SwitchAndGivenPosition extending AssetAndGivenState. In the latter the (asset, state) tuple is given by the child element <relatedSwitchAndPosition>.

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>