1 Scope

1.1 Scope of this Companion Specification

This document specifies an OPC UA Information Model for the representation of a machine tool. OPC UA for Machine Tools, Part 1 aims at straightforward integration of a machine tool into higher level IT systems. The scope is to create a common interface among machine tools of different technologies, manufacturers and model series. This first part of the OPC UA Companion Specification for Machine Tools aims to provide the basics for such an interface. These allow for monitoring the machine tool and giving an overview of the jobs on it. This information is mostly technology neutral. The OPC UA for Machine Tools interface allows an exchange of information between a machine tool and software systems like MES, SCADA, ERP or data analytics systems.

1.2 Organizations

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

German Machine Tool Builders’ Association (VDW)

The VDW, headquartered in Frankfurt am Main, Germany, represents the German machine tool industry. Together with the Sector Association Machine Tools and Manufacturing Systems within the VDMA (German Engineering Federation) the VDW comprises about 290 predominantly mid-tier companies. They account for approximately 90 per cent of the sector’s total turnover, which most recently exceeded 17 billion euros.

The VDW represents its members to the public, the politicians, business associates and the academic community, both nationally and internationally. It is also a can-do service provider for its members when it comes to opening up sales markets, keeping the business cycle under observation and acquiring market data, handling technical, commercial and legal issues, cooperation with the international machine tool industry, standardisation and recruitment of new talent. On the basis of in-depth sectoral knowledge, it provides information, consultancy and support in response to individual questions and problems. Permanent committees and working groups guarantee the exchange of sector-specific views and empirical feedback. We provide regular information for our members on topical technical, commercial and legal issues.

In this context VDW is interested in increasing the innovation and competitive capacity of machine tool builders and manufacturers of machine tool controllers by introducing a unified machine tool interface. This universal interface is understood as essential prerequisite towards digital manufacturing.

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

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-8, OPC Unified Architecture - Part 8: Data Access

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

OPC 10000-9, OPC Unified Architecture - Part 9: Alarms and Conditions

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

OPC 10000-20, OPC Unified Architecture - Part 20: File Transfer

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

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

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

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

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

OPC 10031-4, OPC UA for ISA-95 - Part 4: Job Control

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

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

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

OPC 40001-3, OPC UA for Machinery - Part 3: Job Management

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

3 Terms, abbreviated terms and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling are understood in this document. This document will use these concepts to describe the Machine Tools 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-9, OPC 10000-20 OPC 10000-100, OPC 10000-200, OPC 10031-4, OPC 40001-1, OPC 40001-3 as well as the following apply.

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

3.2 OPC UA for Machine Tools terms

3.2.1 Alert

3.2.2 Channel

3.2.3 Controller

3.2.4 Machine Tool

3.2.5 Manual Tool Change

3.2.6 Multitool

3.2.7 Part

3.2.8 Production Plan

list of all job elements a specific machine knows about
EXAMPLE: All jobs which were transferred to the machine in some way.

3.2.9 Untitled

3.2.10 Untitled

3.2.11 Program

also: production program; list of operations that the controller performs in sequence;
usually a machine-readable file, such as an NC program, which is needed for the controller to fulfil the job; NC programs may also carry a hierarchy of further sub-(NC)programs

3.2.12 Replacement Tool

tool with equivalent (identical) process capabilities (size and functionality) to an existing tool; used by the controller if the designated tool is locked due to wear, done automatically and/or after user interaction

3.2.13 Stacklight

3.2.14 Tool

3.2.15 Utility

3.3 Abbreviated terms

3.4 Conventions used in this document

3.4.1 Conventions for Node descriptions

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 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 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.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 Annex A.

If the BrowseName is not defined by this document, a namespace index prefix like ‘0:EngineeringUnits’ or ‘2:DeviceRevision’ is added to the BrowseName. This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 136 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 document or if it is server-specific.

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

3.4.3.2 Objects

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

3.4.3.3 Variables

For all Variables specified in this document, the Attributes named in Table 6 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 document, the Attributes named in Table 7 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 document, 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.

4 General Information to Machine Tools and OPC UA

4.1 Introduction to Machine Tools

According to ISO standards, a “machine tool is a mechanical device, which is fixed and powered, typically used to process workpieces by selective removal/addition of material or mechanical deformation (…). Machine tools operation can be mechanical, controlled by humans or by computers (…)”. There is a great variety of metalworking machine tools: milling machines, lathes, sheet metal forming machines, EDM machines and additive manufacturing machines are just some examples. Stainless steel, aluminium, titanium and copper are some of the main metals processed by these machine tools. In addition, to manufacture components for key industries like automotive, aerospace, energy and medical technology, machine tools enable the production of all the other machines, including themselves. This is why we call them the mother machines.

For the scope of the standard, mainly machine tools for machining metal and other hard materials were considered. Most of these machine tools are equipped with a CNC Control and a PLC. In order to represent these machine tools with a common OPC UA interface, several use cases were considered.

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 the MachineTool model, 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 subtype 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 summarised 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.

The OPC UA specification defines a very wide range of functionality in its basic information model. It is not expected 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. Namespaces in OPC UA have a globally unique string called a NamespaceUri and a locally unique integer called a NamespaceIndex. The NamespaceIndex is only unique within the context of a Session between an OPC UA Client and an OPC UA Server. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of values in OPC UA that are qualified with Namespaces: NodeIds and QualifiedNames. NodeIds are globally unique identifiers for Nodes. This means the same Node with the same NodeId can appear in many Servers. This, in turn, means Clients can have built in knowledge of some 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 Machine Tools specification. For the use cases described in sections 5.2 to 5.9, a maximum sampling rate of 1 Hz is considered to be sufficient.

5.1 Identify Machines of Different Manufacturers

The machines of different manufacturers shall be identifiable in a standardised manner. To realize this, a number of basic and static information like manufacturer name and serial number are offered on the Machine Tools interface. This information can be found on the interface in an instance of the MachineToolIdentificationType.

5.2 Overview if Production is Running

Using information provided by the Machine Tools interface, an overview if the machine tool is in production or not should be possible. Additionally, if the machine tool is in an erroneous state, it needs to be evident over the interface.

If the machine tool is not in production, the reason for this state should also be identifiable.

The information of the machine tool and controller state can be found in the information model in the Monitoring Component (defined by the MonitoringType) of the MachineToolType. Other nodes that provide important information for an overview if the production is running are the override values of NC channels and working units in the ChannelMonitoringType and the WorkingUnitMonitoringType.

Another indication of the machine tool status is the machine stacklight. Its representation in the Machine Tools information model can be found in the StacklightType.

The errors and warnings on the machine tool shall be available on the Machine Tools interface with the OPC UA mechanism described in OPC UA Part 9 – Alarms and Conditions.

5.3 Overview of Parts in a Job

Using the Machine Tools interface, an overview of the target and actual manufactured parts is possible. The relevant information can be found in the information model in the MaterialActuals field of the ISA95JobResponseDataType as defined by OPC 10031-4 and OPC 40001-3.

5.4 Overview of Runtimes for a Job

In order to calculate cycle times and prognoses for production, the Machine Tools interface provides the time data of start and end of job orders on the machine tool.

The events can be found in the information model as InterruptionConditionType with its ConditionClassId and ConditionClassName (that specify the reason for the interruption further), and the StartTime and EndTime fields of the ISA95JobResponseDataType as defined by OPC 10031-4 and the ActualProductionTime as defined by OPC 40001-3.

To receive the events for a specific program, job order or controller, the OPC UA client can subscribe to the ISA95JobOrderStatusEventType generated by the ISA95JobResponseProviderObjectType.

5.5 Overview of Machine Tool State

With the interface, information on the machine tool state is available, e.g., in the MachineOperationMonitoringType. The MachineOperationMonitoring type also contains the MachineryItemState and MachineryOperation mode from OPC 40001-1.The states of NC channels and controllers in the machine tool are available as well.

In the information model, the status of the production is shown for each job order in the JobOrderList.

The control mode of the channel is represented in the ChannelMode of the ChannelMonitoringType.

5.6 Overview of Upcoming Manual Activities

For a machine operator who works on multiple machine tools in his shift, an indication which of the machine tools has the soonest need of a manual intervention is helpful (e.g., tool change, part change, preparation for the next job…).

To achieve this, the Machine Tools interface offers the possibility to give prognoses for different events. These prognoses can of course only be provided if the machine tool can estimate the time of the respective future event.

The available types of prognoses are: MaintenancePrognosisType, ManualActivityPrognosisType, PartUnloadPrognosisType, ProcessChangeoverPrognosisType, ProductionJobEndPrognosisType, PartLoadPrognosisType, ToolLoadPrognosisType, ToolUnloadPrognosisType, ToolChangePrognosisType and UtilityChangePrognosisType.

On the Machine Tools interface, there is a list of available prognoses, which is of PrognosisListType. It contains all known prognoses with their times to happen.

5.7 Overview of Errors and Warnings

The machine tool is expected to offer all current errors and warnings over the Machine Tools interface.

These errors and warnings shall be mapped to OPC UA event types accordingly. For errors, the Machine Tools information model offers the AlertType. For messages with lower urgency, there is the NotificationEventType.

5.8 Providing Data for KPI Calculations

To facilitate the calculation of different KPIs like for example OEE, the Machine Tools interface offers different machine times. These times allow to calculate the durations of different machine modes. To calculate the KPI, additional data not provided by the interface may be necessary.

Some of these relevant times are transferred via the event mechanism in OPC UA.

For detailed information about KPI calculation and possible values of the information model to use, please refer to Annex C.

5.9 Providing an Overview of Tool Data

On the Machine Tools interface, data concerning the tools in the machine tool is available.

In the Machine Tools interface, tools are modelled with the MultiToolType and ToolType and aggregated in a list with the ToolListType.

In the Machine Tools information model, the tool data are constrained to very basic information. Especially all geometric information about the tool is omitted on the interface. This is mainly due to the multitude of different norms for different tools.

On the interface, there are the identifiers of the tools in the machine tool. With these, it can be verified if a machine tool is prepared to execute a certain machining task.

There is also some information about the tool life condition of the tool. The interface will show at which tool life value a warning to change the tool is issued and the tool life limit value at which the tool is intended to be changed.

If there are multiple tools of the same type equipped in the machine tool, the one that will primarily be used in the machining process is marked as planned for operating. Using this information, the tool distribution among different machines can be planned remotely and changed without disturbing the current machine operation.

5.10 Provide OPC UA for Machinery Use Cases

The Machine Tools interface makes use of OPC 40001-1. As such, it is providing the use cases “Machine Identification and Nameplate”, “Finding all Machines in a Server”, “Finding all Components of a Machine” and “Machine Monitoring”. It also provides the MachineryBuildingBlocks folder, directly referencing all Machinery Building blocks used by the Machine Tools interface instance.

In addition, the Machine Tools interface incorporates OPC 40001-3. This specification provides the use cases “provide job orders”, “control job orders”, “get information about the state of execution and intermediate as well as end results” and “delete job orders”.

6 Machine Tools Information Model Overview

This section introduces the “OPC UA Information Model for Machine Tools”.

This Information Model provides the necessary ObjectTypes to model a machine tool interface in a structure as illustrated in Figure 6. There are ObjectTypes that are used to identify the machine tool (MachineToolIdentificationType), to monitor the machine tool (Monitoring Type), to manage the production (Production Type) on the machine tool, to handle the Equipment of the machine tool (EquipmentType) and to give notification on the status of the machine tool (NotificationType).

The ObjectType hierarchy of this Companion Specification is shown within the Figures 7-12. Objects from external specifications are positioned within greyish-green boxes.

Figure 7 shows the inheritance relations of the MachineToolType.

Figure 8 shows the inheritance hierarchy of all ObjectTypes used in the MachineToolType’s Identification component. This relates to the document structure in 8.3.

Figure 9 shows the inheritance hierarchy of all types used in the MachineToolType’s Monitoring component. This conforms to the structure of the section Monitoring.

[DEPRECATED in version 1.02] Figure 10 shows the inheritance hierarchy of all types used in the MachineToolType’s Production component. This conforms to the structure of the section Production.

Figure 11 shows the inheritance hierarchy of all types used in the MachineToolType’s Equipment component. This conforms to the structure of the section Equipment.

Figure 12 shows the inheritance hierarchy of all types used in the MachineToolType’s Notification component. This conforms to the structure of the section Notification.

7 General Recommendations for Implementation

7.1 Localization

If the text part of a value of DataType LocalizedText, like the Manufacturer or the Model of a machine tool, is language neutral, i.e., it is the same in all languages, the locale of the LocalizedText shall be null or an empty string.

For all LocalizedText that have a language, the English version may be provided if possible.

7.2 Extending the Specification

If a type in this specification lacks information for a specific scenario, it is possible to extend the type. This is done in a specific namespace to indicate that it is outside the scope of this specification. To extend a type, a subtype containing the additional information is created. Instances of this subtype can be used interchangeably with instances of its parent type in the overall Machine Tools node structure. As the subtyped object needs to contain all information the parent type requires, all clients using this specification can handle the information of the supertype in the subtype. Clients that don’t know the subtype might not use its additional information though.

7.3 GeneralModelChangeEvent and NodeVersion

This specification provides the possibility to indicate changes in the AddressSpace to a client. Most often this concept is used in list representations, to add or delete Nodes from the list. OPC 10000-3 defines the property NodeVersion and the GeneralModelChangeEventType to indicate such changes. Whenever the address space in this specification is changing, the NodeVersion and the GeneralModelChangeEvent shall be used in the way defined in OPC 10000-3.

As content for the NodeVersion Property, a timestamp of the moment the node structure was changed converted to a string with the format yyyy-MM-ddTHH:mm:ss.sZ (using UTC time for display) shall be used.

8 OPC UA ObjectTypes

8.1 MachineToolType

The MachineToolType represents the entire machine tool interface of the information model. It is the entry point to the OPC UA interface of a machine tool. It gives a basic structure to the interface. An instance of this type aggregates all information related to one machine tool.

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

The MachineToolType is formally defined in Table 9.

Equipment (see 8.5 ), 2:Identification (see 8.2), Monitoring (see 8.3), Notification (see 8.6) and Production (see 8.4) are instances of the respective types. They are used to structure the information in the MachineToolType topically. 3:Components and 3:MachineryBuildingBlocks are used as described in OPC 40001-1. To differentiate between 3:Components and Equipment, 3:Components should contain elements that are an inseparable part of the machine and Equipment should contain removable elements (e.g., tools).

The components of the MachineToolType have additional subcomponentns which are defined in Table 10.

The 0:FileSystem is the root of all file directories of the OPC UA server and the underlying machine.

Note: While a direct coupling is not essential, aligning the file paths in both OPC UA 0:FileSystem and actual file systems is recommended (e.g. "/Directory1/FileA" in Unix and "ns=1;i=1001 Directory1/FileA" in OPC UA BrowsePath). Harmonizing OPC UA 0:FileSystem with actual file systems is advised for a more intuitive and efficient work environment.

The components of the MachineToolType have additional references which are defined in Table 11. The Production component will be replaced by the 6:JobManagement AddIn of the 3:MachineryBuildingBlocks in future versions of this specification. Hence, Table 11 defines its 0:IsDeprecated Reference.

8.2 Identification

8.2.1 MachineToolIdentificationType

The MachineToolIdentificationType of the Machine Tools information model holds static data which shall uniquely identify a machine tool among a pool of the machine tool operating entity. It is a subtype of the 3:MachineIdentificationType defined in OPC 40001-1, so it inherits all InstanceDeclarations specified there.

The MachineToolIdentificationType is formally defined in Table 12.

SoftwareIdentification contains a list of instances of the SoftwareIdentificationType (see Table 14). This list contains the machine tool’s software identification information. It allows to add multiple software items, e.g., one for each of PLC, NC and HMI.

2:SoftwareRevision inherited from the 3:MachineIdentificationType shall contain an overall software patch level of the machine tool. Individual software revision numbers may be given using SoftwareIdentification.

For the 2:DeviceClass inherited from the 3:MachineIdentificationType, the values in Table 13 should be used but might be extended by specifications using OPC 40501-1. The most appropriate value, based on the main machine tool technology shall be chosen.

Additive manufacturing machines are not defined in the source mentioned. They include every additive technology currently available.

All other properties of the MachineToolIdentificationType are defined in OPC 40001-1 and are intended to be used as indicated there.

8.2.2 SoftwareIdentificationType

The SoftwareIdentificationType holds information about the specific software in operation in the machine tool. Almost all modern machine tools operate on several software system components, this shall enable presentation of software components (NC Kernel, HMI base system, etc.). Figure 13 shows an example instance of the application of this type within the 2:Identification component of the MachineToolType.

The SoftwareIdentificationType is formally defined in Table 15.

In most cases, machine tools consist of several software components. A software component can be an individual application, or plugin of an application involved in controlling the machine tool.

2:SoftwareRevision provides a string representation of the version or revision level of the software component, the software/firmware of a hardware component. Examples are: “PLL01 1.10.0.3”, “V05.01.01.15”, “3.1 R1293”, “70.0.1”.

The Identifier Property provides an identifier to distinguish the software component.

2:Manufacturer refers to the manufacturer/producer of the software.

8.3 Monitoring

8.3.1 MonitoringType

The MonitoringType is used to structure information given in the MachineToolType. It contains the monitoring information of the machine tool and its subsystems.

The MonitoringType is formally defined in Table 16.

<MonitoredElement> is an optional Placeholder for ElementMonitoringType instances. This allows for any number of such instances as a component of the MonitoringType. For the DisplayName, it is recommended to use the value of the Name Property of the respective ElementMonitoringType instance.

MachineTool provides overall monitoring information of the machine tool.

Stacklight contains the information about a stacklight’s composition and status. It is an object of 4:BasicStacklightType, defined in OPC 10000-200. If the machine tool has a stacklight available, the Stacklight shall be present.

The optional 4:StackLevelType and 4:StackRunningType of the 4:BasicStacklightType shall not be used, only a segmented light shall be shown. Thus, the 4:StacklightMode of each stacklight has to be “Segmented” (0).

As 4:<StackElement>, only elements of 4:StackElementLightType shall be used. For these, the 4:SignalOn, 4:SignalColor and 4:SignalMode shall be used, not the 4:ControlChannelType (see Table 17).

8.3.2 ElementMonitoringType

The ElementMonitoringType is intended to be a supertype for all monitoring information that is specific to a particular element within the machine tool. An element doesn’t have to be a physical component. Examples for such elements are NC channels or spindles. It is an abstract type, meaning it is not instantiated, only the subtypes are.

The ElementMonitoringType is formally defined in Table 18.

The Name property refers to a name of the element.

8.3.3 WorkingUnitMonitoringType

The WorkingUnitMonitoringType is a supertype used to group monitoring information of machine tool elements that are a direct and active part of the machining process. It is an abstract type, meaning it is not instantiated, only the subtypes are.

The WorkingUnitMonitoringType is formally defined in Table 19.

The WorkingUnitMonitoringType has no other explicitly defined References.

8.3.4 LaserMonitoringType

The LaserMonitoringType provides basic monitoring information of a laser device used in the machining process, e.g., a beam source for a laser beam used as a tool.

The LaserMonitoringType is formally defined in Table 20.

ControllerIsOn being True indicates that the controller of the laser device is running. This gives no indication whether laser light is currently emitted.

LaserState indicates the current state of a laser device. It is defined in 12.4.

8.3.5 EDMGeneratorMonitoringType

The EDMGeneratorMonitoringType is a collection of information about the EDM spark generator

The EDMGeneratorMonitoringType is formally defined in Table 21

IsOn being True indicates that the EDM spark generator has a valid set of technology parameters, meets all safety conditions required and is switched on.

EDMGeneratorState indicates the current state of the EDM spark generator. It is defined in 12.3.

8.3.6 SpindleMonitoringType

The SpindleMonitoringType is a collection of information about the rotary process axis.

Depending on the actual context of the machine tool, this may for example be a tool-holding milling spindle or a workpiece-holding turning spindle.

The SpindleMonitoringType is formally defined in Table 22.

IsRotating being True indicates if the spindle is rotating and has a valid commanded rotation speed.

Override is representing the current value of the spindle override.

IsUsedAsAxis being True indicates if the monitored element is used as an axis or, if False, as a spindle. If IsUsedAsAxis is True, the values of IsRotating and Override shall not be used by a client.

8.3.7 ChannelMonitoringType

The ChannelMonitoringType provides the monitoring information about one NC channel.

The ChannelMonitoringType is formally defined in Table 23.

ChannelState is representing the current status of the NC channel and is defined in 12.1.

ChannelMode is representing the current mode the NC channel operates in. It is defined in 12.2.

FeedOverride is representing the current value of the feed override of the NC channel.

RapidOverride is representing the current value of the rapid override of the NC channel.

ChannelModifiers is representing additional program modifiers usually used during special operations of the machine tool, e.g., preparation of production (see 8.3.10).

8.3.8 CombinedChannelMonitoringType

The CombinedChannelMonitoringType is a subtype of the ChannelMonitoringType and inherits all its InstanceDeclarations. Using this type instead of a ChannelMonitoringType provides an aggregated representation of the channels in a machine tool. The rules for aggregation are given in Table 24. Sometimes it is not necessary to provide one representation per individual channel, e.g., if one channel is of primary interest, the status of the remaining channels is irrelevant for the machine tool status. It could be used together with the separate channels. Typical applications are multi-spindle machines in which a large number of channels are used for interlinked work steps.

The CombinedChannelMonitoringType is formally defined in Table 25.

The CombinedChannelMonitoringType contains no further References than the ones inherited.

8.3.9 MachineOperationMonitoringType

The MachineOperationMonitoringType provides overall monitoring information of the machine tool.

The MachineOperationMonitoringType is formally defined in Table 26.

FeedOverride is the combined actual feed override value that is effective for the manufacturing program of the machine tool.

IsWarmUp being True indicates if the machine tool is performing a warmup task. A warmup is not used for production, it is the mode used to reach a stable operating point for the machine tool. An example is reaching the optimal operating temperature. This might be indicated by a hardware switch on the machine tool, a special control command, a special production program (referenced by program name) or otherwise. In combination with the 3:MachineryItemState and the 3:MachineryOperationMode, the following behaviour is expected: If IsWarmUp is True, the 3:MachineryItemState is in state 3:Executing and the 3:MachineryOperationMode is in state 3:Setup.

3:MachineryItemState is used as defined in OPC 40001-1. Shall also be referenced as AddIn in the 3:MachineryBuildingBlocks folder.

3:MachineryOperationMode is used as defined in OPC 40001-1. Shall also be referenced as AddIn in the 3:MachineryBuildingBlocks folder.

MaintenanceMode, as a SubStateMachine of the 3:MachineryOperationMode (see Table 29), is only valid if the 0:CurrentState of 3:MachineryOperationMode is 3:Maintenance.

Obligation indicates the instance responsible for the current activities of the machine.

OperationMode contains a MachineOperationMode value as defined in 12.5. The values of the MachineOperationMode enum are derived from the MO modes of machinery functional safety standards. For a machine adhering to such a standard, the OperationMode shall show the respective mode. For a machine not adhering to such a standard, the OperationMode shall be filled with the appropriate mode available from the MachineOperationMode Enum. The OperationMode is only a representation of the machine mode, it shall not be used in a safety relevant manner.

[DEPRECATED in version 1.02] PowerOnDuration is the duration the machine has been powered, meaning all systems have line voltage. It is counted in full hours. This value only increases during the lifetime of the machine and is not reset when the machine is power cycled.

2:OperationCounters with 3:MachineryOperationCounterType is used as defined in OPC 40001-1. Shall also be referenced as AddIn in the 3:MachineryBuildingBlocks folder. It shall contain the 2:PowerOnDuration defined in OPC 40001-1.

2:OperationCounters optionally contains the counter PartsProducedInLifetime, which is the counter for the total number of produced parts during the machine’s lifetime. The exact way this number is acquired may differ between different machines. No quality information of PartsProducedInLifetime can be given.

The PowerOnDuration component will be replaced by the 2:PowerOnDuration of the 2:OperationCounters in future versions of this specification. Hence, Table 28 defines its 0:IsDeprecated Reference.

8.3.10 MachineOperationModeStateMachineType

For this specification, the 3:MachineryOperationModeStateMachineType defined in OPC 40001-1 is extended by a sub state for 3:Maintenance. An overview is shown in Figure 14.

The state 3:Maintenance is overridden in the MachineOperationModeStateMachineType. The additional references are defined in Table 31. The remaining contents of the state machine are left unchanged, as defined in OPC 40001-1.

8.3.11 MaintenanceModeStateMachineType

The MaintenanceModeStateMachineType defines the different modes of maintenance being perfomed on a machine. It is used as a SubStateMachine. If the parent state is not active, the 0:CurrentState Variable of the MaintenanceModeStateMachineType shall have a status equal to Bad_StateNotActive.

The MaintenanceModeStateMachineType is formally defined in Table 32.

The MaintenanceModeStateMachineType does not define an initial state.

The Service state indicates that measures to maintain or increase availability and duration of life are implemented. For example, linear guides are replaced, the bearings are lubricated, or the working area is cleaned.

The Inspection state indicates that the status is evaluated. For example, the lubrication is checked, the expendable parts are examined for wear and tear or the functionality of a workpiece holder is checked.

The Repair state indicates that the functionality of the unit is restored. For example, errors are fixed, or components are replaced.

The Upgrade state indicates that the performance, functionality, etc. of the unit are improved. For example, software upgrades, retrofitting of more powerful modules or modules with a longer duration of life.

The Other state is used if none of the other states apply.

The InstanceDeclarations of the MaintenanceModeStateMachineType have additional Attribute values defined in Table 33.

8.3.12 ChannelModifierType

The ChannelModifierType allows to show which modifiers are used while the machine is performing pre-production tests and similar tasks.

The ChannelModifierType is formally defined in Table 34.

BlockSkip being True indicates that specially marked NC program blocks are skipped.

DryRun being True indicates that a test run using with a dedicated axis feed is being performed.

OptionalStop being True indicates that the execution will stop at special machine commands.

TestMode being True indicates a test mode which enables execution of a program without physical axis movement. The machining process may be simulated during program execution.

SingleStep being True indicates if the NC channel operates in single block/single step mode.

8.3.13 ObligationType

The ObligationType is used to indicate the entity responsible for the current activities of the machine. This value is needed for certain KPI standards.

The ObligationType is formally defined in Table 35.

EndUserObligated being True indicates that the machine‘s activity is the responsibility of the end user/operator.

MachineBuilderObligated being True indicates that the machine’s activity is the responsibility of the machine builder.

Typically, only one of EndUserObligated or MachineBuilderObligated is True, indicating the respective entity as responsible. Both being False indicates the obligation being unclear (e.g., unknown, third entity responsible). Both variables being True should not be used. It is foreseen that further obligation entities may be added in later versions; this way of representation allows for extension.

8.4 Production

8.4.1 ProductionType

[DEPRECATED in version 1.02] The ProductionType will be replaced by the job management defined in OPC 40001-3 in future versions of this specification. Hence the 0:IsDeprecated Reference was added.

As a minimal implementation please only instantiate the mandatory variables. Set NumberInList to the value 0, fill Name according to the mapping in Annex B.2 and implement State, as described below in the respective sections.

The ProductionType is used to structure information given in the MachineToolType. It groups the information about the production plan and the production statistics.

The ProductionType is formally defined in Table 36.

ProductionPlan is a list of all job elements currently running and planned for execution.

If there is no job on the machine, there may be no ProductionJob object in the list.

In case the ProductionPlan is used as a dynamic list (i.e., ProductionJobType nodes are being added and deleted), the precondition for deleting any node is that all values of variables represent the final state of the job and are sent to all clients in active subscriptions.

ActiveProgram contains the program that is currently running on the machine. If the machine control discriminates between main and subprograms, this program shall be the main program. It is used in parallel to the ProductionPlan, so it allows for an access of the running program without browsing the jobs in the ProductionPlan. The 0:NumberInList Property of the ActiveProgram shall match the one used in the ProductionPlan for the same program. If the ProductionPlan is not used, it shall be 0.

Statistics is the object that contains statistics information related to production.

8.4.2 ProductionJobListType

[DEPRECATED in version 1.02] The ProductionJobListType will be replaced by the job management defined in OPC 40001-3 in future versions of this specification. Hence the 0:IsDeprecated Reference was added.

The ProductionJobListType is a type used for structuring objects of ProductionJobType in an ordered list structure.

The ProductionJobListType is formally defined in Table 37.

0:<OrderedObject> is a placeholder for any number of ProductionJobType instances. To indicate the order of jobs on the machine, the 0:NumberInList parameter of the ProductionJobType is used. This index shall be 0 for the first list element and increase by one for each subsequent list element. If jobs are deleted from the list or inserted into the list, the 0:NumberInList has to be adjusted for all following ProductionJobType instances in the list, such that the 0:NumberInList elements always form a sequential series of numbers. For the DisplayName of the 0:<OrderedObject>, it is recommended to use the value of the Identifier Property of the respective ProductionJobType instance.

The 0:NodeVersion and the 0:GeneralModelChangeEventType inherited from the 0:OrderedListType are intended to be used in the way defined in OPC 10000-3 and 7.3.

8.4.3 ProductionJobType

[DEPRECATED in version 1.02] The ProductionJobType will be replaced by the job management defined in OPC 40001-3 in future versions of this specification. Hence the 0:IsDeprecated Reference was added.

The ProductionJobType provides aggregated production data for running a sequence to produce several parts after one preparation mounting.

Examples for such a mounting are putting four raw parts on a pallet for a machining centre, setting up the fitting diameter bars in a turning centre bar feeder or loading a metal sheet from which hundreds of parts can be cut or punched. This sequence shall represent several parts which will usually (but not always) be several identical products. A job may be executed several times.

The ProductionJobType is formally defined in Table 38.

The components of the ProductionJobType have additional references which are defined in Table 39.

The Identifier is the identifier of the job. This Identifier is used to reference the job in other places of the AddressSpace, e.g., in the ProductionPartTransitionEventType. For this reason, the Identifier shall be unique.

The CustomerOrderIdentifier is used to reference the customer order this job belongs to. This information often originates from an external system handling production organisation (e.g., MES).

The OrderIdentifier is used to reference a company internal order the job belongs to. This information often originates from an external system handling production organisation (e.g., MES).

PartsCompleted indicates how many parts have been completed in the current job including all runs. This counter does not give any indication about the part quality. If PartSets are used, this counter shall be in sync with the respective PartsCompletedPerRun counter.

PartSets contains a list of ProductionPartSetType nodes related to the job. It is a list of the part sets, which contain the parts produced in the current run of the job. For the DisplayName of the <PartSet>, it is recommended to use the value of the Name Property of the respective ProductionPartSetType instance.

PartsGood indicates how many good parts have been completed in the current job including all runs. A part is counted as long as there is no contradicting evidence. Note that such evidence may arise in subsequent processing steps (on different machines), even if a part was counted as good. In this case, the data on the OPC UA Server are not changed retrospectively. If individual Parts are modelled, this counter shall be identical to the number of PartType instances with PartQuality set to Good, CapabilityUnavailable or WillNotBeMeasured.

ProductionPrograms contains a list of ProductionProgramType nodes representing the programs used in the job. This list is made out of at least one instance of ProductionProgramType. The ordering of the programs is displayed using the 0:HasOrderedComponent Reference and the 0:NumberInList component of the ProductionProgramType instance applied from the 0:IOrderedObjectType. The underlying ordering is the call sequence of the programs. The program called first shall have the number 0 and appear first along the OrderedComponents. For the DisplayName of the 0:<OrderedObject>, it is recommended to use the value of the Name Property of the respective ProductionProgramType instance.

The ProductionPrograms may include one single ProductionProgramType instance. If it contains more than one ProductionProgramType instance, the call hierarchy of the programs is not shown in this list. Neither is the relation of programs and channels modelled in the ProductionProgramType. Which programs to include in the list can be chosen by the integrator of the information model (e.g., main program only, subprograms included, …). The list shall include programs relevant to the job and manufacturing of the job, macros and cycles for general purpose tasks are usually not included.

RunsCompleted is a counter that increases after each completed run of the job. This means, the run was not aborted and finished regularly. This counter does not give any indication about the part quality.

RunsPlanned indicates how many times a job should be executed. RunsPlanned has a Property called IsValid, which indicates if the planned number of job runs is known to the machine (True) or not (False). The number of planned job runs not being known occurs in continuous production, that is if the machine is started with the respective job and job runs are repeated endlessly. The production process only ends when the machine is stopped by an external measure (operator or system).

State is an instance representation of the ProductionJobStateMachineType. It indicates the current state the job is in and the transition used to get into this state.

0:NumberInList is used to enumerate ProductionJobType instances used as list elements. This index shall be 0 for the first list element and increase by one for each subsequent list element. If nodes are deleted from the list or inserted into the list, the 0:NumberInList has to be adjusted for all following nodes in the list, such that the 0:NumberInList elements always form a sequential series of numbers.

8.4.4 ProductionProgramType

[DEPRECATED in version 1.02] The ProductionProgramType will be replaced by the job management defined in OPC 40001-3 in future versions of this specification. Hence the 0:IsDeprecated Reference was added.

The ProductionProgramType is the representation of a program. A program is a list of operations that the controller performs in sequence. It's usually a machine-readable file which is needed for the controller to fulfil the job.

The ProductionProgramType is formally defined in Table 40.

The Name is used to distinguish and identify programs on a machine.

State is an instance representation of the ProductionProgramStateMachineType. It indicates the current state the part is in and the transition used to get into this state.

0:NumberInList is used to enumerate ProductionProgramType instances used as list elements. This index shall be 0 for the first list element and increase by one for each subsequent list element. If nodes are deleted from the list or inserted into the list, the 0:NumberInList has to be adjusted for all following nodes in the list, such that the 0:NumberInList elements always form a sequential series of numbers.

8.4.5 ProductionActiveProgramType

[DEPRECATED in version 1.02] The ProductionActiveProgramType will be replaced by the job management defined in OPC 40001-3 in future versions of this specification. Hence the 0:IsDeprecated Reference was added.

The ProductionActiveProgramType is used to represent programs that are currently running within the machine.

The ProductionActiveProgramType is formally defined in Table 41.

JobNodeId contains the 0:NodeId of the ProductionJobType instance this program is used in.

JobIdentifier holds the same content as the Identifier Property of the ProductionJobType instance this program is used in.

State is inherited from the ProductionProgramType and overridden to be mandatory.

8.4.6 ProductionPartSetType