Template:StateSpace: Difference between revisions

From railML 3 Wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
(creation of general page StateSpace)
 
(Replaced content with "<includeonly>{{note|Please, recognize our outline on state space.}}</includeonly><noinclude> ==Usage== This template produces a hint to our outline on s...")
Tag: Replaced
 
Line 1: Line 1:
{{head|State Space}}
<includeonly>{{note|Please, recognize our [[Dev:StateSpace|outline on state space]].}}</includeonly><noinclude>
=== AssetAndState ===
==Usage==
This template produces a hint to our outline on state space.
===Arguments===
''None''
==Examples==
<pre>{{StateSpace}}</pre>delivers{{StateSpace}}


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
[[category:template]]
# <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.
</noinclude>
 
 
 
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>

Latest revision as of 11:55, 30 May 2020

Usage

This template produces a hint to our outline on state space.

Arguments

None

Examples

{{StateSpace}}

delivers

🗒️ Please, recognize our outline on state space.  
Retrieved from "https://wiki3.railml.org/index.php?title=Template:StateSpace&oldid=3747"