Figure 1: The OPC Foundation's Field Level Communications Initiative - extending OPC UA to the field level.

© OPC Foundation

The OPC Foundation's Field Level Communications (FLC) initiative was launched in November 2018 to establish OPC UA as a standardized, universal and manufacturer-independent industrial interoperability solution at field level(Fig. 1). In the first phase of the FLC initiative, the focus was on controller-to-controller communication, which supports flexible and reconfigurable processing and manufacturing processes and, among other things, enables the cyclical exchange of real-time and safety-critical process data. The chosen solution approach is generic, i.e. it covers the requirements of applications in discrete manufacturing and the process industry in equal measure. The specifications for extending OPC UA for the field level have been published under the name OPC UA FX (Field eXchange). The specified concepts form the basis for specification extensions that will also support the controller-to-device (C2D) and device-to-device (D2D) communication application scenarios in the future.

The OPC UA FX system architecture

Figure 2: The OPC UA and OPC UA FX system architecture.

© OPC Foundation

The solution approach for OPC UA FX is based on the OPC UA framework with its mechanisms for information modeling, the integrated security functions and the client/server and PubSub communication services, as shown in Figure 2 . UAFX controllers and, in the next step, UAFX field devices must expose selected information via a defined OPC UA information model, the Automation Component (AC), which contains both the function model and the asset model. The scope of an AC is at the discretion of the provider. It can be as small as a single, compact I/O module - or as large as a complex, room-sized machine. The asset model describes physical objects, but can also include non-physical objects such as firmware or licenses. The function model describes a logical functionality and defines a defined interface through the information model. It consists of one or more Functional Entities (FE), each of which encapsulates input/output variables, communication and device parameters, as well as communication connections. A functional entity is abstracted from the hardware so that applications can be ported to new hardware. The Connection Manager (CM) is a service that is usually located in one of the controllers. It is responsible for establishing and managing connections between FEs in different controllers. A UAFX connection is first established via client/server mechanisms, whereby information for establishing a bidirectional PubSub connection - including compatibility checks and parameterization - is exchanged. The PubSub connection is then prepared and put into operation, which means that cyclical process data can be transferred between controllers from this point onwards.

Safety-critical data can also be exchanged between controllers. For this purpose, OPC UA Safety uses a safety protocol that uses standard UAFX connections and is therefore independent of the underlying transport protocols 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, while the underlying UAFX connections and the underlying communication stacks do not require any additional evaluation and testing.

Each UAFX connection can be authenticated and optionally encrypted using the standard OPC UA security mechanisms specified for client/server and PubSub communication. The connection is established after completion of an OPC UA Secure Session Establishment using asymmetric cryptography with certificates and private keys.

Flexible transport architecture

Features of the UAFX Bridge Component Facets (o=optional, ✔=mandatory)

© OPC Foundation

A key element of the OPC UA FX solution approach is the flexible transport architecture that enables interoperability between automation components with cyclic communication, including application-specific mappings to underlying communication protocols (such as UDP/IP or Layer-2 Ethernet) and physical layers (such as Single-Pair Ethernet, Ethernet-APL or 5G) to meet different communication needs.

PubSub communication is required for all devices involved in the cyclic exchange of process data. Additional communication functions and capabilities build on each other, with compatible subsets of functions to support progressively more advanced capabilities, including deterministic communication via Ethernet Time-Sensitive Networking (TSN). All controllers and field devices are interoperable over Layer 3 networks (IP networks), which are typically used in a large plant with many skids, modules, machines and cells. For this purpose, all controllers and field devices use OPC UA PubSub using UDP UADP.

Managed bridges are VLAN (Virtual Local Area Network) and QoS (Quality of Service) capable. They also support topology detection services and implement standard IT management protocols. The implementation of management functions is mandatory in bridges (see UAFX Base Bridge Component Facet according to Table 1). This facilitates the development of network monitoring and management tools that can operate most UAFX controllers and devices in a single system view, regardless of whether they have implemented TSN functions or not.

Ethernet Time-Sensitive Networking (TSN)

The UAFX transport architecture

© OPC Foundation

TSN provides mechanisms to realize networks with guaranteed latency and no packet loss in case of overload, as required for some automation applications. It is designed for Layer 2 networks, which typically occur within a single skid, module, machine or cell. Connections using TSN provide the most application determinism, but operating over a Layer 3 switch or router requires enhancements such as the use of DetNet, which is currently being developed by the IETF.

To meet the different communication needs of automation applications, three optional UAFX Bridge Component Facets have been defined. TSN-capable integrated bridges are represented by the UAFX Advanced & Full Bridge Component Facets according to the table.

The UAFX Advanced Bridge Component Facet supports time synchronization and frame preemption as essential features, based on the UAFX Base Bridge Component Facet. The Full Bridge Component Facet is based on the UAFX Advanced Bridge Component Facet and supports in particular the extensions for "Scheduled Traffic" (EST) - also known as 802.1Qbv or Time Aware Shaper (TAS). The Field Level Communications Initiative has committed to supporting the IEC/IEEE 60802 TSN Profile for Industrial Automation as soon as it is published, probably by the end of 2024. It is expected that all Industrial Ethernet variants and IT devices operating in an industrial network with TSN will comply with this specification so that a network management tool can allocate the required network resources to each application. IEC/IEEE 60802 Configuration Domains require that all bridges - regardless of whether they are integrated in a controller, a field device or an infrastructure switch - are compliant with IEC/IEEE 60802. If a controller or field device supports TSN features and also includes a bridge, it must implement either the UAFX Advanced Bridge Component Facet or the UAFX Full Bridge Component Facet (according to the table), and this bridge must be IEC/IEEE 60802 compliant. The mechanisms for connecting multiple IEC/IEEE 60802 configuration domains in a single network and the extension of domains by network routers have yet to be standardized. Once a network is correctly configured and sufficient resources have been allocated, TSN prevents packet loss due to network congestion and also ensures limited latency in the delivery of packets or data to the destination.

OPC UA FX end devices are configured via OPC UA, online or offline, whereas network infrastructure devices are configured via common and established network management protocols. This means that OPC UA is not intended to replace established management protocols for the configuration of network devices. In principle, both centralized and decentralized configuration is supported. The relevant protocols for TSN configuration are defined in the TSN IA Profile IEC/IEEE 60802. The role of OPC UA and OPC UA UA FX in the context of network management is to provide relevant industrial application scenarios and corresponding configuration workflows for time-critical OPC UA and OPC UA FX applications.

An outlook

The author: Peter Lutz is Director FLC at the OPC Foundation.

© OPC Foundation

The first UAFX specification release defines extensions to the OPC UA framework that enable controller-to-controller communication via a common network infrastructure in order to exchange cyclical process data based on the manufacturer-independent OPC UA (IEC 62541) standard. OPC UA is thus establishing itself as an industrial interoperability standard not only for vertical integration from the control level to the edge and into the cloud, but also as a communication standard for the exchange of process data between controllers, regardless of which protocol these controllers use for communication with the connected field devices, e.g. servo drives, decentralized I/Os, sensors. In phase 2 of the Field Level Communications Initiative, which was launched in January 2024 and is designed to run for four years, the concepts developed for the controller-to-controller (C2C) use case will be expanded for the controller-to-device (C2D) and device-to-device (D2D) use cases. This includes device- and application-specific information models, for example for motion control, instrumentation and decentralized I/O peripherals. OPC UA then provides a uniform communication standard that scales completely across all levels, from the field to the cloud, both vertically and horizontally. A key success factor here is that OPC UA is supported by all the world's major automation providers, so that in future users will be free to decide which systems and components they use in their production plants and factories.