作者 | 梵高先生

小編 | 不吃豬頭肉

軟件定義汽車對(duì)網(wǎng)絡(luò)通信技術(shù)的影響

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

圖 2: 標(biāo)準(zhǔn)化的基礎(chǔ)軟件和硬件平臺(tái)

功能上移的本質(zhì)，是應(yīng)用軟件向上移動(dòng)，而底層基礎(chǔ)軟件和硬件平臺(tái)則可標(biāo)準(zhǔn)化，實(shí)現(xiàn)長(zhǎng)周期維護(hù)。簡(jiǎn)單來說，這可以稱為“軟硬分離”，或“應(yīng)用軟件與基礎(chǔ)軟件/硬件平臺(tái)分離”。

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

DDS 的關(guān)鍵特性
首先從通信模式的角度來看。很多人習(xí)慣將 DDS 與 SOME/IP 進(jìn)行對(duì)比，但實(shí)際上兩者遵循的是完全不同的通信模式，有不同的應(yīng)用場(chǎng)景。

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

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

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

圖 6: DDS 的以數(shù)據(jù)為中心的概念以及解耦

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

2.DDS 的平臺(tái)無關(guān)
DDS 的另一大特性是平臺(tái)無關(guān)性。這里的“平臺(tái)”泛指操作系統(tǒng)、傳輸協(xié)議等底層依賴。DDS 實(shí)現(xiàn)平臺(tái)無關(guān)的方式是，盡量不依賴于平臺(tái)的獨(dú)有復(fù)雜功能，而將這些功能需求自己實(shí)現(xiàn)，然后通過統(tǒng)一的標(biāo)準(zhǔn)化接口對(duì)外提供服務(wù)。

圖 7: DDS 的平臺(tái)無關(guān)
因此，DDS 的可移植性非常良好，只要有基本的 UDP 通信支持，就可以運(yùn)行 DDS。事實(shí)上，DDS 與 UDP 被認(rèn)為是最佳拍檔，因?yàn)?UDP 最為簡(jiǎn)單，幾乎沒有 QoS 保證。而 DDS 則希望底層協(xié)議盡可能簡(jiǎn)單，因?yàn)橹T如 QoS 等復(fù)雜功能需求，DDS 自身已實(shí)現(xiàn)并對(duì)應(yīng)用開放。
不過，DDS 這種“自力更生”的做法，也帶來了一個(gè)印象 —— 在很多人眼里，DDS 顯得過于“重”、過于復(fù)雜，資源開銷較大。筆者認(rèn)為這是一種取舍：DDS 一邊提供了豐富特性、標(biāo)準(zhǔn)統(tǒng)一接口和平臺(tái)無關(guān)性，作為代價(jià)，另一邊就是較高的資源開銷和軟件復(fù)雜度。這是一種權(quán)衡，沒有絕對(duì)的對(duì)錯(cuò)。

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

圖 8: DDS-RPC（圖片來自 https://www.omg.org/spec/DDS-RPC ）
OMG 發(fā)布了 DDS-RPC 標(biāo)準(zhǔn)規(guī)范，其中給出了一個(gè)參考實(shí)現(xiàn)。做法是在 DDS Topic 的基礎(chǔ)上再封裝一層，對(duì)于請(qǐng)求報(bào)文，添加包含客戶端 GUID （全局唯一 ID） 和序列號(hào)的報(bào)文頭，以讓服務(wù)端識(shí)別來源和追蹤序列。服務(wù)端回復(fù)時(shí)，將服務(wù)端 ID、序列號(hào)及原請(qǐng)求頭復(fù)制到響應(yīng)報(bào)文頭中，使客戶端能對(duì)應(yīng)到之前的請(qǐng)求。

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

技術(shù)實(shí)現(xiàn)方面，我們可能需要自行解決一系列額外的技術(shù)問題。

功能應(yīng)用方面，這種使用方式可能會(huì)限制 DDS 原有的一些獨(dú)特優(yōu)勢(shì)。

資源消耗方面，DDS 較高的系統(tǒng)資源占用可能成為一個(gè)不容忽視的負(fù)擔(dān)。

因此，在做出技術(shù)路線的選擇之前，我們必須審慎評(píng)估其帶來的收益是否足以抵消相應(yīng)的成本和潛在風(fēng)險(xiǎn)。

DDS 與 TSN 的融合
1.實(shí)時(shí)性是系統(tǒng)性問題
首先需要明確，實(shí)時(shí)性是一個(gè)系統(tǒng)性挑戰(zhàn)，原因在于汽車電子電氣系統(tǒng)本身就是一個(gè)錯(cuò)綜復(fù)雜的大系統(tǒng)。尤其是在車載以太網(wǎng)進(jìn)入汽車領(lǐng)域后，Linux、Android、QNX 等復(fù)雜操作系統(tǒng)也開始大量應(yīng)用，這使得確保整體實(shí)時(shí)性變得更加困難。

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

除了網(wǎng)絡(luò)層面，大部分不確定性實(shí)際上來自于終端節(jié)點(diǎn)內(nèi)部，而這部分無法依賴 TSN 來解決。由于終端內(nèi)部的復(fù)雜性，很難有一個(gè)標(biāo)準(zhǔn)化的簡(jiǎn)單方案來全面解決內(nèi)部實(shí)時(shí)性問題。
那么針對(duì) DDS，我們可以采取以下措施來提高實(shí)時(shí)性和確定性:

?內(nèi)存申請(qǐng)固化：減少不可預(yù)測(cè)的動(dòng)態(tài)內(nèi)存申請(qǐng)

?通信關(guān)系固化：降低正常使用場(chǎng)景下通信關(guān)系的動(dòng)態(tài)變化，減少節(jié)點(diǎn)動(dòng)態(tài)進(jìn)出

?交互過程固化：減少 DDS 協(xié)議維護(hù)數(shù)據(jù)可靠性而產(chǎn)生的額外數(shù)據(jù)交換

?數(shù)據(jù)長(zhǎng)度限制：避免單次發(fā)送/接收時(shí)間超出預(yù)期

總之，我們可以在一定程度上限制 DDS 的動(dòng)態(tài)性特征，以換取更好的可預(yù)期性和實(shí)時(shí)性。這是一種權(quán)衡，需要根據(jù)具體場(chǎng)景需求來平衡動(dòng)態(tài)性和實(shí)時(shí)性。
2.通過 TSN 改善 DDS 時(shí)間控制
前面我們從全局角度分析了實(shí)時(shí)性問題，下面針對(duì)一些具體點(diǎn)做進(jìn)一步探討。

DDS 的工作依賴于兩種時(shí)鐘

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

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

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

2.TRANSPORT_PRIORITY - 同理，應(yīng)用層可以指定不同數(shù)據(jù)流的傳輸優(yōu)先級(jí)，但無法直接對(duì)底層傳輸層進(jìn)行優(yōu)先級(jí)調(diào)度。

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

1.將 RTPS 消息映射到 UDP/IP 上，再通過 TSN 傳輸 UDP 數(shù)據(jù)包。這是一種相對(duì)容易實(shí)現(xiàn)的方式，因?yàn)橹恍鑼⒃袀鹘y(tǒng)以太網(wǎng)改為 TSN 以太網(wǎng)，對(duì)系統(tǒng)修改較小。但缺點(diǎn)是數(shù)據(jù)需經(jīng) UDP/IP 協(xié)議棧再到 TSN 網(wǎng)絡(luò)，實(shí)時(shí)性會(huì)受操作系統(tǒng)內(nèi)核調(diào)度影響。

2.將 RTPS 直接映射到 TSN 網(wǎng)絡(luò)的以太網(wǎng)幀上，繞過 UDP/IP 協(xié)議棧的影響。這種方式可有效提高實(shí)時(shí)性，但需對(duì) DDS 實(shí)現(xiàn)做大量修改，研發(fā)工作量較大。

兩種方案各有利弊，應(yīng)根據(jù)具體場(chǎng)景的實(shí)時(shí)性需求和開發(fā)投入進(jìn)行權(quán)衡選擇。

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

1.簡(jiǎn)單的獨(dú)立網(wǎng)絡(luò)節(jié)點(diǎn)

2.復(fù)雜節(jié)點(diǎn)，內(nèi)部包含多個(gè)通過板載交換機(jī)通信的子系統(tǒng)

3.支持多進(jìn)程的高級(jí)操作系統(tǒng)節(jié)點(diǎn)，進(jìn)程間通信采用基于共享內(nèi)存的 DDS

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

1.實(shí)時(shí)處理從 TSN Box 采集的數(shù)據(jù)

2.進(jìn)行深入的時(shí)鐘同步性能分析

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

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

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