1  概述

汽車電子軟件開發(fā)模型一般分為瀑布模型和V模型。如圖1-1所示，瀑布模型的開發(fā)遵循從上到下的固定順序，依次為需求分析、總體設計、詳細設計、編碼與調試、測試五個階段，各階段劃分明確，以有序的方式來解決復雜的問題，盡可能地實現(xiàn)預期需求。瀑布模型中的每一個階段都有對應的循環(huán)反饋，在后續(xù)開發(fā)階段中發(fā)現(xiàn)缺陷時，可以把缺陷反饋到上一階段進行修正。


圖1-1 瀑布模型開發(fā)流程

在需求明確且穩(wěn)定時，可采用瀑布模型進行軟件開發(fā)，但在實際開發(fā)中，需求會因為各種原因發(fā)生變更，這樣會給瀑布模型的開發(fā)帶來很大的工作量，因為需求的變更意味著整個開發(fā)流程需要重新返回到需求分析階段。且瀑布模型只有在項目后期才進行測試，難以在前期發(fā)現(xiàn)設計錯誤或紕漏，會帶來研發(fā)成本增高、開發(fā)周期延長等風險。因此，大多數(shù)公司使用V模型來進行開發(fā)。如圖1-2所示，傳統(tǒng)V模型的左側從上到下為需求分析、系統(tǒng)設計、子系統(tǒng)設計、軟件設計以及編碼實現(xiàn)，其中代碼是開發(fā)人員基于詳細的軟件設計進行編寫的；針對V模型左側的每個開發(fā)階段，右側會有不同的測試階段與之一一對應，依次為系統(tǒng)測試、集成測試、軟件測試以及單元測試，如，軟件產(chǎn)品的需求可在系統(tǒng)測試階段得到驗證。相較于瀑布模型，V模型的優(yōu)勢有：

•  具有較強的可追溯性；

•  能在開發(fā)前期進行測試驗證，發(fā)現(xiàn)重大錯誤；

•  模型開發(fā)簡單高效，能減少開發(fā)成本，提高開發(fā)效率


圖1-2 V模型開發(fā)流程

隨著嵌入式軟件開發(fā)的規(guī)模以及復雜度越來越大，系統(tǒng)的安全性和實時性要求越來越高，在傳統(tǒng)的V模型開發(fā)過程中人工編碼或多或少會出現(xiàn)語句錯誤、代碼缺陷等問題，且在代碼中難以直觀地表現(xiàn)出邏輯關系。此時可以將基于模型的設計（MBD）融入到V模型的開發(fā)流程中，如圖1-3所示，結合系統(tǒng)仿真和代碼自動生成技術，在開發(fā)流程中讓各個功能以模塊化的形式表現(xiàn)，自動生成相關的代碼，減少代碼的編寫錯誤，同時能在各階段驗證相關功能的邏輯。


圖1-3 融合MBD的V模型開發(fā)流程

融合MBD的V模型開發(fā)流程，首先需要定義仿真建模目標，即詳細了解系統(tǒng)的需求。在系統(tǒng)設計階段需要進行物理建模設計，隨后在子系統(tǒng)設計階段進行快速原型搭建，此時需要運用模型在環(huán)測試（MIL）對所搭建的算法模型進行功能以及完整性驗證。之后將設計好的功能模塊自動生成對應的產(chǎn)品代碼，在單元測試、軟件測試過程中，進行軟件在環(huán)（SIL）以及處理器在環(huán)(PIL)測試，驗證代碼以及編譯后的可執(zhí)行文件與模型在功能上是否保持一致。然后進行MBD的最后一步：集成測試，對所集成的系統(tǒng)進行硬件在環(huán)測試（HIL），驗證被測終端在真實硬件設備通信環(huán)境中是否滿足車聯(lián)網(wǎng)系統(tǒng)各應用功能的需求。剩下的測試步驟與傳統(tǒng)V模型中的測試一致，如車輛在環(huán)測試（VIL）、實車測試等。下文將針對C-V2X功能場景各階段的開發(fā)測試方法逐一介紹。

2  模型在環(huán)測試（MIL）

模型在環(huán)測試（MIL）是集成軟件算法模型和被控對象模型（交通流模型、車輛動力學模型等）的閉環(huán)測試系統(tǒng)，通過相關測試用例對軟件算法模型進行測試，在模型層面驗證軟件系統(tǒng)功能的正確性?；谀Ｐ驮O計(MBD)的前期將一個大的系統(tǒng)拆解成多個不同的子模塊，然后將各子模塊逐一分解為多個單一的功能模塊，在支持模塊化設計的仿真軟件（例如Simulink）中，逐一搭建各單一功能模塊模型，最終形成所需的算法模型，通過輸入測試用例驗證搭建的算法模型是否滿足設計的功能需求。


圖2-1 模型在環(huán)測試

以交叉路口碰撞預警（ICW）算法功能測試為例，當主車駛向交叉路口，與交叉路口側向行駛的車輛存在潛在碰撞危險時，ICW需要對主車駕駛員進行預警，相關的MIL測試流程如圖2-1所示。首先進行測試用例設計，基于測試用例在Simulink中搭建交通流模型、動力學模型等模型（模型結合），仿真環(huán)境搭建如下：

（1）依據(jù)ICW測試場景，設置交叉路口道路、紅綠燈、交通標志、RSU等基礎設施；

（2）依據(jù)ICW測試場景，設置近車、外部交通參與者的位置以及初始狀態(tài)；

（3）設置外部光照、氣象等外部影響因素；

（4）設置車輛動力學模型，其中包含車輛參數(shù)調節(jié)，如懸架、發(fā)動機、轉向等相關參數(shù)；

（5）規(guī)劃車輛路徑，以滿足ICW的場景測試需求。

搭建好的的測試場景模型不斷向算法模型發(fā)送外部交通要素以及近車的相關信息數(shù)據(jù)，同時算法模型基于其算法邏輯輸出預警結果，然后將算法預警結果與測試用例中的預期預警結果進行比對，檢查預警算法是否能在規(guī)定的時間預警以及是否出現(xiàn)了誤報、漏報等情況，達到驗證預警算法的目的。

MIL測試系統(tǒng)所具備的功能優(yōu)勢主要有:

•  預警功能算法模型和場景模型具有良好的可讀性，可直觀看出預警算法的運行邏輯；

•  有利于開發(fā)人員在開發(fā)初期發(fā)現(xiàn)預警錯誤等問題，降低開發(fā)周期和開發(fā)成本；

•  高動態(tài)性，可隨時調節(jié)各模型參數(shù)，方便進行修改驗證。

3  軟件在環(huán)測試（SIL）

軟件在環(huán)測試系統(tǒng)通過交通流模型、車輛動力學模型等構成的功能場景模型進行所需業(yè)務數(shù)據(jù)的模擬收發(fā)，與封裝好的算法代碼形成一個閉環(huán)測試系統(tǒng)。通過SIL在早期開發(fā)過程中對軟件代碼進行測試，可確保在開發(fā)過程中盡早發(fā)現(xiàn)代碼生成過程中的一些問題，例如代碼生成工具的錯誤設置導致生成的代碼有誤。如圖3-1所示，車聯(lián)網(wǎng)SIL測試場景中的被測對象是基于MIL中的算法模型自動生成的代碼，SIL用封裝好的代碼替代Simulink環(huán)境中MIL測試的算法模型，其他工作流程與MIL一致，用于C-V2X車聯(lián)網(wǎng)功能場景正確性的驗證。


圖3-1 軟件在環(huán)測試

如圖3-2所示，在代碼生成正確的情況下，同時輸入相同的測試用例，理想情況下一定會得到相同的測試結果（即偏差<=閾值），即測試通過，否則，則表明代碼生成過程中存在錯誤。SIL測試中的算法代碼需實現(xiàn)的功能與MIL測試中的算法模型功能應該是一致的，且SIL的測試用例也需要和MIL保持一致。


圖3-2 MIL與SIL功能一致性驗證

4  處理器在環(huán)測試（PIL）

軟件在環(huán)測試（SIL）主要驗證模型自動生成的代碼與模型在功能上的一致性，而SIL自動生成的代碼是在PC上運行的，一般PC的浮點數(shù)處理精度會比被測終端的嵌入式處理器要高，所以可以通過PIL測試來驗證測試用例在處理器上的運行結果是否與軟件上的運行結果一致。

在仿真軟件中搭建以ICW為例的功能場景，場景的搭建步驟及測試用例與SIL一致，被測終端通過硬件通信方式與PC建立連接，實現(xiàn)通信。PC將測試系統(tǒng)中的測試業(yè)務數(shù)據(jù)（本車在交叉路口運動狀態(tài)數(shù)據(jù)和位置數(shù)據(jù)、遠車在交叉路口運動狀態(tài)數(shù)據(jù)和位置數(shù)據(jù)、路側消息等外部交通要素數(shù)據(jù)）發(fā)送給被測終端，經(jīng)過被測終端的預警算法處理，判斷兩車在交叉路口是否有潛在的碰撞風險，輸出預警信息返回到PC的仿真軟件中，形成完整的PIL測試過程。如圖4-1所示。


圖4-1 處理器在環(huán)測試

PIL測試系統(tǒng)的主要優(yōu)勢有：

•  驗證編譯后燒錄在處理器上的可執(zhí)行文件的功能邏輯與SIL中的模塊功能邏輯是否一致，避免在研發(fā)后期發(fā)現(xiàn)可執(zhí)行文件缺陷等問題；

•  可以依據(jù)可執(zhí)行文件在處理器上的運行時間來優(yōu)化預警算法及硬件配置。

5  硬件在環(huán)測試（HIL）

PIL系統(tǒng)中使用的目標硬件僅僅是被測終端的處理器，而不是完整的被測終端產(chǎn)品。在車聯(lián)網(wǎng)系統(tǒng)應用開發(fā)過程中，需要HIL來進行集成測試，以驗證軟件在真實被測終端的邏輯功能。HIL系統(tǒng)中使用的目標硬件是完整的被測終端產(chǎn)品，與實時機、信號模擬器、GNSS信號發(fā)生器、V2X信號發(fā)生器以及信道模擬器等設備建立連接，模擬在真實通信環(huán)境下與其他車輛終端、路側設備之間的數(shù)據(jù)交互，驗證被測終端是否滿足設計要求。

在仿真軟件中搭建以ICW為例的功能場景，場景的搭建步驟及測試用例與PIL一致。將仿真軟件中的衛(wèi)星信號數(shù)據(jù)通過GNSS發(fā)生器發(fā)送給被測終端，用于模擬交叉路口近車的定位信息；將近車車輛狀態(tài)信息通過信號模擬器發(fā)送給被測終端,用于模擬被測終端接收近車數(shù)據(jù)；將仿真軟件中遠車車輛信息、路側信息、道路、天氣等外部交通要素數(shù)據(jù)，通過V2X信號發(fā)生器生成V2X標準通信數(shù)據(jù)（BSM、RSI、RSM、MAP、SPAT等），經(jīng)由信道模擬器發(fā)送給被測終端，其中信道模擬器模擬車聯(lián)網(wǎng)功能場景中真實的信道環(huán)境；被測終端經(jīng)過算法處理，輸出預警信息或其他功能信息返回給仿真軟件，與預期結果進行對比，形成完整的HIL測試過程。如圖5-1所示。


圖5-1硬件在環(huán)測試

HIL測試系統(tǒng)的主要功能及優(yōu)勢包括：

•  測試驗證被測終端在完整系統(tǒng)中是否滿足車聯(lián)網(wǎng)系統(tǒng)應用功能需求；

•  測試驗證被測終端及算法在特定場景中的容錯能力（如丟包、信道衰落等場景）；

•  加快車聯(lián)網(wǎng)終端產(chǎn)品的研發(fā)進度，減少不必要的實車測試成本及縮短產(chǎn)品開發(fā)周期。

6  車輛在環(huán)測試（VIL）

車輛在環(huán)測試（VIL），主要驗證被測終端集成到真實車輛環(huán)境下的功能。實車通過與實時機、GNSS信號發(fā)生器、V2X信號發(fā)生器、信道模擬器等儀器設備建立連接，模擬實車在多種場景下的功能表現(xiàn)是否滿足設計要求。在車聯(lián)網(wǎng)系統(tǒng)的開發(fā)流程中，被測終端經(jīng)過HIL測試后，邏輯算法功能在真實被測終端得到了初步驗證，但HIL測試的整車環(huán)境是基于動力學模型搭建的，模型與真實車輛相比，其精度存在一定差異。此時可以引入車輛在環(huán)測試（VIL）對終端設備進行更加精準的邏輯功能關系驗證。

如圖6-1所示，針對V2X應用功能場景測試，VIL測試系統(tǒng)主要包含測試系統(tǒng)實時機（含仿真軟件）、GNSS信號發(fā)生器、V2X信號發(fā)生器、信道模擬器、集成被測終端的實車。在測試系統(tǒng)實時機中建立V2X功能測試場景，把仿真軟件中的本車衛(wèi)星定位數(shù)據(jù)通過GNSS信號發(fā)生器發(fā)送給被測終端；將車輛的轉向、油門、剎車等控制信息發(fā)送給實車，使實車的轉向、速度、加速度等參數(shù)能匹配仿真場景中設定的運動狀態(tài)；其他車輛信息、路側信息、道路、天氣等外部交通要素數(shù)據(jù)通過V2X信號發(fā)生器生成后，以V2X標準通信數(shù)據(jù)格式（BSM，RSI、RSM、MAP、SPAT等）經(jīng)信道模擬器發(fā)送給被測終端；被測終端經(jīng)過算法處理，輸出預警信息或其他功能信息，輸出信息通過實車的HMI進行展示（觸覺、視覺、聽覺等），并與預期結果進行對比，形成完整的VIL測試系統(tǒng)。


圖 6-1 車輛在環(huán)測試

VIL測試系統(tǒng)的主要優(yōu)勢包括：

•  基于實車搭建各類車聯(lián)網(wǎng)仿真場景，能提高測試真實性和準確性；

•  能高度仿真測試各類真實車聯(lián)網(wǎng)環(huán)境中的危險工況，降低實車道路測試的風險和測試成本；

•  可以盡早發(fā)現(xiàn)實車與V2X測試終端交互過程中的功能缺陷。

7  駕駛員在環(huán)測試（DIL）

駕駛員在環(huán)測試（DIL），主要是評估駕駛員的反應時間以及測試駕駛員在干預駕駛情況下的系統(tǒng)功能。駕駛員在環(huán)測試系統(tǒng)是一種通過測試系統(tǒng)實時機、動態(tài)駕駛員模擬艙（駕艙）、被測終端、GNSS信號發(fā)生器、信號模擬器、V2X信號發(fā)生器、信道模擬器等設備聯(lián)調而成的“人-車-環(huán)境”測試系統(tǒng)。

在測試系統(tǒng)實時機中建立V2X功能測試場景，將仿真軟件中的本車數(shù)據(jù)以及衛(wèi)星定位數(shù)據(jù)分別通過信號模擬器和GNSS信號發(fā)生器發(fā)送給被測終端，仿真軟件中的遠車信息、路側信息、道路、天氣等外部交通要素數(shù)據(jù)通過V2X信號發(fā)生器生成后以V2X標準通信數(shù)據(jù)格式（BSM，RSI、RSM、MAP、SPAT等）發(fā)送給被測終端。被測終端經(jīng)過算法處理，輸出預警信息或其他功能信息。輸出的信息通過動態(tài)駕駛員模擬艙的HMI展示出來（觸覺、視覺、聽覺等），駕駛員在收到相關提示或功能性消息后，采取變道、制動等措施來避免發(fā)生危險。動態(tài)駕駛模擬艙通過記錄消息提醒時間與駕駛員的操作時間計算得出駕駛員反應時間及被測終端在駕駛員干預后的系統(tǒng)功能表現(xiàn)情況。


圖 7-1 駕駛員在環(huán)測試

DIL測試系統(tǒng)的主要優(yōu)勢包括：

•  在臺架上即可采集駕駛員的駕駛習慣信息及駕駛員反應時間；

•  可以對被測終端在開展了人工干預后的系統(tǒng)功能開展測試。

8  總結

C-V2X終端產(chǎn)品在規(guī)?；逃弥?，需要在V2X功能場景的功能、性能、穩(wěn)定性和魯棒性等方面進行全面的測試驗證。V模型開發(fā)流程和MBD開發(fā)方法的融合，保障了研發(fā)人員可以將更多的精力投入到算法設計和測試驗證工作中，加快產(chǎn)品開發(fā)迭代速度的同時，也保證了產(chǎn)品的質量。