基于DDS 的車(chē)載分布式系統(tǒng)的測(cè)試策略探討

王昊天

（上海北匯信息科技有限公司， 北京 102208）

1 概述

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

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

2 SOME/IP與DDS

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

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

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

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

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

3 DDS的測(cè)試策略和方案探討

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

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

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

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

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

3.2 DDS配置測(cè)試

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

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

圖1 DDS配置測(cè)試部分條目參考

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

4 DDS服務(wù)接口測(cè)試

服務(wù)接口測(cè)試的核心工作是服務(wù)請(qǐng)求的仿真，這意味著測(cè)試工具要集成DDS中間件，使其能夠仿真客戶端的行為。遺憾的是，截至此文撰寫(xiě)時(shí)，行業(yè)內(nèi)沒(méi)有針對(duì)DDS服務(wù)測(cè)試的成熟工具可以使用。

我們可以使用多種方案來(lái)完成DDS服務(wù)接口測(cè)試，比如利用CANoe的Socket或FDX接口，或其他測(cè)試框架（如Robot Framework和ECU TEST），開(kāi)發(fā)“DDS適配器”，來(lái)完成服務(wù)的仿真和測(cè)試。如圖3所示。

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

5 總結(jié)

隨著軟件定義汽車(chē)和車(chē)載以太網(wǎng)的快速發(fā)展，傳統(tǒng)IT行業(yè)很多分布式系統(tǒng)技術(shù)也逐步運(yùn)用到汽車(chē)中，比如本文提到的中間件技術(shù)。然而引入這些不同的技術(shù)時(shí)，我們必須意識(shí)到，汽車(chē)除了是一個(gè)智能終端設(shè)備，它的本質(zhì)屬性是交通工具，在把汽車(chē)交付到消費(fèi)者手中之前，廠商應(yīng)進(jìn)行充分的驗(yàn)證和測(cè)試，保證產(chǎn)品的品質(zhì)。本文介紹了中間件的概念以及SOME/IP、DDS等技術(shù)，對(duì)DDS以及基于DDS的SOA系統(tǒng)的測(cè)試策略進(jìn)行探討，歡迎各位讀者提出寶貴意見(jiàn)，與我們進(jìn)一步交流。