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

01概述

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

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

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

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

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

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

02概念階段的驗證（Verification）

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

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

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

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

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

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

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

03功能安全概念（FSC）

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

SbW的相關項定義；

HARA報告（此處還不是已經驗證的版本）；

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

Figure2： Item Definition of the SbW