There is a great deal of work being undertaken by the OPC Foundation’s Field Level Communications (FLC) initiative.

Ethernet insights
- Integrating Ethernet down to the field level in industrial settings enhances interoperability and enables seamless real-time data exchange between controllers and field devices using the OPC UA framework.
- The OPC UA FX (Field eXchange) initiative supports various communication scenarios, including controller-to-controller, controller-to-device, and device-to-device, utilizing standardized protocols like UDP/IP and Ethernet-APL for reliable and efficient process data transmission.
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 the field level. In the first phase of the FLC initiative, the focus has been on controller-to-controller (C2C) 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 — it covers the requirements of applications in discrete manufacturing and the process industry in equal measure. The specifications for extending OPC UA to 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.
System architecture
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. UAFX controllers and, in the next step, UAFX field devices must disclose selected information via a defined OPC UA information model, the Automation Component (AC), which contains both the functional 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 functional model describes a logical functionality. 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 is exchanged. The PubSub connection is then prepared and put into operation – cyclical process data can be transferred between controllers from this point onwards.
Safety-critical data can also be exchanged between controllers and, for this purpose, OPC UA Safety uses a safety protocol over standard UAFX connections and is therefore independent of the underlying transport protocols used. The advantage of this is that the evaluation and testing effort by a notified body 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.
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 Raw Ethernet — and physical layers — such as single-pair ethernet (SPE) or ethernet advanced physical layer (Ethernet-APL) 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 across layer 3 networks (IP networks), which are typically deployed in a large plant with many skids, modules, machines and cells. For this purpose, all controllers and field devices support OPC UA PubSub using UDP UADP.
Managed bridges are VLAN (Virtual Local Area Network) and QoS (Quality of Service) aware. They also offer support for topology detection services and implement IT-standard management protocols. The implementation of management features is mandatory in bridges. This allows network monitoring and management tools to be developed that are able to operate most UAFX controllers and devices within a single system view, regardless of whether or not they have implemented TSN functions. However, OPC UA FX may be deployed also on devices with embedded unmanaged bridges.
Time-sensitive networking
TSN provides mechanisms to create networks with zero congestion packet loss and bounded network latency which are required by some automation applications. It is designed for layer 2 networks typically seen within a single skid, module, machine or cell. Connections using TSN deliver the greatest application determinism while operation through a layer 3 switch or router will require enhancements which are currently being developed.
To meet the different communication needs of automation applications, three optional UAFX Bridge Component Facets have been defined.
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 FLC Initiative has committed to supporting the IEC/IEEE 60802 TSN Profile for Industrial Automation as soon as it is published — hopefully 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 and this bridge must be IEC/IEEE 60802 compliant. Once a network is correctly configured and sufficient resources have been allocated, TSN ensures both zero packet loss due to network congestion and 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.
Outlook
The first UAFX specification release defines extensions to the OPC UA framework that enable controller-to-controller (C2C) 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 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. In Phase 2 of the FLC 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. 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.
– This originally appeared on Control Engineering Europe.