軟體定義汽車對網路通訊技術的影響
十多年來，汽車電子電氣架構架構在不斷升級的應用需求的推動下快速演進。從智慧網聯、自動駕駛、智慧座艙，到軟體定義汽車、OTA 升級等新興應用層出不窮，上層應用的創新必將催生電子電氣架構的相應變革，後者是前者實現的重要基礎。
回溯十多年前，當時典型的架構就是中央閘道器加上若干 CAN 節點的拓撲結構。後來隨著域控制器、主幹網路、集中式架構等概念的引入，區域控制器和高效能運算單元開始嶄露頭角。
在這股變革浪潮中，值得重點關注的是一個趨勢——功能上移。早期的分散式架構中，整車功能分散佈局在十餘個 ECU 之中。然而，這種分散佈局在快速迭代和頻繁升級的大潮下，顯然無法很好適應需求。過於分散加劇了 ECU 間耦合，任何區域性變動都可能引發整車級連鎖反應，迭代升級效率大打折扣。
為解決這一困境，後來引入了域控制器概念，將分散的 ECU 功能進行整合，實現集中管理和高效升級。更進一步，功能繼續上移集中至中央高效能運算平臺，從根本上解決了分散佈局導致的迭代低效問題，有力支援軟體快速迭代升級的需求。
功能上移的本質，是應用軟體向上移動，而底層基礎軟體和硬體平臺則可標準化，實現長週期維護。簡單來說，這可以稱為“軟硬分離”，或“應用軟體與基礎軟體/硬體平臺分離”。
在這種軟體快速迭代升級的大趨勢下，應用軟體對基礎軟硬體平臺提出了新的需求。
首先是動態性需求。為實現快速開發新車型，有必要賦予基礎平臺一定的動態靈活性，這也是過去十年 SOA 架構飛速發展的原因之一。動態化的平臺，就像搭樂高積木一樣，可讓 OEM 廠商快速為系統增加新的功能。
其次，更為重要的是實時性需求。這是汽車與消費電子的根本差別所在。作為交通工具，汽車的首要任務是確保駕駛員、乘客和行人的安全。要實現這一點，基礎軟硬體必須具備足夠的實時響應能力、可靠性和確定性，才能有力承載關鍵應用。
那麼DDS 如何滿足上述各方面需求呢？
DDS 的關鍵特性
首先從通訊模式的角度來看。很多人習慣將 DDS 與 SOME/IP 進行對比，但實際上兩者遵循的是完全不同的通訊模式，有不同的應用場景。
DDS 是典型的釋出訂閱 （Pub-Sub） 通訊模型，更像一種面向訊號的通訊方式。大家熟知的 CAN 匯流排實際上也是釋出訂閱模型，只不過 DDS 版的釋出訂閱要更加靈活。
而客戶端伺服器模型 （Client-Server），又稱 SOA 模型，則是在釋出訂閱模型基礎上的進一步抽象。
在釋出訂閱模型中，釋出者和訂閱者互動的是獨立的訊息 （Message）。但在 SOA 模型裡，客戶端和服務端互動的資料則賦予了新的語義，如請求訊息、響應訊息、事件訊息等。
表面上 SOA 模型看似更高階，但實際上兩種模式並無優劣之分，只是各有適用的場景。
釋出訂閱模型更適合大量簡單的實時資料分發場景，如感測器資料、車輛狀態資料的分發。此外，釋出端和訂閱端也是相對解耦的，雙方無需關注對方的位置狀態，筆者稍後將詳解 DDS 在這方面的優勢。
而客戶端伺服器模型的限制則更多。首先要求資料流嚮明確，需有一中央節點，其他節點 （客戶端） 只與該節點通訊，客戶端節點之間無直接互動。其次，通訊模式是請求-響應式的，如資料庫查詢、檔案服務等。再者，資料和計算資源均集中在服務端。
因此，SOA 通訊模型的適用場景是比較有限的。如果資料流不符合該模型，使用 SOA 反而會增加設計和開發的負擔。事實上，近年一些 OEM 在第一代車載乙太網量產後便急於追求整車 SOA 化，但開發效率未能顯著提升，反而增加了不少成本。
DDS 的以資料為中心
DDS 的一個重要特性是“以資料為中心”。
過去在介紹 SOA 時，人們常說其一大特點是解耦。但解耦並非 SOA 的專利，DDS 同樣能夠實現解耦。
與 SOA 中的服務、請求、響應等複雜概念不同，DDS 世界中只有“資料”這一核心要素。應用程式可以像訪問資料庫一樣，自由收發資料，而無需關注資料來源去向。釋出端只需把資料“丟給”DDS，不必理會接收者情況；訂閱端則直接從 DDS “拿走”所需資料，不問資料釋出方。這種“充分解耦”的模式，甚至超越了 SOA。
大家可能會問，DDS 中是否也存在一箇中央節點，和 SOA 架構類似? 從邏輯上講，確實存在一個虛擬的“全域性資料空間”。但這並非 SOA 中的“伺服器”概念，兩者指向不同層次。DDS 中的“服務”，僅指資料分發服務，屬底層功能，負責資料發現、儲存、釋出等，不涉及業務邏輯；而 SOA 中的“服務”則指應用層的業務服務，如空調、音樂等。這是須明確區分的兩個概念。另外，儘管 DDS 邏輯上有“全域性資料空間”，但在物理實現上它仍是分散式的，並不存在真實的伺服器節點，因此不存在單點故障和效能瓶頸隱患。
上圖可以很好地解釋 DDS 釋出訂閱雙方的解耦關係。一開始整個系統處於空閒狀態，釋出端第一個“喚醒”，開始釋出資料。此時網路中尚無接收者，但沒關係，釋出端只管把資料“丟給”DDS 即可，隨後自己進入休眠。等到有訂閱端上線需要資料時，直接從 DDS“拿走”所需資料即可，根本無需在意資料來源頭。這種“充分解耦”模式靠 DDS 的內建 QoS （服務質量）實現，這能夠使 DDS 的耦合程度比 SOA 更低。因為在 SOA 的請求-響應通訊中，客戶端和服務端必須同時線上，而 DDS 並不一定要求如此。
DDS 的平臺無關
DDS 的另一大特性是平臺無關性。這裡的“平臺”泛指作業系統、傳輸協議等底層依賴。DDS 實現平臺無關的方式是，儘量不依賴於平臺的獨有複雜功能，而將這些功能需求自己實現，然後透過統一的標準化介面對外提供服務。
因此，DDS 的可移植性非常良好，只要有基本的 UDP 通訊支援，就可以執行 DDS。事實上，DDS 與 UDP 被認為是最佳拍檔，因為 UDP 最為簡單，幾乎沒有 QoS 保證。而 DDS 則希望底層協議儘可能簡單，因為諸如 QoS 等複雜功能需求，DDS 自身已實現並對應用開放。
不過，DDS 這種“自力更生”的做法，也帶來了一個印象 —— 在很多人眼裡，DDS 顯得過於“重”、過於複雜，資源開銷較大。筆者認為這是一種取捨：DDS 一邊提供了豐富特性、標準統一介面和平臺無關性，作為代價，另一邊就是較高的資源開銷和軟體複雜度。這是一種權衡，沒有絕對的對錯。
基於 DDS 實現的 SOA 架構
SOA在現代車載分散式系統中扮演著至關重要的角色。SOA 提供了一種靈活、可擴充套件的方法來設計和實現複雜的分散式系統，使得不同的服務能夠獨立開發、部署和維護，同時又能無縫地協同工作。
透過在 DDS 之上實現 SOA，我們似乎可以結合 DDS 的資料中心特性和 SOA 的服務中心特性，既能夠利用DDS的適用於大量實時資料分發的特性，又具備了SOA的靈活、可擴充套件，便於管理的優勢。
前文提到 DDS 並非 SOA 架構，與 SOME/IP 等技術有所不同。但透過一定手段，DDS 確實可以支援類 SOA 的通訊模式。
OMG 釋出了 DDS-RPC 標準規範，其中給出了一個參考實現。做法是在 DDS Topic 的基礎上再封裝一層，對於請求報文，新增包含客戶端 GUID （全域性唯一 ID） 和序列號的報文頭，以讓服務端識別來源和追蹤序列。服務端回覆時，將服務端 ID、序列號及原請求頭複製到響應報文頭中，使客戶端能對應到之前的請求。
雖然 DDS 可以大致模擬 SOA，但仍有些特性缺失，比如真正意義上的服務發現功能。DDS 雖然也有發現機制 （SPDP/SEDP），但僅提供通訊端點層面的發現，無法發現應用層業務服務。不過，DDS 本身提供了良好擴充套件性，DDS-RPC 框架使用者可自行開發所需的服務發現功能。
另一個限制是，一旦將 DDS 用於請求-響應模式的 RPC 通訊，很多 QoS 特性將不再適用。
綜合考慮，將 DDS 用作 SOA 通訊框架或 SOME/IP 的替代方案時，我們需要全面權衡其優勢與挑戰。DDS 與 SOA 的結合無疑能帶來諸多優點，如高效能的實時資料分發與靈活的服務架構的融合。然而，這種整合也伴隨著顯著的成本和潛在缺陷：
- 技術實現方面，我們可能需要自行解決一系列額外的技術問題。
- 功能應用方面，這種使用方式可能會限制 DDS 原有的一些獨特優勢。
- 資源消耗方面，DDS 較高的系統資源佔用可能成為一個不容忽視的負擔。
因此，在做出技術路線的選擇之前，我們必須審慎評估其帶來的收益是否足以抵消相應的成本和潛在風險。
DDS 與 TSN 的融合
實時性是系統性問題
首先需要明確，實時性是一個系統性挑戰，原因在於汽車電子電氣系統本身就是一個錯綜複雜的大系統。尤其是在車載乙太網進入汽車領域後，Linux、Android、QNX 等複雜作業系統也開始大量應用，這使得確保整體實時性變得更加困難。
其中的根源在於，從應用程式、中介軟體、作業系統到硬體、網路，每個環節都存在一定的不確定性因素，而這些不確定性會沿著系統層層累積，越靠近應用層級別，不確定性就越高；而越接近硬體層級，不確定性就越低，最終各環節不確定性的累積導致整個系統的不確定性和實時性下降。
因此，解決分散式系統實時性問題是一個複雜的系統工程，我們不能寄希望於某一單一技術的應用就能全面解決。單靠某種中介軟體、作業系統或網路技術是遠遠不夠的，需要從系統層面綜合施策，透過架構、平臺、中介軟體、作業系統等多維協同，才能夠滿足嚴格的實時性需求。
首先需要明確的一點是，TSN （時間敏感網路）只能解決網路層面的實時性問題，且主要針對二層或二層以下。汽車領域常見的 TSN 協議見下表。
|
排程策略 |
應用效果 |
|
Strict Priority (IEEE 802.1Q) |
為關鍵業務流量分配更高的優先順序，提高這些流量的實時性 |
|
Frame Preemption (IEEE 802.1Qbu) |
減少長幀引起的“隊頭阻塞”，使得關鍵業務的幀可以得到更快處理，進一步為關鍵業務流量降低延時 |
|
TAS (IEEE 802.1Qbv) |
基於時間視窗的門控排程，降低延遲，增加流量的可預測性和確定性 |
|
CBS (IEEE 802.1Qav) |
延展突發流量的傳輸，使流量更加均勻 |
|
FRER (IEEE 802.1CB) |
提供流量的冗餘傳輸，增加網路的可靠性，減少因故障造成的資料丟失 |
除了網路層面，大部分不確定性實際上來自於終端節點內部，而這部分無法依賴 TSN 來解決。由於終端內部的複雜性，很難有一個標準化的簡單方案來全面解決內部實時性問題。
那麼針對 DDS，我們可以採取以下措施來提高實時性和確定性:
- 記憶體申請固化：減少不可預測的動態記憶體申請
- 通訊關係固化：降低正常使用場景下通訊關係的動態變化，減少節點動態進出
- 互動過程固化：減少 DDS 協議維護資料可靠性而產生的額外資料交換
- 資料長度限制：避免單次傳送/接收時間超出預期
總之，我們可以在一定程度上限制 DDS 的動態性特徵，以換取更好的可預期性和實時性。這是一種權衡，需要根據具體場景需求來平衡動態性和實時性。
透過 TSN 改善 DDS 時間控制
前面我們從全域性角度分析了實時性問題，下面針對一些具體點做進一步探討。
DDS 的工作依賴於兩種時鐘：
- 內部時鐘 - 用於中介軟體內部的各種定時操作，如週期性傳送 SPDP 訊息、Heartbeat 訊息、Deadline 控制等。
- 外部時鐘 - 主要用於為傳送訊息打上時間戳。
應用時間同步（例如透過 IEEE 802.1 AS 同步）後，可實現更精確的時間控制，如 Deadline 等 QoS 策略。如果時間未同步，不同節點之間會存在時間偏差。例如傳送端 1 秒週期傳送資料，接收端實際週期或許是 1.2 秒。這時如果配置 1 秒的 Deadline QoS，接收端就可能誤判為超時。
因此，缺少時鐘同步系統時，我們只能放寬 Deadline 容忍度，比如正負 500 ms 視為正常。而透過時鐘同步技術，我們可以實現更精準的 Deadline 控制，例如 1 ms 或更低。
另一需注意的是時鐘跳躍問題。當 DDS 時鐘配置為同步時鐘源時，啟動或其他情況下時鐘可能會發生較大跳躍。無論是內部時鐘還是外部時鐘的跳躍，都可能導致 DDS 工作異常。所以在正常執行期間，時鐘跳躍是應當儘量避免的。
時鐘同步對實現精確的實時性控制非常重要，但也需規避時鐘跳躍風險。在部署時鐘同步方案時，務必權衡兩者，審慎評估並制定相應的容錯措施。
透過 TSN 改善 DDS 的傳輸延遲和優先順序
另一需要關注的是傳輸延遲和優先順序問題，這也是 TSN 所重點關注的。
在 DDS 中，有對應的 QoS 策略:
- LATENCY_BUDGET - 允許應用程式向底層傳輸層指定一個延遲時間要求。但 DDS 作為應用層中介軟體，本身無法對底層傳輸進行控制，只能給出這樣的“期望”。
- TRANSPORT_PRIORITY - 同理，應用層可以指定不同資料流的傳輸優先順序，但無法直接對底層傳輸層進行優先順序排程。
需要注意的是，這些延遲和優先順序的設定，實際上更多是應用層對底層傳輸的一種“建議”或“要求”。如何基於這些要求來動態排程網路資源、規劃路徑、設定佇列等，需要在底層傳輸層有相應的機制來支援，DDS 本身無法約束。
一種可行方案是在 DDS 下層部署一個 TSN 中介軟體，專門負責動態處理這些延遲和優先順序需求。但這種機制也存在新的不確定性風險。當資源有限時，必定會有部分延遲、優先順序需求無法滿足，這將導致無法接受的實時性下降。因此，在決定是否採用這種機制時，我們需要全面評估其在車載場景下的適用性和合理性，謹慎權衡收益和潛在風險。
OMG DDS-TSN
說到 DDS 與 TSN 的融合，就不得不提接 OMG 釋出的 DDS-TSN 規範，該規範定義了 DDS 與 TSN 的整合外掛。目前該規範已經發布了 Beta 版本，有需要的讀者可以在 OMG 官網免費下載。
DDS-TSN 規範的目的是建立一個統一標準，使不同供應商在實現 DDS 與 TSN 整合時能夠遵循相同規範，從而實現整個行業內產品和工具鏈的互操作性，有利於提高開發效率，降低成本。
OMG DDS-TSN 規範約束了兩個主要方面的內容:
第一是標準化了 DDS-TSN 系統的部署和配置流程。
第二是提出了兩種具體的技術實現方案:
- 將 RTPS 訊息對映到 UDP/IP 上，再透過 TSN 傳輸 UDP 資料包。這是一種相對容易實現的方式，因為只需將原有傳統乙太網改為 TSN 乙太網，對系統修改較小。但缺點是資料需經 UDP/IP 協議棧再到 TSN 網路，實時性會受作業系統核心排程影響。
- 將 RTPS 直接對映到 TSN 網路的乙太網幀上，繞過 UDP/IP 協議棧的影響。這種方式可有效提高實時性，但需對 DDS 實現做大量修改，研發工作量較大。
兩種方案各有利弊，應根據具體場景的實時性需求和開發投入進行權衡選擇。
針對 DDS -TSN 的系統級測試
在中介軟體測試領域，一個核心問題是如何有效地對中介軟體產生激勵或觸發測試。這一挑戰源於中介軟體介面的特殊性。
黑盒測試通常需要模擬被測物件的輸入並測量其輸出。然而，中介軟體的介面多以軟體形式存在，這與傳統的 ECU 硬體在環 （HIL） 測試有顯著差異。中介軟體測試面臨的主要困難在於缺乏可直接進行激勵或測量的物理外部介面。
為應對這一挑戰，業界普遍採用的方法是在 ECU 內部嵌入專門的測試應用程式。例如，TC 8 中的 Upper Tester 或 ETS 就屬於此類應用。這些程式的作用是將中介軟體的軟體介面以標準化的服務介面形式透過網路暴露出來，使外部測試系統能夠訪問中介軟體介面。
在 DDS-TSN 系統測試中，北匯資訊沿用了這一思路，在系統內建入測試應用程式。需要注意的是，車載分散式系統通常具有較高的複雜性，可能包含多種網路節點配置：
- 簡單的獨立網路節點
- 複雜節點，內部包含多個透過板載交換機通訊的子系統
- 支援多程序的高階作業系統節點，程序間通訊採用基於共享記憶體的 DDS
儘管系統結構複雜多樣，北匯資訊仍能採用統一的方式植入測試程式。這得益於 DDS 介面的一致性，使我們無需過多關注底層實現細節。
在測試系統層面，北匯資訊透過私有協議對這些 DDS 測試程式進行控制和編排，以實現各種測試用例。這種架構實現了真正的“應用到應用”測試，能夠全面反映整個系統的行為表現。
除了全系統測試，北匯資訊還開展了多種專項測試，聚焦於特定環節，如物理層到物理層（Phy-to-Phy）測試。但需要注意的是，這類區域性測試結果可能無法準確反映整個系統的時間特性。
北匯資訊不僅提供標準測試用例集，還支援使用者根據系統的特殊場景定製開發新的測試用例。例如，使用者可以設計一對多通訊、多對一通訊等模擬真實應用場景的測試。
此外，時間特性測試（如延遲測試）依賴於全域性同步時鐘，以確保收發雙方具有共同的時間基準。這一點在設計和執行測試時需要特別關注。
為了實時監控時鐘同步系統的執行狀態，北匯資訊採用了 TSN CoreSolution 工具，能夠對網路中每個節點的 1 PPS（每秒脈衝）訊號進行實時監測。透過這種方式，我們可以準確判斷時鐘同步系統是否正常工作，以及其誤差是否滿足系統要求。
在硬體方面，使用的核心工具是 TSN Box。這是一個專門設計用於 TSN 系統模擬和分析的硬體系統。TSN Box 具備豐富的介面支援，尤其是能夠採集 1 PPS 訊號，這使得它成為時鐘同步監測的理想裝置。
與 TSN Box 配套的是上位機軟體 TSN Tools。這款軟體提供了強大的資料分析和視覺化功能。透過 TSN Tools，我們能夠：
- 實時處理從 TSN Box 採集的資料
- 進行深入的時鐘同步效能分析
- 提供直觀的視覺化介面，便於工程師快速識別和解決同步問題
這套工具組合（TSN Box 硬體 + TSN Tools 軟體）為我們提供了一個全面的 TSN 系統分析平臺。它不僅能夠監測時鐘同步，還能對整個 TSN 網路的效能進行全方位的評估和最佳化。
除了時鐘同步監測，TSN Box 還具備捕獲乙太網原始資料的能力，這為深入分析 DDS-TSN 系統的行為提供了重要支援。值得注意的是，所有捕獲的資料都以 gPTP 為基準時鐘，確保了資料的時間一致性。
在實際應用中，測試過程中產生的各類資料，如 DDS 介面測試日誌、乙太網資料幀的時間戳等，都可以被放置在同一時間基準上進行分析。這種統一的時間視角使得測試工程師能夠全面、準確地評估系統效能。
透過對這些統一基準的資料進行分析，我們可以輕鬆地識別並量化系統中每個環節的具體延遲。這種精細化的延遲分析對於最佳化系統效能、滿足嚴格的實時要求至關重要。
總結
本文全面介紹了軟體定義汽車對網路通訊技術的新需求，並闡述瞭如何透過 DDS 與 TSN 的融合來提升系統的動態靈活性和實時效能力，最後介紹了針對 DDS 與 TSN 融合系統的測試解決方案。針對複雜的 DDS-TSN 系統，文中提出了一套完整的“應用到應用”的系統級測試方法，透過植入測試程式、監控時鐘同步、捕獲網路資料包並進行統一時間基準的分析，可以全面評估和驗證系統的實時效能指標，為軟體定義汽車的軟硬體架構整合提供有力支援。
北匯資訊在車載網路通訊和中介軟體測試領域擁有多年經驗，已為眾多整車廠和供應商提供過 DDS、TSN 等技術的諮詢和測試服務，擁有成熟的解決方案和專業的技術團隊，能夠滿足客戶在軟體定義汽車網路通訊架構整合和測試驗證等方面的各種需求，期待各位讀者與我們進一步交流。