01

介紹

ISO的目的是識別和分類車輛系統的潛在風險，并得出與預防或者減輕這些危害相關的安全概念和相關的安全要求。對于復雜和分布式開發系統而言，安全要求的開發通常包含以下挑戰：

● 在危害分析中找到正確的細節點（進行有效的審查）

● 定義安全目標，使其推動實現（以支持系統的開發）

● 文檔假設（以明確清晰的相關項范圍）

● 證明安全概念（以支持安全檔案）

● 不要遺漏相關的要求或者屬性（以確保完整性）

● 支持主機廠和供應商的接口（以避免不一致）

本文從ISO 26262中所要求的關鍵產出物——相關項定義、危害分析、安全目標、功能安全要求、技術安全要求等的角度提出建議，來保證安全要求開發的完整性。

02

相關項定義

相關項定義的目的是定義和描述在整車層面的相關項，并對其進行充分的理解，目標是使安全生命周期中定義的每個活動能夠充分執行。初步危害分析是根據相關項定義進行的，安全概念是根據此信息得出的。相關項定義是安全項目的“快照”，不能根據安全過程后期或發生其他技術變化時得出的安全要求進行更新。當我們對功能進行修改，增加或者刪除時，應當及時對相關項定義進行更新。

相關項定義應該包括：

● 法規要求，國家標準和國際標準；

● 整車層面的功能行為，包括運行模式或者運行狀態；

●所要求的功能的質量，性能和可用性（如果適用）；

●相關項的約束，比如功能依賴性，與其他相關項的依賴 性等；

●行為不足的潛在后果（如果有的話），包括已知的失效模式和危害；

●執行器的能力，或者其假定的能力；

03

初步危害分析

準備危害分析

初步危害分析是基于系統發生故障假設的“理想實驗”。得出的結果是可能危險的列表，包括指定的ASIL等級，反應危害事件的危險程度。為了支持識別故障的系統方法，在執行危害分析和風險評估之前，提前準備一套關于故障模式考慮的指導詞是很有幫助的。指導詞可以幫助開發者去考慮相關的失效(典型的指導詞有"NO,UNINTENDED,EARLY,LATE,MORE,LESS,INVERTED,INTERMITTENT")。對于每一個指導詞，指導詞的含義應該根據要考慮的系統的主要功能來描述。例如，對于電子轉向柱鎖功能，“UNINTENDED”是指系統在需要轉向的情況下鎖定。（注意：重要的是要確保在正確的細節級別上完成這一步驟。應避免有太詳細的級別和太多的功能/子功能，以使危害分析具有可評估性。）

通常，從執行器的角度而不是傳感器的角度來考慮故障模式是有幫助的，因為考慮故障模式的任務不是對現有設計的驗證——這將在功能安全過程的后續步驟中通過適當的安全分析（FMEA, FTA, …）來完成。

場景分析和危害識別

對于在前一步驟中確定的功能和故障的所有組合，應描述系統在出現故障時的行為。例如，對于前面描述的故障，對系統級別的影響是電子轉向柱鎖鎖定轉向柱。對于每一個故障模式，所有可能導致潛在危險的操作情況、系統/操作模式、用例和環境條件等，應該：

●被明確（可以由相關數據庫支持）；

●在危害分析中被引用；

相關的數據庫應該包括操作情況、運行模式和環境條件。如果在項目中發現了新的方面，可以及時地更新到數據庫中，以減少忘記/遺漏危險情況的風險。

我們需要描述潛在相關項發生故障時可能對整車層面產生的影響。例如，前面描述的故障對整車層面的影響是轉向被鎖定，車輛無法轉向。基于對整車層面的影響，描述了危險和可能的后果。我們可以根據在整車層面上可以觀察到的條件或者事件來定義危險，并將它們描述出來。

另外，假設也應當被描述出來（例如，駕駛員為確保可控性而采取的行動）。這些假設加強了危害分析的范圍。推導出要求，并在隨后的步驟中通過適當的方法驗證這些要求。為了使風險清晰明了，每一個風險最好有唯一的ID標識。

危害分類

接下來，我們便可以通過以下步驟對危險進行分類（分類的目的是評估危害所需的風險降低水平）：

●Severity——潛在嚴重程度的估計（包含合理的理由）

●Exposure——暴露概率的估計（包含合理的理由）

●Controllability——可控性的估計（包含合理的理由）

圖1 嚴重度-暴露概率-可控性的分類

（圖片來源 ISO 26262, PART3）

基于上面三個參數的估計，確保ASIL的確定是按照ISO 26262中的定義進行的。

圖2 ASIL等級的確定（圖片來源 ISO 26262, PART3）

定義安全目標

功能安全目標是基于危害分析和風險評估中定義的危害的最高水平的安全要求。

以下規則有助于確保得出的安全目標支持系統開發：

●安全目標應該清晰、準確；

●安全目標不應包含技術細節；

●安全目標應能夠通過技術手段實現；

●安全目標應具有唯一的標識ID；

●應為每種被評定為ASIL A, B, C, D的危險指定至少一個安全目標；

●一個安全目標可以分配給多個危險；

●一個危險可能有多個安全目標；

●如果安全目標可以通過轉換到或者維持一個或多個安全狀態來實現，則應規定好相應的安全狀態。

04

功能安全概念（FSC）

為了符合初步危害分析的安全目標，功能安全概念以功能安全要求的形式規定了基本的安全機制（Safety Mech-anism）和安全措施（safety measures）。

圖3 安全要求的結構和分布

（圖片來源 ISO 26262, PART3）

功能安全要求被分配給系統架構中的要素。當我們開發功能安全概念時，可以考慮以下幾點：

●對于每一個安全目標，至少可以分解出一個功能安全要求。

●除此之外，將初步危害分析中的假設轉化成功能安全要求，來確保在驗證和確認過程中處理這些假設。

●開發功能安全要求時，可以提前把需求的各種類別/屬性定義出來（比如：信息，安全需求，操作模式，ASIL等級，安全狀態等）。類別和屬性有助于需求工程師對需求進行恰當的描述。

●對于有冗余設計的需求，我們可以通過ASIL分解的方法來降低單個需求的ASIL等級。分解通常會導致額外的需求。

●功能安全要求被分配給初始架構里的要素。通常，我們把功能安全要求分配給邏輯塊而不是物理組件。在一個項目中，不同的方案來分配功能安全要求，其技術實現也不同。

●執行安全分析，以確保功能安全概念和初始的危害分析之間的符合性和一致性。

圖4 需求的種類及其屬性

05

安全要求規范

在安全要求規范中，功能安全要求被分解為分配給單個組件或者子系統的技術安全要求。為了明確技術安全要求，系統設計是必要的，反之亦然，技術安全要求會對系統設計產生影響。

開發技術安全要求時，通常要考慮以下幾點：

●來自系統設計，相關項定義和功能安全概念的輸入信息：外部接口，約束，技術框圖，組件和子系統的功能概述，內部接口，以及系統層級架構的描述，包含系統層面的冗余概念。這些輸入一定程度上可以確保系統設計和技術安全要求是一致的。

●由功能安全要求開發出的技術安全要求，包括FTTI，緊急操作，驗證與確認等等。技術安全要求的類別和屬性也可以參考上面的表格。

●對子系統分配好硬件指標要求（不同等級的產品有不同的要求，請參考ISO 26262第五部分）。

圖5 硬件指標值的定義（see ISO 26262, Part5）

●同樣在安全要求規范中，我們也可以進行ASIL分解，并定義安全相關的參數。

●開發的技術安全要求要匹配到相應的組件或者子系統上。

● 執行安全分析，以確保技術安全概念，功能安全概念和初始的系統架構假設之間的符合性和一致性，并驗證系統設計是否滿足技術安全要求。

ISO 26262定義的技術安全要求涵蓋了通常由OEM定義的系統級別（包括對子系統/組件的要求），但是也涵蓋了組件/子系統的內部要求。這些子系統/組件一般都是供應商開發的。

●在技術安全要求中，組件/子系統的內部方面，如：

? 與部件內故障檢測相關的措施；

? 內部故障響應的詳細信息；

? 避免潛在失效；

? 多點故障檢測時間間隔；

? 對組件架構/冗余概念的描述，包括對處理潛在相關 故障的措施的描述（主機廠通常不會給出詳細的要求，細節的設計要求通常由組件/子系統的供應商來給出）。

●對硬件指標值的分配：

?如果使用了冗余設計，并且故障檢測不限于單個組件，最好為每一個組件分配好單點故障度量（SPFM）和潛在故障度量(LFM)的目標值。不然，實現該安全目標的組件/子系統應直接繼承安全目標對應的SPFM和LFM目標值。

06

安全V&V報告

安全驗證和確認報告包括詳細的驗證和確認計劃以及狀態的追蹤：

●安全分析和規范之間的一致性（功能安全要求、技術安全要求以及詳細的軟硬件安全要求）。

●所有安全相關要求/參數狀態的驗證和確認。

●定義、確認和設計驗證的狀態。

●確認硬件指標計算。

對安全目標和功能/技術安全要求來說，可參考以下活動：

●應參考相應的分析要素，并在安全V&V報告中計劃必要的驗證和確認活動。

●所有活動應根據開發生命周期計劃來進行，并記錄相應的結果（形成文件），以證明所有安全目標都已實現，所有功能/技術安全要求都已滿足。

對于安全目標來說，可參考以下活動：

● 在安全目標層面計算硬件度量指標值（PMHF, SPFM, LFM），并對計算的結果和結論進行評估和驗證。

對功能安全概念來說，可參考以下活動：

● 驗證（比如：測試）應該以文檔的形式記錄下來。并對其正確性和完整性進行評估和驗證。

● 如果為功能安全要求定義/明確了參數，那相關的參數的驗證規范需要給出（包括驗證活動和通過標準），并對其正確性和完整性進行評估和驗證。

●按照計劃執行規定的驗證和確認活動（比如：評審，測試），并記錄相應的V&V結果（形成文件）。測試結果應滿足通過標準。

對技術安全要求來說，可參考以下活動：

● 開發相應的驗證規范，來驗證技術安全要求的正確實現（如故障注入，安全相關功能測試等），并對驗證規范的正確性和完整性進行評估和驗證。

●組件/子系統供應商應按照技術安全要求開發詳細的軟件和硬件的安全要求，并檢查以下幾方面：

?供應商方面的實現過程是合適恰當的。

?軟件和硬件的安全要求，軟硬件接口和組件的設計都是根據技術安全要求得到的，并保證其正確性和完整性。

?執行安全分析，確認相應的違反技術安全要求的故障，并確保安全分析的完整性和正確性。

?正確的軟件和硬件設計（包括內部和外部的接口），并與安全分析相對應。

●組件/子系統供應商應完善技術安全要求：

?對于內部故障處理類的要求，要明確與檢測和指示組件內故障有關的措施，以及內部故障相應的詳細信息。

?對于潛伏故障處理類的要求，要明確與部件內故障的檢測和指示相關的措施，潛伏故障的避免，以及故障響應的詳細信息。

?對于定義的PMHF的要求，對組件設計架構的描述（冗余概念的描述，如有），以及處理潛在相關失效的措施的描述。

●組件/子系統的供應商驗證組件中軟件和硬件安全要求的實現，可以檢查如下幾方面：

?根據測試規范，驗證所開發的安全機制的有效性和故障覆蓋是滿足要求的。

? FMEDA的計算結果是滿足相應ASIL等級的指標要求的。

?如果需要的話，對相應的軟件/硬件組件進行鑒定，并生成鑒定報告。

對于每一個V&V活動，責任，對相應文件的引用以及狀態都應該在安全V&V報告中進行追蹤。OEM和供應商接口，以及雙方涉及到的ISO26262部分如下所示。

圖6 OEM與供應商的接口