What is OPC UA FX?

OPC UA FX (Field eXchange) is the extension of OPC UA that enables vendor-neutral, deterministic and secure communication between controllers and between controllers and field devices, defined in the specification series OPC 10000-80 to 10000-84. Until recently OPC UA mainly connected the PLC to higher-level systems such as SCADA and MES; OPC UA FX pushes the standard down to the field level. It does so using OPC UA PubSub over UDP and, where hard timing matters, TSN. The specifications are developed within the OPC Foundation’s Field Level Communications initiative.


πŸ•°οΈ How did OPC UA FX come about?

The OPC Foundation launched the Field Level Communications (FLC) initiative in November 2018 at the SPS IPC Drives fair in Nuremberg. At launch its steering committee comprised more than twenty companies, including ABB, Beckhoff, Bosch Rexroth, B&R, Cisco, Hilscher, Huawei, Kuka, Mitsubishi Electric, Omron, Phoenix Contact, Rockwell Automation, Schneider Electric, Siemens, Wago and Yokogawa. The goal: a single open, unified and secure communication solution from sensor to cloud.

Year Milestone
2018 FLC initiative launched (November)
2021 Second release candidate (December): more than 320 experts from over 65 companies, demo with components from 20 manufacturers
2022 First UAFX specifications (November) for controller-to-controller (C2C)
2024 Certification programme for UAFX controllers (November)
2025 Version 1.00.03 of the specification series
2026 Release candidate 1.00.04 (March), Part 81 version 1.00.04 published (July), multi-vendor C2D demo planned for SPS (November)

The first release deliberately focused on controller-to-controller exchange. The extension to controller-to-device (C2D) and device-to-device (D2D), with profiles for motion, I/O and process instruments, is still at the release-candidate and prototyping stage as of early October 2026.


🧠 Which parts make up the OPC UA FX specification?

Part Title Content
OPC 10000-80 Overview and Concepts Terminology, use cases and architecture
OPC 10000-81 Connecting Devices and Information Model Information model, connections and the ConnectionManager
OPC 10000-82 Networking Network requirements, topology discovery and time synchronisation
OPC 10000-83 OfflineEngineering Descriptors for exchanging engineering data
OPC 10000-84 Profiles Profiles and conformance requirements, such as the UAFX Controller Profile

Everything that OPC UA PubSub and core OPC UA already cover (address space, services, message encoding) is reused. UAFX adds the models and conventions needed to connect devices from different brands without custom engineering.


πŸ”§ How does OPC UA FX work?

The architecture revolves around a handful of core concepts:

  • AutomationComponent β€” a unit representing one or more assets that performs automation functions, such as a controller, drive or I/O station. It also reports its own health status.
  • Asset β€” the physical or logical building blocks of an AutomationComponent, with identification and diagnostic information.
  • FunctionalEntity β€” the actual automation function, with standardised InputData, OutputData and configuration data. Companion specifications and vendors derive their own types from it.
  • Connection β€” a logical relationship between FunctionalEntities for exchanging data, either unidirectional or bidirectional.
  • ConnectionManager β€” the party that establishes and supervises connections. It can be embedded in a controller or run as a central application.

Data is carried by PubSub with UADP encoding over UDP/IP. That works over standard Ethernet, over TSN for guaranteed latency, and also over 5G, which has already been shown in demonstrations. For safety functions UAFX reuses OPC UA Safety (Part 15), so standard and safety data share the same network, in line with functional safety principles.

Offline and online engineering

UAFX distinguishes two ways of working. In online engineering a tool reads the real components and sets up connections. In offline engineering you design the system before the hardware exists, based on Descriptors: digitally signed AML containers holding AutomationML models, manuals, certificates and other files. During commissioning those plans are deployed to the real devices.


πŸ”„ How does OPC UA FX relate to TSN and Ethernet-APL?

OPC UA FX defines the protocol and information model; the physical network comes from other standards:

  • TSN β€” for deterministic behaviour on converged networks, UAFX follows the IEC/IEEE 60802 profile (the TSN profile for industrial automation). Following the IEC ballot in May 2025 and IEEE approval in March 2026, the profile was published at the end of June 2026 as IEC/IEEE 60802:2026.
  • Ethernet-APL β€” for the process industries, the OPC Foundation has been working with the FieldComm Group since 2022 on an instrumentation device profile based on UAFX that can also run over Ethernet-APL. APL itself is a variant of Single Pair Ethernet designed for hazardous areas.

🏭 How does OPC UA FX compare with PROFINET, EtherNet/IP and EtherCAT?

Feature OPC UA FX PROFINET IP EtherCAT
Governed by OPC Foundation PROFIBUS & PROFINET International ODVA EtherCAT Technology Group
Determinism Via TSN (IEC/IEEE 60802) RT and IRT, TSN in development CIP Sync/Motion, TSN in development Very high, on-the-fly frame processing
Vendor neutrality High, backed by nearly all major brands Strong Siemens ecosystem Strong Rockwell ecosystem Open, but of Beckhoff origin
Information model Built in (OPC UA semantics) Device profiles CIP objects Device profiles (CoE)
Security Certificates, signing, encryption Security classes emerging CIP Security Limited, relies on segmentation
Maturity Young; C2C certifiable, C2D in development Very mature, large installed base Very mature Very mature in motion

In the long run OPC UA FX competes with these fieldbuses, but in practice coexistence is the norm. Many vendors offer the established protocols and UAFX side by side, and TSN allows different protocols to share the same network.


πŸ” How secure is OPC UA FX?

UAFX inherits the security model of OPC UA and extends it for PubSub:

  • Application certificates β€” every controller and device has an X.509 certificate. A security administrator rolls out certificates, roles and users; see certificate management.
  • Security Key Service (SKS) β€” PubSub messages are signed and encrypted with group keys distributed by an SKS. A controller conforming to the UAFX Controller Profile must support the SKS push model.
  • Authenticated connections β€” the ConnectionManager establishes connections through secure OPC UA sessions.
  • Signed engineering data β€” Descriptors are digitally signed, so tampering with device descriptions is detectable.

Security in the protocol does not replace network measures. Network segmentation in line with IEC 62443 and zoning based on the Purdue model remain necessary. Manufacturers of UAFX products also fall under the Cyber Resilience Act.


🧭 What does OPC UA FX mean for system integrators?

A practical approach for an integrator or end user:

  1. Define the use case β€” C2C between PLCs from different vendors is usable today; for C2D, motion and I/O, products are still scarce.
  2. Check certification β€” ask for OPC UA FX certification via the Compliance Test Tool (UACTT), which has included more than 350 UAFX test scripts since November 2024.
  3. Design the network β€” choose TSN switches supporting IEC/IEEE 60802 if you need deterministic connections; otherwise standard Ethernet is enough.
  4. Set up PKI and SKS β€” decide who issues certificates, how they are renewed and where the SKS runs.
  5. Work with Descriptors β€” ask suppliers for signed Descriptors and include them in your engineering standard.
  6. Test with multiple vendors β€” build a test rig with at least two brands before deploying UAFX on a production line.

An example of early adoption is B&R’s (ABB) ACOPOS M4 servo drive, presented at SPS 2025 as one of the first drives developed natively around OPC UA FX. In motion control, UAFX is therefore still at an early stage of real-world use.


❓ Frequently asked questions

Is OPC UA FX a fieldbus?

OPC UA FX fulfils the same role as an industrial fieldbus, but it is not a new layer-2 Ethernet protocol. OPC UA FX uses standard UDP/IP and TSN and adds a standardised information model. That makes it an open layer on top of Ethernet rather than a closed fieldbus.

Will OPC UA FX replace PROFINET and EtherNet/IP?

In the short term OPC UA FX will not replace PROFINET and EtherNet/IP, both of which have an enormous installed base. OPC UA FX mainly offers a vendor-neutral alternative for communication between controllers from different manufacturers. On TSN networks the protocols can run side by side.

Is OPC UA FX already available in products?

OPC UA FX is available for controller-to-controller communication, and controllers have been certifiable since November 2024. For controller-to-device, the OPC Foundation is still working on the specification and prototypes in 2026. The first drives with native OPC UA FX, such as the B&R ACOPOS M4, have been announced.

Does OPC UA FX always require TSN?

OPC UA FX also works over standard Ethernet and has even been demonstrated over 5G. TSN is only needed when you want guaranteed latency on a network that also carries other traffic. For that, UAFX follows the IEC/IEEE 60802 TSN profile.

How is OPC UA FX secured?

OPC UA FX uses X.509 application certificates, secure sessions for setting up connections, and signed and encrypted PubSub messages. A Security Key Service distributes the keys for PubSub. Network segmentation in line with IEC 62443 is still required on top of that.

What is the difference between OPC UA PubSub and OPC UA FX?

OPC UA PubSub (Part 14) describes how messages are published and received. OPC UA FX builds on it with an information model, a ConnectionManager, offline engineering and profiles, so that devices from different vendors are genuinely interoperable. PubSub is the transport; UAFX is the agreement on what is exchanged.


πŸ“Œ In summary

OPC UA FX takes OPC UA to the field level with vendor-neutral, secure communication between controllers and devices that becomes deterministic over TSN. Controller-to-controller is specified and certifiable; controller-to-device is on its way. For integrators, now is the time to experiment with PKI, TSN and Descriptors, while PROFINET, EtherNet/IP and EtherCAT remain everyday practice for the time being.