Understanding OPC UA FX Architecture: Controllers, Devices, and TSN

How many communication protocols are running across your automation setup right now? And how many of them actually talk to each other without a workaround in between?

For most engineers, the honest answer is more than it should take. That's not a design failure on your part. It's the reality of building automation systems where every vendor brought their own protocol to the table, and interoperability was always an afterthought.

That's the gap OPC UA FX Architecture was built to close. Not just at the data layer, but deep at the field level where controllers, drives, robots, and sensors do the actual work.

In our first blog of this series, we covered what OPC UA FX is and why traditional OPC UA couldn't fully address field-level communication on its own. This blog goes one layer deeper into how each component is structured and how TSN ties it all together. If you're working with or planning around OPC UA PubSub communication, this is the architectural foundation you need to understand first.

Breaking Down the OPC UA FX Architecture

At its core, OPC UA FX brings together three essential elements: controllers, field devices, and a TSN-enabled Ethernet network. Controllers and devices exchange information using standardized OPC UA FX models, while TSN provides the deterministic communication required for real-time industrial applications. Together, these technologies form the foundation of the OPC Foundation's Field Level Communications (FLC) architecture.

Before examining these components in more detail, it's worth introducing another important concept used throughout the architecture: Functional Entities (FEs). One of the core building blocks of the OPC UA FX architecture. Functional Entities are standardized software representations that exist within OPC UA FX controllers and devices. They describe a device's capabilities, the data it can publish or consume, and the interfaces it exposes to the rest of the system. By representing these capabilities in a standardized way, Functional Entities allow devices from different vendors to understand and interact with each other using a common communication framework. 

Each Functional Entity contains InputSets and OutputSets that define the process data exchanged through OPC UA PubSub communication. For example, a drive may expose speed commands through its InputSet and publish actual speed feedback through its OutputSet.

During system configuration, a Connection Manager- either embedded within a controller or deployed as a separate engineering component - uses these Functional Entity definitions to verify that communicating devices are compatible. Once validated, the publisher-subscriber relationship can be established and cyclic data exchange can begin..

OPC UA FX Controllers: Enabling Distributed Control and Communication

Controllers are one of the primary participants in the OPC UA FX architecture. Defined by the UAFX Controller Profile, they combine traditional control functionality with standardized OPC UA-based communication capabilities.

A UAFX controller can act as a Publisher, Subscriber, or both, exchanging information with other controllers and field devices through OPC UA FX communication mechanisms. In addition to executing automation logic, controllers expose standardized information models that describe their capabilities, configuration, and operational data.

By supporting interoperable communication across vendor boundaries, UAFX controllers help create distributed automation systems where information can be exchanged using common standards rather than proprietary protocols.

OPC UA FX Field Devices: Extending Interoperability to the Factory Floor

Field devices represent the physical layer of an automation system, including drives, remote I/O modules, sensors, actuators, robots, and other equipment deployed on the factory floor.

Within the OPC UA FX architecture, these devices are no longer limited to exchanging raw process values. Instead, they can expose standardized information models that describe their functions, capabilities, and operational data in a consistent manner across vendors.

This standardized representation enables controllers and other devices to understand and interact with field equipment more effectively, reducing integration complexity and supporting greater interoperability throughout the automation system.

TSN: Providing Deterministic Communication for OPC UA FX

Time-Sensitive Networking (TSN) provides the network foundation that enables OPC UA FX to support real-time industrial communication requirements. Rather than being a separate communication protocol, TSN is a collection of IEEE 802.1 standards that enhance standard Ethernet with deterministic networking capabilities.

TSN introduces features such as precise time synchronization, traffic scheduling, and guaranteed bandwidth allocation, allowing critical automation data to be delivered within predictable time boundaries.

By combining OPC UA FX communication models with TSN Network Architecture-enabled Ethernet infrastructure, industrial systems can support both operational technology (OT) and information technology (IT) traffic on a common network while maintaining the timing requirements needed for automation and control applications.

Feature	Standard Ethernet	TSN Network Architecture
Latency	Variable, load-dependent	Bounded and guaranteed
Time Synchronization	Not required	Precision clock across all nodes
Traffic Prioritization	Basic QoS only	Dedicated time slots per stream
IT/OT Convergence	Separate networks needed	Single converged network
Real-Time Control Suitability	Limited	Designed for it

How the OPC UA FX Architecture Works Together

Individually, controllers, field devices, and TSN each serve a specific purpose. The real value of OPC UA FX emerges when these components work together as part of a unified communication architecture.

In a typical deployment, controllers and field devices expose standardized OPC UA information models describing their capabilities, interfaces, and operational data. These capabilities are represented through Functional Entities, which define how information is exchanged between participants in the network.

During engineering and commissioning, the Connection Manager uses these Functional Entity definitions to validate compatibility and establish communication relationships between controllers and field devices. This allows devices from different vendors to be integrated using a common communication framework.

Once communication has been configured, process data is exchanged using OPC UA PubSub. Controllers and field devices can act as Publishers, Subscribers, or both, depending on their role within the system. This enables controller-to-controller (C2C), controller-to-device (C2D), and device-to-device (D2D) communication using a common framework.

Unlike traditional PLC-centric architectures, OPC UA FX allows smart field devices to participate directly in network communication. Sensors, drives, robots, and other field devices can publish and subscribe to process data independently, enabling more distributed and interoperable automation systems.

At the network level, Time-Sensitive Networking (TSN) provides deterministic communication by synchronizing devices and ensuring critical automation traffic is delivered within predictable timing boundaries. As a result, operational technology (OT) traffic and enterprise IT traffic can coexist on the same Ethernet infrastructure without compromising real-time performance.

Together, these technologies create a vendor-independent automation architecture where devices can discover capabilities, exchange information, and coordinate actions using standardized communication mechanisms rather than proprietary protocols.

Building the Future of Interoperable Automation 

The OPC UA FX architecture matters because of what it removes from your engineering workload. When controllers talk directly to peer controllers, field devices expose structured semantic data regardless of manufacturer, and TSN guarantees every critical exchange, the biggest blockers to real Industry 4.0 interoperability are gone.

You're no longer locked into one vendor ecosystem. You're no longer managing separate network infrastructures for safety, control, and enterprise systems. The specifications are published and Phase 2 device profile expansion is already underway.

If you need hands-on support building UAFX-compliant systems, our OPC UA development services team works across information modeling, embedded integration, and multi-vendor interoperability projects.

Frequently Asked Questions

Q1. What is the role of the Connection Manager in OPC UA FX architecture?

The Connection Manager is responsible for establishing and managing communication relationships within an OPC UA FX system. It uses Functional Entity definitions to verify compatibility between participants, validates communication parameters, and configures the Publisher-Subscriber connections required for cyclic data exchange. 

Q2. What is the IEC/IEEE 60802 profile and why does it matter for OPC UA over TSN?

IEC/IEEE 60802 is the Time-Sensitive Networking (TSN) profile developed for industrial automation. It defines a common set of TSN features, configuration rules, and interoperability requirements, ensuring that controllers, field devices, and network infrastructure from different vendors can operate together on the same TSN-enabled network. 

Q3. Can OPC UA FX field devices work on existing Ethernet infrastructure?

Yes. OPC UA FX communication can operate over standard Ethernet networks. However, applications requiring deterministic real-time performance benefit from TSN-enabled infrastructure that complies with the IEC/IEEE 60802 profile, including compatible switches and network devices. 

Q4. What is the difference between C2C, C2D, and D2D communication in OPC UA FX?

Controller-to-Controller (C2C) communication enables direct data exchange between controllers. Controller-to-Device (C2D) communication allows controllers to interact with field devices such as drives, I/O modules, and sensors. Device-to-Device (D2D) communication enables smart field devices to exchange information directly without routing all traffic through a controller. In OPC UA FX, these communication patterns are supported through standardized PubSub mechanisms.