01

介紹

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

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

● 定義安全目標，使其推動實現(xiàn)（以支持系統(tǒng)的開發(fā)）

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

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

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

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

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

02

相關項定義

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

相關項定義應該包括：

● 法規(guī)要求，國家標準和國際標準；

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

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

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

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

●執(zhí)行器的能力，或者其假定的能力；

03

初步危害分析

準備危害分析

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

通常，從執(zhí)行器的角度而不是傳感器的角度來考慮故障模式是有幫助的，因為考慮故障模式的任務不是對現(xiàn)有設計的驗證——這將在功能安全過程的后續(xù)步驟中通過適當?shù)陌踩治觯‵MEA, FTA, …）來完成。

場景分析和危害識別

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

●被明確（可以由相關數(shù)據(jù)庫支持）；

●在危害分析中被引用；

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

我們需要描述潛在相關項發(fā)生故障時可能對整車層面產(chǎn)生的影響。例如，前面描述的故障對整車層面的影響是轉向被鎖定，車輛無法轉向?；趯φ噷用娴挠绊?，描述了危險和可能的后果。我們可以根據(jù)在整車層面上可以觀察到的條件或者事件來定義危險，并將它們描述出來。

另外，假設也應當被描述出來（例如，駕駛員為確?？煽匦远扇〉男袆樱?。這些假設加強了危害分析的范圍。推導出要求，并在隨后的步驟中通過適當?shù)姆椒炞C這些要求。為了使風險清晰明了，每一個風險最好有唯一的ID標識。

危害分類

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

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

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

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

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

（圖片來源 ISO 26262, PART3）

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

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

定義安全目標

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

以下規(guī)則有助于確保得出的安全目標支持系統(tǒng)開發(fā)：

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

●安全目標不應包含技術細節(jié)；

●安全目標應能夠通過技術手段實現(xiàn)；

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

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

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

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

●如果安全目標可以通過轉換到或者維持一個或多個安全狀態(tài)來實現(xiàn)，則應規(guī)定好相應的安全狀態(tài)。

04

功能安全概念（FSC）

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

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

（圖片來源 ISO 26262, PART3）

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

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

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

●開發(fā)功能安全要求時，可以提前把需求的各種類別/屬性定義出來（比如：信息，安全需求，操作模式，ASIL等級，安全狀態(tài)等）。類別和屬性有助于需求工程師對需求進行恰當?shù)拿枋觥?/p>

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

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

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

圖4 需求的種類及其屬性

05

安全要求規(guī)范

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

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

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

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

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

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

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

●開發(fā)的技術安全要求要匹配到相應的組件或者子系統(tǒng)上。

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

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

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

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

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

? 避免潛在失效；

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

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

●對硬件指標值的分配：

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

06

安全V&V報告

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

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

●所有安全相關要求/參數(shù)狀態(tài)的驗證和確認。

●定義、確認和設計驗證的狀態(tài)。

●確認硬件指標計算。

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

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

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

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

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

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

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

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

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

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

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

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

?供應商方面的實現(xiàn)過程是合適恰當?shù)摹?/p>

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

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

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

●組件/子系統(tǒng)供應商應完善技術安全要求：

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

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

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

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

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

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

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

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

圖6 OEM與供應商的接口