軟件定義汽車對測試的影響

OEM和供應(yīng)商之間傳統(tǒng)的合作模式是由OEM釋放技術(shù)需求，供應(yīng)商按照需求進行軟件和硬件實現(xiàn)，最終交付的是完整的軟硬件系統(tǒng)。隨著集中式架構(gòu)的逐步演進，這種合作模式正在被打破——標準化的高性能硬件平臺、高級操作系統(tǒng)、中間件以及虛擬化技術(shù)得以應(yīng)用，使硬件越來越抽象化，可以使應(yīng)用程序脫離硬件，相對獨立的進行開發(fā)和測試。這就允許ECU的開發(fā)可以進行更細致的分工，比如硬件由供應(yīng)商A提供，操作系統(tǒng)和基礎(chǔ)軟件由供應(yīng)商B進行開發(fā)或集成，應(yīng)用軟件由供應(yīng)商C開發(fā)等等?？梢哉fOEM和供應(yīng)商的合作模式更靈活了。

OEM作為集成方，需要對來自不同供應(yīng)商的模塊進行“驗收測試”，其目的是確認該模塊是否按照需求進行實現(xiàn)。根據(jù)需求類型可以將驗收測試劃分為三個部分：針對行業(yè)標準的驗收測試，針對OEM企業(yè)標準的驗收測試，以及針對車型項目需求的驗收測試。其中每個部分又根據(jù)測試方法的不同而分成兩種類型，分別是靜態(tài)審查和動態(tài)測試。

OEM和供應(yīng)商的合作模式的改變對其中動態(tài)測試的部分的影響很大。進行動態(tài)測試時，測試環(huán)境需要為被測對象提供運行環(huán)境，并且能夠仿真系統(tǒng)中的其他部分（或稱殘余系統(tǒng)）與被測對象的交互。在傳統(tǒng)的OEM和供應(yīng)商的合作模式下，供應(yīng)商交付的是ECU實體，是包含軟件和硬件的一整套系統(tǒng)，所以這時候所謂的動態(tài)測試指的就是ECU的HiL測試。這種情況下ECU和殘余系統(tǒng)的交互實現(xiàn)方案相對來說是標準化的，如CAN/LIN等總線信號以及I/O信號，目前有非常成熟的解決方案。而當OEM和供應(yīng)商的合作模式改變之后，供應(yīng)商交付物的形態(tài)更加多樣，它可能是一個完整的ECU，或者一個操作系統(tǒng)，或者一個中間件，或者一個應(yīng)用軟件。這種多樣性對動態(tài)測試環(huán)境的搭建帶來了挑戰(zhàn)，比如把應(yīng)用程序作為被測對象，我們需要模擬被測對象依賴的全部環(huán)境，包括操作系統(tǒng)、依賴庫和硬件等，十分困難。因為測試方案不像原來一樣標準化了，測試系統(tǒng)很難像流水線一樣生產(chǎn)出來。新的模式下，我們需要和每一個客戶深入溝通，明確測試對象是什么，邊界在哪里，需求是什么，然后才能進一步評估，制定合適的測試方案。

DDS中間件的測試策略

DDS中間件即是上述新模式下的一個典型例子，那么如何對這種產(chǎn)品進行測試呢？

對于成熟的標準的軟件產(chǎn)品，比如Linux，QNX等，我們其實并不需要對其核心功能進行太多測試，因為軟件廠商或開發(fā)者會在產(chǎn)品開發(fā)過程中進行大量測試，市場和時間也能充分證明其質(zhì)量的可靠性，這也是我們選擇成熟軟件模塊的意義所在。然而，當我們把來自不同供應(yīng)商的標準產(chǎn)品放到同一個系統(tǒng)或網(wǎng)絡(luò)中協(xié)同工作時，必須考慮到它們之間是否兼容，也就是互操作問題。

那么對DDS來說，會出現(xiàn)互操作問題嗎？這需要分情況討論。

如果參與DDS通信的節(jié)點均是基于高性能SoC實現(xiàn)，并且運行標準操作系統(tǒng)（如Linux，QNX等），得益于DDS良好的可移植性和OS無關(guān)的特性，OEM可以采用成熟的商業(yè)產(chǎn)品或開源產(chǎn)品，然后部署在每個節(jié)點中。此時，若所有節(jié)點運行著相同的來源和版本的DDS中間件，顯然這種模式下我們可以忽略互操作的問題。

然而，目前也有不少廠商正在嘗試或已經(jīng)實現(xiàn)向MCU中集成DDS中間件。受限于MCU性能和資源，DDS軟件必須經(jīng)過適當裁剪和優(yōu)化才能在MCU的環(huán)境下運行。同時，MCU軟硬件高度耦合，軟件移植、復(fù)用和維護并不容易，這種情況下我們可能不能再將其視為成熟的軟件模塊，廠商因此需要對DDS軟件進行大量的測試來保證DDS系統(tǒng)的質(zhì)量。這種情況下，為了避免與其他DDS軟件互通時產(chǎn)生交互問題，互操作測試是必不可少的。除了上述情況，如果DDS中間件來源或版本存在差別，互操作性測試也將是十分必要的。

除了互操作測試，另一個更重要的關(guān)注點是系統(tǒng)測試，具體來說是DDS中間件集成至目標平臺后，會不會出現(xiàn)系統(tǒng)性問題。因為車載電子電器系統(tǒng)的計算平臺五花八門，不同車型平臺，不同項目，其搭載的系統(tǒng)平臺（包括芯片架構(gòu)，操作系統(tǒng)等）可能都有不同，甚至還有像基于MCU的DDS這種嵌入式軟件，這些不同的平臺相互的組合情況，DDS QoS配置組合情況，以及復(fù)雜的網(wǎng)絡(luò)配置情況（如DDS-TSN），更難以計數(shù)。盡管DDS協(xié)議棧廠商可能會驗證DDS產(chǎn)品與常見平臺的兼容性，但是這很難覆蓋所有可能的系統(tǒng)配置。所以我們認為在上述情況下對DDS中間件進行功能和性能測試是有必要的。

DDS協(xié)議測試工具介紹

基于上文對測試策略的討論和實踐總結(jié)，北匯信息與南京臻融軟件科技合作開發(fā)了DDS協(xié)議測試套件，該產(chǎn)品能夠在特定系統(tǒng)環(huán)境下驗證DDS中間件的功能和性能，以及不同的DDS產(chǎn)品之間的互操作性。

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

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

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

DDS協(xié)議測試規(guī)范/用例完全自主設(shè)計開發(fā)，并且在多年的項目實踐中不斷進行迭代和優(yōu)化，目前可以覆蓋OMG DDS 1.4所定義的DCPS的核心功能，包括DDS應(yīng)用程序接口的行為，QoS行為，以及性能測試，共計400余條測試用例，通過所開發(fā)的測試腳本套件，全部可實現(xiàn)自動化執(zhí)行。

?

DDS協(xié)議測試實踐

如下示例展示了DDS測試的執(zhí)行過程。

測試環(huán)境如圖2所示，為便于展示，被測系統(tǒng)為Windows主機中運行的兩臺Ubuntu虛擬機，兩臺虛擬機中均運行DDS Tester。被測DDS為某DDS中間件產(chǎn)品，目前在汽車行業(yè)內(nèi)已經(jīng)得到較廣應(yīng)用。

在上位機軟件DDS Test Frame中選擇并執(zhí)行測試用例，如圖4所示。

我們以DisposeWTimeStamp_WrongHandle這條失敗的測試用例來說明一下測試問題的分析步驟。測試步驟如下表所示。

在這條測試用例中，DDS Test Frame發(fā)送指令，使DDS Tester創(chuàng)建同一個Topic的兩個數(shù)據(jù)，分別為Data1和Data2，Topic中指定“key”為鍵，不同鍵值的兩個數(shù)據(jù)應(yīng)視為同一個Topic的兩個不同的實例。之后創(chuàng)建對應(yīng)的DDS實體，包括DomainParticipant，Topic，Publisher，以及DataWriter，并使用Data1和Data2分別在DataWriter中進行注冊，獲得兩個句柄Handle1和Handle2，分別指向key為1和2的兩個Topic實例，Data1和Data2。當取消注冊時，DDS Tester使用了錯誤的句柄，即使用Data1和Handle2來取消注冊，按照OMG DDS標準的描述，這時DDS應(yīng)向應(yīng)用程序返回“PRECONDITION_NOT_MET”，但實際返回為“OK”。

通過以上示例我們可以看到，被測DDS并沒有完全按照OMG DDS標準進行實現(xiàn)。在實際項目中，這樣的偏離可能導致系統(tǒng)不能達到設(shè)計預(yù)期的功能或者性能。DDS作為支撐起整車分布式系統(tǒng)的重要的框架性軟件，我們需要謹慎的評估每一個對需求的實現(xiàn)偏離，因為其影響的范圍可能并不局限于某個應(yīng)用程序或某個應(yīng)用場景，它可能影響的是整個分布式系統(tǒng)。

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

總結(jié)

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