The Field Level Communications (FLC) initiative of the OPC Foundation was launched to establish OPC UA as a uniform, consistent and vendor-independent industrial interoperability solution also at the field level.

To this end, extensions to the OPC UA framework are being specified that standardize the semantics and behavior of controllers and field devices from different manufacturers, both for discrete manufacturing and for the process industry.

Three and a half years after its launch, the initiative has completed the final release candidate of the first specification version, which is being named OPC UA Field eXchange (FX).

This first specification has the focus on cross-vendor controller-to-controller use cases that support flexible and reconfigurable processing and manufacturing operations. A multi-vendor demo was created to test the interaction of UAFX controller prototypes that exchange process data on the basis of OPC UA and the OPC UA FX extensions.

OPC UA and UAFX System Architecture.

Application example

To illustrate the application of OPC UA FX an example is given in the following: A machine operator buys two identical machine tools from manufacturer 1 and two identical robots from manufacturer 2 to automate the loading and unloading of the machine tools.

To control and synchronize the processes between the machine tool and the robot, the respective controllers must exchange defined process data with each other. Neither the machine tool nor the robot changes its function or operation after installation, but there is no pre-planning of which machine will be connected to which robot, and possibly the network identification of the different controllers is not defined in advance.

At the time of commissioning, each machine and robot (or more specifically, the controller in each machine or robot) must be assigned their network identification and the network identification of the respective communication partner. No other configuration should be needed on the part of the user to enable plug-and-produce operation with an exchange of real-time and safety data.

Schematic structure of the first OPC UA FX multi-vendor demo.

Technical Solution Approach of OPC UA FX

To enable the plug-and-produce concept described above, the OPC UA framework is extended by corresponding features, which are described in the following.

UAFX controllers must expose selected information via a prescribed OPC UA information model, the so-called Automation Component (AC), which contains both the functional model and the asset model. The scale of an AC is up to the vendor.

It could be as small as an individual standalone 8 point I/O controller or as large as a complex, room-sized machine. The asset model describes physical items, but can also include items that are not physical, such as firmware or licenses.

The function model describes a logical functionality. It consists of one or more Functional Entities (FE), each of which encapsulate input/output variables, communication and device parameters, as well as communication connections. A Functional Entity is abstracted from the hardware, which enables applications to be ported to new hardware. The Connection Manager (CM) is a service that is usually located in one of the controllers and is responsible for establishing or managing connections between FEs in different controllers.

Dashboard of the UAFX Multi-Vendor Demo (All Controllers View).

Dashboard of the UAFX Multi-Vendor Demo with the visualization of 2 production lines.

A UAFX connection is first established via client/server mechanisms, where information for establishing a bidirectional PubSub connection (including compatibility checks, parameterization) is exchanged. The PubSub connection is then prepared and put into operation.

Offline engineering is an important element for the development, operation and maintenance of an automation system. By allowing the user to be able to understand the operation of the automation system before deploying the system in physical hardware, the user will know that the system will perform the control function reliably and correctly once the physical system is in place.

To make this possible, so-called descriptors are used. The descriptor of an AC is a set of documents containing an OPC UA information model and possibly other useful information for configuration purposes. The information can be for a single AC or a group of ACs (like a machine, machine module or skid). The AC descriptor is delivered in a packaged container format containing both product and configuration information.

A product descriptor contains the product data of the controller and is usually provided by the controller vendor. The configuration descriptor contains information such as functional units, communication DataSets, required quality of service (QoS) and data necessary for one or more connections. The configuration descriptor is created in the engineering process, usually with the intention to share engineering information between two engineering tools.

Safety data can also be exchanged between controllers. For this, OPC UA Safety, a safety protocol that is transmitted via standard UAFX connections, is used. The advantage of this approach is that the evaluation and testing effort by a notified body (e.g. TÜV) is limited to the safe transmission protocol, whereas the underlying UAFX connections do not require any additional evaluation and testing.

Each UAFX connection can be authenticated and optionally encrypted by standard OPC UA security mechanisms specified for the Client/Server and PubSub communication. The connection establishment is entered after a OPC UA Secure Session establishment is completed using asymmetric cryptography with certificates and private keys.

Unification of horizontal and vertical communication via OPC UA (a) and UAFX (b), as well as migration to a continuous, convergent network (c) that full scales from the field to the cloud and vice versa.

First OPC UA FX Specification Version

The first OPC UA FX specification version consists of five specification parts:

• Part 80 (OPC 10000-80) provides an overview and introduces the basic concepts of using OPC UA for field level communications.
• Part 81 (OPC 10000-81) specifies the base information model and the communication concepts to meet the various use cases and requirements of Factory and Process Automation.
• Part 82 (OPC 10000-82) describes networking services, such as topology discovery and time synchronization.
• Part 83 (OPC 10000-83) describes the data structures for sharing information required for Offline Engineering using descriptors and descriptor packages.
• Part 84 (OPC 10000-84) describes the UAFX Profiles that are used to segregate OPC UA FX features with regard to testing of OPC UA products implementing OPC UA FX functionality.

OPC UA FX Specifications (Parts 80-84)

First OPC UA FX Multi-Vendor Demo

In November 2021, a first multi-vendor interoperability demo was realized, in which automation and network components were combined to illustrate cross-vendor data exchange via OPC UA and the OPC UA FX extensions. For this purpose, 17 controllers (including PLC, motion and robot controllers, as well as Distributed Control Systems) from different vendors – including the largest automation manufacturers in the world – were interconnected via a common network infrastructure.

This infrastructure consists of conventional Ethernet switches, Ethernet TSN (Time-Sensitive Networking) switches, and a 5G testbed using the millimeter-wave frequency range.

All controllers of the demonstrator provide current status and asset information via an integrated OPC UA server, which is queried and visualized via a central dashboard. The “All Controllers” view displays the status of OPC UA connections for all 17 controllers in the multi-vendor demo, as well as status information about the PubSub-based UAFX connections configured by each of the UAFX controller prototypes. The dashboard itself is interactive and, when clicking on one of the 17 controllers, switches to the “Asset View”, which displays the UAFX asset information modeled and exposed by the controllers.

In order to demonstrate the possibilities and advantages of the UAFX extensions, a modular bottling line was simulated in the demonstrator, in which 4 machine units for washing, filling, capping and labeling the bottles are combined to form a production line. For demonstrating cross-vendor interoperability, each of these units is equipped with a control system from a different manufacturer.

The configuration of the communication connections and the process data exchanged via these connections to implement a functioning production line is carried out via a UAFX Connection Manager, as already described above. In the demonstrator, a stand-alone (external) Connection Manager from Unified Automation, based on UA Expert, and a Connection Manager integrated into the SIMATIC PLC from Siemens, each with its own graphical user interface, are used. The Connection Managers act as OPC UA clients and use the OPC UA servers integrated in the UAFX controller prototypes to configure UAFX connections between the respective controllers.

The corresponding process data is then exchanged via these UAFX connections using OPC UA Pub/Sub. The controllers act as UAFX publishers and/or UAFX subscribers depending on their role & position in the configured production line. The process data can be real-time data or, for example, safety data for fail safe operations. The configured production lines can be visualized and monitored in the dashboard.

Members Of The OPCF FLC Steering Committee

Summary and Outlook

The first OPC UA FX specification defines extensions to the OPC UA framework that enable uniform networking between controllers via a common network infrastructure in order to exchange process data on the basis of a manufacturer-independent interface.
OPC UA is thus establishing itself as an industrial interoperability standard not only for the vertical integration from the control level to the edge or up to the cloud, but also as an interface for exchanging process data between controllers, regardless of which protocol these controllers use to communicate with the underlying field devices, e.g. servo drives, distributed I/Os, sensors.

In the next project phase that will be launched end of July 2022, the concepts developed for the “controller-to-controller” use case will be extended for “controller-to-device” (C2D) and “device-to-device” (D2D). This supports additional use cases, including further functions and device-specific models, e.g. for motion control, instrumentation and distributed I/Os. OPC UA will then provide a uniform communication standard that scales completely across all levels, from the field to the cloud, both vertically and horizontally.

Ethernet TSN (Time-Sensitive Networking) and the IEC/IEEE 60802 TSN IA (Industrial Automation) profile of IEC/IEEE 60802 are particularly important because it enables different protocols, regardless of whether they are IT or OT protocols, to coexist in a uniform and common network infrastructure.

This enables a step-by-step migration of conventional industrial Ethernet protocols to a uniform OPC UA-based communication solution and barriers due to incompatible protocols and profiles can be removed step by step. A decisive success factor here is that OPC UA is supported by all major automation suppliers in the world, so that users will be free to decide in the future which systems and components they use in their production plants and factories.

Peter Lutz, Director FLC, OPC Foundation