自 ISO 26262 2018 版發(fā)布后，細心的讀者可能會發(fā)現(xiàn)在第六章的軟件開發(fā)部分的措辭有了微妙的變化，從測試（Testing）變成了驗證（Verification）。比如軟件單元測試變成了軟件單元驗證，軟件集成與測試變成了軟件集成與驗證。

那么這兩者有什么區(qū)別？新標準為什么要做這樣的變動呢？也許我們可以從 DO178 中找到一些答案，在 DO178 中有如下說明：

圖1 DO178 中關于 Verification 的描述

即驗證并非簡單的測試，因為測試不能展示沒有錯誤。驗證的范圍大于測試，通常會包括評審、分析和測試；類似的表述在 IEC61508 標準中也能找到。我們來比較一下新舊標準中關于軟件集成與測試（驗證）的方法：

圖2 ISO 26262 2011版(上)和2018版（下）中的軟件集成與測試/驗證方法

舊版本在軟件集成驗證階段以動態(tài)測試為主：基于需求的測試、接口測試、故障注入測試、資源使用測試和背靠背測試；而新版本在舊版本的基礎上增加了包括靜態(tài)分析在內(nèi)的方法：控制流和數(shù)據(jù)流的驗證、靜態(tài)代碼分析和基于抽象解釋的靜態(tài)分析。從中可以看到軟件驗證環(huán)節(jié)需要結(jié)合包括動態(tài)測試、靜態(tài)分析和人工評審在內(nèi)的多種手段才能更有效排除錯誤，確保交付質(zhì)量。

技術交流

ISO 26262 研討會（上海/北京）

2019年 7 月2 日 950

主要介紹 MathWorks 工具鏈對于 ISO 26262 和 SOTIF 的支持情況，涵蓋滿足 ISO 26262 要求的模型驗證和代碼驗證、符合 ISO 26262 軟件開發(fā)過程中的工具審核問題，以及針對無人駕駛應用的場景建模仿真等方向。

請掃描二維碼完成此次活動注冊：

從實施角度看，控制流和數(shù)據(jù)流可以采用覆蓋度識別模型中的不可達邏輯、調(diào)用樹分析函數(shù)關系以及共享變量的讀寫沖突檢查等；靜態(tài)分析手段則包括了代碼（或模型）的合規(guī)和缺陷檢查、復雜度等數(shù)據(jù)統(tǒng)計；基于抽象解釋的靜態(tài)分析采用了更為深入的形式化驗證方法，對于特定范圍內(nèi)的模型或代碼錯誤進行類窮舉分析以確保軟件安全（ absence of errors）。

隨著自動駕駛等應用的興起，在確定性的系統(tǒng)故障失效問題之外增加了由于類似于傳感器性能受限、人工智能算法功能不足以及駕駛者誤操作等不確定因素，需要在功能安全之外有新的安全標準補充，即預期功能安全（SOTIF）。SOTIF 的核心問題是探索發(fā)現(xiàn)未知不安全場景（區(qū)域 3）并將其轉(zhuǎn)化為已知不安全場景（區(qū)域 2），通過風險評估和功能改進迭代最終實現(xiàn)已知安全場景（區(qū)域 1）的最大化。

圖3 SOTIF 中的場景分類和目標

在這個過程中測試擔當了非常大的比重，不管是針對區(qū)域2的需求測試還是針對區(qū)域 3 的隨機測試。一款自動駕駛應用的成熟可能需要數(shù)十億公里的測試，而仿真作為高效率低成本的測試手段，不管從模型在環(huán)到硬件在環(huán)還是從 NCAP 標準測試場景到隨機生成測試場景，都是應對 SOTIF 的利器。

圖4 MBD 流程中的 SOTIF 驗證和確認

在汽車行業(yè)技術劇變前夕，未來新應用的復雜度呈指數(shù)級增加，創(chuàng)新點逐漸從機械為主到以軟件為主，最終融合為以模型為中心?；谀Ｐ偷牧鞒毯头椒ǜ@前所未有的重要，自動化的仿真、測試和驗證技術的深入應用可以幫助我們更好地應對這些新的挑戰(zhàn)。