平常和客户交流，经常被问到的跟车载TSN相关的问题，借着回答阐述一下我对车载TSN的理解，希望能给大家一些启发。
这是我最经常听到的一个问题。业界对于TSN在车载网络部署前景的担忧，大部分来自于对应用场景的不确定。我个人完全理解这样的看法。TSN应用场景的缺乏，可以进一步细分到两个层面：
a. 现阶段对高带宽+确定性需求最大的自驾域部分，以太网并不是主要的基础设施，自然也就谈不上TSN的应用了。
Figure1 华为CCA架构 - 摘自东吴证券研报
我们来看华为CCA架构。以太网环网确实部署了，但自驾相关的传感器（摄像头/毫米波雷达/激光雷达）并没有上环网而是直连MDC，数量最多且重要性最高（基于纯视觉路线的流行）的摄像头用的是名为GMSL（Gigabit Multimedia Serial Link）的串行链接技术，毫米波雷达用的是CAN，只有激光雷达使用以太网且是点到点直连，这种架构下TSN毫无用武之地。
b.即使有符合TSN特点的使用场景，架构设计人员依然有其他选项可以绕过。
Figure2 基于区域控制器的架构示意图-1
如上图所示，假如两个红五星标记的执行器基于应用需求要做同步，由于他们接到了不同的区域控制器，问题便转换为区域控制器之间的同步，使用TSN协议族中的IEEE 802.1AS通过以太网实现控制器间的同步是一个理所当然的选项。但还有没有其他路径呢？当然有。
Figure3基于区域控制器的架构示意图-2
如上图，只要控制器上有足够的端口，直接把右车身的执行器连到左后区域控制器就行了，同一控制器处理端口间同步是相对容易的事情。这个操作增加了线束成本的同时减少了协议部署的成本和网络与控制器协同工作的成本，从可行性的角度上看完全说的过去。所以TSN又悲催的被退居二线了。
综合以上两点，那TSN在车载领域就没戏了吗？我从一个跨界人士的视角出发斗胆说两句，其实也没那么悲观。
首先咱们明确一个观点：应用为王，网络是用来辅助应用实现的。这在哪行哪业都一样，道理很简单，应用是C端可见用来卖钱的，网络本身是卖不出钱的，所以根据应用需求来设计网络是天经地义的。但应用是一成不变的吗？不仅不是，而且肉眼可见迭代的速度越来越快。这时候如果还本着“能跑就行”的原则来设计网络，无异于一个老妈子追在应用屁股后面摞补丁，用稍微长远一点的眼光来看其实是不经济的。比如前面提的执行器同步的例子，这版需求是满足了，下一版需求如果是四个角上的执行器同步咋办，再拉两根线？反之在以太网上基于AS实现时钟同步，看似大炮打蚊子，实则建立了一个有弹性可扩展的架构，之后跟同步相关的需求都可以纳入到同一个框架里轻松解决，以不变应万变。高瞻远瞩加脚踏实地，在可行性和前瞻性中间找一个平衡，有难度但很有价值。综上所述我认为，以太环网加TSN的解决方案至少会长期作为一个选项存在。
Figure4 华为CCA的理想形态 - 摘自东吴证券研报
其次，我对TSN的信心也部分来自于对于以太网技术的信心，相信他在车载网络中占的地盘未来还能再扩一扩。以太网技术诞生40多年，在很多领域其实是以挑战者的身份出现最后占据了统治地位，比如在电信网络中挑落ATM技术，在高性能计算网络中击败Infiniband技术，车载网络里面对MOST他也是后来居上。以太网所依仗的优势无非这几点：（速率）量大管饱，没有专利墙，协议简单（CAN更简单，但速率上有先天劣势），行业应用广泛可以互相借鉴。大家发现没有，这里所有点其实都命中同一个关键词就是“省钱”。尽管现阶段车载以太网的成本并没有太大优势，我还是相信随着渗透率的提高，以太网在不久的将来会成为最经济的选择。
回到前文提到的自驾域，渗透率最高的摄像头通信目前SerDes（GMSL是其中一种实现方式）占据主流，那以太网还有机会吗？我认为是有的，比如Marvell就一直在推以太网传摄像头数据的方案。
Figure5 基于以太网的摄像头通信 - from Marvell
原因可能有几个。未来以太网成本降低会带来经济性方面的优势。近一两年涌现的车载算力集中化的实现可能将过往摄像头自带的图像处理/视频压缩等能力转移到自驾域控上，而无压缩原始视频的传输会对通信链路提出更高的带宽需求（1Gbps to 10/25Gbps），而这超出了SerDes的能力范围。另外基于车载应用的日新月异，我无责任拍个脑袋，也许未来会有传感器间互动的需求？那基于分组交换的以太网比点到点的Serdes实现起来方便多了。
综上所述，以太网在自驾域乃至整个车载网络中的地位可以说“未来可期”，作为以太网小弟的TSN日子也不会太差，大家要有信心。
这个一般是深入研究和动手实践过TSN的人会提的问题，我之前也有相同的认知，但仔细想想，其实还是有进一步推敲的空间。首先我们要明确在这个场景中应用TSN的目标，追求的究竟是低时延，还是低抖动（确定性）？
如果追求的是低时延，那可以说这个抱怨是个伪命题，我举个例子来说明这一点：我所在的写字楼，寄过来的包裹都是统一发到大楼物业，物业保安每三天才给我送一次，那我会拒绝隔天能到的顺丰而选用2-3天能到的邮政吗？反正都一样？那显然是不会的，最后这一段我可以有各种办法，可以投诉保安让他们勤点送，可以要求改规则让顺丰直接送上来，我自己跑跑腿去取也是可以的，肯定不会选择的是接受那个慢的快递。同样道理，当上层软件拖累了整体系统的时延指标，要做的事肯定是去优化上层软件而不是反过来质疑网络。木桶的装水量取决于最短的那块板，但正常的思路是去补短板，而不是对着长板说“你们的意义何在”。
Figure6 顺丰特快
如果追求的是确定性，那确实是个问题，因为非实时系统从理论上就无法保障时延的确定性。所以我们应该从系统设计的层面做把关，对于有整体确定性要求的系统，光靠TSN是无法满足的，必须搭配实时操作系统。
Figure7 RTOS实时操作系统
TSN作为网络基础设施的底层协议被用于承载时间敏感的业务流，跟TSN相关的测试包含两类，第一类是针对基础设施本身的测试，第二类是给定基础设施时针对业务的测试，本文主要讨论第一类测试。
针对TSN本身的测试，首要的自然是功能测试。我们很多时候也说一致性测试，这个说法是从其他以太网协议比如TCP/IP协议测试继承过来的，从测试目标上来看他跟功能测试是一回事。由于TSN协议族比较庞大，车载应用一般并不需要用到所有的协议，因此挑选需部署的协议进行测试即可。IEEE 802.1 TSN协议族中的绝大部分均已冻结，所以功能测试用例本身一般没有太大争议。
Figure8 TSN协议族
接下来是性能测试，这点争议就大很多，因为绝大部分标准不规定这个。此时让我们call back前文的两个观点：“TSN是用来辅助应用实现的”，“应用迭代的速度越来越快”。定一个相对较高的性能要求，有助于降低未来面对应用迭代时被迫调整网络设计的可能性。典型的性能要求包括时钟同步精度/时隙精度/单跳网络的时延抖动最大值等。
Figure9 IEEE 802.1AS时钟同步精度要求
最后还有可靠性/稳定性/鲁棒性测试。这里需要针对corner case进行设计，如各种故障（链路/节点），非法消息，突发流量等等。我特别建议增加长时间稳定性验证的测试，一些在前面功能/性能测试中没有显现的问题有可能在这一步被筛出来，也有助于减少后续系统测试甚至实车测试中遇到各种奇怪问题的概率。
Figure10 AS系统中链路与主节点均故障的corner case
