This articles outlines OPC-UA as a potential data collection method with MachineMetrics. It covers what tools and techniques are available to explore the key space on your OPC-UA server, how data is structured in OPC-UA, and how those data points can be referenced and transformed into a model that is consistent across all pieces of equipment monitored using MachineMetrics.
Topics covered in this article
- What is OPC-UA?
- Browsing the OPC-UA Server
What is OPC-UA?
OPC-UA ("Open Platform Communications Unified Architecture") is a common interoperability standard for the secure and reliable exchange of data 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. By itself, it does not describe the data that is made available by it in a consistent manner. Each data point that can be retrieved from an OPC-UA server (in this context, a machine), has a meaning that is specific to the implementation. Each make, family, model and even individual configuration of a machine can have a different set of data points that mean different things. While OPC-UA is in the process of being standardized for CNC machines and unified through specifications for various verticals like UMATI and the MTConnect/OPC-UA Companion Specification for manufacturing equipment, the adoption of these standards are just starting and won't be widely available for some time.
The OPC Foundation is responsible for the development and maintenance of this standard.
Browsing the OPC-UA Server
There are a number of client tools available to browse your OPC-UA server. We’ll suggest a few to choose from, which we will use to determine which node IDs we want to monitor.
Command line/terminal client
For a command line client, capable of printing out sections of the OPC-UA data tree, we recommend using the 'a command' line client called
uals, from the python-OPC-UA tools library (source code and installation documentation can be found here). Using the
uals tool, we can print the tree-like data of the opc-ua server in plaintext. The following command template would print a given namespace and depth from an OPC-UA server (without a username or password).
uals -u opc.tcp://<address>:<port> -i <namespace_id> -d <tree_depth>
If you are uncertain of the namespace you need to browse, that parameter can be omitted to include all namespaces on the server. There is no harm in this. The responses may simply contain extra, unnecessary data.
For a more involved interactive command line client, capable of viewing and browsing the data tree manually, we recommend using
opcua-commander, for which the source code and documentation can be found here. (This requires node.js be installed on your system).
The OPC Foundation recommends a few GUI clients, which can be found here and here.
Typically, GUI clients are more intuitive and straightforward in their setup than terminal clients for a majority of non-technical users. These clients should have sufficient documentation to allow you to connect and find the data items MachineMetrics will need to get your data reporting through our system.
Please Note: Both of these GUI clients are only supported on Windows 7 or higher (not linux or macOS). If you do not have access to a Windows machine, then the only option is to use one of the terminal clients listed above to discover the proper node ID’s
OPC-UA Data Structure
OPC-UA data is comprised of Simple and Complex types.
- Int32 (possibly other Int sizes as well, untested however)
- Object Types
- Enum Types
- Array Types (not currently supported)
Object types are effectively structs or hash tables of properties, enum types define a specific set of values, and array types are an ordered collection of items. Object types and array types can have properties and items that are complex types or simple types. Currently, only Object types with simple type properties are supported.
In the context of MachineMetrics’ OPC-UA implementation, the order of the complex types as they’re listed above is important which we’ll address later.
Referencing and Transforming OPC-UA Data in MachineMetrics
MachineMetrics uses a YAML document to reference OPC-UA tags, describe the structure of the complex types, and transform that data into a model that is consistent across all types of equipment. Here is a complete configuration for an OPC-UA device.
ACTIVE: laser-power > 0
tags section of the OPC-UA configuration defines references to specific nodes in the OPC-UA browse space. Tags should be formatted as follows below; the name of the tag will specify a MachineMetrics configuration label which can be referenced elsewhere in the configuration. The tags are defined by a
path property, which should point to a node ID of a variable in the OPC-UA tree (for more information on determining node ID’s, see the Browsing the OPC-UA Server section). An example of a single tag monitoring a value with a simple type of integer representing the power of the laser would look as follows:
Referencing Complex Types in Tags
Suppose there was a complex type found at the node
ns=2;s=Laser.CurrentPlan. We could reference properties on the
CurrentPlan node in our tags like so:
This would give us the
partQuantity property on the
CurrentPlan node. This assumes the node has a
partQuantity property. The value of this property can be referenced later in the data-items section via the
The final piece of the MachineMetrics YAML config is a
data-items section. This section is where values monitored from
tags are able to be modeled in a way that is consistent for all pieces of equipment in MachineMetrics. As seen below, basic transformation is possible in the
Here is an example defining the data items that will be sent to MachineMetrics. Values can either be passed through directly, transformed with boolean conditions and mathematical equations, and applied to switch-case-like syntax for specifying enumerations.
part_count is passing the integer value retrieved from the
cutting is passing through the string retrieved from the
PartCutState enumeration value found in the
execution is outputting
ACTIVE if the integer value of the
laser-power tag is greater than 0. If it is less than or equal to 0, the fall-through state that is output is
ACTIVE: laser-power > 0