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

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

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

• 確定需求

• 實現(xiàn)需求

• 驗證需求

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

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

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

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

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

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

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

• Safety verification：驗證功能安全需求有沒有被實現(xiàn)？

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

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

2. Safety verification （安全驗證）

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

2.1 系統(tǒng)層功能安全需求驗證

系統(tǒng)層的功能安全需求驗證主要是通過相關項的系統(tǒng)集成和測試實現(xiàn)。

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

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

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

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

• 安全機制正確的功能表現(xiàn)、準確性和時序

• 接口實現(xiàn)的一致性與正確性

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

• 魯棒性水平

2.1.1. 軟硬件集成測試

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

2.1.2. 系統(tǒng)集成測試

為了發(fā)現(xiàn)系統(tǒng)集成中的系統(tǒng)性故障，應根據(jù)需求對應的ASIL等級使用下面表格中給出的可行的測試方法來實現(xiàn)。

2.1.3. 整車集成測試

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

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

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

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

軟件層功能安全需求的開發(fā)主要體現(xiàn)在以下三個方面：

• 軟件架構設計

• 軟件單元設計

• 軟件集成

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

2.3.1. 軟件架構設計的驗證

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

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

• 與目標硬件的兼容性

• 與設計指南保持一致

2.3.2. 軟件單元設計的驗證

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

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

• 與目標硬件的兼容性

• 與設計指南保持一致

• 對軟硬件接口規(guī)范的符合性

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

• 源代碼與其設計規(guī)范的一致性

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

• 軟件單元的實現(xiàn)與目標硬件的兼容性

  
  

• 

3. Safety validation（安全確認）

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

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

• 提供安全目標在整車層面上是正確的、完整的并得到完全實現(xiàn)的證據(jù)。

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

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

• Safety verification：驗證功能安全需求有沒有被實現(xiàn)？

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

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

3.1. 安全確認的環(huán)境

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

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

3.2. 安全驗證的目標

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

• 可控性

• 用于控制隨機失效和系統(tǒng)性失效的安全措施的有效性

• 外部措施的有效性

• 其他技術要素的有效性

3.3. 安全驗證的方式

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

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

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

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

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

• 評審