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

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

圖1 DO178 中關于 Verification 的描述

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

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

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

技術交流

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

2019年 7 月2 日 950

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

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

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

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

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

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

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

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