1 Scope

This document defines a Companion Specification for Wireless Machine Tool Peripherals (WMTP) using OPC UA constructs to exchange process parameters wireless between components and software systems, such as MES-Systems, mobile devices, etc.

The process parameters are recorded by sensors on the components and are used for process monitoring.

The aim of the specification is to define all relevant process parameters for the use of wireless machine tool peripherals in alignment to the Bluetooth Industial Measurement Devices standard for WMTP (see 2). Only the industry-specific (manufacturer-independent) process values are defined - company-specific process values are not taken into account in the specification.

The first version of the OPC UA Companion Specification for WMTP applies to driven tool units, static tool holders and angle heads. Other sensor-equipped machine peripherals can be modelled on the basis of this Companion Specification, but will probably have to be extended by certain parameters.

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

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

http://www.opcfoundation.org/documents/10000-1/

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

http://www.opcfoundation.org/documents/10000-2/

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

http://www.opcfoundation.org/documents/10000-3/

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

http://www.opcfoundation.org/documents/10000-4/

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

http://www.opcfoundation.org/documents/10000-5/

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

http://www.opcfoundation.org/documents/10000-6/

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

http://www.opcfoundation.org/documents/10000-7/

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

http://www.opcfoundation.org/documents/10000-100/

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

http://www.opcfoundation.org/documents/40001-1/

OPC 30081, OPC UA for Process Automation Devices – PA-DIM

http://www.opcfoundation.org/documents/30081/

OPC 40001-2, OPC UA for Machinery – Part2: Process Values

http://www.opcfoundation.org/documents/40001-2/

Bluetooth Industial Measurement Devices for WMTP

https://www.bluetooth.com/specifications/specs/industrial-measurement-device-service-2/

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 Wireless Machine Tool Peripheral 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, … 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 Wireless Machine Tool Peripherals terms

3.2.1

Wireless Machine Tool Peripheral

Nonstationary component of a machine tool that can transmit data wirelessly.

3.2.2

Driven Tool Unit

Tool unit with one or more spindles for clamping rotating cutting tools driven by a machine tool.

3.2.3

Static Tool Holder

Tool holder for clamping of non-rotating tools in lathes.

3.2.4

Adjustable Boring Unit

Adjustable boring unit for making holes with different diameters in workpieces.

3.2.5

Workpiece Clamping Device

Device for fixing and positioning workpieces in machine tools.

3.2.6

Touch Probe

A switch that switches when a workpiece surface is touched, providing repeatable geometric data.

3.2.7

Bluetooth

A standard communication protocol for wireless data transmission between devices over a short distance.

3.2.7

Work Cycle
A work cycle is the process enclosing a single operation (e.g., drilling one hole into a workpiece).

3.2.7

Service Cycle
A service cycle is the interval between two maintenance operations. The Service Cycle Data provides values describing the service cycle of the device.

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 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 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 illustrates the 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.

Each Type Node or well-known Instance Node defined shall have one or more ConformanceUnits defined in 9.1 that require the Node to be in the AddressSpace.

The relations between Nodes and ConformanceUnits are defined at the end of the tables defining Nodes, one row per ConformanceUnit. The ConformanceUnits are reflected in the Category element for the Node definition in the UANodeSet (see OPC 10000-6).

The list of ConformanceUnits in the UANodeSet allows Servers to optimize resource consumption by using a list of supported ConformanceUnits to select a subset of the Nodes in an Information Model.

When a Node is selected in this way, all dependencies implied by the References are also selected.

Dependencies exist if the Node is the source of HasTypeDefinition, HasInterface, HasAddIn or any HierarchicalReference. Dependencies also exist if the Node is the target of a HasSubtype Reference. For Variables and VariableTypes, the value of the DataType Attribute is a dependency. For DataType Nodes, any DataTypes referenced in the DataTypeDefinition Attribute are also dependencies.

For additional details see OPC 10000-5.

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.

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 10.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 74 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.

3.4.4 Structures

OPC 10000-3 differentiates between different kinds of Structures. The following conventions explain, how these Structures shall be defined.

The first kind are Structures without optional fields where none of the fields allows subtype (except fields with abstract DataTypes). Its definition is in Table 12.

The second kind are Structures with optional fields where none of the fields allows subtypes (except fields with abstract DataTypes). Its definition is in Table 13.

Structures with fields that are optional have an “Optional” column. Fields that are optional have True set, otherwise False.

The third kind are Structures without optional fields where one or more of the fields allow subtypes. Its definition is in Table 14.

Structures with fields that allow subtypes have an “Allow Subtypes” column. Fields that allow subtypes have True set, otherwise False. Fields with abstract DataTypes can always be subtyped.

4 General information to Wireless Machine Tool Peripherals and OPC UA

4.1 Introduction to Wireless Machine Tool Peripherals

WMTP are components that are used in machine tools for various machining tasks and can transmit acquired data wirelessly. WMTPs can be, for example, static tool holders or driven tool units. These are intermediate components between the machine tool and the machining tools. By means of sensors, process data such as temperature, vibrations, humidity, etc. can be recorded in these components and used for process monitoring.

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 Wireless Machine Tool Peripherals, 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.

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 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 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 of 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 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 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 functionality (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 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

This section introduces the use cases for the OPC UA for Wireless Machine Tool Peripherals specification.

5.1 Conformity with the Industrial Measurement Devices standard for WMTP

The information model should map the entire scope of the Industrial Measurement Devices Bluetooth standard for WMTP.

5.2 Identify Wireless Machine Tool Peripherals in a standardized way

The WMTP of different manufacturers shall be identifiable in a standardized manner. To realize this, a number of basic and static information like manufacturer name and serial number are offered on the WMTP interface.

5.3 Status of the battery level

Usually a WMTP has an integrated battery. The status of the battery charge level indicates how much energy is currently in the battery in relation to the total capacity of the battery. It should be ensured that the filling level of the battery is made available.

5.4 Condition monitoring of the WMTP

To ensure a high level of process reliability, the operating status of the device must be monitored permanently and unmanned. For this purpose, data is permanently recorded during use on the device using sensors and transmitted to a gateway. The data may include e.g., operating hours, temperature, humidity, forces.

5.5 Writing the current date and time to the WMTP

In order to be able to track events, the current date and time can be written to the device for logging. When troubleshooting or performing maintenance, it is helpful to know the exact time of a particular event.

5.6 Possibility to update the firmware

To ensure functionality, security and performance, it should be possible to distribute a firmware update to the device. This should be done by transferring a byte stream.

5.7 Licensing of the WMTP

A licence is issued for the use of a software product. It should be possible to store license information permanently on the device with the possibility to verify its validity. Licence information can be, for example product name, licence number, delivery note number, hardware serial number.

5.8 Harmonization with existing standards such as OPC UA for Machinery

Where possible and appropriate, the modeled information model should be based on preliminary work by other standards. For example, the OPC UA for Machinery specification maps different structures that are relevant for the entire mechanical engineering sector. It is useful to promote harmonization by referencing such building blocks.

6 Wireless Machine Tool Peripheral Information Model overview

This section provides an overview of the OPC UA information model for wireless machine tool peripherals (WMTP). The information model for WMTP provides the ObjectTypes, VariableTypes and Methods required to map the Industrial Measurement Devices standard for WMTP. When using this OPC UA information model, the user is not bound to the Industrial Measurement Devices standard for WMTP.

The resulting data of a WMTP, as well as the methods to be executed on it, are assigned to the respective FolderType Objects.

The FolderType DeviceConfiguration provides methods and variables relating to the configuration of a WMTP. In addition to WMTP identification data, the DeviceInformation FolderType object also provides information on the battery level and information on the device license and life cycle, for example.

The FolderType Measurements contains all measured values actually recorded by the WMTP. Depending on the application, a WMTP can potentially record a large number of different measured values. First and foremost, these are explicitly temperature, rotation speed, humidity, acceleration and vibration, applied force, torque, the position of a reference point and the dimension. All these measurements can be implemented with one developed ObjectType for measurements, called WMTPMeasurementType. Instances of these measurements shall be located in the FolderType Measurements. The WMTPMeasurementType is a subtype of the ProcessValueType defined in “OPC UA for Machinery – Part 2: Process Values” (OPC 40001-2).

With the use of the two ObjectTypes WMTPWorkCycleDateType and WMTPServiceCycleDataType, desired data and service records can be transferred or deleted from the WMTP. The data is sent by the WMTP to the Client in response to the method used, the data is not stored to a specific node of the information model.

On Figure 6 you can see an overview of the WirelessMachineToolPeripheralType.

7 OPC UA ObjectTypes

Figure 7 shows all ObjectTypes which are defined by this companion specification.

7.1 WirelessMachineToolPeripheralType ObjectType Definition

7.1.1 Overview

The WirelessMachineToolPeripheralType provides information about the WMTP itself. This ObjectType is the entry point to the OPC UA interface of a WMTP. An instance of this ObjectType aggregates all information related to one system.

It is highly recommended that all instances of a WirelessMachineToolPeripheralType are referenced from the 3:Machines node defined in OPC 40001-1.

The WirelessMachineToolPeripheralType is formally defined in Table 15.

DeviceConfiguration is representing a collection of all nodes that enable configuration or provide information on the configuration of a WMTP.

DeviceInformation is representing a collection of all nodes that provide information about the WMTP.

WMTPWorkCycleData enables the handling of measured work cycles.

WMTPServiceCycleData enables the handling of service data of the WMTP.

MachineryLifetimeCounters is representing a collection of all counters with a start and an end value. It is used as the MachineryLifetimeCounterType defined in OPC 40001-1. In the information model for WMTP, all counters that are implemented according to the MachineryLifetimeCounterType of the OPC 40001-1 shall be integrated with the HasComponent reference under this Object. This Object shall also be referenced as HasAddIn in the MachineryBuildingBlocks Folder.

MachineryOperationCounters is representing a collection of all incrementing counters. It is used as the MachineryOperationCounterType defined in OPC 40001-1. In the information model for WMTP, all counters that are implemented according to the MachineryLifetimeCounterType of the OPC 40001-1 shall be integrated with the HasComponent reference under this Object. This Object shall also be referenced as HasAddIn in the MachineryBuildingBlocks Folder.

Measurements is representing a collection of all nodes that provide values measured by the WMTP, such as temperature, rotation speed, humidity, etc.

MachineryBuildingBlocks is representing a folder that directly references all those building blocks of the OPC UA for Machinery (OPC 40001-1, OPC 40001-3) which are implemented with an HasAddIn reference in this information model.

The components of the WirelessMachineToolPeripheralType have additional references which are defined in Table 16.

The components of the WirelessMachineToolPeripheralType have additional subcomponents which are defined in Table 17.

CalibrationMode indicates whether the device is currently in calibration mode or not. True means the WMTP is in calibration mode.

SetDeviceTime enables writing the current date and time on the WMTP.

UpdateFirmware enables transferring a new firmware to the WMTP. Possible implementation or monitoring of the installation takes place independently of OPC UA on the respective WMTP and is solved differently by different manufacturers.

SendLicenseData enables transferring license data to the WMTP. Possible implementation or monitoring of the installation takes place independently of OPC UA on the respective WMTP and is solved differently by different manufacturers.

SwitchCalibrationMode enables the WMTP to be switched to calibration mode and back.

Identification is used as defined in OPC 40001-1 and shall also be referenced as AddIn in the

MachineryBuildingBlocks Folder.

BatteryLevel contains all data on the current battery level of the WMTP.

LicenseInformation contains information about the license of the WMTP. How this information looks like is solved differently by different manufacturers.

NextServiceDate is the date when the next maintenance is scheduled.

LastService is the date when the last maintenance of the device was carried out.

LifeCycleStatus is a parameter which outputs the life cycle in the form of four stages (unknown, green, yellow, red). This parameter is generated internally in the WMTP and is solved differently by different manufacturers.

LicenseValidity is used as the MachineryLifetimeCounterType is defined in OPC 40001-1. It is representing a counter that counts down a time value specified by the manufacturer of the WMTP. At the end of this period, the license of the WMTP Software is not valid anymore.

RemainingLifetimeCounter is used as the MachineryLifetimeCounterType is defined in OPC 40001-1. It is representing a counter that counts down a time value specified by the manufacturer of the WMTP. At the end of this period, the WMTP has reached its maximum lifetime.

RemainingCycleCounter is used as the MachineryLifetimeCounterType is defined in OPC 40001-1. It is representing a counter that counts down a number of working cycles specified by the manufacturer of the WMTP. At the end of this period, the WMTP has reached its maximum service life.

NextServiceCounter is used as the MachineryLifetimeCounterType is defined in OPC 40001-1. It is representing a counter that counts down a time value specified by the manufacturer of the WMTP. A service is to be carried out when this time period expires.

OperationSinceLastServiceCounter is representing a counter that counts the duration of use since the last service of the WMTP.

Temperature contains all data on the measured temperature.

RotationSpeed contains all data on the measured rotational speed.

Humidity contains all data on the measured humidity.

Acceleration contains all data on the measured acceleration of the WMTP.

Force contains all data on the measured force.

Torque contains all data on the measured torque.

Position contains all data on the measured position of the WMTP.

Dimension contains all data on the measured dimension.

NOTE: The list of measurements is representing the most used types. The model can be extended as required by the end user.

A child Node of the WirelessMachineToolPeripheralType has an additional Attribute value defined in Table 18.

7.1.2 SetDeviceTime

The Method SetDeviceTime allows to set the device time. The signature of this Method is specified below.

Signature

	SetDeviceTime (
		[in]	0:DateTime		DateTime,
		[in]	0:TimeZoneDataType	TimeZoneOffset
	);
	

NOTE: A call with DateTime = "2024-02-03 12:00" (UTC time) and TimeZoneOffset = {120; true}, sets the (local) machine time to "03-02-2024 14:00" and the time zone to "UTC+2".

7.1.3 UpdateFirmware

The Method UpdateFirmware sends a new firmware to be transferred to the WMTP. The signature of this Method is specified below.

Signature

	UpdateFirmware (
		[in]	0:Byte[]	FirmwareData
	);
	

7.1.4 SendLicenseData

The Method SendLicenseData sends license data to the WMTP. The signature of this Method is specified below.

Signature

	SendLicenseData (
		[in]	0:Byte[]	LicenseData
	);
	

7.1.5 SwitchCalibrationMode

The Method SwitchCalibrationMode enables to switch the WMTP between "Calibrate" mode and "Use" mode. The signature of this Method is specified below.

Signature

	SwitchCalibrationMode (
		[in]	0:UInt16	TargetMode
	);
	

7.2 ObjectTypes for data transfer and management

7.2.1 WMTPWorkCycleDataType ObjectType Definition

The WMTPWorkCycleDataType provides the Methods that are required for reading out and deleting the work cycle data of a WMTP. It is formally defined in Table 27.

DeleteAllStoredRecords enables to permanently delete all stored data from the WMTP.

DeleteStoredRecordsTime enables to permanently delete a desired section of stored data from the WMTP, chosen by the time of measurement.

DeleteStoredRecordsIndex enables to permanently delete a desired section of stored data from the WMTP, chosen by the index of measurement.

AbortOperation enables the termination of the process currently being executed by the WMTP. This is necessary as some transfer processes can take several minutes.

ReportNumberOfStoredRecords enables querying the number of data records available on the WMTP.

ReportNumberOfStoredRecordsTime enables querying the number of data records available on the WMTP according to a given timespan.

CombinedReportAll enables to request all stored data from the WMTP.

CombinedReportIndex enables to request the stored data from the WMTP according to the index of the measurements. Using this method, it is possible to request the entire data set as well as desired sections.

CombinedReportTime enables to request the stored data from the WMTP according to the timestamp of the measurements. Using this method, it is possible to request the entire data set as well as desired sections.

7.2.2 WMTPServiceCycleDataType ObjectType Definition

The WMTPServiceCycleDataType provides the Methods that are required for reading out and deleting the service cycle data of a WMTP. It is formally defined in Table 28.

DeleteStoredAllRecords enables to permanently delete all stored data from the WMTP. Using this method, it is possible to remove the entire data set as well as desired sections.

DeleteStoredRecordsTime enables to permanently delete a desired section of stored data from the WMTP, chosen by the time of measurement.

DeleteStoredRecordsNumber enables to permanently delete a desired section of stored data from the WMTP, chosen by the index of measurement.

AbortOperation enables the termination of the process currently being executed by the WMTP. This is necessary as some transfer processes can take several minutes.

ReportNumberOfStoredRecords enables querying the number of data records available on the WMTP.

ReportNumberOfStoredRecordsTime enables querying the number of data records available on the WMTP according to a given timespan.

CombinedReportAll enables to request all stored data from the WMTP.

CombinedReportIndex enables to request the stored data from the WMTP according to the index of the measurements. Using this method, it is possible to request the entire data set as well as desired sections.

CombinedReportTime enables to request the stored data from the WMTP according to the timestamp of the measurements. Using this method, it is possible to request the entire data set as well as desired sections.

7.2.3 Methods used for data transfer and management

7.2.3.1 DeleteAllStoredRecords

The Method DeleteAllStoredRecords enables to permanently delete all stored data from the WMTP. Using this method, it is possible to remove the entire data set. The signature of this Method is specified below.

Signature

	DeleteAllStoredRecords (
	);

7.2.3.2 DeleteStoredRecordsTime

The Method DeleteStoredRecordsTime enables to permanently delete the stored data from the WMTP from a specific given time. The signature of this Method is specified below.

Signature

	DeleteStoredRecordsTime (
		[in]	0:DateTime	FromTimestamp,
		[in]	0:DateTime	ToTimestamp,
	);
	

7.2.3.3 DeleteStoredRecordsIndex

The Method DeleteStoredRecordsIndex enables to permanently delete the stored data from the WMTP from a specific given time. The signature of this Method is specified below.

Signature

	DeleteStoredRecordsIndex (
		[in]	0:UInt32	FromIndex,
		[in]	0:UInt32	ToIndex,
	);
	

7.2.3.4 AbortOperation

The Method AbortOperation enables the termination of the process currently being executed by the WMTP. This is necessary as some transfer processes can take several minutes. The signature of this Method is specified below.

Signature

	AbortOperation (
	);

7.2.3.5 ReportNumberOfStoredRecords

The Method ReportNumberOfStoredRecords enables to report how many records are currently stored at the WMTP.

Signature

	ReportNumberOfStoredRecords (
		[out]	0:UInt32	NumberOfStoredRecords);
	

7.2.3.6 ReportNumberOfStoredRecordsTime

The Method ReportNumberOfStoredRecordsTime enables to report how many records are currently stored at the WMTP in a specific timespan.

Signature

	ReportNumberOfStoredRecordsTime (
		[in]	0:DateTime	FromTimestamp,
		[in]	0:DateTime	ToTimestamp,
		[out]	0:UInt32	NumberOfStoredRecords);
	

7.2.3.7 CombinedReportAll

The Method CombinedReportAll enables access to the entire data set stored on the WMTP. A record transfer is defined within this specification as a transfer of a “copy” of the records and not a “move” of the records because the server retains the original log entries. The signature of this Method is specified below.

Signature

	CombinedReportAll (
		[out]	WMTPOutputDataType[]	CombinedReport
	);
	

NOTE: If all measured values exceed the maximum size of an OPC UA message, this method cannot be used. In this case, the data should be queried in packets, for example using the CombinedReportIndex.

7.2.3.8 CombinedReportIndex

The Method CombinedReportIndex enables access to the entire data set stored on the WMTP based on the index of the measurements. A record transfer is defined within this specification as a transfer of a “copy” of the records and not a “move” of the records because the server retains the original log entries. The signature of this Method is specified below.

Signature

	CombinedReportIndex (
		[in]	0:UInt32	FromIndex,
		[in]	0:UInt32	ToIndex,
		[out]	WMTPOutputDataType[]	CombinedReport
	);
	

7.2.3.9 CombinedReportLastValue

The Method CombinedReportLastValue enables access to the last measurement stored on the WMTP. A record transfer is defined within this specification as a transfer of a “copy” of the records and not a “move” of the records because the server retains the original log entries. The signature of this Method is specified below.

Signature

	CombinedReportLastValue (
		[out]	WMTPOutputDataType	CombinedReport
	);
	

7.2.3.10 CombinedReportFirstValue

The Method CombinedReportFirstValue enables access to the first measurement stored on the WMTP. A record transfer is defined within this specification as a transfer of a “copy” of the records and not a “move” of the records because the server retains the original log entries. The signature of this Method is specified below.

Signature

	CombinedReportFirstValue (
		[out]	WMTPOutputDataType	CombinedReport
	);
	

7.2.3.11 CombinedReportTime

The Method CombinedReportTime enables access to the entire data set stored on the WMTP based on the timestamp of the measurements. A record transfer is defined within this specification as a transfer of a “copy” of the records and not a “move” of the records because the server retains the original log entries. The signature of this Method is specified below.

Signature

	CombinedReportTime (
		[in]	0:DateTime	FromTimestamp,
		[in]	0:DateTime	ToTimestamp,
		[out]	WMTPOutputDataType[]	CombinedReport
	
	);
	

7.3 WMTPMeasurementType ObjectType Definition

7.3.1 Overview

The WMTPMeasurementType is a subtype of the ProcessValueType defined in OPC 40001-2.

Figure 9 shows an overview of the WMTPMeasurementType. The blue marked Variables 5:AnalogSignal and Status are inherited from the respective supertypes and are complemented by the WMTPMeasurementType.

The WMTPMeasurementType is formally defined in Table 47.

LimitCounters is used as the MachineryOperationCounterType defined in OPC 40001-1. The WMTPMeasurementType is using the LimitCounters to structure the two counters OperationAboveHigh and OperationAboveHighHigh. The LimitCounters shall also be referenced as AddIn in the MachineryBuildingBlocks Folder to provide better access from a higher level.

TriggerSettings represents the time period from one measurement point to the next. If the relevant sensor of the WMTP does not define the measurement triggering using the TriggerSettings, the default value 0 shall be assumed.

SetTriggerSettings enables the TriggerSettings to be adjusted.

DeltaCondition represents the delta value that needs to be reached before the WMTP triggers the next measurement transmission. If the relevant sensor of the WMTP does not define the measurement triggering using the DeltaCondition, the default value 0 shall be assumed.

SetDeltaCondition enables the DeltaCondition to be adjusted.

NOTE: A WMTP sensor requires at least one value for the TriggerSettings or the DeltaCondition, as these variables are used to determine the measuring frequency. It is also possible to convert both conditions. If one of the variables is not required, the default value must be set for this variable. It must be ensured that both values are not zero at the same time.

TypeOfMeasurement describes which physical type of measurement is represented by this Instance of the WMTPMeasurementType. A list of possible options can be found in Table 48.

TypeOfSample defines the category of the measurement set. This specification defines standardized values for resources Table 48.

RelativeUncertainty is representing the percent uncertainty of measurement.

AbsoluteUncertainty is representing the measurement error in the same unit as the measured value.

Timestamp is representing the exact time of the measurement. Since the WMTP collects the data at a different time than when it is transferred to the OPC UA server, the time of data collection should be stored within this property.

Index is representing the number of the measurement.

MeasurementPeriod defines the time period over which the WMTPMeasurementType was recorded.

InternalUpdateInterval defines the sampling rate of the sensor.

Status is inherited from the from OPC 40001-2.

NOTE: The 6:ProcessValueType already provides the Variable SignalTag from the Object SignalType (OPC 30081), which can be used by inheritance in subtypes, is used to describe the location of the measurement. This variable can be used, for example, if several sensors are installed and the measured values must be clearly assignable.

NOTE: The 6:ProcessValueType already provides the Variable ValuePrecision from the Object 0:DataItemType, which can be used by inheritance in subtypes, is used to describe the precision (resolution) of the measured value or the sensor. It specifies the smallest increment of the measurement.

A Node of the WMTPMeasurementType has an additional Attribute value defined in Table 48.

The components of the WMTPMeasurementType have additional subcomponents which are defined in Table 49.

OperationAboveHigh represents a counter that records the time that the Status variable has the value 9 (ABOVE_HIGH_LIMIT) or 10 (ABOVE_HIGHHIGH_LIMIT). All the different statuses are defined in OPC 40001-2.

OperationAboveHighHigh represents a counter that records the time that the Status variable has the value 10 (ABOVE_HIGHHIGH_LIMIT). All the different statuses are defined in OPC 40001-2.

NOTE: The WMTPMeasurementType is a subtype of the ProcessValueType from OPC 40001-2. The additional subcomponents mentioned above are referring to the mandatory 5:AnalogSignal Variable and the Status Variable of the ProcessValueType which are inherited to the WMTPMeasurementType.

The components of the WMTPMeasurementType have additional references which are defined in Table 50.

7.3.2 SetTriggerSettings

The Method SetTriggerSettings enables to adjust the trigger settings of the relevant sensor of the WMTP. TriggerSettings represents the time period from one measurement point to the next. If the relevant sensor of the WMTP does not define the measurement triggering using the TriggerSettings, the default value 0 shall be assumed.

Signature

	SetTriggerSettings (
		[in]	0:Duration	TriggerDuration
	);
	

7.3.3 SetDeltaCondition

The Method SetDeltaCondition enables to adjust the delta condition of the relevant sensor of the WMTP. DeltaCondition represents the delta value that needs to be reached before the WMTP triggers the next measurement transmission. If the relevant sensor of the WMTP does not define the measurement triggering using the DeltaCondition, the default value 0 shall be assumed.

Signature

	SetDeltaCondition (
		[in]	0:Number	DeltaValue
	);
	
	
	NOTE: The DeltaValue parameter must be adapted to the existing measured value of the WMTPMeasurementType. The EngineeringUnit and the DataType of the number must therefore also be used here in this input parameter of the method.

8 OPC UA DataTypes

8.1 WMTPOutputDataType

The WMTPOutputDataType represents a structure that defines optional and mandatory variables that can be output when querying a WMTP. All contained entries in the structure are nodes of the WMTPMeasurementType or one of its supertypes. The structure is defined in Table 55.

NOTE: Many controllers/embedded devices do not yet support structures with optional entries. To ensure that such devices can also interpret the present structure, all entries have been set as mandatory. The entries EngineeringUnits, ActualValue, TypeOfMeasurement, and TypeOfSample should always be set. However, if the remaining entries are not required, they can also be set to the default value 0.

Its representation in the AddressSpace is defined in Table 56.

9 Profiles and ConformanceUnits

9.1 Conformance Units

This chapter defines the corresponding Conformance Units for the OPC UA Information Model for OPC UA for Wireless Machine Tool Peripherals.

9.2 Facets

9.2.1 Facet list

Table 58 lists all Facets defined in this document and defines their URIs.

9.2.2 Server Facets

9.2.2.1 Overview

The following sections specify the Facets available for Servers that implement the Wireless Machine Tool Peripherals companion specification. Each section defines and describes a Facet or Profile.

9.2.2.2 WMTP Basic Server Facet

This Facet defines support for base WMTP functionality.

9.2.2.3 WMTP Service and LifeCycle Basic Facet

This Facet defines support for basic WMTP service and lifecycle data.

9.2.2.4 WMTP Service and LifeCycle Advanced Facet

This Facet defines support for advanced WMTP service and lifecycle data.

9.2.2.5 WMTP Temperature Facet

This Facet defines support for at least one WMTP temperature measurement.

9.2.2.6 WMTP Rotation Speed Facet

This Facet defines support for at least one WMTP rotational speed measurement.

9.2.2.7 WMTP Humidity Facet

This Facet defines support for at least one WMTP humidity measurement.

9.2.2.8 WMTP Acceleration Facet

This Facet defines support for at least one WMTP acceleration measurement.

9.2.2.9 WMTP Force Facet

This Facet defines support for at least one WMTP force measurement.

9.2.2.10 WMTP Torque Facet

This Facet defines support for at least one WMTP torque measurement.

9.2.2.11 WMTP Position Facet

This Facet defines support for at least one WMTP position measurement.

9.2.2.12 WMTP Dimension Facet

This Facet defines support for at least one WMTP dimension measurement.

9.2.2.13 WMTP Work Cycle Data Facet

This Facet defines support for handling the work cycle data of a WMTP.

9.2.2.14 WMTP Service Cycle Data Facet

This Facet defines support for handling the work cycle data of a WMTP.

9.2.3 Client Facets

This specification does not define any Client Facets.

10 Namespaces

10.1 Namespace Metadata

Table 72 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.