In every state of the VisionStateMachine or any of its SubStateMachines, an error may occur.

The system may also decide to enter state Error by means of an automatic operation if it cannot – or should not – continue its normal operation in the presence of an error. Note that the presence of an error condition does not necessarily cause the system to enter the Error state, it may be capable to continue normal operation in the presence of a signaled error condition. However, it the system does enter the Error state, it is mandatory that it indicates this by activating an error condition.

An error shall be signaled by an appropriate error condition. An arbitrary number of error conditions can be active at any time.

Error conditions are exposed as subtypes of the ConditionType defined in OPC 10000-9 and may have Acknowledge and Confirm methods and the appropriate state handling. It is expected that the calling of these methods has an effect upon the underlying system and/or that the underlying vision system monitors the state of the conditions and uses these in its internal decision making process whether to stay in the Error state or in which state to transition next.

It is assumed that the Acknowledge method will typically be called by a client automatically, indicated that the message has at least been received. The Confirm method will typically be caused by a human interaction, confirming that the cause of the error is remedied.

For convenience, the VisionStateMachine may offer the ConfirmAll method which shall confirm all conditions currently active. The effect on the internal decision making shall be the same as when the methods would have been called individually from the outside.

Thus, in Error state, the system decides either on its own or based on external input, like an acknowledgement or confirmation of the error, and other (non OPC UA) input signals, which state to transition to next.

Upon entering the Error state, an event of type ErrorEventType is triggered, upon leaving to some other state, an ErrorResolved event is triggered, if the error is actually resolved, in addition to the mandatory StateChanged events. Thus, a control system may listen only to the Error and ErrorResolved events monitoring the vision system.

The Error state can be left in the following ways:

• By a call to the Halt or Reset method, transitioning to states Halted and Preoperational respectively. The condition(s) causing the Error state do not necessarily have to be resolved for this transition. Only if they are resolved, an ErrorResolvedEvent shall be triggered.
• By an internal decision of the system to transition into the Halted or Preoperational states. As these states do not constitute normal productive operation of the system, the condition(s) causing the Error state do not necessarily have to be resolved for this transition. Only if they are resolved, an ErrorResolved event shall be triggered. Subsequent action, e.g. a call to ActivateConfiguration in these states may lead to the error being resolved and the system being capable of resuming normal productive operation.
• By an internal decision of the system to transition into the Operational state. As this state constitutes normal productive operation, this transition is only allowed if the condition(s) leading to the Error state are actually resolved. Therefore, an ErrorResolved event shall be triggered in this case.

In the last case, the automatic transition into the Operational state due to the resolving of the error condition(s), the system will actually go into one of the states of the SubStateMachines of the Operational state, using the 3rd method for entering a SubStateMachine described in Section 8.1.2.1 by a server-specific decision about the state.

Thus, the vision system can decide, based on its internal conditions, in which actual state it will continue operation. It may decide that it can immediately continue a job interrupted by the error and return to the SingleExecution or ContinuousExecution states; it may decide that it can immediately take on the next job and return to the Ready state; it may decide that it needs a re-initialization of a recipe and return to the Initialized state. It may even decide that it can resume a synchronization with an external system and return to any state within a VisionStepModelStateMachine inside one of these states.