本篇屬于汽車功能安全專題系列第03篇內(nèi)容，我們接著聊功能安全概念開發(fā)階段剩余內(nèi)容。

ISO 26262 基于V模型，汽車功能安全開發(fā)活動始于概念階段，該階段主要包含以下內(nèi)容:

相關(guān)項定義(Item Definition)，即定義研究對象

危害分析和風險評估(HARA)，即導(dǎo)出安全目標及ASIL等級

功能安全方案開發(fā)(FSC)，即形成系統(tǒng)化概念階段工作方案輸出

在上一篇文章''02 - 汽車功能安全系列之概念階段開發(fā) - Item Definition & HARA''(我是鏈接)中，我們聊到了前兩部分內(nèi)容，定義了功能安全研究的對象，即相關(guān)項，通過HARA過程，對相關(guān)項的功能進行系統(tǒng)級別安全分析，導(dǎo)出了危害事件并量化其風險(ASIL)，最終得到功能安全目標(SG)及其ASIL等級，作為整個功能安全研究最初的安全需求。

今天主要聊聊功能安全概念階段第三個部分內(nèi)容(強烈建議先看前面幾篇文章)，具體包括:

什么是功能安全需求(FSR)

什么是功能安全方案(FSC)

怎么從安全目標(SG)得到功能安全需求(FSR)

FSR分配至系統(tǒng)架構(gòu)

01

什么是FSR

功能安全需求(Functional Safety Requirements, FSR)是我們在概念階段最常聽到的概念之一，那什么是FSR呢？

功能安全目標(SG)屬于基于車輛或系統(tǒng)級別的安全需求，過于抽象，我們需要將其進行細化，得到為滿足安全目標，基于組件級別的相對比較具體的，但依舊還是基于功能層面的邏輯功能需求，這個就是FSR。

大家可能好奇，為什么非要搞得這么麻煩，直接細化到技術(shù)層面，信號層面不好嗎?

是的，不好！一方面，研究分析工作需要循序漸進，一口吃不成大胖子，對于簡單或者非常熟悉的研究對象，在大牛加持下可能可以直接從安全目標導(dǎo)出技術(shù)層面的安全需求，但對于大部分系統(tǒng)或者大部分工程師而言，這個很難做到，很容易出現(xiàn)錯誤或缺失。另外一方面，沒有中間工作產(chǎn)物，功能安全評審也過不了。

那么我們應(yīng)該從哪些方面去定義組件層面的功能安全需求或者功能安全需求應(yīng)該解決哪些問題呢？根據(jù)ISO 26262-3-2018，功能安全需求應(yīng)該針對以下幾個方面，提出相應(yīng)功能級別的解決方案，作為FSR:

故障預(yù)防

故障探測，控制故障或功能異常

過渡到安全狀態(tài)

容錯機制

發(fā)生錯誤時功能的降級及與駕駛員預(yù)警的相互配合

將風險暴露時間減少到可接受的持續(xù)時間所必需的駕駛員預(yù)警

駕駛員預(yù)警，以增加駕駛員對車輛的可控性

車輛級別時間相關(guān)要求，即故障容錯時間間隔，故障處理時間間隔，和

仲裁邏輯，從不同功能同時生成的多種請求中選擇最合適的控制請求。

如何理解呢？通俗的講，F(xiàn)SR無非就是基于以下兩個角度定義安全需求:

事前預(yù)防: 從設(shè)計的角度出發(fā)，為盡可能避免系統(tǒng)中軟件和硬件相關(guān)的失效，系統(tǒng)中的組件應(yīng)該實現(xiàn)或具備哪些功能。

事后補救: 如果系統(tǒng)還是發(fā)生了失效，及時探測，顯示，控制故障。盡早給駕駛員警示故障，讓駕駛員有效干預(yù)，或控制車輛系統(tǒng)進入一個安全狀態(tài)，防止或減輕傷害產(chǎn)生。

此外，針對FSR，還需要注意以下幾點:

1

FSR本質(zhì)是需求，一般是甲方(主機廠)對供應(yīng)商提出的安全要求，只考慮為滿足安全目標及ASIL等級，系統(tǒng)應(yīng)該怎么正常工作，不涉及具體的技術(shù)實現(xiàn)方式。

2

針對每個SG，應(yīng)該至少導(dǎo)出一個FSR。

3

FSR應(yīng)該繼承對應(yīng)安全目標的ASIL等級。如果存在ASIL等級分解，則需要遵循ISO 26262-9:2018中獨立性(Independence)要求。(注意獨立性和免于干擾(FFI)的區(qū)別)

4

如果FSR涉及事后補救措施，則該FSR需要定義相應(yīng)的安全狀態(tài)，故障容錯時間間隔(如果安全狀態(tài)需要過渡，還需定義緊急運行時間間隔)。很多朋友搞不清楚到底這些東西屬不屬于安全需求。

5

FSR需要分配至系統(tǒng)架構(gòu)，并作為FSC的組成部分，這個我們后續(xù)詳細介紹。

例如，功能安全需求示例: 制動踏板開度必須正確反映駕駛員制動意圖(ASIL D)。至于應(yīng)該采用什么傳感器，具體怎么反應(yīng)意圖都不是功能層面考慮的問題。

02

什么是FSC

Functional Safety Concept(FSC)一般翻譯為功能安全方案或概念，個人覺得功能安全方案更合理些，F(xiàn)SC本質(zhì)上是概念階段所有開發(fā)工作進行系統(tǒng)化匯總后形成的工作輸出產(chǎn)物。 ISO 26262 對FSC定義比較模糊，即為了滿足安全目標，F(xiàn)SC包括安全措施(含安全機制)。 那到底什么是安全措施(Safety measure)呢? 它和安全機制(Safety mechanism)有什么區(qū)別，這里給朋友們做個辨析:

1

安全措施:事前預(yù)防+事后補救，較為廣泛，一切用以避免或控制系統(tǒng)性失效、隨機硬件失效的技術(shù)解決方案的統(tǒng)稱。

2

安全機制: 事后補救部分，只是安全措施的一部分，針對系統(tǒng)功能出現(xiàn)異常后，為探測，顯示，控制故障的所采取的措施。一般涉及具體技術(shù)手段，在概念階段不做具體要求，在系統(tǒng)階段進行定義。

所以理論上講，只要是為保證相關(guān)項功能安全，所有在功能層面采取的解決方案都屬于功能安全方案。一般來講，一個完整的FSC應(yīng)該包含以下主要內(nèi)容:

其中，安全狀態(tài)主要包括:關(guān)閉功能，功能降級，安全運行模式，Limp Home等Fail to safe策略，目前Fail to operational，如冗余運行等策略相對較少。

系統(tǒng)一旦違反安全目標，安全機制必須在容錯時間間隔(FTTI)將系統(tǒng)轉(zhuǎn)移到安全狀態(tài)。

這里簡單說說怎么確定故障容錯時間間隔(FTTI):

一般可以根據(jù)安全目標所對應(yīng)的代表性危害事件(一般是ASIL等級最高的危害事件)，通過對應(yīng)運行場景定量或定性評估得到，包括歷史數(shù)據(jù)，仿真計算，實際測試等。

在實際操作中，如果難以計算確定，可以根據(jù)經(jīng)驗對其進行預(yù)設(shè)，然后對代表性危害事件進行實車運行場景模擬，最后根據(jù)測試數(shù)據(jù)和安全確認指標(Validation criteria)確定假設(shè)合理性。

對于ASIL等級較高的安全需求，理論上都應(yīng)該進行車輛測試確認。

最后聊聊，F(xiàn)SR和FSC形式和書寫工具問題:

首先，F(xiàn)SR一般都是直接包含在FSC之中，多采用需求管理或者文本工具，如Doors，Word進行書寫和管理，方便進行版本管理和評審。

其次，F(xiàn)SC內(nèi)容沒有統(tǒng)一的結(jié)構(gòu)要求，將所需內(nèi)容合理組織形成輸出結(jié)果且保證分析結(jié)果可追溯性即可。

03

怎么從SG得到FSR

和安全目標(SG)導(dǎo)出，即HARA過程相比，從安全目標(SG)到功能安全需求(FSR)，也需要進行安全分析，其區(qū)別在于:

安全分析的對象基于組件層次，非車輛或系統(tǒng)級別。

除了歸納分析法(Inductive analysis)，還可采取演繹(Deductive analysis)分析方法。

其中，F(xiàn)MEA(Failure Mode and Effects Analysis, 即失效模式與影響分析)和FTA(Fault Tree Analysis, 即故障樹分析)是歸納和演繹最具代表性的分析方法，也是功能安全開發(fā)最常用的安全分析方法。 接下來我們簡單地聊聊它們的特點和區(qū)別:

FMEA

典型的歸納分析法: 是從多個個別的事物中獲得普遍的規(guī)則。

定性分析。

自下而上，從原因到結(jié)果，即從可能的故障原因，分析可能的危害結(jié)果。

FTA

典型的演繹分析方法: 從已知的定律經(jīng)過邏輯推演得到新的定律的方法。

定性和定量分析，概念和系統(tǒng)階段多定性分析，硬件度量分析多定量分析。

自上而下，從結(jié)構(gòu)到原因，即從危害結(jié)果或事件，分析可能導(dǎo)致其產(chǎn)生的原因。

從SG到FSR，多采用FTA分析方法進行分析，主要原因在于:

首先，F(xiàn)MEA在設(shè)計階段一般指DFMEA，即Design FMEA。FMEA一般用于產(chǎn)品設(shè)計或工藝在真正實現(xiàn)之前，對其進行安全分析發(fā)現(xiàn)產(chǎn)品弱點，并優(yōu)化改進。所以FMEA意味著事件發(fā)生之前的行為，盡可能避免危害產(chǎn)生，只包括事前預(yù)防，這一點和功能安全安全機制需求完全不同，事后補救是功能安全重要的保證安全的措施。

其次，F(xiàn)TA自上而下，從結(jié)果到原因的分析方法和從SG到FSR的導(dǎo)出方向一致，操作更為便捷，更容易完整地識別故障原因和影響。

那接下來我們一起看看FTA操作步驟: 步驟一:確定分析邊界，包括分析對象，范圍，抽象級別。 步驟二:選擇分析的故障，即頂部事件，通常將違反的安全目標(SG)作為FTA頂層事件。 步驟三:根據(jù)頂層事件，確認直接，必要和充分導(dǎo)致故障產(chǎn)生的原因，建立故障樹，直至分析的最低抽象級別，即底層基本事件(對于FSR，一般為組件級別，如傳感器，執(zhí)行器，控制單元等)。 步驟四:根據(jù)底層基本事件，采取安全措施以消除相關(guān)故障路徑，制定相應(yīng)的FSR。

(感興趣的朋友可以私信我，我再考慮后續(xù)是否有必要出一篇安全分析文章)

04

FSR分配至系統(tǒng)架構(gòu)

根據(jù)ISO 26262-3-2018要求，F(xiàn)SR必須分配至系統(tǒng)架構(gòu)，作為FSC的重要組成部分。其主要目的在于:

將不同安全目標對應(yīng)的安全需求及ASIL落實到架構(gòu)中具體的軟件或硬件組件當中去，進而確定不同組件開發(fā)對應(yīng)的所有安全需求及最高ASIL等級要求，以便于后續(xù)系統(tǒng)，軟件和硬件的進一步開發(fā)。

架構(gòu)作為需求和具體軟/硬件實現(xiàn)之間的橋梁，是基于模型的系統(tǒng)工程開發(fā)(MBSE)重要內(nèi)容，能有效改善基于文本或文檔開發(fā)的弊端，實現(xiàn)模型統(tǒng)一的管理，維護，及需求和測試的可追溯性，可驗證性。

一般來講，系統(tǒng)架構(gòu)一般采用通用化建模語言UML或SysML在相關(guān)架構(gòu)開發(fā)軟件，如Enterprise Architect， Cameo等，進行開發(fā)，作為功能安全概念開發(fā)的輸入內(nèi)容。但可惜的是，目前大部分車企都沒有完整的系統(tǒng)架構(gòu)或多基于PowerPoint等形式的簡單架構(gòu)描述。這就導(dǎo)致一方面安全分析沒有辦法依據(jù)架構(gòu)開展，另一方面，沒有辦法將安全需求分配至系統(tǒng)架構(gòu)。 架構(gòu)是門藝術(shù)，是當前軟件定義汽車大背景下，解決系統(tǒng)及軟件復(fù)雜度一大利器，我后續(xù)單獨給朋友們聊聊架構(gòu)這個話題。

審核編輯 ：李倩