VisionAutomaticModeStateMachineType is an ObjectType subtype of FiniteStateMachineType and represents the behavior of a vision system in automatic operation.

The conceptual idea is that of a vision system installed on a production line for inline inspection or process control. This is taken in a very broad sense to cover other situations easily, like sample test stations where a human operator starts the inspection jobs or robot-mounted systems for position guidance. Thus, the state machine reflects the goal of specifying a system to be easily integrated into automated production and inspection systems.

The Operational state of the VisionStateMachineType has a mandatory SubStateMachine of the VisionAutomaticModeStateMachineType, indicating that this mode of operation shall always be present in a vision system conforming to this specification.

This SubStateMachine is typically entered by a transition from state Preoperational to its internal state Initialized, either an automatic transition or caused by the SelectModeAutomatic method

It can also be entered by automatic transitions from state Error to any of its internal states. These transitions exist to allow the vision system to try after resolving an error to resume operation with the “highest possible state”. That means, when the error occurs in SingleExecution state, the vision system will try to resume and finish this operation. Failing that, it will try to return to Ready state for the next Start method; failing that, it will return to state Initialized to be made Ready again. Note however, that the method of resolving an error and resuming operation after the Error state is defined by the vision system, not this specification.

In the following state diagram, method-triggered transitions are again black with the method written as UML trigger; automatic transitions are orange with a possible event as UML effect introduced with a “/”.

To clarify the entire context, the other main states are also shown in Figure 24. For clarity, transitions from the top-level VisionStateMachine into states of the VisionAutomaticModeStateMachine are not shown in the diagram.

Figure 24 – States and transitions of the VisionAutomaticModeStateMachineType

Interactions between external systems and the global “AutomaticMode” state machine are limited to few transitions in the model which we will see in detail in the description of methods and transitions. The most prominent points are obviously the Start-methods, typically used by a client to start operation of a vision system.

However, there is frequently a need to synchronize operations between the vision systems and external systems where the vision system remains conceptually in one of the states of the “AutomaticMode” state machine. The most obvious example is that of taking images of a part from various positions, either by moving the part relative to a camera system, handling it with a robot arm, or by moving the camera relative to the part, again possibly by a robot manipulator. This entire interaction would conceptually take place within SingleExecution state or ContinuousExecution state.

To enable all states in the “AutomaticMode” state machine to carry out such interactions, each is marked as a complex state by the symbol, and has an optional SubStateMachine of the VisionStepModelStateMachineType.

The AutomaticMode state machine is entered from state Preoperational of the VisionStateMachineType either by an automatic operation or by the SelectModeAutomatic method.

A call to SelectModeAutomatic causes transition to state Initialized. Alternatively, the system can automatically transition into Initialized.

It is expected that within the states Initialized and Ready, the system can carry out management operations, with recipes and configurations. In order to carry out automatic evaluations, at least one recipe needs to be prepared in the system.

Recipe management is very system- and application-specific and correspondingly hard to generalize. Therefore, systems may exhibit different state transition behavior caused by recipe management methods, according to their capabilities. This is described in detail in Annex B.1 and the definition of the RecipeManagementType in chapter 7.5.

At some point, the system will be in Ready state. The simplest way will typically be a single call to AddRecipe and to PrepareRecipe to load and prepare a single recipe.

It is expected that in state Ready the system can at any time start an evaluation operation. This operation is denoted as a “job”. The “AutomaticMode” state machine defines two distinct methods of carrying out evaluation, namely “single job” operation and “continuous” operation.

Typical examples for SingleJob operation are the inspection of individual work pieces. Typical examples for Continuous operation are web inspection, package sorting, etc. The main differences between these two types of jobs are:

• With a SingleJob, the client starting the job can reasonably expect it to end after an application-specific, but finite time; a Continuous job will typically not end on its own, so the notion of a timeout is meaningless.
• Within a SingleJob, typically an AcquisitionDone event will be triggered at some point, informing the environment that all required data has been acquired so that the inspection part can leave the field of view of the camera, either by moving the part or the camera.

The image processing operation is accordingly started by one of two start methods, StartSingleJob or StartContinuous.

In single job as well as in continuous operation, the system can produce an arbitrary number of results, all of them partial with the exception of the last one. Whenever a partial or final result is available, the system shall trigger a ResultReady event with a result ID.

The result can then be retrieved by one of the GetResult method calls or directly from the ResultContent Component of the ResultReady event if it is included in the event Typically, the result will be available through a GetResult method call even if included with the ResultReady event, however the client cannot make assumptions about the result management of the vision system. This has to be treated in an application-specific way.

A call to the StartSingleJob method will cause a transition into state SingleExecution, where the system will typically acquire data and, once it has finished acquiring data, will fire an AcquisitionDone event. Note that there is no temporal relationship between the system returning to the Ready state and the completion of image acquisition or processing for the job triggered by a Start method. The system can already have left state SingleExecution to Ready, it can even accept another Start method call and carry out the next job, before the AcquisitionDone event for the previous job occurs, if the system is capable of handling several image acquisitions and/or image evaluations simultaneously.

From the point of view of the OPC UA client, the state machine is always carrying out one job only. However, there may be evaluation process of several jobs running in parallel on the system and may trigger AcquisitionDone events as well as ResultReady events.

Whenever the system is ready for the next StartSingleJob method, it will transition into the Ready state again.

A call to the StartContinuous method will cause a transition into state ContinuousExecution, where the system will continuously acquire and process data.

This state models the behavior of systems like textile inspection systeme, package sorting machines, monitoring and surveillance systems, which do not expect start commands for individual work pieces but constantly acquire and process data.

The system may go back to the Ready state, automatically due to internal conditions, or by calling the Abort or Stop methods.

The Stop and Abort methods offer two different means of finishing operation in the “Executing” states, with the intention that the system transitions to the Ready state.

Both can be considered intended interruptions of a running system, in contrast to an error or the complete stopping of operations by Reset and Halt methods.

The difference between the two methods is:

• In response to an Abort method call, the system is expected to end running operation and transition to the Ready state as fast as possible, without regard to acquired or computed data.
• In response to a Stop method call, the system is expected to end running operation and transition to the Ready state as soon as possible while retaining as much result data as possible. It is expected that results will become available for all images acquired before the Stop method was called.

These methods shall always be executable. If for some reason the vision system is not capable of carrying out this transition, the method shall fail with an appropriate status code, typically Bad_InternalError, and the state machine shall transition into the Error state.

For example, depending on the camera / sensor used, it may not be possible to interrupt the acquisition process arbitrarily from the outside.

As described in Section 8.1.2.1 the VisionAutomaticMode SubStateMachine of the Operational state can be entered in two different ways:

• From the Preoperational state of the parent state machine through an automatic transition or a transition triggered by the SelectModeAutomatic method into the Initialized state of the VisionAutomaticModeStateMachine. In these cases, the parent state machine transitions into the parent state Operational implicitly.
• From the Error state of the parent state machine through an automatic transition into the Operational state of the parent state machine. In this case the server will decide based on the conditions in the vision system in which state of the VisionAutomaticModeStateMachine the system ends up.

Figure 25 shows these ways; for clarity, all other transitions have been left out. The transitions from the Preoperational state are shown as solid lines as they are actually modelled in the type definition. The transitions from the Error state are shown in dashed lines as they are not explicitly modelled but only “virtual” transitions decided by the server internally.

Figure 25 – Entering the VisionAutomaticModeStateMachine SubStateMachine

Figure 26 – Overview VisionAutomaticModeStateMachineType

VisionAutomaticModeStateMachineType is formally defined in Table 96.

Table 96 – VisionAutomaticModeStateMachineType definition

Attribute	Value
	Includes all attributes specified for the FiniteStateMachineType
BrowseName	VisionAutomaticModeStateMachineType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the FiniteStateMachineType defined in OPC 10000-5 Annex B.4.5
HasComponent	Object	Initialized	--	StateType
HasComponent	Object	Ready	--	StateType
HasComponent	Object	SingleExecution	--	StateType
HasComponent	Object	ContinuousExecution	--	StateType
HasComponent	Object	InitializedToReadyRecipe	--	TransitionType
HasComponent	Object	InitializedToReadyProduct	--	TransitionType
HasComponent	Object	InitializedToReadyAuto	--	TransitionType
HasComponent	Object	ReadyToInitializedRecipe	--	TransitionType
HasComponent	Object	ReadyToInitializedProduct	--	TransitionType
HasComponent	Object	ReadyToInitializedAuto	--	TransitionType
HasComponent	Object	ReadyToSingleExecution	--	TransitionType
HasComponent	Object	ReadyToSingleExecutionAuto	--	TransitionType
HasComponent	Object	ReadyToContinuousExecution	--	TransitionType
HasComponent	Object	ReadyToContinuousExecutionAuto	--	TransitionType
HasComponent	Object	SingleExecutionToReadyStop	--	TransitionType
HasComponent	Object	SingleExecutionToReadyAbort	--	TransitionType
HasComponent	Object	SingleExecutionToReadyAuto	--	TransitionType
HasComponent	Object	ContinuousExecutionToReadyStop	--	TransitionType
HasComponent	Object	ContinuousExecutionToReadyAbort	--	TransitionType
HasComponent	Object	ContinuousExecutionToReadyAuto	--	TransitionType
HasComponent	Method	Stop	--		Mandatory
HasComponent	Method	Abort	--		Mandatory
HasComponent	Method	StartSingleJob	--		Mandatory
HasComponent	Method	StartContinuous	--		Mandatory
HasComponent	Method	SimulationMode	--		Optional
HasComponent	Object	InitializedStepModel	--	VisionStepModelStateMachineType	Optional
HasComponent	Object	ReadyStepModel	--	VisionStepModelStateMachineType	Optional
HasComponent	Object	SingleExecutionStepModel	--	VisionStepModelStateMachineType	Optional
HasComponent	Object	ContinuousExecutionStepModel	--	VisionStepModelStateMachineType	Optional

Table 97 specifies the VisionAutomaticStateMachine’s state Objects. These state Objects are instances of the StateType defined in OPC 10000-5 – Annex B. Each state is assigned a unique StateNumber value.

See Table 98 for a brief description of the states. The states will be detailed in the following subsections.

Table 97 – VisionAutomaticModeStateMachineType States

Browse Name	References	Target BrowseName	Value	Target Type Definition	Notes
Initialized	HasProperty	StateNumber	5	PropertyType	--
	FromTransition	ReadyToInitializedRecipe		TransitionType	--
	FromTransition	ReadyToInitializedProduct		TransitionType	--
	FromTransition	ReadyToInitialzedAuto		TransitionType	--
	ToTransition	InitializedToReadyRecipe		TransitionType	--
	ToTransition	InitializedToReadyProduct		TransitionType	--
	ToTransition	InitializedToReadyAuto		TransitionType	--
	HasSubstateMachine	InitializedStepModel		VisionStepModelStateMachineType	--
Ready	HasProperty	StateNumber	6	PropertyType	--
	FromTransition	InitializedToReadyRecipe		TransitionType	--
	FromTransition	InitializedToReadyProduct		TransitionType	--
	FromTransition	InitlializedToReadyAuto		TransitionType	--
	FromTransition	SingleExecutionToReadyStop		TransitionType	--
	FromTransition	SingleExecutionToReadyAbort		TransitionType	--
	FromTransition	SingleExecutionToReadyAuto		TransitionType	--
	FromTransition	ContinuousExecutionToReadyStop		TransitionType	--
	FromTransition	ContinousExecutionToReadyAbort		TransitionType	--
	FromTransition	ContinousExecutionToReadyAuto		TransitionType	--
	ToTransition	ReadyToInitializedRecipe		TransitionType	--
	ToTransition	ReadyToInitializedProduct		TransitionType	--
	ToTransition	ReadyToInitializedAuto		TransitionType	--
	ToTransition	ReadyToSingleExecution		TransitionType	--
	ToTransition	ReadyToSingleExecutionAuto		TransitionType	--
	ToTransition	ReadyToContinuousExecution		TransitionType	--
	ToTransition	ReadyToContinuousExecutionAuto		TransitionType	--
	HasSubstateMachine	ReadyStepModel		VisionStepModelStateMachineType	--
SingleExecution	HasProperty	StateNumber	7	PropertyType	--
	FromTransition	ReadyToSingleExecution		TransitionType	--
	FromTransition	ReadyToSingleExecutionAuto		TransitionType	--
	ToTransition	SingleExecutionToReadyStop		TransitionType	--
	ToTransition	SingleExecutionToReadyAbort		TransitionType	--
	ToTransition	SingleExecutionToReadyAuto		TransitionType	--
	HasSubstateMachine	SingleExecutionStepModel		VisionStepModelStateMachineType	--
ContinuousExecution	HasProperty	StateNumber	8	PropertyType	--
	FromTransition	ReadyToContinuousExecution		TransitionType	--
	FromTransition	ReadyToContinuousExecutionAuto		TransitionType	--
	ToTransition	ContinuousExecutionToReadyStop		TransitionType	--
	ToTransition	ContinousExecutionToReadyAbort		TransitionType	--
	ToTransition	ContinousExecutionToReadyAuto		TransitionType	--
	HasSubstateMachine	ContinuousExecutionStepModel		VisionStepModelStateMachineType	--

Table 98 – VisionAutomaticModeStateMachineType State Descriptions

StateName	Description
Initialized	This state indicated that the vision system is sufficiently initialized so that management operations like configuration and recipe management can be carried out through the server, if the optional management objects exist.
Ready	This state indicates that the vision system is capable of being started to carry out jobs, e.g. through Start methods called on the server.
SingleExecution	This state indicates that the vision system will acquire the data required for carrying out a single inspection or measuring job and will finish whatever operations are necessary to return to the Ready state to accept the next job.
ContinuousExecution	This state indicates that the vision system continually acquires and processes data, until it is stopped by internal or external reasons, e.g. calling the Stop or Abort methods on the server.

In this state, the system is characterized by the following properties:

• The system is able to perform management and operations.
• Configurations can be managed by methods detailed in Section 7.2.
• Recipes can be managed by methods detailed in Sections 7.5, 7.6, 7.7.
• One or more recipes can be prepared by the PrepareRecipe method such that these are ready to be used in processing operations.
• Results can be pulled from the internal result-store by the methods detailed in Section 7.10.
• The system can be put into simulation mode (see Section 8.3.7.5).

This state will be the first state entered in the VisionAutomaticModeStateMachine when the superior VisionStateMachine enters the Operational state either by an automatic transition from Preoperational or by a SelectModeAutomatic method call.

If an error is dectected which suspends normal operation, the system will change to the Error state in the VisionStateMachine.

This state can be left in the following ways:

• Into Ready state by a PrepareRecipe method call.
• Into Preoperational state of the VisionStateMachine by a Reset method call.
• Into Halted state of the VisionStateMachine by a Halt method call.
• Into Error state of the VisionStateMachine by an internal error.

All method-triggered transitions can also occur automatically upon an internal decision of the system.

This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.

In this state, the system is characterized by the following properties:

• The vision system has prepared one or more recipes such that they can be used for processing immediately upon a StartSingleJob or StartContinuous method call (unless it is a system without any recipe management).
• The vision system is ready to accept either a StartSingleJob or a StartContinuous method to begin image processing operation.
• Recipes can be added and retrieved by methods detailed in Sections 7.5, 7.6, 7.7.
• Which recipes are ready for use can be changed by calling the PrepareRecipe method depending on the recipe handling capabilities of the system.
• Results can be pulled from the internal result-store by the methods detailed in Section 7.5.
• The vision system can be put into simulation mode (see Section 8.3.7.5).

Depending on the recipe handling capabilities of the vision system, calling an AddRecipe or PrepareRecipe method in this state may cause the system to fall back into Initialized state, temporarily preventing it from accepting Start methods.

If an error is dectected which suspends normal operation, the system will transition to Error state in the VisionStateMachine.

This state can be left in the following ways:

• Into the SingleExecution state by a StartSingleJob method call.
• Into the ContinuousExecution state by a StartContinuous method call.
• Into the Initialized state by an UnprepareRecipe method call.
• Into the Preoperational state of the VisionStateMachine by a Reset method call.
• Into the Halted state of the VisionStateMachine by a Halt method call.
• Into the Error state of the VisionStateMachine by an internal error.

All method-triggered transitions can also occur automatically upon an internal decision of the system.

This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.

In this state, the system is characterized by the following properties:

• The vision system has received a command to begin the execution of an individual job (measuring, inspection, identifying, …), e.g. by a call to the StartSingleJob method on the server.
• The vision system collects sensor data (i.e. acquiring single or multiple images, possibly awaiting triggers, often in hardware).
• If data acquisition is a “multi-stage-process” (interaction with other devices) this may be modelled with a VisionStepModelType SubStateMachine (all states allow for this, but this is the most typical application, therefore we emphasize it here).
• The vision system may indicate to the client by an AcquisitionDone event that acquisition has been finished, e.g. as a signal that the part can be removed from the camera’s field of view, either by moving the part or he camera.
• The vision system carries out the processing of the acquired data at least so far that the internal resources are available to transition into state Ready to accept the next start command.
• Results can be pulled from the internal result-store by the methods detailed in Section 7.5 (depending on the capabilities of the system).

Note that the above description illustrates a typical behavior. The vision system is, however, in no way obliged to perform any particular operation – like image acquisition or processing – in this state. It can do completely different things or nothing at all before returning to Ready state. The point is rather that the difference between SingleExecution state and Ready state lies in the availability of the required resources for starting a job.

If an error is detected which suspends normal operation, the system will change to state Error in the VisionStateMachine.

This state can be left in the following ways:

• into the Ready state by an automatic transition when the required resources are available. The system shall trigger a Ready event in this case. Note that this is in no way related to the vision system completing an image acquisition or evaluation and/or producing a result.
• Into the Ready state by the methods Stop and Abort, see Section 8.3.2.4 for details.
• Into the Preoperational state of the VisionStateMachine by a Reset method call.
• Into the Halted state of the VisionStateMachine by a Halt method call.
• Into the Error state of the VisionStateMachine by an internal error.

All method-triggered transitions can also occur automatically upon an internal decision of the system.

This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.

In this state, the system is characterized by the following properties:

• The vision system has received a StartContinuous command to begin the execution of a continuous job
• The vision system collects sensor data (i.e. acquiring single or multiple images, possibly awaiting triggers, often in hardware) and processes this in a continuously ongoing fashion.
• Results can be pulled from the internal result-store by the methods detailed in Section 7.5 (depending on the capabilities of the system).

Note that the above description illustrates a typical behavior. The vision system is, however, in no way obliged to perform any particular operation – like image acquisition or processing – in this state. It can do completely different things or nothing at all before returning to Ready state. The point is rather that the difference between ContinuousExecution state and Ready state lies in the availability of the required resources for starting a job.

If an error is detected which suspends normal operation, the system will change to the Error state in the VisionStateMachine.

This state can be left in the following ways:

• Into the Ready state by Stop and Abort method calls, see Section 8.3.2.4 for details.
• Into the Preoperational state of the VisionStateMachineType by a Reset method call.
• Into the Halted state of the VisionStateMachineType by a Halt method call.
• Into the Error state of the VisionStateMachineType by an internal error.

All method-triggered transitions can also occur automatically upon an internal decision of the system.

This state can be a composite state with an optional VisionStepModelStateMachineType SubStateMachine.

Transitions are instances of Objects of the TransitionType defined in OPC 10000-5 – Annex B which also includes the definitions of the ToState, FromState, HasCause, and HasEffect References used. Table 99 specifies the Transitions defined for the VisionStateMachineType. Each Transition is assigned a unique TransitionNumber.

Table 99 – VisionAutomaticModeStateMachineType transitions

BrowseName	References	Target BrowseName	Value	Target TypeDefinition	Notes
InitializedToReadyRecipe	HasProperty	TransitionNumber	561	PropertyType	--
	FromState	Initialized		StateType	--
	ToState	Ready		StateType	--
	HasCause	PrepareRecipe		Method	--
	HasEffect	StateChangedEventType			--
	HasEffect	RecipePreparedEventType			--
InitializedToReadyProduct	HasProperty	TransitionNumber	562	PropertyType	--
	FromState	Initialized		StateType	--
	ToState	Ready		StateType	--
	HasCause	PrepareProduct		Method	--
	HasEffect	StateChangedEventType			--
	HasEffect	RecipePreparedEventType			--
InitializedToReadyAuto	HasProperty	TransitionNumber	560	PropertyType	--
	FromState	Initialized		StateType	--
	ToState	Ready		StateType	--
	HasEffect	StateChangedEventType			--
ReadyToInitializedRecipe	HasProperty	TransitionNumber	651	PropertyType	--
	FromState	Ready		StateType	--
	ToState	Initialized		StateType	--
	HasCause	UnprepareRecipe		Method	--
	HasEffect	StateChangedEventType			--
ReadyToInitializedProduct	HasProperty	TransitionNumber	652	PropertyType	--
	FromState	Ready		StateType	--
	ToState	Initialized		StateType	--
	HasCause	UnprepareProduct		Method	--
	HasEffect	StateChangedEventType			--
ReadyToInitializedAuto	HasProperty	TransitionNumber	650	PropertyType	--
	FromState	Ready		StateType	--
	ToState	Initialized		StateType	--
	HasEffect	StateChangedEventType			--
ReadyToSingleExecution	HasProperty	TransitionNumber	671	PropertyType	--
	FromState	Ready		StateType	--
	ToState	SingleExecution		StateType	--
	HasCause	StartSingleJob		Method	--
	HasEffect	StateChangedEventType			--
	HasEffect	JobStartedEventType			--
ReadyToSingleExecutionAuto	HasProperty	TransitionNumber	670	PropertyType	--
	FromState	Ready		StateType	--
	ToState	SingleExecution		StateType	--
	HasEffect	StateChangedEventType			--
	HasEffect	JobStartedEventType			--
ReadyToContinuousExecution	HasProperty	TransitionNumber	681	PropertyType	--
	FromState	Ready		StateType	--
	ToState	ContinuousExecution		StateType	--
	HasCause	StartContinuous		Method	--
	HasEffect	StateChangedEventType			--
	HasEffect	JobStartedEventType			--
ReadyToContinuousExecutionAuto	HasProperty	TransitionNumber	680	PropertyType	--
	FromState	Ready		StateType	--
	ToState	ContinuousExecution		StateType	--
	HasEffect	StateChangedEventType			--
	HasEffect	JobStartedEventType			--
SingleExecutionToReadyAuto	HasProperty	TransitionNumber	760	PropertyType	--
	FromState	SingleExecution		StateType	--
	ToState	Ready		StateType	--
	HasEffect	StateChangedEventType			--
	HasEffect	ReadyEventType			--
SingleExecutionToReadyStop	HasProperty	TransitionNumber	761	PropertyType
	FromState	SingleExecution		StateType	--
	ToState	Ready		StateType	--
	HasCause	Stop		Method	--
	HasEffect	StateChangedEventType			--
	HasEffect	ReadyEventType			--
SingleExecutionToReadyAbort	HasProperty	TransitionNumber	762	PropertyType	--
	FromState	SingleExecution		StateType	--
	ToState	Ready		StateType	--
	HasCause	Abort		Method	--
	HasEffect	StateChangedEventType			--
	HasEffect	ReadyEventType			--
ContinuousExecutionToReadyAuto	HasProperty	TransitionNumber	860	PropertyType	--
	FromState	ContinuousExecution		StateType	--
	ToState	Ready		StateType	--
	HasEffect	StateChangedEventType			--
	HasEffect	ReadyEventType			--
ContinuousExecutionToReadyStop	HasProperty	TransitionNumber	861	PropertyType	--
	FromState	ContinuousExecution		StateType	--
	ToState	Ready		StateType	--
	HasCause	Stop		Method	--
	HasEffect	StateChangedEventType			--
	HasEffect	ReadyEventType			--
ContinuousExecutionToReadyAbort	HasProperty	TransitionNumber	862	PropertyType	--
	FromState	ContinuousExecution		StateType	--
	ToState	Ready		StateType	--
	HasCause	Abort		Method	--
	HasEffect	StateChangedEventType			--
	HasEffect	ReadyEventType			--

Calling this method on the server is used to start a single execution type job in the vision system which will be reflected by transition from the Ready state to the SingleExecution state.

Signature

StartSingleJob ([in]MeasIdDataTypemeasId,[in]PartIdDataTypepartId,[in]RecipeIdExternalDataTyperecipeId[in]ProductIdDataTypeproductId[in]BaseDataType[]parameters[out]JobIdDataTypejobId[out]Int32error);

Table 100 – StartSingleJob Method Arguments

Argument	Description
measId	Identifies the measuring or inspection run from the point of view of the client. May be empty.
partId	Identifies the part to be measured or inspected from the point of view of the client. The partId may be identical on different measIDs, e.g. for repeat measurements in capability tests. May be empty.
recipeId	If not empty, it must be the ExternalId of a prepared recipe which is to be used by this job.
productId	It not empty, it must be the ProductId of a product for which a recipe has been prepared which is to be used by this job.
parameters	List of parameters for this particular execution of the recipe; number and type of the parameters are recipe-specific, so the client may need to re-browse the method signature after a change in recipe preparation.
jobId	A system-wide unique identification of the job. This argument must be returned.
error	0 – OK Values > 0 are reserved for errors defined by this and future standards. Values < 0 shall be used for application-specific errors.

Table 101 – StartSingleJob Method AddressSpace Definition

Attribute	Value
BrowseName	StartSingleJob
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	InputArguments	Argument[]	PropertyType	Mandatory
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory

It is expected that clients work either recipe-based or product-based, i.e. that a client gives either the RecipeId argument or the ProductId argument. Recipe and product management being the province of the vision system, it is implementation defined how the vision system reacts to none or both be given

Typical possibilities are that a system without recipe management or with only a single prepared recipe can use this recipe to execute a job and accept both parameters to be empty, whereas a system with multiple prepared recipes would probably consider it an error if both are empty and decide based on internal rules which takes precedence if both are given.

Results are to be marked with as many of the identification values as possible to allow for unique identification and flexible filtering, i.e., it is expected that the server uses all meta data elements provided by the client and supported by the server profile to mark the results, filter the results, and fill the ResultReady event.

The jobId is mandatory to be returned and to be included in results.

Restarting with the same measId can lead to identical or different jobIds, depending on the application. It is therefore not reliably possible to use multiple calls with the same measId to query for jobIds.

The parameters argument is intended for filling free parameters of a recipe with concrete values for the given job. Its structure is therefore dependent on the recipe used. The server will have to instantiate this method with an application-specific parameter structure before entering the Ready state. The server may re-instantiate this method with a different parameter structure after preparing a different recipe. In the case of several recipes being in prepared state at the same time, this structure is expected to be the superset of parameters required by the prepared recipes. The client will have to browse for the actual argument structure of the method at least once before calling a Start method (in the case of a system without recipe management) and application-specific potentially after each call to PrepareRecipe.

Calling this method on the server is used to start a continuous execution type job in the vision system which will be reflected by transition from the Ready state to the ContinuousExecution state. It has the same signature and semantics as method StartSingleJob described in Section 8.3.7.1.

Table 102 – StartContinuous Method AddressSpace Definition

Attribute	Value
BrowseName	StartContinuous
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	InputArguments	Argument[]	PropertyType	Mandatory
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory

In response to an Abort call on the server, the vision system is expected to end running operation and transition to the Ready state as fast as possible, without regard to acquired or computed data.

See the general remarks on Stop and Abort methods in Section 8.3.2.4 for further information on the behavior.

Signature

Abort ([in]Int32cause[in]StringcauseDescription[out]Int32error);

Table 103 – Abort Method Arguments

Argument	Description
cause	Implementation-specific number denoting the reason for the Abort command.
causeDescription	Text for said reason, e.g. for logging purposes. May be empty.
error	0 – OK Values > 0 are reserved for errors defined by this and future standards. Values < 0 shall be used for application-specific errors.

Table 104 – Abort Method AddressSpace Definition

Attribute	Value
BrowseName	Abort
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	InputArguments	Argument[]	PropertyType	Mandatory
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory

The cause argument given to the method can only be interpreted by the underlying vision system It can be used, for example, for logging purposes. It is expected that a value of 0 will be considered an “unspecified reason”.

In response to a Stop method call on the server, the vision system is expected to end running operation and transition to state Ready as soon as possible while retaining as much result data as possible.

See the general remarks on Stop and Abort in 8.3.2.4 for further information on the behavior.

Signature

Stop ([in]Int32cause[in]StringcauseDescription[out]Int32error);

Table 105 – Stop Method Arguments

Argument	Description
cause	Implementation-specific number denoting the reason for the Stop command.
causeDescription	Text for said reason, e.g. for logging purposes. May be empty.
error	0 – OK Values > 0 are reserved for errors defined by this and future standards. Values < 0 shall be used for application-specific errors.

Table 106 – Stop Method AddressSpace Definition

Attribute	Value
BrowseName	Stop
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	InputArguments	Argument[]	PropertyType	Mandatory
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory

The cause argument given to the method can only be interpreted by the underlying vision system It can be used, for example, for logging purposes. It is expected that a value of 0 will be considered an “unspecified reason”.

This method puts the system into a system-specific special mode of operation. It is expected that this mode does one or all of the following things:

• Simulate hardware (for tests on notebook)
• Produce simulated results (for tests within the line)
• Simulate parts of a recipe

It is mandatory that each result produced by the system when simulation mode is on must be marked with a simulation flag.

Signature

SimulationMode ([in]Booleanactivate[in]Int32cause[in]StringcauseDescription[out]Int32error);

Table 107 – SimulationMode Method Arguments

Argument	Description
activate	Switch simulation on (true) or off (false)
cause	Implementation specific number which the server can use, e.g. to control the simulation in a specific way
causeDescription	String describing the reason for the call, for logging purposes May be empty.
error	0 – OK Values > 0 are reserved for errors defined by this and future standards. Values < 0 shall be used for application-specific errors.

Table 108 – SimulationMode Method AddressSpace Definition

Attribute	Value
BrowseName	SimulationMode
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	InputArguments	Argument[]	PropertyType	Mandatory
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory

RecipePreparedEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event shall be triggered by the server when the preparation of a recipe is completed on the vision system. Figure 27 defines the structure. It is formally defined in Table 109.

Typically, if the RecipeManagementType object is carried out by the server in a synchronous manner, this event will be triggered before the method returns, but there is no specified temporal relationship between the call to the PrepareRecipe method and the triggering of the event (except for the obvious that the event cannot occur before the call).

The same holds for the PrepareProduct method of the RecipeManagementType object which, in effect, also prepares a recipe.

An important special case, described in Section B.1.2.3, is local editing of an already prepared recipe. Since after local editing has finished, the recipe is a different one than before, effectively a new recipe has been prepared. Therefore, local editing of a prepared recipe shall generate a RecipePrepared event.

The RecipePrepared event transports the identification of the prepared recipe. If the event was caused by a PrepareProduct method call, it also transports the ProductId, otherwise the ProductId shall be empty.

Figure 27 – Overview RecipePreparedEventType

Table 109 – Definition of RecipePreparedEventType

Attribute	Value
BrowseName	RecipePreparedEventType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseEventType defined in OPC 10000-5
HasProperty	Variable	ExternalId	RecipeIdExternalDataType	PropertyType	Optional
HasProperty	Variable	InternalId	RecipeIdInternalDataType	PropertyType	Mandatory
HasProperty	Variable	ProductId	ProductIdDataType	PropertyType	Optional

JobStartedEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server when the state machine transitions from the Ready state to the SingleExecution or ContinuousExecution state. Figure 28 defines the structure. It is formally defined in Table 110.

It indicates to the client that the vision system has started the execution of a job, regardless whether the transition occurred due to a call to the StartSingleJob or StartContinuous method or automatically due, e.g. for a fieldbus start signal.

The event transports the jobId created upon the transition from state Ready to state SingleExecution or ContinuousExecution. This enables clients to maintain a time-sequential log of jobs, regardless whether this particular client started the job or whether the job was started by an OPC UA method call at all.

In the case of multiple running state machines in the same server, the client can use the Source property inherited from BaseEventType to identify the state machine instance the event originated from.

Figure 28 – Overview JobStartedEventType

Table 110 – Definition of JobStartedEventType

Attribute	Value
BrowseName	JobStartedEventType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseEventType defined in OPC 10000-5
HasProperty	Variable	JobId	JobIdDataType	PropertyType	Mandatory

ReadyEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server when the state machine transitions to the Ready state from one of the “Execution” states, i.e. SingleExecution or ContinuousExecution. Figure 29 defines the structure. It is formally defined in Table 111.

It indicates to the client that the vision system has the necessary resources available for executing the next job. The client still has to make sure that the state machine is actually in the Ready state before calling the StartSingleJob or StartContinuous method as the vision system may fall out of the Ready state due to internal reasons or other method calls

The event transports the jobId created upon the transition from state Ready to state SingleExecution or ContinuousExecution. Together with the JobStarted event this enables clients to maintain a time-sequential log of state changes for each job.

In the case of multiple running state machines in the same server, the client can use the Source property inherited from BaseEventType to identify the state machine instance the event originated from.

Figure 29 – Overview ReadyEventType

Table 111 – Definition of ReadyEventType

Attribute	Value
BrowseName	ReadyEventType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseEventType defined in OPC 10000-5
HasProperty	Variable	JobId	JobIdDataType	PropertyType	Mandatory

ResultReadyEvent is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server when the vision system has a complete or partial result available for the client. Figure 30 defines the structure. It is formally defined in Table 112.

To enable access to a result, several properties of the result, which are generated by the system, are supplied. These properties can be used to query the results in the ResultManagement object. A sufficiently small result can also be provided in the ResultContent component of the event.

The ResultReadyEvent is not shown explicitly in the state machine as it is not connected to a state transition.

Figure 30 – Overview ResultReadyEventType

Table 112 – Definition of ResultReadyEventType

Attribute	Value
BrowseName	ResultReadyEventType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseEventType defined in OPC 10000-5
HasProperty	Variable	IsPartial	Boolean	PropertyType	Mandatory
HasProperty	Variable	IsSimulated	Boolean	PropertyType	Optional
HasProperty	Variable	ResultState	ResultStateDataType	PropertyType	Mandatory
HasProperty	Variable	MeasId	MeasIdDataType	PropertyType	Optional
HasProperty	Variable	PartId	PartIdDataType	PropertyType	Optional
HasProperty	Variable	ExternalRecipeId	RecipeIdExternalDataType	PropertyType	Optional
HasProperty	Variable	InternalRecipeId	RecipeIdInternalDataType	PropertyType	Mandatory
HasProperty	Variable	ProductId	ProductIdDataType	PropertyType	Optional
HasProperty	Variable	ExternalConfigurationId	ConfigurationIdDataType	PropertyType	Optional
HasProperty	Variable	InternalConfigurationId	ConfigurationIdDataType	PropertyType	Mandatory
HasProperty	Variable	JobId	JobIdDataType	PropertyType	Mandatory
HasProperty	Variable	ResultId	ResultIdDataType	PropertyType	Mandatory
HasProperty	Variable	CreationTime	UtcTime	PropertyType	Mandatory
HasProperty	Variable	ProcessingTimes	ProcessingTimesDataType	PropertyType	Optional
HasProperty	Variable	ResultContent	BaseDataType[]	PropertyType	Optional

IsPartial

Indicates whether the result is the partial result of a total result.

IsSimulated

Indicates whether the system was in simulation mode when the job generating this result was created.

ResultState

Indicates at what processing state this result was generated.

MeasId, PartId, ExternalRecipeId, InternalRecipeId, ProductId, ExternalConfigurationId, InternalConfigurationId, JobId, ResultId

If the information is somehow linked to one of the (vision system) objects referenced by these Ids, these properties can transport this reference. In particular:

MeasId: This identifier is given by the client when starting a single or continuous execution and transmitted to the vision system. It is used to identify the respective result data generated for this job. Although the system-wide unique JobId would be sufficient to identify the job which the result belongs to, this makes for easier filtering on the part of the client without keeping track of JobIds.

PartId: A PartId is given by the client when starting the job; although the system-wide unique JobId would be sufficient to identify the job which the result belongs to, this makes for easier filtering on the part of the client without keeping track of JobIds.

ExternalRecipeId:

External Id of the recipe in use which produced the result. The ExternalId is only managed by the environment. This will typically be derived from the arguments of the Start method call which caused the result to be created.

InternalRecipeId:

Internal Id of the recipe in use which produced the result. This Id is system-wide unique and it is assigned by the vision system. This will typically be derived from the arguments of the Start method call which caused the result to be created.

ProductId: Id of the product selected to produce the result. This will typically be derived from the arguments of the Start method call which caused the result to be created.

ExternalConfigurationId: External Id of the configuration in effect in the system when the result was produced.

InternalConfigurationId: Internal Id of the configuration in effect in the system when the result was produced.

JobId:

The Id of the job, created by the transition from state Ready to state SingleExecution or to state ContinuousExecution which produced the result.

ResultId: vision-system-wide unique Id, which is assigned by the system. This Id can be used for fetching exactly this result using the methods detailed in Section 7.10.2.

CreationTime

CreationTime indicates the time when the result was created.

ProcessingTimes

Collection of different processing times that were needed to create the result.

ResultContent

Abstract data type to be subtyped from to hold result data created by the selected recipe.

AcquisitionDoneEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server. when the vision system finishes a data acquisition process for a job. Figure 31 shows the structure of the event. It is formally defined in Table 113.

It is not shown explicitly in the state machine diagram as it is not directly connected to a transition.

It indicates to the client that data acquisition for the specified job has finished. In many machines, this will be a signal that the work piece or camera can be moved. Triggering this event during a single or continuous execution is application-specific and not mandatory.

The event provides the JobId created upon the transition from the Ready state to the SingleExecution or ContinuousExecution state. This enables the client to maintain a time-sequential log of state changes for each job and also to match the event to the corresponding start signal.

In the case of multiple running state machines in the same server, the client can use the Source property inherited from BaseEventType to identify the state machine instance the event originated from.

Figure 31 – Overview AcquisitionDoneEventType

Table 113 – Definition of AcquisitionDoneEventType

Attribute	Value
BrowseName	AcquisitionDoneEventType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseEventType defined in OPC 10000-5
HasProperty	Variable	JobId	JobIdDataType	PropertyType	Mandatory

JobId

The Id of the job for which the event was triggered. The JobId is created by the transition from state Ready to state Acquiring.

If a vendor wants to add a mode of operation, the following steps are required:

1. Define a SubType of FiniteStateMachineType describing the behavior of this operation mode, designated here as VendorModeStateMachineType. This SubType shall not have an InitialState to allow for selective activation of operation modes.
2. Define a SubType of VisionStateMachineType which
3. binds an instance of VendorModeStateMachineType as SubStateMachine to the Operational state of this SubType.
4. defines a SelectModeVendor method to trigger a transition into a desired starting state of this SubStateMachine.
5. binds the SelectModeVendor method as additional HasCause to the method-triggered transition from the Preoperational state to the Operational state, i.e., T141 in Table 84 (according to OPC 10000-5 B.4.18, adding causes to a transition is allowed, not however to introduce a new transition, so the existing transition ).
6. contains direct transitions from the Preoperational state into the desired starting state of the VendorModeStateMachine, typically an automatic one and one triggered by SelectModeVendor (again this is allowed by OPC 10000-5, B.4.18).
7. Take care that automatic transitions into the Operational state lead into states of the VendorModeStateMachine in a suitable way, especially for transitions from the Error state to facilitate the error handling described in Section 8.2.2.4.

The designation elements ModeStateMachineType and SelectMode shall be used as shown above. The Vendor part of the designations can be freely chosen.