来源：TSNLAB 微信公众号
大约3、5年前，坊间流传最多的说法，是TSN（特指Qbv门控方案）编排太难。关于这件事情，在之前的文章我们也不断表达过观点，主要是早年间研究者把编排的模型建立的很精细，而后来随着研究的深入、算法的不断演进，更主要是引入了更多真实工程约束而带来了简化，所以目前带编排能力的网络控制器已经有不少了。
而近期，坊间流传更多的则变成了当前业界缺少TSN的端设备，所以TSN应用比较困难。其实这说的没错。
那么我们如果想在当前状态下尽量加速TSN的应用落地，首当其冲的问题是，TSN的端到端应用落地，一定要支持TSN的端吗？怎样的端才叫做“支持TSN”呢？
要解答这个问题，我们首先要明确，什么是TSN端到端应用？从TSN——时间敏感网络的角度来看，最核心的，就是这个TSN网络可以为关键业务提供端到端的“时间敏感”服务，即提供端到端报文传输的确定性，而确定性又包含了提供“有界时延”和“零丢包”。这里TSN技术集合里，需要用到的关键技术，一个就是时延相关的（各种调度机制），一个就是资源预留相关的（核心是使得网络可以识别关键业务，给出对应的服务）。
讲人话，什么是TSN端到端应用？网络可以：1、识别关键业务；2、给出特定的服务。具体到例如一个TSN交换机上，则为：1、交换机入口处识别关键业务，放入特定队列；2、交换机出口处保障关键业务队列有足够的受调度的资源，不会丢包，并通过优先级、门控调度等方式，保障关键报文的排队时间上限不超过其需求。而端侧用户的感知是，网络对我的关键业务的传输，满足了我的确定性要求。
那我们认为，满足这样特征的一个网络，或者说一个由端和网组成的系统，就是一个成功的TSN端到端应用。
上面对于网络需要关注的1、2两条，其实不论是IEEE 802.1的标准定义，还是学术界的研究，还是各厂商之间的竞争力宣传，更多都聚焦在第2条上。我们听到过太多关于TSN门控编排以及编排算法的探讨，关于CBS、ATS等异步整形方案的研究和实践，等等。而对于第1条，可能它更像是一个工程问题。但是，这第1条，其实是TSN端到端应用的“1”，而第二条，则是后面的“0”。没有1，后面加再多0也没有用。
因此，关于最开始的问题：TSN的端到端应用落地，一定要支持TSN的端吗？怎样的端才叫做“支持TSN”呢？我们可以转而思考为网络如何在当前端设备的状态下搞定上面提出的“识别关键业务”、“给出特定的服务”这两件事。而“给出特定的服务”其实是纯网络设备的问题，则问题进一步转化为，“如何在不引入对端侧设备的升级要求的情况下，让网络能够正确地识别关键业务”。（注：本文中的关键业务，可以是一个或多个业务，也可以是一类或多类业务。相应地，网络中也存在一个或多个、一类或多类非关键业务。）
我们按TSN的应用场景分开来看。
1、在车载网络、机载网络中，关键终端及其业务不会突然发生变化，可以提前知道关键业务有哪些、从哪儿来、到哪儿去、是什么流量特征，故允许网络静态预配置，来实现TSN。
2、在运营商网络中（包含而不限于移动前传、承载网等），其实TSN端到端应用的效果，和当初IntServ非常相像，而由于此类网络中流量的多样性和复杂性，使得问题变得比较复杂。后面可以独立写篇文章来讨论。
3、最后是受关注度比较高的工业自动化网络，这里的情况也比较复杂。当前的端设备在选择网络方案时，基本要在主流的PROFINET、EtherNet/IP、EtherCAT等工业以太网协议中选择一个或多个进行支持，而这些协议背后的生态圈，是否向TSN演进、演进的速度，是各生态圈背后的主要玩家来决定的。所以，还是在不改变、不预设端设备本身的条件下，我们可以发现有流量自学习与组态协同两种方法来解决上面的问题。
由于工业以太网协议，使用标准的Ethernet帧格式，对于多数工业以太网协议，通用的交换机或TSN交换机正常识别并转发这些工业以太网报文是没有问题的。并且用于工业控制的流量（PLC东西向：PLC-PLC；PLC南向：PLC-IO）往往具有明确的周期特征，所以，流量自学习方案的核心，就是利用网络设备的能力，识别这些关键流量，学习其特征。由此可以实现上述第1条“交换机入口处识别关键业务，放入特定队列”。同时，学习到的特征，可以上报给TSN网络控制器（例如CNC），进而帮助网络进行调度方法的编排，由此可以实现上述第2条“交换机出口处保障关键业务队列有足够的受调度的资源，不会丢包，并通过优先级、门控调度等方式，保障关键报文的排队时间上限不超过其需求”。当然，流量自学习的方法，有其约束，是一种过渡方案。
而好的方案则是组态协同。所谓组态，就是工业用户需要在自动化软件上进行的网络组态、工艺组态、PLC编程、HMI组态等一系列操作。其中，在网络组态的这一步，其实有哪些工业端设备相连，它们的地址、通信周期、通信要求（看门狗）等等信息，对于软件而言都是确定的信息（不论是用户配置的，还是使用的默认值）。每个工业以太网协议都有属于自己的自动化软件，甚至每个PLC厂商都可以做自己的自动化软件。因而，只要自动化软件的开发方，愿意与TSN网络侧进行协同开发，把网络组态中的信息告知网络控制器，那么上面的第1、2两条问题自然就可以得到解决。当然，网络控制器也可以作为一个功能组件，直接包到自动化软件里面。
由此我们回答了“如何在不引入对端侧设备的升级要求的情况下，让网络能够正确地识别关键业务”这个问题。下一篇文章会介绍流量自学习与组态协同两个方案的具体实践，敬请期待。
接下来回到最开头的问题，TSN的端到端应用落地，一定要支持TSN的端吗？——答案是，不需要。
怎样的端才叫做“支持TSN”呢？——如果从支持TSN时间门控端到端编排的角度来看，那这个端需要具备：1、和网络进行精准时间同步的能力；2、能够在约定的时间把报文发到网络介质上。如果这个端，仅仅通过软件升级，获取时间同步的能力（1588v2），获取系统调度的任务抢占的能力，提高系统调度的实时性，那么一般可以把发包的时间精确到us量级。如果这个端，硬件也升级了，则可以把发包的时间精确到ns量级，并且可以实现多类业务发送时的硬件队列调度。此外，一个“支持TSN”的端还可以有更多特性。比如，在TSN“分布式用户、集中式网络”的配置架构下，TSN端应能够与CNC（TSN网络控制器）进行符合标准定义的或类似的用户网络信息交互的能力。而在TSN“纯分布式”配置架构下，TSN端应支持如SRP、RAP等资源预留协议，直接参与TSN控制面的工作。再比如，TSN端按照与TSN网络交互的结果，在发送报文的头部的特定位置，按照约定对自己进行标识。
话说到这里，我们也看出来了，端侧的所谓TSN的升级，不论是软件还是硬件，其实是可以提高TSN端到端确定性的性能，是在“1”后面加“0”。而不论是通过静态配置、还是流量自学习方案、组态系统方案，都可以实现TSN端到端的那个“1”，而这个过程并不需要端设备额外做什么。