TSN 概述与发展背景

1.1 时间敏感网络的起源

说实话，我刚入行做工业通信那会儿，大家还都指着传统以太网过日子。交换机能跑、延迟能接受，就够了。直到有一次，我在一条汽车焊装线上调试视觉定位系统——工业相机每拍一张照片，要等20毫秒甚至更久才能收到机器人应答。生产线一快起来，直接撞车。客户拍桌子说：“这什么破网络？”

那时候我们才发现，传统以太网天生就有两个硬伤：延迟不确定和时钟不同步。你想想看，一个交换机里存着队列，先到的包先走，遇到突发流量就得排队。运气好时延1毫秒，运气不好50毫秒。这在普通办公网里无所谓，但在工业运动控制、车载网络里，差1毫秒可能就废掉一个零件。

TSN（时间敏感网络）就是为了解决这个问题才诞生的。说白了，它就是在标准以太网上加了一套“交通管制系统”。给高优先级的流量开辟专用车道，再让所有设备对同一个时钟，保证数据在规定时间内到达。这听起来简单，背后的技术细节却不少。

我建议你记住TSN的三大核心能力：时间同步、时间感知调度和可靠性保障。后面每个章节都会跟这三样东西打交道。

1.2 工业互联网的核心需求

你可能要问：为什么非得用TSN？传统以太网加上一些工业协议不也能对付吗？嗯，这个问题我在2016年一个自动化展会上也跟同行争论过。现实是，工业互联网正在把以前各自独立的网络——现场总线、伺服驱动、视觉系统、云端调度——全部揉进一张以太网里。这张网要同时跑三类数据：

• 周期性控制数据：比如运动控制指令，每100微秒发一次，必须准时到，不能丢。
• 非周期性事件数据：比如报警、故障信号，可以稍微延迟，但不能堵死。
• 后台配置/诊断数据：比如固件升级、日志上传，带宽大、实时性要求低。

传统交换机会让这三种数据混在一起抢带宽。结果就是：控制指令被大文件传输堵在路上，设备“断气”。

我自己做过一个测试：在100台设备的产线上，用标准工业交换机跑EtherCAT，丢包率只有0.01%——看起来还行。但一旦加入视频流和云端数据汇聚，丢包率就跳到0.5%，直接影响机器人同步。用了TSN交换机之后，在同等负载下，控制流延迟抖动从±500微秒降到±5微秒。差距就在这里。

1.3 TSN标准化进程

TSN不是某家公司闭门造车搞出来的。它源于IEEE 802.1工作组在2012年前后启动的TSN任务组（最初叫AVB——音视频桥接）。我记得2015年参加IEEE 802.1 interim会议时，整个房间也就三十多人，大家围着一张白板争论队列模型。如今TSN标准已经发展到30多个子项了。

下面这个表格列出了TSN的核心标准家族，都是后续章节反复提到的内容：

标准化进程有几个关键里程碑：

• 2012年： AVB任务组正式更名为TSN任务组，将研究范围从音视频扩展到工业、汽车、航空航天。
• 2015-2018年： 核心标准（802.1AS-2020、802.1Qbv-2015等）陆续发布，第一批商用TSN芯片出现。
• 2020年： IEEE 802.1Qcz（链路聚合）等后续标准发布，TSN可用性进一步提升。
• 2023年至今： 国际标准组织如IEC（IEC 61158、IEC 62439）和工业联盟（如OPC UA、PROFINET、EtherCAT）纷纷将TSN作为底层传输基础。

为什么要关注标准化？因为在做一致性验证时，我们要保证设备跟标准一个字都不能差。我记得有一次测试一款交换机的802.1AS实现，它宣称支持，但我在抓包中发现它的Pdelay_Resp间隔始终比标准要求多了20个时钟周期。这种偏差在单设备上几乎不可察觉，但上百台设备级联后，时钟同步误差会累积到微秒级。所以一致性验证就是要揪出这种“差不多先生”。

下面这张图帮你理清TSN标准家族的主要脉络和它们之间的关系：

好，这一章我们梳理了TSN从哪里来、为什么要用、以及标准化做了哪些事。我个人一直觉得，理解背景比死记标准编号更重要。下回你在产线或实验室里遇到TSN设备，可以先问自己三个问题：它支持时间同步吗？它用什么整形策略？它的冗余方案是什么？带着这三个问题，后面的课你会听得更明白。