TSN会干掉PROFINET和EtherNet/IP吗？

似乎每隔一段时间，工业网络圈子里就会出现一轮"XXX将被替代"的讨论。

前些年是"工业以太网会干掉现场总线"，现在是"TSN可能会干掉PROFINET和EtherNet/IP"。

这类讨论的规律很一致：新技术发布，白皮书铺天盖地，大厂站台背书，论坛热议。

前几天跑现场，就碰到有个客户提了一嘴，说到TSN的替代性。TSN这件事，值得认真分析——它不是炒作，但"替代PROFINET/EtherNet/IP"这个说法，把问题严重简化了。

一、先搞清楚这三个东西各自是啥

很多人一上来就讨论"谁替代谁"，但连这三个技术分别解决什么问题都没搞清楚。这不就是讨论跑偏的根本原因。

PROFINET 是什么？

PROFINET 是西门子主导、PI（PROFIBUS & PROFINET International）组织维护的工业以太网协议，覆盖从现场层到控制层的完整通信体系。它不只是一个传输协议，而是一套包含设备模型、参数化、诊断、拓扑发现、时钟同步在内的完整应用框架。

PROFINET 按实时性分三个等级：

• TCP/IP通道（NRT）：非实时，用于参数配置和非周期通信
• RT（实时）：周期通信，典型刷新周期1~10ms，满足大多数运动控制需求
• IRT（同步实时）：基于硬件时间槽，抖动μs，用于高精度多轴同步

EtherNet/IP 是什么？

EtherNet/IP 是罗克韦尔和ODVA组织维护的工业以太网协议，基于标准TCP/IP和UDP/IP，使用CIP（通用工业协议）作为应用层。EtherNet/IP 更"标准以太网友好"，设备和IT网络的集成相对容易，在北美市场占有率高。

TSN 是什么？

这是最容易被误解的一点。

TSN（时间敏感网络）不是一个工业通信协议，它是一组IEEE以太网标准的集合。

TSN解决的问题是：让标准以太网具备确定性时延能力。它不定义设备模型、不定义参数化方式、不定义诊断机制——它只管"怎么保证这个数据包在确定的时间窗口内被传输"。

核心标准包括：

• IEEE 802.1AS：全网时钟同步，目标精度μs
• IEEE 802.1Qbv：时间感知整形（TAS），给不同流量分配时间槽
• IEEE 802.1Qbu / 802.3br：帧抢占，让高优先级帧可以打断低优先级帧的传输
• IEEE 802.1CB：帧复制与消除，提供冗余路径的无缝切换

用一个比喻：TSN是道路基础设施（限速、红绿灯、专用车道），PROFINET和EtherNet/IP是跑在路上的运输规则和货物标准。

二、为什么会有TSN替代的说法

这个说法的来源，是TSN解决了工业以太网一个长期存在的痛点。

传统工业以太网（包括PROFINET RT和EtherNet/IP）实现确定性传输的方式，是"绕开标准以太网的竞争机制"——用私有的调度算法、专用芯片、或者时分复用来保证实时性。

这带来了两个代价：

• 互操作性差：PROFINET的实时通道和EtherNet/IP的实时通道互不兼容，用了谁家的协议就被绑定在谁家的生态里
• IT/OT融合困难：工业实时流量和普通IT流量跑在同一个网络上，会互相干扰，所以OT网络通常要物理隔离，增加了部署成本

TSN的出现，理论上可以解决这两个问题：

• 因为TSN是IEEE标准，基于标准以太网芯片，不同厂商的TSN设备理论上可以互操作
• 因为TSN用时间槽隔离不同流量，实时工业流量和普通IT流量可以安全地跑在同一张网上

所以有人得出结论：既然TSN提供了确定性传输的通用底层，PROFINET和EtherNet/IP各自的私有实时机制就没有存在的必要了，TSN自然会替代它们。

这个逻辑，有一半是对的，有一半是错的。

三、对的那一半：TSN确实在重构底层

PROFINET和EtherNet/IP的主要厂商，已经在把TSN作为下一代协议的传输层基础。

西门子和PI组织推进的是 PROFINET over TSN，用TSN替换PROFINET IRT原有的私有同步实时机制，同时保留PROFINET的设备模型、参数化、诊断等上层应用框架。

罗克韦尔和ODVA推进的是 EtherNet/IP with CIP Sync over TSN，同样是用TSN做底层传输，保留CIP的上层逻辑。

OPC基金会推进的是 OPC UA over TSN（也叫OPC UA FX），在TSN上跑OPC UA的发布/订阅机制，打通现场层和云端的数据通路。

这意味着：在底层传输机制上，TSN确实在逐步取代各家私有的实时以太网方案。从这个角度说，"TSN替代了PROFINET IRT的底层"是准确的。

四、错的那一半：上层应用框架不会消失

TSN只管传输层，管不了上面的事。

一台西门子的分布式IO设备，除了需要实时传输数据，还需要：

• 设备发现和地址分配（DCP协议）
• 参数化和配置（PROFINET的AR/CR机制）
• 诊断和报警上报（AlarmCR通道）
• 拓扑识别（LLDP扩展）
• 功能安全（PROFIsafe）

这些都是PROFINET应用层定义的内容，和底层用不用TSN无关。就算底层换成了TSN，这些上层机制依然存在，依然需要工程师去配置和维护。

EtherNet/IP也是同样的逻辑。CIP定义了对象模型、连接管理、数据类型、设备行规……这些是EtherNet/IP的核心价值所在，和传输层是不是TSN没有直接关系。

所以更准确的说法是：

TSN不会替代PROFINET和EtherNet/IP，而是成为它们下一代版本的传输基础。就像高速公路升级了，但货运规则、托运合同、装卸标准并没有因此消失。

五、真正的竞争：不是协议之争，而是生态之争

如果TSN成为通用底层，那么理论上PROFINET设备和EtherNet/IP设备可以跑在同一张TSN网络上，互操作性大幅提升。

这听起来是好事，但它同时意味着：各家协议原本依靠私有实时机制构建的生态护城河，会被削弱。

过去，你的工厂用了西门子PLC，就几乎必须用PROFINET，因为只有PROFINET IRT才能和西门子控制器做高精度同步。换协议意味着换整套生态，迁移成本极高。

如果PROFINET over TSN和EtherNet/IP over TSN都跑在标准TSN网络上，未来的竞争就不再是"谁的实时性更好"，而是"谁的工程工具更好用、谁的设备生态更丰富、谁的功能安全更完善"。

这对新进入工业网络市场的厂商是一个机会窗口。当底层传输标准化之后，专注于某一层做深做透，反而可能切入市场。

比如工业网络设备领域，国内有厂商如三旺通信，在工业交换机和网关产品上持续跟进TSN标准演进，提供支持IEEE 802.1AS时钟同步的工业交换机产品线，帮助工厂在现有网络基础上逐步引入TSN能力，而不需要一次性推倒重来。这种渐进式TSN就绪的思路，在当前TSN设备生态还不完整的过渡期，比全面换新更有实操价值。

六、落地现实：TSN现在能用吗

说了这么多理论，回到最实际的问题：现在，我的工厂能上TSN吗？

可以开始评估和试点，但不建议大规模押注。

当前TSN落地面临几个现实问题：

问题一：设备生态还不完整

支持TSN的终端设备（传感器、驱动器、IO模块）数量仍然有限。一张TSN网络，如果大多数终端设备不支持TSN，那TSN的价值就大打折扣。现阶段真正能做到全链路TSN的工厂，基本都是新建的标杆项目，有大厂背书和补贴支撑。

问题二：互操作性还在验证中

TSN标准是通用的，但不同厂商的TSN实现是否真正互操作，还需要通过测试认证来证明。目前IEEE和IIC（工业互联网联盟）在推进TSN互操作测试，但覆盖的场景和设备组合还不够全面。

问题三：工程工具链不成熟

PROFINET有STEP 7/TIA Portal做配置，EtherNet/IP有Studio 5000。TSN网络的配置和调度规划，目前还没有被广泛采用的统一工具。网络管理员需要手动规划时间槽和流量调度，这对运维人员的技术要求很高。

问题四：存量设备的迁移成本

工厂里跑了十年的PROFINET IRT设备，不会因为TSN出现就立刻换掉。过渡期可能长达十年以上。这意味着工业网络工程师需要同时维护TSN和非TSN设备共存的混合网络，复杂度反而上升。

七、不同工厂的应对策略

根据工厂的实际情况，策略应该有所不同：

a.新建工厂 / 新建产线

有条件的话，基础设施层面可以按TSN就绪的方向规划，选择支持802.1AS时钟同步的工业交换机，预留TSN配置能力。上层应用协议仍然按业务需求选PROFINET或EtherNet/IP，等待设备生态成熟后平滑升级。

b.现有工厂改造

不建议为了TSN大规模换网络基础设施。优先梳理哪些场景对确定性时延有强需求，哪些场景用现有协议已经够用。对于强需求场景，可以考虑局部试点TSN，其余保持现状。

设备选型

新采购的工业交换机和网关，可以优先考虑支持TSN关键标准的产品，即使当前不需要启用TSN功能，也为未来留下升级路径。这比等TSN完全成熟后再全部替换，成本要低很多。

总结

TSN和PROFINET/EtherNet/IP，不是替代关系，是分层共存、底层融合的关系。

TSN解决的是如何在标准以太网上实现确定性传输，PROFINET和EtherNet/IP解决的是如何在工业现场组织设备通信、配置、诊断的完整体系。两者在不同层面工作，未来的方向是TSN成为两者共同的传输基础，而不是TSN取而代之。

对工厂工程师来说，现在最务实的动作不是"要不要换TSN"，而是"新采购的设备和基础设施，是否为TSN留了升级路径"。

等等看，不是消极的应对，而是在一个生态还未完全成熟的技术周期里，最理性的决策方式。