All state machine types defined in this specification are mandatory unless explicitly stated otherwise. However, some states may be implemented as transient (do-nothing) states depending on the characteristics of the vision system.

To improve clarity and re-usability, this specification makes use of hierarchical state machines. This means that states of a state machine may have underlying SubStateMachines. The instantiation of a SubStateMachine for a particular state of the main state machine may be specified as optional.

OPC 10000-5, Annex B.4.9 defines several ways of entering a SubStateMachine:

1. If the SubStateMachine has an initial state (i.e., a state of type InitialStateType) this state is entered whenever the parent state is entered.We make use of this principle for the VisionStepModelStateMachine defined in Section 8.4.
2. A SubStateMachine can also be entered by a direct transition from the parent state machine into one of its states, bypassing the initial state. In this case, the parent state machine goes automatically into the parent state of the SubStateMachine. We make use of this principle for operation mode state machines like the VisionAutomaticModeStateMachine defined in Section 8.3.
3. If a SubStateMachine has no initial state and the parent state is entered directly, the state of the SubStateMachine is server-specific.We make use of this principle for the error handling described in Section 8.2.2.4.

The SubStateMachine types used here do not have transitions into specific states of the parent state machine so that they are not bound to a specific state machine, but can be used within states of any state machine. Therefore, the SubStateMachines are not left explicitly. Instead, the parent state machine may leave the parent state of the SubStateMachine in which case the SubStateMachine ceases to be active and will enter a Bad_StateNotActive state. In that case, the system actually transitions from a state of the SubStateMachine into an unrelated state of the main state machine, but this transition will not be explicitly shown or specified on the level of the SubStateMachine.

We make use of that principle especially for the error handling described in Section 8.2.2.4.

At present, this specification describes one such mode, the “Automatic” mode. All pertaining states are contained in a SubStateMachine of type VisionAutomaticModeStateMachine defined in Section VisionAutomaticModeStateMachineType. The reason for this naming is that this state machine is derived – but not restricted to – the typical application of a vision system in automatic operation on a production line.State machine type hierarchy

The following diagram shows the hierarchy of mandatory state machine types in this specification. All state machine types are derived from the FiniteStateMachineType, implying that all their states and transitions are pre-defined and cannot be changed or added to by sub-typing so that a client can detect all states and transitions and rely on these and only these states and transitions to exist on sub-types of the state machine type

Figure 21 – Vision system state machine type hierarchy

In the state machines specified here, most transitions can be caused by method calls and all transitions can be caused by internal decisions of the vision system. We call these “automatic” transitions.

In the state diagrams describing the state machines in the following sections, all transitions are shown individually. Transitions caused by methods are shown in black with the method name as the UML transition trigger. “Automatic” transitions are shown in orange without a trigger.

Upon entry into a new state, a StateChanged Event will be triggered indicating the transition.

Some transitions may trigger extra events. These events are shown in the state diagrams on the transition as a UML effect, preceded by a “/”.

Some transitions may depend on conditions. Where they are semantically important, they have been put into the state diagrams as UML guards in “[]”.

The server can prevent transitions from being carried out, e.g. due to the internal state of the vision system. A typical example would be to prevent leaving the parent state of a VisionStepModelStateMachine in order to avoid interrupting synchronization with an external system.

As automatic transitions are always done for internal reasons, the server will obviously simply not execute the transition in this case.

For method-triggered transitions, the server should set the Executable flag of the method in question to False to signal to clients that this method should currently not be called. If the method is called anyway, regardless of the Executable flag, the method shall fail with an appropriate error code.