5.1.工作成果

這一小節描述了“工作成果”一詞。

工作成果是滿足ISO26262系列標準相應要求的結果（見ISO26262-1：2018的3.185）。因此，工作成果可以提供符合這些安全要求的證據。

需求規范是可以通過需求數據庫或文本文件記錄的工作成果。可執行模型是一種工作成果，可以通過建模可以執行的語言文件來表示（例如：用于使用軟件工具進行模擬）。

工作成果的文件（見【文檔管理】ISO26262-8：2018的第10條）作為執行的安全活動、安全要求或相關信息的記錄。這種文件不限于任何形式或媒介。

工作成果的文檔可以用電子或紙質文件、單個文檔或一組文檔來表示。它可以與其他工作成果的文檔或不直接用于功能安全的文檔相結合。

為了避免信息的重復，可以使用文檔內部或文檔之間的交叉引用。

5.2.確認措施

5.2.1概述

在ISO26262中，指定的工作成果在隨后的活動中被評估，無論是作為確認措施的一部分，還是作為驗證活動的一部分。本款說明核查和確認措施的區別。

驗證活動是ISO26262中的主要措施，以提供證據證明工作成果是合適的，并符合相應的要求。工作成果的驗證可包括：

? 根據更高級別的安全要求，對導出的安全要求的規范或實施進行驗證，涉及完整性和正確性；或

? 通過行使相關項或其要素，執行測試用例和檢查測試結果，以提供滿足特定安全要求的證據。

驗證活動在ISO26262-3、ISO26262-4、ISO26262-5和ISO26262-6中有規定。此外，ISO26262系列標準中有關驗證活動的一般要求在【驗證】（ISO26262-8：2018中規定，第9條）和【安全需求規范和管理】（ISO26262-8：2018的第6條）中規定了具體的安全要求驗證細節。

工作成果的驗證可以通過使用技術進行，例如：

? 評審；

? 模擬；

? 分析；或

? 測試。

認可措施在【認可措施】（ISO26262-2：2018的6.4.9）中規定，并被執行以評估相關項在功能安全方面的成就。

示例：如果在系統架構設計階段應用ASIL分解：

對由此產生的系統架構設計的驗證是根據技術安全概念進行的（見【認可措施】ISO26262-4：2018的6.4.9）；及

【關于ASIL剪裁的需求分解】（ISO26262-9：2018的第5條），確認ASIL分解的正確應用可以作為功能安全評估的一部分進行，包括確認已經進行了相關故障分析，并證明在實現相應冗余安全要求的要素之間聲稱有足夠的獨立性。

5.2.2功能安全評估

如果相關項安全目標的最高ASIL是ASILC或D，則進行功能安全評估，以評估相關項實現功能安全的情況。在ISO26262-2中，描述了功能安全評估的某些方面以及確認措施的進一步方面。

功能安全評估的范圍在【相關項的安全管理】（ISO26262-2：2018的第6條）。

在進行功能安全評估的情況下，功能安全審計和確認評審的結果是功能安全評估的輸入。負責評估的人可以根據自己的酌處權進行評估，包括如何利用功能安全審計和確認評審的結果。

示例1如果功能安全審計的結果令人滿意，負責功能安全評估的人可以決定相關審計的結果，而不進一步判斷功能安全所需流程的執行情況。

示例2：根據特定工作成果的確認評審報告，負責評估的人可以決定對該工作成果的某些方面進行更深入的評審，或者可以檢查確認評審是否充分考慮到該工作成果與相關工作成果之間的相互作用。

注1：負責功能安全評估的人可能進行特定的確認評審，即。確認評審不一定由與評估責任人不同的人進行。

功能安全評估可以重復或更新。

示例3：由于相關項或相關項要素的變更而進行的功能安全評估更新，該更新被變更管理識別為對相關項的功能安全有影響（見ISO26262-8：2018的第8條【變更管理】）。

示例4功能安全重新評估，由功能安全評估報告觸發，該報告建議有條件接受或拒絕該相關項的功能安全。在這種情況下，迭代包括對上一次功能安全評估所產生的建議采取后續行動，包括評估所執行的糾正行動（如果適用的話）。

如果相關項的安全目標的最高ASIL是ASILA或ASILB，則可以省略或執行不那么嚴格的功能安全評估。然而，即使沒有進行功能安全評估，其他確認措施仍在執行（見ISO26262-2：2018的表1）。

在分布式開發的情況下，功能安全評估的范圍包括車輛制造商和相關項供應鏈中的供應商生成的工作成果以及實施的過程和安全措施（見ISO26262-2和ISO26262-8：2018的第5條【分布式開發的接口】）。

功能安全評估的目的是評估一個相關項在功能安全方面的成就，這只有在相關項層面是可能的。因此，供應商的功能安全評估（開發相關項要素）僅指范圍有限的評估，它本質上是對隨后的功能安全評估活動（在客戶層面）的輸入。作為相關項開發的最終客戶，車輛制造商指定人員進行全面的功能安全評估，以判斷相關項的功能安全成就。這一判斷包括提供接受、有條件接受或拒絕相關項功能安全的建議。

注2：對于一級供應商負責相關項開發的情況，包括車輛集成，該供應商接管上述角色的車輛制造商。

因此，以實際的方式，可以將分布式開發情況下的功能安全評估分為：

? 功能安全評估范圍有限，涉及供應鏈中的供應商。適用的ASIL是由供應商開發的相關項要素（也見ISO26262-8：2018的5.4.5（Functional safety assessment activities in a distributed development））的最高繼承的ASIL（相關項的安全目標）；及

? 最后的功能安全評估，包括對集成相關項實現的功能安全的判斷，例如。由車輛制造商執行。適用的ASIL是安全要求的最高ASIL（另見ISO26262-2）。

示例5：汽車制造商開發了一個帶有ASILD安全目標（SG1）和ASILB安全目標（SG2）的相關項，并將對該相關項進行功能安全評估。例如，第二層或第三層供應商可能只開發相關項的ASILB要素，即。只有繼承SG2的ASIL的要素（然而，如果要素共存的標準適用的話，請參閱【要素共存標準】（ISO26262-9：2018的第6條）。在ISO26262-2：2018中有一個建議，表1對這個要素的開發執行具有獨立性I0的功能安全評估。

范圍、程序（例如：供應商提供的工作成果、客戶評審的工作成果）和關于客戶與供應商之間接口的功能安全評估的執行在相應的開發接口協議中規定（見ISO26262-8：2018的第5條【分布式開發的接口】）。

示例6：DIA between avehicle manufacturer （customer） and a Tier1 supplier.DIA between a Tier1 supplier（customer） and a Tier2 supplier.

在分布式開發的情況下進行功能安全評估的一種可能方式是，車輛制造商和供應鏈中的供應商各自處理各自負責的評估活動的那些方面，具體如下：

供應商評審在所制定的要素中實施的安全措施，包括其適當性和有效性，以符合相應的安全目標或安全

要求（由客戶提供或由供應商開發），并評估其實施的過程和適用的工作成果。供應商還評估所開發的要素對相關項功能安全的潛在影響，例如。確定實施的安全措施是否會導致新的危險；以及

車輛制造商評估集成相關項的功能安全性。評估的一部分可以基于一個或多個供應商提供的工作成果或信息，包括功能安全評估報告。

注3：客戶可以評估供應商實施的安全措施和供應商提供的工作成果。客戶還可以評估供應商在供應商場所實施的過程（見ISO26262-8：2018的5.4.3.1）

5.3.安全檔案的理解

5.3.1安全檔案解讀

安全案件的目的是提供一個明確、全面和可辯護的論證，并有證據支持，即一個相關項在預期的環境中操作時沒有不合理的風險。

這里給出的指導重點是ISO26262的范圍。

安全檔案有三個主要要素，即：

? 安全目標和相關安全要求（相關項或要素的安全目標）；

? 安全論證；及

? ISO26262系列標準工作成果（即證據）。

這三個要素之間的關系，在ISO26262系列標準的背景下，如圖7所示。

圖7-安全檔案的關鍵要素（見參考［2］）

安全論證傳達了證據和目標之間的關系。可以提出許多頁的輔助證據，而不清楚地解釋這些證據與安全目標的關系。論證和證據都是安全案件的關鍵要素。沒有證據支持的論證是沒有根據的，因此沒有說服力。沒有論據的證據無法解釋，導致對如何滿足安全目標缺乏明確性。安全檔案通過安全檔案報告的編寫和展示進行傳達。安全檔案報告的作用是總結安全論證，然后參考捕捉支持安全證據的報告（例如：測試報告）。

到目前為止，在其他行業中使用的安全論證經常通過敘述性文本在安全檔案報告中傳達。敘述性文本可以描述安全目標是如何被解釋、分配和分解的，最終導致引用證據來證明完成了較低級別的安全聲明。或者，或者作為支持，圖形參數符號（例如聲明-參數-證據和目標結構符號［2］）可以用來直觀和明確地表示安全參數的個別要素（要求、聲明、證據和使用環境）以及這些要素之間存在的關系（即。個人需求如何得到特定聲明的支持，聲明如何得到證據的支持，以及為論證定義的假設使用環境）。

一種安全論證，通過對已實現相關項的特性的直接上訴來論證安全（例如：定時看門狗的行為）通常被稱為產品參數。通過對開發和評估過程的特點的吸引力來論證安全的安全論證（例如：所采用的設計符號）通常被稱為過程參數。

這兩種類型的參數都可以用來實現相關項安全性的合理參數，其中過程參數可以看作是對產品參數中使用的證據的信心。

5.3.2安全檔案開發生命周期

安全檔案的開發可以被視為與安全生命周期的其他開發階段集成的增量活動。

注意，安全計劃可以包括增量步驟的計劃和安全檔案的初始版本。

這種方法允許在產品開發的給定里程碑上的安全檔案的中間版本。例如，安全檔案的初始版本可以在技術安全要求驗證后創建；安全檔案的臨時版本可以在系統設計驗證后創建；最終版本可以在功能安全評估的最終報告之前創建。

安全檔案須接受【認可措施】（ISO26262-2：2018的6.4.9）中給出的確認評審。

如果相關項被修改，對安全檔案的影響將被評估，如果必要的話，考慮到修改，安全檔案將被更新。

責任編輯：haq