1 Scope

This document defines the UA companion specification using OPC UA constructs to provide information for data transfer from and to Geometric Measurement Systems (e.g., Manual and Automatic Gauging Systems for Dimensional Tasks, Coordinate Measuring Systems, Form Measuring Systems, Surface Texture Measuring Systems) in various industries. The OPC UA Companion Specification for Geometric Measurement Systems (GMS) aims to provide a unique interface for communication partners from different manufacturers to allow for interoperability.

Among others, the following functionalities are covered:

Identification of machines, machine data and status

Managing part data (in version 1 only monitoring)

Accessing data of measuring results.

Job management (in version 1 only monitoring)

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

Secure: encryption, authentication, authorization and auditing

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

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

VDMA Measuring and Testing Technology

The VDMA represents over 3.300 mainly small and medium-size member companies in the engineering industry, making it one of the largest and most important industrial associations in Europe. The VDMA Measuring and testing technology represent more than 200 manufacturers of length measurement technology, testing technology and weighing technology. The objective of this industry-driven platform is to support this sector through a wide spectrum of activities and services such as standardization, statistics, marketing, public relations, trade fair policy, networking events and representation of interests.

2 Normative references

The following referenced documents are indispensable for the application 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.

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-9, OPC Unified Architecture - Part 9: Alarms and Conditions

OPC 10000-9

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

OPC 10000-100

OPC 10000-200, OPC Unified Architecture - Part 200: Industrial Automation

OPC 10000-200

OPC 40001-1 OPC Unified Architecture - Part 1: Building Blocks for Machinery

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

OPC 40001-101 OPC Unified Architecture - Part 101: Machinery Result Transfer

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

OPC 40501-1 OPC Unified Architecture - Part 1: Machine Tools - Monitoring and Job

http://www.opcfoundation.org/UA/MachineTools/Part1/

3 References

4 Terms, abbreviated terms and conventions

4.1 Overview

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

The terminology used in this specification considers the definitions according to The International Vocabulary of Metrology (VIM) [JCGM 200].

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

4.2 OPC UA for GMS terms

4.2.1 Geometric Measurement System (GMS)

4.2.1.1 Untitled

[SOURCE: JCGM 200]

4.2.2 Measurement Reason (MeasReason)

4.2.2.1 Untitled

indication why a measurement is carried out

4.2.3 Measurement Routine (MeasurementRoutine)

4.2.3.1 Untitled

sequence of steps to perform a measurement on a GMS. In most cases, this routine is done automatically or semi-automatically. It is also called a measurement plan or sequence.

4.2.4 Measuring System

4.2.4.1 Untitled

[SOURCE: JCGM 200]

4.2.5 Master

4.2.5.1 Untitled

[SOURCE: JCGM 200]

4.2.6 Part

4.2.6.1 Untitled

[SOURCE: OPC 40501-1]

4.2.7 Sensor (Primary)

4.2.7.1 Untitled

[SOURCE: JCGM 200]

4.2.8 Additional Sensor

4.2.8.1 Untitled

every further sensor except the primary sensor that carries out the geometric measurement

4.2.9 Calibration

4.2.9.1 Untitled

[SOURCE: JCGM 200]

4.2.10 Qualification

4.2.10.1 Untitled

[SOURCE: ISO 10360 Part 1]

4.3 Abbreviated terms

4.4 Conventions used in this document

4.4.1 Conventions for Node descriptions

4.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 "undefined", so either "undefined" or "undefined" 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 with a HasTypeDefinition Reference to the corresponding Node.

• 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 4.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 illustrates the table. If no components are provided, the DataType, TypeDefinition and Other 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 4.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.

4.4.1.2 Additional References

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

References can be to any other Node.

4.4.1.3 Additional sub-components

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

4.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.

4.4.2 NodeIds and BrowseNames

4.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 0:HasProperty or 0: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.

4.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 13.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 69 provides a list of namespaces and their indexes as used in this document.

4.4.3 Common Attributes

4.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 document or if it is server-specific.

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

4.4.3.2 Objects

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

4.4.3.3 Variables

For all Variables specified in this document, 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.

4.4.3.4 VariableTypes

For all VariableTypes specified in this document, 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.

4.4.3.5 Methods

For all Methods specified in this document, 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.

5 General information about Geometric Measurement Systems (GMS) and OPC UA

5.1 Introduction to Geometric Measurement Systems in Industrial Production

Metrology is an important provider of information in industrial production. Therefore, its integration into the digital data flow of information in production is obvious. The most common application of metrology is its use for quality inspection.

Figure 1 shows a simplified representation of the process chain for order processing in production from development and construction to work planning (routing) and to manufacturing. This process is connected to the process of quality inspection based on measurements from inspection, (test) planning to measurement and to analysis. All process steps are managed by production planning. The feedback of data from the analysis into upstream processes are marked with dashed lines [Pfeifer 2006]. An additional line represents the connection between the measurement system and external instances.

Besides the horizontal integration along the process chain of production, a vertical integration into upper management exists. This integration can be described by the levels of automation pyramid according to [IEC 62264-1].

The scope of the Geometric Measurement System companion specification is marked with "GMS".

A large proportion of the measurements in production are measurements on the part geometry.

5.1.1 Definition of a Geometric Measurement System

The International Vocabulary for Metrology (VIM) [JCGM 200] defines the general concepts and the associated terms for metrology. Chapter 3 of VIM describes devices for measurement. A measuring instrument is thus a device used for making measurements, alone or with one or more supplementary devices. A measuring system consists of a set of one or more measuring instruments and often other devices, including any reagent and supply, assembled and adapted to give information used to generate measured quantity values within specified intervals for quantities of specified kinds. A measuring system may even consist of one single measuring instrument only.

The standards of Geometrical Product Specification (ISO GPS) are used to define the geometric requirements for workpieces in technical specifications and the requirements for their verification [ISO 14638]. The verification is mainly done by measurements. General concepts and requirements for the used measuring equipment define ISO 14978. The described measuring equipment is also called a measuring system. This leads to the term Geometric Measurement System (GMS). A GMS is a measuring system according to [JCGM 200] performing geometrical measuring tasks. The measurement in production is often automated.

OPC UA offers the opportunity to integrate GMS into production according to the described path in Figure 1.

5.1.2 Classification and Structure of Geometric Measurement Systems

The field of Geometric Measurement Systems is very broad. In this section, the components of a GMS, as well as a classification for possible implementations, will be shown. The structures described here are exemplary. There may be further or future classifications for which this Companion Specification can still be used, and a GMS may contain further components or subsystems. Figure 2 contains an overview of the common components. It does not claim to be complete.

According to Figure 2, there are seven different main types of common components of a GMS (green). They may also be split into different subtypes (grey). The main types are defined as:

The GMS consists of an instrument that comprises one or more sensors (4.2.7).

Environmental control [VDI 2627] requires additional sensors (4.2.8)).

Part carrier & fixtures: enable a strict control and fixed reference in space and time - the coordinate systems - between measured component and measurement system.

Accessories enable the GMS to function according to the production plan.

Safety devices enable the GMS to observe its environment and prevent it from harming the operator or the measured part.

Figure 3 contains the classification of a GMS and divide the GMS into manual measurement instruments [ISO 14978], surface texture measuring instruments [ISO 25178], multi point measuring instruments, coordinate measuring systems [ISO 10360] and special systems. The gauges [ISO 1938] are treated as manual instruments. The list of applicable GMS does not claim to be complete.

5.1.3 Result Management in Geometric Measurement Systems

The output of all measurement systems are measurement results. For geometric measurement results, many file formats and structures (e.g., AQDEF^® [AQDEF 5], DMIS [ISO 22093], QIF, I++ DMS, ...) and other generic formats (CSV, raw text, JSON, XML …) are used. All these formats have their specific use cases, domains, and benefits [Pfeifer 2006]. Therefore, this Companion Specification defines only the transport and the management of the result. The concepts of the result management are based on the Result Management of the OPC 40001-101.

5.2 Introduction to OPC Unified Architecture

5.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 Geometric Measurement Systems, 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 provide 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.

5.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 4.

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.

5.2.3 Information modelling in OPC UA

5.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 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 a number of Attributes including a unique identifier called a NodeId and non-localized name called as BrowseName. An Object representing a 'Reservation' is shown in Figure 5.

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

The type Nodes are templates that define all of the children that can be present in an instance of the type. In the example in Figure 6 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 from 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 7 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 8. 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).

5.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.

5.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.

6 Use cases

This companion specification describes how a GMS is addressed via OPC UA. For this purpose, the following primary use cases for the communication with a GMS are considered in sections 6.1 to 6.56.5. These use cases are located in the overview figure of a Geometric Measurement System (GMS) in Figure 9.

Further use cases can also be covered or specified in other standards (vendor or Companion Specification).

In each chapter for the use cases, a simple sequence diagram demonstrates a typical communication example between GMS and other instances like operator, high-level system in the automation pyramid, data bases or other systems.

6.1 Retrieve static machine data

A higher-level system requests from a GMS which (measurement) functions/parameters (measuring space) are available, how the machine is identified if the measuring system is calibrated, retrieves additional information from machine components and, to receive an overview of the sensor system, respectively in order to

provide an overview of GMS's capabilities

validate measurement jobs addressed to a certain GMS

plan measuring tasks for GMSs

be able to locate all GMSs

assign the appropriate GMS to the part to be measured, if several different GMSs are available

Figure 10 shows a typical communication between GMS, operator and high-level system to retrieve static machine data as a sequence diagram.

6.2 Retrieve dynamic machine status

A higher-level system would like to know the status/state/condition (e.g., collision) of the GMS, when manual intervention is required, the current error message, what measures have to be taken in case of intervention to

plan the next jobs

keep usage statistics

plan maintenance

assign service

calculate key performance indicators (e.g., OEE [ISO 22400-2])

archive data

verify the reliability of the measurements

send warnings, if necessary.

Figure 11 and Figure 12 show a typical communication between GMS, operator, and high-level system to retrieve dynamic machine data as a sequence diagram.

6.3 Job management

A higher-level system may manage/schedule/start/stop measurement routines, be able to assign part to a job/measurement routine/batch, want to know the remaining time till the job is finished, know what the current status of the job is and include dynamic part data in the measurement result (e.g., material no., part no., comments, operator) in order to

be able to distribute the execution processes automatically

(automatically) start/enable the measurement routine

create an overview of the current job status

ensure traceability

Figure 13 shows a typical communication between GMS, operator and high-level system to manage jobs as a sequence diagram.

6.4 Managing part data

A higher-level system/handling system would like to identify a part on the GMS, know whether the measuring procedure was error-free, know when a measurement is finished as well as read and write meta-data (e.g., batch, temperature) in order to

decide whether the part requires further processing, has to be sorted out, or the measurement has to be repeated

annotate measured values with the meta-data and save them

transmit these to the next production process

request the GMS to load proper data to measure (e.g., measurement routine) a part

Figure 14 shows a typical communication between GMS, operator, and high-level system to manage part data as a sequence diagram.

6.5 Retrieve measurement results

A higher-level system would like to receive the measurement results (incl. meta-data) for a part in order to

correct/adjust the program in the machine tool

be able to guarantee complete traceability of the workpiece

reject or rework the workpiece, if necessary

release the products

optimize the product

interpret the product (e.g., statistical analyses)

check the product quality

Figure 15 shows a typical communication between GMS, operator, and high-level system to retrieve measurement results as a sequence diagram.

7 Geometric Measurement System Information Model overview

This section introduces the "OPC UA Information Model for Geometric Measurement Systems". This Information Model provides the necessary ObjectTypes to model the interface of a Geometric Measurement System with the hierarchy as illustrated in Figure 16 (nodes of GMS marked in yellow, whereas nodes of the OPC UA Information model of machine tools are marked in blue/grey). The model is based on the OPC UA model of machine tools, so the most important types are (subtype of) types of the machine tool model.

There are ObjectTypes that are used to identify the GMS (GMSIdentificationType), to monitor the GMS (GMSMonitoringType), to manage the production (ProductionType) of the GMS, to handle the Equipment of the GMS (GMSEquipmentType) and to give notification on the status of the GMS (NotificationType).

Additional to the types adopted from the machine tool information model, there are types for the Result Management (GMSResultManagementType) which is based on the result transfer model of OPC UA for Machinery.

The ObjectType hierarchy and the important children of an ObjectType of this Companion Specification are shown in Figure 17 - Figure 22. Objects from external specifications are positioned within greyish-blue boxes.

8 OPC UA ObjectTypes

8.1 GMSType

The GMSType provides information about the Geometric Measurement System itself. It is the entry point to the OPC UA interface of a Geometric Measurement System. There is a basic structure to the interface. An instance of this type aggregates all information related to one system.

All instances of GMSType have to be referenced from the 3:Machines node defined in OPC 40001-1. At least one instance of GMSType shall be present to qualify for any profile of OPC UA for GMS.

The GMSType is formally defined in Table 12.

Equipment (see 8.6), Identification (see 8.7), Monitoring (see 8.8), Notification (see OPC UA 40501-1) and Production (see 8.9) are instances of the respective types. They are used to thematically assign the structure of the information in the MachineToolType and the GMSType, respectively. ResultManagement is the entry point for the result management.

The components of the GMSType have additional subcomponents that are defined in Table 13.

8.2 MultiSensorType

The MultiSensorType provides information about the type of measuring probe.

The MultiSensorType is formally defined in Table 14.

Axes describes the number and name (e.g., X,Y,Z) of available axes. The names of the axes should be described according to ISO 841 / ISO 10791.

Alignment describes if a tool is fixed or flexible.

8.3 SensorType

The SensorType provides information about the properties of the sensor.

The SensorType is formally defined in Table 15.

AbsoluteProbe indicates if the sensor provides an absolute position directly after switching on. The sensor does not need a referencing or zeroing after the start up.

Axes describes the number of available axes. The names of the axes should be descripted according to ISO 841 / ISO 10791.

Alignment describes if a sensor is fixed or flexible.

Capabilities is defined as an array of tool capabilities (e.g., single point measurement, scanning measurement, contact measurement). This value must not be changed.

The Class indicates in which mode a sensor is operated. This value must not be changed (see Table 17)

For each quantity, an EngineeringUnit is defined as reference value. A measured value is a multiple of this unit.

IsQualifiedStatus is defined as the status of the tool qualification.

The MeasuringRange defines the part of the working range for which the errors do not exceed the specified error limits. This is also called as "used range".

The Resolution indicates the smallest perceptible difference.

WorkingRange is the maximum range in which a probe can deliver values. It is normally larger than measuring range.

The components of the SensorType have additional subcomponents which are defined in Table 16.

The 0:EngineeringUnits of Qualified must be a time unit (e.g., hour, days) and the StartValue is the timestamp (Unix timestamp) of the last qualification.

LimitValue is the chosen value at which the tool is no longer qualified.

WarningValue is the chosen value at which a warning is sent, that the sensor must be requalified.

The component Variables of the SensorType have specific Attribute values defined in Table 17. The Attribute values for Capabilities/0:EnumStrings and Class/0:EnumStrings given here shall be used by instances must not be changed.

The element entries to the value attribute of Capabilities/0:EnumStrings have the following meaning:

Other: None of the entries defined applies.

PtMeas: Sensor capable to do single point measurement.

PtMeasSelfCenter: Sensor capable to do single point self-centering measurement.

FeatureExtract: Sensor capable to extract parameters of feature from recorded points.

ProfileScan: Sensor capable to record continuously points along a spatial path.

ArealScan: Sensor capable to record continuously lines with points along a spatial path.

The element entries to the value attribute of Class/0:EnumStrings have the following meaning:

Other: None of the entries defined applies.

NoTool: No sensor for the GMS is currently available.

UnDefTool: The properties of the current sensor are not defined.

TactileTouchTrigger: The current sensor is a tactile sensor with touch trigger contact detection.

TactileMeasuring: The current sensor is a tactile sensor with measuring contact detection.

Optical-1D: The current sensor is an optical sensor for 1 dimension (e.g., point distance sensor).

Optical-2D: The current sensor is an optical sensor for 2 dimensions (e.g., camera).

Optical-3D: The current sensor is an optical sensor for 3 dimensions (e.g., fringe projection sensor).

Roughness: The current sensor measures surface texture.

Eddy Current Sensor: The current sensor measures eddy current.

TemperatureProbing: The current sensor measures temperature.

SensorType and MultiSensorType define a two-level structure to inform about the abilities of the available sensors on a GMS. The MultiSensorType offers the possibility of combining technically connected sensors (e.g. different sensors on a flexible carrier like an articulating carrier [ISO 10360-1]). It is not intended to provide complete information about the technical structure of all sensor components (e.g. information about each stylus of a tactile probe [ISO 10360-1]). Nevertheless it is possible to do so by defining each stylus as a sensor.

Figure 23 shows two examples for GMSs with typical sensor equipment. The GMS on the left has a tactile sensor (e.g. fixed scanning sensor) and an articulating carrier described by the MultiSensorType with three further sensors, that are changeably connected to the same mount. The tactile sensor is modelled as SensorType; the MultiSensorType describing the articulating carrier combines three instances of SensorType. The GMS on the right has two sensors mounted in parallel, both are modelled as SensorTypes.

8.4 LoadingMonitoringType

The LoadingMonitoringType provides information about the availability of the machine for loading a component for testing.

The LoadingMonitoringType is formally defined in Table 18.

IsInLoadingPosition informs if the machine is in a safe position for loading.

LoadStatus contains information whether a part is loaded or not.

The component Variables of the SensorType have Attribute values defined in Table 19. The Attribute values given here shall be used by instances must not be changed.

The element entries to the Attribute values of LoadStatus/0:EnumStrings have the following meaning:

Unknown: The load status is not known by the GMS.

Empty: There is no part in the GMS.

Filled: There is one or more parts in the GMS.

InProgess: The load status is changing.

8.5 ToolMonitoringType

The ToolMonitoringType provides the monitoring information about the active tool.

The ToolMonitoringType is formally defined in Table 20.

ActiveTool comprises all NodeIds of the tools which are currently used in the process.

8.6 GMSEquipmentType

The GMSEquipmentType provides information about the sensor or measuring probe.

The GMSEquipmentType is formally defined in Table 21.

AdditionalSensor is a folder that contains all available additional sensors.

Accessories is a folder that contains all available accessories.

<AdditionalSensor> represents individual additional sensors.

<RotaryTable> represents individual rotary tables.

<SensorExchangeRack> represents individual sensor exchange racks.

<TipExchangeRack> represents individual tip exchange racks.

8.7 GMSIdentificationType

The GMSIdentificationType provides information about the current machine.

The GMSIdentificationType is formally defined in Table 23.

SubDeviceClass is defined in a more special way than the generic DeviceClass. The classification is made based on the description in section 5.1.2. The corresponding possible values (for the SubDeviceClass) may be taken from Table 24.

Workspace is defined as the workspace of the axes, which is the same as the Measuring Range in most situations.

8.8 GMSMonitoringType

The GMSMonitoringType provides information about monitoring the status of the GMS.

The GMSMonitoringType is formally defined in Table 25.

LoadingMonitoring informs if the machine is in a safe position for loading.

ToolMonitoring provides monitoring information about the tool (e.g., the currently used tool).

8.9 GMSJobType

The GMSJobType provides aggregated production data to run a sequence of measurements of several parts after one preparatory mounting.

The GMSJobType is formally defined in Table 26.

BatchIdentifier is defined as the unique batch identifier of the job for future reference.

Duration is defined as approximate time in milliseconds this job will take. This value can be estimated by the machine based on the last measurement runs or on the measuring equipment capability test.

RemainingTime is defined as the time in milliseconds remaining for the MeasuringRoutine and the part. It represents an approximated value that can't always be determined precisely.

MeasurementReason indicates why this job is carried out.

8.10 GMSPartType

The GMSPartType provides information about the component to be measured by the GMS.

The GMSPartType is formally defined in Table 27.

NestIdentifier indicates the nesting or spindle used to create or process the current part.

The operator specifies the worker who performs the measurement. The field contains an Identifier of the worker.

PartAmendmentStatus is used to distinguish and identify a version of the part type currently measured via a GMS.

PartCarrierIdentifier defines the unique identifier for the part carrier.

PartDescription is defined as a free text field that can be used for a customer part description.

ProcessParameter is defined as an additional parameter that describes the process.

ProcessingMachineIdentifier is a unique identifier of the machine that has processed the part.

ProductionNumber is a freely selectable identifier that identifies a subset of a production batch.

8.11 CalibrationPrognosisType

The CalibrationPrognosisType provides information about the GMS status regarding its performance. During the calibration the GMS’s errors are determined. The GMS performance is verified if the error is not greater than the specification. The information about the error is not used for correction. The GMS is not considered as a calibration target according to OPC 10000-200. Therefore a separate specification is defined here. The CalibrationPrognosisType is formally defined in Table 28.

Calibrated indicates whether the machine is calibrated or not.

CalibrationInterval is defined as the interval of time in which the machine needs a new calibration. The exact interval depends on the measuring principle and the machine utilization and is provided by the customer.

CalibrationPreptime is defined as the additional time needed to prepare a calibration considering the calibration interval to assure that the calibration expired (see Figure 24 for reference).

DateOfCalibration is defined as the date and time when the last calibration was carried out.

CalibrationCertificate contains a reference to all available calibration certificates.

8.12 GMSResultManagementType

The GMSResultManagementType provides mechanisms to access results generated by the underlying GMS. Results can be managed in a local result store of the Server. Methods and Objects with Variables as well as Events and external file stores can be used to provide the results for the Client.

Figure 22 shows the hierarchical structure and details of the composition. It is formally defined in Table 29.

This ObjectType extends the ResultManagementType of the Machinery. As part of this extension, deviation values can be provided via OPC UA.

CorrectionsFolder is a folder that contains several corrections. The count and the corrections itself are application-specific.

The components of the GMSResultManagementType have additional subcomponents which are defined in Table 30.

<Corrections> represents individual corrections.

CorrectionCount indicates the total number of corrections.

8.13 CorrectionType

The CorrectionType provides information about a correction value the GMS has calculated. It is formally defined in Table 31. The value is the deviation of a characteristic value from a target value. The target value is a value the manufacturing should achieve. The correction can be used by a (tool) machine to adjust the production process. This can be, for example, the correction of a tool. Either the correction value relative or the correction value absolute must be implemented.

Identifier is a unique ID to identify this correction value.

CharacteristicIdentifier is a reference to the characteristic.

CorrectionValueRelative indicates how much the characteristic deviates and gives an indication to the upstream system how much the processing needs to be adjusted. The value is relative to the target value.

CorrectionValueAbsolute indicates how much the characteristic deviates and gives an indication to the upstream system how much the processing needs to be adjusted. The value is absolute to the target value.

The UpperControlLimit is the upper limit from which on a correction should be applied.

The LowerControlLimit is the lower limit from which on a correction should be applied.

ProgramName contains the name of the program.

8.14 RotaryTableType

The RotaryTableType provides information about a rotary table used as an additional degree of freedom in some GMS.

The RotaryTableType is formally defined in Table 32.

Identification is performed according to MachineryIdentificationType.

IsIntegrated is defined as True if the RotaryTable is integrated into the GMS and cannot be removed.

NumberOfAxes defines the number of axes (DegreesOfFreedom) the RotaryTable can be configured for.

8.15 SensorExchangeRackType

The SensorExchangeRackType provides information about a sensor exchange rack used as an additional rack for sensors in some GMS.

The SensorExchangeRackType is formally defined in Table 33.

Identification is performed according to MachineryIdentificationType.

IsAvailable is defined as True if the SensorExchangeRack is available into the GMS.

8.16 TipExchangeRackType

The TipExchangeRackType provides information about a tip exchange rack used as an additional rack for tips in some GMS.

The TipExchangeRackType is formally defined in Table 34.

Identification is performed according to MachineryIdentificationType.

IsAvailable is defined as True if the TipExchangeRack is available into the GMS.

8.17 CharacteristicType

The CharacteristicType contains the Metainformation about a characteristic of the part. Its representation in the AddressSpace is formally defined in Table 35.

CharacteristicIdentifier is a unique identifier of the measured characteristic.

ResultValue is the actual measurement result value.

ResultEvaluation indicates whether the result was in tolerance.

UpperToleranceLimit is the absolute upper limit where the part is still in its specification.

LowerToleranceLimit is the absolute lower limit where the part is still in its specification.

Nominal is the value given in the Geometrical Product Specification. This value indicates which theoretical value the component or the distance between two construction reference points must have (e.g., how large the bore hole must be).

CharacteristicsClass is a hint of the importance of the characteristic. The least important class is 0. Higher classes are more important. An example based on Q-DAS for the value description is given here [AQDEF 5]:

0 unimportant

1 little important

2 important

3 significant

4 critical

IsValid is used to mark the measured value as valid or invalid. A measurement run can be invalid within the scope of the current measurement for some reason (e.g., a hole missing in the current part). The result file could contain more information.

The Formula describes how the measurement is performed (e.g., T1-((T20-21)*0.41 + (T22-T23)*0.7))

CharacteristicType components have additional subcomponents which are defined inTable 36.

9 OPC UA EventTypes

9.1 SensorWarningAlarmType

This SensorWarningAlarmType is used if an additional sensor (e.g., a temperature sensor) measures a value that is out of the allowed range. This alarm is only used for sensors that are not involved in the geometrical measurement directly (e.g., a probe). Its representation in the AddressSpace is formally defined in Table 37.

The ErrorCode is used as the manufacturer defined error code. Often this is a numeric code whose meaning can be found in the manufacturer's documentation for the Geometric Measurement System.

It is supposed that any error message shown to users of the system is transmitted with the SensorWarningAlarmType in the Message Property inherited from the BaseEventType.

9.2 IntermediateResultEventType

This IntermediateResultEventType is a subtype of the ResultReadyEventType. Instead of a ResultReadyEvent this event should be used for an intermediate result which contains information about one or more characteristics. Its representation in the AddressSpace is formally defined in Table 38.

Characteristics contains the information about the characteristics that are measured in this step.

ProgramName contains the name of the program.

10 OPC UA VariableTypes

10.1 GMSResultType

The GMSResultType contains information about the measurement result. It extends the generic ResultType of OPC UA for Machinery.

The GMSResultType is formally defined in Table 39.

UsedTools is defined as an array of all tools used to create this result

10.2 CatalogType

The CatalogType is a subtype of the MultiStateValueDiscreteType. It is used to represent a value that is defined by a customer catalogue (e.g., company catalog). An example of a catalog can be found at https://www.q-das.com/en/service/data-format-aqdef.

It is formally defined in Table 40.

The CatalogEntry is the key that points to the value.

The CatalogName is the name of the catalog or a subcatalog used in the machine environment.

10.3 AdditionalSensorType

The AdditionalSensorType is a subtype of the 0:AnalogUnitType. It is used to represent additional sensor e.g., temperature sensors.

It is formally defined in Table 41.

Identifier is the identifier of the sensor. The Identifier shall be unique within the AddressSpace.

Class indicates what type of sensor the current one is (e.g., temperature, vibration, humidity, others).

Name is used to distinguish and identify sensors on a GMS (e.g., temp_sensor_ext_1). Hence, the Name should be unique within the GMSType it belongs to.

The component Variables of the SensorType have additional Attributes defined in Table 42.

11 OPC UA DataTypes

11.1 WorkspaceType

This structure contains all information about a Workspace. This Structure is an abstract DataType and further divides into the subtypes of Cartesian and Cylindrical workspaces.

Its representation in the AddressSpace is defined in Table 43.

11.2 CartesianWorkspaceType

This structure contains the information of a Cartesian Workspace. The structure is defined in Table 44.

Its representation in the AddressSpace is defined in Table 45.

11.3 CylindricalWorkspaceType

This structure contains the information of a Cylindrical Workspace. The structure is defined in Table 46

Its representation in the AddressSpace is defined in Table 47

11.4 MeasurementReasonEnum

This enumeration MeasurementReasonEnum indicates the reason of a measurement. The enumeration is defined in Table 48.

The MeasurementReasonEnum representation in the AddressSpace is defined in Table 49.

11.5 ToleranceLimitEnum

This enumeration defines the kind of a tolerance limit. The enumeration is defined in Table 50.

Its representation in the AddressSpace is defined in Table 51.

11.6 ToolAlignmentState

This enumeration defines the alignment of a tool. The enumeration is defined in Table 52.

Its representation in the AddressSpace is defined in Table 53.

11.7 ToolIsQualifiedStatus

This enumeration defines qualified status of a tool. The enumeration is defined in Table 54.

Its representation in the AddressSpace is defined in Table 55.

12 Profiles and Conformance Units

12.1 Overview

The structure of the Profiles and Conformance Units is based on the Profiles of the machine tools and is shown in Figure 25. All servers need to implement the basic profile which can be extended with additional facets.

12.2 Conformance Units

Table 56 defines the corresponding ConformanceUnits for the OPC UA Information for GMS.

12.3 Profiles

12.3.1 Profile list

Table 57 lists all Profiles defined in this document and defines their URIs.

12.3.2 Server Facets

12.3.2.1 Overview

The following sections specify the Facets available for Servers that implement the OPC UA for Geometric Measurement Systems. Each section defines and describes a Facet or Profile.

12.3.2.2 GMS Basic Server Profile

Table 58 defines a Profile that describes the minimum required content and address space functionality any GMS server shall at least provide.

12.3.2.3 GMS Basic Secure Server Profile

Table 58 defines a Profile that adds security features for client authentication to the GMS Basic Server Profile.

12.3.2.4 GMS Monitoring Server Profile

Table 60 defines a Facet that describes the additional monitoring information.

12.3.2.5 GMS Tools Server Facet

Table 61 defines a Facet, that contains the information about tools (sensors) in the GMS. If the list of tools is used dynamically, the ConformanceUnits MachineTool Event Propagation and MachineTool Event Tools shall be provided.

12.3.2.6 GMS Tool Life Server Facet

Table 62 defines a Facet, that provides the tool life data for tools in the GMS.

12.3.2.7 GMS Production Server Facet

Table 63 defines a Facet, that contains enhanced information about the process on the GMS compared to the MachineTool Basic Server Profile.

12.3.2.8 GMS Errors and Alerts Server Facet

Table 64 defines a Facet, that contains the ConformanceUnits concerning errors and alerts sent by the GMS.

12.3.2.9 GMS Prognoses Server Facet

Table 65 defines a Facet, that contains the ConformanceUnits related to the Prognoses Server sent by the GMS

12.3.2.10 GMS Result Server Facet

Table 66 defines a Facet, that contains enhanced information about the result and result management on the GMS.

13 Namespaces

13.1 Namespace Metadata

Table 67 defines the namespace metadata for this document. The object is used to provide version information for the namespace and an indication about static Nodes. Static Nodes are identical for all Attributes in all Servers, including the Value Attribute. See OPC 10000-5 for more details.

The information is provided as Object of type NamespaceMetadataType. This object is a component of the Namespaces Object that is part of the Server Object. The NamespaceMetadataType ObjectType and its Properties are defined in OPC 10000-5.

The version information is also provided as part of the ModelTableEntry in the UANodeSet XML file. The UANodeSet XML schema is defined in OPC 10000-6.

Note: The IsNamespaceSubset Property is set to False as the UANodeSet XML file contains the complete Namespace. Servers only exposing a subset of the Namespace need to change the value to True.

13.2 Handling of OPC UA Namespaces

Namespaces are used by OPC UA to create unique identifiers across different naming authorities. The Attributes NodeId and BrowseName are identifiers. A Node in the UA AddressSpace is unambiguously identified using a NodeId. Unlike NodeIds, the BrowseName cannot be used to unambiguously identify a Node. Different Nodes may have the same BrowseName. They are used to build a browse path between two Nodes or to define a standard Property.

Servers may often choose to use the same namespace for the NodeId and the BrowseName. However, if they want to provide a standard Property, its BrowseName shall have the namespace of the standards body although the namespace of the NodeId reflects something else, for example the EngineeringUnits Property. All NodeIds of Nodes not defined in this document shall not use the standard namespaces.

Table 68 provides a list of mandatory and optional namespaces used in an GMS OPC UA Server.

Table 69 provides a list of namespaces and their indices used for BrowseNames in this document. The default namespace of this document is not listed since all BrowseNames without prefix use this default namespace.