Introduction

The OPC 40100-2 specifications contain OPC UA Companion Specifications of several industry sectors and are developed by members of VDMA and/or the OPC Foundation. OPC UA is a machine to machine communication technology to transmit characteristics of products (e.g. manufacturer name, device type or components) and process data (e.g. temperatures, pressures or feed rates). To enable vendor unspecific interoperability the description of product characteristics and process data must be standardized utilizing technical specifications, the OPC UA companion specifications.

Associations

VDMA Robotics + Automation

The VDMA represents around 3300 German and European companies in the mechanical engineering industry. The industry represents innovation, export orientation, medium-sized companies and employs around four million people in Europe, more than one million of them in Germany.

The Robotics + Automation Association as part of VDMA represents one of the most dynamic and fastest growing sectors of the machinery industry and consists of the three groups Robotics, Machine Vision, and Integrated Assembly Solutions. The German Robotics + Automation sector, which reached close to €15 billion in turnover in 2019, is a pacemaker for the digitalization of production. With future studies, trade fair policy and activities such as OPC UA the association is ready for the future.

OPC Foundation

OPC is the interoperability standard for the secure and reliable exchange of data and information in the industrial automation space and in other industries. It is platform independent and ensures the seamless flow of information among devices from multiple vendors. The OPC Foundation is responsible for the development and maintenance of this standard.

OPC UA is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. This multi-layered approach accomplishes the original design specification goals of:

Platform independence: from an embedded microcontroller to cloud-based infrastructure

Security: encryption, authentication, authorization, and auditing

Extensibility: ability to add new features including transports without affecting existing applications

Comprehensive information modelling capabilities: for defining any model from simple to complex

1 Scope

This document specifies an OPC UA Information Model for the representation of a machine vision system.

OPC Machine Vision Part 1 concerned itself with the control & behavior of machine vision systems and their integration into production control and IT systems.

OPC Machine Vision Part 2 focuses on the management and monitoring of machine vision systems and their components for asset management systems, taking into account existing and emerging standards in these areas, like OPC for Devices and OPC for Machinery.

Part 2 thus aims at integrating machine vision systems into Industry 4.0 systems for monitoring the health of production equipment, predictive maintenance, data analytics, optimization of processes, resource efficiency, etc.

2 Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies

There are no normative references in this document.

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

OPC 10000-1

OPC 10000-2, OPC Unified Architecture - Part 2: Security Model

OPC 10000-2

OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

OPC 10000-3

OPC 10000-4, OPC Unified Architecture - Part 4: Services

OPC 10000-4

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

OPC 10000-5

OPC 10000-6, OPC Unified Architecture - Part 6: Mappings

OPC 10000-6

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

OPC 10000-7

OPC 10000-8, OPC Unified Architecture - Part 8: Data Access

OPC 10000-8

OPC 10000-100, OPC Unified Architecture - Part 100: Devices

OPC 10000-100

OPC 40001-1, OPC UA for Machinery - Part 1: Basic Building Blocks

http://www.opcfoundation.org/UA/Machinery/

OPC 40010-1, OPC UA for Robotics - Part 1: Vertical Integration

http://www.opcfoundation.org/UA/Robotics/

SEMI E10-0312: SEMI E10 Standard: Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM) and Utilization).

3 Terms, definitions, and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling are understood in this specification. This specification will use these concepts to describe the OPC UA for Machine Vision Information Model. For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-7, OPC 10000-100, OPC 40001-1 as well as the following apply.

Note that OPC UA terms and terms defined in this specification are italicized in the specification.

3.2 OPC UA for Machine Vision Part 2 terms

3.3 Abbreviated terms

3.4 Conventions used in this document

3.4.1 Conventions for Node descriptions

3.4.1.1 Node definitions

Node definitions are specified using tables (see Table 2 ).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1.

The TypeDefinition is specified for Objects and Variables.

The TypeDefinition column specifies a symbolic name for a NodeId, i.e., the specified Node points to the corresponding Node, with a HasTypeDefinition Reference.

The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.4.2.2).

Nodes of all other NodeClasses cannot be defined in the same table; therefore, only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 explains the content/structure of a Type definition table. If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass and DataType can be derived from the type definitions, and the symbolic name can be created as defined in 3.4.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined, they are separated by commas. The name or the short name may be used.

3.4.1.2 Additional References

To provide information about additional References, the format as shown in Table 4 is used.

The components of the ObjectType have additional references which are defined in Table 4.

References can be to any other Node.

3.4.1.3 Additional sub-components

To provide information about sub-components, the format as shown in Table 5 is used.

3.4.1.4 Additional Attribute values

The type definition table provides columns to specify the values for required Node Attributes for InstanceDeclarations. To provide information about additional Attributes, the format as shown in Table 6 is used.

There can be multiple columns to define more than one Attribute.

3.4.2 NodeIds and BrowseNames

3.4.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this document is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this document, because they are not defined by this document but generated by the Server.

3.4.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this document is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this document is defined in 14.2.

For InstanceDeclarations of NodeClass Object and Variable that are placeholders (OptionalPlaceholder and MandatoryPlaceholder ModellingRule), the BrowseName and the DisplayName are enclosed in angle brackets (<>) as recommended in OPC 10000-3. If the BrowseName is not defined by this document, a namespace index prefix is added to the BrowseName (e.g., prefix '0' leading to ‘0:EngineeringUnits’ or prefix '2' leading to ‘2:DeviceRevision’). This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 81 provides a list of namespaces and their indexes as used in this document.

3.4.3 Common Attributes

3.4.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this specification or if it is server-specific.

For all Nodes specified in this specification, the Attributes named in Table 7 shall be set as specified in the table.

3.4.3.2 Objects

For all Objects specified in this specification, the Attributes named in Table 8 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.3 Variables

For all Variables specified in this specification, the Attributes named in Table 9 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.4 VariableTypes

For all VariableTypes specified in this specification, the Attributes named in Table 10 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.5 Methods

For all Methods specified in this specification, the Attributes named in Table 11 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 General information on Machine Vision and OPC UA

4.1 Introduction to Machine Vision Systems

A machine vision system is any computer system, smart camera, vision sensor or even any other component that has the capability to record and process digital images or video streams and extracts information from them. In an industrial production this usually refers to the factory floor or industrial market.

Digital images or video streams represent data in a general sense, comprising multiple spatial dimensions (e.g. 1D scanner lines, 2D camera images, 3D point clouds, image sequences, etc.) acquired with the help of any kind of light. The term “light” in this companion specification refers to visible light, infrared, ultraviolet, x-ray, radar, ultrasonic, virtual imaging, etc. it is used as a catch-all term for all current and future imaging techniques used to gather data in a machine vision context.

The output of a machine vision system can be raw or pre-processed images or any image-based measurements, inspection results, process control data, robot guidance data, etc., depending on the specific vision task.

Machine vision systems therefore cover a broad range of applications that can vary from small single task systems in an embedded board or smart camera, to a very complicated multi-computer, multi-camera setup that can be reconfigured to analyze different aspects of a product line.

Applications include identification (like data matrix code, bar code or character recognition), pose determination (e.g., for robot guidance), assembly checks, gauging up to very high accuracy, surface inspection, color identification, among others.

Therefore, a machine vision system is a collection of different components and other machines that work together to achieve a particular vision task.

Figure 49 shows an example of a machine vision system in the context of this companion specification composed of multiple hardware and software components.

These underlying components of the system and their relationships present themselves to the “outside world” in various ways, e.g., the PLC can use various interfaces like digital I/O, Fieldbus, or other vendor specific protocol definitions. The objects and relationships described in this specification may express these interfaces and offer a global view on the system.

This companion specification provides a way to model a machine vision system by using building blocks that express all the configurations that a component like a PLC can have. It envisions things not as rigid objects but as a collection of capabilities and aspects. A physical PLC will then not be model a single object but as a group of objects like a computing device + physical interfaces for its I/Os, serial and ethernet ports. This approach allows to be more granular and compact with the amount of information that can be expressed about a physical object. This abstraction may reflect the structure and relationships between all the components of the machine vision system or may present a view without too much detail.

4.2 Introduction to OPC Unified Architecture

4.2.1 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as a universal communication protocol. While there are numerous communication solutions available, OPC UA has key advantages:

A state of art security model (see OPC 10000-2).

A fault tolerant communication protocol.

An information modelling framework that allows application developers to represent their data in a way that makes sense to them.

OPC UA has a broad scope which delivers for economies of scale for application developers. This means that a larger number of high-quality applications at a reasonable cost are available. When combined with semantic models such as OPC UA for Machine Vision, OPC UA makes it easier for end users to access data via generic commercial applications.

The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers process information locally and then provides that data in a consistent format to any application requesting data - ERP, MES, PMS, Maintenance Systems, HMI, Smartphone, or a standard Browser, for examples. For a more complete overview see OPC 10000-1.

4.2.2 Basics of OPC UA

As an open standard, OPC UA is based on standard internet technologies, like TCP/IP, HTTP, Web Sockets.

As an extensible standard, OPC UA provides a set of Services (see OPC 10000-4) and a basic information model framework. This framework provides an easy manner for creating and exposing vendor defined information in a standard way. More importantly all OPC UA Clients are expected to be able to discover and use vendor-defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historian applications. This specification is an example of an OPC UA Information Model designed to meet the needs of developers and users.

OPC UA Clients can be any consumer of data from another device on the network to browser based thin clients and ERP systems. The full scope of OPC UA applications is shown in Figure 1.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data, it offers a high-performing data exchange solution. Security is built into OPC UA as security requirements become more and more important especially since environments are connected to the office network or the internet and attackers are starting to focus on automation systems.

4.2.3 Information modelling in OPC UA

4.2.3.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard services. These Objects consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example, a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the type of the actual value, such as a string, float, structure etc. It can also describe the Variable value as a variant. A Method Node represents a function that can be called. Every Node has several Attributes including a unique identifier called a NodeId and non-localized name called as BrowseName. An Object representing a ‘Reservation’ is shown in Figure 2.

Object and Variable Nodes represent instances, and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 3 illustrates the relationship between an instance and its TypeDefinition.

The type Nodes are templates that define all the children that can be present in an instance of the type. In the example in Figure 3 the PersonType ObjectType defines two children: First Name and Last Name. All instances of PersonType are expected to have the same children with the same BrowseNames. Within a type the BrowseNames uniquely identify the children. This means Client applications can be designed to search for children based on the BrowseNames of the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses types that multiple Servers implement.

OPC UA also supports the concept of sub-typing. This allows a modeller to take an existing type and extend it. There are rules regarding sub-typing defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType. For example, the modeller may decide that the existing ObjectType in some cases needs an additional Variable. The modeller can create a subtype of the ObjectType and add the Variable. A Client that is expecting the parent type can treat the new type as if it was of the parent type. Regarding DataTypes, subtypes can only restrict. If a Variable is defined to have a numeric value, a sub type could restrict it to a float.

References allow Nodes to be connected in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical references are used to create the structure of Objects and Variables. Non-hierarchical are used to create arbitrary associations. Applications can define their own ReferenceType by creating subtypes of an existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 4 depicts several References, connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 5. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the AddressSpace of an OPC UA Server.

A complete description of the different types of Nodes and References can be found in OPC 10000-3 and the base structure is described in OPC 10000-5.

OPC UA specification defines a very wide range of functionality in its basic information model. It is not required that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of Profiles, which segment the functionality into testable certifiable units. This allows the definition of functional subsets (that are expected to be implemented) within a companion specification. The Profiles do not restrict functionality, but generate requirements for a minimum set of functionalities (see OPC 10000-7)

4.2.3.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Each namespace in OPC UA has a globally unique string called a NamespaceUri which identifies a naming authority and a locally unique integer called a NamespaceIndex, which is an index into the Server's table of NamespaceUris. The NamespaceIndex is unique only within the context of a Session between an OPC UA Client and an OPC UA Server- the NamespaceIndex can change between Sessions and still identify the same item even though the NamespaceUri's location in the table has changed. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of structured values in OPC UA that are qualified with NamespaceIndexes: NodeIds and QualifiedNames. NodeIds are locally unique (and sometimes globally unique) identifiers for Nodes. The same globally unique NodeId can be used as the identifier in a node in many Servers – the node's instance data may vary but its semantic meaning is the same regardless of the Server it appears in. This means Clients can have built-in knowledge of what the data means in these Nodes. OPC UA Information Models generally define globally unique NodeIds for the TypeDefinitions defined by the Information Model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same names to be used by different information models without conflict. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

4.2.3.3 Companion Specifications

An OPC UA companion specification for an industry specific vertical market describes an Information Model by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market, and potentially also well-defined Objects as entry points into the AddressSpace.

5 Use cases

5.1 Overview

This section outlines the different use cases that this companion specification addresses.

5.2 Items and System Relationships

5.3 Inventory and replacements

5.4 Static maintenance information

5.5 Dynamic Maintenance Information

5.6 Health Monitoring

5.7 Information recording

5.8 Service history record

6 OPC Machine Vision Part 2 Information Model overview

Part 1 of the OPC Machine Vision Companion Specification defines the VisionSystemType, an instance of which serves as the entry point to the functional view of a machine vision system. This specification introduces the VisionSystemAssetType, an instance of which shall provide an additional entry point into the inner structure of a machine vision system. The VisionSystemAssetType represents the composition of the machine vision system, i.e., it shows which components and other machines together build up the machine vision system. An instance of the VisionSystemType (defined in Part 1) and an instance of VisionSystemAssetType (defined in Part 2), representing the same machine vision system, shall have a RepresentsSameEntityAs reference (OPC 10000-23) connecting them (Figure 6).

The VisionSystemAssetType provides optional folders that can be instantiated individually to organize the different components and other machines that constitute the machine vision systems e.g., ComputingDevices, Lenses, DisplayUnits, etc., as can be seen from Figure 7. The complete set of defined possible common components can be found in section 8.1. With the exception of ImageHandlingAspects all the instances that are organized in the folders of the VisionSystemAssetType can be of any type but need to implement the interface IVisionInfoType (section 7.5) or one of its subtypes. The IVisionInfoType interface contains basic information about identification, maintenance, and health of the machine vision system, as well as all the items (machines or components) that form it.

The idea behind this modelling approach is to enable the implementer to use instances of other ObjectTypes that are already defined in other companion specifications (future or current), when appropriate. The IVisionInfoType interface shall be implemented on the instances organized by the folders in VisionSystemAssetType unless a specific subtype of IVisionInfoType for that particular item type exists (e.g., IComputingDeviceType, IDisplayUnitType, etc.). The implementation of the IVisionInfoType or one of its subtypes can also be done on the ObjectType instead of the instance to be organized in that folder. This specification also defines several convenience ObjectTypes that are not mandatory, that can be directly instantiated, and implement the necessary interfaces for different items.

7 OPC Machine Vision Common Types

This section describes the InterfaceTypes and ObjectTypes containing the parameters that are common to all the items of the vision system as well as the vision system (as a whole). Any changes to the modelling rules of the existing parameters listed within these types or any addition of parameters can be done directly within the instances or by subtyping.

7.1 Vision Machine Identification

The VisionMachineIdentificationType contains the identification and nameplate information that can be used to identify an instance as a “Machine”. This ObjectType is a subtype of the MachineIdentificationType defined in OPC 40001-1 Machinery Companion Specification. It is formally defined in Table 12. This ObjectType identifies the whole vision system and can be used for all components that are machines themselves.

The HardwareRevision property provides the revision level of the hardware of the machine vision system following the rules of Sematic Versioning 2.0.0

The ConfigurationCode property provides the specific information how the machine vision system has been configured for a specific use case or application.

The SoftwareRevision property provides the version or revision level of the software in the machine vision system following the rules of Semantic Versioning 2.0.0.

7.2 Vision Component Identification

The VisionComponentIdentificationType contains the identification and nameplate information that can be used to identify an instance as a “Component”. This ObjectType is a subtype of MachineryComponentIdentificationType defined in OPC 40001-1 Machinery Companion Specification. It is formally defined in Table 13.

The HardwareRevision property provides the revision level of the hardware of the component in the machine vision system following the rules of Sematic Versioning 2.0.0

The ConfigurationCode property provides the specific information how that component of the machine vision system has been configured for a specific use case or application.

The SoftwareRevision property provides the version or revision level of the software in the component of the machine vision system following the rules of Semantic Versioning 2.0.0.

7.3 VisionMaintenanceInfoType ObjectType Definition

This subtype of FunctionalGroupType contains basic information needed to provide maintenance of an Item. It is formally defined in Table 14.

Note: In addition to the variables defined in this ObjectType it is possible to inform about maintenance related events of an Item using ConditionType’s events. In those cases, it is strongly suggested the use of the information model describe on OPC 10000-110 Asset Management Basics. Each of those ConditionType’s shall implement the IMaintenanceEventType and use a relevant category (e.g., CalibrationDueConditionClassType) when appropriate.

The components of the VisionMaintenanceInfoType have additional subcomponents which are defined in Table 23.

The StartOfWarranty property denotes the beginning of the warranty period of the item.

The LastService property denotes the last moment in time when the most recent service was carried out on the item.

The NextService property denotes the planned moment in time when the next service is to be carried out on the item.

The CalibrationNeeded property is a flag that if True denotes that the item needs calibration.

The LastCalibration property denotes the time when the previous calibration was carried out on the item.

The NextCalibration property denotes the planned time when the next calibration is to be carried out on the item.

The ServiceClass property provides information that an item is classified as a wear and tear part, whether it is a line replaceable unit (LRU), shop replaceable unit (SRU), wear and tear part (WTP), infrastructural unit (ISU), infrastructural equipment (ISE), etc.

The 2:OperationCounters is recommended to be used as defined in OPC 40001-1.

Note: Servers can add additional entries into the EnumStrings array. The order of the value attributes corresponds with the numeric value that must be provided in the value of the variable.

The MaintenanceRecord property provides the most recent note that was recorded while performing maintenance. This property can be historized if a history of previous maintenance notes is to be made available. This property can also be used to provide a link to an external resource (e.g., a file or a webpage) where the user can get access to more information about the item related to maintenance.

Note: If the server implements maintenance events using OPC 10000-110 Asset Management Basics, a maintenance record can also be created by a client application monitoring the events triggered by Item.

The FirmwareInfo property denotes the information about the firmware of the Item.

7.4 VisionHealthInfoType ObjectType Definition

The VisionHealthInfoType provides the current general condition of the machine vision system or its item with respect to its/their functional fitness. It is formally defined in Table 17.

The RemainingLifeTime property denotes the remaining lifetime of the item. It serves as an indication to service personnel for maintenance activities.

The Temperature property denotes the temperature value (along with its unit) of the item.

The State property denotes the SEMI E10 State of the item (see Section 11.1).

The DeviceHealth variable indicates the status as defined by NAMUR Recommendation NE107. The DeviceHealthEnumeration DataType is formally defined in OPC 10000-100 Device Model.

The DeviceHealthAlarms folder shall organize the Alarms and Conditions related to the item if these Alarms and Conditions are instantiated in the address space.

7.5 IVisionInfoType InterfaceType definition

This InterfaceType defines the minimal basic information that each item (that can be either a component or a machine by itself) shall provide in a vision system. It is formally defined in Table 18.

The 2:Identification object contains Properties of the item that will serve for identification like Manufacturer, SerialNumber, etc. This node shall be an instance of either the MachineIdentificationType or MachineryComponentIdentificationType or a subtype of either of these types. Depending on the type used, the item will be identified as a machine or a component. Implementers of this specification are free to provide subtypes of the base types defined in OPC 40001-1 Machinery Companion Specification or use the ones defined in Sections 7.1 and 7.2.

The 2:Maintenance object contains Properties which provide information needed for maintenance purposes e.g StartOfWarranty, MostRecentService etc., see Section 0 for further details.

The Health object contains Properties like Temperature, DeviceHealth and Notifications indicating the status of an item.

All the objects mentioned above (namely 2:Identification, 2:Maintenance and Health) are folders as they are instance declarations of types derived from the FolderType formally defined in in OPC 10000-5 Information Model

7.6 VisionItemFolderType ObjectType Definition

The VisionItemFolderType provides a way to organize items of the machine vision system into functional categories and is formally defined in Table 19. Each object instance within this folder shall implement the IVisionInfoType interface as defined in 7.5 or one of its subtypes.

The components of the VisionItemFolderType have additional subcomponents which are defined in Table 20.

8 OPC Machine Vision System Asset

8.1 VisionSystemAssetType ObjectType Definition