ISO26262功能安全驗證和確認

ISO 26262將功能安全開發融入了廣為熟知的“V模型”開發流程中。根據系統/軟件/硬件三個層級的劃分，ISO 26262共涉及三個“V模型”：

“V模型”中的功能安全開發，截圖來自ISO 26262

“V模型”可以簡單概括為三步：

• 確定需求

• 實現需求

• 驗證需求

在前面的系列文章中將重點放在了“V模型”的左邊的功能安全活動上，本文將對右邊展開說明，即功能安全驗證（safety verification）和功能安全確認（safety validation）。

1. Verification (驗證) 和validation (確認) 辨析

讀者如果查英文字典會發現，verification和validation的釋義十分接近，功能安全國標GB/ T 34590中將這兩個詞分別翻譯成“驗證”和“確認”，實際上單看這兩個詞還是會讓讀者產生含義重合的印象。因此在開始本文之前，有必要對這兩個概念進行辨析。

維基百科上對這兩個詞的解釋非常到位：

• Verification：Have we made what we were trying to make? （預期的事情有沒有實現？）

• Validation: Are we trying to make the right thing? （做的事情是否正確？）

沿著這個思路理解功能按照開發中的概念，可以得到如下解釋：

• Safety verification：驗證功能安全需求有沒有被實現？

• Safety validation: 確認功能安全需求提的對不對？即功能安全需求實現了是否確實能保證安全？

根據這樣的解釋可以發現功能安全驗證（safety verification）和功能安全確認（safety validation）屬于兩個維度。接下來將分別從這兩個維度來說明ISO 26262中的要求。

2. Safety verification （安全驗證）

功能安全概念開發可以簡單概括為：基于整車層的安全目標和相關項的系統架構和邊界導出系統功能安全需求；進一步根據細化的軟硬件架構分別導出軟件功能安全需求和硬件功能安全需求。關于系統/硬件/軟件三個層級的功能安全需求如何進行安全驗證（safety verification）分別記錄在標準中的第4/5/6部分，為便于理解，接下來將以中文版GB/ T 34590為參考對其進行一個總結。

2.1 系統層功能安全需求驗證

系統層的功能安全需求驗證主要是通過相關項的系統集成和測試實現。

• 相關項集成過程的第一個目標是測試每一條安全要求是否滿足規范以及ASIL級別的要求。

• 相關項集成過程的第二個目標是驗證涵蓋安全要求的“系統設計”在整個相關項上是否得到正確實施。

相關項要素的集成按照系統化的方法進行，從軟硬件集成開始，經過系統集成，最后完成整車集成，測試目標包括但不限于：

• 功能安全要求和技術安全要求的正確實施

• 安全機制正確的功能表現、準確性和時序

• 接口實現的一致性與正確性

• 安全機制的診斷或失效覆蓋的有效性

• 魯棒性水平

2.1.1. 軟硬件集成測試

為了發現系統設計中的系統性故障，在軟硬件集成過程中，應根據需求對應的ASIL等級使用下面表格中給出的可行的測試方法來實現。

2.1.2. 系統集成測試

為了發現系統集成中的系統性故障，應根據需求對應的ASIL等級使用下面表格中給出的可行的測試方法來實現。

2.1.3. 整車集成測試

為了探測整車集成期間的系統性故障，應根據需求對應的ASIL等級使用下面表格中給出的可行的測試方法來實現。

2.2. 硬件層功能安全需求驗證

硬件層功能安全需求驗證主要目的是驗證硬件設計是否違背系統設計規范和硬件安全要求，從而保證硬件設計與硬件安全要求的一致性和完整性。

2.3. 軟件層功能安全需求驗證

軟件層功能安全需求的開發主要體現在以下三個方面：

• 軟件架構設計

• 軟件單元設計

• 軟件集成

軟件層的安全驗證也是基于這三個方面展開。

2.3.1. 軟件架構設計的驗證

軟件架構設計的驗證使用表6中所列出的軟件架構驗證方法來論證下述屬性:

• 與軟件安全要求的符合性

• 與目標硬件的兼容性

• 與設計指南保持一致

2.3.2. 軟件單元設計的驗證

軟件單元設計的驗證使用表9中所列出的軟件架構驗證方法來證明:

• 與軟件安全要求的符合性

• 與目標硬件的兼容性

• 與設計指南保持一致

• 對軟硬件接口規范的符合性

• 通過追溯性表明滿足了分配給軟件單元的軟件安全要求

• 源代碼與其設計規范的一致性

• 源代碼與其編碼指南的一致性

• 軟件單元的實現與目標硬件的兼容性

  
  

• 

3. Safety validation（安全確認）

標準中將安全確認的目的概括為：

• 提供符合安全目標的證據及功能安全概念適合相關項的功能安全的證據。

• 提供安全目標在整車層面上是正確的、完整的并得到完全實現的證據。

由此可以看出安全確認中的“確認”在于確認安全目標及安全目標對應的安全標準(safety criteria)是否被滿足。

結合到安全目標與安全需求之間的關系可以看出，只有當整車層的安全目標被滿足了，才能說明由安全目標導出的安全需求如果實現了可以保證安全。這與文章開頭闡述的安全驗證和安全確認的概念相吻合。

• Safety verification：驗證功能安全需求有沒有被實現？

• Safety validation: 確認功能安全需求提的對不對？即功能安全需求實現了是否確實能保證安全？

安全確認的要求和要點可以從以下幾個方面概括。

3.1. 安全確認的環境

不同的車型整車各方面參數不同，導致車輛的動態表現都有區別，因此對于和整車動態表現有必然聯系的安全目標（如制動、驅動和轉向等）都應該采用整車環境對相關項進行安全目標進行確認。

對于和整車環境無必然聯系的安全目標（如HMI相關），在有充分的證據表明仿真環境準確性可信的情況下也可以選擇仿真環境（如HiL）。

3.2. 安全驗證的目標

通常來說，通過評估以下幾個方面來確認安全目標是否被實現。

• 可控性

• 用于控制隨機失效和系統性失效的安全措施的有效性

• 外部措施的有效性

• 其他技術要素的有效性

3.3. 安全驗證的方式

在這里需要強調一個容易被誤解的點，安全目標的確認不是只有測試這一種方式，而是可以使用以下方法的適當組合:

• 已定義了測試流程、測試案例和通過/未通過準則的可重復性測試(功能和安全要求的正向測試、黑盒測試、仿真、邊界條件下的測試、故障注入、耐久測試、壓力測試、高加速壽命測試、外部影響模擬)

• 分析;（如FMEA、FTA、ETA）

• 長期測試,例如車輛駕駛日程安排和受控測試車隊

• 實際使用條件下的用戶測試、抽測或盲測、專家小組

• 評審