作者 | 梵高先生

小編 | 不吃豬頭肉

軟件定義汽車對網絡通信技術的影響

圖 1: 汽車電子電氣架構演進趨勢
十多年來，汽車電子電氣架構架構在不斷升級的應用需求的推動下快速演進。從智能網聯、自動駕駛、智能座艙，到軟件定義汽車、OTA 升級等新興應用層出不窮，上層應用的創新必將催生電子電氣架構的相應變革，后者是前者實現的重要基礎。
回溯十多年前，當時典型的架構就是中央網關加上若干 CAN 節點的拓撲結構。后來隨著域控制器、主干網絡、集中式架構等概念的引入，區域控制器和高性能計算單元開始嶄露頭角。
在這股變革浪潮中，值得重點關注的是一個趨勢——功能上移。早期的分布式架構中，整車功能分散布局在十余個 ECU 之中。然而，這種分散布局在快速迭代和頻繁升級的大潮下，顯然無法很好適應需求。過于分散加劇了 ECU 間耦合，任何局部變動都可能引發整車級連鎖反應，迭代升級效率大打折扣。
為解決這一困境，后來引入了域控制器概念，將分散的 ECU 功能進行整合，實現集中管理和高效升級。更進一步，功能繼續上移集中至中央高性能計算平臺，從根本上解決了分散布局導致的迭代低效問題，有力支持軟件快速迭代升級的需求。

圖 2: 標準化的基礎軟件和硬件平臺

功能上移的本質，是應用軟件向上移動，而底層基礎軟件和硬件平臺則可標準化，實現長周期維護。簡單來說，這可以稱為“軟硬分離”，或“應用軟件與基礎軟件/硬件平臺分離”。

在這種軟件快速迭代升級的大趨勢下，應用軟件對基礎軟硬件平臺提出了新的需求。
首先是動態性需求。為實現快速開發新車型，有必要賦予基礎平臺一定的動態靈活性，這也是過去十年 SOA 架構飛速發展的原因之一。動態化的平臺，就像搭樂高積木一樣，可讓 OEM 廠商快速為系統增加新的功能。
其次，更為重要的是實時性需求。這是汽車與消費電子的根本差別所在。作為交通工具，汽車的首要任務是確保駕駛員、乘客和行人的安全。要實現這一點，基礎軟硬件必須具備足夠的實時響應能力、可靠性和確定性，才能有力承載關鍵應用。
那么DDS 如何滿足上述各方面需求呢？

DDS 的關鍵特性
首先從通信模式的角度來看。很多人習慣將 DDS 與 SOME/IP 進行對比，但實際上兩者遵循的是完全不同的通信模式，有不同的應用場景。

圖 3: DDS 通信模式
DDS 是典型的發布訂閱 （Pub-Sub） 通信模型，更像一種面向信號的通信方式。大家熟知的 CAN 總線實際上也是發布訂閱模型，只不過 DDS 版的發布訂閱要更加靈活。

圖 4: SOME/IP 的通信模式
而客戶端服務器模型 （Client-Server），又稱 SOA 模型，則是在發布訂閱模型基礎上的進一步抽象。
在發布訂閱模型中，發布者和訂閱者交互的是獨立的消息 （Message）。但在 SOA 模型里，客戶端和服務端交互的數據則賦予了新的語義，如請求消息、響應消息、事件消息等。
表面上 SOA 模型看似更高級，但實際上兩種模式并無優劣之分，只是各有適用的場景。
發布訂閱模型更適合大量簡單的實時數據分發場景，如傳感器數據、車輛狀態數據的分發。此外，發布端和訂閱端也是相對解耦的，雙方無需關注對方的位置狀態，筆者稍后將詳解 DDS 在這方面的優勢。
而客戶端服務器模型的限制則更多。首先要求數據流向明確，需有一中央節點，其他節點 （客戶端） 只與該節點通信，客戶端節點之間無直接交互。其次，通信模式是請求-響應式的，如數據庫查詢、文件服務等。再者，數據和計算資源均集中在服務端。

圖 5: SOA 的典型發展過程（圖片來源于AEC 2024《Is SOME/IP the right solution for the next 10 years of vehicles》）
因此，SOA 通信模型的適用場景是比較有限的。如果數據流不符合該模型，使用 SOA 反而會增加設計和開發的負擔。事實上，近年一些 OEM 在第一代車載以太網量產后便急于追求整車 SOA 化，但開發效率未能顯著提升，反而增加了不少成本。1.DDS 的以數據為中心
DDS 的一個重要特性是“以數據為中心”。
過去在介紹 SOA 時，人們常說其一大特點是解耦。但解耦并非 SOA 的專利，DDS 同樣能夠實現解耦。
與 SOA 中的服務、請求、響應等復雜概念不同，DDS 世界中只有“數據”這一核心要素。應用程序可以像訪問數據庫一樣，自由收發數據，而無需關注數據來源去向。發布端只需把數據“丟給”DDS，不必理會接收者情況；訂閱端則直接從 DDS “拿走”所需數據，不問數據發布方。這種“充分解耦”的模式，甚至超越了 SOA。
大家可能會問，DDS 中是否也存在一個中央節點，和 SOA 架構類似? 從邏輯上講，確實存在一個虛擬的“全局數據空間”。但這并非 SOA 中的“服務器”概念，兩者指向不同層次。DDS 中的“服務”，僅指數據分發服務，屬底層功能，負責數據發現、存儲、發布等，不涉及業務邏輯；而 SOA 中的“服務”則指應用層的業務服務，如空調、音樂等。這是須明確區分的兩個概念。另外，盡管 DDS 邏輯上有“全局數據空間”，但在物理實現上它仍是分布式的，并不存在真實的服務器節點，因此不存在單點故障和性能瓶頸隱患。

圖 6: DDS 的以數據為中心的概念以及解耦

上圖可以很好地解釋 DDS 發布訂閱雙方的解耦關系。一開始整個系統處于空閑狀態，發布端第一個“喚醒”，開始發布數據。此時網絡中尚無接收者，但沒關系，發布端只管把數據“丟給”DDS 即可，隨后自己進入休眠。等到有訂閱端上線需要數據時，直接從 DDS“拿走”所需數據即可，根本無需在意數據源頭。這種“充分解耦”模式靠 DDS 的內置 QoS （服務質量）實現，這能夠使 DDS 的耦合程度比 SOA 更低。因為在 SOA 的請求-響應通信中，客戶端和服務端必須同時在線，而 DDS 并不一定要求如此。

2.DDS 的平臺無關
DDS 的另一大特性是平臺無關性。這里的“平臺”泛指操作系統、傳輸協議等底層依賴。DDS 實現平臺無關的方式是，盡量不依賴于平臺的獨有復雜功能，而將這些功能需求自己實現，然后通過統一的標準化接口對外提供服務。

圖 7: DDS 的平臺無關
因此，DDS 的可移植性非常良好，只要有基本的 UDP 通信支持，就可以運行 DDS。事實上，DDS 與 UDP 被認為是最佳拍檔，因為 UDP 最為簡單，幾乎沒有 QoS 保證。而 DDS 則希望底層協議盡可能簡單，因為諸如 QoS 等復雜功能需求，DDS 自身已實現并對應用開放。
不過，DDS 這種“自力更生”的做法，也帶來了一個印象 —— 在很多人眼里，DDS 顯得過于“重”、過于復雜，資源開銷較大。筆者認為這是一種取舍：DDS 一邊提供了豐富特性、標準統一接口和平臺無關性，作為代價，另一邊就是較高的資源開銷和軟件復雜度。這是一種權衡，沒有絕對的對錯。

3.基于 DDS 實現的 SOA 架構
SOA在現代車載分布式系統中扮演著至關重要的角色。SOA 提供了一種靈活、可擴展的方法來設計和實現復雜的分布式系統，使得不同的服務能夠獨立開發、部署和維護，同時又能無縫地協同工作。
通過在 DDS 之上實現 SOA，我們似乎可以結合 DDS 的數據中心特性和 SOA 的服務中心特性，既能夠利用DDS的適用于大量實時數據分發的特性，又具備了SOA的靈活、可擴展，便于管理的優勢。
前文提到 DDS 并非 SOA 架構，與 SOME/IP 等技術有所不同。但通過一定手段，DDS 確實可以支持類 SOA 的通信模式。

圖 8: DDS-RPC（圖片來自 https://www.omg.org/spec/DDS-RPC ）
OMG 發布了 DDS-RPC 標準規范，其中給出了一個參考實現。做法是在 DDS Topic 的基礎上再封裝一層，對于請求報文，添加包含客戶端 GUID （全局唯一 ID） 和序列號的報文頭，以讓服務端識別來源和追蹤序列。服務端回復時，將服務端 ID、序列號及原請求頭復制到響應報文頭中，使客戶端能對應到之前的請求。

圖 9: 基于 DDS 實現 SOA 時存在的問題
雖然 DDS 可以大致模擬 SOA，但仍有些特性缺失，比如真正意義上的服務發現功能。DDS 雖然也有發現機制 （SPDP/SEDP），但僅提供通信端點層面的發現，無法發現應用層業務服務。不過，DDS 本身提供了良好擴展性，DDS-RPC 框架使用者可自行開發所需的服務發現功能。
另一個限制是，一旦將 DDS 用于請求-響應模式的 RPC 通信，很多 QoS 特性將不再適用。
綜合考慮，將 DDS 用作 SOA 通信框架或 SOME/IP 的替代方案時，我們需要全面權衡其優勢與挑戰。DDS 與 SOA 的結合無疑能帶來諸多優點，如高性能的實時數據分發與靈活的服務架構的融合。然而，這種整合也伴隨著顯著的成本和潛在缺陷：

技術實現方面，我們可能需要自行解決一系列額外的技術問題。

功能應用方面，這種使用方式可能會限制 DDS 原有的一些獨特優勢。

資源消耗方面，DDS 較高的系統資源占用可能成為一個不容忽視的負擔。

因此，在做出技術路線的選擇之前，我們必須審慎評估其帶來的收益是否足以抵消相應的成本和潛在風險。

DDS 與 TSN 的融合
1.實時性是系統性問題
首先需要明確，實時性是一個系統性挑戰，原因在于汽車電子電氣系統本身就是一個錯綜復雜的大系統。尤其是在車載以太網進入汽車領域后，Linux、Android、QNX 等復雜操作系統也開始大量應用，這使得確保整體實時性變得更加困難。

圖 10: 分布式系統的實時性問題
其中的根源在于，從應用程序、中間件、操作系統到硬件、網絡，每個環節都存在一定的不確定性因素，而這些不確定性會沿著系統層層累積，越靠近應用層級別，不確定性就越高；而越接近硬件層級，不確定性就越低，最終各環節不確定性的累積導致整個系統的不確定性和實時性下降。因此，解決分布式系統實時性問題是一個復雜的系統工程，我們不能寄希望于某一單一技術的應用就能全面解決。單靠某種中間件、操作系統或網絡技術是遠遠不夠的，需要從系統層面綜合施策，通過架構、平臺、中間件、操作系統等多維協同，才能夠滿足嚴格的實時性需求。
首先需要明確的一點是，TSN （時間敏感網絡）只能解決網絡層面的實時性問題，且主要針對二層或二層以下。汽車領域常見的 TSN 協議見下表。

除了網絡層面，大部分不確定性實際上來自于終端節點內部，而這部分無法依賴 TSN 來解決。由于終端內部的復雜性，很難有一個標準化的簡單方案來全面解決內部實時性問題。
那么針對 DDS，我們可以采取以下措施來提高實時性和確定性:

?內存申請固化：減少不可預測的動態內存申請

?通信關系固化：降低正常使用場景下通信關系的動態變化，減少節點動態進出

?交互過程固化：減少 DDS 協議維護數據可靠性而產生的額外數據交換

?數據長度限制：避免單次發送/接收時間超出預期

總之，我們可以在一定程度上限制 DDS 的動態性特征，以換取更好的可預期性和實時性。這是一種權衡，需要根據具體場景需求來平衡動態性和實時性。
2.通過 TSN 改善 DDS 時間控制
前面我們從全局角度分析了實時性問題，下面針對一些具體點做進一步探討。

DDS 的工作依賴于兩種時鐘

1.內部時鐘 - 用于中間件內部的各種定時操作，如周期性發送 SPDP 消息、Heartbeat 消息、Deadline 控制等。2.外部時鐘 - 主要用于為發送消息打上時間戳。

圖 12: DDS 的時鐘系統
應用時間同步（例如通過 IEEE 802.1 AS 同步）后，可實現更精確的時間控制，如 Deadline 等 QoS 策略。如果時間未同步，不同節點之間會存在時間偏差。例如發送端 1 秒周期發送數據，接收端實際周期或許是 1.2 秒。這時如果配置 1 秒的 Deadline QoS，接收端就可能誤判為超時。
因此，缺少時鐘同步系統時，我們只能放寬 Deadline 容忍度，比如正負 500 ms 視為正常。而通過時鐘同步技術，我們可以實現更精準的 Deadline 控制，例如 1 ms 或更低。
另一需注意的是時鐘跳躍問題。當 DDS 時鐘配置為同步時鐘源時，啟動或其他情況下時鐘可能會發生較大跳躍。無論是內部時鐘還是外部時鐘的跳躍，都可能導致 DDS 工作異常。所以在正常運行期間，時鐘跳躍是應當盡量避免的。
時鐘同步對實現精確的實時性控制非常重要，但也需規避時鐘跳躍風險。在部署時鐘同步方案時，務必權衡兩者，審慎評估并制定相應的容錯措施。
3.通過 TSN 改善 DDS 的傳輸延遲和優先級
另一需要關注的是傳輸延遲和優先級問題，這也是 TSN 所重點關注的。
在 DDS 中，有對應的 QoS 策略:

1.LATENCY_BUDGET - 允許應用程序向底層傳輸層指定一個延遲時間要求。但 DDS 作為應用層中間件，本身無法對底層傳輸進行控制，只能給出這樣的“期望”。

2.TRANSPORT_PRIORITY - 同理，應用層可以指定不同數據流的傳輸優先級，但無法直接對底層傳輸層進行優先級調度。

需要注意的是，這些延遲和優先級的設置，實際上更多是應用層對底層傳輸的一種“建議”或“要求”。如何基于這些要求來動態調度網絡資源、規劃路徑、設置隊列等，需要在底層傳輸層有相應的機制來支持，DDS 本身無法約束。
圖 13: TSN 中間件
一種可行方案是在 DDS 下層部署一個 TSN 中間件，專門負責動態處理這些延遲和優先級需求。但這種機制也存在新的不確定性風險。當資源有限時，必定會有部分延遲、優先級需求無法滿足，這將導致無法接受的實時性下降。因此，在決定是否采用這種機制時，我們需要全面評估其在車載場景下的適用性和合理性，謹慎權衡收益和潛在風險。
4.OMG DDS-TSN
說到 DDS 與 TSN 的融合，就不得不提接 OMG 發布的 DDS-TSN 規范，該規范定義了 DDS 與 TSN 的集成插件。目前該規范已經發布了 Beta 版本，有需要的讀者可以在 OMG 官網免費下載。
DDS-TSN 規范的目的是建立一個統一標準，使不同供應商在實現 DDS 與 TSN 集成時能夠遵循相同規范，從而實現整個行業內產品和工具鏈的互操作性，有利于提高開發效率，降低成本。
OMG DDS-TSN 規范約束了兩個主要方面的內容:第一是標準化了 DDS-TSN 系統的部署和配置流程。第二是提出了兩種具體的技術實現方案:

1.將 RTPS 消息映射到 UDP/IP 上，再通過 TSN 傳輸 UDP 數據包。這是一種相對容易實現的方式，因為只需將原有傳統以太網改為 TSN 以太網，對系統修改較小。但缺點是數據需經 UDP/IP 協議棧再到 TSN 網絡，實時性會受操作系統內核調度影響。

2.將 RTPS 直接映射到 TSN 網絡的以太網幀上，繞過 UDP/IP 協議棧的影響。這種方式可有效提高實時性，但需對 DDS 實現做大量修改，研發工作量較大。

兩種方案各有利弊，應根據具體場景的實時性需求和開發投入進行權衡選擇。

針對 DDS -TSN 的系統級測試圖 14: “應用到應用”的 DDS-TSN 系統級接口測試框架
在中間件測試領域，一個核心問題是如何有效地對中間件產生激勵或觸發測試。這一挑戰源于中間件接口的特殊性。
黑盒測試通常需要仿真被測對象的輸入并測量其輸出。然而，中間件的接口多以軟件形式存在，這與傳統的 ECU 硬件在環 （HIL） 測試有顯著差異。中間件測試面臨的主要困難在于缺乏可直接進行激勵或測量的物理外部接口。
為應對這一挑戰，業界普遍采用的方法是在 ECU 內部嵌入專門的測試應用程序。例如，TC 8 中的 Upper Tester 或 ETS 就屬于此類應用。這些程序的作用是將中間件的軟件接口以標準化的服務接口形式通過網絡暴露出來，使外部測試系統能夠訪問中間件接口。
在 DDS-TSN 系統測試中，北匯信息沿用了這一思路，在系統內置入測試應用程序。需要注意的是，車載分布式系統通常具有較高的復雜性，可能包含多種網絡節點配置：

1.簡單的獨立網絡節點

2.復雜節點，內部包含多個通過板載交換機通信的子系統

3.支持多進程的高級操作系統節點，進程間通信采用基于共享內存的 DDS

盡管系統結構復雜多樣，北匯信息仍能采用統一的方式植入測試程序。這得益于 DDS 接口的一致性，使我們無需過多關注底層實現細節。
在測試系統層面，北匯信息通過私有協議對這些 DDS 測試程序進行控制和編排，以實現各種測試用例。這種架構實現了真正的“應用到應用”測試，能夠全面反映整個系統的行為表現。
除了全系統測試，北匯信息還開展了多種專項測試，聚焦于特定環節，如物理層到物理層（Phy-to-Phy）測試。但需要注意的是，這類局部測試結果可能無法準確反映整個系統的時間特性。
北匯信息不僅提供標準測試用例集，還支持用戶根據系統的特殊場景定制開發新的測試用例。例如，用戶可以設計一對多通信、多對一通信等模擬真實應用場景的測試。
圖 15: 監測 DDS-TSN 的時鐘同步狀態
此外，時間特性測試（如延遲測試）依賴于全局同步時鐘，以確保收發雙方具有共同的時間基準。這一點在設計和執行測試時需要特別關注。
為了實時監控時鐘同步系統的運行狀態，北匯信息采用了 TSN CoreSolution 工具，能夠對網絡中每個節點的 1 PPS（每秒脈沖）信號進行實時監測。通過這種方式，我們可以準確判斷時鐘同步系統是否正常工作，以及其誤差是否滿足系統要求。
在硬件方面，使用的核心工具是 TSN Box。這是一個專門設計用于 TSN 系統仿真和分析的硬件系統。TSN Box 具備豐富的接口支持，尤其是能夠采集 1 PPS 信號，這使得它成為時鐘同步監測的理想設備。
與 TSN Box 配套的是上位機軟件 TSN Tools。這款軟件提供了強大的數據分析和可視化功能。通過 TSN Tools，我們能夠：

1.實時處理從 TSN Box 采集的數據

2.進行深入的時鐘同步性能分析

3.提供直觀的可視化界面，便于工程師快速識別和解決同步問題

這套工具組合（TSN Box 硬件 + TSN Tools 軟件）為我們提供了一個全面的 TSN 系統分析平臺。它不僅能夠監測時鐘同步，還能對整個 TSN 網絡的性能進行全方位的評估和優化。
圖 16: 監測 DDS-TSN 的網絡消息的格式和行為
除了時鐘同步監測，TSN Box 還具備捕獲以太網原始數據的能力，這為深入分析 DDS-TSN 系統的行為提供了重要支持。值得注意的是，所有捕獲的數據都以 gPTP 為基準時鐘，確保了數據的時間一致性。
在實際應用中，測試過程中產生的各類數據，如 DDS 接口測試日志、以太網數據幀的時間戳等，都可以被放置在同一時間基準上進行分析。這種統一的時間視角使得測試工程師能夠全面、準確地評估系統性能。
通過對這些統一基準的數據進行分析，我們可以輕松地識別并量化系統中每個環節的具體延遲。這種精細化的延遲分析對于優化系統性能、滿足嚴格的實時要求至關重要。

總結
本文全面介紹了軟件定義汽車對網絡通信技術的新需求，并闡述了如何通過 DDS 與 TSN 的融合來提升系統的動態靈活性和實時性能力，最后介紹了針對 DDS 與 TSN 融合系統的測試解決方案。針對復雜的 DDS-TSN 系統，文中提出了一套完整的“應用到應用”的系統級測試方法，通過植入測試程序、監控時鐘同步、捕獲網絡數據包并進行統一時間基準的分析，可以全面評估和驗證系統的實時性能指標，為軟件定義汽車的軟硬件架構集成提供有力支持。
北匯信息在車載網絡通信和中間件測試領域擁有多年經驗，已為眾多整車廠和供應商提供過 DDS、TSN 等技術的咨詢和測試服務，擁有成熟的解決方案和專業的技術團隊，能夠滿足客戶在軟件定義汽車網絡通信架構集成和測試驗證等方面的各種需求，期待各位讀者與我們進一步交流。