作者 |梵高先生小編 | 吃不飽
01軟件定義汽車對測試的影響
OEM和供應(yīng)商之間傳統(tǒng)的合作模式是由OEM釋放技術(shù)需求，供應(yīng)商按照需求進(jìn)行軟件和硬件實(shí)現(xiàn)，最終交付的是完整的軟硬件系統(tǒng)。隨著集中式架構(gòu)的逐步演進(jìn)，這種合作模式正在被打破——標(biāo)準(zhǔn)化的高性能硬件平臺、高級操作系統(tǒng)、中間件以及虛擬化技術(shù)得以應(yīng)用，使硬件越來越抽象化，可以使應(yīng)用程序脫離硬件，相對獨(dú)立的進(jìn)行開發(fā)和測試。這就允許ECU的開發(fā)可以進(jìn)行更細(xì)致的分工，比如硬件由供應(yīng)商A提供，操作系統(tǒng)和基礎(chǔ)軟件由供應(yīng)商B進(jìn)行開發(fā)或集成，應(yīng)用軟件由供應(yīng)商C開發(fā)等等。可以說OEM和供應(yīng)商的合作模式更靈活了。 OEM作為集成方，需要對來自不同供應(yīng)商的模塊進(jìn)行“驗(yàn)收測試”，其目的是確認(rèn)該模塊是否按照需求進(jìn)行實(shí)現(xiàn)。根據(jù)需求類型可以將驗(yàn)收測試劃分為三個部分：針對行業(yè)標(biāo)準(zhǔn)的驗(yàn)收測試，針對OEM企業(yè)標(biāo)準(zhǔn)的驗(yàn)收測試，以及針對車型項(xiàng)目需求的驗(yàn)收測試。其中每個部分又根據(jù)測試方法的不同而分成兩種類型，分別是靜態(tài)審查和動態(tài)測試。 OEM和供應(yīng)商的合作模式的改變對其中動態(tài)測試的部分的影響很大。進(jìn)行動態(tài)測試時(shí)，測試環(huán)境需要為被測對象提供運(yùn)行環(huán)境，并且能夠仿真系統(tǒng)中的其他部分（或稱殘余系統(tǒng)）與被測對象的交互。在傳統(tǒng)的OEM和供應(yīng)商的合作模式下，供應(yīng)商交付的是ECU實(shí)體，是包含軟件和硬件的一整套系統(tǒng)，所以這時(shí)候所謂的動態(tài)測試指的就是ECU的HiL測試。
這種情況下ECU和殘余系統(tǒng)的交互實(shí)現(xiàn)方案相對來說是標(biāo)準(zhǔn)化的，如CAN/LIN等總線信號以及I/O信號，目前有非常成熟的解決方案。而當(dāng)OEM和供應(yīng)商的合作模式改變之后，供應(yīng)商交付物的形態(tài)更加多樣，它可能是一個完整的ECU，或者一個操作系統(tǒng)，或者一個中間件，或者一個應(yīng)用軟件。這種多樣性對動態(tài)測試環(huán)境的搭建帶來了挑戰(zhàn)，比如把應(yīng)用程序作為被測對象，我們需要模擬被測對象依賴的全部環(huán)境，包括操作系統(tǒng)、依賴庫和硬件等，十分困難。因?yàn)闇y試方案不像原來一樣標(biāo)準(zhǔn)化了，測試系統(tǒng)很難像流水線一樣生產(chǎn)出來。新的模式下，我們需要和每一個客戶深入溝通，明確測試對象是什么，邊界在哪里，需求是什么，然后才能進(jìn)一步評估，制定合適的測試方案。
02DDS中間件的測試策略
DDS中間件即是上述新模式下的一個典型例子，那么如何對這種產(chǎn)品進(jìn)行測試呢？ 對于成熟的標(biāo)準(zhǔn)的軟件產(chǎn)品，比如Linux，QNX等，我們其實(shí)并不需要對其核心功能進(jìn)行太多測試，因?yàn)檐浖S商或開發(fā)者會在產(chǎn)品開發(fā)過程中進(jìn)行大量測試，市場和時(shí)間也能充分證明其質(zhì)量的可靠性，這也是我們選擇成熟軟件模塊的意義所在。然而，當(dāng)我們把來自不同供應(yīng)商的標(biāo)準(zhǔn)產(chǎn)品放到同一個系統(tǒng)或網(wǎng)絡(luò)中協(xié)同工作時(shí)，必須考慮到它們之間是否兼容，也就是互操作問題。 那么對DDS來說，會出現(xiàn)互操作問題嗎？這需要分情況討論。 如果參與DDS通信的節(jié)點(diǎn)均是基于高性能SoC實(shí)現(xiàn)，并且運(yùn)行標(biāo)準(zhǔn)操作系統(tǒng)（如Linux，QNX等），得益于DDS良好的可移植性和OS無關(guān)的特性，OEM可以采用成熟的商業(yè)產(chǎn)品或開源產(chǎn)品，然后部署在每個節(jié)點(diǎn)中。此時(shí)，若所有節(jié)點(diǎn)運(yùn)行著相同的來源和版本的DDS中間件，顯然這種模式下我們可以忽略互操作的問題。 然而，目前也有不少廠商正在嘗試或已經(jīng)實(shí)現(xiàn)向MCU中集成DDS中間件。受限于MCU性能和資源，DDS軟件必須經(jīng)過適當(dāng)裁剪和優(yōu)化才能在MCU的環(huán)境下運(yùn)行。同時(shí)，MCU軟硬件高度耦合，軟件移植、復(fù)用和維護(hù)并不容易，這種情況下我們可能不能再將其視為成熟的軟件模塊，廠商因此需要對DDS軟件進(jìn)行大量的測試來保證DDS系統(tǒng)的質(zhì)量。這種情況下，為了避免與其他DDS軟件互通時(shí)產(chǎn)生交互問題，互操作測試是必不可少的。除了上述情況，如果DDS中間件來源或版本存在差別，互操作性測試也將是十分必要的。 除了互操作測試，另一個更重要的關(guān)注點(diǎn)是系統(tǒng)測試，具體來說是DDS中間件集成至目標(biāo)平臺后，會不會出現(xiàn)系統(tǒng)性問題。因?yàn)檐囕d電子電器系統(tǒng)的計(jì)算平臺五花八門，不同車型平臺，不同項(xiàng)目，其搭載的系統(tǒng)平臺（包括芯片架構(gòu)，操作系統(tǒng)等）可能都有不同，甚至還有像基于MCU的DDS這種嵌入式軟件，這些不同的平臺相互的組合情況，DDS QoS配置組合情況，以及復(fù)雜的網(wǎng)絡(luò)配置情況（如DDS-TSN），更難以計(jì)數(shù)。盡管DDS協(xié)議棧廠商可能會驗(yàn)證DDS產(chǎn)品與常見平臺的兼容性，但是這很難覆蓋所有可能的系統(tǒng)配置。所以我們認(rèn)為在上述情況下對DDS中間件進(jìn)行功能和性能測試是有必要的。
03DDS協(xié)議測試工具介紹
基于上文對測試策略的討論和實(shí)踐總結(jié)，北匯信息與南京臻融軟件科技合作開發(fā)了DDS協(xié)議測試套件，該產(chǎn)品能夠在特定系統(tǒng)環(huán)境下驗(yàn)證DDS中間件的功能和性能，以及不同的DDS產(chǎn)品之間的互操作性。

南京臻融軟件科技有限公司多年來專注于DDS產(chǎn)品與相關(guān)工具鏈的自主研發(fā)。其產(chǎn)品ZRDDS是我國首個100%自主研制并被OMG組織官方認(rèn)證的DDS產(chǎn)品。

圖1：DDS協(xié)議測試的測試框架示意 圖1顯示了DDS協(xié)議測試的測試框架示意。上位機(jī)中運(yùn)行的DDS Test Frame軟件能夠提供圖形化的用戶界面，具備測試用例管理，測試用例執(zhí)行監(jiān)控，測試報(bào)告生成，測試系統(tǒng)配置等功能。DDS Tester是專門為測試而開發(fā)的應(yīng)用程序，在開始測試之前需要將此應(yīng)用植入被測系統(tǒng)的每個節(jié)點(diǎn)內(nèi)部。測試執(zhí)行過程中，上位機(jī)將指令下發(fā)至DDS Tester，DDS Tester按照指令內(nèi)容執(zhí)行操作，比如調(diào)用某個應(yīng)用程序接口，并將結(jié)果返回至上位機(jī)。其角色類似于TC8 TCP/IP測試中的Upper Tester。得益于DDS標(biāo)準(zhǔn)化的應(yīng)用程序接口，理論上DDS Tester可在不同供應(yīng)商的DDS產(chǎn)品之間輕松移植。

當(dāng)然，DDS節(jié)點(diǎn)并不一定只通過以太網(wǎng)進(jìn)行通信，其它還包括板載交換機(jī)的介質(zhì)無關(guān)接口，共享內(nèi)存，或者本地環(huán)回網(wǎng)絡(luò)等等，測試環(huán)境可以根據(jù)系統(tǒng)的實(shí)際情況進(jìn)行搭建。

DDS協(xié)議測試規(guī)范/用例完全自主設(shè)計(jì)開發(fā)，并且在多年的項(xiàng)目實(shí)踐中不斷進(jìn)行迭代和優(yōu)化，目前可以覆蓋OMG DDS 1.4所定義的DCPS的核心功能，包括DDS應(yīng)用程序接口的行為，QoS行為，以及性能測試，共計(jì)400余條測試用例，通過所開發(fā)的測試腳本套件，全部可實(shí)現(xiàn)自動化執(zhí)行。 04DDS協(xié)議測試實(shí)踐
如下示例展示了DDS測試的執(zhí)行過程。
圖2：測試環(huán)境 圖3：DDS Tester 運(yùn)行界面 測試環(huán)境如圖2所示，為便于展示，被測系統(tǒng)為Windows主機(jī)中運(yùn)行的兩臺Ubuntu虛擬機(jī)，兩臺虛擬機(jī)中均運(yùn)行DDS Tester。被測DDS為某DDS中間件產(chǎn)品，目前在汽車行業(yè)內(nèi)已經(jīng)得到較廣應(yīng)用。 在上位機(jī)軟件DDS Test Frame中選擇并執(zhí)行測試用例，如圖4所示。 圖4：在DDS Test Frame中執(zhí)行測試用例 我們以DisposeWTimeStamp_WrongHandle這條失敗的測試用例來說明一下測試問題的分析步驟。測試步驟如下表所示。

?
在這條測試用例中，DDS Test Frame發(fā)送指令，使DDS Tester創(chuàng)建同一個Topic的兩個數(shù)據(jù)，分別為Data1和Data2，Topic中指定“key”為鍵，不同鍵值的兩個數(shù)據(jù)應(yīng)視為同一個Topic的兩個不同的實(shí)例。之后創(chuàng)建對應(yīng)的DDS實(shí)體，包括DomainParticipant，Topic，Publisher，以及DataWriter，并使用Data1和Data2分別在DataWriter中進(jìn)行注冊，獲得兩個句柄Handle1和Handle2，分別指向key為1和2的兩個Topic實(shí)例，Data1和Data2。當(dāng)取消注冊時(shí)，DDS Tester使用了錯誤的句柄，即使用Data1和Handle2來取消注冊，按照OMG DDS標(biāo)準(zhǔn)的描述，這時(shí)DDS應(yīng)向應(yīng)用程序返回“PRECONDITION_NOT_MET”，但實(shí)際返回為“OK”。 通過以上示例我們可以看到，被測DDS并沒有完全按照OMG DDS標(biāo)準(zhǔn)進(jìn)行實(shí)現(xiàn)。在實(shí)際項(xiàng)目中，這樣的偏離可能導(dǎo)致系統(tǒng)不能達(dá)到設(shè)計(jì)預(yù)期的功能或者性能。DDS作為支撐起整車分布式系統(tǒng)的重要的框架性軟件，我們需要謹(jǐn)慎的評估每一個對需求的實(shí)現(xiàn)偏離，因?yàn)槠溆绊懙姆秶赡懿⒉痪窒抻谀硞€應(yīng)用程序或某個應(yīng)用場景，它可能影響的是整個分布式系統(tǒng)。

DDS協(xié)議測試套件中的測試用例能夠在實(shí)際系統(tǒng)環(huán)境下遍歷幾乎所有應(yīng)用程序接口，以及所有可能出現(xiàn)的調(diào)用接口的參數(shù)組合情況，并且能夠評估整個系統(tǒng)在不同場景下的性能表現(xiàn)，實(shí)現(xiàn)了對DDS中間件的全面和深入的測試和評估。

05總結(jié)
本篇文章探討了DDS中間件的測試策略，并介紹了北匯信息與臻融軟件科技推出的測試套件，然后通過一個示例展示了測試執(zhí)行和分析問題的過程。如果想了解更多關(guān)于DDS協(xié)議測試套件的信息，歡迎聯(lián)系我們。
在過去的一年，除本文所介紹DDS協(xié)議測試，北匯落地實(shí)踐了若干DDS相關(guān)的測試開發(fā)項(xiàng)目，包括基于OEM定制需求的DDS通信測試、S2S測試、DDS應(yīng)用類測試，后續(xù)會有相關(guān)的文章持續(xù)與大家分享，敬請關(guān)注。