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

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

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

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

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

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

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

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

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

FSR分配至系統架構

01

什么是FSR

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

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

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

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

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

故障預防

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

過渡到安全狀態

容錯機制

發生錯誤時功能的降級及與駕駛員預警的相互配合

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

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

車輛級別時間相關要求，即故障容錯時間間隔，故障處理時間間隔，和仲裁邏輯，從不同功能同時生成的多種請求中選擇最合適的控制請求。

如何理解呢？通俗的講，FSR無非就是基于以下兩個角度定義安全需求: 

事前預防: 從設計的角度出發，為盡可能避免系統中軟件和硬件相關的失效，系統中的組件應該實現或具備哪些功能。

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

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

1

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

2

針對每個SG，應該至少導出一個FSR。

3

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

4

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

5

FSR需要分配至系統架構，并作為FSC的組成部分，這個我們后續詳細介紹。  

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

02

什么是FSC

Functional Safety Concept(FSC)一般翻譯為功能安全方案或概念，個人覺得功能安全方案更合理些，FSC本質上是概念階段所有開發工作進行系統化匯總后形成的工作輸出產物。  

ISO 26262 對FSC定義比較模糊，即為了滿足安全目標，FSC包括安全措施(含安全機制)。  

那到底什么是安全措施(Safety measure)呢? 它和安全機制(Safety mechanism)有什么區別，這里給朋友們做個辨析: 

1

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

2

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

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

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

系統一旦違反安全目標，安全機制必須在容錯時間間隔(FTTI)將系統轉移到安全狀態。

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

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

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

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

最后聊聊，FSR和FSC形式和書寫工具問題: 

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

其次，FSC內容沒有統一的結構要求，將所需內容合理組織形成輸出結果且保證分析結果可追溯性即可。

03

怎么從SG得到FSR

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

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

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

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

FMEA

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

定性分析。

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

FTA

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

定性和定量分析，概念和系統階段多定性分析，硬件度量分析多定量分析。

自上而下，從結構到原因，即從危害結果或事件，分析可能導致其產生的原因。

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

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

其次，FTA自上而下，從結果到原因的分析方法和從SG到FSR的導出方向一致，操作更為便捷，更容易完整地識別故障原因和影響。

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

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

04

FSR分配至系統架構

根據ISO 26262-3-2018要求，FSR必須分配至系統架構，作為FSC的重要組成部分。其主要目的在于:  

將不同安全目標對應的安全需求及ASIL落實到架構中具體的軟件或硬件組件當中去，進而確定不同組件開發對應的所有安全需求及最高ASIL等級要求，以便于后續系統，軟件和硬件的進一步開發。

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

 一般來講，系統架構一般采用通用化建模語言UML或SysML在相關架構開發軟件，如Enterprise Architect， Cameo等，進行開發，作為功能安全概念開發的輸入內容。但可惜的是，目前大部分車企都沒有完整的系統架構或多基于PowerPoint等形式的簡單架構描述。這就導致一方面安全分析沒有辦法依據架構開展，另一方面，沒有辦法將安全需求分配至系統架構。  

架構是門藝術，是當前軟件定義汽車大背景下，解決系統及軟件復雜度一大利器，我后續單獨給朋友們聊聊架構這個話題。