IEC/IEEE 60802 TSN Profile: 7 Decisions Industrial Network Architects Must Make in 2026

For eight years, the honest answer to “should we build this cell on TSN?” was “wait for the profile.” That answer expired on 29 June 2026, when IEC/IEEE 60802 Edition 1.0 was published as a dual-logo IEC and IEEE standard. The waiting is over, and the awkward part begins: a profile does not tell you what to build. It narrows the enormous IEEE 802.1 time-sensitive networking toolbox down to a defensible subset, then hands the remaining choices back to you with sharper edges. Grandmaster placement, traffic-class mapping, the configuration model, how much non-real-time traffic your network must survive, and what happens to the twelve thousand PROFINET nodes already bolted to your machines — all still yours to decide.

This post is the decision framework, not another TSN primer.

What this covers: what 60802 actually standardises, seven concrete architecture decisions the published profile now forces, how it relates to PROFINET over TSN, OPC UA FX and EtherCAT without replacing any of them, and which questions the industry has explicitly left open.

Context and Background

Time-sensitive networking is not one standard. It is roughly a dozen amendments to IEEE Std 802.1Q and its siblings — 802.1AS for time synchronisation, 802.1Qbv scheduled traffic, 802.1Qbu and 802.3br frame preemption, 802.1Qci per-stream filtering and policing, 802.1CB frame replication and elimination, 802.1Qcc configuration models, 802.1Qav credit-based shaping. Each one is optional. Each one has parameters. Two vendors can both claim “TSN support” and share almost no overlapping capability.

That combinatorial freedom is exactly why industrial deployments stalled. A machine builder cannot certify a cell against a toolbox. Profiles exist to fix this, and 802.1 has done it before: 802.1CM defines a fronthaul profile for mobile networks, and a separate profile covers aerospace onboard networks. Each one selects features, options, configurations, defaults, protocols and procedures for bridges, end stations and LANs in a specific domain.

IEC/IEEE 60802 is the industrial automation entry in that family, and it is the one the whole OT world has been waiting on. It is a joint project of IEC SC65C/WG18 and IEEE 802, which is why it carries both logos and why the automation trade organisations were in the room. Its scope statement is deliberately narrow: it selects features and configurations of bridges, end stations and LANs to build industrial automation networks. It adds no new protocol. It invents no new shaper. It is a filter and a set of defaults, plus the management surface — YANG modules — needed to configure what it selects, and a cybersecurity baseline covering secure configuration, device identity and access control.

The second half of the story is conformance. Since 2022, Avnu Alliance, the CC-Link Partner Association, ODVA, the OPC Foundation and PROFIBUS & PROFINET International have collaborated — informally branded TIACC, for TSN Industrial Automation Conformance Collaboration — on a single common conformance test plan for the profile, to be used as the base test by all participating organisations. That matters more than it sounds. It means a device certified by one body should coexist at the TSN layer with a device certified by another, even when they speak entirely different application protocols above it.

So the raw material is now on the table: a published profile, and a shared way to test against it.

The Seven Decisions IEC/IEEE 60802 Now Forces

Direct answer: IEC/IEEE 60802 is a published profile, not a protocol. It selects which IEEE 802.1 TSN features industrial bridges and end stations must implement and how they are configured. Adopting it in 2026 means making seven architecture decisions: device and feature scope, time-synchronisation topology, traffic-class and scheduling model, configuration model, netload robustness, installed-base bridging strategy, and conformance language in procurement.

Figure 1: Where the IEC/IEEE 60802 profile sits in the stack.

The profile occupies a thin but load-bearing layer. Below it, IEEE 802.3 provides the physical and MAC layers and IEEE 802.1 provides the TSN feature set. Above it, application protocols — PROFINET, OPC UA FX, CIP, EtherCAT — define what the data means and how devices discover, parameterise and exchange it. The profile itself only says which of the lower-layer options are in play, with which defaults and which management model. The shared conformance test plan hangs off the profile, and engineering tools configure the network through the CNC and CUC roles the profile references.

A profile removes options, not decisions

There is a persistent misreading of profiles that goes: “the standards body chose for me, so I can procure generically.” That is half true and dangerous in the other half.

What IEC/IEEE 60802 genuinely removes is the interoperability gamble. You no longer have to ask whether vendor A’s scheduled-traffic implementation will interpret gate control lists the same way as vendor B’s, or whether their synchronisation will converge across a mixed-vendor chain. That was the class of failure that killed multi-vendor TSN pilots between 2019 and 2024.

What it does not remove is engineering. The profile scopes the toolbox to an industrial-plausible subset and defines how the selected features must behave. It does not know your cycle time, your topology, your cable lengths, your hop count, your PLC’s jitter budget, or whether the same cable also carries a 4K inspection camera. Those are inputs only you have. The profile makes your answers portable; it does not produce them.

Three layers you are deciding across

It helps to separate the seven decisions into three bands, because they fail in different ways and on different timescales.

Procurement-band decisions — which device classes and which optional IEC/IEEE 60802 features you require — are effectively irreversible once hardware ships, because TSN features generally live in switch silicon. Today’s installed Ethernet components usually cannot be extended to TSN by a software update; the industry’s working assumption is that the standard Ethernet module of the future will simply be TSN-capable, but that future arrives one hardware refresh at a time.

Design-band decisions — synchronisation topology, traffic classes, scheduling model — are changeable but expensive, because they propagate into controller configuration, application cycle design and safety arguments.

Operations-band decisions — configuration model, netload policy, conformance acceptance testing — are the ones you will actually revisit, and the ones most teams underinvest in.

Decision 1 — Device scope and which optional features you require

The first decision is the least glamorous and the most binding: for each role in your network — bridge, end station with talker/listener behaviour, engineering workstation, gateway — what do you actually require the device to implement?

Because IEC/IEEE 60802 is a profile for industrial automation networks generically, it accommodates a range of plant realities: hard-cyclic motion control, softer cyclic I/O, alarm and diagnostic traffic, and converged IT traffic sharing the same infrastructure. Not every device in a plant needs every capability. A remote I/O block at the leaf of a tree is a talker and listener; it is not a relay and does not need bridge-side scheduling.

The practical move is to write a small device-class matrix before you talk to a vendor. Three or four rows is usually enough: backbone bridge, machine-level bridge or integrated switch, cyclic end station, non-cyclic end station. For each, decide whether you require scheduled traffic, whether you require frame preemption, whether you require per-stream filtering and policing, whether you require redundancy handling, and which time-synchronisation role it plays.

The anti-pattern here is requiring everything everywhere. Frame preemption on a 1 Gbit/s link between two bridges buys you far less than it does on a 100 Mbit/s link where a single maximum-size interfering frame costs about 120 microseconds of transmission time. Requiring it universally inflates cost with no payoff, and narrows your vendor list for no architectural reason.

Decision 2 — Time synchronisation topology and redundancy

Everything deterministic in TSN is downstream of time. Get this wrong and no amount of scheduling saves you.

Figure 2: Separating the working clock from global wall-clock time, with a redundant working-clock domain.

The industrial profile work has consistently distinguished two different reasons a machine needs time. The working clock is the shared timebase that schedules actually run on — it must be tight, but it does not need to be correct in the wall-clock sense. The global clock is traceable wall-clock time, used for logging, alarms, correlation with MES and historian records, and forensic reconstruction. Requirements analysis in the 60802 project has treated working-clock deviation between a node and the grandmaster as a sub-microsecond budget, with global time a much looser requirement.

This separation drives three sub-decisions.

Where the grandmaster lives. In a machine-centric design the working-clock grandmaster is usually inside the machine — often the controller — so that the machine remains autonomous if the plant network is cut. In a line-centric design it sits at the line controller. Putting the working clock on a plant-wide IT time source is almost always wrong: you have made your motion control dependent on an IT-managed device with an IT change window.

How many domains you run. gPTP supports multiple domains over the same physical network. Running a working-clock domain and a separate global-time domain is common and cheap. Running a second working-clock domain with an independent grandmaster is the redundancy story: because both domains are synchronised continuously, a grandmaster failure does not require a re-election before time is available again. The alternative — relying on the Best Master Clock Algorithm to discover the failure and elect a replacement — leaves the network without a reference for the duration of the election, which is precisely the window a motion application cannot tolerate. The IEEE 802.1ASdm amendment exists to provide hot standby without BMCA for this reason.

How deep your tree is. Synchronisation error accumulates hop by hop through residence-time and link-delay measurement error. A significant fraction of the 60802 project’s simulation work was devoted to exactly this: error generation over long chains, timestamp granularity, and mean link delay averaging algorithms. The architectural consequence is simple and unpopular — the daisy chains that industrial Ethernet made normal are the enemy of a tight synchronisation budget. If your working clock needs to hold sub-microsecond accuracy at the last node, count your hops early and be prepared to go to a star or a shallower tree.

IEC/IEEE 60802 Decisions 3 to 5: Scheduling, Configuration and Netload

Three decisions determine whether the network behaves deterministically under load, who is allowed to change it, and what happens when something misbehaves. These are where most brownfield projects go wrong, and where the profile’s defaults help most.

Decision 3 — Traffic classes and the scheduling model

TSN gives you several ways to protect latency-critical traffic, and they are not alternatives so much as tools for different traffic shapes.

Scheduled traffic (802.1Qbv) uses a time-based gate control list per egress queue. Frames in a protected class transmit only inside their window. This delivers the tightest bounds and is the right answer for isochronous motion. It is also the most operationally demanding: every bridge on the path needs a consistent schedule, and the schedule is a function of topology, so a topology change invalidates it.

Frame preemption (802.1Qbu with 802.3br) lets an express frame interrupt a preemptable one mid-transmission, cutting the interference cost of a long best-effort frame to a fragment. It is cheaper to operate than scheduling — no global schedule, no topology coupling — and it is the disproportionately valuable tool on slower links.

Credit-based shaping (802.1Qav) bounds bandwidth for a class without needing a schedule, which suits cyclic-but-not-isochronous traffic.

Strict priority alone still works for traffic that only needs to be ahead of best-effort, and most plants have more of that traffic than they admit.

The architectural decision is not “which one” but how many classes and what maps into them. Concretely, you are deciding a priority-to-traffic-class mapping that must be identical on every bridge and every end station in the domain, and you are deciding which classes get which treatment. A workable starting split for a converged cell built on IEC/IEEE 60802 is: one isochronous class under scheduled traffic, one cyclic class under credit-based shaping or strict priority with preemption, one class for alarms and acyclic configuration traffic, and best-effort for everything else including the IT traffic you are converging.

The mistake to avoid is a proliferation of classes. Every additional protected class consumes queue resources that industrial bridge silicon has in limited supply, complicates the schedule computation, and multiplies the acceptance tests you have to run. If you cannot state in one sentence what distinguishes class 4 from class 5 and why an application would choose one, you do not need both.

There is a second-order trap here that catches teams migrating from a legacy protocol. Existing industrial Ethernet systems have their own implicit priority conventions. When you map them into a 60802 class scheme, you are also deciding what happens to that legacy traffic when the network is congested — and “the same as before” is usually not available.

Decision 4 — Configuration model: who computes the schedule

Figure 3: The centralised configuration flow — end stations declare requirements to the CUC, which requests streams from the CNC, which computes and pushes bridge configuration.

IEEE Std 802.1Qcc introduced three configuration models, and the profile work has concentrated on the division of responsibility between a Centralized User Configuration component and a Centralized Network Configuration component.

In the fully distributed model, end stations announce their requirements into the network and bridges resolve resources hop by hop. It has no central point of failure and no engineering tool dependency. It also cannot compute a globally optimal time-based schedule, because no single entity has the whole topology.

In the centralised network / distributed user model, end stations still advertise their own requirements, but a CNC holds the network view and configures the bridges.

In the fully centralised model, a CUC gathers application requirements from end stations, hands stream requests to the CNC, and the CNC computes paths and schedules and writes configuration into the bridges — in practice through YANG models carried over a protocol such as NETCONF. The CNC is the component that actually configures scheduled traffic gates, credit-based shaping, preemption, per-stream filtering and policing, and redundancy.

The decision is genuinely architectural, and it is not primarily technical. It is a question of who owns the running configuration of your plant network, and therefore who is on the hook at 3 a.m. IEC/IEEE 60802 constrains the mechanisms; it does not assign the ownership.

A fully centralised model gives you the tightest determinism and a single, auditable source of truth. It also means the engineering tool is now production infrastructure. If the CNC is an application on an engineering laptop, your plant network has a single point of failure with a screensaver. If it is a redundant service under IT management, you have just given IT a change-control veto over machine behaviour — which may be correct, and may be organisationally impossible.

A pragmatic middle path that several vendors have converged on is a hierarchical arrangement: a machine-local CUC and CNC that own the machine’s internal schedule, subordinate to a plant-level entity that owns the backbone and the inter-machine streams. This preserves machine autonomy — the machine still boots and runs with its line connection down — while allowing the line to be engineered as a whole. Hierarchical CUC/CNC management models were explored in the IEC/IEEE 60802 project precisely because flat centralisation does not match how plants are actually owned and commissioned.

Whichever model you pick, decide early, because the model determines which management interfaces you must demand from every device in Decision 1. A device that only supports a proprietary configuration channel cannot participate in a model-driven CNC workflow, no matter what its datasheet says about TSN.

Decision 5 — Netload and robustness

This is the decision nobody makes explicitly and everybody lives with.

The entire value proposition of converged industrial networking is that one infrastructure carries control traffic and everything else — vision, diagnostics, firmware updates, remote access, historian feeds. The moment you accept that, you have accepted that the network will regularly be subjected to traffic no one designed for.

The question the architecture has to answer is: what load, and what misbehaviour, must the network absorb while control traffic still meets its deadline? You are specifying a robustness envelope. Concretely that means deciding:

• The sustained and burst best-effort load the design is validated against, expressed as a percentage of link capacity on the most loaded link, not as a hand-wave.
• What happens to a stream that exceeds its declared rate. Per-stream filtering and policing (802.1Qci) exists exactly to drop or throttle a misbehaving talker at ingress before it can consume the schedule budget of a downstream bridge. Deciding to enable it is deciding that a broken device degrades itself rather than the cell.
• What happens on link failure, and whether recovery is by redundancy (802.1CB frame replication and elimination, which sends duplicates over disjoint paths and eliminates them at the merge point) or by reconvergence (a spanning-tree variant or a ring protocol, which costs time).
• What a device does when it has lost synchronisation. This is the most commonly skipped case. A node whose working clock has drifted out of tolerance should not keep transmitting into its scheduled window as though nothing happened.

Frame replication deserves a specific warning. FRER gives seamless redundancy with zero failover time, which is intoxicating for safety-adjacent applications. It also doubles the traffic on the protected streams, requires genuinely disjoint paths to be worth anything, and needs sequence recovery state in the merge devices. Applying it to every cyclic stream because it is available is a good way to spend your bandwidth budget on a failure mode you could have handled with a ring.

IEC/IEEE 60802 Decisions 6 and 7: The Installed Base and the Contract

Decision 6 — What you do with the equipment you already own

This is the live industry debate, and it is worth being blunt about it. The TSN/A Conference in September 2026 scheduled a session titled “PROFINET on TSN: shifting to IEC/IEEE 60802 while preserving the installed base.” That title is the whole problem statement. The direction of travel for PROFINET is to use IEC/IEEE 60802 mechanisms for network communication, and simultaneously to demonstrate that existing PROFINET devices can still be integrated and operated in that environment.

Figure 4: Brownfield migration paths — the answer depends on whether bridges, devices, or neither can be replaced in this capital cycle.

There are four realistic strategies, and most plants will use all four in different cells.

Bridges first. Replace the infrastructure with 60802-capable bridges while the end devices stay as they are. The devices keep speaking their existing protocol; the network gains the ability to protect and converge traffic. This is the highest-leverage move because infrastructure has a longer life than you think and because TSN capability is a silicon property you cannot retrofit. It is also the move that most often fits an existing capital plan, since switches are refreshed on a different cycle than machines.

Islands behind gateways. Leave a cell exactly as it is and connect it to the 60802 backbone through a gateway that presents the cell’s traffic as one or more streams. This is explicitly the EtherCAT Technology Group’s framing: EtherCAT itself stays unchanged, and TSN is an extension that allows EtherCAT segments to be addressed through heterogeneous TSN networks. On the EtherCAT side this can be done with an upgrade at the MainDevice and no change to subordinate devices, plus a moderate extension in the bridges connecting the segments. The ETG’s TSN working group maintains a formal liaison with the 60802 joint working group, so this is a coordinated position rather than a workaround.

Native cells. Greenfield machines, or machines whose controller and I/O are being replaced anyway, get 60802-conformant end stations from the start. This is where you get the full benefit and where you should concentrate your first deployments, because it is also where a failure is cheapest to diagnose.

Mapped legacy traffic. Where neither bridges nor devices can change, the legacy traffic rides the new backbone in a mapped traffic class, treated as one more traffic type with a defined envelope. It gets no new determinism, but it stops being a reason not to converge.

The sequencing advice that falls out of this: do not start with your hardest cell. Start with the cell where a native deployment is possible, build the operational muscle — schedule computation, acceptance testing, diagnostics — and only then attack the brownfield cases where you will be debugging across a protocol boundary.

Decision 7 — Conformance and what you put in the purchase order

The final decision is the one with the highest return on the least effort: what your specification actually says.

“Must support TSN” is worthless. It was worthless before IEC/IEEE 60802 existed and it is worthless now. So, only slightly less so, is “must support IEC/IEEE 60802” without qualification, because the profile spans device roles and optional capabilities.

Useful procurement language names four things:

1. The device role and the required feature set from your Decision 1 matrix, feature by feature, with the profile as the normative reference for how each feature behaves.
2. Conformance evidence. The shared conformance test plan developed under the TIACC collaboration is intended to be the common base test used by Avnu Alliance, the CC-Link Partner Association, ODVA, the OPC Foundation and PROFIBUS & PROFINET International, and made available to the wider ecosystem. Ask which certification the device holds, from which body, against which version of the test plan, and request the report — not the logo.
3. The management interface. Name the configuration model and the required management protocol and models. A device that cannot be configured by your CNC is a device you will configure by hand forever.
4. Interoperability obligations. State that the device must coexist at the TSN layer with conformant devices from other vendors running other automation protocols. That coexistence is the explicit goal of the common test plan, and putting it in writing gives you a contractual position when it fails.

Add one more clause that costs nothing: require that the vendor document the device’s synchronisation performance characteristics and its behaviour on loss of synchronisation. You will need both for the acceptance test, and asking for them is a quick way to find out how seriously the vendor took the profile.

How IEC/IEEE 60802 Relates to PROFINET, OPC UA FX and EtherCAT

The single most common misconception about IEC/IEEE 60802 is that it replaces the industrial protocols. It does not, and it was never intended to. The profile operates at layer 2 and defines how bridges and end stations handle frames deterministically. It says nothing about device models, cyclic data exchange semantics, parameterisation, diagnostics, or engineering.

PROFINET over TSN refers to PROFINET using the 60802 profile for its layer-2 behaviour. PROFINET’s application layer — its device model, its GSDML-based engineering, its diagnostics — is unchanged. What changes is that PROFINET’s real-time requirements are met by profile-defined TSN mechanisms on common hardware rather than by PROFINET-specific switching behaviour, which is what makes convergence with other traffic on the same infrastructure possible. The open question is not whether this works but how the transition is sequenced across an installed base measured in tens of millions of nodes.

OPC UA FX sits above the profile in a slightly different way. The Field Level Communications initiative extended OPC UA down to controller-to-controller and controller-to-device communication, using OPC UA PubSub for the data plane. That PubSub traffic needs deterministic transport, and 60802 provides it. The OPC Foundation has been explicit that the profile underpins OPC UA FX, and a dedicated working group exists to keep IEC/IEEE 60802, IEEE 802.1 and OPC UA PubSub over TSN aligned. The alignment work was still an active agenda item at the TSN/A Conference in September 2026, alongside a PlugFest connecting industrial TSN endpoint prototypes — including OPC UA FX devices — through a 60802-ready network. Treat the alignment as converging rather than complete.

EtherCAT takes the most distinct position. EtherCAT’s determinism comes from its own on-the-fly processing within a segment and does not need TSN inside that segment. The ETG’s position is that EtherCAT remains unchanged and TSN is used to carry EtherCAT segments across a heterogeneous network. In an architecture sense, EtherCAT is a client of an IEC/IEEE 60802 network rather than a protocol rebuilt on top of it.

The practical consequence for an architect is liberating: the choice of application protocol and the choice of network profile are becoming separable. Our PROFINET vs EtherCAT vs OPC UA FX comparison goes deeper on that trade space, and the OPC UA over TSN reference architecture covers what the converged data plane looks like in practice.

Trade-offs, Gotchas, and What Goes Wrong

Publication is not availability. A standard published in June 2026 does not mean a full catalogue of conformant, certified silicon in September 2026. Product cycles in industrial automation run in years. Expect a period where the profile is normative, vendor claims are enthusiastic, and independently verified conformance is thin. This is the single biggest reason to write Decision 7’s language carefully.

Conformance is not interoperability. Two devices can each pass the common test plan and still fail in your network — because of a configuration model mismatch, an unfortunate priority mapping, a topology deeper than either vendor validated, or a synchronisation budget you never computed. A certification report shifts risk; it does not eliminate integration testing.

The schedule is a topology dependency you did not know you signed up for. Scheduled traffic bakes the topology into the gate control lists. Add a bridge, change a cable route, or fail over to a redundant path, and the schedule may no longer be valid. Teams accustomed to plugging a switch in at 2 a.m. to fix a problem will be surprised. Decide who is allowed to change topology, and how the schedule gets recomputed, before commissioning.

Daisy chains and hop count. Industrial Ethernet normalised long line topologies because it was cheap. Synchronisation error and worst-case latency both accumulate per hop. The profile does not repeal physics.

Silicon, not software. Existing Ethernet infrastructure generally cannot be upgraded to TSN by firmware. Any migration plan that assumes a software path for installed switches is a plan that will be rewritten.

Diagnostics maturity. When a schedule is wrong, the symptom is a machine that occasionally misses a cycle. Finding that with conventional tooling is hard. Budget for TSN-aware diagnostic capability in your Decision 1 matrix — the ability to read gate control lists, per-queue counters and synchronisation status from the bridge — or you will be debugging determinism with a link light.

What remains unsettled. Be honest with stakeholders about the open items: the installed-base migration path is an active industry debate rather than a settled recipe; OPC UA FX alignment work is ongoing; certification programme rollout across the participating bodies is in progress; and hierarchical CUC/CNC ownership is a design pattern, not a standardised architecture. None of this is a reason to wait. All of it is a reason to build an escape hatch into your first deployment.

Practical Recommendations

Start by writing the device-class matrix. It is a one-page artefact and it forces every other decision into the open. Then compute your synchronisation budget by hand for your worst-case path before you commit to a topology — hop count is the variable you can still change cheaply at design time and cannot change at all after the cable trays go in.

Pick the configuration model based on organisational reality rather than technical elegance. If your plant has no one who will own a CNC as production infrastructure, a fully centralised model will decay into a spreadsheet within a year. A machine-local centralised model subordinate to a plant backbone is usually the honest answer.

Deploy natively where you can, gateway where you cannot, and resist the temptation to make your first IEC/IEEE 60802 network the one carrying your most valuable process.

A checklist to run before you sign anything:

• [ ] Device-class matrix written, with required features per role.
• [ ] Working-clock and global-time domains separated; grandmaster placement decided; redundancy approach chosen.
• [ ] Worst-case hop count and synchronisation budget computed for the deepest path.
• [ ] Priority-to-traffic-class mapping defined once, plant-wide, in a document with a version number.
• [ ] Configuration model chosen and an owner named for the running configuration.
• [ ] Netload envelope specified numerically; ingress policing decision made; loss-of-sync behaviour specified.
• [ ] Migration path chosen per cell, with a first deployment that is native rather than brownfield.
• [ ] Procurement language naming role, features, conformance evidence, management interface and interoperability obligation.
• [ ] Acceptance test plan that includes multi-vendor coexistence and behaviour under your specified netload.

Frequently Asked Questions

Is IEC/IEEE 60802 a new protocol?

No. It is a profile. It selects features, options, configurations, defaults, protocols and procedures from the existing IEEE 802.1 and 802.3 standards for bridges, end stations and LANs used in industrial automation, and specifies how the selected features must be configured and managed. No new frame format, no new shaper, no new synchronisation protocol. Its value is in narrowing an enormous option space to a subset that multiple vendors can implement compatibly, plus the management models and cybersecurity baseline needed to operate that subset.

When was IEC/IEEE 60802 published?

Edition 1.0 was published on 29 June 2026 as a dual-logo standard of the IEC and IEEE, developed jointly by IEC SC65C/WG18 and IEEE 802. It is available from the IEC webstore and the IEEE Standards Association. The project ran through multiple draft cycles from 2018 onward, with the FDIS ballot draft circulating in March 2026. Publication makes the profile normative and citable in procurement, which is the main practical change for architects.

Does IEC/IEEE 60802 replace PROFINET or EtherCAT?

No. It operates at layer 2 and says nothing about application-layer device models, cyclic exchange semantics or engineering tooling. PROFINET over TSN means PROFINET using 60802 mechanisms underneath an unchanged application layer. EtherCAT’s position is that EtherCAT segments stay unchanged and TSN carries them across a heterogeneous network. OPC UA FX uses the profile as deterministic transport for OPC UA PubSub. The profile makes network choice and protocol choice more separable, not interchangeable.

How do I know a device really conforms to the profile?

Ask for the certification report, the certifying organisation, and the test plan version. Avnu Alliance, the CC-Link Partner Association, ODVA, the OPC Foundation and PROFIBUS & PROFINET International have collaborated on a single common conformance test plan intended as the shared base test across all of them, so that conformant devices running different automation protocols coexist at the TSN layer. A vendor claim of “60802 support” with no named certification and no report should be treated as a statement of intent.

Can I upgrade my existing switches to TSN?

Usually not. TSN features such as scheduled traffic gates and frame preemption are implemented in switch silicon, and installed Ethernet components generally cannot be extended to TSN by software. Plan for infrastructure replacement on a hardware refresh cycle. The consolation is that bridges-first migration is often the most practical opening move: new infrastructure plus existing end devices gives you the converged backbone without touching the machines.

Do I need a CNC to run an IEC/IEEE 60802 network?

It depends on the configuration model you choose. A fully distributed model needs no central component but cannot compute a globally optimal time-based schedule. Scheduled traffic in practice pushes you toward a centralised network configuration component that computes paths and schedules and writes bridge configuration through YANG models over a protocol such as NETCONF. If you need isochronous determinism, budget for a CNC as production infrastructure with a named owner — not as a tool on an engineering laptop.

Further Reading

• PROFINET vs EtherCAT vs OPC UA FX + TSN: the 2026 deterministic Ethernet decision — the protocol-layer trade space that sits above this profile.
• TSN and IEEE 802.1Q: a time-sensitive networking architecture guide — mechanism-level explanation of the shapers and synchronisation the profile selects from.
• OPC UA over TSN deterministic IIoT reference architecture — what a converged OPC UA data plane looks like end to end.
• Time-sensitive networking industrial reference architecture — plant-level topology patterns and where TSN domains begin and end.
• IEC/IEEE 60802 project page, IEEE 802.1 TSN Task Group — scope, status and the full draft and presentation archive.
• IEC/IEEE 60802:2026, IEC Webstore — the published standard.

By Riju — about