平常和客戶交流，經常被問到的跟車載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