中介軟體•SOME/IP•DDS

“中介軟體”是一個比較抽象和寬泛的概念，它並不特指一種具體的技術，其概念起源於複雜分散式軟體系統的開發，其目的是實現軟體元件之間進行資料交換，使軟體元件之間實現解耦。這種資料交換通常是通過網路進行，而中介軟體的任務就是確保網路本身對軟體元件是透明的。比如我們所熟知的SOME/IP就是一種典型的中介軟體技術實現。使用中介軟體能夠簡化系統的開發，提高管理和測試效率。

車載網路通訊的中介軟體有其特殊之處。車載軟體系統可能十分複雜，這些系統可能分佈在一個ECU的不同模組裡，或在同一個ECU模組的不同程序中，也可能分佈在不同ECU中。這些不同的模組或不同的ECU可能使用不同的軟體架構和作業系統，比如符合POSIX要求的類Unix作業系統（如Linux和QNX），Classic AUTOSAR系統，Adaptive AUTOSAR系統等，中介軟體在這些不同的系統之間起到了重要的橋樑作用。

SOME/IP是最早應用在汽車上的通訊中介軟體，在2014年由寶馬率先實現了量產。但是近年來汽車行業對中介軟體技術的探索並未停止，目前主要有兩個方向。

一是對SOME/IP進行功能上的擴充套件，其主要的思路是給SOME/IP新增TLV（Type Length Value）支援，以實現更好的靈活性。我們知道SOME/IP的序列化採用了比較靜態的定義方式，比如SOME/IP的Payload中的引數的型別，引數的順序，位元組序等，都是在配置檔案中靜態定義的，那麼應用程式在使用這些型別時，必須要嚴格遵循配置檔案中的定義去解析資料。所謂TLV，簡單來說就是給每個引數新增一些附加的“標籤”資訊，比如型別資訊，長度資訊，這樣應用程式可以依賴這些“標籤”資訊動態解析引數。對TLV的支援將使軟體系統進一步解耦，讓應用程式以更靈活的方式使用SOME/IP。但是靈活性和高效率往往是魚與熊掌不可兼得，引入TLV的缺點也是顯著的，額外的“標籤”資訊將佔用更多的Payload空間，這會降低頻寬的利用率，對實時性有一定影響（尤其是對於資源有限的小型ECU）。

二是DDS（Data Distribution Service）。DDS是目前國防，航空等領域廣泛應用的通訊中介軟體技術，我們曾在往期文章中介紹過。DDS的核心規範有兩個，分別是DDS specification，以及 DDSI-RTPS specification。DDS specification定義了DDS的應用程式介面和基本行為，DDSI-RTPS specification定義了DDS的傳輸實現，目的是實現不同DDS產品的互操作性。除此之外，DDS在2017年釋出了DDS-RPC規範，使得DDS能夠基於釋出-訂閱模型實現遠端過程呼叫（RPC），滿足SOA架構的需求。

DDS和SOME/IP是在不同的應用場景和不同的需求下誕生的技術，所以它們之間註定有很大的區別。DDS有著更豐富的特性，尤其是對QoS的支援。但是相對於SOME/IP，DDS也有顯著的不足。首先，RTPS訊息頭部十分冗長，這會降低傳輸效率和實時性。另一方面，汽車作為一個相對封閉的系統，為了降低功耗，經常需要頻繁的喚醒和休眠，這就要求系統有非常快的啟動速度，而DDS並不是為這種場景設計的，DDS可能必須經過深入的優化才能滿足嚴苛的時間要求。最後，DDS目前只能在Adaptive AUTOSAR框架下執行，Classic AUTOSAR目前並不支援，儘管有廠商使用複雜驅動（DDS）的方式在Classic AUTOSAR平臺集成了DDS，但這並不是一種完美的解決方案。首先Classic AUTOSAR平臺往往資源有限，同時又有嚴苛的實時性要求，在其之上執行DDS顯得代價高昂；其次，通過複雜驅動意味著和硬體強相關，這會喪失軟體的可移植性，對於DDS這種基礎軟體元件，廠商要付出更多的開發、測試和維護的成本，這實際上也不符合AUTOSAR的初衷。

儘管目前有一些技術問題需要解決，但不可否認的是，DDS依然前途光明，國內很多OEM已經將DDS作為了下一代電子電器架構的基礎通訊技術，甚至已經實現了量產。

DDS的測試策略和方案探討

DDS協議一致性測試

DDS本質上一種傳統的工業基礎軟體，使用者購買了軟體，然後在系統裡每個節點上進行“安裝”。所以我們可以看到很多商用的DDS軟體產品，在其內部的測試流程中，有一個很重要的環節是“安裝測試（Install tests）”，目的是驗證DDS產品在常見平臺的相容性。而使用者在集成了DDS之後並不會過多的對DDS產品本身進行驗證，更側重應用層測試。所以這就造成了目前DDS生態裡缺少像TC8這種行業內標準化的測試規範，以及相應的測試工具。

車載電子電器系統的計算平臺五花八門，不同OEM，不同車型平臺，不同專案，其搭載的系統平臺（包括晶片架構，作業系統等）可能都有不同，這些不同的平臺相互的組合情況更難以計數。這種背景下，只依賴DDS產品供應商內部的“安裝測試”似乎顯得不足。

此外，正如上文所討論，為了讓DDS的功能和效能更符合車內通訊的要求，使用者需要對DDS產品進行定製裁剪和優化，尤其是針對非標準計算平臺實現的DDS（如Classic AUTOSAR平臺），在這個過程中使用者需要對產品進行充分的測試，才能保證裁剪或優化後的軟體仍然是可靠的。

不同DDS產品之間的互操作也是不可忽視的問題。OMG組織並不提供DDS軟體實現，各廠商可以根據該標準實現自己的DDS。儘管DDS釋出了DDSI-RTPS規範來保證不同DDS實現之間的互操作性，但是這裡提到的“互操作性”，可能並沒有經過充分的測試和驗證。儘管軟體開發者可能會在內部的產品測試階段進行與其他產品的互操作測試，但是這很難覆蓋DDS的所有功能特性，也很難覆蓋目前市面上所有DDS產品的所有可能出現的組合。此外，DDS的軟體實現經常與OMG規範產生偏離，比如DDS實現不支援某些OMG規範中的特性，或者DDS實現中增加了OMG規範中沒有要求的額外的功能特性，這種情況可能也會引發互操作問題。基於這種考慮，使用者根據實際情況對系統進行鍼對性的互操作測試也許是更好的選擇。

為了滿足這種需求，北匯信息正與合作伙伴開展DDS一致性測試測試包的開發工作，以實現DDS產品在特定平臺下的功能特性一致性驗證，具體包括：

• API介面測試
• DDS基本行為測試
• QoS測試
• DDS Discovery測試
• X-Types測試
• DDS-Security測試
• 互操作測試
• 效能測試

DDS配置測試

DDS一個很大的特點是支援“開箱即用”，即使用者不需要對系統做任何特殊配置即可使用DDS，比如IP地址，埠號，DDS系統中每個Participant，DataReader和DataWriter的ID等等，所有的這一切都是由DDS/RTPS進行自動配置，動態的發現系統裡的節點。使用者只需要在IDL檔案中定義自己的型別，就可以進行應用程式的開發，這對網路架構設計者和應用開發者都非常的友好。

為了滿足不同系統對中介軟體功能和效能不同的需求，DDS也提供了多種方式允許使用者對DDS的行為特性進行進一步調節，比如QoS配置，RTPS通訊層面的配置等。如果說使用者進行了這些配置工作，我們需要設計測試方案來驗證這些配置的一致性。這一部分可基於Vector CANoe option Ethernet，通過程式設計和定製開發來實現。使用Vector提供的多種乙太網介面卡，編寫指令碼進行RTPS訊息的解析，並從中提取這些配置資訊，驗證其與使用者配置規範的一致性。

圖1 DDS配置測試部分條目參考

圖2  基於CANoe實現的DDS配置測試工程示例

DDS服務介面測試

服務介面測試的核心工作是服務請求的模擬，這意味著測試工具要整合DDS中介軟體，使其能夠模擬客戶端的行為。遺憾的是，截至此文撰寫時，行業內尚無針對DDS服務測試的成熟的貨架式工具。

北匯信息基於積累的工程經驗，通過定製化開發，目前可提供多種服務模擬方案以完成DDS服務介面測試。比如利用CANoe的Socket或FDX介面，或其他測試框架（如Robot Framework和ECU TEST），開發“DDS介面卡”，來完成服務的模擬和測試。

圖3 基於CANoe FDX實現的“DDS介面卡”示意圖

總結

隨著軟體定義汽車和車載乙太網的快速發展，傳統IT行業很多分散式系統技術也逐步的運用到汽車中，比如我們今天提到的中介軟體技術。然而引入這些不同的技術時，我們必須意識到，汽車除了是一個智慧終端裝置，它的本質屬性是交通工具，在把汽車交付到消費者手中之前，廠商應進行充分的驗證和測試，保證產品的質量。本篇文章介紹了中介軟體的概念，以及SOME/IP，DDS等技術，結合北匯信息多年來在電子電器測試方面的經驗，對DDS以及基於DDS的SOA系統的測試策略進行探討，並簡單介紹了北匯信息提供的測試方案，後續將給大家帶來DDS一致性測試等內容的專題介紹，歡迎各位讀者提出寶貴意見，與我們進一步交流。