Time-Sensitive Networking (TSN) Industrial Reference Architecture (2026)

Last Updated: October 4, 2026

A plant floor that runs PROFINET IRT on the robot cells, EtherCAT on the SMT line, a vendor ring on the conveyors and a separate VLAN for vision has solved determinism five times and converged nothing. Each island is deterministic only because nothing else is allowed on its wire. The moment a camera, a historian and a drive share a cable, the old schemes fail in the same way: a 1,538-byte best-effort frame that started a microsecond too early delays a 100-byte control frame by twelve microseconds on a gigabit link, and a hundred and twenty-three microseconds on a 100 Mbit/s one.

Time-Sensitive Networking (TSN) is the IEEE 802.1 answer: a toolbox of Ethernet amendments that give a shared switched network a common sense of time, a way to schedule the wire, and a way to survive a cable cut without losing a frame. In October 2026 it also has something it lacked for years, a finished industrial profile. IEC/IEEE 60802 was published on June 29, 2026, so “which TSN features, with which defaults” now has an answer you can put in a tender.

What this covers: the problem TSN actually solves, a five-plane reference architecture, the standards that matter and their exact status, how the 802.1Qbv gate schedule works with a worked numeric example and a Linux taprio configuration, preemption, per-stream filtering, redundancy with 802.1CB, the configuration models (CUC and CNC), how OPC UA FX rides on top, a migration path, the failure modes that bite in production, and a checklist.

What Changed for October 2026

This is a ground-up rewrite of the June 2026 version of this post. Treat the earlier specifics as superseded; the corrections below are the ones that change decisions.

IEC/IEEE 60802 is published. The IEEE 802.1 project page lists IEC/IEEE 60802-2026 as a published standard dated June 29, 2026 (a 220-page document, per a standards-catalogue listing). The earlier post described the profile as in progress. The IEEE project page itself still shows stale PAR text, so cite the publication, not the PAR.
802.1AS-2020 is the timing baseline, not “AS-Rev”. The earlier post used the working title. The standard is IEEE 802.1AS-2020, with hot-standby grandmaster improvements added by IEEE 802.1ASdm-2024.
Avnu certification dates. The earlier post said the Avnu industrial programme was “finished in late 2024”. Avnu’s own announcement is dated July 9, 2024 and describes a TSN component certification programme that initially covers 802.1AS and enhancements for scheduled traffic (EST, i.e. 802.1Qbv), with preemption (IET) and credit-based shaping (FQTSS) planned to follow. It is a component programme, not a guarantee of whole-plant interoperability.
Amendments are folded into the base standard. 802.1Qbv, Qbu, Qci and Qch are no longer read as standalone documents; they live inside IEEE 802.1Q (first merged in 802.1Q-2018, with later amendments through 2022 to 2025).
OPC UA FX is moving, with a release candidate in flight. The OPC Foundation’s March 2026 field-level communications update describes Release Candidate V1.00.04 with new Parts 81 and 84, an interoperability event at Beckhoff in February 2026, and a multi-vendor demonstration planned for SPS in Nuremberg in November 2026. Real-time FX over TSN is still being prototyped, so treat it as emerging.
Unverified marketing figures removed. The earlier post quoted cabling savings of 30 to 40 percent and a camera bandwidth figure without sources. They are gone; this version labels every illustrative number.

Context and Background

For twenty years, industrial Ethernet bought determinism by owning the wire. PROFINET IRT reserves an isochronous window in every cycle with dedicated ASICs. EtherCAT lets a single frame travel through every device and be edited on the fly. POWERLINK has a managing node poll its controlled nodes, and Sercos III and CC-Link IE Field divide time in their own ways. Each is excellent inside its silo. Each fails, loudly, if a foreign frame appears on the wire. The comparison is covered in depth in PROFINET vs EtherCAT vs OPC UA FX over TSN.

TSN changes the unit of cooperation from the protocol to the switch. Standard Ethernet bridges, extended with time synchronization and scheduled egress, carry control traffic, video, and IT traffic on one fabric, and each class gets the guarantee it needs. The IEEE 802.1 Time-Sensitive Networking Task Group, which evolved from the Audio Video Bridging group, maintains the toolbox. Its project page shows the following as published, with the publication years that matter when you read a datasheet:

Standard	What it does	Published
802.1Qbv	Scheduled traffic (time-aware shaper)	2015, now in 802.1Q
802.1Qbu with 802.3br	Frame preemption	2016, 802.1Q-2018
802.1CB	Frame replication and elimination for reliability	2017
802.1Qci	Per-stream filtering and policing	2017, now in 802.1Q
802.1Qch	Cyclic queuing and forwarding	2017, now in 802.1Q
802.1Qcc	Stream reservation and configuration enhancements	2018
802.1AS-2020	Timing and synchronization (gPTP)	2020
802.1Qcr	Asynchronous traffic shaping	2020
802.1Qdj	Configuration enhancements for TSN	2024
802.1ASdm	Hot standby and clock drift error reduction	2024
IEC/IEEE 60802	TSN profile for industrial automation	June 29, 2026

The 2.5 and 5 Gbit/s Ethernet speeds, single-pair Ethernet, and Ethernet-APL for process plants all matter for the physical layer, and the Ethernet-APL reference architecture covers the process-industry side. The standards body view is on the IEEE 802.1 TSN page.

Why now? Three pressures converge. Motion control, machine vision and digital-twin telemetry now share bandwidth that a 100 Mbit/s fieldbus cannot carry. Software-defined control, where a virtual PLC runs in a container and talks to drives over the network, makes the network the backplane; see software-defined manufacturing with virtual PLCs. And OPC UA has become the common information layer, with FX extending it to the field level. TSN is the Layer 2 half of that pairing.

My thesis in this post is simple and slightly uncomfortable: TSN is not a performance feature, it is an operations discipline. The silicon has been capable for years. What decides whether a TSN deployment works is whether time is trustworthy, whether the schedule is computed from a model rather than hand-tuned, and whether you can see violations when they happen. The architecture below is organized around those three, not around the standards list.

Reference Architecture: Five Planes, One Fabric

A TSN industrial network is best understood as five planes that must each be explicit: the data plane (end stations and bridges forwarding frames), the time plane (gPTP), the control plane (CUC and CNC), the protection plane (filtering, policing, redundancy), and the application plane (OPC UA FX, PROFINET over TSN, vision, IT). If any plane is implicit, you will discover it during an outage.

Figure 1: Time-Sensitive Networking reference architecture, showing the application, control, time, protection and data planes on one switched fabric.

Figure 1 shows how the planes interact. Engineering tools describe streams to the Centralized User Configuration entity (CUC). The Centralized Network Configuration entity (CNC) knows the topology and computes gate schedules, which it pushes to each bridge. The gPTP grandmaster distributes time over the same cables. Policing and redundancy functions run in the bridges and keep one misbehaving talker or one cut cable from harming the others. Applications see a normal Ethernet interface.

The data plane: bridges that can schedule

The data plane is a conventional IEEE 802.1Q bridge with extra egress machinery. Each port has up to eight traffic queues, mapped from the VLAN priority code point (PCP). A transmission gate sits in front of each queue and opens or closes on a repeating schedule. A frame is eligible only if its queue gate is open and the whole frame can finish before the gate closes (or preemption is available). This is the time-aware shaper, standardized as 802.1Qbv.

The critical property is that a schedule moves the contention away from the wire. A control frame does not win because it has a higher priority; it wins because during its window nobody else is allowed to start. Strict priority alone cannot give you this, since a lower-priority frame that has already started cannot be interrupted. That head-of-line blocking is the whole reason Qbv and preemption exist.

The time plane: gPTP and the 1 microsecond budget

Scheduling only works if every bridge agrees what time it is, to well under the gate window. IEEE 802.1AS-2020 is the gPTP profile of IEEE 1588: each hop measures its link delay with peer-to-peer delay messages and corrects for its own residence time, so accuracy does not degrade with load. The industrial profile target is demanding: an IEC/IEEE 60802 requirements presentation gives a maximum time error of 1 microsecond across 64 hops, with a goal of 100 hops, relative to the grandmaster.

Two details matter for architects. First, 802.1AS-2020 supports multiple time domains, and 60802 distinguishes global time, traceable to an external reference, from the working clock, a time source for the application, with optional secondary domains. Separating them lets a cell keep running on its working clock when the plant’s GPS-traceable global reference is lost. Second, because gPTP is hop-by-hop, every device in the path must be gPTP-aware. A non-TSN switch in the middle is not a degraded path; it silently adds asymmetric, load-dependent delay and breaks the time budget.

The control plane: CUC, CNC, and a model of the network

IEEE 802.1Qcc defines three configuration models. In the fully distributed model, talkers and listeners signal reservations hop by hop with the Stream Reservation Protocol (SRP). In the centralized model, a CNC learns topology, receives stream requirements from a CUC, computes the schedules and configures bridges with NETCONF and YANG. A fully centralized model adds the CUC’s control over end stations. Industrial deployments overwhelmingly use the centralized approach, because a schedule is a global optimization problem. You cannot compute non-colliding windows hop by hop.

The 60802 profile defines YANG modules for device data sheets and remote procedure calls, which is the part that makes a CNC from one vendor able to configure bridges from another. That is a larger deal than the shaper itself: before, “TSN-capable” told you nothing about whether you could actually configure it with neutral tooling.

The protection plane: policing and redundancy

A schedule is a promise by the talker as much as by the network. IEEE 802.1Qci per-stream filtering and policing enforces that promise at ingress: it identifies streams, applies stream gates synchronized to the schedule, and meters traffic, so a talker that sends too much, too early, or too large is dropped at the first bridge rather than corrupting everyone’s window. IEEE 802.1CB frame replication and elimination for reliability (FRER) sends duplicate frames over disjoint paths and removes duplicates at the merge point, giving zero-recovery-time redundancy. Both are covered in detail below.

The application plane: what the bits mean

Above the network, applications still need a data model and a transport. In 2026 the realistic options are OPC UA PubSub with the FX profile, PROFINET running over TSN (the TSN-based PROFINET line is the continuity route for Siemens-centric estates), and vendor stacks such as CIP over TSN for EtherNet/IP users. The network does not care. What it cares about is a stream: a source, a destination, a VLAN and priority, a period, a maximum frame size, and a latency requirement. The more precisely engineering tools can state those, the better the CNC can do its job. The companion post on OPC UA over TSN as a deterministic IIoT reference architecture goes deeper on the application seam.

Deeper Analysis: Gate Schedules, Preemption, Filtering and Redundancy

Direct answer: the 802.1Qbv time-aware shaper gives each traffic class a repeating transmission window on every egress port. Because windows are computed centrally from stream requirements and every bridge shares gPTP time, a critical frame meets an open gate with an empty queue at every hop, so end-to-end latency becomes the sum of fixed transmission and forwarding times, not a distribution.

How a Qbv gate control list works

Each egress port holds a gate control list (GCL): an ordered list of entries, each with an eight-bit gate state (one bit per queue, 1 for open) and a time interval. The list repeats with a configured cycle time, anchored to a base time expressed in gPTP time. The bridge executes the list autonomously in hardware, so the schedule is only as good as the clocks behind it.

Figure 2: IEEE 802.1Qbv egress port, showing classification into eight queues, per-queue gates driven by the gate control list, and transmission selection into the MAC with optional preemption.

Figure 2 shows the path a frame takes. The classifier maps the VLAN PCP to a traffic class, the frame waits in its queue, and the gate decides when it becomes eligible. Transmission selection then picks among eligible queues by strict priority. The bridge also applies a guard band: it will not start a frame whose transmission would run past the gate-close time, which prevents a best-effort frame from leaking into the next window.

A worked example (illustrative numbers)

Take a gigabit cell with 16 servo drives, one controller, a 250 microsecond cycle, and each drive producing one 64-byte-payload frame per cycle. The numbers below are my own arithmetic from the Ethernet frame format, not vendor measurements.

A tagged frame is 14 bytes header, 4 bytes VLAN tag, 64 bytes payload and 4 bytes FCS: 86 bytes. Add 8 bytes preamble and 12 bytes inter-frame gap and you get 106 bytes on the wire, or 848 ns at 1 Gbit/s.
Sixteen such frames converging on the controller’s uplink need 16 x 848 ns = 13.6 microseconds, or 5.4 percent of the 250 microsecond cycle.
A maximum-size best-effort frame (1,518 bytes plus 20 bytes of overhead) takes 12.3 microseconds at 1 Gbit/s. Without preemption, the gate for best-effort must close at least that long before the critical window opens. That guard band alone is nearly as long as the critical window itself.
Allow 3 microseconds per hop for store-and-forward forwarding and residence time (an assumption; check your switch’s datasheet), plus 848 ns of transmission, and a five-hop path adds roughly 19 microseconds of latency, constant from cycle to cycle.

A schedule for the controller-facing port might then read: queue 7 open for 20 microseconds at the start of the cycle, queues 0 to 6 open for the remaining 230 microseconds with a 12.3 microsecond guard band ahead of the next cycle’s window. With preemption the guard band shrinks to roughly the preemption residual, covered next.

Frame preemption: 802.1Qbu and 802.3br

Preemption attacks the guard-band cost directly. The Ethernet MAC is split into an express MAC and a preemptable MAC (IEEE 802.3br defines the interspersing of express traffic). When an express frame is ready while a preemptable frame is mid-transmission, the preemptable frame is fragmented: the MAC pauses it, sends the express frame, then resumes with the next fragment. The receiver reassembles. The minimum fragment sizes mean the residual blocking is a few hundred nanoseconds at 1 Gbit/s rather than 12 microseconds. A figure of around 124 bytes of worst-case residual blocking is commonly cited for the standard; verify it against the specification text before you design to it.

The cost is real. Preemption must be negotiated per link using the Link Layer Discovery Protocol (LLDP) and a verification handshake, both ends must support it, and each fragment adds overhead, so throughput drops for the preemptable class. It matters most on 100 Mbit/s links, where an unpreempted maximum-size frame blocks for roughly 123 microseconds, and least on 10 Gbit/s, where the same frame takes about 1.2 microseconds. Avnu’s certification programme listed preemption (IET) as a later phase, which is a reasonable signal that interoperability testing for it lags the shaper.

Per-stream filtering and policing: 802.1Qci

Qci has three building blocks. Stream filters match a frame to a stream by stream handle, priority and maximum frame size. Stream gates open and close on a schedule, so a stream frame outside its window is dropped even if it is perfectly formed. Flow meters apply a two-rate, three-colour policer. Together they make the network defend itself against a babbling talker, a crashed controller that loops, or a misconfigured vision camera.

The operational point is that Qci turns a silent schedule violation into a counter. Each filter exposes drop counts, and those counters are your first-class telemetry for “somebody is breaking the contract”. A Qci deployment that is never monitored gives you protection but no diagnosis.

Frame replication and elimination: 802.1CB

FRER replicates a stream at its source or at an early bridge, sends the copies over disjoint paths, and eliminates duplicates near the listener. Each frame carries a redundancy tag with a 16-bit sequence number. The sequence recovery function keeps a history of sequence numbers and discards any frame whose number has already been seen. If one path fails, the other copy arrives without any reconvergence delay.

Figure 4: IEEE 802.1CB frame replication and elimination, where a talker stream is replicated at the first bridge, travels two disjoint paths, and is merged at the last bridge before the listener.

The trade-offs are concrete. FRER doubles the bandwidth of every protected stream, so protect only the streams that justify it. The paths must truly be disjoint (shared power, shared conduit, or a shared switch defeat the purpose), and the history length must cover the maximum latency difference between paths measured in packets, otherwise good frames are discarded as duplicates or old duplicates slip through. Compare this with ring protocols such as MRP, which reconverge in milliseconds and lose frames during the switchover; FRER loses none.

Other shapers: CQF and ATS

Two alternatives exist for streams where full schedule computation is too heavy. Cyclic Queuing and Forwarding (802.1Qch) forwards in lock-step cycles, so latency per hop is bounded by one or two cycle times without per-stream schedules; it is simple but coarse. Asynchronous Traffic Shaping (802.1Qcr) uses per-stream token-bucket-style shaping and does not need synchronized clocks, which makes it attractive for mixed-criticality networks where time is not available everywhere. In a factory, expect Qbv for hard real-time motion, CQF or ATS for soft-real-time streams, and plain priority for everything else.

Configuring a Linux talker with taprio

End stations need scheduling too. A controller that releases its frame a few hundred microseconds late wastes the network’s precision. Linux provides the taprio queueing discipline, which implements a Qbv-style schedule on the host. The tc-taprio(8) manual page documents three modes. The software mode shown first uses a time-driven schedule; the second uses txtime-assist (flags 0x1) with an ETF qdisc to timestamp packets; the third is full offload (flags 0x2), where the NIC hardware executes the gate list. The manual notes that txtime-assist and full offload are mutually exclusive, so flags 0x3 is invalid.

# Full offload example adapted from the tc-taprio(8) manual page.
# Eight traffic classes, one hardware queue each. Cycle = 100 us.
# Gate masks are hex bitmasks: bit 7 = queue 7 (highest priority).
tc qdisc add dev eth0 parent root stab overhead 24 taprio \
    num_tc 8 \
    map 0 1 2 3 4 5 6 7 \
    queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
    max-sdu 0 0 0 0 0 200 0 0 \
    base-time 200 \
    sched-entry S 80 20000 \
    sched-entry S a0 20000 \
    sched-entry S 5f 60000 \
    flags 0x2

Read it as three time slices: 20 microseconds with only queue 7 open (S 80), 20 microseconds with queues 7 and 5 open (S a0), and 60 microseconds with queues 0 to 4 and 6 open (S 5f), then repeat. max-sdu caps the frame size on queue 5 at 200 bytes, which is how a talker avoids violating a window it cannot fit. base-time is expressed in nanoseconds on the clock chosen with clockid, and in production it must be a future instant on the PTP-disciplined clock, typically CLOCK_TAI. Full offload requires NIC driver support, so check the driver and firmware before assuming it works; consumer-grade controllers that advertise TSN have a history of errata in specific modes.

The configuration conversation

The CNC workflow is where “determinism” becomes a software problem. The sequence in Figure 3 is the shape of every centralized deployment: the CUC collects stream requests from engineering, asks the CNC to compute and provision the schedule, the CNC reads topology and bridge capabilities, pushes configuration, and reports back the result so end stations can start.

Figure 3: Centralized TSN configuration sequence, from stream requests at the CUC through schedule computation at the CNC to gate programming on each bridge and confirmation to the end stations.

Two properties of this flow deserve attention. First, schedule changes must be applied atomically across hops, with a future activation time, or you will briefly have bridges on different schedules and windows that collide. The Qbv specification handles this with an administrative list and an operational list: new schedules are staged, then swapped at a configured time. Second, the CNC is infrastructure. If it is down, the running schedule continues, but you cannot add a stream or recover from a topology change. Treat it like a PLC: redundant, versioned, backed up, and access-controlled.

IEC/IEEE 60802, OPC UA FX and Where They Fit

A toolbox is not a design. The reason TSN deployments stalled between 2018 and 2024 was not missing features but missing choices: dozens of options, no agreed defaults, and consortia each picking a different subset. IEC/IEEE 60802, titled the Time-Sensitive Networking profile for industrial automation, is the joint IEC and IEEE answer. It selects features, options, configurations, defaults, protocols and procedures for bridges, end stations and LANs, and defines YANG modules for data-sheet information and remote procedure calls. The IEEE page lists the publication date as June 29, 2026.

What can you rely on from the profile? From the public material I could verify: a synchronization target of 1 microsecond over 64 hops with a goal of 100; two time-domain concepts (global time and working clock); gating cycle ranges the profile considers, from 250 microseconds to 10 milliseconds at 100 Mbit/s and 31.25 microseconds to 1 millisecond at 1 Gbit/s and above; tick granularity of 10 ns or better; and two conformance classes, a feature-rich Class A and a more resource-constrained Class B. Those figures come from an IEEE 802.1 webinar describing the project while it was in development, so check them against the final text before writing them into a specification. For a deeper walk-through of the profile itself, see our IEC/IEEE 60802 TSN profile analysis.

An important structural point from the 60802 editor’s report is that a profile cannot deviate from the base standards. It cannot loosen 802.1AS; if the industrial requirement needs a change to timing behavior, the change must be made in 802.1AS itself, which is exactly why amendments such as 802.1ASdm (hot standby and clock drift error reduction) exist. A procurement team reads that as: the profile makes choices, the base standards make guarantees.

OPC UA FX on top

OPC UA Field eXchange (UAFX) is the OPC Foundation’s field-level extension, covering controller-to-controller and controller-to-device communication with a standard information model and connection management. It is transport-agnostic in principle, using OPC UA PubSub, with real-time delivery over TSN as the target for deterministic traffic. The Foundation’s March 2026 update describes Release Candidate V1.00.04 with Part 81 (connecting devices and information model, including improved ConnectionManager functionality and publishing interval configuration) and Part 84 (profiles), a February 2026 interoperability event at Beckhoff, and a live controller-to-controller workflow demonstration. A multi-vendor showcase is planned for the SPS fair in November 2026. The same update says real-time communication over TSN is still a focus area where participants aligned on milestones to accelerate prototyping.

My reading: UAFX is a credible convergence target for new machines and cells, but in October 2026 you should treat “UAFX over TSN in production, multi-vendor, at motion-control cycle times” as something to prove in your own lab. The engineering-data and connection-management parts are ahead of the real-time transport. For details on the releases, see OPC UA FX v1.00.04 vs v1.00.03, Parts 81 to 84 and the broader OPC UA FX field exchange reference architecture.

Hardware: what the silicon supports

TSN feature support is a property of the silicon, the driver, and the firmware, in that order of unreliability. Public datasheets help you shortlist. For instance, Microchip’s LAN969x switch family datasheet lists support for 802.1Qbv, 802.1Qch, 802.1Qci, 802.1AS-2020, 802.1CB and 802.1Qbu, with port speeds from 1 to 10 Gbit/s. NXP and other vendors ship automotive and industrial TSN switch and SoC families with similar feature sets. Industrial switch vendors such as Hirschmann, Moxa, Cisco and Belden package this silicon with management software, and the differences that matter are rarely the headline features: they are YANG and NETCONF support, how many gate control list entries a port holds, schedule-change atomicity, counter visibility, and whether FRER is implemented in hardware at line rate.

Ask suppliers five questions in writing: Which of Qbv, Qbu, Qci, CB and AS-2020 are implemented, in hardware, on every port? What is the maximum gate control list length and the minimum entry interval? Is the switch Avnu-certified for 802.1AS and EST, and against which test-tool version? Does it expose a NETCONF/YANG interface that a third-party CNC can drive? And does it implement the 60802 YANG data-sheet modules? Answers that start with “it is TSN capable” are not answers.

Reference Deployment: A Three-Zone Factory

A realistic plant has three zones with different needs. A cell holds a controller, drives and I/O, with cycles from 250 microseconds to a few milliseconds and a handful of hops. A line aggregates cells and carries controller-to-controller traffic, vision streams, and condition monitoring. The site backbone connects lines to MES, the historian, and the edge platform that feeds the digital twin. TSN applies a different mix in each zone.

Zone	Typical traffic	TSN features that earn their keep	Links
Cell	Motion, safety-adjacent I/O, drive feedback	gPTP, Qbv, Qci, optional preemption	100 Mbit/s to 1 Gbit/s
Line	C2C, vision, diagnostics	Qbv for C2C, CQF or ATS for soft streams, FRER on rings	1 to 10 Gbit/s
Site	MES, historian, twin telemetry	VLANs, priority, gPTP distribution only	10 Gbit/s and up

The design rule I use is to keep the hard real-time diameter small. Do not stretch a scheduled domain across the whole plant because the standard permits 64 hops. Every hop adds a scheduling entry, a failure mode, and a debugging session. Keep scheduled streams inside a cell or line, aggregate to the backbone as a policed, shaped class, and let the site run on priorities.

Capacity planning

Compute the schedule from streams, not from interfaces. Build a table with one row per stream: source, destinations, frame size on the wire, period, deadline and redundancy class. Sum the wire time per port per cycle to find utilization (as in the worked example, 5.4 percent for sixteen small frames). Add guard bands, one per gate-closing boundary unless preemption is enabled. Then add 20 to 30 percent headroom for the schedule to grow. Plan for the hyperperiod: if streams have periods of 250 microseconds and 1 millisecond, the schedule repeats every millisecond, and harmonic periods keep the gate list short. Awkward periods such as 300 and 450 microseconds create long schedules that exceed a switch’s gate-list capacity.

Time distribution topology

Put two grandmaster-capable clocks in the architecture, with one in the global-time domain traced to a reference and one acting as the working-clock source for the cell. Use 802.1AS-2020’s external port configuration, or equivalent management control, so the synchronization tree is deterministic rather than elected on the fly after a failure. Hot standby, specified in 802.1ASdm, reduces the switchover time and is the feature to ask about if your process cannot tolerate a time disturbance.

Security belongs in the architecture

TSN assumes a trusted fabric. Time messages and configuration channels are high-value targets: an attacker who can inject gPTP announce messages can move the time that every gate depends on, and one who can reach the NETCONF interface can rewrite the schedule. Mitigations are conventional but must be planned: port-based access control with IEEE 802.1X, device identity with IEEE 802.1AR, link encryption with MACsec where latency budgets allow, management-plane isolation, and zone and conduit design per IEC 62443. See IEC 62443 zones and conduits and zero trust for industrial OT and IoT for the wider design.

Migration Roadmap from Fieldbus Islands

Rip-and-replace is rarely justified. The sequence that works is incremental and starts with what you can measure.

Phase 0, baseline. Capture current cycle times, jitter and loss on existing networks, and inventory every device with its TSN capabilities. Without a baseline you cannot prove improvement.

Phase 1, time first. Deploy gPTP across a pilot area and monitor offset and path delay for weeks before scheduling anything. Time quality problems appear as slow drift, and they are cheaper to find before frames depend on them.

Phase 2, convergence of IT and vision onto the TSN fabric with priorities only. Move non-critical traffic first. This validates cabling, VLAN plans and monitoring without risking motion.

Phase 3, scheduled cell. Pick one cell with a clear owner, compute a Qbv schedule through a CNC, enable Qci in monitoring mode first, then enforcing mode. Compare against the baseline.

Phase 4, redundancy and scale. Add FRER to the streams that justify it, extend to lines, and write the operational runbooks: schedule change, clock failover, switch replacement.

Phase 5, UAFX adoption. As devices ship with UAFX support, introduce controller-to-controller and controller-to-device connections that use the standard information model. Until then, keep the fieldbus for hard-real-time and use TSN for convergence; the two coexist well. For the 5G alternative on mobile assets, see TSN vs 5G URLLC.

Trade-offs, Gotchas, and What Goes Wrong

Time is the single point of failure nobody monitors. If the grandmaster fails and the fallback takes seconds, gates drift apart and windows collide even though every link is up. Monitor offset from master on every bridge, alert at a fraction of the gate window, and test failover on purpose. The symptom of clock trouble is rarely “down”; it is intermittent latency spikes that correlate with nothing.

Schedules go stale. A hand-edited gate list survives until someone adds a drive, swaps a switch, or changes a cycle time. Keep schedules as generated artifacts from a model, in version control, with the stream table as the source of truth.

Non-TSN devices in the path. An unmanaged switch or media converter between two TSN bridges breaks gPTP and can break the schedule silently. Audit every hop, including patch-panel converters and wireless bridges.

Misaligned talkers. The network is only deterministic from the first bridge. If a Linux controller releases packets with scheduler jitter of hundreds of microseconds, the first-hop Qci stream gate will drop the late frames. Use hardware-offloaded scheduling on the end station, or a real-time kernel with taprio and etf, and measure transmit timestamps.

Feature-matrix surprises. “Supports Qbv” can mean four gate entries per port, no cycle-time extension, or no interoperability with another vendor’s CNC. Preemption mismatches are a classic: one end negotiates it, the other does not, and the link silently falls back.

FRER misconfiguration. A history length too short for the path-delay difference causes good frames to be eliminated as duplicates. A shared failure domain (same power feed, same conduit) means redundancy that never helps.

Complexity cost. TSN needs skills that sit between networking and automation: YANG, NETCONF, PTP analysis, schedule modelling. If your team will not keep those skills, a simpler design may be the right call: priority queuing and over-provisioned gigabit links solve many cells with soft real-time needs. Do not adopt TSN for prestige; adopt it for a measured requirement such as multi-protocol convergence, sub-millisecond bounded latency, or zero-loss redundancy.

Observability gaps. A deployed schedule without telemetry is a faith position. Collect Qci drop counters, gate-state errors, gPTP offset and path-delay histograms, and queue depth, and put them in the same dashboards operators already use.

Practical Recommendations

Start from requirements, not from standards. For each stream write down period, frame size, maximum latency, maximum jitter, and loss tolerance; only streams with sub-millisecond bounds or zero-loss needs justify scheduled traffic or FRER. Everything else can ride on priorities.

Adopt the 60802 profile as your procurement baseline, since it is now published, and require suppliers to state conformance class and YANG data-sheet support. Require Avnu component certification where it exists for the features you need, understanding that it covers 802.1AS and EST first. Treat UAFX over TSN as a pilot technology and test interoperability with your actual controller and drive pairs.

Invest in the control plane. Pick a CNC that speaks standard NETCONF and YANG, deploys atomic schedule changes, and exports its model. Make two clocks and a tested failover part of the design review.

Checklist before go-live:

Stream table complete, with wire sizes and periods, and harmonic where possible
Every device in each scheduled path is gPTP-aware, verified by an audit, not an assumption
Grandmaster failover tested, with measured time disturbance recorded
Schedule generated from the stream table and stored in version control
Qci enabled, counters exported, alert thresholds set
Preemption and FRER capabilities verified per link and per path, including disjointness
End-station transmit jitter measured against the first-hop window
NETCONF and management plane segmented, authenticated and logged
Rollback procedure for schedule changes rehearsed

Frequently Asked Questions

What is Time-Sensitive Networking in industrial automation?

Time-Sensitive Networking is a set of IEEE 802.1 and 802.3 standards that add deterministic delivery to standard Ethernet. Bridges share a synchronized clock (gPTP, IEEE 802.1AS-2020), transmit critical traffic in scheduled windows (802.1Qbv), protect streams with policing (802.1Qci), and survive cable failures with duplicate frames over disjoint paths (802.1CB). The result is bounded latency for control traffic on the same network that carries video and IT data, replacing separate fieldbus islands.

Is IEC/IEEE 60802 published?

Yes. The IEEE 802.1 project page lists IEC/IEEE 60802-2026, the time-sensitive networking profile for industrial automation, as published on June 29, 2026, and a standards-catalogue listing shows a 220-page document. The profile selects TSN features, options, defaults and procedures for bridges and end stations, and defines YANG modules for data-sheet information and remote procedure calls. It does not change the base standards; it chooses from them so that multi-vendor industrial networks interoperate more predictably.

What is the difference between 802.1Qbv and 802.1Qbu?

IEEE 802.1Qbv is the time-aware shaper: a repeating gate schedule that opens and closes each traffic queue at planned times, so critical frames find an empty path. IEEE 802.1Qbu, together with IEEE 802.3br, is frame preemption: an express frame can interrupt a lower-priority frame mid-transmission. Qbv schedules the wire; preemption shrinks the guard band that Qbv would otherwise reserve. They are complementary, and preemption matters most on slower 100 Mbit/s links.

Does TSN replace PROFINET or EtherCAT?

Not directly. TSN is a Layer 2 capability, while PROFINET, EtherCAT and OPC UA FX are application-level protocols. PROFINET can run over a TSN network, and OPC UA FX is designed to use TSN for deterministic delivery. EtherCAT’s on-the-fly processing is a different mechanism and remains strong for tight motion loops. Most plants will run mixed estates for years, using TSN to converge IT, vision and controller-to-controller traffic first, and moving hard-real-time loops only when a measured benefit exists.

How accurate does gPTP need to be for TSN?

It depends on the gate windows, but the industrial target is demanding. IEC/IEEE 60802 requirements material specifies a maximum time error of 1 microsecond across 64 hops relative to the grandmaster, with a goal of 100 hops. Since gate windows are typically tens of microseconds or more, 1 microsecond is a sound budget. IEEE 802.1AS-2020 achieves this using peer-to-peer delay measurement and hop-by-hop correction, which is why every device in the path must support gPTP.

Do I need TSN, or are priorities enough?

If your streams tolerate occasional latency spikes of hundreds of microseconds and you can over-provision links, strict priority queues on gigabit Ethernet may suffice. Choose TSN when you need bounded worst-case latency or jitter under load, when you are converging several real-time protocols, or when zero-loss redundancy matters. The decision should come from measured requirements. TSN adds configuration, time distribution and monitoring work that you should only accept for a concrete payoff.

References

IEEE 802.1 TSN Task Group, standards and publication status. https://1.ieee802.org/tsn/
IEEE 802.1, IEC/IEEE 60802 TSN Profile for Industrial Automation (published June 29, 2026). https://1.ieee802.org/tsn/iec-ieee-60802/
IEEE 802.1, 60802 D3.4 editor’s report, June 2025. https://grouper.ieee.org/groups/802/1/files/public/docs2025/60802-woods-D3-4-update-06-25-v01.pdf
IEEE 802.1, TSN and 60802 webinar (Woods), April 2023. https://www.ieee802.org/1/files/public/docs2023/webinar-woods-TSN_60802-0423.pdf
Avnu Alliance, TSN component certification programme announcement, July 9, 2024. https://avnu.org/news/worlds-first-tsn-component-certification-program-from-avnu-alliance-delivers-interoperability-within-converged-networks/
OPC Foundation, Field Level Communications Corner, March 2026. https://opcconnect.opcfoundation.org/2026/03/field-level-communications-corner-march-2026/
Linux tc-taprio(8) manual page. https://www.man7.org/linux/man-pages/man8/tc-taprio.8.html
Microchip, LAN969x Ethernet Switch Family datasheet. https://mouser.com/pdfDocs/LAN969x-Ethernet-Switch-Family-00005274.pdf
IEEE SA, TSN industry flyer 2026. https://engagestandards.ieee.org/rs/211-FYL-955/images/IEEE-SA_TSN_Industry_8.5x11_flyer_2026_web.pdf

By Riju – about