StateMachines

The following example provides an overview of the base features that the state machines defined in this Appendix will support. In the following a more complex example is given, that also supports sub-state machines.

Figure 1 gives an overview over a simple state machine. It contains the three states “State1”, “State2” and “State3”. There are transitions from “State1” to “State2”, “State2” to “State2”, etc. Some of the transitions provide additional information with regard to what causes (or triggers) the transition, e.g. the call of “Method1” for the transition from “State1” to “State2”. The effect (or action) of the transition can also be specified, e.g. the generation of an Event of the “EventType1” in the same transition. The notation used to identify the cause is simply listing it on the transition, the effect is prefixed with a “/”. More than one cause or effect are separated by a “,”. Not every transition has to have a cause or effect, for example the transition between “State2” and “State3”.

Figure 1: Example of a simple state machine

For simplicity, the state machines described in this section will only support causes in form of specifying Methods that have to be called and effects in form of EventTypes of Events that are generated. However, the defined infrastructure allows extending this to support additional different causes and effects.

Figure 2 shows an example of a state machine where “State6” is a sub-state-machine. This means, that when the overall state machine is in State6, this state can be distinguish to be in the sub-states “State7” or “State8”. Sub-state-machines can be nested, i.e. “State7” could be another sub-state-machine.

Figure 2: Example of a state machine having a sub-machine

The types defined in this section are illustrated in Figure 3. The MyFiniteStateMachineType is a minimal example which illustrates how these Types can be used to describe a StateMachine. See section Alarms and Conditions for additional examples of StateMachines.

Figure 3: The StateMachine Information Model

The StateMachineType is the base ObjectType for all StateMachineTypes. It defines a single Variable which represents the current state of the machine. An instance of this ObjectType shall generate an Event whenever a significant state change occurs. The Server decides which state changes are significant. Servers shall use the GeneratesEventReferenceType to indicate which Event(s) could be produced by the StateMachine.

Subtypes may add Methods which affect the state of the machine. The Executable Attribute is used to indicate whether the Method is valid given the current state of the machine. The generation of AuditEvents for Methods is described in section Services. A StateMachine may not be active. In this case, the CurrentState and LastTransition Variables shall have a status equal to Bad_StateNotActive.

Subtypes may add components which are instances of StateMachineTypes. These components are considered to be sub-states of the StateMachine. SubStateMachines are only active when the parent machine is in an appropriate state.

Events produced by SubStateMachines may be suppressed by the parent machine. In some cases, the parent machine will produce a single Event that reflects changes in multiple SubStateMachines.

FiniteStateMachineType is subtype of StateMachineType that provides a mechanism to explicitly define the states and transitions. A Server should use this mechanism if it knows what the possible states are and the state machine is not trivial.

CurrentState stores the current state of an instance of the StateMachineType. CurrentState provides a human readable name for the current state which may not be suitable for use in application control logic. Applications should use the Id Property of CurrentState if they need a unique identifier for the state.

LastTransition stores the last transition which occurred in an instance of the StateMachineType. LastTransition provides a human readable name for the last transition which may not be suitable for use in application control logic. Applications should use the Id Property of LastTransition if they need a unique identifier for the transition.

The StateVariableType is the base VariableType for Variables that store the current state of a StateMachine as a human readable name

Id is a name which uniquely identifies the current state within the StateMachineType. A subtype may restrict the DataType.

Name is a QualifiedName which uniquely identifies the current state within the StateMachineType.

Number is an integer which uniquely identifies the current state within the StateMachineType.

EffectiveDisplayName contains a human readable name for the current state of the state machine after taking the state of any SubStateMachines in account. There is no rule specified for which state or sub-state should be used. It is up to the server and will depend on the semantics of the StateMachineType.

StateMachines produce Events which may include the current state of a StateMachine. In that case servers shall provide all the optional Properties of the StateVariableType in the Event, even if they are not provided on the instances in the Address Space.

The TransitionVariableType is the base VariableType for Variables that store a Transition that occurred within a StateMachine as a human readable name.

The SourceTimestamp for the value specifies when the Transition occurred. This value may also be exposed with the TransitionTime Property.

Id is a name which uniquely identifies a Transition within the StateMachineType. A subtype may restrict the DataType.

Name is a QualifiedName which uniquely identifies a transition within the StateMachineType.

Number is an integer which uniquely identifies a transition within the StateMachineType.

TransitionTime specifies when the transition occurred.

The FiniteStateMachineType is the base ObjectType for StateMachines that explicitly define the possible States and Transitions. Once the States are defined subtypes shall not add new States

The States of the machine are represented with instances of the StateType ObjectType. Each State shall have a BrowseName which is unique within the StateMachine and shall have a StateNumber which shall also be unique across all States defined in the StateMachine. A concrete subtype of FiniteStateMachineType shall define at least one State.

A StateMachine may define one State which is an instance of the InitialStateType. This State is the State that the machine goes into when it is activated.

The Transitions that may occur are represented with instances of the TransitionType. Each Transition shall have a BrowseName which is unique within the StateMachine and may have a TransitionNumber which shall also be unique across all Transitions defined in the StateMachine.

The initial State for a Transition is a StateType Object which is the target of a FromState Reference. The final State for a Transition is a StateType Object which is the target of a ToState Reference. The FromState and ToState References shall always be specified.

A Transition may produce an Event. The Event is indicated by a HasEffect Reference to a subtype of BaseEventType. The StateMachineType shall have GeneratesEvent References to the targets of a HasEffect Reference for each of its Transitions.

A FiniteStateMachineType may define Methods that cause a transition to occur. These Methods are targets of HasCause References for each of the Transitions that may be triggered by the Method. The Executable Attribute for a Method is used to indicate whether the current State of the machine allows the Method to be called.

A FiniteStateMachineType may have sub-state-machines which are represented as instances of StateMachineType ObjectTypes. Each State shall have a HasSubStateMachine Reference to the StateMachineType Object which represents the child States. The SubStateMachine is not active if the parent State is not active.

The FiniteStateVariableType is a subtype of StateVariableType and is used to store the current state of a FiniteStateMachine as a human readable name

Id is inherited from the StateVariableType and overridden to reflect the required DataType. This value shall be the NodeId of one of the State Objects of the FiniteStateMachineType.

Name inherited from StateVariableType shall be the BrowseName of one of the State Objects of the FiniteStateMachineType.

Number inherited from StateVariableType shall be the StateNumber for one of the State Objects of the FiniteStateMachineType

The FiniteTransitionVariableType is a subtype of TransitionVariableType and is used to store a Transition that occurred within a FiniteStateMachine as a human readable name.

Id is inherited from the TransitionVariableType and overridden to reflect the required DataType. This value shall be the NodeId of one of the Transition Objects of the FiniteStateMachineType.

Name inherited from the TransitionVariableType shall be the BrowseName of one of the Transition Objects of the FiniteStateMachineType.

Number inherited from the TransitionVariableType shall be the TransitionNumber for one of the Transition Objects of the FiniteStateMachineType.

States of a FiniteStateMachine are represented as Objects of the StateType

The InitialStateType is a subtype of the StateType and is formally defined in Table 148. An Object of the InitialStateType represents the State that a FiniteStateMachine enters when it activated. Each FiniteStateMachine can have at most one State of type InitialStateType, but a FiniteStateMachine does not have to have a State of this type.

A StateMachine goes into its initial state whenever the parent state is entered. However, a state machine may define a transition that goes directly to a state of the SubStateMachine. In this case the SubStateMachine goes into that State instead of the initial State. The two scenarios are illustrated in Figure 4. The transition from State5 to State6 causes the SubStateMachine to go into the initial State (State7), however, the transition from State4 to State8 causes the parent machine to go to State6 and the SubStateMachine will go to State8.

Figure 4: Example of an initial State in a sub-machine

If no initial state for a SubStateMachine exists and the State having the SubStateMachine is entered directly, then the State of the SubStateMachine is server specific.

Transitions of a FiniteStateMachine are represented as Objects of the ObjectType TransitionType.

Each valid Transition shall have exactly one FromState Reference and exactly one ToState Reference, each pointing to an Object of the ObjectType StateType.

Each Transition can have one or more HasCause References pointing to the cause that triggers the Transition.

Each Transition can have one or more HasEffect References pointing to the effects that occur when the Transition was triggered.

The FromState is a concrete reference type and can be used directly. It is a subtype of NonHierarchicalReferences.

The semantic of this type is to point form a Transition to the starting State the Transition connects.

The SourceNode of this ReferenceType shall be an Object of the ObjectType TransitionType or one of its subtypes. The TargetNode of this ReferenceType shall be an Object of the ObjectType StateType or one of its subtypes.

Each Transition can have one or more HasEffect References pointing to the effects that occur when the Transition was triggered.

The ToState is a concrete reference type and can be used directly. It is a subtype of NonHierarchicalReferences.

The semantic of this type is to point form a Transition to the ending State the Transition connects.

The source node of this ReferenceType shall be an Object of the ObjectType TransitionType or one of its subtypes. The target node of this ReferenceType shall be an Object of the ObjectType StateType or one of its subtypes.

References of this ReferenceType may be only exposed uni-directional. Sometimes this is required, for example, if a Transition points to a State of a sub-machine.

The HasCause type is a concrete reference type and can be used directly. It is a subtype of NonHierarchicalReferences.

The semantic of this type is to point form a Transition to something that causes the Transition. In this Appendix we only define Methods as Causes. However, the ReferenceType is not restricted to point to Methods.

The source node of this ReferenceType shall be an Object of the ObjectType TransitionType or one of its subtypes. The TargetNode can be of any node class.

The HasEffect is a concrete reference type and can be used directly. It is a subtype of NonHierarchicalReferences.

The semantic of this reference type is to point form a Transition to something that will be effected when the Transition is triggered. In this Appendix we only define EventTypes as Effects. However, the ReferenceType is not restricted to point to EventTypes.

The source node of this ReferenceType shall be an Object of the ObjectType TransitionType or one of its subtypes. The TargetNode can be of any node class.

The HasSubStateMachine is a concrete type and can be used directly. It is a subtype of NonHierarchicalReferences.

The semantic of this type is to point from a State to an instance of a StateMachineType which represents the sub-states for the State.

The SourceNode of this ReferenceType shall be an Object of the ObjectType StateType. The TargetNode shall be an Object of the ObjectType StateMachineType or one of its subtypes. Each Object can be the TargetNode of at most one HasSubStateMachine Reference.

The SourceNode (the state) and the TargetNode (the SubStateMachine) shall belong to the same StateMachine, i.e. both shall be referenced from the same Object of type StateMachineType using a HasComponent Reference or a subtype of HasComponent.

The TransitionEventType is a subtype of the BaseEventType. It can be used to generate an Event identifying that a Transition of a StateMachine was triggered.

The TransitionEventType inherits the Properties of the BaseEventType.

The inherited Property SourceNode shall be filled with the NodeId of the StateMachine instance were the Transition occurs. If the Transition occurs in a SubStateMachine, then the NodeId of the SubStateMachine has to be used. If the Transition occurs between a StateMachine and a SubStateMachine, then the NodeId of the StateMachine has to be used, independent of the direction of the Transition.

Transition identifies the Transition that triggered the Event.

FromState identifies the State before the Transition.

ToState identifies the State after the Transition.

The AuditUpdateStateEventType is a subtype of the AuditUpdateMethodEventType. It can be used to generate an Event identifying that a Transition of a StateMachine was triggered.

The AuditUpdateStateEventType inherits the Properties of the AuditUpdateMethodEventType.

The inherited Property SourceNode shall be filled with the NodeId of the StateMachine instance were the State changed. If the State changed in a SubStateMachine, then the NodeId of the SubStateMachine has to be used.

The SourceName for Events of this type should be the effect that generated the event (e.g. the name of a Method). If the effect was generated by a Method call, the SourceName should be the name of the Method prefixed with “Method/”.

OldStateId reflects the Id of the state prior the change.

NewStateId reflects the new Id of the state after the change.

In general, all rules on subtyping apply for StateMachine types as well. Some additional rules apply for StateMachine types. If a StateMachine type is not abstract, subtypes of it shall not change the behaviour of it. That means, that in that case a subtype shall not add States and it shall not add Transitions between its States. However, a subtype may add SubStateMachines, it may add Transitions from the States to the States of the SubStateMachine, and it may add Causes and Effects to a Transition. In addition, a subtype of a StateMachine type shall not remove States or Transitions.

Figure 5: Example of a StateMachineType using inheritance

In Figure 5 an example of a StateMachine is given using the Notation described in the section of section Address Space. First, a new StateMachineType is defined, called “MyStateMachineType”, inheriting from the base FiniteStateMachineType. It contains two States, “State1” and “State2” and a Transition “Transition1” between them. The Transition points to a Method “MyMethod” as the Cause of the Transition and an event type “EventType1” as the Effect of the Transition.

Instances of “MyStateMachineType” can be created, for example “MyStateMachine”. It has a Variable “CurrentState” representing the current State. The “MyStateMachine” Object only includes the Nodes which expose information specific to the instance.

Figure 6: Example of a StateMachineType with a SubStateMachine using inheritance

Figure 6 gives an example of a StateMachineType having a SubStateMachine for its “State1”. For simplicity no effects and causes are shown, as well as type information for the States or ModellingRules.

The “MyStateMachineType” contains an Object “MySubMachine” of type “AnotherStateMachineType” representing a SubStateMachine. The “State1” references this Object with a HasSubStateMachine Reference, thus it is a SubStateMachine of “State1”. Since “MySubMachine” is an Object of type “AnotherStateMachineType” it has a Variable representing the current State. Since it is used as an InstanceDeclaration, no value is assigned to this Variable.

An Object of “MyStateMachineType”, called “MyStateMachine” has Variables for the current State, but also has an Object “MySubMachine” and a Variable representing the current state of the SubStateMachine. Since the SubStateMachine is only used when “MyStateMachine” is in “State1”, a client would receive a Bad_StateNotActive StatusCode when reading the SubStateMachine CurrentState Variable if “MyStateMachine” is in a different State.

Figure 7: Example of a StateMachineType using containment

Figure 7 gives an example of an ObjectType not only representing a StateMachine but also having some other functionality. The ObjectType “MyObjectType” has an Object “MyComponent” representing this other functionality. But is also contains a StateMachine “MyStateMachine” of the type “MyStateMachineType”. Objects of “MyObjectType” also contain such an Object representing the StateMachine and a Variable containing the current state of the StateMachine, as shown in the Figure.

The StateMachines shown so far only had Transitions between States on the same level, i.e. on the same StateMachine. Of cause, it is possible and often required to have Transitions between States of the StateMachine and States of its SubStateMachine.

Because a SubStateMachine can be defined by another StateMachineType and this type can be used in several places, it is not possible to add a bi-directional Reference from one of the shared States of the SubStateMachine to another StateMachine. In this case it is suitable to expose the FromState or ToState References uni-directional, i.e. only pointing from the Transition to the State and not have the other direction browsable. If a Transition points from a State of a SubStateMachine to a State of another sub-machine, both, the FromState and the ToState Reference, are handled uni-directional.

A Client shall be able to handle the information of a StateMachine if the ToState and FromState References are only exposed as forward References and the inverse References are omitted.

Figure 8 gives an example of a state machine having a transition from a sub-state to a state.

Figure 8: Example of a state machine with transitions from sub-states

In Figure 9, the representation of this example as StateMachineType in the Address Space is given. The “Transition1”, part of the definition of “MyStateMachineType”, points to the “StateX” of the StateMachineType “AnotherStateMachineType”. The Reference is only exposed as forward Reference and the inverse Reference is omitted. Thus, there is no Reference from the “StateX” of “AnotherStateMachineType” to any part of “MyStateMachineType” and “AnotherStateMachineType” can be used in other places as well.

Figure 9: Example of a StateMachineType having Transitions to SubStateMachines