汽車抬頭顯示HUD軟件驗證方法研究

【摘" 要】隨著汽車智能座艙系統的普及，越來越多的車型會配備汽車抬頭顯示HUD系統。文章結合某車型抬頭顯示HUD的開發過程，詳述HUD的軟件驗證方法，并研究軟件驗證的優化方案。

【關鍵詞】HUD；軟件驗證；方法優化

中圖分類號：U463.675" " 文獻標識碼：A" " 文章編號：1003-8639（ 2024 ）02-0086-02

Research on Verification Method of HUD Software

ZHANG Liangjie

（SAIC-GM Wuhan Branch，Wuhan 430200，China）

【Abstract】With the popularization of intelligent cockpit systems in automobiles，more and more vehicles will equip with head up display. This paper combines the development process of a certain vehicle's head up display，elaborates on the software validation method of HUD，and studies the optimization scheme of software validation.

【Key words】HUD；software validation；method study

汽車抬頭顯示系統，簡稱HUD，其主要功能是生成一個在擋風玻璃前的虛像與路面疊加，使駕駛員不低頭就可以看到所需的信息，如速度、擋位、導航等。如圖1所示。

1" ECU軟件驗證方法

為保證軟件開發的品質和效率，汽車行業普遍按照V模型來進行ECU軟件開發。V模型來源于ASPICE，其大體可以分為幾個不同的階段，即需求定義、功能開發、軟件集成測試、功能集成測試和整車集成測試，如圖2所示。本文主要側重于軟件的驗證方法研究，將根據主流OEM的開發經驗，研究適用于HUD的軟件驗證流程。

1）靜態代碼分析：靜態代碼是軟件驗證中必不可少的一環，指在不運行程序的條件下進行代碼分析的方法，主要從代碼風格、語法、語義等多維度對工程代碼進行分析，能提前發現代碼中存在的漏洞，如安全漏洞、內存泄漏、違反代碼標準的行為、未初始化的變量或指針等。在靜態代碼分析階段，缺陷的修復成本是最低的，如圖3所示。

2）單元測試：由于靜態代碼分析存在局限性，需要單元測試來驗證代碼是否滿足設計要求。單元測試精確到每個模塊和每個函數，用于驗證各個模塊是否滿足設計要求，單元測試的優點是能夠在開發周期的早期發現問題，暴露任何不符合需求設計要求的代碼，以識別并減少單元中的不確定性，識別死代碼和無法訪問的代碼，降低長期開發成本。

3）黑盒測試：需由獨立的測試團隊完成，并基于硬件平臺盡可能進行自動化測試，以驗證軟件設計滿足需求，黑盒測試不應代替開發過程中的其他集成測試。

4）軟件架構分析：從軟件架構層面分析軟件的薄弱點來輔助驗證，進而發現軟件設計中存在的問題，問題不限于軟件架構缺少魯棒性、處理器的連續任務處理、多核任務的軟件分配、驅動的可重入性等。

5）軟件壓力測試：在最壞工況下對軟件進行多次測試，來暴露軟件的隱藏缺陷和問題，軟件壓力測試的目的分為兩方面：①魯棒性，確保ECU在壓力情況下仍可以按預期工作；②彈性，確保軟件能在壓力情況移除后恢復正常工作狀態。

6）ECU性能分析測試：用來分析最壞工況下關鍵任務的執行時間和任務分配，分析應當包括但不限于上電喚醒、休眠時間、最壞工況下堆棧的使用情況、CPU的使用情況等。

7）軟件追溯表：為了確保所有的軟件需求均被測試覆蓋，軟件追溯表需記錄測試項與軟件需求的對應關系，以驗證零部件軟件驗證覆蓋了所有需求。

2" HUD軟件驗證方法

HUD軟件測試方法總共分為3類：白盒測試、黑盒測試和灰盒測試。

1）白盒測試主要包括靜態分析和單元測試。靜態分析的檢查范圍包括：自研代碼、模型生成代碼、開源庫代碼和第三方代碼。靜態分析工具必須支持最新的MISRA C和MISRA C++規則項，要求所有Mandatory類問題必須修復，對于Advisory和Required類需經過充分評估后決定是否修復。靜態分析結果示意如圖4所示。

單元測試范圍包括所有的自研代碼和模型，不包括第三方代碼。單元測試的原則性要求是函數的語句覆蓋率和分支覆蓋率達到100%，覆蓋率未達100%的函數需有明確的分析說明。單元測試用例應根據原始需求設定函數的期望輸出值，并與實際輸出值做比較。單元測試結果示意如圖5所示。

2）HUD黑盒測試主要包括3個大類：Overvoltage amp; Undervoltage Test、Functionality Test和Diagnostics Test。Overvoltage amp; Undervoltage Test主要驗證在高低壓狀態下HUD的功能穩定性；Functionality Test主要驗證在正常工況下HUD各個功能，如背光、電源管理狀態、顯示功能等是否正常；Diagnostics Test主要驗證診斷功能是否與需求相符。黑盒測試用例需100%覆蓋原始需求，黑盒測試和單元測試與需求之間的追溯關系需總結在軟件追溯表里。

3）灰盒測試包括軟件壓力測試和ECU性能分析。軟件壓力測試包括Startup and Shutdown Test、Memory Handling Test、Input Overload Test、Output Faults Test、Overloading of Interrupts Test和Sleep Stress Cases。壓力測試中添加最壞工況來測試軟件的穩定性，如對HUD增加高低壓工況下Memory的刷寫測試，增加當LVDS信號異常掉線恢復后HUD的穩定性測試，增加當Mirror異常卡滯時HUD能否正常休眠等。為驗證軟件在異常工況的穩定性，所有壓力測試Case要求至少測試50次。ECU性能分析包括Powerup_Wakeup_Shutdown Test、Message Latencies Test、Reaction Times to Inputamp;Output Test、Worst Case Stack Usage Test、ISRworst Case Execution Times Test和CPU Loading Test。ECU性能分析的每個測試Case至少測試10次，所有性能分析測試項需模擬實車真實環境，CPU Load測試需在功能邏輯不沖突的情況下創建對應的最壞工況，如Crank、休眠喚醒、多任務執行等，以驗證系統是否會存在卡滯。

3" 軟件驗證方法升級

使用本測試方法參與某旗艦車型的HUD測試開發項目，發現也有不足之處需要升級。

1）軟件追溯表需涵蓋所有釋放的需求，需追溯至需求文檔的最小章節號，且章節號應連續。

2）針對HUD的特性，壓力測試中增加當鏡面卡滯時是否會影響HUD正常休眠的測試。

3）針對HUD的工作特性，壓力測試CPU Load測試中增加組合工況下各Task的執行情況。

4）壓力測試中增加LVDS信號突然掉線恢復后HUD的功能測試，并將測試次數增加至100次。

5）中斷測試中需增加復雜環境以評估中斷執行的穩定性。

4" 總結

本文針對某車型的HUD開發，提供了一套完善的軟件驗證流程，并結合項目經驗提供了改善方案，最終通過臺架驗證和項目量產的售后問題反饋，確定了該方案的有效性，并為后續HUD軟件驗證的持續開發提供了思路和方向。

參考文獻：

[1] 陳君，馮飛. 嵌入式軟件自動化測試研究[J]. 工業控制計算機，2021，34（9）：15-16.

[2] 夏佳佳，鄒毅軍，周江偉，等. 嵌入式軟件自動化測試系統研究[J]. 計算機測量與控制，2016，24（4）：22-25.

[3] 冀佩剛. 程序靜態分析研究[D]. 蘭州：蘭州大學，2006.

[4] 酈亦非. 基于ASPICE模型的汽車軟件開發質量管理[J]. 上海質量，2021（8）：57-60.

[5] 王麗娟，劉全周，李占旗，等. 汽車電子嵌入式軟件單元測試用例設計方法研究[J]. 中國汽車，2022（8）：14-18，23.

（編輯" 楊凱麟）

收稿日期：2023-07-25

作者簡介

張亮杰，男，碩士，零部件軟件驗證工程師amp;車身電子系統工程師。