好幾天沒有更新，本期銜接上期，繼續(xù)闡述功能安全概念階段相關(guān)內(nèi)容。本期將按照前一篇文章的要求，設(shè)定功能安全要求，來減輕／防止SbW 電動助力轉(zhuǎn)向系統(tǒng)的危險發(fā)生。沒看到上一期文章的朋友不要擔心，文末有上期的鏈接。一起來學習吧！

01概述

本篇主要學習如何根據(jù)ISO 26262 PART3第七章節(jié)來明確我們的功能安全需求（FSR）。本章節(jié)的目標是設(shè)置一個框架，用于檢測和處理相關(guān)項的故障，從而確保相關(guān)項的安全。也就是說，我們整車在開發(fā)階段沒有表現(xiàn)出來的殘余故障是對車輛層面造成危害的根本原因。下面的Figure1展示了這些故障如何導致了車輛層面的危險。

Figure1： Propagation of faults on horizontal interfaces； from code to vehicle，horizontal interface include： HSI， components interfaces， vehicle interfaces……

ISO 26262為不同類型故障的產(chǎn)品測量制定了框架：

應對隨機硬件失效（Random HW Failure）的技術(shù)安全措施：冗余和自檢測；

應對系統(tǒng)性的系統(tǒng)、軟件和硬件（Systematic Failure）的技術(shù)安全措施：通過防御性的編程和設(shè)計決策；

然而，在功能安全概念中，我們將只在功能層面上來處理故障的減輕（即如何把危害降低到可接受的程度）。

02概念階段的驗證（Verification）

應驗證包含安全目標在內(nèi)的危害分析和風險評估，從而為以下方面提供證據(jù)：

1． 符合相關(guān)項的定義：我們的HARA分析是否全面（即包含相關(guān)項的所有功能）？是否涉及邊界和接口相關(guān)的問題？

2． 危害事件覆蓋度的完整性：我們的潛在失效模式是不是可以覆蓋所有的潛在危害事件呢？

3． 操作場景的正確選取：OEM是否認為所列出的所有場景都是合乎邏輯的，并對該場景清單進行批準？

4． 與其他相關(guān)項的相關(guān)HARA保持一致性：我們應該知道我們所要做的相關(guān)項與外部相關(guān)項的接口，從而確保我們選擇的其他相關(guān)項相互作用的危害與我們的相關(guān)項的危害是一致的。

5． 保證安全目標與分配的ASIL 等級和危害事件的一致性：為什么？因為我們的產(chǎn)品是建立在安全目標之上的，如果它沒有針對正確的危害，那么我們建立的系統(tǒng)就是錯誤的。

有時候，我們不清楚所選的操作處境和危險場景之間的影響，這時候，我們不得不要求OEM來模擬我們想要的場景，并且給我們反饋結(jié)果，然后將結(jié)果添加到驗證報告中。因此，上述的5點在HARA驗證的結(jié)果，應該記錄在一份報告中，這個報告就叫做危害分析和風險評估的驗證報告（Verification report of the HARA）。

03功能安全概念（FSC）

概念一詞是抽象的，它沒有分配給任何類型的目標或者是ECU，甚至還沒有實現(xiàn)。我們此時仍然是在功能級別上在工作。也就是說，到目前為止，還沒有物理系統(tǒng)架構(gòu)（Physical System Architecture）。為了執(zhí)行功能安全概念，讓我們來準備以下的輸入：

SbW的相關(guān)項定義；

HARA報告（此處還不是已經(jīng)驗證的版本）；

系統(tǒng)架構(gòu)設(shè)計（來自外部資源，因為我們不能收到其他任何的設(shè)計決策的偏見影響，這樣我們才容易可以發(fā)現(xiàn)設(shè)計的缺陷），參見Figure2：

Figure2： Item Definition of the SbW