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 type AssetAndState directly, and extend it with a suitable reference to an asset as well as a property describing the state. Depending on the particular instance the naming of these elements are varying.

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

The types extending AssetAndState use enumerated states matching the type of asset. The possible values in these enumerations are documented separately for each element inheriting AssetAndState.

In addition, the AssetAndState type always provides the following attribute:

• @isNegated – This Boolean value shall be used to express an inversion, i.e. all other possible states or positions are meant except the given one.

AssetAndGivenState

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

The following attributes are provided for all elements inheriting AssetAndGivenState:

• @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.

Instances

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>

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 inPosition="left">
        <refersToSwitch ref="pt_swi01"/>
</facingSwitchInPosition>

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

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