引言
在功能安全的開發、測試過程中概念階段的活動一般都是由主機廠負責，而從系統開發到單元實現則是由供應商負責，對於供應商所做的一系列測試通常稱為零部件級測試。根據ISO 26262功能安全標準的劃分，功能安全在零部件階段的測試包括：軟體單元測試、軟體整合測試、硬體整合測試、嵌入式軟體測試、軟硬體整合測試。本次主要探討軟體在零部件階段的測試。
目前功能安全零部件測試的困難
來自OEM的認可壓力：隨著主機廠對功能安全的重視和投入，主機廠越來越專業，稽核要求也越來越嚴格，不僅要求過ISO 26262產品認證和流程認證，並且親自下場對各輸入物及詳細內容進行審查。
技術儲備不足：大多數零部件供應商沒有專門的功能安全團隊，缺少功能安全開發能力和測試能力。
資源不足：大部分零部件供應商缺少完整的測試工具鏈，各階段測試人員配備不齊。
目前國內的功能安全標準正處於由國家推薦性標準逐漸向強制性標準過渡的時期，加之在新能源汽車出海的大趨勢下，功能安全標準也正在加速與國際接軌。未來功能安全標準將成為汽車供應鏈廠商的准入門檻之一。那麼執行滿足功能安全標準要求的測試已是刻不容緩且必須解決的問題，下面將依據功能安全標準和公司在軟體測試方面的積累提供滿足功能安全測試的解決方案。
軟體單元、整合測試
軟體單元、整合的靜態測試
靜態測試是指在不執行軟體的情況下，檢查軟體是否符合業內通用的編碼規範/建模規範，像MISRA、MAB等，儘早發現軟體的資料流/控制流問題，以及選用一些程式碼度量的約束，來提高軟體質量。
基於MBD的靜態分析
模型的靜態分析主要是透過選擇合適的建模標準和模型度量指標來進行驗證，它的分析原理就是利用模型的一些屬性和結構資訊來推斷程式碼的行為和可能存在的問題。對於模型生成的程式碼也需要做程式碼靜態分析。
建模規範選擇：在進行模型靜態分析時，依據使用的建模工具和要求來選擇建模規則。
- 所有基於MBD的開發都需要選擇MAB建模規範；
- 使用了Simulink 和 Stateflow 的模型工具需要選擇MISRA SLSF；
- 使用了TargetLink的模型工具需要選擇MISRA TL；
- 如果需要符合ISO 26262對於模型的標準要求，需要選擇定製的功能安全規範。
工具選擇：對於模型的靜態測試通常選用MES的MXAM工具，MXAM是一款高度自動化的靜態分析工具，可支援多種模型型別的檢查，並且提供了符合ISO 26262標準的檢查規範。
手寫程式碼的靜態分析
程式碼的靜態分析主要從編碼規範的檢查、程式流和資料流的分析、程式碼度量分析等三個維度展開。它的分析原理是對編寫的程式碼進行逐行檢查，尋找潛在的錯誤、漏洞和不符合規範的程式碼結構。
編碼規範選擇：在進行程式碼靜態分析時，通常依據使用的語言和遵循的規則來選用編碼規範。
- C程式碼：通常選用最新的MISRA編碼標準MISRA C 2023；
- C++程式碼：
- 基於C++98/03開發選用MISRA C++ 2008；
- 基於C++11及C++14標準選用AUTOSAR；
- 基於C++17的標準選用MISRA C++ 2023；
- 考慮資訊保安時需要遵循CERT和CWE規範。
工具選擇：對於程式碼的靜態測試通常選用Helix QAC，它支援多種編碼標準，以及擁有業界領先的編碼規範覆蓋度，擁有豐富的命令列，更容易實現自動化，方便與持續整合系統進行融合。
軟體單元、整合的動態測試
動態測試透過實際執行程式碼來驗證軟體的行為和效能是否符合預期，動態測試可以發現靜態測試中未被檢測到的缺陷，確保軟體安全需求及安全機制執行正確，無非預期的輸出，併為軟體介面的一致性和完整性提供證據。
軟體單元的動態測試
測試範圍：軟體單元詳細設計規範、軟體單元介面文件。
測試方法：
基於需求的測試：使用不同輸入來激發軟體單元程式碼中的各種執行路徑，驗證輸出符合預期，從而驗證軟體單元設計規範和分配的軟體安全要求滿足設計要求。
介面測試：考慮軟體單元輸入訊號的無效/有效等價類和邊界值，模擬輸入檢測輸出的正確性，從而驗證軟體單元與介面文件的一致性、輸出的正確性。
故障注入測試：故障注入測試一般要修改被測的軟體單元（比如改變變數的值，引入程式碼突變或破壞CPU暫存器的值），主要用來驗證軟體單元的“故障檢測及處理”功能的正確性，以及軟體的魯棒性。
軟體整合的動態測試
測試範圍：軟體架構設計文件、細化的軟硬體介面規範。
測試方法：
基於需求的測試：驗證多個單元或元件整合後的軟體功能，正向、反向的功能驗證。用來驗證分配給軟體架構的軟體要求，確保軟體架構能夠滿足系統級別的需求
介面測試：考慮整合的元件、模組輸入訊號的有效/無效等價類和邊界值，模擬輸入檢測輸出的正確性，以檢查單元和單元或元件和元件之間資料的一致性和完整性。
故障注入測試：注入任意的介面故障以測試安全機制（例如透過損壞軟體介面），以測試與安全機制相關的軟硬體介面的正確性。
資源使用測試的目的是確認在最壞的情況下，資源CPU、ROM、RAM等的使用情況。只有在目標硬體上執行軟體測試或目標處理器的模擬器支援資源佔用測試時，才能正確評估軟體資源佔用情況，一般可以在PIL和HIL測試階段進行驗證。
背靠背測試針對於基於MBD的開發，要求對模型生成的程式碼和模型進行等效性驗證。
軟體動態測試環境
模型動態測試環境MIL：TPT + MATLAB/Simulink
模型的動態測試主要是對模型的功能和介面進行測試，在TPT中選擇平臺和被測模型，工具可以自動獲取介面資訊並生成測試框架。測試框架中包含test driver和被測模型，test driver在測試執行期間與被測系統（SUT）進行互動，透過測試框架將測試用例定義的輸入訊號激勵給到被測系統（SUT），再回採被測模型的輸出結果並對其進行評估。
程式碼動態測試環境SIL：PC端+交叉編譯鏈
將模型生成的程式碼或手寫程式碼編譯成能在目標機上執行的程式碼，在PC端進行驗證。
模型生成的程式碼：TPT/FUSION + MATLAB/Simulink
用於對模型生成的程式碼進行背靠背測試，使用TPT的FUSION DLL呼叫Simulink生成的程式碼，對模型和模型生成的程式碼進行相同的輸入，對比測試輸出結果。
手寫程式碼：VectorCAST + 交叉編譯鏈
VectorCAST支援300+種交叉編譯鏈，它可以呼叫交叉編譯工具將原始碼編譯成目標機上的可執行程式碼，可以自動解析原始碼生成測試套件，測試人員能夠根據測試套件使用工具提供的測試用例生成方法或手動建立測試用例，然後測試套件和測試用例會被傳輸到模擬器或者目標板執行測試，最終將執行的結果返回到上位機介面以供檢視。
二、嵌入式軟體測試
嵌入式軟體測試主要是驗證在目標環境執行時滿足軟體安全需求（SSR），以及不包含與功能安全相關的非預期功能和特性。
測試範圍：軟體安全需求（SSR）。
嵌入式軟體測試環境
目標板+偵錯程式 + TPT：
TPT用來整合偵錯程式，作為上位機可以進行測試用例設計及測試執行；偵錯程式可直接訪問記憶體，讀取或修改暫存器、變數數值，以達到對軟體內部輸入輸出引數的修改及監控，另外偵錯程式還可以讀取MCU中資源佔用情況及各個函式的執行時間。
在嵌入式軟體測試階段，使用“目標板+偵錯程式+TPT”的測試方案可以驗證：
- 對接收到的外部故障反饋、輸入資訊進行處理；
- 與外部模組的資料通訊校驗；
- 可以驗證晶片的內建安全機制，比例處理器、記憶體、看門狗、程式流的監控等；
- 資源使用測試
三、軟硬體整合測試
軟硬體整合測試旨在證明所整合控制器的軟體和硬體正確的互動。
測試範圍：技術安全需求（TSR）、軟硬體介面規範（HSI）。
軟硬體整合測試環境
控制器 + CANoe + VT System
在軟硬體整合測試階段，“控制器 + CANoe + VT System”可以被用來測試技術安全需求（TSR）的相關要求，包括：技術安全需求的驗證、安全機制的驗證、內部介面驗證和外部介面驗證等。
另外，該測試方案還可以用來補充嵌入式軟體階段的測試，使用“目標板+偵錯程式 + TPT”的測試方案一般不能完全覆蓋軟體安全需求的測試，比如一些涉及到電壓採集、外部通訊的收發和外部模組對自身故障的檢測處理等，可以使用HIL的方案輔助驗證。
控制器 + TPT + CANoe + VT System + 偵錯程式
該測試方案主要是在普通的HIL環境下整合了偵錯程式，可以用來測試軟硬體介面（HSI）。軟硬體介面的測試主要是依據介面的描述和功能進行驗證，已確認硬體可以被軟體正確的控制和使用。
總結
ISO 26262標準對零部件階段的測試從模型、程式碼到最後的ECU都提出了要求，每個階段的測試重點各不相同，主要目的就是為了更快更好的查出軟體問題，保證質量。北匯除了能夠提供上述的測試解決方案，還可以提供對應的測試服務。如果有需要或想了解更多資訊，歡迎您來聯絡我們。