OPC UA FX Controller-to-Device vs Controller-to-Controller: What C2D Adds in 2026

If you read the OPC UA Field eXchange specifications end to end today, you will find something surprising. OPC UA FX Controller-to-Device is a defined term in Part 80, it has a working group behind it, and it has passed multi-vendor interoperability testing. What it does not have, as of September 2026, is a published specification clause. The released 1.00 series specifies exactly one interaction model in normative detail — Controller-to-Controller — and every application profile in Part 84 is shaped like a controller. That gap is the whole story of C2D, and it explains why a technology that already works on a PlugFest bench is not yet something you can buy against a conformance certificate.

What this covers: the precise status of C2D as of 20 September 2026, the mechanical differences between C2C and C2D in roles, information model, connection establishment, profiles and TSN dependence, and how to sequence a field-level migration that does not strand hardware.

Context and Background

The OPC Foundation’s Field Level Communications (FLC) initiative exists to push OPC UA below the controller layer, into motion, safety, instrumentation and remote I/O. Its Steering Committee comprises 23 member companies funding both budget and technical staff, and the technical output is split across ten working groups — Architecture, Base Facet, Offline Engineering, Networking, Safety, Motion, Instrumentation, IO, Prototyping and Test Development. That roster is itself a roadmap: three of those groups exist purely to define device classes that the published specification does not yet cover.

The resulting standard, OPC UA FX, is a five-part series. Part 80 (OPC 10000-80) carries overview and concepts. Part 81 (OPC 10000-81) defines the UAFX information model and connection handling. Part 82 (OPC 10000-82) sets networking requirements. Part 83 (OPC 10000-83) specifies the data structures for OfflineEngineering. Part 84 (OPC 10000-84) specifies the OPC UA and networking profiles required for compliance. The online reference currently shows Parts 81 and 84 at v1.00.04 and Parts 80 and 82 at v1.00.03.

Part 80 clause 5.3 lays out five interaction categories: Controller-to-Controller, Controller-to-Device, Controller-to-Compute, Device-to-Device and Device-to-Compute. Its definition of C2D is deliberately terse — an “interaction model involving Controllers exchanging data with devices.” But clause 6, the concepts chapter, contains a single communication clause, 6.1, and it is titled Controller-to-Controller communication. Nothing in the published concepts chapter elaborates C2D.

That asymmetry is not an oversight. It reflects a staged publication strategy the Foundation has followed since the first UAFX release. For a fuller picture of how the initiative got here, see our analysis of OPC UA FX field-level communications in 2026 and the OPC UA FX field exchange reference architecture. The primary source for the specification text itself is the OPC Foundation online reference for Part 80.

What C2D Actually Adds Over C2C

Direct answer: Controller-to-Controller connects two peer automation components that each own their own application, negotiating a symmetric PubSub data exchange. Controller-to-Device adds an asymmetric relationship in which a controller configures, controls and owns a field device that has no independent application — and that requires device-class semantics, onboarding for constrained hardware, and profiles UAFX has not yet published.

Figure 1: C2C connects peer controllers through a ConnectionManager; C2D extends the same AutomationComponent abstraction down to drives, remote I/O and instruments.

Figure 1 shows why the two look deceptively similar on paper. Both endpoints are modelled as an AutomationComponent, the abstract type defined in Part 81. Both are connected by a ConnectionManager acting as an OPC UA Client. Both carry descriptors imported from an engineering tool. The topology diagram barely changes when you slide from C2C to C2D. The behaviour underneath changes a great deal.

Roles: peers versus an owner and an owned

In C2C, two controllers each run a complete control application. Each one decides what it publishes and what it subscribes to. Part 80 clause 6.1 is explicit that both bidirectional and unidirectional traffic can be used, and the relationship is one of negotiated interoperability between best-of-breed products from different vendors. Neither controller owns the other.

C2D inverts that. A servo drive, a remote I/O head or a Coriolis flowmeter does not run an independent automation application. It exposes process data, accepts configuration, and follows commands. The controller is the owner. Part 81 already contains the machinery for this — the ControlGroupType with its EstablishControl, ReleaseControl and ReassignControl methods lets one automation component claim exclusive write authority over a set of control items. What is missing is the standardised vocabulary of what those control items mean for a drive versus a valve positioner.

That vocabulary is exactly what the Motion, IO and Instrumentation working groups are chartered to produce. The FLC charter for the Motion group names its targets precisely: standard drives, frequency converters, positioning drives, servo drives and motion encoders. The Instrumentation group covers flowmeters, analyzers, transmitters, flame detectors, valves and valve controllers. The IO group covers modular and block I/O. Each group adds interfaces and behaviours to the UAFX base specifications for its device class.

Information model: the same types, far more instances

Part 81 models an AutomationComponent as two sub-models — an asset model and a functional model. The asset model describes hard assets such as devices, controllers and modules, plus soft assets such as firmware and licences. The functional model describes what the component actually does through FunctionalEntityType, which carries InputsFolderType, OutputsFolderType, ConfigurationDataFolderType and FunctionalEntityCapabilitiesType.

For C2C, a typical automation component is one chassis with a handful of functional entities. For C2D, the asset model has to describe the physical decomposition of a modular I/O station. Part 81 anticipated this: it defines AssetConnectorType with four concrete subtypes — SlotType, SocketType, ClampType and ClampBlockType — plus a HasPart reference type. Those are modular-I/O concepts. They exist in the published specification because the authors knew C2D was coming.

The practical consequence is instance count. A single 32-slot remote I/O rack with terminal-level granularity can present hundreds of asset nodes, each with identification data used for verification. Part 81 clause 5.2 requires identity and compatibility verification for both assets and functional entities before a connection is established. Multiply that by the device count of a real machine and you get an address space and a verification workload an order of magnitude larger than anything C2C produces.

Connection establishment: the same handshake, more participants

Part 81 clause 6.2.4 defines the EstablishConnections method on AutomationComponentType, and its behaviour is a strict command sequence. The commands, in the order the specification lists them, are VerifyAssetCmd, VerifyFunctionalEntityCmd, ReserveCommunicationIdsCmd, CreateConnectionEndpointCmd, EstablishControlCmd, SetConfigurationDataCmd, ReassignControlCmd, SetCommunicationConfigurationCmd and EnableCommunicationCmd, with an Abort path. Each command has a defined behaviour for both the PubSub and Client/Server mappings.

Above that sits the ConnectionManager, whose ProcessConnectionConfigurationSets method drives the whole thing through actions named ActionEstablishConnections, ActionEstablishConnectionsEnabled, ActionEstablishConnectionsDisabled, ActionRemoveConnections, ActionEnableConnections and ActionDisableConnections. The ConnectionManager itself is a UAFX Client. Part 81 clause 13 specifies how it locates servers — via a Global Discovery Server, via a Local Discovery Server, or through a session-less client connection — and how it resolves nodes using PortableNodeId, PortableRelativePath or AliasName.

That indirection matters enormously for C2D. A controller with a fixed IP and a full OPC UA server stack can be found by GDS lookup without trouble. A cascade of 60 drives on a machine cannot each afford a session-based discovery round trip during commissioning. The session-less client connection path and the PortableNodeIdentifier machinery exist precisely so a ConnectionManager can address constrained endpoints without a full session per device.

Connection Establishment Under Load: The C2C Handshake and Why C2D Strains It

Figure 2: the EstablishConnections command sequence from Part 81 clause 6.2.4.3, driven by the ConnectionManager across both endpoints.

Figure 2 traces one connection. Read it as a transaction: the ConnectionManager verifies identity, reserves communication identifiers, creates endpoints, claims control, pushes configuration data, pushes communication configuration, then enables communication. If any step fails, the Abort path unwinds it. Part 81 defines explicit event types for the failure cases — EstablishConnectionErrorEventType and CloseConnectionErrorEventType — alongside ConnectionConfigurationSetProcessingStartedEventType, ConnectionConfigurationSetProcessingSucceededEventType and ConnectionConfigurationSetProcessingFailedEventType.

Why the round-trip count is the real constraint

Work the arithmetic. The following numbers are illustrative — they are not published benchmarks — but they show where the pressure sits.

A C2C commissioning event on a line with eight controllers produces, at most, 28 peer pairs, and in practice far fewer because engineers connect only the pairs that exchange data. Call it 20 connections. At nine commands per connection plus verification reads, that is a few hundred OPC UA service calls. Even at a pessimistic 50 ms per round trip on a loaded engineering network, the whole handshake completes in under a minute.

Now take a packaging line with 8 controllers and 240 field devices — drives, valve islands, I/O heads, sensors with IO-Link masters behind them. If each device needs one connection, that is 240 handshakes. At the same nine commands each, you are at roughly 2,200 service calls, plus asset verification reads that scale with the number of asset nodes per device. On a modular I/O head presenting 40 asset nodes, verification alone is substantial.

Serialised at 50 ms per round trip, 2,200 calls is close to two minutes — acceptable. But the ConnectionManager also has to handle retries on devices that boot slowly, and commissioning is rarely a single clean pass. The practical risk is not raw throughput. It is that a failure in device 173 aborts a configuration set and forces a re-run, and the specification’s transactional model means the ConnectionManager must be able to reason about partial state. That is why the v1.00.04 maintenance work on ConnectionConfigurationSets matters more than it looks.

What the 2026 maintenance releases actually changed

Two dated events are worth separating. In the March 2026 edition of the Foundation’s Field Level Communications Corner, the OPC Foundation announced that Release Candidate V1.00.04 was complete, introducing OPC 10000-81 and OPC 10000-84 into the staged publication of the UAFX 1.00 series. The announced Part 81 content included extensions to the ConnectionManager and ConnectionConfigurationSets, added GDS address support, more flexible referencing from ConnectionEndpoint to DataSet Readers and Writers, improved publishing interval configuration, and clarified requirements for Events and LogObject contents. Part 84 gained new ConformanceUnits reflecting the new Part 81 functionality, and refined Descriptor content ConformanceUnits.

Then, on 27 July 2026, the Foundation published OPC UA FX Specification Maintenance Release V1.00.04, updating Parts 10000-081 and 10000-084. That release carried corrections and enhancements to Part 81 including improved Asset and FunctionalEntity linking, support for multiple GDS addresses, and additional DataSetReader and DataSetWriter identification.

Read those two lists together and a pattern emerges. Multiple GDS addresses, more flexible ConnectionEndpoint-to-DataSetReader/Writer referencing, better Asset-to-FunctionalEntity linking and finer publishing interval control are not C2C conveniences. They are the plumbing a large, heterogeneous, multi-segment device population needs. The 1.00.04 work is C2D groundwork shipped inside a C2C specification.

Client/Server is still future work

One constraint deserves emphasis because it is widely misread. Part 80 clause 6.1 states plainly that this release of the UAFX specification defines Connections using OPC UA PubSub for data exchange, including the usage of TSN, and that Connections using OPC UA Client/Server for data exchange are planned for future releases.

Part 81 does define ClientServerConnectionEndpointType, ClientServerCommunicationFlowConfigurationType and the Client/Server variants of the reserve and configure commands. The type system is there. The concepts part says the data-exchange mapping is not yet released. For anyone designing a C2D architecture, plan for PubSub — a request/response device connection is not something you can specify against today.

Profiles, Conformance Units and the Device-Shaped Gap

Figure 3: Part 84 v1.00.04 builds every application profile on top of the AutomationComponent facets, but the published application profiles are all controller-shaped.

Part 84 is the part that decides what you can certify. Its clause 5 defines ConformanceUnits, grouped as UAFX Base, UAFX AutomationComponent, UAFX FxAsset, UAFX FunctionalEntity and UAFX ConnectionManager for the information model, plus UAFX Ethernet networking features and UAFX Ethernet Networking Quantities for networking, plus a set for OfflineEngineering covering Descriptor, Descriptor Security and Descriptor contents.

Clause 6 then assembles those units into profiles and facets. The Information Model facets in clause 6.6.2 are generic: UAFX AutomationComponent, AutomationComponent Communication Publisher Facet, AutomationComponent Communication Subscriber Facet, Diagnostic Counters Facet, Logging Facet, IFunctionalEntity Facet, ConnectionEndpoint Diagnostics Facet, IAssetRevision Facet, IAssetExtensions Facet, Asset Facet, and the four asset-connector facets — Slot, Socket, Clamp and ClampBlock. Nothing in that list presumes a controller.

The networking facets in clause 6.6.3 are equally neutral: Base Bridge Component Facet, Advanced Bridge Component Facet, Full Bridge Component Facet, End Station Component Facet and UAFX Station.

Then clause 6.6.4 arrives, and it is titled UAFX Controller Profiles. Its members are UAFX Controller Server, UAFX ConnectionManager Client, UAFX SubscriberConfiguration Facet, UAFX SKS Push, UAFX ConnectionManager, ConnectionManager Connection Monitoring Facet, ConnectionManager Diagnostic Counters Facet, ConnectionManager Logging Facet, UAFX Controller and UAFX Controller Safety Facet.

There is no corresponding UAFX Device Profiles group. That is the mechanical definition of the C2D gap. The building blocks — conformance units, information-model facets, networking facets — are already device-agnostic and already published. What has not been published is the set of application profiles that say “a conformant UAFX servo drive shall implement these units and no fewer.”

Why this is the binding constraint, not the information model

It is tempting to conclude that C2D is nearly done because Part 81 already models everything a device needs. That conclusion confuses capability with conformance.

A profile is a purchasing instrument. It is what a test tool checks, what a certificate names, and what a specification in a tender document can reference. Without a device profile, two vendors can both implement Part 81 correctly and still fail to interoperate, because nothing forces them to implement the same subset. The Test Development working group’s charter says this in plain language: it defines test cases based on conformance units, profiles and facets produced by the other FLC groups, and coordinates test-script development with the OPC Compliance working group. No profile means no test case means no certificate.

The Certification Requirements subgroup exists for the same reason, chartered to analyse the requirements for testing and certifying UAFX controllers and devices. The device half of that sentence is still open work.

Safety cuts across both models

OPC UA Safety is the one area where C2D was designed in from the start. The FLC Safety working group’s charter states that OPC UA Safety uses a black-channel approach to specify all safety communication for controller-to-controller as well as controller-to-device. Part 80 clause 6.1 confirms that functionally safe communications using PubSub, and eventually Client/Server, can be addressed by adding the OPC UA Safety protocol defined in OPC 10000-15.

Part 84 already publishes a UAFX Controller Safety Facet. A device-side safety facet is the obvious counterpart, and it is the piece that makes safety drives and safety I/O certifiable over UAFX.

Networking and TSN: What Changes When the Endpoint Is a Sensor

Part 82 defines the general networking requirements for UAFX. Its scope statement names four component abstractions — Bridge Component, End Station Component, IA-station and UAFX Station — and covers network services for remote management, topology discovery and time synchronisation on Ethernet networks.

The selected mechanisms are specific. Remote management is NETCONF over TLS. Topology discovery uses IEEE 802.1AB LLDP with selected YANG modules and a defined TLV selection covering Chassis ID, Port ID, System Capabilities and Management Address. Time synchronisation uses IEEE Std 802.1AS-2020 with a UAFX gPTP profile. Discovery and naming use DHCP, DNS and multicast DNS. Quality of service is built from traffic priority and VLANs, with a default priority-to-traffic-class mapping and a default PriorityMappingTable.

Part 82 is candid about its own limits. Its scope says UAFX intends all networking configuration of End Station and Bridge Components to be done through NETCONF, but that this release selects only the basic protocol layers as a first step. Consequently, it says, this release requires vendor-specific mechanisms such as web interfaces, CLI and engineering tools to configure networking-related mechanisms and services.

The 60802 handoff finally happened

Part 82 also states that definitions it contains which are also covered by the IEC/IEEE 60802 TSN Profile for Industrial Automation will be superseded by IEC/IEEE 60802 after that standard’s publication, and that Part 82 will be updated accordingly.

That publication has now occurred: IEC/IEEE 60802 Edition 1.0 was issued in June 2026 as a dual-logo IEC and IEEE standard. The practical effect is that the TSN feature selection UAFX depends on is now stable and externally maintained, and a future Part 82 revision can delete its interim definitions rather than maintain a parallel profile. For the broader architectural picture see our IEC/IEEE 60802 TSN profile decision guide and the OPC UA over TSN deterministic IIoT reference architecture.

Why devices raise the TSN stakes

C2C traffic between controllers is typically a modest number of high-value flows on a backbone that an integrator controls. Cycle times in the 1 ms to 10 ms range are common, flow counts are in the tens, and the bridges involved are usually managed switches with generous buffers.

C2D flips every one of those properties. Flow counts run to the hundreds. Cycle times for motion can be an order of magnitude tighter. The endpoints are cost-engineered — a valve island or an I/O head has a small PHY budget, limited buffer memory and a controller that may not have hardware timestamping at all. gPTP on such a device is a real bill of materials decision, not a firmware checkbox.

That is why the September 2026 PlugFest results are worth noting for what they tested rather than what they proved. Per the Foundation’s September 2026 Field Level Communications Corner, all UAFX C2C and C2D communication paths tested at the event were successful, and interoperability was demonstrated for UDP multicast communication, priority-based QoS using VLAN tagging, and gPTP time synchronisation across different implementations. VLAN-tagged priority is the entry-level QoS mechanism from Part 82 clause 5.6, not full scheduled traffic. The event validated the baseline, which is exactly what a prototyping phase should do.

A separate two-day Industrial TSN PlugFest for IEC/IEEE 60802 was scheduled at the University of Stuttgart for 28–29 September 2026, bringing industrial TSN endpoint prototypes including UAFX-enabled devices onto a 60802-ready network. Those two events, taken together, are the empirical track record C2D currently has.

For how UAFX compares against entrenched field-level protocols on determinism, see our PROFINET vs EtherCAT vs OPC UA FX over TSN comparison.

A Side-by-Side Decision Matrix

Dimension	Controller-to-Controller (C2C)	Controller-to-Device (C2D)
Specification status (20 Sep 2026)	Published; UAFX 1.00 series, maintenance release V1.00.04 of 27 July 2026	Release candidate in preparation per FLC Corner, June 2026; not published
Normative concepts clause	Part 80 clause 6.1	None yet
Role relationship	Symmetric peers, each with its own application	Asymmetric; controller owns and configures the device
Information model types used	AutomationComponentType, FunctionalEntityType, ConnectionEndpointType	Same, plus heavy use of asset connectors — Slot, Socket, Clamp, ClampBlock — and HasPart
Control semantics	ControlGroup rarely contested	ControlGroup ownership and ReassignControl are central
Data exchange mapping	OPC UA PubSub, TSN optional; Client/Server planned for a future release	Same constraint applies; plan for PubSub
Application profiles in Part 84	UAFX Controller Profiles group, clause 6.6.4	No device profile group published
Certification	Test cases derivable from published profiles	Blocked until device profiles exist
Typical flow count per system	Tens	Hundreds
gPTP burden	On controllers and bridges	Pushed onto cost-engineered endpoints
Safety story	UAFX Controller Safety Facet published	OPC UA Safety black channel covers C2D by charter; device facet pending
Device-class semantics	Not required	Required; Motion, IO and Instrumentation working groups

The matrix makes the asymmetry plain. C2D reuses almost everything from C2C at the type-system level. What it needs is the layer above the type system — semantics per device class, and profiles that make those semantics testable.

Trade-offs, Gotchas, and What Goes Wrong

Figure 4: a decision path for field-level architecture in 2026, given that C2D is not yet a certifiable target.

The first failure mode is buying against a roadmap. A vendor demonstrating C2D at SPS is demonstrating a prototype validated at a PlugFest, not a certified product. The multi-vendor OPC UA FX Demo Wall debuts at SPS in Nuremberg on 24–26 November 2026 and will feature motion devices, remote I/O, field instruments and fieldbus gateways working with UAFX controllers and edge gateways. That is a genuine interoperability milestone and it is also a marketing surface. Treat any C2D claim in a quotation as pre-standard unless the vendor names a published profile.

The second is underestimating the address space. Asset verification is mandatory before a connection is established, and modular devices multiply asset nodes. An I/O rack with slot, socket and clamp modelling can present far more nodes than the controller that owns it. Engineering tools that browse the full address space at commissioning time will crawl. Part 81’s PortableNodeIdentifier and AliasName machinery exists to avoid full browses; use it.

The third is assuming Client/Server. The type system contains Client/Server connection endpoints, and it is easy to assume they are usable for cyclic device data. Part 80 clause 6.1 says the released mapping is PubSub and that Client/Server data exchange is planned for a future release. An architecture that assumes acyclic request/response to 200 drives is designing against something that does not exist yet.

The fourth is treating gPTP as free. The September 2026 PlugFest validated gPTP interoperability across implementations, which is meaningful. It does not mean a €40 sensor can hold a working clock within the jitter budget a motion loop needs. Hardware timestamping is a silicon decision made years before the device ships.

The fifth is network configuration drift. Part 82 openly requires vendor-specific mechanisms — web UIs, CLI, engineering tools — for networking configuration in this release, because the NETCONF and YANG selection is only partial. In a C2C deployment with a dozen bridges that is manageable. Across a line with 60 bridges and hundreds of end stations, manual configuration is how determinism quietly degrades between commissioning and the first production change.

The sixth is mistaking a maintenance release for a feature release. V1.00.04 updated Parts 81 and 84 only. Parts 80 and 82 remain at v1.00.03, which means the concepts chapter and the networking requirements have not been revised to reflect either the new conformance units or the June 2026 publication of IEC/IEEE 60802. Anyone reading only Part 80 will form a slightly stale picture.

Practical Recommendations

Treat 2026 as a preparation year for Controller-to-Device, not a deployment year. The useful work is architectural and procurement-side, and almost all of it pays off regardless of when the C2D release candidate becomes a release.

Start by separating the two decisions that usually get bundled. Deciding to run OPC UA FX between controllers is available today and is testable against published profiles. Deciding to run UAFX down to drives and instruments is a forward commitment. Sequence them; do not gate the first on the second.

On the network side, build for 60802 now. The profile is published, it is stable, and every bridge you buy in the next two years will be in service when C2D lands. Specify gPTP support with hardware timestamping on end stations you expect to carry time-critical device traffic, and insist on NETCONF-capable bridges even though Part 82’s NETCONF selection is still partial.

On the device side, ask vendors three concrete questions rather than whether they “support UAFX.” Which conformance units do they implement today? Do they expose the asset model with connector types for modular hardware? Can their device be onboarded through a Global Discovery Server with certificate provisioning, as the Foundation’s C2C engineering-workflow demonstration requires? A vendor who can answer those is building toward the real thing.

Checklist:

• Confirm current spec versions before writing a requirement — Parts 81 and 84 at v1.00.04, Parts 80 and 82 at v1.00.03.
• Design data exchange around OPC UA PubSub; do not assume Client/Server for cyclic device data.
• Budget gPTP and hardware timestamping into device BOM decisions now.
• Specify IEC/IEEE 60802 conformance for new bridges and end stations.
• Require GDS-based onboarding, certificate provisioning and role-based access control in device tenders.
• Model modular hardware with Slot, Socket, Clamp and ClampBlock semantics in your own asset data, so the mapping is trivial later.
• Keep a fieldbus-to-UAFX gateway in the architecture as the migration bridge.
• Re-read the Field Level Communications Corner each quarter; that is where C2D status changes first.

Frequently Asked Questions

Is OPC UA FX Controller-to-Device released yet?

No. As of 20 September 2026, the published UAFX 1.00 series specifies Controller-to-Controller only. In the June 2026 Field Level Communications Corner the OPC Foundation stated that, following completion of the C2C specifications, the FLC technical working groups were preparing a release candidate with extensions to support C2D communication and integration of motion devices, remote I/O, sensors and actuators. A release candidate is not a release, and no final C2D publication has been announced.

What is the difference between C2C and C2D in OPC UA FX?

C2C connects two peer controllers, each running its own automation application, through a negotiated PubSub data exchange. C2D connects a controller to a field device that has no independent application — the controller owns it, configures it and commands it. Both use the same AutomationComponent abstraction from Part 81, but C2D requires device-class semantics for motion, I/O and instrumentation, plus application profiles that Part 84 has not yet published.

Which OPC UA FX parts do I need to read for C2D?

Part 80 for the interaction model and the explicit statement that only PubSub data exchange is released. Part 81 for the AutomationComponent model, ControlGroups, the EstablishConnections command sequence and the ConnectionManager. Part 82 for networking requirements including gPTP, LLDP and NETCONF. Part 84 for conformance units and profiles — this is where you will see the device-shaped gap most clearly. Part 83 covers OfflineEngineering descriptors.

Does OPC UA FX require TSN?

Not strictly. Part 82’s baseline quality-of-service mechanisms are traffic priority and VLANs, and the September 2026 PlugFest demonstrated priority-based QoS using VLAN tagging alongside UDP multicast and gPTP. TSN is what UAFX uses when bounded latency is required, and it follows the IEC/IEEE 60802 profile, published as Edition 1.0 in June 2026. For motion-class C2D traffic, treat TSN as effectively mandatory.

What changed in the OPC UA FX V1.00.04 maintenance release?

Published 27 July 2026, it updated Parts 10000-081 and 10000-084. Part 81 gained improved Asset and FunctionalEntity linking, support for multiple Global Discovery Server addresses and additional DataSetReader and DataSetWriter identification. Part 84 added ConformanceUnits reflecting the new Part 81 functionality and refined Descriptor content ConformanceUnits. Parts 80 and 82 were not updated and remain at v1.00.03.

Can I certify a UAFX field device today?

Not against a device profile, because Part 84 v1.00.04 publishes only controller-shaped application profiles in its clause 6.6.4 group. A device can implement published information-model and networking facets, and vendors are doing exactly that in prototypes. But certification requires test cases derived from profiles, and the FLC Test Development and Certification Requirements groups are still working the device half of that problem.

Further Reading

• OPC UA FX in 2026: field-level communications goes open — the initiative, its members and its commercial stakes.
• OPC UA FX field exchange reference architecture — how the AutomationComponent model maps onto a real plant topology.
• PROFINET vs EtherCAT vs OPC UA FX over TSN — determinism and cycle-time comparison against incumbent fieldbuses.
• OPC UA over TSN deterministic IIoT reference architecture — network design for bounded-latency OPC UA.
• OPC Foundation online reference, Part 80: UAFX Overview and Concepts — the normative structure of the five-part series.
• OPC Foundation Field Level Communications initiative — working-group charters, including Motion, Instrumentation and IO.

By Riju — about