Usually it is desirable to expose some information on the inner state of the machine vision framework to the outside world. A state machine only covers information on the current control state of the vision system. If an error occurs it transits to the Error state, but offers no information why this happened. Therefore we need additional communication elements that are capable of transporting error messages, warning messages to avoid the occurrence of an error, or any other kind of information helpful for the client.

The kind of errors that may occur and the additional information to be transported are highly application specific. Therefore it is out of scope for this standard to define such things. Instead we are defining a framework of rules on how to structure application specific messages and how messages should interact with the state machine. The goal for this is to make it possible that even a “generic” client without further knowledge of a specific application is able to get a basic picture of the current state of the vision system.

In general each client is free to decide if it reads information from an OPC UA server. There is no mechanism for a server to enforce that a specific client gets a message. But OPC UA offers different levels of client / user interaction that may be selected for information being published.

The message is published at the interface and no feedback is expected to inform the server if the information has been read by any client.

After it is published on the interface the server waits for one client to acknowledge the reception of the message. Usually such an acknowledgement is automatically generated by a client PLC reading the information.

If a message requiring an acknowledgement has been published it will stay active till an acknowledgement has been received, even if the cause triggering this message has already been cleared.

Application Note:

As a Reset method call tries to bring the system back to an initial state it clears all active messages. If an error state could not be cleared the message will show up again after performing the reset.

After the message is published one of the receiving clients has to acknowledge the reception and afterward has to confirm that the server may clear the information. This mechanism is usually used to call for human assistance. The client PLC acknowledges the reception and shows a message on its HMI. After the operator gives the command to continue the PLC sends the confirmation to inform the server.

If the vision System has its own user console such a user confirmation may be entered there. Therefor it is allowed that the vision system may clear the message even without the confirmation received from a client. But it has to wait for the reception of an acknowledgement before doing so.

As a number of messages may be published at the same time the vision system may optionally offer a ConfirmAll method that sets the confirmation for all active messages.

We are defining five classes of informational elements to be exposed on the interface. The classes are distinguished by their severity regarding the influence on the operation of the vision system.

Each message transports its severity represented as a value between 0 and 1000.

This class of lowest severity carries messages for debugging and diagnostic purposes. It may safely be ignored by clients.

This class may be used for messages that do not require that any client reads them for the normal operation. The vision system is able to safely continue normal operation even if this message is ignored.

A message of this class has a midlevel severity. The server can decide if for a specific message an acknowledgement, or acknowledgement and confirmation may be needed.

If on the vision system side a condition arises that could affect the normal operation of the system a message of this class should be created. An error message requires an acknowledgement from the client side. The server may decide that also a confirmation is needed.

This highest class of severity is used for error messages associated with problems that need human interaction. This kind of errors cannot automatically be solved, an operator has to do something in the physical world before the operation can go on. Acknowledgement and confirmation is mandatory for this class.

Table 128 – Information Elements

Information Type

Severity

needs Acknowledge

needs Confirmation

OPC UA Type

Persistent Error

801...1000

yes

yes

VisionPersistentErrorConditionType

Error

601...800

yes

optional

VisionErrorConditionType

Warning

401...600

optional

optional

VisionWarningConditionType

Information

201...400

no

no

VisionInformationEventType

Diagnostic Information

1…200

no

no

VisionDiagnosticInfoEventType

VisionEvents are generated to signal noteworthy events during the operation of the vision system which do not require interaction.

All non-inherited properties are optional and stay optional on the concrete sub-types because these EventTypes will be used under very different operational circumstances in the vision system; it is therefore not possible to specify that, e.g. a jobId shall be mandatory, since an event may be triggered during the preparation of a recipe, when no job is running.

However, the intention is for the server to provide as much information to the client as possible, i.e. fill as many properties as possible.

The EventType for VisionEvents is formally defined in Table 129.

image046.png

Figure 38 – Overview VisionEventType

Table 129 – VisionEventType Definition

Attribute

Value

BrowseName

VisionEventType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in OPC 10000-5

HasSubtype

ObjectType

VisionDiagnosticInfoEventType

Defined in 11.4.2

HasSubtype

ObjectType

VisionInformationEventType

Defined in 11.4.3

HasProperty

Variable

CausePath

String

PropertyType

Optional

HasProperty

Variable

MeasId

MeasIdDataType

PropertyType

Optional

HasProperty

Variable

PartId

PartIdDataType

PropertyType

Optional

HasProperty

Variable

ExternalRecipeId

RecipeIdExternalDataType

PropertyType

Optional

HasProperty

Variable

InternalRecipeId

RecipeIdInternalDataType

PropertyType

Optional

HasProperty

Variable

ProductId

ProductIdDataType

PropertyType

Optional

HasProperty

Variable

ExternalConfigurationId

ConfigurationIdDataType

PropertyType

Optional

HasProperty

Variable

InternalConfigurationId

ConfigurationIdDataType

PropertyType

Optional

HasProperty

Variable

JobId

JobIdDataType

PropertyType

Optional

HasProperty

Variable

ResultId

ResultIdDataType

PropertyType

Optional

The following properties are inherited from BaseEventType and shall be used in VisionEventType in the manner described here.

SourceNode

Reference to the source of the Message. This could be a failing method or, in case of an internally triggered message, the state machine object itself.

SourceName

Name of the Message source.

Severity

Severity of the Information within the boundaries defined by Table 128.

Message

A textual description of the error as a string.

The following describes the usage of the properties added by VisionEventType with respect to BaseEventType.

CausePath

Path information string based on the E10 scheme described in 11.6 or an application specific expanded derivation of that.

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.

VisionDiagnosticInfoEvents are generated to signal events of the lowest severity class as described in Section 11.3.2.

The EventType for VisionDiagnosticInfoEvents is formally defined in Table 130.

image047.png

Figure 39 – Overview VisionDiagnosticInfoEventType

Table 130 – VisionDiagnosticInfoEventType

Attribute

Value

BrowseName

VisionDiagnosticInfoEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the VisionEventType

VisionInformationEvents are generated to signal events of low severity class as described in Section 11.3.3.

The EventType for VisionInformationEvents is formally defined in Table 131.

image048.png

Figure 40 – Overview VisionInformationEventType

Table 131 – VisionInformationEventType

Attribute

Value

BrowseName

VisionInformationEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the VisionEventType

VisionConditions are generated to signal important events during the operation of the vision system which require interaction, i.e. conditions.

All non-inherited properties are optional and stay optional on the concrete sub-types because these ConditionTypes will be used under very different operational circumstances in the vision system; it is therefore not possible to specify that, e.g. a jobId shall be mandatory, since an error condition may be triggered during the preparation of a recipe, when no job is running.

However, the intention is for the server to provide as much information to the client as possible, i.e. fill as many properties as possible.

The EventType for VisionConditions is formally defined in Table 132.

image049.png

Figure 41 – Overview VisionConditionType

Table 132 – VisionConditionType

Attribute

Value

BrowseName

VisionConditionType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the AcknowledgeableConditionType defined in OPC 10000-9

HasSubtype

ObjectType

VisionWarningConditionType

Defined in 11.4.5

HasSubtype

ObjectType

VisionErrorConditionType

Defined in 11.4.6

HasSubtype

ObjectType

VisionPersistentErrorConditionType

Defined in 11.4.7

HasProperty

Variable

CausePath

String

PropertyType

Optional

HasProperty

Variable

MeasId

MeasIdDataType

PropertyType

Optional

HasProperty

Variable

PartId

PartIdDataType

PropertyType

Optional

HasProperty

Variable

ExternalRecipeId

RecipeIdExternalDataType

PropertyType

Optional

HasProperty

Variable

InternalRecipeId

RecipeIdInternalDataType

PropertyType

Optional

HasProperty

Variable

ProductId

ProductIdDataType

PropertyType

Optional

HasProperty

Variable

ExternalConfigurationId

ConfigurationIdDataType

PropertyType

Optional

HasProperty

Variable

InternalConfigurationId

ConfigurationIdDataType

PropertyType

Optional

HasProperty

Variable

JobId

JobIdDataType

PropertyType

Optional

HasProperty

Variable

ResultId

ResultIdDataType

PropertyType

Optional

HasProperty

Variable

ErrorCode

UInt64

PropertyType

Optional

HasProperty

Variable

ErrorString

String

PropertyType

Optional

HasProperty

Variable

StopReaction

Boolean

PropertyType

Mandatory

HasProperty

Variable

BlockReaction

Boolean

PropertyType

Mandatory

The properties which VisionConditionType has in common with VisionEventType have the same semantics and usage as described in Sections 11.4.1.2 and 11.4.1.3..

The following describes the usage of the properties added by VisionConditionType with respect to AcknowledgeableConditionType.

ErrorString

A system specific string classifying the error / warning.

ErrorCode

A system specific numeric code classifying the error / warning.

StopReaction

If the system did stop normal operation because of this error (state machine did transit to error state) this property shall be set to true.

BlockReaction

If the system did stop normal operation and user interaction is needed because of this error this property shall be set to true.

The VisionWarningConditionType is used to represent conditions in the vision system which the client should be warned about as described in Section 11.3.4.

The server can use the AckedState and ConfirmedState variables of the AcknowledgeableConditionType to control whether the vision system requires acknowledgement and confirmation of the condition as described in OPC 10000-9.

The VisionWarningConditionType is formally defined in Table 133.

image050.png

Figure 42 – Overview VisionWarningConditionType

Table 133 – VisionWarningConditionType

Attribute

Value

BrowseName

VisionWarningConditionType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the VisionConditionType

The VisionErrorConditionType is used to represent error conditions in the vision system as described in Section 11.3.5.

The server can use the AckedState and ConfirmedState variables of the AcknowledgeableConditionType to control whether the vision system requires acknowledgement and confirmation of the condition as described in OPC 10000-9.

The VisionErrorConditionType is formally defined in Table 134.

image051.png

Figure 43 – Overview VisionErrorConditionType

Table 134 – VisionErrorConditionType

Attribute

Value

BrowseName

VisionErrorConditionType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the VisionConditionType

The VisionPersistentErrorConditionType is used to represent error conditions in the vision system requiring outside interaction as described in Section 11.3.6.

The server can use the AckedState and ConfirmedState variables of the AcknowledgeableConditionType to control whether the vision system requires acknowledgement and confirmation of the condition as described in OPC 10000-9.

The VisionPersistentErrorConditionType is formally defined in Table 135.

image052.png

Figure 44 – Overview VisionPersistentErrorConditionType

Table 135 – VisionPersistentErrorConditionType

Attribute

Value

BrowseName

VisionPersistentErrorConditionType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the VisionConditionType

VisionSafetyEventType is an EventType subtype of BaseEventType, defined in OPC 10000-5. This event is to be triggered by the server when a safety-related incident occurs in the vision system. The structure is defined in Figure 45. It is formally defined in Table 136.

Event properties

  • VisionSafetyTrigger: flag indicating the current internal safety state
  • VisionSafetyInformation: information about the internal safety state provided by the vision system

image053.png

Figure 45 – Overview VisionSafetyEventType

Table 136 – VisionSafetyEventType Definition

Attribute

Value

BrowseName

VisionSafetyEventType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

Subtype of the BaseEventType defined in OPC 10000-5

HasProperty

Variable

VisionSafetyTriggered

Boolean

PropertyType

Mandatory

HasProperty

Variable

VisionSafetyInformation

String

PropertyType

Mandatory

There is only a loose connection between the generation of messages and the exposed behavior of the vision system on the state machine level. The following mandatory behavior is defined:

As the OPC UA interface only offers a view to the underlying vision system each call of the defined methods may fail. The method may deliver some information on the cause of the fail, but this information is only visible for the client calling the method. If any other clients are interested in this kind of information there is no way for them to get it. Therefore we define that if a method call fails the vision system has to generate a message at least of the warning without acknowledgement type naming the failed method including the calling parameters.

As the definition of the vision system is out of the scope of this document this is also true for the detection of error states within the vision system. As a consequence of this the generation of messages signaling such conditions is not associated to a specific state of the state machine.

As a general rule the transition to the error state of the state machine should only be performed if this is inevitable for the operation. The creation of an error message does not require that the state machine transitions to the Error state. A problem may be detected in a part of the vision system that is not needed for the current task at hand. Only if in this situation a method is called that can’t be performed because of this problem a transition to the Error state should occur.

On the other hand if the state machine does a transition to the Error state it is mandatory that a message of the error type or higher severity describing the cause is generated or already active.

It is up to the vision system to define if an internal error condition can be resolved immediately or if it has to wait for external acknowledgement / confirmation before trying to do so. Even if the system is successful in clearing the condition internally it has to wait for the reception of the acknowledgement of the corresponding message object if this is of an acknowledgeable type, before the message is cleared.

Application Note:

As the reception of an acknowledgement / confirmation can only take place once for each message object on the interface the vision system after reception has to check if the error condition is / can be resolved. If it is unable to resolve the error and interaction of the client / user side is required for resolving, it has to clear the message and create a new one to start a new resolving cycle.

Example:

During normal operation a vision system detects that it cannot accept a new job because the camera lens is dirty. It generates an error message informing the client on this with Ack and Conf required.

The client acknowledges the message and shows a message box on its console asking the operator to clean the lens.

The Operator presses the confirmation button without reading the message.

The client sends the confirmation for the message.

After reception of confirmation the vision System takes a test image and detects that the lens is still dirty. As there is still the need for user interaction the vision system has to decide what to do.

If it does nothing the client still sees the confirmed error message and therefore knows that it was not resolved. But as there are no additional confirmation options for the client the vision system will never get informed that if it may continue.

Therefore the vision system clears the confirmed message and creates a new one to start a new cleaning request with a hopefully better result.

The generation of large amounts of diagnostic messages may have impact on the performance of the vision system. As an OPC UA client can decide on its own if he reads such messages this is only a problem on the server side. It is common practice that the generation of such debugging / diagnostic messages can be suppressed within the vision System software. The server shall expose the information on suppressing of such messages in the following way. An integer variable DiagnosticLevel with a valid range between 1 … 200 is published showing that all diagnostic messages with a severity level lower or equal to this value are suppressed. Optionally this variable may be defined to be client writable to set a desired diagnostic level externally. For values lower than 150 it is not mandatory that the vision System is capable of upholding the performance expected for the application. The initial value of this variable on system start should be 200.

Application Note:

Example of a failing method call

Let’s assume the vision system is in the Ready state with an activated recipe in its memory. A client can call the PrepareRecipe method to load a second recipe but with a wrong recipe name that is not present in the vision system.

The method call will fail with an error message informing the calling client that this is a unknown recipe.

The vision system issues a warning message with a severity of e.g. 503 containing the information that a call of the PrepareRecipe method for that Recipe name failed.

The vision system does not transit to the Error state as there is no need to do so, since normal operation is not compromised at the moment. The vision system is able to accept jobs using the already activated recipe.

If the client now calls the StartSingleJob method with the unknown recipe the vision system could consider this an error and transition to the Error state while issuing a message of the error class. This decision is application specific. It is also valid that it only lets the method call fail and issues a warning message without transition to the Error state.

An external recipe management system could receive such a warning message and push the missing recipe to the vision system using the AddRecipe method.

System state information is often used to benchmark the reliability of a system. Therefore on a time scale it is estimated how long the system was productive, defective or in maintenance. To support this, a system should be able to publish its current state in a way enabling a client to do such estimation.

This standard follows the scheme of 6 basic system states defined by SEMI E10 standard (SEMI E10: Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM) and Utilization). The following diagram shows how the total time of existence of a system is divided into different categories. From the left to the right the model gets more detailed.

Table 137 – E10 system states

E10

Total Time

Operations Time

Uptime

Manufacturing Time

Production

PRD

Standby

SBY

Engineering

ENG

Downtime

Scheduled Downtime

SDT

Unscheduled Downtime

UDT

Nonscheduled Time

NST

If the optional SystemState variable exists on the server, the vision system shall continuously map its internal state to one of the six generic states on the right. This current state shall be published in the SystemState variable in the interface.

The vision system is currently working on a job.

The vision system is ready to accept a command but is currently not executing a job. It could for example be waiting for a Start command or a user input.

The vision system is not working and not ready to accept a command because a user is currently working on the system. This could be for editing a recipe or changing the system configuration.

The vision system is not available for production and this was planned in advance. This could be for cleaning, maintenance or calibration works.

The vision system is not available for production due to failure and repair. This covers all kinds of error states that might occur during operation.

The vision system is not working because no production was scheduled. This also covers things like operator training on the system.

Example:

An application specific extension of the base states:

E10

vendor / application specific extension

PRD

Acquisition

ACQ CAM A

 

 

ACQ CAM B

 

Processing

SBY

Waiting for PREPARE

 

Waiting for START

ENG

Recipe Editing

 

Calibration

SDT

Maintenance

 

Cleaning

Optics A

 

 

Optics B

UDT

Software Related Error

 

Hardware Related Error

NST

Powered Off

 

Operator Training

If the system is in state “ACQ CAM A” the current path would be “PRD/Acquisition/ACQ CAM A

The tree-like E10 scheme may be extended to the right by getting more specific on the current state of action the system is performing. As in the original E10 scheme, at every time the system has to choose exactly one state (rightmost field of a branch) it is currently in. To be compatible to clients understanding only the basic E10 states the system has to give the “/” separated path running along the branch of that tree starting from the base E10 state to the current state.

The same scheme should be used to structure error states. Every error information carries such path information to enable generic clients without deeper application knowledge to get a basic understanding of the possible error cause. The following basic error paths shall be used. As above this model may be expanded to the right as needed.

Table 138 – Basic error paths

UDT

Software Related Error

 

Hardware Related Error

Computing Unit

 

 

Sensor Unit

 

 

Controller Unit

 

 

Lighting Unit

The system can only be in one specific state (leaf of the tree), although errors can occur in more than one leaf simultaneously. In this case the system still has to select exactly one system state to be published.

There are two different approaches possible:

  1. The system selects the most severe error and publishes its path as the current system state.
  2. The system truncates the path to the last element common for all active errors.

The system may select one approach fitting to the current application.

Example:

A system is in an Error State and there are currently two errors active. The system uses application specific extended error classes:

  • UDT/Hardware Related Error/ Sensor Unit/Camera A/Fan Fail
  • UDT/Hardware Related Error/Lighting Unit/LED A/Over Temperature

Possibility 1:

The system decides that an over temperature is the most severe error and publishes “UDT/Hardware Related Error/Lighting Unit/LED A/Over Temperature“ as its system state.

Possibility 2:

The system publishes the truncated path “UDT/Hardware Related Error” as its current system state.