01

介紹

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

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

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

● 文檔假設(shè)（以明確清晰的相關(guān)項(xiàng)范圍）

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

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

● 支持主機(jī)廠和供應(yīng)商的接口（以避免不一致）

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

02

相關(guān)項(xiàng)定義

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

相關(guān)項(xiàng)定義應(yīng)該包括：

● 法規(guī)要求，國家標(biāo)準(zhǔn)和國際標(biāo)準(zhǔn)；

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

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

●相關(guān)項(xiàng)的約束，比如功能依賴性，與其他相關(guān)項(xiàng)的依賴 性等；

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

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

03

初步危害分析

準(zhǔn)備危害分析

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

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

場(chǎng)景分析和危害識(shí)別

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

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

●在危害分析中被引用；

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

我們需要描述潛在相關(guān)項(xiàng)發(fā)生故障時(shí)可能對(duì)整車層面產(chǎn)生的影響。例如，前面描述的故障對(duì)整車層面的影響是轉(zhuǎn)向被鎖定，車輛無法轉(zhuǎn)向。基于對(duì)整車層面的影響，描述了危險(xiǎn)和可能的后果。我們可以根據(jù)在整車層面上可以觀察到的條件或者事件來定義危險(xiǎn)，并將它們描述出來。

另外，假設(shè)也應(yīng)當(dāng)被描述出來（例如，駕駛員為確?？煽匦远扇〉男袆?dòng)）。這些假設(shè)加強(qiáng)了危害分析的范圍。推導(dǎo)出要求，并在隨后的步驟中通過適當(dāng)?shù)姆椒?yàn)證這些要求。為了使風(fēng)險(xiǎn)清晰明了，每一個(gè)風(fēng)險(xiǎn)最好有唯一的ID標(biāo)識(shí)。

危害分類

接下來，我們便可以通過以下步驟對(duì)危險(xiǎn)進(jìn)行分類（分類的目的是評(píng)估危害所需的風(fēng)險(xiǎn)降低水平）：

●Severity——潛在嚴(yán)重程度的估計(jì)（包含合理的理由）

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

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

圖1 嚴(yán)重度-暴露概率-可控性的分類

（圖片來源 ISO 26262, PART3）

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

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

定義安全目標(biāo)

功能安全目標(biāo)是基于危害分析和風(fēng)險(xiǎn)評(píng)估中定義的危害的最高水平的安全要求。

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

●安全目標(biāo)應(yīng)該清晰、準(zhǔn)確；

●安全目標(biāo)不應(yīng)包含技術(shù)細(xì)節(jié)；

●安全目標(biāo)應(yīng)能夠通過技術(shù)手段實(shí)現(xiàn)；

●安全目標(biāo)應(yīng)具有唯一的標(biāo)識(shí)ID；

●應(yīng)為每種被評(píng)定為ASIL A, B, C, D的危險(xiǎn)指定至少一個(gè)安全目標(biāo)；

●一個(gè)安全目標(biāo)可以分配給多個(gè)危險(xiǎn)；

●一個(gè)危險(xiǎn)可能有多個(gè)安全目標(biāo)；

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

04

功能安全概念（FSC）

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

圖3 安全要求的結(jié)構(gòu)和分布

（圖片來源 ISO 26262, PART3）

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

●對(duì)于每一個(gè)安全目標(biāo)，至少可以分解出一個(gè)功能安全要求。

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

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

●對(duì)于有冗余設(shè)計(jì)的需求，我們可以通過ASIL分解的方法來降低單個(gè)需求的ASIL等級(jí)。分解通常會(huì)導(dǎo)致額外的需求。

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

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

圖4 需求的種類及其屬性

05

安全要求規(guī)范

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

開發(fā)技術(shù)安全要求時(shí)，通常要考慮以下幾點(diǎn)：

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

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

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

圖5 硬件指標(biāo)值的定義（see ISO 26262, Part5）

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

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

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

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

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

? 與部件內(nèi)故障檢測(cè)相關(guān)的措施；

? 內(nèi)部故障響應(yīng)的詳細(xì)信息；

? 避免潛在失效；

? 多點(diǎn)故障檢測(cè)時(shí)間間隔；

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

●對(duì)硬件指標(biāo)值的分配：

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

06

安全V&V報(bào)告

安全驗(yàn)證和確認(rèn)報(bào)告包括詳細(xì)的驗(yàn)證和確認(rèn)計(jì)劃以及狀態(tài)的追蹤：

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

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

●定義、確認(rèn)和設(shè)計(jì)驗(yàn)證的狀態(tài)。

●確認(rèn)硬件指標(biāo)計(jì)算。

對(duì)安全目標(biāo)和功能/技術(shù)安全要求來說，可參考以下活動(dòng)：

●應(yīng)參考相應(yīng)的分析要素，并在安全V&V報(bào)告中計(jì)劃必要的驗(yàn)證和確認(rèn)活動(dòng)。

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

對(duì)于安全目標(biāo)來說，可參考以下活動(dòng)：

● 在安全目標(biāo)層面計(jì)算硬件度量指標(biāo)值（PMHF, SPFM, LFM），并對(duì)計(jì)算的結(jié)果和結(jié)論進(jìn)行評(píng)估和驗(yàn)證。

對(duì)功能安全概念來說，可參考以下活動(dòng)：

● 驗(yàn)證（比如：測(cè)試）應(yīng)該以文檔的形式記錄下來。并對(duì)其正確性和完整性進(jìn)行評(píng)估和驗(yàn)證。

● 如果為功能安全要求定義/明確了參數(shù)，那相關(guān)的參數(shù)的驗(yàn)證規(guī)范需要給出（包括驗(yàn)證活動(dòng)和通過標(biāo)準(zhǔn)），并對(duì)其正確性和完整性進(jìn)行評(píng)估和驗(yàn)證。

●按照計(jì)劃執(zhí)行規(guī)定的驗(yàn)證和確認(rèn)活動(dòng)（比如：評(píng)審，測(cè)試），并記錄相應(yīng)的V&V結(jié)果（形成文件）。測(cè)試結(jié)果應(yīng)滿足通過標(biāo)準(zhǔn)。

對(duì)技術(shù)安全要求來說，可參考以下活動(dòng)：

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

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

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

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

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

?正確的軟件和硬件設(shè)計(jì)（包括內(nèi)部和外部的接口），并與安全分析相對(duì)應(yīng)。

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

?對(duì)于內(nèi)部故障處理類的要求，要明確與檢測(cè)和指示組件內(nèi)故障有關(guān)的措施，以及內(nèi)部故障相應(yīng)的詳細(xì)信息。

?對(duì)于潛伏故障處理類的要求，要明確與部件內(nèi)故障的檢測(cè)和指示相關(guān)的措施，潛伏故障的避免，以及故障響應(yīng)的詳細(xì)信息。

?對(duì)于定義的PMHF的要求，對(duì)組件設(shè)計(jì)架構(gòu)的描述（冗余概念的描述，如有），以及處理潛在相關(guān)失效的措施的描述。

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

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

? FMEDA的計(jì)算結(jié)果是滿足相應(yīng)ASIL等級(jí)的指標(biāo)要求的。

?如果需要的話，對(duì)相應(yīng)的軟件/硬件組件進(jìn)行鑒定，并生成鑒定報(bào)告。

對(duì)于每一個(gè)V&V活動(dòng)，責(zé)任，對(duì)相應(yīng)文件的引用以及狀態(tài)都應(yīng)該在安全V&V報(bào)告中進(jìn)行追蹤。OEM和供應(yīng)商接口，以及雙方涉及到的ISO26262部分如下所示。

圖6 OEM與供應(yīng)商的接口