作者 |浩瀚

小編 | 不吃豬頭肉

引言
在功能安全的開發、測試過程中概念階段的活動一般都是由主機廠負責，而從系統開發到單元實現則是由供應商負責，對于供應商所做的一系列測試通常稱為零部件級測試。根據ISO 26262功能安全標準的劃分，功能安全在零部件階段的測試包括：軟件單元測試、軟件集成測試、硬件集成測試、嵌入式軟件測試、軟硬件集成測試。本次主要探討軟件在零部件級的軟件測試。

目前功能安全零部件測試的困難

1.來自OEM的認可壓力：隨著主機廠對功能安全的重視和投入，主機廠越來越專業，審核要求也越來越嚴格，不僅要求過ISO 26262產品認證和流程認證，并且親自下場對各輸入物及詳細內容進行審查。

2.技術儲備不足：大多數零部件供應商沒有專門的功能安全團隊，缺少功能安全開發能力和測試能力。

3.資源不足：大部分零部件供應商缺少完整的測試工具鏈，各階段測試人員配備不齊。目前國內的功能安全標準正處于由國家推薦性標準逐漸向強制性標準過渡的時期，加之在新能源汽車出海的大趨勢下，功能安全標準也正在加速與國際接軌。未來功能安全標準將成為汽車供應鏈廠商的準入門檻之一。那么執行滿足功能安全標準要求的測試已是刻不容緩且必須解決的問題，下面將依據功能安全標準和公司在軟件測試方面的積累提供滿足功能安全測試的解決方案。

軟件單元、集成測試
2.1軟件單元、集成的靜態測試
靜態測試是指在不運行軟件的情況下，檢查軟件是否符合業內通用的編碼規范/建模規范，像MISRA、MAB等，盡早發現軟件的數據流/控制流問題，以及選用一些代碼度量的約束，來提高軟件質量。

基于MBD的靜態分析
模型的靜態分析主要是通過選擇合適的建模標準和模型度量指標來進行驗證，它的分析原理就是利用模型的一些屬性和結構信息來推斷代碼的行為和可能存在的問題。對于模型生成的代碼也需要做代碼靜態分析。

建模規范選擇

在進行代碼靜態分析時，通常依據使用的語言和遵循的規則來選用編碼規范。在進行模型靜態分析時，依據使用的建模工具和要求來選擇建模規則。1)所有基于MBD的開發都需要選擇MAB建模規范；2)使用了Simulink 和 Stateflow 的模型工具需要選擇MISRA SLSF；3)使用了TargetLink的模型工具需要選擇MISRA TL；4)如果需要符合ISO 26262對于模型的標準要求，需要選擇定制的功能安全規范。工具選擇：對于模型的靜態測試通常選用MES的MXAM工具，MXAM是一款高度自動化的靜態分析工具，可支持多種模型類型的檢查，并且提供了符合ISO 26262標準的檢查規范。手寫代碼的靜態分析
代碼的靜態分析主要從編碼規范的檢查、程序流和數據流的分析、代碼度量分析等三個維度展開。它的分析原理是對編寫的代碼進行逐行檢查，尋找潛在的錯誤、漏洞和不符合規范的代碼結構。

編碼規范選擇

在進行代碼靜態分析時，通常依據使用的語言和遵循的規則來選用編碼規范。1)C代碼：通常選用最新的MISRA編碼標準MISRA C 2023；2)C++代碼：a.基于C++98/03開發選用MISRA C++ 2008b.基于C++11及C++14標準選用AUTOSARC.基于C++17的標準選用MISRA C++ 20233)考慮信息安全時需要遵循CERT和CWE規范。工具選擇：對于代碼的靜態測試通常選用Helix QAC，它支持多種編碼標準，以及擁有業界領先的編碼規范覆蓋度，擁有豐富的命令行，更容易實現自動化，方便與持續集成系統進行融合。

2.2軟件單元、集成的動態測試
動態測試通過實際執行代碼來驗證軟件的行為和性能是否符合預期，動態測試可以發現靜態測試中未被檢測到的缺陷，確保軟件安全需求及安全機制執行正確，無非預期的輸出，并為軟件接口的一致性和完整性提供證據。軟件單元的動態測試測試范圍：軟件單元詳細設計規范、軟件單元接口文檔。測試方法：

基于需求的測試：使用不同輸入來激發軟件單元代碼中的各種執行路徑，驗證輸出符合預期，從而驗證軟件單元設計規范和分配的軟件安全要求滿足設計要求。

接口測試：考慮軟件單元輸入信號的無效/有效等價類和邊界值，模擬輸入檢測輸出的正確性，從而驗證軟件單元與接口文檔的一致性、輸出的正確性。

故障注入測試：故障注入測試一般要修改被測的軟件單元（比如改變變量的值，引入代碼突變或破壞CPU寄存器的值），主要用來驗證軟件單元的“故障檢測及處理”功能的正確性，以及軟件的魯棒性。

軟件集成的動態測試測試范圍：軟件架構設計文檔、細化的軟硬件接口規范。測試方法：

基于需求的測試：驗證多個單元或組件集成后的軟件功能，正向、反向的功能驗證。用來驗證分配給軟件架構的軟件要求，確保軟件架構能夠滿足系統級別的需求。

接口測試：考慮集成的組件、模塊輸入信號的有效/無效等價類和邊界值，模擬輸入檢測輸出的正確性，以檢查單元和單元或組件和組件之間數據的一致性和完整性。

故障注入測試：注入任意的接口故障以測試安全機制（例如通過損壞軟件接口），以測試與安全機制相關的軟硬件接口的正確性。

資源使用測試的目的是確認在最壞的情況下，資源CPU、ROM、RAM等的使用情況。只有在目標硬件上執行軟件測試或目標處理器的仿真器支持資源占用測試時，才能正確評估軟件資源占用情況，一般可以在PiL和HiL測試階段進行驗證。背靠背測試針對于基于MBD的開發，要求對模型生成的代碼和模型進行等效性驗證。軟件動態測試環境模型動態測試環境MIL：TPT + MATLAB/Simulink模型的動態測試主要是對模型的功能和接口進行測試，在TPT中選擇平臺和被測模型，工具可以自動獲取接口信息并生成測試框架。測試框架中包含test driver和被測模型，test driver在測試執行期間與被測系統（SUT）進行交互，通過測試框架將測試用例定義的輸入信號激勵給到被測系統（SUT），再回采被測模型的輸出結果并對其進行評估。

代碼動態測試環境SiL：PC端+交叉編譯鏈將模型生成的代碼或手寫代碼編譯成能在目標機上運行的代碼，在PC端進行驗證。

a.模型生成的代碼：TPT/FUSION + MATLAB/Simulink

用于對模型生成的代碼進行背靠背測試，使用TPT的FUSION DLL調用Simulink生成的代碼，對模型和模型生成的代碼進行相同的輸入，對比測試輸出結果。

b.手寫代碼：VectorCAST + 交叉編譯鏈

VectorCAST支持300+種交叉編譯鏈，它可以調用交叉編譯工具將源碼編譯成目標機上的可執行代碼，可以自動解析源代碼生成測試套件，測試人員能夠根據測試套件使用工具提供的測試用例生成方法或手動創建測試用例，然后測試套件和測試用例會被傳輸到模擬器或者目標板執行測試，最終將執行的結果返回到上位機界面以供查看。

嵌入式軟件測試
嵌入式軟件測試主要是驗證在目標環境執行時滿足軟件安全需求（SSR），以及不包含與功能安全相關的非預期功能和特性。測試范圍：軟件安全需求（SSR）。嵌入式軟件測試環境a.目標板+調試器 + TPT：TPT用來集成調試器，作為上位機可以進行測試用例設計及測試執行；調試器可直接訪問內存，讀取或修改寄存器、變量數值，以達到對軟件內部輸入輸出參數的修改及監控，另外調試器還可以讀取MCU中資源占用情況及各個函數的運行時間。

在嵌入式軟件測試階段，使用“目標板+調試器+TPT”的測試方案可以驗證：

①對接收到的外部故障反饋、輸入信息進行處理；

②與外部模塊的數據通訊校驗；

③可以驗證芯片的內置安全機制，比例處理器、內存、看門狗、程序流的監控等；

④資源使用測試

軟硬件集成測試

軟硬件集成測試旨在證明所集成控制器的軟件和硬件正確的交互。測試范圍：技術安全需求（TSR）、軟硬件接口規范（HSI）。軟硬件集成測試環境

a.控制器 + CANoe + VT System

在軟硬件集成測試階段，“控制器 + CANoe + VT System”可以被用來測試技術安全需求（TSR）的相關要求，包括：技術安全需求的驗證、安全機制的驗證、內部接口驗證和外部接口驗證等。

另外，該測試方案還可以用來補充嵌入式軟件階段的測試，使用“目標板+調試器 + TPT”的測試方案一般不能完全覆蓋軟件安全需求的測試，比如一些涉及到電壓采集、外部通訊的收發和外部模塊對自身故障的檢測處理等，可以使用HiL的方案輔助驗證。

b.控制器 + TPT + CANoe + VT System + 調試器

該測試方案主要是在普通的HiL環境下集成了調試器，可以用來測試軟硬件接口（HSI）。軟硬件接口的測試主要是依據接口的描述和功能進行驗證，已確認硬件可以被軟件正確的控制和使用。

總結
ISO 26262標準對零部件階段的測試從模型、代碼到最后的ECU都提出了要求，每個階段的測試重點各不相同，主要目的就是為了更快更好的查出軟件問題，保證質量。北匯信息除了能夠提供上述的測試解決方案，還可以提供對應的測試服務。