来源：TSNLAB 微信公众号
去年夏天在上海，和一位自动化专家聊了一下午，TSN究竟有什么用，最终，对方用自己的方式总结出一句话，反而一语点醒我们做网络的人——“有了TSN，UDP也能保障确定性！”
和一些工控企业、相关院所的专家和工程师交流，聊到如何构建我们自主可控的工业网络方案的时候，最终常常会倾向于做一套端到端的“私有方案”。可能背后有两点，虽然大家很少直接提及，但很大程度上影响了上面的决策：
1、传统的ETH、IP、UDP/TCP网络没有确定性，无法普遍用于工控场景。
2、行业里的老大哥们是怎么干的呢？总线或者工业以太啊！那我们自然要做一套新的总线或者工业以太啊！
再看ICT，如果说CT就是基础设施，那么IT应用，涉及互联网通信的话，大部分都是基于UDP或TCP的。如果“有了TSN，UDP也能保障确定性！”之后，OT领域也可以基于UDP等通用协议栈自由开发应用，不需要再受限于私有硬件、需购买软件授权等，同时网络确定性性能还优于EtherCAT、PROFINET IRT（后面会讲）。那么，Why not？
因此，我们提出通用确定性方案，其愿景就是让用户、供应商可以基于通用算力和软硬件（含Ethernet TSN网络）来研发设备、开发应用、构建方案。同时，通用确定性的命名，也是为了打破“确定性要求越高，越需要封闭专用方案”的一般性认识。
通用确定性方案的任务自然也就明确了。举例说明，当下做一个APP，在通信的部分基于UDP开发，不论是软件接口还是案例参考，都是丰富且成熟的。那么，距离“有了TSN，UDP也能保障确定性！”还缺少什么？
•工作任务1、性能验证：讲道理谁都可以，TSN的道理也讲了很多年，但基于通用软硬件（含TSN）的应用，究竟能达到怎样的确定性性能指标？对比EtherCAT、PROFINET IRT这些工控领域用于运动控制的高精尖工业以太技术又如何？
•工作任务2、开发方案：TSN看起来好复杂，我端侧需要怎么弄、网络需要怎么配？有没有可以一个开放的开发平台，既可以提供方案文档作为参考，也可以提供开发接口以便进行快速原型验证？
这就是我们的工作目标。并且通过这篇文章，我们隆重宣布，工作任务1已经完成了性能验证的基线测试，结果是惊人的好！
面向工业控制，通用确定性方案三大核心性能指标定义如下：
•指标1：端到端PTP时间同步精度——>影响同步控制精度——> 与时间同步软硬件能力相关
•指标2：端侧发包精度（抖动）——>影响指标3 ——> 与端侧系统实时性、网卡能力相关
•指标3：端到端确定性低时延 ——> 影响控制响应速度——> 与TSN网络方案相关
用标准Ethernet、IPv4、UDP协议栈在Linux PC上写了一个根据系统时钟周期发包的程序，模拟工控应用。上结论，如下图：
指标1，基于Linux自带的PTP能力，配合网络TSN交换机的PTP能力，从端侧系统、到网卡、到对端网卡、到对端系统，同步精度在129ns以内；
指标2，使用了Linux Preempt rt软实时、配合i210网卡，能使发包精度在98ns以内（即应用侧要求在1点整把报文发送到网络上，而网卡实际完成这件事情的时间差异不超过98ns）；
指标3，关键控制流报文的端到端时延，在有无1500Byte背景流大包的影响下无变化，如下图，注意纵坐标单位是ns。不计算链路时延（链路长度/光速）和受自身包长影响的存储转发时延（包长/链路带宽，如100Byte@1Gbps大约为1.2us）的情况下，基本上每跳3us！也就是只有固有交换机处理时延，没有排队时延。
把这样的性能代入到典型的工控场景和PROFINET IRT、EtherCAT进行对比计算，得到如下表格。计算的基本原理参考下面这篇文章，用一句话来概括，就是“同周期内多个从站的报文在PLC出口到第一跳设备的串行排队时延或主站到离它最远的那个从站的总网络传输时延成为了制约周期进一步降低的因素”。
J. Jasperneite, M. Schumacher and K. Weber, "Limits of increasing the performance of Industrial Ethernet protocols," 2007 IEEE Conference on Emerging Technologies and Factory Automation (EFTA 2007), Patras, Greece, 2007, pp. 17-24, doi: 10.1109/EFTA.2007.4416748IF: NA NA NA. keywords: {Ethernet networks;Communication industry;Automation;TCPIP;Job shop scheduling;Bit rate;Network topology;Electrical equipment industry;Media Access Protocol;Measurement},
TSN之所以在网络能力上有显著的优势，最主要的原因不是因为有什么了不得的新机制设计，而是通用开放的Ethernet带来的10倍起步的带宽优势（甚至可能还更便宜！）。
通用确定性还有四个影响性能的关键因素：
•1、算力与架构。
•2、系统与软硬实时方案。
•3、端侧网卡硬件。
•4、网络协议栈。
我们的基线测试是基于x86工控机、Linux preempt rt软实时、i210网卡、标准UDP+IPv4+Ethernet协议栈进行的。实际上当然可以用不同的排列组合。我们同时还测试了仅使用网络硬件时间戳做PTP，无定时发送功能（即网卡无“Qbv”）情况下的几个case，如下表（PTP精度同上，不受影响，故未列出）。
可见，网卡无“Qbv”时，性能会有所下降，但也仍然是很不错的水平。除此之外，其它不同的排练组合会有怎样的效果，哪些因素会成为对整体性能的主要影响因素，这里一方面能拓展出不少有价值的学术研究的课题，另一方面综合考虑成本的组合也会对未来商用方案选型提供参考。因此我们肯定希望、也呼吁产业界学术界的同仁们广泛参与到“通用确定性：基于通用软硬件做工控”的讨论中。同时我们会在ZIGGO平台上公开本文性能验证的开发方案文档和代码，给感兴趣的读者作为参考或实现快速原型验证。当然我们更加期待您使用不同的软硬件组合复现测试，把新的文档、代码与测试结果再贡献回开放平台。同期，我们正在进行组合了x86 IPC、嵌入式ARM和OpenEuler操作系统的方案测试。理想的情况是，在未来，对于常用的算力与架构、系统与软硬实时方案、端侧网卡硬件和网络协议栈的组合，都可以在开放平台上找到上述三个关键性能指标的参考数值（前述工作任务1），和开发方案的文档与代码（工作任务2）。
-----------------------------------------
ZIGGO是由清华大学杨铮教授团队研发的全栈式TSN工业网络平台，包含了交换机、流量调度管理、网络性能测试和故障诊断等功能模块。ZIGGO 全面支持TSN标准，包括 IEEE 802.1AS、Qav、Qbv、Qcc等协议，实现了网络设备间纳秒级的时间同步，为关键数据流量提供了确定性转发与超低时延传输，支持IT流量与OT流量的共网传输。ZIGGO 提供了即插即用的协议一致性评估和组网性能评估解决方案，支持对TSN网络设备进行性能分析和协议验证，包括时间同步精度分析与协议一致性分析、关键流量时延与抖动分析、Qbv门控精度与带宽保障检测等。
网址：http://tns.thss.tsinghua.edu.cn/ziggo/
-----------------------------------------
其实当前的运动控制方案中，除了EtherCAT，基本上都已经是（或下一代即将是）X over Ethernet/TSN了。例如PROFINET的ccD、CC-Link IE TSN是X over TSN，CIP Motion是X over UDP Ethernet + 1588v2，Powerlink是X（CANopen） over Ethernet，OPC UAFX是X（类似SERCOS）over TSN。那么如果要做不被卡脖子的方案，最自然的方案就是X over TSN或X over UDP TSN，这个X是CANopen等，或者自己制定，都可以。然后具体到端设备怎么做，控制器、驱动器的软硬件方案可以根据性能要求从上面四个关键因素中选取组合，同时从通用确定性开发平台上找到对应的方案文档和代码进行快速原型验证。我们提出通用确定性，最终的关键目的，是让供应商可以自由选择通用软硬件组合、并基于此开发设备应用方案，让用户能用到充分竞争市场下的、性价比和供应链都更好的通用ICT硬件，让工业软件知识更容易被兼容和复用。
-----------------------------------------
回顾一下，本文提出了通用确定性的
一个愿景：让用户、供应商可以基于通用算力和软硬件（含Ethernet TSN网络）研发设备、开发应用、构建方案。
两个工作任务：提供性能验证demo；构建开发平台，提供方案参考文档和代码。
三个核心性能指标（针对工控）：端到端PTP时间同步精度；端侧发包精度（抖动）；端到端确定性低时延。
四个影响性能的关键因素：算力与架构；系统与软硬实时方案；端侧网卡硬件；网络协议栈。