廣告
汽車功能安全概述及產(chǎn)品設(shè)計過程詳解
2021-09-13 11:05:49· 來源：驅(qū)動視界
隨著電動化、智能化的發(fā)展，越來越多的汽車配備了電子電氣系統(tǒng)，如電傳動系統(tǒng)、助力轉(zhuǎn)向系統(tǒng)、自動駕駛系統(tǒng)等，原有的機械部件被電子器件取代。而引入如此復(fù)雜的
隨著電動化、智能化的發(fā)展，越來越多的汽車配備了電子電氣系統(tǒng)，如電傳動系統(tǒng)、助力轉(zhuǎn)向系統(tǒng)、自動駕駛系統(tǒng)等，原有的機械部件被電子器件取代。而引入如此復(fù)雜的電子電氣系統(tǒng)對整車安全帶來了極大的風(fēng)險，簡單的一個元器件老化、失效，都有可能引發(fā)系統(tǒng)故障，進而導(dǎo)致事故發(fā)生。因此，對汽車及其相關(guān)零部件安全的要求也是越來越高。
為了達到更高程度的安全要求，在針對其他行業(yè)安全的通用IEC 61508標準的基礎(chǔ)上，衍生出針對汽車行業(yè)特定的ISO 26262功能安全標準。ISO 26262要求車載電子電氣系統(tǒng)在檢測到潛在的危險情況，啟動保護或糾正裝置，以防止發(fā)生危險事件或提供緩解措施以減少危險事件的后果。簡而言之，功能安全的最終目的是確保產(chǎn)品安全運行，即便出現(xiàn)問題也能夠最大程度減少傷害。所以，在電動化及智能化程度最高的新能源汽車行業(yè)，引入和深入實施ISO 26262功能安全標準，指導(dǎo)相關(guān)的產(chǎn)品開發(fā)，是十分必要的。
ISO 26262對關(guān)鍵的安全級別進行了四層劃分，通過汽車安全完整性等級（ASIL）來衡量。ASIL A是最低等級，要求數(shù)目約100個左右，而ASIL D是最高等級，要求數(shù)目近200個（如圖1所示）。等級越高，安全系統(tǒng)就需要提供越多的安全和驗證措施，需要增加更多的測試和集成工作，也就意味著供應(yīng)商需要承擔(dān)更多的開發(fā)成本和時間。
為了實現(xiàn)新能源汽車的整車功能安全，需要OEM和各級供應(yīng)商有著明確的職責(zé)劃分和合作模式，國外主機廠在與供應(yīng)商合作中，如博世、電裝等，都有著明確的功能安全標準和驗證要求。當(dāng)然不同的汽車部件對功能安全的要求是不同的，越核心的部件需要越高等級的功能安全。就新能源汽車車輛自身安全而言，電機控制器不得不算是最核心的部件之一，電機控制器作為新能源汽車的動力控制系統(tǒng)，掌握著整車的加速、剎車等關(guān)鍵性能，電控失效帶來的安全風(fēng)險不容忽視，所以，符合功能安全的電控設(shè)計正逐漸成為業(yè)內(nèi)的普遍需求，當(dāng)前對電控的功能安全需求多為ASIL C等級，但在未來，電控的功能安全需求或?qū)⑻嵘秊锳SIL D級，這需要供應(yīng)商具備復(fù)雜度更高、冗余性更強、可靠性指標更高的電控產(chǎn)品設(shè)計能力和水平。
下面對功能安全在整個產(chǎn)品設(shè)計過程中的應(yīng)用進行詳細介紹：
1 概念階段
概念階段主要任務(wù)是從整車層面確定功能，針對功能失效的危害事件進行風(fēng)險評估并制定安全目標（主要屬性：ASIL等級、FTTI和安全狀態(tài)）導(dǎo)出功能安全需求。本部分主要有4個活動（如圖2），接下來咱們就來講講這些活動主要實現(xiàn)什么。
注：FTTI: 從故障發(fā)生到故障處理完成的時間,FTTI時間是從整車層面定義，零部件的FTTI時間為其中一部分。
圖2：概念階段主要活動
1.1 相關(guān)項定義
在汽車功能安全領(lǐng)域，很多人都有聽說過HARA分析。但在進行HARA分析之前，需要先定義項目要實現(xiàn)的功能，以及實現(xiàn)該功能產(chǎn)品的使用環(huán)境、與其它產(chǎn)品相關(guān)的依賴性和相互影響、法規(guī)要求、系統(tǒng)和組件之間的接口和邊界條件，這就是相關(guān)項定義的主要目的。在此活動中需要畫一個與相關(guān)項相關(guān)的物理架構(gòu)圖，即為項目邊界圖，定義系統(tǒng)的邊界和與它相關(guān)聯(lián)的系統(tǒng)。值得注意的是，針對零部件廠家此處的功能是零部件在整車層面體現(xiàn)的功能。如：電機控制器的提供扭矩功能，簡稱“扭矩功能”，在HARA分析后的功能就會這樣描述“請求正向動力實際輸出反向動力”，屬于比較細化的描述。
1.2 HARA分析
危害分析和風(fēng)險評估針對相關(guān)項所定義的每一個功能分別進行HAZOP分析（功能無、功能多、功能少、功能相反、非預(yù)期、卡滯）。在定義危害事件（整車故障、路面狀況、天氣狀況、駕駛情景和用戶），最后進行風(fēng)險評估確定每一條危害事件的ASIL等級，從S（嚴重度）、E（暴露概率）、C（可控性）三個角度進行分析。
注：巧記S+E+C=7對應(yīng)ASILA；S+E+C=8對應(yīng)ASIL B；S+E+C=9對應(yīng)ASILC；S+E+C=10對應(yīng)ASIL D。
1.3 安全目標
完成HARA分析后，應(yīng)為每一條危害事件確定安全目標。安全目標是最高層面的安全需求，其重要屬性包括ID、描述、ASIL等級、FTTI、安全狀態(tài)。ASIL等級為所覆蓋的危害事件的最高等級。產(chǎn)品的最后驗證活動也就是從整車層面確定ASIL等級和安全目標，是大“V”驗證活動中最后一個活動“安全確認”。
1.4 功能安全需求
功能安全需求是由安全目標和安全狀態(tài)導(dǎo)出，可能有人會問如何導(dǎo)出？把它簡單理解成一個分解的過程就行。例如：確保把大象放進冰箱里這個“安全目標”，第一步打開冰箱門；第二步把大象裝進冰箱；第三步關(guān)上冰箱門，這三步就是根據(jù)“安全目標”導(dǎo)出的“功能安全需求”。
注意：在分解過程中，需要繼承安全目標最高ASIL等級。功能安全需求是大“V”驗證活動中，對應(yīng)整車集成和測試。
為了使導(dǎo)出的功能安全需求更具完整性，可以通過整車層面的安全分析導(dǎo)出，如：FMEA、FTA、HAZOP。目前行業(yè)內(nèi)常用FTA方法。其方法將每個安全目標的故障作為FTA的頂事件，然后將每個安全目標相關(guān)設(shè)備的物理框圖畫出來，用FTA分析相關(guān)設(shè)備失效，將FTA分析的每一個可能的底事件和未開展事件都需要定義相應(yīng)的安全需求來降低危害事件發(fā)生的可能性。例如：整車控制器與電機控制器之間通信的CAN總線錯誤可能導(dǎo)致安全目標違背，于是就提出“要求整車控制器輸出的信號需要進行時序保護和CRC校驗，以保證傳輸給電機控制器的信號正確”這樣一條功能安全需求。
2 系統(tǒng)階段
系統(tǒng)階段主要根據(jù)功能安全需求和其它非安全需求一起整合并細化成技術(shù)（安全）需求，然后進行系統(tǒng)設(shè)計，形成技術(shù)（安全）概念，并將技術(shù)（安全）需求分配給軟硬件。此階段主要有6個活動，見圖3，接下來詳細講一下各過程。
圖3：系統(tǒng)階段主要活動
2.1 技術(shù)（安全）需求
大家看到標題中的“安全”用括號是否會感到好奇呢。咱們就先從這講起，工程師們想想就知道，作為一個產(chǎn)品不可能只有安全相關(guān)的需求，肯定需要一些非安全相關(guān)的需求才能做出一個完整的產(chǎn)品。在系統(tǒng)階段的第一個任務(wù)，就是將功能安全需求和非安全需求整合并細化成技術(shù)（安全）需求。
非安全相關(guān)的需求包括：裝配工藝（如：特殊點膠位）、振動需求、性能需求等。在細化安全需求時，需要將安全機制及具體實施方案考慮進去。確定產(chǎn)品開發(fā)設(shè)計的相關(guān)方案，如上面例子第二步“把大象裝進冰箱”，在這里就要細化成是買冰箱還是自己做冰箱，以及把活的大象趕進去還是殺了后整頭或切塊裝進去。在此活動中需要注意ASIL等級的分解。此活動對應(yīng)大“V”的系統(tǒng)集成和測試。
2.2 系統(tǒng)架構(gòu)設(shè)計
大家看到這部分標準可能很容易犯迷糊，不清楚系統(tǒng)架構(gòu)是啥意思，也不知道如何下手。其實系統(tǒng)架構(gòu)設(shè)計就是將技術(shù)（安全）需求描述的功能模塊用框圖的形式表示出來，即為每一條需求的技術(shù)解決方案以框圖形式表達?？驁D的輸入、輸出接口就是功能模塊的輸入、輸出接口，然后把所有的框圖組合在一起就成了系統(tǒng)架構(gòu)圖。注意這里面包含兩個內(nèi)容，第一、技術(shù)（安全）需求的ID要與系統(tǒng)架構(gòu)的ID對應(yīng)，確保需求與架構(gòu)一致；第二、要將模塊接口描述的參數(shù)信息寫到架構(gòu)的接口參數(shù)描述當(dāng)中去。
另外系統(tǒng)架構(gòu)應(yīng)該從概念階段的初步架構(gòu)中展開設(shè)計系統(tǒng)架構(gòu)，等把整個產(chǎn)品的架構(gòu)設(shè)計好后，打開概念階段的架構(gòu)點擊深入就是系統(tǒng)階段的架構(gòu)，再點擊深入就是軟硬件層面的架構(gòu)。就像咱們看地圖一樣，先是從地球放大展開找到中國再放大找到省再放大找到市。作為一個工程師想想自己設(shè)計出這樣的架構(gòu)是不是很漂亮。
2.3 安全分析和相關(guān)性失效分析
安全分析是分析系統(tǒng)性失效的工具，目的是幫助與支持設(shè)計。在系統(tǒng)階段的安全分析需要用到兩種，分別為FMEA、FTA。FMEA和FTA都是以識別系統(tǒng)性失效的原因和系統(tǒng)性故障影響的工具，F(xiàn)TA是演繹分析法，F(xiàn)MEA是歸納分析法。演繹分析，從上往下分析導(dǎo)出安全目標違背的根本原因；歸納分析，從下往上采用故障模型（可采用HAZOP關(guān)鍵字）對可能導(dǎo)致安全目標違背的所有失效模式進行分析。兩者可以相互驗證且都是通過分析驗證架構(gòu)來滿足技術(shù)（安全）需求，一般分析安全機制的需求是否滿足功能安全需求的要求。
相關(guān)性失效分析又稱為獨立性分析簡稱DFA。DFA主要識別在不同ASIL等級的模塊間不能相互干擾，以達到不違背安全需求或安全目標。
技術(shù)（安全）需求、系統(tǒng)架構(gòu)設(shè)計、安全分析和DFA是一個迭代過程，如果安全分析的結(jié)果，發(fā)現(xiàn)技術(shù)（安全）需求細化的安全機制不夠全面，就需要去更新需求同時也要更新架構(gòu)，以達到四者一致。
2.4 軟硬件接口設(shè)計
軟硬件接口設(shè)計就是將軟件與硬件交互的內(nèi)容定義清楚，先將接口定義清楚，方便軟件工程師和硬件工程師分別設(shè)計。在后續(xù)產(chǎn)品硬件和軟件分別驗證完成后，可以進行軟硬件集成和測試。站在實際開發(fā)角度來講，也可以減少軟硬件工程師之間扯皮的事情。
3 硬件層面
硬件層面就是根據(jù)技術(shù)（安全）需求導(dǎo)出硬件(安全)需求并通過硬件設(shè)計來實現(xiàn)。在詳細設(shè)計后，分析隨機硬件故障失效和影響。在硬件層面有6個活動（見圖4）。硬件（安全）需求、硬件架構(gòu)設(shè)計、安全分析這三個活動與系統(tǒng)階段同理，這里就不再贅述。在這里主要講下硬件詳細設(shè)計和FMEDA。硬件（安全）需求對應(yīng)小“V”的硬件集成和測試。
圖4：硬件層面的主要活動
3.1 硬件詳細設(shè)計
硬件詳細設(shè)計是原理圖級別的設(shè)計，根據(jù)硬件（安全）需求和硬件架構(gòu)來設(shè)計原理圖。特別需要注意原理圖模塊電路需要跟硬件架構(gòu)的模塊對應(yīng)，模塊之間的接口也要一樣。
3.2 FMEDA
FMEDA（隨機硬件失效導(dǎo)致違背安全目標的評估）是評估硬件隨機失效的方法。針對每一個ASIL等級的開發(fā)，根據(jù)ISO 26262標準要求具有相應(yīng)的量化指標需要滿足，如ASIL B PMHF＜100FIT，SPFM≥90%，LFM≥60%。FMEDA分析就是確定是否滿足安全目標所定義的ASIL等級目標值。
輸入原理圖和BOM結(jié)合安全目標，對原理圖上的元器件逐個進行FMEDA分析，通過查找行業(yè)認可的失效率手冊（SN 29500、IEC 62380等）獲取元器件的基礎(chǔ)失效率，然后針對每一個元器件分析單點故障和殘余故障，多點故障和潛伏故障，考慮對應(yīng)安全機制的診斷覆蓋率確定安全失效總和、單點故障失效和殘余故障失效總和，計算單點故障失效率和潛伏故障失效率以及隨機硬件故障失效率衡量是否滿足量化指標。
4 軟件層面
軟件層面的軟件（安全）需求跟硬件層面一樣，都是從技術(shù)（安全）需求那里導(dǎo)出，但在細化軟件（安全）需求時應(yīng)考慮硬件約束及其對軟件的影響。軟件層面共有7個活動（見圖5）。軟件（安全）需求、軟件架構(gòu)設(shè)計、安全分析跟前面講的一樣是迭代過程，軟件（安全）需求和安全分析與系統(tǒng)階段工作內(nèi)容同理，這里就不再贅述。
圖5：軟件層面的主要活動
4.1 軟件架構(gòu)設(shè)計
軟件架構(gòu)跟硬件架構(gòu)一樣，先要實現(xiàn)軟件（安全）需求，還需要描述各軟件模塊及其在層次結(jié)構(gòu)中的交互。交互包括兩方面，靜態(tài)和動態(tài)。靜態(tài)：需要把每個模塊與模塊之間的接口和數(shù)據(jù)路徑描述清楚；動態(tài)：需要將模塊與模塊之間的時序和定時描述清楚。此活動對應(yīng)小“V”的軟件集成和測試。
4.2 軟件單元設(shè)計與實現(xiàn)
軟件單元設(shè)計與實現(xiàn)主要是根據(jù)軟件架構(gòu)和軟件（安全）需求詳細定義軟件單元并按照定義實現(xiàn)軟件單元代碼，并且在單元測試之前需要先進行靜態(tài)測試。特別需要注意軟件代碼模塊與軟件架構(gòu)的模塊對應(yīng)，模塊之間的接口、靜態(tài)接口描述的一樣。此活動對應(yīng)小“V”的軟件單元測試。
5 3“V”
ISO 26262基于“V”模型開發(fā)產(chǎn)品驗證，可能很多工程師不清楚活動對應(yīng)關(guān)系?，F(xiàn)在我把3個“V”對應(yīng)的活動用圖示方式畫出來，圖6是大“V”對應(yīng)的活動，圖7是硬件“V”對應(yīng)的活動，圖8是軟件“V”對應(yīng)的活動。
圖6：大“V”對應(yīng)的活動
圖7：硬件“V”對應(yīng)的活動
注：硬件階段的驗證也可以參考軟件V模型，將測試分成三個部分。針對硬件詳細設(shè)計驗證的硬件模塊測試；針對硬件架構(gòu)設(shè)計驗證的硬件集成和測試；以及針對硬件需求驗證的硬件測試，分別定義測試用例進行測試，使驗證和設(shè)計的追溯更清晰，只是因為硬件需要將所有電路模塊整合在一片板上才方便工作，所以看起來只有一個測試活動。
圖8：軟件“V”對應(yīng)的活動
6 3大追溯關(guān)系
6.1 需求之間的追溯關(guān)系
各個部分的需求從上到下是可以相互追溯的，需求追溯也是審核時的重點關(guān)注內(nèi)容（詳見圖9）。
圖9：需求與需求之間的關(guān)系
6.2 需求與架構(gòu)的追溯關(guān)系
系統(tǒng)需求對應(yīng)系統(tǒng)架構(gòu)、硬件需求對應(yīng)硬件架構(gòu)、軟件需求對應(yīng)軟件架構(gòu)，每個階段的需求和架構(gòu)都是可以相互追溯。架構(gòu)是需求的實現(xiàn)以及進一步詳細設(shè)計的依據(jù)。
6.3 設(shè)計和驗證的追溯關(guān)系
如圖6、圖7、圖8中的3V模型可以知道V模型的左邊的設(shè)計和右邊的驗證，這也就是設(shè)計驗證的追溯關(guān)系。例如：技術(shù)安全概念對應(yīng)系統(tǒng)集成和測試、功能安全概念對應(yīng)整車集成和測試。
廣告 編輯推薦
最新資訊
-
開年豪擲1.8億搶用戶，又一車企加入“價格
2026-03-04 16:05
-
聯(lián)合國法規(guī)R60對兩輪車操縱件與指示裝置的
2026-03-04 12:08
-
標準立項|《汽車異種材料鉚接接頭拉伸性能
2026-03-04 11:40
-
“汽車大角度座椅 第1部分：通用要求”將有
2026-03-04 11:39
-
“汽車大角度座椅 第2部分：可靠性要求”將
2026-03-04 11:39
