Errata exists for this version of the document.

This annex describes the basic infrastructure to model state machines. It defines ObjectTypes, VariableTypes and ReferenceTypes and explains how they should be used.

This annex is an integral part of this standard, that is, the types defined in this annex have to be used as defined. However, it is not required but strongly recommended that a Server uses these types to expose its state machines. The defined types may be subtyped to refine their behaviour.

When a Server exposes its state machine using the types defined in this annex, it might only provide a simplified view on its internal state machine, hiding for example substates or putting several internal states into one exposed state.

The scope of the state machines described in this annex is to provide an appropriate foundation for state machines needed for OPC 10000-9 and OPC 10000-10. It does not provide more complex functionality of a state machine like parallel states, forks and joins, history states, choices and junctions, etc. However, the base state machine defined in this annex can be extended to support such concepts.

The following clauses describe examples of state machines, define state machines in the context of this annex and define the representation of state machines in OPC UA. Finally, some examples of state machines, represented in OPC UA, are given.

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

Figure B.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, for example the call of “Method1” for the transition from “State1” to “State2”. The effect (or action) of the transition can also be specified, for example 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 B.1 – Example of a simple state machine

For simplicity, the state machines described in this annex 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 B.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 distinguished to be in the sub-states “State7” or “State8”. Sub-state-machines can be nested, that is, “State7” could be another sub-state-machine.

Figure B.2 – Example of a state machine having a sub-machine

The infrastructure of state machines defined in this annex only deals with the basics of state machines needed to support OPC 10000-9 and OPC 10000-10. The intention is to keep the basic simple but extensible.

For the state machines defined in this annex we assume that state machines are typed and instances of a type have their states and semantics specified by the type. For some types, this means that the states and transitions are fixed. For other types the states and transitions may be dynamic or unknown. A state machine where all the states are specified explicitly by the type is called a finite state machine.

Therefore we distinguish between StateMachineType and StateMachine and their subtypes like FiniteStateMachineType. The StateMachineType specifies a description of the state machine, that is, its states, transitions, etc., whereas the StateMachine is an instance of the StateMachineType and only contains the current state.

Each StateMachine contains information about the current state. If the StateMachineType has SubStateMachines, the StateMachine also contains information about the current state of the SubStateMachines. StateMachines which have their states completely defined by the type are instances of a FiniteStateMachineType.

Each FiniteStateMachineType has one or more States. For simplicity, we do not distinguish between different States like the start or the end states.

Each State can have one or more SubStateMachines.

Each FiniteStateMachineType may have one or more Transitions. A Transition is directed and points from one State to another State.

Each Transition can have one or more Causes. A Cause leads a FiniteStateMachine to change its current State from the source of the Transition to its target. In this annex we only specify Method calls to be Causes of Transitions. Transitions do not have to have a Cause. A Transition can always be caused by some server-internal logic that is not exposed in the AddressSpace.

Each Transition can have one or more Effects. An Effect occurs if the Transition is used to change the State of a StateMachine. In this annex we only specify the generation of Events to be Effects of a Transition. A Transition is not required to expose any Effects in the AddressSpace.

Although this annex only specifies simple concepts for state machines, the provided infrastructure is extensible. If needed, special States can be defined as well as additional Causes or Effects.

The types defined in this annex are illustrated in Figure B.3. The MyFiniteStateMachineType is a minimal example which illustrates how these Types can be used to describe a StateMachine. See OPC 10000-9 and OPC 10000-10 for additional examples of StateMachines.

Figure B.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 GeneratesEvent ReferenceType 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 defined in OPC 10000-4. A StateMachine may not be active. In this case, the CurrentState and LastTransition Variables shall have a status equal to Bad_StateNotActive (see Table B.17).

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. The FiniteStateMachineType is defined in B.4.5.

The StateMachineType is formally defined in Table B.1.

Table B.1 – StateMachineType Definition

Attribute		Value
BrowseName		StateMachineType
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseObjectType defined in 6.2. Note that a Reference to this subtype is not shown in the definition of the BaseObjectType.
HasSubtype	ObjectType		FiniteStateMachineType	Defined in B.4.5
HasComponent	Variable		CurrentState	LocalizedText	StateVariableType	Mandatory
HasComponent	Variable		LastTransition	LocalizedText	TransitionVariableType	Optional

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.

The StateVariableType is formally defined in Table B.2.

Table B.2 – StateVariableType Definition

Attribute		Value
BrowseName		StateVariableType
DataType		LocalizedText
ValueRank		−1 (−1 = Scalar)
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseDataVariableType defined in 7.4. Note that a Reference to this subtype is not shown in the definition of the BaseDataVariableType.
HasSubtype	VariableType		FiniteStateVariableType	Defined in B.4.6
HasProperty	Variable		Id	BaseDataType	PropertyType	Mandatory
HasProperty	Variable		Name	QualifiedName	PropertyType	Optional
HasProperty	Variable		Number	UInt32	PropertyType	Optional
HasProperty	Variable		EffectiveDisplayName	LocalizedText	PropertyType	Optional

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 AddressSpace.

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.

The TransitionVariableType is formally defined in Table B.3.

Table B.3 – TransitionVariableType Definition

Attribute		Value
BrowseName		TransitionVariableType
DataType		LocalizedText
ValueRank		−1 (−1 = Scalar)
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseDataVariableType defined in 7.4. Note that a Reference to this subtype is not shown in the definition of the BaseDataVariableType.
HasSubtype	VariableType		FiniteTransitionVariableType	Defined in B.4.7
HasProperty	Variable		Id	BaseDataType	PropertyType	Mandatory
HasProperty	Variable		Name	QualifiedName	PropertyType	Optional
HasProperty	Variable		Number	UInt32	PropertyType	Optional
HasProperty	Variable		TransitionTime	UtcTime	PropertyType	Optional
HasProperty	Variable		EffectiveTransitionTime	UtcTime	PropertyType	Optional

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.

EffectiveTransitionTime specifies the time when the current state or one of its substates was entered. If, for example, a StateA is active and – while active – switches several times between its substates SubA and SubB, then the TransitionTime stays at the point in time where StateA became active whereas the EffectiveTransitionTime changes with each change of a substate.

The FiniteStateMachineType is the base ObjectType for StateMachines that explicitly define the possible States and Transitions. Once the States and Transitions are defined subtypes shall not add new States and Transitions (see B.4.18). Subtypes may add causes or effects.

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. Be aware that States in a SubStateMachine may have the same StateNumber or BrowseName as States in the parent machine. 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. In this case the CurrentState and LastTransition Variables of the SubStateMachine shall have a status equal to Bad_StateNotActive (see Table B.17).

The FiniteStateMachineType is formally defined in Table B.4.

Table B.4 – FiniteStateMachineType Definition

Attribute		Value
BrowseName		FiniteStateMachineType
IsAbstract		True
References	NodeClass		BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the StateMachineType defined in 6.2.
HasComponent	Variable		CurrentState	LocalizedText	FiniteStateVariableType	Mandatory
HasComponent	Variable		LastTransition	LocalizedText	FiniteTransitionVariableType	Optional
HasComponent	Variable		AvailableStates	NodeId[]	BaseDataVariableType	Optional
HasComponent	Variable		AvailableTransitions	NodeId[]	BaseDataVariableType	Optional

In some Servers an instance of a StateMachine may restrict the States and / or Transitions that are available. These restrictions may result from the internal design of the instance. For example the StateMachine for an instrument’s limit alarm which only supports Hi and HiHi and can not produce a Low or LowLow. An instance of a StateMachine may also dynamically change the available States and/or Transitions based on its operating mode. For example when a piece of equipment is in a maintenance mode the available States may be limited to some subset of the States available during normal operation.

The AvailableStates Variable provides a NodeId list of the States that are present in the StateMachine instance. The list may change during operation of the Server.

The AvailableTransitions Variable provides a NodeId list of the Transitions that are present in the StateMachine instance. The list may change during operation of the Server.

An example of a FiniteStateMachine type is shown in Figure B.4 below.

Figure B.4 – Example of a FiniteStateMachine type

An example instance of the type is shown in Figure B.5. In this example the States {7,8,9} and the Transitions {G,H,I,J} are not available in this instance.

Figure B.5 – Example of a FiniteStateMachine instance

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

The FiniteStateVariableType is formally defined in Table B.5.

Table B.5 – FiniteStateVariableType Definition

Attribute		Value
BrowseName		FiniteStateVariableType
DataType		LocalizedText
ValueRank		−1 (−1 = Scalar)
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the StateVariableType defined in B.4.3
HasProperty	Variable		Id	NodeId	PropertyType	Mandatory

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.

The Name Property is inherited from StateVariableType. Its Value shall be the BrowseName of one of the State Objects of the FiniteStateMachineType.

The Number Property is inherited from StateVariableType. Its Value 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.

The FiniteTransitionVariableType is formally defined in Table B.6.

Table B.6 – FiniteTransitionVariableType Definition

Attribute	Value
BrowseName	FiniteTransitionVariableType
DataType	LocalizedText
ValueRank	−1 (−1 = Scalar)
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the TransitionVariableType defined inB.4.4. Note that a Reference to this subtype is not shown in the definition of the BaseDataVariableType.
HasProperty	Variable	Id	NodeId	PropertyType	Mandatory

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.

The Name Property is inherited from the TransitionVariableType. Its Value shall be the BrowseName of one of the Transition Objects of the FiniteStateMachineType.

The Number Property is inherited from the TransitionVariableType. Its Value 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 StateType is formally defined in Table B.7.

Table B.7 – StateType Definition

Attribute	Value
BrowseName	StateType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseObjectType defined in 6.2. Note that a Reference to this subtype is not shown in the definition of the BaseObjectType.
HasProperty	Variable	StateNumber	UInt32	PropertyType	Mandatory
HasSubtype	ObjectType	InitialStateType	Defined in B.4.9

The InitialStateType is a subtype of the StateType and is formally defined in Table B.8. An Object of the InitialStateType represents the State that a FiniteStateMachine enters when it is 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 SubStateMachine 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 B.6. 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 B.6 – 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.

Table B.8 – InitialStateType Definition

Attribute		Value
BrowseName		InitialStateType
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the StateType defined in B.4.8

Transitions of a FiniteStateMachine are represented as Objects of the ObjectType TransitionType formally defined in Table B.9.

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.

Table B.9 – TransitionType Definition

Attribute		Value
BrowseName		TransitionType
IsAbstract		False
References	NodeClass		BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseObjectType defined in 6.2. Note that a Reference to this subtype is not shown in the definition of the BaseObjectType.
HasProperty	Variable		TransitionNumber	UInt32	PropertyType	Mandatory

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

The semantic of this ReferenceType 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.

The representation of the FromState ReferenceType in the AddressSpace is specified in Table B.10.

Table B.10 – FromState ReferenceType

Attributes	Value
BrowseName	FromState
InverseName	ToTransition
Symmetric	False
IsAbstract	False
References	NodeClass	BrowseName	Comment

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

The semantic of this ReferenceType is to point form a Transition to the ending 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.

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 representation of the ToState ReferenceType in the AddressSpace is specified in Table B.11.

Table B.11 – ToState ReferenceType

Attributes	Value
BrowseName	ToState
InverseName	FromTransition
Symmetric	False
IsAbstract	False
References	NodeClass	BrowseName	Comment

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

The semantic of this ReferenceType is to point from a Transition to something that causes the Transition. In this annex we only define Methods as Causes. However, the ReferenceType is not restricted to point to Methods. The referenced Methods can, but do not have to point to a Method of the StateMachineType. For example, it is allowed to point to a server-wide restart Method leading the state machine to go into its initial state.

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

The representation of the HasCause ReferenceType in the AddressSpace is specified in Table B.12.

Table B.12 – HasCause ReferenceType

Attributes	Value
BrowseName	HasCause
InverseName	MayBeCausedBy
Symmetric	False
IsAbstract	False
References	NodeClass	BrowseName	Comment

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

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

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

The representation of the HasEffect ReferenceType in the AddressSpace is specified in Table B.13.

Table B.13 – HasEffect ReferenceType

Attributes	Value
BrowseName	HasEffect
InverseName	MayBeEffectedBy
Symmetric	False
IsAbstract	False
References	NodeClass	BrowseName	Comment

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

The semantic of this ReferenceType 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, that is, both shall be referenced from the same Object of type StateMachineType using a HasComponent Reference or a subtype of HasComponent.

The representation of the HasSubStateMachine ReferenceType in the AddressSpace is specified in Table B.14.

Table B.14 – HasSubStateMachine ReferenceType

Attributes	Value
BrowseName	HasSubStateMachine
InverseName	SubStateMachineOf
Symmetric	False
IsAbstract	False
References	NodeClass	BrowseName	Comment

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. It is formally defined in Table B.15.

Table B.15 – TransitionEventType

Attribute	Value
BrowseName	TransitionEventType
IsAbstract	True
References		NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the base BaseEventType defined in 6.4.2
HasComponent		Variable	Transition	LocalizedText	TransitionVariableType	Mandatory
HasComponent		Variable	FromState	LocalizedText	StateVariableType	Mandatory
HasComponent		Variable	ToState	LocalizedText	StateVariableType	Mandatory

The TransitionEventType inherits the Properties of the BaseEventType.

The inherited Property SourceNode shall be filled with the NodeId of the StateMachine instance where 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. It is formally defined in Table B.16.

Table B.16 – AuditUpdateStateEventType

Attribute		Value
BrowseName		AuditUpdateStateEventType
IsAbstract		True
References	NodeClass		BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the AuditUpdateMethodEventType defined in 6.4.27
HasProperty	Variable		OldStateId	BaseDataType	PropertyType	Mandatory
HasProperty	Variable		NewStateId	BaseDataType	PropertyType	Mandatory

The AuditUpdateStateEventType inherits the Properties of the AuditUpdateMethodEventType.

The inherited Property SourceNode shall be filled with the NodeId of the StateMachine instance where 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 this 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.

In Table B.17 specific StatusCodes used for StateMachines are defined.

Table B.17 – Specific StatusCodes for StateMachines

Symbolic Id	Description
Bad_ StateNotActive	The accessed state is not active.

Figure B.7 – Example of a StateMachineType using inheritance

In Figure B.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 B.8 – Example of a StateMachineType with a SubStateMachine using inheritance

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

Figure B.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 B.10 gives an example of a state machine having a transition from a sub-state to a state.

Figure B.10 – Example of a state machine with transitions from sub-states

In Figure B.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 B.11 – Example of a StateMachineType having Transition to SubStateMachine