驗證是ISO26262中關于成果認可最重要的環節。

        ISO26262對驗證（Verification）的定義是檢查對象是否滿足特定的要求，驗證的形式包括了驗證評審（verification review）、走查（walk-through），檢查（inspection）、驗證測試（verification testing）、模擬仿真（simulation）、原型機驗證（prototyping）和分析（analysis包括安全分析、控制流程分析、數據流分析等等）。

        從驗證本身的系統性和正式程度從小到大排序，驗證的各個形式可以排為檢查、走查、模擬仿真、原型機驗證、分析、驗證評審。

        驗證在功能安全活動不同階段的對象也有差異，比如在產品概念提出階段，驗證的對象主要為：依據危害風險評估導出的安全目標以及根據安全目標定義的功能安全概念，如場景危害識別是否適用、相關性定義是否正確、是否與其他相關項定義的危害和風險評估一致、危害事件是否覆蓋實際應用等。如，在產品開發階段，驗證主要是針對硬件設計的架構，驗證其需求規范、架構設計、模型或代碼是否符合安全要求。

        驗證以建立驗證計劃作為開始，如上述的產品各個開發階段的驗證都是從驗證計劃開始的。

        1）所需驗證的對象：組成待驗證的成果清單，要考慮成果的復雜性，進行適當的拆分；

        2）針對每個待驗證的成果，確定相應的驗證目的，確定驗證目的時要充分借鑒前期的驗證經驗，如維修的歷史數據、已經使用的經歷等，這可以指導驗證目的和制定的驗證方法的剪裁；

        3）對工作成果采用什么樣的驗證方法，評審/檢查/走查/測試/仿真/分析，驗證方法最終要細化為“驗證規范"作為驗證支持依據，同時要保證驗證方法是充分的，必要時要進行幾種驗證形式的組合；

        4）如果采用的是測試或者模擬作為驗證方法，則要明確驗證的環境和驗證所需的設備，要充分考慮驗證技術的成熟度，不能采用的未經過經驗證明有效性的方法和設備進行驗證；

        5）分配驗證資源；

        6）驗證過程中出現異常時，明確應該采取或建議采取的閉環活動；

        7）對于哪些已經經過驗證后，進行了變更的成果，制定回歸策略，即對驗證計劃的剪裁（是部分重復驗證，還是全部重復驗證）。

        對于驗證方法的細化就形成了驗證規范，驗證規范最需要細化的是測試用例。

        1）測試用例的識別性，即該測試應用到哪項成果，什么目的驗證；

        2）測試用例針對的是哪個版本的工作成果；

        3）對驗證目標采用何種預處理或配置，比如將MCU應用在什么場景下，配置什么功能或系統，如果對于通用型的要素，其會在很多場合應用，則需將要素置于一種通用的（覆蓋多種應用場景的）條件下進行驗證；

        4）環境條件，就是與測試過程或模擬過程相關的物理條件，比如溫度。

        5）驗證過程中要監測的行為，比如輸出數據，可接受的范圍，時間或容差的特性，測試時需要考核前后數據的變化趨勢，就需要對初始值進行明確的定義；有可能存在不同的測試用例下，會存在多種預處理、配置或環境條件和規范，這時候可以采用一種明確能覆蓋多種測試用例的驗證配置進行驗證。

        6）測試通過和不通過的判據。

測試用例可以根據測試設備和測試環境、邏輯和時序關系、所利用的資源進行分組，比如對于可以分為回歸測試用例或者完整的測試用例。

        驗證要求第二/三方驗證，即不能用工作成果的完成人進行驗證。驗證完成后要對驗證的結果進行評估。

        2）評估驗證計劃和驗證規范的完整性和適用性；

        3）評估驗證過程中所用到的環境配置、驗證工具及標定數據是否符合要求；

        4）評估驗證結果與預期結果的一致性；

        5）綜合給出驗證通過或不通過，并對于不通過的給出具體的理由以及整改建議；

        6）如果存在驗證過程未按照驗證計劃或規范執行，需要給出理由。

        單一層級的驗證，比如只針對開發的硬件進行功能、性能等安全性的評估，并不能提供硬件滿足安全要求的充分證據，比如：硬件與其他接口兼容性、硬件與其他已有硬件的匹配性、硬件對整車安全的貢獻性、硬件開發的種種假設證明的有效性等等，這些都無法單獨在硬件驗證的層面進行評估。

        因此，為充分評估開發硬件的功能安全，往往要通過將硬件與軟件、其他要素、系統甚至整車集成起來，按照“驗證原型機測試"的標準去考核。ISO26262給出集成測試的相關規定。

關于集成測試，某一開發的硬件要通過三個階段集成至整車系統，完成安全目標的確認。

        但是從集成的難度和所需要的資源的考慮，集集成階段越高，集成驗證的難度越高，占用資源越多，因此盡可能選擇低階段的集成策略。

        如何選擇集成驗證的策略：

        1）明確需要驗證測試的目標，比如要驗證安全機制對傳感器的診斷，EDC對數據錯誤的診斷和控制等；

        2）定義這些承載這些測試目標的相關項和測試的要求（預期的行為，集成的等級），比如驗證開發的硬件與接口的兼容性，就必須考慮硬件與系統的集成；

        3）確定了測試的目標和承載這些目標的相關項和測試要求，要進行梳理，確保每一條測試的目標都能夠進行至少一次地驗證，比如某項測試目標無法在軟硬件集成階段進行驗證，則需要到系統集成階段進行驗證；

        4）要考慮硬件開發概念階段是否采用了假設，如SEooC的開發，是基于應用假設為前提的，對這種假設需要在系統，甚至是整車的層面進行集成驗證；

        5）如果系統集成時，存在多個可能的集成變體，即所謂的多配置，那么我們就要充分評估，在未來整車量產時，可能采用哪些系統配置，盡可能地包絡這些系統配置（或形成系統的集合）完成系統級的驗證。

        確定目標和相應的集成策略后，根據需要選擇相對應的方法，ISO26262 part4 第7.4.2-7.4.4給出了三個集成階段的測試方法，總體上包括：

        1）功能和非功能的測試：對集成硬件的功能和性能對照規格書要求的測試；

        2）內外接口測試：包括模擬，數字輸入輸出測試、邊界測試和等價類測試，評估接口功能兼容性、時序容錯性。

        1）故障注入測試：采用特殊方法向運行中的測試對象注入故障，如騷擾、錯誤數據、延遲時序等；

        2）背靠背測試：在具有仿真模型和結果的情況下，采用實際試驗對仿真模型和結果的差異進行評估和分析。

        1）錯誤猜測法測試：類似故障注入法，基于專家知識和經驗數據預測被測對象可能錯在的錯誤，然后設計評估方法去檢查這些錯誤；

        2）來自現場經驗的測試：直接從使用現場采集的數據，如試車時的運行數據；

3）長期測試：類似來自現場經驗的測試，只是將普通用戶作為測試者，收集實際使用條件下的數據。

        1）資源使用測試：對集成系統所能容納的負載，代碼，功率等能力進行測試；

        2）壓力測試：測試對象在高負載和惡劣環境下是否能夠長期穩定運行的能力進行測試。