“OPC UA over TSN能实现微秒级确定性通信。”这句话在方案书里很常见，但它缺了一个关键限定：确定性是相对于截止时间来定义的，不是绝对的。

一篇2026年的论文用可复现的负载感知基准，对Modbus TCP、OPC UA PubSub over TSN和EtherCAT做了对比测试，覆盖从250微秒同步伺服控制到1秒状态监测的五种负载。

结果值得逐条拆开看。

EtherCAT在所有负载下都是100%准时，抖动在亚微秒量级。 这是它的协议机制决定的——帧遍历从站、就地处理，不经过存储转发，确定性来自物理层和协议层的耦合设计。

OPC UA PubSub over TSN在截止时间≥1毫秒时，准时率达到99.87%以上。 这个数字对绝大多数产线协同、单元级控制已经足够。

但截止时间压到250微秒时，准时率掉到75.3%。 这意味着每四个周期就有一个周期错过了截止时间。对于同步伺服控制这类要求每个周期都不能错过的场景，75.3%的准时率在工程上等于不可用。

Modbus TCP在2毫秒以下不可用，10毫秒以上可以达到99.8%。 这符合它的设计定位——简单、开放、适合慢速遥测和状态采集，但不适合任何有硬截止时间的控制回路。

这组数据指向的结论不是“哪个协议更好”，而是工厂网络里不同流量的时间要求相差三个数量级以上，不存在一个协议在所有层级都最优。论文给出的建议是分层架构：EtherCAT用于运动控制，OPC UA PubSub over TSN作为单元到企业的骨干，Modbus TCP留给传统慢速遥测。

为什么OPC UA PubSub over TSN会在250微秒处“碎掉”？

TSN的确定性依赖三层协同：gPTP做全网时钟对齐到亚微秒，802.1Qbv做时间感知门控预留时隙，OPC UA PubSub做实时发布订阅。缺任何一层，确定性都不成立。

但还有一个前提条件经常被忽略：终端必须支持硬件时间戳和Qbv调度。 如果终端不支持，交换机上的调度配置无法生效，网络会退化回“尽力而为”模式，跟普通工业以太网没有本质区别。

OPC UA PubSub over TSN的确定性还受到TSN跳数的影响。论文的敏感性分析显示，随着跳数增加，OPC UA PubSub的确定性会退化。250微秒这个刻度上，每多一跳，时隙对齐的余量就被侵蚀一次，直到准时率跌破可用阈值。

这对做方案选型的人意味着什么？

如果你的控制回路截止时间是毫秒级——比如产线协同、视觉引导的节拍控制、单元级的状态同步——OPC UA PubSub over TSN在1毫秒以上的截止时间上表现是可靠的，而且它带来的是厂商无关的开放架构和统一信息模型。

如果你的控制回路截止时间是250微秒级——比如多轴同步伺服、高速贴装、精密运动控制——目前经过实测验证的协议仍然是EtherCAT和Profinet IRT这类为硬实时设计的现场总线。用OPC UA PubSub over TSN去覆盖这个层级，是在用架构的开放性/交换确定性的余量，而这个交换在250微秒上并不划算。

最后说一句。

OPC UA over TSN的长期方向是对的。标准与试点已经成熟，在半导体、多厂商强实时协同等场景有明确的落地价值。但“长期替代Profinet”和“现在能覆盖250微秒控制回路”是两件事。存量设备和工程习惯决定了它在可见的未来是分层共存，不是全面替代。

方案书里写“确定性”的时候，把截止时间刻度标上去。没有刻度的确定性，在验收的时候一文不值。

平时我也写写代码，维护两个开源项目：

ProtoForge（工业协议仿真平台，28种协议，130+设备模板）： GitHub：suoten/ProtoForge Gitee：suoten/ProtoForge

EdgeLiteGateway（AI物联网关，13种协议采集，边缘AI推理）： GitHub：suoten/EdgeLiteGateway Gitee：suoten/EdgeLiteGateway