全面解讀DDS和TSN融合技術(shù)及其測試方案

作者 | 梵高先生

小編 | 不吃豬頭肉

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DDS 的工作依賴于兩種時鐘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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