OPC UA FX & TSN in 2026: Multi-Vendor Automation

OPC UA has been common above the controller layer for years. In 2026, OPC UA FX is now proving multi-vendor Controller-to-Controller (C2C) interoperability while Controller-to-Device (C2D) extensions are being prototyped and validated across controllers, I/O and drives. The work is beginning to look less like a standards exercise and more like an interoperable field system.

At the OPC Foundation’s four-day OPC UA FX PlugFest at Festo in Esslingen from 7 to 10 September 2026, 28 participants from 16 companies tested controllers, I/O, drives and other field-device prototypes. The Foundation reported that all tested OPC UA FX Controller-to-Controller (C2C) and Controller-to-Device (C2D) communication paths were successful. The event also exercised UDP multicast, VLAN priority-based QoS and gPTP time synchronisation across different implementations.

That does not mean every PLC, drive and remote I/O on the market can now be mixed freely. A PlugFest is not the same thing as a production certification programme. But it is a useful sign that the engineering problem has moved on from “can the specification work?” to “how do we procure, commission and maintain it properly?”

Two pieces have fallen into place this year

The first is OPC UA FX itself. The OPC Foundation published maintenance release V1.00.04 in July 2026, refining the field-level connection model, profiles and conformance units. The September interoperability work then put those definitions against multiple implementations.

The second is Time-Sensitive Networking. IEC/IEEE 60802-2026 was published on 29 June 2026. It defines a TSN profile for industrial automation by selecting the features, options, defaults and procedures that bridges and end stations should use. This matters because saying that a switch or controller is merely “TSN capable” is too vague for a multi-vendor industrial design. A common profile gives vendors and users something more concrete to engineer against.

OPC UA FX does not depend on TSN for every use case, but the combination is important where deterministic Ethernet behaviour, time synchronisation and interoperable field communication are required.

What OPC UA FX is trying to solve

Factories already have many good industrial communication systems. PROFINET, EtherCAT, EtherNet/IP, CANopen, CAN FD and other protocols are not going to disappear simply because another specification exists. In many machines they are mature, fast and well understood.

The recurring problem is at the boundaries. One controller vendor has its own engineering model, another has a different one, the drive layer is handled separately, security onboarding is inconsistent, and the data model seen by the edge or MES layer has to be rebuilt yet again.

OPC UA FX is aimed at making some of those boundaries less proprietary. It extends the OPC UA information model, security and engineering concepts towards the field, including controller-to-controller and controller-to-device use cases. That gives machine builders and plant integrators a route to carry both data and its meaning across vendor boundaries rather than simply moving anonymous registers from A to B.

This is also why I would not describe OPC UA FX as a replacement for existing deterministic fieldbuses. In a brownfield plant, replacing a reliable servo or safety architecture merely to claim a new protocol usually creates more risk than value. The first useful applications are likely to be where multi-vendor controllers, cells or skids have to interoperate, where engineering data needs to survive equipment changes, or where a new machine platform is being designed with a longer lifecycle in mind.

What should go into a specification now

For a new machine or plant project, “supports OPC UA” and “supports TSN” are no longer sufficient procurement statements. They hide too much.

State the OPC UA FX function required. C2C should be explicit. Where C2D is proposed, require the vendor to state whether the implementation is a production release, prototype or pre-certification build, together with the relevant profile and specification version.
Ask for conformance and interoperability evidence. Certification status, PlugFest participation and supported conformance units are more useful than a logo on a brochure.
Define the engineering workflow. Controller descriptors, offline engineering, certificate provisioning, Global Discovery Server behaviour and role-based access should be considered before commissioning.
Define the TSN profile where deterministic Ethernet is required. Time synchronisation, QoS, VLAN behaviour and topology assumptions should be documented instead of relying on the phrase “TSN ready”.
Specify failure behaviour. A deterministic communication path still needs a defined response when time sync is lost, a certificate expires, a connection cannot be established or a device is replaced.

The objective is not to write a thicker tender. It is to avoid discovering during FAT that two devices are each standards-compliant but were engineered around different assumptions.

Where this fits beside brownfield OPC UA and Single-Pair Ethernet

For an existing plant, the migration path is usually layered. Legacy OPC DA can be bridged to modern OPC UA without disturbing reliable control, as discussed in our earlier note on modernising brownfield SCADA data from OPC DA to OPC UA. OPC UA FX becomes more relevant when new controllers and devices are being introduced and the field-level architecture itself is open for redesign.

Physical media is a separate decision. 10BASE-T1L Single-Pair Ethernet can be useful where long-reach Ethernet to field devices makes sense, while conventional industrial Ethernet remains appropriate elsewhere. OPC UA FX sits above that choice. The transport, profile and application model still have to be engineered as one system.

Why this matters to machine builders in Malaysia and Singapore

Malaysia and Singapore have large installed bases of multi-vendor automation in semiconductor, electronics, logistics, process and general manufacturing. Many machine builders also export equipment into plants that already have their own preferred PLC, security and data standards.

A more interoperable field architecture can reduce the amount of custom glue code needed between machines, controllers and plant systems. It can also make equipment replacement less disruptive because the engineering description, security model and data semantics are not tied as tightly to one vendor’s private interface.

The cost side still needs discipline. New standards do not remove validation, certification, cybersecurity or commissioning effort. In the early phase, they can increase it because engineering teams are learning the new tooling while vendor implementations are still maturing. I would therefore use OPC UA FX first where interoperability has a measurable lifecycle value, not simply because it is new.

What I would test in a real project

Before specifying OPC UA FX plant-wide, I would build a small multi-vendor test cell with at least two controllers, one representative field device, the intended managed Ethernet switches and the actual certificate-management approach. Test commissioning, device replacement, time-sync loss, certificate expiry, network load and recovery after power cycling. Do it with the same engineering tools that will be used on site.

If the project includes TSN, verify the actual IEC/IEEE 60802 profile implementation rather than treating deterministic Ethernet as a property of the cable. If a conventional industrial Ethernet or fieldbus already meets the machine’s timing and reliability requirements, keep it. OPC UA FX is most valuable where it removes an integration boundary, not where it simply adds another acronym.

Sources

Featured image: CANS industrial automation project image.

Planning a multi-vendor PLC, SCADA, OPC UA or industrial Ethernet architecture? CANS can review the communications design, brownfield migration path and integration boundaries before they become commissioning problems. Contact CANS or WhatsApp us.

OPC UA FX in 2026: Multi-Vendor Field Interoperability Is Getting Real