Figure 7 – Example of a StateMachineType using inheritance

In Figure 7 an example of a StateMachine is given using the Notation defined in OPC 10000-3. 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 EventType "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 8 – Example of a StateMachineType with a SubStateMachine using inheritance

Figure 8 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 9 – Example of a StateMachineType using containment

Figure 9 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 it 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, that is, 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, that is, only pointing from the Transition to the State and not being able to browse to the other direction. 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 10 gives an example of a state machine having a transition from a sub-state to a state.

Figure 10 – Example of a StateMachine with Transitions from sub-states

In Figure 11 the representation of this example as StateMachineType in the AddressSpace 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 11 – Example of a StateMachineType having Transition to SubStateMachine

When a subtype of FiniteStateMachineType having States extends the StateMachine, it is not allowed to add additional States, but instead SubStateMachines can be added to existing States.

The example in Figure 12 shows a very simple StateMachine with two States.

Figure 12 – Example of a StateMachine with two States

In Figure 13 the StateMachine of Figure 12 is extended by adding two substates to "State1".

Figure 13 – Example of a StateMachine extended with two Substates

In Figure 14 the StateMachine of Figure 13 is extended by adding two substates to "State2", and an effect on the Transition between "State1" and "State2".

Figure 14 – Example of a StateMachine extended with another two Substates

In Figure 15 the representation of this example as StateMachineType in the AddressSpace is given. The “MyStateMachineType” defines the StateMachine of Figure 12, and the “MySubStateMachineType” is a subtype and extends the StateMachine with a SubStateMachine as defined in Figure 13. The “MySubSubStateMachineType” is another subtype as defined in Figure 14.

The States and Transitions of "MyStateMachineType” are replicated to "MySubStateMachineType" and "MySubSubStateMachineType". Since "Method1” is not overridden, the "Transition1" of all three types is referencing the Method of "MyStateMachineType”. In "MySubStateMachineType”, a SubStateMachine for "State1" was added, and in "MySubSubStateMachineType" a SubStateMachine for "State2". In addition, "MySubSubStateMachineType" adds an effect to "Transition1".

Figure 15 – Example of a StateMachineType adding SubStateMachines in Subtypes