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