“中間件”是一個比較抽象和寬泛的概念，它并不特指一種具體的技術(shù)，其概念起源于復雜分布式軟件系統(tǒng)的開發(fā)，其目的是實現(xiàn)軟件組件之間進行數(shù)據(jù)交換，使軟件組件之間實現(xiàn)解耦。這種數(shù)據(jù)交換通常是通過網(wǎng)絡(luò)進行，而中間件的任務就是確保網(wǎng)絡(luò)本身對軟件組件是透明的。比如我們所熟知的SOME/IP就是一種典型的中間件技術(shù)實現(xiàn)。使用中間件能夠簡化系統(tǒng)的開發(fā)，提高管理和測試效率。

車載網(wǎng)絡(luò)通信的中間件有其特殊之處。車載軟件系統(tǒng)可能十分復雜，這些系統(tǒng)可能分布在一個ECU的不同模塊里，或在同一個ECU模塊的不同進程中，也可能分布在不同ECU中。這些不同的模塊或不同的ECU可能使用不同的軟件架構(gòu)和操作系統(tǒng)，比如符合POSIX要求的類Unix操作系統(tǒng)（如Linux和QNX），Classic AUTOSAR系統(tǒng)，Adaptive AUTOSAR系統(tǒng)等，中間件在這些不同的系統(tǒng)之間起到了重要的橋梁作用。

SOME/IP是最早應用在汽車上的通信中間件，在2014年由寶馬率先實現(xiàn)了量產(chǎn)。但是近年來汽車行業(yè)對中間件技術(shù)的探索并未停止，目前主要有兩個方向。

一是對SOME/IP進行功能上的擴展，其主要的思路是給SOME/IP添加TLV（Type Length Value）支持，以實現(xiàn)更好的靈活性。我們知道SOME/IP的序列化采用了比較靜態(tài)的定義方式，比如SOME/IP的Payload中的參數(shù)的類型，參數(shù)的順序，字節(jié)序等，都是在配置文件中靜態(tài)定義的，那么應用程序在使用這些類型時，必須要嚴格遵循配置文件中的定義去解析數(shù)據(jù)。所謂TLV，簡單來說就是給每個參數(shù)添加一些附加的“標簽”信息，比如類型信息，長度信息，這樣應用程序可以依賴這些“標簽”信息動態(tài)解析參數(shù)。對TLV的支持將使軟件系統(tǒng)進一步解耦，讓應用程序以更靈活的方式使用SOME/IP。但是靈活性和高效率往往是魚與熊掌不可兼得，引入TLV的缺點也是顯著的，額外的“標簽”信息將占用更多的Payload空間，這會降低帶寬的利用率，對實時性有一定影響（尤其是對于資源有限的小型ECU）。

二是DDS（Data Distribution Service）。DDS是目前國防，航空等領(lǐng)域廣泛應用的通信中間件技術(shù)，我們曾在往期文章中介紹過。DDS的核心規(guī)范有兩個，分別是DDS specification，以及 DDSI-RTPS specification。DDS specification定義了DDS的應用程序接口和基本行為，DDSI-RTPS specification定義了DDS的傳輸實現(xiàn)，目的是實現(xiàn)不同DDS產(chǎn)品的互操作性。除此之外，DDS在2017年發(fā)布了DDS-RPC規(guī)范，使得DDS能夠基于發(fā)布-訂閱模型實現(xiàn)遠程過程調(diào)用（RPC），滿足SOA架構(gòu)的需求。

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

盡管目前有一些技術(shù)問題需要解決，但不可否認的是，DDS依然前途光明，國內(nèi)很多OEM已經(jīng)將DDS作為了下一代電子電器架構(gòu)的基礎(chǔ)通信技術(shù)，甚至已經(jīng)實現(xiàn)了量產(chǎn)。

DDS的測試策略和方案探討

DDS協(xié)議一致性測試

DDS本質(zhì)上一種傳統(tǒng)的工業(yè)基礎(chǔ)軟件，用戶購買了軟件，然后在系統(tǒng)里每個節(jié)點上進行“安裝”。所以我們可以看到很多商用的DDS軟件產(chǎn)品，在其內(nèi)部的測試流程中，有一個很重要的環(huán)節(jié)是“安裝測試（Install tests）”，目的是驗證DDS產(chǎn)品在常見平臺的兼容性。而用戶在集成了DDS之后并不會過多的對DDS產(chǎn)品本身進行驗證，更側(cè)重應用層測試。所以這就造成了目前DDS生態(tài)里缺少像TC8這種行業(yè)內(nèi)標準化的測試規(guī)范，以及相應的測試工具。

車載電子電器系統(tǒng)的計算平臺五花八門，不同OEM，不同車型平臺，不同項目，其搭載的系統(tǒng)平臺（包括芯片架構(gòu)，操作系統(tǒng)等）可能都有不同，這些不同的平臺相互的組合情況更難以計數(shù)。這種背景下，只依賴DDS產(chǎn)品供應商內(nèi)部的“安裝測試”似乎顯得不足。

此外，正如上文所討論，為了讓DDS的功能和性能更符合車內(nèi)通信的要求，用戶需要對DDS產(chǎn)品進行定制裁剪和優(yōu)化，尤其是針對非標準計算平臺實現(xiàn)的DDS（如Classic AUTOSAR平臺），在這個過程中用戶需要對產(chǎn)品進行充分的測試，才能保證裁剪或優(yōu)化后的軟件仍然是可靠的。

不同DDS產(chǎn)品之間的互操作也是不可忽視的問題。OMG組織并不提供DDS軟件實現(xiàn)，各廠商可以根據(jù)該標準實現(xiàn)自己的DDS。盡管DDS發(fā)布了DDSI-RTPS規(guī)范來保證不同DDS實現(xiàn)之間的互操作性，但是這里提到的“互操作性”，可能并沒有經(jīng)過充分的測試和驗證。盡管軟件開發(fā)者可能會在內(nèi)部的產(chǎn)品測試階段進行與其他產(chǎn)品的互操作測試，但是這很難覆蓋DDS的所有功能特性，也很難覆蓋目前市面上所有DDS產(chǎn)品的所有可能出現(xiàn)的組合。此外，DDS的軟件實現(xiàn)經(jīng)常與OMG規(guī)范產(chǎn)生偏離，比如DDS實現(xiàn)不支持某些OMG規(guī)范中的特性，或者DDS實現(xiàn)中增加了OMG規(guī)范中沒有要求的額外的功能特性，這種情況可能也會引發(fā)互操作問題。基于這種考慮，用戶根據(jù)實際情況對系統(tǒng)進行針對性的互操作測試也許是更好的選擇。

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

▲API接口測試

▲DDS基本行為測試

▲QoS測試

▲DDS Discovery測試

▲X-Types測試

▲DDS-Security測試

▲互操作測試

▲性能測試

DDS配置測試

DDS一個很大的特點是支持“開箱即用”，即用戶不需要對系統(tǒng)做任何特殊配置即可使用DDS，比如IP地址，端口號，DDS系統(tǒng)中每個Participant，DataReader和DataWriter的ID等等，所有的這一切都是由DDS/RTPS進行自動配置，動態(tài)的發(fā)現(xiàn)系統(tǒng)里的節(jié)點。用戶只需要在IDL文件中定義自己的類型，就可以進行應用程序的開發(fā)，這對網(wǎng)絡(luò)架構(gòu)設(shè)計者和應用開發(fā)者都非常的友好。

為了滿足不同系統(tǒng)對中間件功能和性能不同的需求，DDS也提供了多種方式允許用戶對DDS的行為特性進行進一步調(diào)節(jié)，比如QoS配置，RTPS通信層面的配置等。如果說用戶進行了這些配置工作，我們需要設(shè)計測試方案來驗證這些配置的一致性。這一部分可基于Vector CANoe option Ethernet，通過編程和定制開發(fā)來實現(xiàn)。使用Vector提供的多種以太網(wǎng)接口卡，編寫腳本進行RTPS消息的解析，并從中提取這些配置信息，驗證其與用戶配置規(guī)范的一致性。

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

圖2 基于CANoe實現(xiàn)的DDS配置測試工程示例

DDS服務接口測試

服務接口測試的核心工作是服務請求的仿真，這意味著測試工具要集成DDS中間件，使其能夠仿真客戶端的行為。遺憾的是，截至此文撰寫時，行業(yè)內(nèi)尚無針對DDS服務測試的成熟的貨架式工具。

北匯信息基于積累的工程經(jīng)驗，通過定制化開發(fā)，目前可提供多種服務仿真方案以完成DDS服務接口測試。比如利用CANoe的Socket或FDX接口，或其他測試框架（如Robot Framework和ECU TEST），開發(fā)“DDS適配器”，來完成服務的仿真和測試。

圖3基于CANoe FDX實現(xiàn)的“DDS適配器”示意圖

總結(jié)

隨著軟件定義汽車和車載以太網(wǎng)的快速發(fā)展，傳統(tǒng)IT行業(yè)很多分布式系統(tǒng)技術(shù)也逐步的運用到汽車中，比如我們今天提到的中間件技術(shù)。然而引入這些不同的技術(shù)時，我們必須意識到，汽車除了是一個智能終端設(shè)備，它的本質(zhì)屬性是交通工具，在把汽車交付到消費者手中之前，廠商應進行充分的驗證和測試，保證產(chǎn)品的質(zhì)量。

本篇文章介紹了中間件的概念，以及SOME/IP，DDS等技術(shù)，結(jié)合北匯信息多年來在電子電器測試方面的經(jīng)驗，對DDS以及基于DDS的SOA系統(tǒng)的測試策略進行探討，并簡單介紹了北匯信息提供的測試方案，后續(xù)將給大家?guī)鞤DS一致性測試等內(nèi)容的專題介紹。