OPC UA Over TSN for Real-Time Industrial Communication: Understanding the Technology and Implementation

How time-sensitive networking enables deterministic communication for machine-to-machine control at the field level

Industrial automation has relied on specialized fieldbus protocols for decades to achieve the precise timing control needed for motor coordination, robotic control, and synchronized manufacturing processes. Each protocol—PROFINET, EtherCAT, Powerlink, EtherNet/IP—solved the real-time communication problem but created a different challenge: vendor lock-in and system incompatibility.

A machine builder selecting a controller from one vendor and motor drives from another often faces incompatibility when the devices use different protocols. This limitation affects flexibility in equipment selection and creates dependencies that complicate maintenance and upgrades.

OPC UA combined with Time-Sensitive Networking offers a different approach. Melvin Francis, project manager for OPC UA and TSN services at be services in Germany, has been working on industrial real-time protocols for nearly a decade. His current research focuses on making OPC UA over TSN practical for implementation on resource-constrained embedded systems.

‍

‍

Understanding Time-Sensitive Networking Fundamentals

‍

Time-Sensitive Networking is not a single protocol but a collection of IEEE standards that work together to provide deterministic communication over standard Ethernet. The technology addresses two fundamental requirements for industrial control: precise time synchronization and guaranteed bandwidth allocation.

The time synchronization component uses IEEE 802.1AS standard, which implements the Precision Time Protocol. In a factory environment with multiple devices controlling coordinated motion, every device must operate with the same time reference accurate to sub-microsecond levels.

Consider ten devices on a network, each with its own internal clock. Without synchronization, these clocks drift relative to each other. For office applications, a few seconds of difference does not matter. For coordinated motor control where positions must align within microseconds, this drift creates problems.

The synchronization process works through a best master clock algorithm. The network participants evaluate themselves against six parameters including clock accuracy and priority to determine which device has the most accurate timekeeper. This device becomes the grandmaster clock for the network. All other devices become slaves that synchronize to the grandmaster.

Slaves continuously exchange messages with the grandmaster, comparing their local time to the grandmaster time. When a slave detects it is ahead or behind, it adjusts its clock accordingly. This exchange happens continuously, keeping all devices synchronized within sub-microsecond accuracy.

One way to visualize this synchronization is through a one pulse per second signal. Each device generates a pulse at precisely one-second intervals. When displayed on an oscilloscope, unsynchronized devices show pulses scattered across time. As synchronization establishes, the pulses converge until they appear as a single line—all devices pulsing at exactly the same moment.

‍

Traffic Shaping for Guaranteed Bandwidth

‍

Time synchronization alone does not solve the real-time communication problem. Networks also need guaranteed bandwidth for critical traffic. This is where IEEE 802.1Qbv standard, known as time-aware scheduling, becomes relevant.

Think of network bandwidth as a shared resource similar to conversation time in a meeting. Some participants need to convey critical information within strict time limits. Others engage in less critical discussion. Without structure, the critical information might get delayed or interrupted by other traffic.

Time-aware scheduling divides time into repeating cycles and assigns specific time windows to different traffic classes. Critical control traffic gets dedicated windows where only that traffic can transmit. Non-critical traffic uses the remaining windows. Because all devices share the same synchronized time, they know exactly when their assigned windows open and close.

Using a 60-second meeting example: critical speakers get 40 seconds of guaranteed uninterrupted time every minute. The remaining 20 seconds is available for other discussions. In network terms, critical motor control packets get 40 percent of every transmission cycle with guaranteed delivery. Diagnostic data, configuration traffic, or video feeds use the remaining bandwidth.

This approach enables a single network to carry multiple types of traffic—real-time control, SCADA data, video surveillance, and IT traffic—without interference. This converges what traditionally required separate networks for operational technology and information technology.

‍

Why OPC UA Needs TSN for Field-Level Communication

‍

OPC UA has been used successfully for enterprise-level industrial communication for years. It excels at connecting manufacturing execution systems to equipment, providing rich information models and secure communication. However, traditional OPC UA uses client-server communication that cannot achieve the cycle times required for field-level control.

Client-server protocols are connection-based. A client requests data, the server responds. This works well for supervisory systems checking status every few seconds or minutes. It cannot reliably deliver data every 100 or 250 microseconds as needed for coordinated motion control.

The OPC UA Part 14 specification added publish-subscribe capability to address this limitation. In PubSub mode, devices publish data at regular intervals without waiting for requests. Subscribers receive this data directly. This removes the request-response delay inherent in client-server communication.

However, PubSub over MQTT or message brokers still cannot guarantee the precise timing needed for control applications. Brokers introduce variable latency as they route messages. For sending sensor data to the cloud every second, this latency is acceptable. For motor control requiring updates every 250 microseconds, it is not.

OPC UA PubSub over TSN uses brokerless communication, sending packets directly from publisher to subscriber over UDP or raw Ethernet. Combined with TSN traffic shaping, this provides the timing guarantees needed for field-level control while maintaining the semantic richness of OPC UA information models.

This combination solves a long-standing problem in industrial automation. Manufacturers can use OPC UA from the sensor level through control, supervisory systems, and up to the cloud. The same protocol handles both real-time control and enterprise integration, reducing complexity and vendor dependencies.

‍

Relationship to OPC UA Field-Level Communications Specification

‍

OPC UA Field-Level Communications is a companion specification that defines exactly how OPC UA PubSub should operate over TSN networks. It provides the detailed implementation requirements that ensure different vendors' products can interoperate when implementing OPC UA over TSN.

The distinction between brokered and brokerless PubSub is central to understanding field-level communications. Brokered PubSub, typically over MQTT, works well for sending data from sensors to cloud systems with publishing intervals of 500 milliseconds or longer. The broker provides useful features like message queuing and quality of service management.

Field-level communication requires different characteristics. Sub-millisecond cycle times of 250 microseconds or even 100 microseconds cannot tolerate broker latency. The FLC specification therefore defines brokerless operation where publishers send directly to subscribers with TSN providing the deterministic delivery guarantees.

‍

Current Research: Low-Footprint Implementation on Embedded Systems

‍

The challenge in making OPC UA over TSN practical is implementation complexity. The technology stack includes seven or more components that must work together: TCP/IP stack, PTP synchronization, TSN scheduling software, configuration management, OPC UA client/server, OPC UA PubSub, and the application itself. All of this must fit in the limited memory and processing power of an embedded controller or motor drive.

The research project at be services, conducted in partnership with Offenburg University and funded by the German government, focuses on creating an ultra-low-footprint SDK that combines all necessary components for OPC UA over TSN. The goal is making the technology accessible to small and medium manufacturers, not just large automation vendors.

The project targets both wired and wireless implementations. While wired Ethernet TSN is more mature, extending the concepts to wireless networks could enable mobile robots and automated guided vehicles to participate in time-synchronized networks. The wireless implementation faces additional challenges in maintaining the determinism that wired networks provide more easily.

Hardware independence is another key objective. The same SDK should work on ARM processors from different vendors—Texas Instruments, Analog Devices, NXP, Renesas—without requiring vendor-specific modifications. It should also be operating system independent, running on bare metal, FreeRTOS, microC/OS, VxWorks, or real-time Linux.

This portability ensures that manufacturers can choose hardware based on their specific requirements rather than being limited to whatever platforms existing TSN implementations support. It also protects against single-vendor dependencies in a rapidly evolving technology space.

‍

Implementation Challenges and Testing Requirements

‍

One significant challenge in OPC UA over TSN implementation is testing and validation. Demonstrating that devices are synchronized is straightforward with oscilloscopes showing pulse alignment. Proving that synchronization remains stable over hours, days, or weeks of continuous operation requires capturing and analyzing millions of data samples.

Commercial test equipment for TSN validation exists but costs prohibit smaller manufacturers from using it. Part of the be services research involves developing open-source test tools that measure synchronization accuracy and packet timing characteristics using accessible hardware.

These test tools run on standard Linux systems with Intel i210 network interface cards, which have built-in TSN support. The total hardware cost for a test system is approximately 200 to 250 euros, making it accessible to companies wanting to experiment with the technology before committing to production implementations.

The test tools measure key TSN parameters including synchronization jitter and traffic shaping performance. They capture network traffic and generate visualizations showing whether packets arrive within their designated time windows. This capability helps developers tune their implementations and diagnose timing issues during development.

‍

Getting Started with OPC UA Over TSN

‍

For organizations interested in exploring OPC UA over TSN, several paths are available depending on objectives and resources. The most accessible starting point uses Linux systems with Intel i210 network interface cards. All necessary software is open source and available through the be services project website.

A developer can set up a working OPC UA over TSN system in about half a day using a PC with an i210 card, downloading the open62541 OPC UA stack with TSN extensions, and following the quick start guide. This provides hands-on experience with the technology without significant investment.

For embedded ARM platform development, the situation is more complex. Not all components are fully open source due to commercial licensing considerations. Companies serious about incorporating OPC UA over TSN into products can engage with be services through signed agreements to access additional resources and reference implementations.

The project maintains reference designs for multiple hardware platforms including development boards from Renesas, Analog Devices, and Texas Instruments. These references show how to integrate the complete stack on resource-constrained embedded systems, addressing practical issues like memory management and real-time scheduling.

Beta releases are already available to selected partners for evaluation and feedback. While not production-ready, these releases allow companies to assess the technology and plan integration into their product roadmaps. The project aims for production-ready releases as the research progresses through its two-year timeline.

‍

The Path Forward for Converged IT and OT Networks

‍

OPC UA over TSN represents more than an incremental improvement in industrial communication. It enables fundamental changes in how manufacturing systems are architected. The ability to run real-time control, supervisory data collection, business system integration, and IT services on a single converged network simplifies infrastructure and reduces costs.

Traditional automation required separate networks for different functions. Field buses connected sensors and actuators to controllers. SCADA networks connected controllers to supervisory systems. Enterprise networks connected business systems. Each network had its own physical infrastructure, switches, and cabling.

Converged networks using TSN can carry all traffic types with appropriate quality of service for each. Time-critical control traffic gets guaranteed bandwidth and timing. Diagnostic data flows without interfering with control. Video surveillance for security uses available bandwidth without disrupting operations. All traffic shares physical infrastructure while maintaining isolation and determinism where needed.

This convergence also addresses the vendor lock-in problem that has limited flexibility in equipment selection. When all devices communicate using OPC UA over TSN, a motor drive from one vendor can work with a controller from another vendor without protocol translation or gateway devices. This interoperability gives manufacturers more freedom in equipment selection and reduces dependency on single vendors.

The technology is moving from research to practical implementation. Multiple vendors now offer TSN-capable network infrastructure. Semiconductor companies provide TSN support in their network interface controllers. Industrial PC and embedded controller manufacturers are adding TSN capabilities. The ecosystem is developing rapidly.

For manufacturing organizations planning automation system upgrades or new installations, understanding OPC UA over TSN capabilities is becoming important. While not every application requires sub-millisecond control, designing networks with TSN capability provides flexibility for future requirements and simplifies integration across control, supervisory, and enterprise levels.

‍