符合ISO 26262的零部件級(jí)的軟件測試解決方案

作者 |浩瀚

小編 | 不吃豬頭肉

引言
在功能安全的開發(fā)、測試過程中概念階段的活動(dòng)一般都是由主機(jī)廠負(fù)責(zé)，而從系統(tǒng)開發(fā)到單元實(shí)現(xiàn)則是由供應(yīng)商負(fù)責(zé)，對(duì)于供應(yīng)商所做的一系列測試通常稱為零部件級(jí)測試。根據(jù)ISO 26262功能安全標(biāo)準(zhǔn)的劃分，功能安全在零部件階段的測試包括：軟件單元測試、軟件集成測試、硬件集成測試、嵌入式軟件測試、軟硬件集成測試。本次主要探討軟件在零部件級(jí)的軟件測試。

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

1.來自O(shè)EM的認(rèn)可壓力：隨著主機(jī)廠對(duì)功能安全的重視和投入，主機(jī)廠越來越專業(yè)，審核要求也越來越嚴(yán)格，不僅要求過ISO 26262產(chǎn)品認(rèn)證和流程認(rèn)證，并且親自下場對(duì)各輸入物及詳細(xì)內(nèi)容進(jìn)行審查。

2.技術(shù)儲(chǔ)備不足：大多數(shù)零部件供應(yīng)商沒有專門的功能安全團(tuán)隊(duì)，缺少功能安全開發(fā)能力和測試能力。

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

軟件單元、集成測試
2.1軟件單元、集成的靜態(tài)測試
靜態(tài)測試是指在不運(yùn)行軟件的情況下，檢查軟件是否符合業(yè)內(nèi)通用的編碼規(guī)范/建模規(guī)范，像MISRA、MAB等，盡早發(fā)現(xiàn)軟件的數(shù)據(jù)流/控制流問題，以及選用一些代碼度量的約束，來提高軟件質(zhì)量。

基于MBD的靜態(tài)分析
模型的靜態(tài)分析主要是通過選擇合適的建模標(biāo)準(zhǔn)和模型度量指標(biāo)來進(jìn)行驗(yàn)證，它的分析原理就是利用模型的一些屬性和結(jié)構(gòu)信息來推斷代碼的行為和可能存在的問題。對(duì)于模型生成的代碼也需要做代碼靜態(tài)分析。

建模規(guī)范選擇

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

編碼規(guī)范選擇

在進(jìn)行代碼靜態(tài)分析時(shí)，通常依據(jù)使用的語言和遵循的規(guī)則來選用編碼規(guī)范。1)C代碼：通常選用最新的MISRA編碼標(biāo)準(zhǔn)MISRA C 2023；2)C++代碼：a.基于C++98/03開發(fā)選用MISRA C++ 2008b.基于C++11及C++14標(biāo)準(zhǔn)選用AUTOSARC.基于C++17的標(biāo)準(zhǔn)選用MISRA C++ 20233)考慮信息安全時(shí)需要遵循CERT和CWE規(guī)范。工具選擇：對(duì)于代碼的靜態(tài)測試通常選用Helix QAC，它支持多種編碼標(biāo)準(zhǔn)，以及擁有業(yè)界領(lǐng)先的編碼規(guī)范覆蓋度，擁有豐富的命令行，更容易實(shí)現(xiàn)自動(dòng)化，方便與持續(xù)集成系統(tǒng)進(jìn)行融合。

2.2軟件單元、集成的動(dòng)態(tài)測試
動(dòng)態(tài)測試通過實(shí)際執(zhí)行代碼來驗(yàn)證軟件的行為和性能是否符合預(yù)期，動(dòng)態(tài)測試可以發(fā)現(xiàn)靜態(tài)測試中未被檢測到的缺陷，確保軟件安全需求及安全機(jī)制執(zhí)行正確，無非預(yù)期的輸出，并為軟件接口的一致性和完整性提供證據(jù)。軟件單元的動(dòng)態(tài)測試測試范圍：軟件單元詳細(xì)設(shè)計(jì)規(guī)范、軟件單元接口文檔。測試方法：

基于需求的測試：使用不同輸入來激發(fā)軟件單元代碼中的各種執(zhí)行路徑，驗(yàn)證輸出符合預(yù)期，從而驗(yàn)證軟件單元設(shè)計(jì)規(guī)范和分配的軟件安全要求滿足設(shè)計(jì)要求。

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

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

軟件集成的動(dòng)態(tài)測試測試范圍：軟件架構(gòu)設(shè)計(jì)文檔、細(xì)化的軟硬件接口規(guī)范。測試方法：

基于需求的測試：驗(yàn)證多個(gè)單元或組件集成后的軟件功能，正向、反向的功能驗(yàn)證。用來驗(yàn)證分配給軟件架構(gòu)的軟件要求，確保軟件架構(gòu)能夠滿足系統(tǒng)級(jí)別的需求。

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

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

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

代碼動(dòng)態(tài)測試環(huán)境SiL：PC端+交叉編譯鏈將模型生成的代碼或手寫代碼編譯成能在目標(biāo)機(jī)上運(yùn)行的代碼，在PC端進(jìn)行驗(yàn)證。

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

用于對(duì)模型生成的代碼進(jìn)行背靠背測試，使用TPT的FUSION DLL調(diào)用Simulink生成的代碼，對(duì)模型和模型生成的代碼進(jìn)行相同的輸入，對(duì)比測試輸出結(jié)果。

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

VectorCAST支持300+種交叉編譯鏈，它可以調(diào)用交叉編譯工具將源碼編譯成目標(biāo)機(jī)上的可執(zhí)行代碼，可以自動(dòng)解析源代碼生成測試套件，測試人員能夠根據(jù)測試套件使用工具提供的測試用例生成方法或手動(dòng)創(chuàng)建測試用例，然后測試套件和測試用例會(huì)被傳輸?shù)侥M器或者目標(biāo)板執(zhí)行測試，最終將執(zhí)行的結(jié)果返回到上位機(jī)界面以供查看。

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

在嵌入式軟件測試階段，使用“目標(biāo)板+調(diào)試器+TPT”的測試方案可以驗(yàn)證：

①對(duì)接收到的外部故障反饋、輸入信息進(jìn)行處理；

②與外部模塊的數(shù)據(jù)通訊校驗(yàn)；

③可以驗(yàn)證芯片的內(nèi)置安全機(jī)制，比例處理器、內(nèi)存、看門狗、程序流的監(jiān)控等；

④資源使用測試

軟硬件集成測試

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

a.控制器 + CANoe + VT System

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

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

b.控制器 + TPT + CANoe + VT System + 調(diào)試器

該測試方案主要是在普通的HiL環(huán)境下集成了調(diào)試器，可以用來測試軟硬件接口（HSI）。軟硬件接口的測試主要是依據(jù)接口的描述和功能進(jìn)行驗(yàn)證，已確認(rèn)硬件可以被軟件正確的控制和使用。

總結(jié)
ISO 26262標(biāo)準(zhǔn)對(duì)零部件階段的測試從模型、代碼到最后的ECU都提出了要求，每個(gè)階段的測試重點(diǎn)各不相同，主要目的就是為了更快更好的查出軟件問題，保證質(zhì)量。北匯信息除了能夠提供上述的測試解決方案，還可以提供對(duì)應(yīng)的測試服務(wù)。