OPC UA FX at the Field Level: Past the Gateway

Most engineers met OPC UA at the SCADA layer: a server on a panel PC, a historian pulling tags over a client session, maybe a gateway shipping data to a broker. That version of OPC UA stops at the controller. It never reached the wire between a PLC and the drive it commands, or between two controllers that have to hand off a batch in step. UAFX, the OPC Foundation's Field eXchange profile, is the attempt to push the same address space and security model down to that last hop. This is a working note on what it actually standardizes at the field level, what runs underneath it, and where it isn't ready yet.

Basics are assumed here. If you need the primer on sessions, namespaces, and the PubSub model, start with the core OPC UA parts and come back. What follows is about the field, where cycle budgets are measured in microseconds and a late frame is a tripped line, not a stale dashboard. The interesting question isn't whether OPC UA can describe a field device — it has always been able to model one. The question is whether two controllers from different vendors can exchange cyclic process data, in real time, with a shared clock and a shared security model, and no translator in between. That is the problem UAFX sets out to close.

What "field level" means in UAFX

The OPC Foundation launched its Field Level Communications initiative in November 2018 and published the first UAFX specification release on 8 November 2022, alongside a live demo of automation gear from twenty manufacturers exchanging data controller-to-controller at the SPS show in Nuremberg (OPC Foundation, 2022). That demo is the thing to keep in mind. The point was never a single vendor's stack talking to itself. It was a Siemens controller and a Rockwell controller and a Beckhoff controller agreeing on one connection model without a gateway translating in the middle.

UAFX abstracts every participant as an AutomationComponent. A component publishes a standard description of its assets, its automation functions, and a standard interface for Connections that other components can consume (OPC 10000-80, Part 80). A Connection is the field-level pipe: a configured, peer-to-peer data exchange with defined endpoints, direction, and timing. Both bidirectional and unidirectional traffic are allowed, and a connection can carry ordinary process data or safety data on the same model.

This first release builds those Connections on OPC UA PubSub rather than client/server. The 2022 multivendor demo ran the PubSub messages over UDP/IP across wired Ethernet, Ethernet TSN, and 5G wireless, which tells you the data plane is deliberately decoupled from the transport. Client/server connections at the field level are noted as future work. So when someone says "OPC UA at the field level" today, they mean PubSub Connections between AutomationComponents, not a session-based read of a tag.

That distinction has teeth for anyone used to the SCADA pattern. A client/server read is request-response and stateful; a publisher pushes a configured DataSet on a fixed interval whether anyone is listening or not, which is what a cyclic control loop needs. The AutomationComponent abstraction is doing real work too. It hides the vendor's internal runtime behind a standard surface, so a controller doesn't expose its proprietary tag database to a peer — it exposes Connections with typed endpoints. Whether the box underneath runs ladder, structured text, or a soft-PLC on an industrial PC is none of the peer's business. That encapsulation is the whole bet: standardize the interface between automation islands, leave the islands themselves alone.

The specification is split across five parts, and it's worth knowing which is which because the release status differs part to part:

• Part 80 (OPC 10000-80) — Overview and Concepts; the informative framing of the AutomationComponent and Connection model.
• Part 81 (OPC 10000-81) — Connecting Devices and Information Model; the normative base model, ConnectionManager, and ConnectionEndpoints.
• Part 82 (OPC 10000-82) — Networking; topology discovery, time synchronization, and the network services a Connection depends on.
• Part 83 (OPC 10000-83) — Offline Engineering; a standardized secure file structure, the Descriptor, for sharing application information between engineering tools before anything is online.
• Part 84 (OPC 10000-84) — Profiles; the conformance units a Controller has to satisfy to claim UAFX support (OPC 10000-80, §4).

Relationships the model names are controller-to-controller, controller-to-device, and device-to-compute. In practice the mature, demonstrated case is controller-to-controller. That ordering matters for planning, and I'll come back to it, because the gap between "controllers interoperate" and "every transmitter on the spur is a UAFX device" is where most of the field-level work still lives.

The wire underneath: TSN and Ethernet-APL

UAFX is a profile, not a physical layer. It rides on whatever Ethernet you give it, but the determinism it promises at the field level comes from two lower-layer technologies the profile leans on: Time-Sensitive Networking for the factory floor and Ethernet-APL for the process plant. Neither is an OPC invention. Both are IEEE and IEC work that UAFX adopts.

TSN is the set of IEEE 802.1 amendments that turn standard switched Ethernet into a network with guaranteed delivery. Three pieces do the heavy lifting. Time synchronization comes from IEEE 802.1AS, the generalized Precision Time Protocol, which distributes a common clock so every bridge and end station shares the same notion of "now." Bounded latency comes from IEEE 802.1Qbv, the time-aware shaper, which opens and closes gated queues on a schedule so a critical stream gets a reserved transmission window even when best-effort traffic is saturating the link. Reliability comes from IEEE 802.1CB, frame replication and elimination, which sends duplicate frames over disjoint paths and discards the copy that loses the race (Seol et al., TSN survey, 2023).

What does that buy a control engineer? That same survey groups industrial traffic into classes by achievable cycle time: legacy class A around one hundred milliseconds, fast Ethernet class B inside ten milliseconds, and deterministic class C under one millisecond. Motion and high-speed coordination live in class C, and the jitter budgets there are brutal — on the order of one hundred nanoseconds for machine tools. You don't hit those numbers with priority tagging and hope. You hit them with a scheduled network and a shared clock, which is exactly what 802.1AS and 802.1Qbv provide. UAFX Part 82 is where topology discovery and time synchronization get pulled into the information model so a UAFX station can describe and configure that network instead of someone hand-tuning switches.

Process plants have a different problem. A refinery doesn't need motion-control jitter; it needs Ethernet that survives a two-kilometre cable run into a Zone 0 area on two wires that also carry power. That's Ethernet-APL, built on the 10BASE-T1L physical layer standardized in IEEE 802.3cg-2019, approved at the end of 2019. APL delivers full-duplex Ethernet over a single twisted pair at long cable lengths, and it does it intrinsically safe under the 2-WISE specification, the two-wire intrinsically safe Ethernet model adopted as an IEC technical specification (ISA InTech, 2021; IEEE 802.3cg-2019). Set the rates and reaches against the fieldbus APL replaces and the jump is hard to overstate.

That roughly three-hundred-fold rate increase isn't the headline, though. The headline is that the field device now speaks IP. The data island disappears. A pressure transmitter on an APL spur and a controller on a TSN backbone are on the same network stack, which is the precondition for one address space reaching all the way down. UAFX is the profile that tries to make that one address space behave the same regardless of which of these wires it crosses.

Establishing a connection without a gateway

Here's the part that separates UAFX from "we put OPC UA on the PLC." A field-level connection between two vendors' controllers has to be engineered, brought online, and diagnosed, and all three steps have to work across tools that have never met. The specification handles this in stages.

Engineering happens offline first. Part 83 defines the Descriptor, a standardized, secure file structure that carries an AutomationComponent's connection-relevant information between engineering tools before any device is powered. So an integrator can lay out a connection in one vendor's tool, export a Descriptor, and import it into another's — the connection topology travels with the file, not with a person's notes. When the components come online, the ConnectionManager on each AutomationComponent establishes the actual peer-to-peer PubSub Connection, binding the configured ConnectionEndpoints to the underlying DataSet writers and readers that move the bytes.

Diagnostics deserve attention because they're where the spec matured most recently. The release candidate completed in March 2025 (RC V1.00.03) added diagnostic counters and error-status indicators to both the AutomationComponent and the ConnectionManager, a capabilities folder showing whether an implementation actually monitors its local and external endpoints for errors, and a LogObject on both for collecting standardized diagnostic information. The same revision pulled Link Layer Discovery Protocol modeling into the UAFX station using objects from OPC 10000-22 (OPC Foundation, FLC Corner, March 2025). If you've ever tried to debug a multi-vendor field bus where each device reports faults its own way, you understand why a standard counter and a standard log are not a footnote.

Commissioning is where this either earns trust or loses it. A field-level connection that drops once a shift and silently re-establishes is worse than one that fails loudly, because the loud failure gets fixed and the quiet one corrupts a batch record nobody questions. The diagnostic surface UAFX added is what lets a maintenance technician, not just the integrator who built the line, see that an endpoint missed frames or that a publishing interval is being missed. Standardized counters also make the data portable into condition monitoring: the same connection-health figures that help a technician on day one feed an asset-health model on day three hundred. And because the counters live in the OPC UA address space, the layer above the field can read them with the same client it already uses for everything else, which is the quiet payoff of having one model from the instrument to the historian.

Work continues. A candidate completed in March 2026 (RC V1.00.04) revised Part 81 and Part 84 with extensions to the ConnectionManager and ConnectionConfigurationSets, added Global Discovery Server address support, more flexible referencing from a ConnectionEndpoint to its DataSet readers and writers, and improved publishing-interval configuration (OPC Foundation, FLC Corner, March 2026). Read the version numbers honestly: this is a 1.00 series still moving through staged release candidates. The model is stable enough to build against, and far enough from frozen that an early deployment should expect revisions.

Security at the last hop

Pushing a protocol to the field level pushes the attack surface with it. A gateway used to be a chokepoint where you could inspect and segment; remove it and every controller is now a directly addressable OPC UA endpoint. So the security model can't be an afterthought, and this is the axis where UAFX's recent work is most visible.

UAFX inherits OPC UA's application-layer security — authentication, signing, and encryption on the Connection itself — rather than trusting the network. The current C2C engineering effort centers the operational mechanics of that: secure onboarding through a Global Discovery Server, certificate provisioning, trust establishment between components that have no prior relationship, and role-based access control. The OPC Foundation issued a call for participation in a controller-to-controller engineering-workflow demonstration built on exactly those steps, with a multivendor showing slated for SPS in Nuremberg in November 2026 (FLC Corner, March 2026). Certificate lifecycle management at field-device scale is the hard, unglamorous problem here. Issuing and rotating certificates for a handful of SCADA servers is one thing; doing it for every controller and, eventually, every instrument is another.

This is also where the OT security framework around the protocol matters. IEC 62443 governs the zones, conduits, and security levels you wrap around industrial systems, and a field-level OPC UA deployment has to sit inside that framework, not beside it. UAFX gives you authenticated, encrypted connections; it does not absolve you of segmentation, patch management, or the rest of a defensible architecture.

Functional safety is a separate, parallel track. OPC UA Safety, standardized as Part 15 and published as IEC 62541-15:2025, defines a safety communication layer that carries safety-relevant data over the same OPC UA transport, built to the IEC 61508 and IEC 61784-3 requirements and usable for applications up to SIL 4 (OPC 10000-15, Part 15). It works on the black-channel principle: the safety layer places no safety requirement on the underlying channel, detecting corruption, loss, and misordering itself through a monitoring number, a timeout, a set of identifiers, and a CRC. A UAFX Connection can carry that safety data alongside standard process data, which is what lets one network do what used to take a separate safety bus.

Where it pays, and where it doesn't yet

So where does this earn its keep? The honest answer is narrower than the marketing. The strong case today is greenfield or major-retrofit lines with multiple controller vendors that have to coordinate in real time — the controller-to-controller case the spec demonstrated first. If you're standing up a packaging line, a converting line, or a process skid where a Rockwell cell has to hand off to a Siemens cell, UAFX is the path to doing that without a translation gateway and the latency, licensing, and single-point-of-failure that come with one. A protocol-converter box isn't only a capital line item; it's a thing that needs firmware updates, a spare in the cabinet, and a person who understands both sides of the mapping when it breaks at two in the morning. Removing it removes that whole tail of cost and fragility. The interoperability is the product, and that's where we point operators evaluating it through our edge telemetry and analytics platform.

Where it doesn't pay yet:

• Pure brownfield with one vendor. If your line is all one OEM and already coordinates fine over that vendor's native field bus, UAFX adds engineering effort for interoperability you don't need. The gateway you'd remove isn't hurting you.
• Device-level instrumentation. The demonstrated maturity is controller-to-controller. Controller-to-device and full device-level UAFX — every transmitter and valve as an AutomationComponent — is further out. Don't plan a transmitter fleet around it today.
• Anything that needs a frozen standard. The spec is in a 1.00 release-candidate series still gaining diagnostic and configuration features. That's healthy for the technology and a real risk for a deployment that can't absorb a revision.
• Networks not built for determinism. UAFX rides on TSN and APL, but it doesn't install them. If your plant Ethernet is unmanaged switches and flat VLANs, the field-level guarantees aren't there no matter what profile you run on top.

Our practical sequence is unglamorous. Get the network right first: managed switches, a TSN-capable backbone where motion demands it, APL where you're reaching hazardous-area instruments, and a real time-synchronization domain. Pilot one controller-to-controller connection between two vendors on a non-critical line and exercise the failure modes — pull a cable, watch the diagnostic counters, force a certificate to expire. Then decide. UAFX is a credible answer to a thirty-year-old problem, multi-vendor interoperability at the field level, and it's close enough to use on the right project. It is not a drop-in upgrade for a working line, and treating it as one is how a good standard earns a bad reputation. Teams weighing that tradeoff are the conversations we have through our industrial deployment services.