ISO 26262 基于V模型,汽車功能安全開發(fā)活動(dòng)始于概念階段,該階段主要包含以下內(nèi)容:
相關(guān)項(xiàng)定義(Item Definition),即定義研究對(duì)象
危害分析和風(fēng)險(xiǎn)評(píng)估(HARA),即導(dǎo)出安全目標(biāo)及ASIL等級(jí)
功能安全方案開發(fā)(FSC),即形成系統(tǒng)化概念階段工作方案輸出
在上一篇文章''02 - 汽車功能安全系列之概念階段開發(fā) - Item Definition & HARA''(我是鏈接)中,我們聊到了前兩部分內(nèi)容,定義了功能安全研究的對(duì)象,即相關(guān)項(xiàng),通過HARA過程,對(duì)相關(guān)項(xiàng)的功能進(jìn)行系統(tǒng)級(jí)別安全分析,導(dǎo)出了危害事件并量化其風(fēng)險(xiǎn)(ASIL),最終得到功能安全目標(biāo)(SG)及其ASIL等級(jí),作為整個(gè)功能安全研究最初的安全需求。
今天主要聊聊功能安全概念階段第三個(gè)部分內(nèi)容(強(qiáng)烈建議先看前面幾篇文章),具體包括:
什么是功能安全需求(FSR)
什么是功能安全方案(FSC)
怎么從安全目標(biāo)(SG)得到功能安全需求(FSR)
FSR分配至系統(tǒng)架構(gòu)
01
什么是FSR
功能安全需求(Functional Safety Requirements, FSR)是我們?cè)诟拍铍A段最常聽到的概念之一,那什么是FSR呢?
功能安全目標(biāo)(SG)屬于基于車輛或系統(tǒng)級(jí)別的安全需求,過于抽象,我們需要將其進(jìn)行細(xì)化,得到為滿足安全目標(biāo),基于組件級(jí)別的相對(duì)比較具體的,但依舊還是基于功能層面的邏輯功能需求,這個(gè)就是FSR。
大家可能好奇,為什么非要搞得這么麻煩,直接細(xì)化到技術(shù)層面,信號(hào)層面不好嗎?
是的,不好!一方面,研究分析工作需要循序漸進(jìn),一口吃不成大胖子,對(duì)于簡(jiǎn)單或者非常熟悉的研究對(duì)象,在大牛加持下可能可以直接從安全目標(biāo)導(dǎo)出技術(shù)層面的安全需求,但對(duì)于大部分系統(tǒng)或者大部分工程師而言,這個(gè)很難做到,很容易出現(xiàn)錯(cuò)誤或缺失。另外一方面,沒有中間工作產(chǎn)物,功能安全評(píng)審也過不了。
那么我們應(yīng)該從哪些方面去定義組件層面的功能安全需求或者功能安全需求應(yīng)該解決哪些問題呢?根據(jù)ISO 26262-3-2018,功能安全需求應(yīng)該針對(duì)以下幾個(gè)方面,提出相應(yīng)功能級(jí)別的解決方案,作為FSR:?
故障預(yù)防
故障探測(cè),控制故障或功能異常
過渡到安全狀態(tài)
容錯(cuò)機(jī)制
發(fā)生錯(cuò)誤時(shí)功能的降級(jí)及與駕駛員預(yù)警的相互配合
將風(fēng)險(xiǎn)暴露時(shí)間減少到可接受的持續(xù)時(shí)間所必需的駕駛員預(yù)警
駕駛員預(yù)警,以增加駕駛員對(duì)車輛的可控性
車輛級(jí)別時(shí)間相關(guān)要求,即故障容錯(cuò)時(shí)間間隔,故障處理時(shí)間間隔,和仲裁邏輯,從不同功能同時(shí)生成的多種請(qǐng)求中選擇最合適的控制請(qǐng)求。
如何理解呢?通俗的講,F(xiàn)SR無非就是基于以下兩個(gè)角度定義安全需求:?
事前預(yù)防: 從設(shè)計(jì)的角度出發(fā),為盡可能避免系統(tǒng)中軟件和硬件相關(guān)的失效,系統(tǒng)中的組件應(yīng)該實(shí)現(xiàn)或具備哪些功能。
事后補(bǔ)救: 如果系統(tǒng)還是發(fā)生了失效,及時(shí)探測(cè),顯示,控制故障。盡早給駕駛員警示故障,讓駕駛員有效干預(yù),或控制車輛系統(tǒng)進(jìn)入一個(gè)安全狀態(tài),防止或減輕傷害產(chǎn)生。
此外,針對(duì)FSR,還需要注意以下幾點(diǎn): ?
1
FSR本質(zhì)是需求,一般是甲方(主機(jī)廠)對(duì)供應(yīng)商提出的安全要求,只考慮為滿足安全目標(biāo)及ASIL等級(jí),系統(tǒng)應(yīng)該怎么正常工作,不涉及具體的技術(shù)實(shí)現(xiàn)方式。
2
針對(duì)每個(gè)SG,應(yīng)該至少導(dǎo)出一個(gè)FSR。
3
FSR應(yīng)該繼承對(duì)應(yīng)安全目標(biāo)的ASIL等級(jí)。如果存在ASIL等級(jí)分解,則需要遵循ISO 26262-9:2018中獨(dú)立性(Independence)要求。(注意獨(dú)立性和免于干擾(FFI)的區(qū)別)
4
如果FSR涉及事后補(bǔ)救措施,則該FSR需要定義相應(yīng)的安全狀態(tài),故障容錯(cuò)時(shí)間間隔(如果安全狀態(tài)需要過渡,還需定義緊急運(yùn)行時(shí)間間隔)。很多朋友搞不清楚到底這些東西屬不屬于安全需求。
5
FSR需要分配至系統(tǒng)架構(gòu),并作為FSC的組成部分,這個(gè)我們后續(xù)詳細(xì)介紹。 ?
例如,功能安全需求示例: 制動(dòng)踏板開度必須正確反映駕駛員制動(dòng)意圖(ASIL D)。至于應(yīng)該采用什么傳感器,具體怎么反應(yīng)意圖都不是功能層面考慮的問題。
02
什么是FSC
Functional Safety Concept(FSC)一般翻譯為功能安全方案或概念,個(gè)人覺得功能安全方案更合理些,F(xiàn)SC本質(zhì)上是概念階段所有開發(fā)工作進(jìn)行系統(tǒng)化匯總后形成的工作輸出產(chǎn)物。 ?
ISO 26262 對(duì)FSC定義比較模糊,即為了滿足安全目標(biāo),F(xiàn)SC包括安全措施(含安全機(jī)制)。 ?
那到底什么是安全措施(Safety measure)呢? 它和安全機(jī)制(Safety mechanism)有什么區(qū)別,這里給朋友們做個(gè)辨析:?
1
安全措施:?事前預(yù)防+事后補(bǔ)救,較為廣泛,一切用以避免或控制系統(tǒng)性失效、隨機(jī)硬件失效的技術(shù)解決方案的統(tǒng)稱。
2
安全機(jī)制: 事后補(bǔ)救部分,只是安全措施的一部分,針對(duì)系統(tǒng)功能出現(xiàn)異常后,為探測(cè),顯示,控制故障的所采取的措施。一般涉及具體技術(shù)手段,在概念階段不做具體要求,在系統(tǒng)階段進(jìn)行定義。
所以理論上講,只要是為保證相關(guān)項(xiàng)功能安全,所有在功能層面采取的解決方案都屬于功能安全方案。一般來講,一個(gè)完整的FSC應(yīng)該包含以下主要內(nèi)容: ?
其中,安全狀態(tài)主要包括:?關(guān)閉功能,功能降級(jí),安全運(yùn)行模式,Limp Home等Fail to safe策略,目前Fail to operational,如冗余運(yùn)行等策略相對(duì)較少。
系統(tǒng)一旦違反安全目標(biāo),安全機(jī)制必須在容錯(cuò)時(shí)間間隔(FTTI)將系統(tǒng)轉(zhuǎn)移到安全狀態(tài)。
這里簡(jiǎn)單說說怎么確定故障容錯(cuò)時(shí)間間隔(FTTI):?
一般可以根據(jù)安全目標(biāo)所對(duì)應(yīng)的代表性危害事件(一般是ASIL等級(jí)最高的危害事件),通過對(duì)應(yīng)運(yùn)行場(chǎng)景定量或定性評(píng)估得到,包括歷史數(shù)據(jù),仿真計(jì)算,實(shí)際測(cè)試等。
在實(shí)際操作中,如果難以計(jì)算確定,可以根據(jù)經(jīng)驗(yàn)對(duì)其進(jìn)行預(yù)設(shè),然后對(duì)代表性危害事件進(jìn)行實(shí)車運(yùn)行場(chǎng)景模擬,最后根據(jù)測(cè)試數(shù)據(jù)和安全確認(rèn)指標(biāo)(Validation criteria)確定假設(shè)合理性。
對(duì)于ASIL等級(jí)較高的安全需求,理論上都應(yīng)該進(jìn)行車輛測(cè)試確認(rèn)。
最后聊聊,F(xiàn)SR和FSC形式和書寫工具問題:?
首先,F(xiàn)SR一般都是直接包含在FSC之中,多采用需求管理或者文本工具,如Doors,Word進(jìn)行書寫和管理,方便進(jìn)行版本管理和評(píng)審。
其次,F(xiàn)SC內(nèi)容沒有統(tǒng)一的結(jié)構(gòu)要求,將所需內(nèi)容合理組織形成輸出結(jié)果且保證分析結(jié)果可追溯性即可。
03
怎么從SG得到FSR
和安全目標(biāo)(SG)導(dǎo)出,即HARA過程相比,從安全目標(biāo)(SG)到功能安全需求(FSR),也需要進(jìn)行安全分析,其區(qū)別在于:
安全分析的對(duì)象基于組件層次,非車輛或系統(tǒng)級(jí)別。
除了歸納分析法(Inductive analysis),還可采取演繹(Deductive analysis)分析方法。
其中,F(xiàn)MEA(Failure Mode and Effects Analysis, 即失效模式與影響分析)和FTA(Fault Tree Analysis, 即故障樹分析)是歸納和演繹最具代表性的分析方法,也是功能安全開發(fā)最常用的安全分析方法。 ? 接下來我們簡(jiǎn)單地聊聊它們的特點(diǎn)和區(qū)別: ?
FMEA
典型的歸納分析法: 是從多個(gè)個(gè)別的事物中獲得普遍的規(guī)則。
定性分析。
自下而上,從原因到結(jié)果,即從可能的故障原因,分析可能的危害結(jié)果。
FTA
典型的演繹分析方法: 從已知的定律經(jīng)過邏輯推演得到新的定律的方法。
定性和定量分析,概念和系統(tǒng)階段多定性分析,硬件度量分析多定量分析。
自上而下,從結(jié)構(gòu)到原因,即從危害結(jié)果或事件,分析可能導(dǎo)致其產(chǎn)生的原因。
從SG到FSR,多采用FTA分析方法進(jìn)行分析,主要原因在于:
首先,F(xiàn)MEA在設(shè)計(jì)階段一般指DFMEA,即Design FMEA。FMEA一般用于產(chǎn)品設(shè)計(jì)或工藝在真正實(shí)現(xiàn)之前,對(duì)其進(jìn)行安全分析發(fā)現(xiàn)產(chǎn)品弱點(diǎn),并優(yōu)化改進(jìn)。所以FMEA意味著事件發(fā)生之前的行為,盡可能避免危害產(chǎn)生,只包括事前預(yù)防,這一點(diǎn)和功能安全安全機(jī)制需求完全不同,事后補(bǔ)救是功能安全重要的保證安全的措施。
其次,F(xiàn)TA自上而下,從結(jié)果到原因的分析方法和從SG到FSR的導(dǎo)出方向一致,操作更為便捷,更容易完整地識(shí)別故障原因和影響。
那接下來我們一起看看FTA操作步驟: 步驟一:?確定分析邊界,包括分析對(duì)象,范圍,抽象級(jí)別。 步驟二:?選擇分析的故障,即頂部事件,通常將違反的安全目標(biāo)(SG)作為FTA頂層事件。 步驟三:?根據(jù)頂層事件,確認(rèn)直接,必要和充分導(dǎo)致故障產(chǎn)生的原因,建立故障樹,直至分析的最低抽象級(jí)別,即底層基本事件(對(duì)于FSR,一般為組件級(jí)別,如傳感器,執(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的重要組成部分。其主要目的在于: ?
將不同安全目標(biāo)對(duì)應(yīng)的安全需求及ASIL落實(shí)到架構(gòu)中具體的軟件或硬件組件當(dāng)中去,進(jìn)而確定不同組件開發(fā)對(duì)應(yīng)的所有安全需求及最高ASIL等級(jí)要求,以便于后續(xù)系統(tǒng),軟件和硬件的進(jìn)一步開發(fā)。
架構(gòu)作為需求和具體軟/硬件實(shí)現(xiàn)之間的橋梁,是基于模型的系統(tǒng)工程開發(fā)(MBSE)重要內(nèi)容,能有效改善基于文本或文檔開發(fā)的弊端,實(shí)現(xiàn)模型統(tǒng)一的管理,維護(hù),及需求和測(cè)試的可追溯性,可驗(yàn)證性。
?一般來講,系統(tǒng)架構(gòu)一般采用通用化建模語言UML或SysML在相關(guān)架構(gòu)開發(fā)軟件,如Enterprise Architect, Cameo等,進(jìn)行開發(fā),作為功能安全概念開發(fā)的輸入內(nèi)容。但可惜的是,目前大部分車企都沒有完整的系統(tǒng)架構(gòu)或多基于PowerPoint等形式的簡(jiǎn)單架構(gòu)描述。這就導(dǎo)致一方面安全分析沒有辦法依據(jù)架構(gòu)開展,另一方面,沒有辦法將安全需求分配至系統(tǒng)架構(gòu)。 ?
架構(gòu)是門藝術(shù),是當(dāng)前軟件定義汽車大背景下,解決系統(tǒng)及軟件復(fù)雜度一大利器,我后續(xù)單獨(dú)給朋友們聊聊架構(gòu)這個(gè)話題。 ?
寫在最后:
功能安全概念階段開發(fā)我們終于聊完了,下期我們繼續(xù)看功能安全系統(tǒng)階段開發(fā)。 ?
審核編輯:劉清
評(píng)論
查看更多