驗證是ISO26262中關(guān)於(yú)成果認可最重要的環節。
ISO26262對驗證(Verification)的定義是檢查對象是否滿足特定的要求,驗證的形式包括瞭(le)驗證評審(verification review)、走查(walk-through),檢查(inspection)、驗證測(cè)試(verification testing)、模拟仿真(simulation)、原型機驗證(prototyping)和分析(analysis包括安全分析、控制流程分析、數據流分析等等)。
從(cóng)驗證本身的系統性和正式程度從(cóng)小到大排序,驗證的各個(gè)形式可以排爲檢查、走查、模拟仿真、原型機驗證、分析、驗證評審。

驗證在功能安全活動不同階段的對象也有差異,比如在産(chǎn)品概念提出階段,驗證的對象主要爲:依據危害風險評估導出的安全目标以及根據安全目标定義的功能安全概念,如場景危害識别是否适用、相關性定義是否正確(què)、是否與其他相關項定義的危害和風險評估一緻、危害事件是否覆蓋實際應用等。如,在産(chǎn)品開發階段,驗證主要是針對硬件設計的架構,驗證其需求規範、架構設計、模型或代碼是否符合安全要求。

驗證以建立驗證計劃作爲開始,如上述的産(chǎn)品各個開發階段的驗證都是從(cóng)驗證計劃開始的。
驗證計劃要包括1)所需驗證的對象:組成待驗證的成果清單(dān),要考慮成果的複雜性,進行适當(dāng)的拆分;
2)針對每個待驗證的成果,確(què)定相應的驗證目的,確(què)定驗證目的時要充分借鑒前期的驗證經驗,如維修的曆史數據、已經使用的經曆等,這可以指導(dǎo)驗證目的和制定的驗證方法的剪裁;
3)對工作成果採(cǎi)用什麽樣的驗證方法,評審/檢查/走查/測(cè)試/仿真/分析,驗證方法最終要細化爲“驗證規範"作爲驗證支持依據,同時要保證驗證方法是充分的,必要時要進行幾種驗證形式的組合;
4)如果採(cǎi)用的是測試或者模拟作爲驗證方法,則要明確(què)驗證的環境和驗證所需的設備,要充分考慮驗證技術的成熟度,不能採(cǎi)用的未經過經驗證明有效性的方法和設備進行驗證;
5)分配驗(yàn)證(zhèng)資源;
6)驗證過程中出現異常時,明確(què)應該採(cǎi)取或建議採(cǎi)取的閉環活動;
7)對於(yú)哪些已經經過驗證後,進行瞭(le)變更的成果,制定回歸策略,即對驗證計劃的剪裁(是部分重複驗證,還是全部重複驗證)。
對於(yú)驗證方法的細化就形成瞭(le)驗證規範,驗證規範最需要細化的是測試用例。

1)測(cè)試用例的識别性,即該(gāi)測(cè)試應用到哪項成果,什麽目的驗證;
2)測(cè)試用例針對(duì)的是哪個版本的工作成果;
3)對驗證目标採(cǎi)用何種預處理或配置,比如将MCU應用在什麽場景下,配置什麽功能或系統,如果對於(yú)通用型的要素,其會在很多場合應用,則需将要素置於(yú)一種通用的(覆蓋多種應用場景的)條件下進行驗證;
4)環境條件,就是與測(cè)試過程或模拟過程相關(guān)的物理條件,比如溫度。
5)驗證過程中要監測的行爲,比如輸出數據,可接受的範圍,時間或容差的特性,測試時需要考核前後數據的變化趨勢,就需要對初始值進行明確(què)的定義;有可能存在不同的測試用例下,會存在多種預處理、配置或環境條件和規範,這時候可以採(cǎi)用一種明確(què)能覆蓋多種測試用例的驗證配置進行驗證。
6)測(cè)試通過(guò)和不通過(guò)的判據。
測試用例可以根據測試設備(bèi)和測試環境、邏輯和時序關系、所利用的資源進行分組,比如對於(yú)可以分爲回歸測試用例或者完整的測試用例。
驗證要求第二/三方驗證,即不能用工作成果的完成人進行驗證。驗證完成後(hòu)要對(duì)驗證的結果進行評估。
驗證結果評估需包括1)評(píng)估驗(yàn)證的成果是不是ONLY的;
2)評估驗證計劃和驗證規(guī)範(fàn)的完整性和适用性;
3)評估驗證過(guò)程中所用到的環(huán)境配置、驗證工具及标定數據是否符合要求;
4)評(píng)估驗證結(jié)果與預期結(jié)果的一緻性;
5)綜合給出驗證通過或不通過,並(bìng)對於(yú)不通過的給出具體的理由以及整改建議;
6)如果存在驗證過程未按照驗證計劃或規範(fàn)執行,需要給(gěi)出理由。
單一層(céng)級的驗證,比如隻針對開發的硬件進行功能、性能等安全性的評估,並(bìng)不能提供硬件滿足安全要求的充分證據,比如:硬件與其他接口兼容性、硬件與其他已有硬件的匹配性、硬件對整車安全的貢獻性、硬件開發的種種假設證明的有效性等等,這些都無法單獨在硬件驗證的層(céng)面進行評估。
因此,爲充分評估開發硬件的功能安全,往往要通過将硬件與軟件、其他要素、系統甚至整車(chē)集成起來,按照“驗證原型機測(cè)試"的标準去考核。ISO26262給(gěi)出集成測(cè)試的相關規定。
集成與驗證的相關規定關於(yú)集成測試,某一開發的硬件要通過三個階段集成至整車系統,完成安全目标的確(què)認。


但是從(cóng)集成的難度和所需要的資源的考慮,集集成階(jiē)段越高,集成驗證的難度越高,占用資源越多,因此盡可能選擇低階(jiē)段的集成策略。
如何選(xuǎn)擇集成驗(yàn)證的策略:
1)明確(què)需要驗證測(cè)試的目标,比如要驗證安全機制對傳感器的診斷,EDC對數據錯誤的診斷和控制等;
2)定義這些承載這些測(cè)試目标的相關項和測(cè)試的要求(預期的行爲,集成的等級),比如驗證開發(fā)的硬件與接口的兼容性,就必須考慮硬件與系統的集成;
3)確(què)定瞭(le)測試的目标和承載這些目标的相關項和測試要求,要進行梳理,確(què)保每一條測試的目标都能夠進行至少一次地驗證,比如某項測試目标無法在軟硬件集成階段進行驗證,則需要到系統集成階段進行驗證;
4)要考慮硬件開發概念階段是否採用瞭(le)假設,如SEooC的開發,是基於(yú)應用假設爲前提的,對這種假設需要在系統,甚至是整車的層面進行集成驗證;
5)如果系統集成時,存在多個可能的集成變(biàn)體,即所謂的多配置,那麽我們就要充分評估,在未來整車量産時,可能採(cǎi)用哪些系統配置,盡可能地包絡這些系統配置(或形成系統的集合)完成系統級的驗證。

確(què)定目标和相應的集成策略後,根據需要選擇相對應的方法,ISO26262 part4 第7.4.2-7.4.4給出瞭(le)三個集成階段的測試方法,總體上包括:
1)功能和非功能的測(cè)試:對(duì)集成硬件的功能和性能對(duì)照規格書要求的測(cè)試;
2)内外接口測(cè)試:包括模拟,數字輸入輸出測(cè)試、邊(biān)界測(cè)試和等價類測(cè)試,評估接口功能兼容性、時序容錯性。
1)故障注入測(cè)試:採(cǎi)用特殊方法向運行中的測(cè)試對象注入故障,如騷擾、錯誤數據、延遲時序等;
2)背靠背測(cè)試:在具有仿真模型和結果的情況下,採(cǎi)用實際試驗對仿真模型和結果的差異進行評估和分析。
1)錯誤猜測(cè)法測(cè)試:類似故障注入法,基於(yú)專家知識和經驗數據預測(cè)被測(cè)對象可能錯在的錯誤,然後設計評估方法去檢查這些錯誤;
2)來自現場經驗的測(cè)試:直接從使用現場採(cǎi)集的數據,如試車時的運行數據;
3)長期測(cè)試:類似來自現場(chǎng)經驗的測(cè)試,隻是将普通用戶作爲測(cè)試者,收集實際使用條件下的數據。
1)資源使用測(cè)試:對(duì)集成系統所能容納的負載,代碼,功率等能力進行測(cè)試;
2)壓力測(cè)試:測(cè)試對象在高負載和惡劣環境下是否能夠長(zhǎng)期穩定運行的能力進行測(cè)試。