01

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

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

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

OEM和供應商的合作模式的改變對其中動態測試的部分的影響很大。進行動態測試時，測試環境需要為被測對象提供運行環境，并且能夠仿真系統中的其他部分（或稱殘余系統）與被測對象的交互。在傳統的OEM和供應商的合作模式下，供應商交付的是ECU實體，是包含軟件和硬件的一整套系統，所以這時候所謂的動態測試指的就是ECU的HiL測試。

這種情況下ECU和殘余系統的交互實現方案相對來說是標準化的，如CAN/LIN等總線信號以及I/O信號，目前有非常成熟的解決方案。而當OEM和供應商的合作模式改變之后，供應商交付物的形態更加多樣，它可能是一個完整的ECU，或者一個操作系統，或者一個中間件，或者一個應用軟件。這種多樣性對動態測試環境的搭建帶來了挑戰，比如把應用程序作為被測對象，我們需要模擬被測對象依賴的全部環境，包括操作系統、依賴庫和硬件等，十分困難。因為測試方案不像原來一樣標準化了，測試系統很難像流水線一樣生產出來。新的模式下，我們需要和每一個客戶深入溝通，明確測試對象是什么，邊界在哪里，需求是什么，然后才能進一步評估，制定合適的測試方案。

02

DDS中間件的測試策略

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

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

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

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

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

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

03

DDS協議測試工具介紹

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

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

圖1：DDS協議測試的測試框架示意

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

當然，DDS節點并不一定只通過以太網進行通信，其它還包括板載交換機的介質無關接口，共享內存，或者本地環回網絡等等，測試環境可以根據系統的實際情況進行搭建。

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

04

DDS協議測試實踐

如下示例展示了DDS測試的執行過程。

圖2：測試環境

圖3：DDS Tester 運行界面

測試環境如圖2所示，為便于展示，被測系統為Windows主機中運行的兩臺Ubuntu虛擬機，兩臺虛擬機中均運行DDS Tester。被測DDS為某DDS中間件產品，目前在汽車行業內已經得到較廣應用。

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

圖4：在DDS Test Frame中執行測試用例

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

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

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

DDS協議測試套件中的測試用例能夠在實際系統環境下遍歷幾乎所有應用程序接口，以及所有可能出現的調用接口的參數組合情況，并且能夠評估整個系統在不同場景下的性能表現，實現了對DDS中間件的全面和深入的測試和評估。

05

總結

本篇文章探討了DDS中間件的測試策略，并介紹了北匯信息與臻融軟件科技推出的測試套件，然后通過一個示例展示了測試執行和分析問題的過程。如果想了解更多關于DDS協議測試套件的信息，歡迎聯系我們。

在過去的一年，除本文所介紹DDS協議測試，北匯落地實踐了若干DDS相關的測試開發項目，包括基于OEM定制需求的DDS通信測試、S2S測試、DDS應用類測試，后續會有相關的文章持續與大家分享，敬請關注。

審核編輯 ：李倩