引言

　　一篇文章帶你認識功能安全

　　隨著各行各業(yè)在產(chǎn)品開發(fā)設計和測試過程中都采用了一套標準化的實踐，安全實踐也變得越來越規(guī)范。汽車行業(yè)也不例外，功能安全標準 ISO-26262 滿足了針對安全關鍵零部件的汽車專用國際標準的需求。ISO-26262是電氣和電子（E/E）系統(tǒng)的通用功能安全標準。本文將結(jié)合ISO-26262，從什么是功能安全、什么是功能安全工程師以及功能安全工程師主要做什么，三個方面展開對功能安全的介紹。

　　01

　　什么是功能安全

　　1

　　背景簡介

　　由于汽車的復雜性，整個行業(yè)正在致力于提供符合安全要求的零部件系統(tǒng)。比如，線控油門系統(tǒng)，當駕駛員踩下油門踏板，踏板上的傳感器向控制器發(fā)送信號時，控制器會綜合分析如發(fā)動機轉(zhuǎn)速、車輛速度、踏板位置等信號，然后將控制指令發(fā)送給油門本體。測試和驗證線控油門系統(tǒng)等是汽車行業(yè)面臨的一個挑戰(zhàn)。ISO 26262的目標就是為所有汽車E/E系統(tǒng)提供一個統(tǒng)一的安全標準。

　　脫胎于IEC-61508的功能安全ISO-26262的國際標準草案于2009年6月發(fā)布。從草案發(fā)布開始，ISO-26262已經(jīng)在汽車行業(yè)獲得了廣泛的關注。工程師將ISO-26262視為最先進的技術(shù)狀態(tài)（state-of-the-art）。該技術(shù)的技術(shù)狀態(tài)在特定時間是開發(fā)設備或流程的最高水準。汽車制造商一般要對因產(chǎn)品故障而造成的損害負責。ISO-26262在汽車行業(yè)是一個通用標準，它提供了一種衡量系統(tǒng)安全性的方法。

　　圖1: 安全相關系統(tǒng)

　　ISO-26262使用V-Model來管理功能安全，并在系統(tǒng)、軟件和硬件級別上規(guī)范產(chǎn)品的開發(fā)。ISO-26262標準提供了整個產(chǎn)品開發(fā)過程中的法規(guī)和建議——從概念階段到產(chǎn)品報廢階段。它詳細說明了如何為系統(tǒng)和組件分配一個可接受的風險級別，并對整個測試過程進行記錄。一般來說，ISO 26262：

　　提供了汽車整個安全生命周期 （管理，開發(fā)，生產(chǎn)，運營，服務，退役），并支持在這些生命周期階段中定制必要的活動；

　　提供了一種基于汽車特定風險的方法來確定風險類別（ASIL）；

　　使用ASIL來指定項目的必要安全要求，以實現(xiàn)可接受的殘余風險；

　　提供了驗證和確認措施的要求，以確保達到足夠和可接受的安全水平；

　　2

　　評估風險——危害分析和風險評估（HARA）

　　當我們對新開發(fā)的車型有了清晰的定義后，也就打響了汽車功能安全的第一槍。我們需要用HARA來識別和評估潛在的危險。一般來講， OEM的功能安全工程師會對車輛級的功能進行HARA分析，以識別潛在的危險場景，并確定每個潛在危險所需的風險降低水平。HARA考慮了在特定駕駛場景中暴露于潛在危險情況的頻率和持續(xù)時間（Exposure），糾正故障行為以減輕潛在危險所需的控制量（Controllability），以及在故障行為發(fā)生時潛在后果的嚴重程度（Severity）。

　　HARA是在車輛層面的特性上進行的，而不是在零部件或者要素層面。對于每一個潛在的危險，都考慮了一些潛在的駕駛方案。比如：在前向碰撞緩解系統(tǒng)中，將根據(jù)不同的駕駛場景，如操作速度和駕駛條件，評估非預期制動的潛在危險。

　　3

　　分配安全等級——功能安全完整性等級（ASIL）

　　在HARA過程中，OEM為每個已識別的潛在風險分配了一個ASIL （Automotive Safety Integrity Level）等級。ASIL在開發(fā)過程中就已經(jīng)確定了。根據(jù)可能存在的風險。

　　圖2：功能安全等級評定

　　比如：如果某輛車的邁速表出了故障，從車子啟動開始就不顯示任何信息，場景可以歸類為QM，因為司機可以很容易地感知故障，并且選擇不開車或者非常謹慎的駕駛。換言之，場景的可控性非常高，而嚴重程度則很低。相比之下，如果車輛無法進行控制，駕駛員在高速行駛時剎車失靈的情況可以歸類于ASIL-D，因為這時導致人嚴重受傷的概率很高。

　　為了適當?shù)亟鉀Q這些情況，ISO 26262使用ASIL評級來確定供應商必須采取的開發(fā)步驟的嚴格性，并定義了安全目標（safety goal）的要求：

　　1. FIT率（Failure In Time）： FIT率是車輛在給定時間段內(nèi)可接受的故障率。車輛必須滿足ASIL評級所規(guī)定的FIT率，但OEM也可以靈活地為系統(tǒng)內(nèi)的基礎組件選擇FIT率。

　　2. 安全概念（Safety Concept）：安全概念決定如何檢測顧故障及如何控制故障，具有更高ASIL評級的系統(tǒng)需要更嚴格的故障檢測和響應能力。

　　3. 安全要求（Safety Requirements）：安全要求規(guī)定了對任何給定故障的適當響應。比如，傳感器檢測到與內(nèi)部安全相關的問題，如內(nèi)存損壞，故障響應系統(tǒng)可能會在規(guī)定的時間內(nèi)終止通過控制器的通信，以便向其他系統(tǒng)指示其故障狀態(tài)。這是安全要求所描述的典型的安全機制——但故障響應系統(tǒng)并不總是恰當合適的。如：對于智駕功能，車輛可能采用故障操作系統(tǒng)，這要求冗余系統(tǒng)接管必要的時間，以使車輛處于最小的風險狀態(tài)（比如，安全停車在路邊）。對于系統(tǒng)故障，遵循嚴格的開發(fā)過程有助于增加該功能將以一種安全的方式運行的信心。

　　4

　　持續(xù)的測試和集成

　　汽車功能安全在整個開發(fā)過程中都采用了V模型。V模型要求，對于開發(fā)的每一步驟，在測試中都必須對應有一個相應的步驟。供應商定期評估其開發(fā)過程，以確保硬件和軟件開發(fā)都遵循了所需要的步驟。

　　圖3：V字開發(fā)模型

　　OEM，供應商或者獨立的第三方公司對所有相關的工作產(chǎn)出物進行功能安全審核和評估，以確保功能安全的實現(xiàn)。功能安全需求一個全面的管理過程，以確保適當?shù)谋O(jiān)督和完整的系統(tǒng)集成。

　　02

　　什么是功能安全工程師，

　　功能安全工程師做什么？

　　關于什么是功能安全工程師？這個問題乍一看很好回答，但如果仔細思考下就會發(fā)現(xiàn)，想找到真實統(tǒng)一的答案卻并不容易。比如擁有完善開發(fā)體系流程的大公司和初創(chuàng)的小公司，他們對功能安全工程師的定義大概率是不同的。思來想去，還是決定以一個新項目為例，來說明下什么是功能安全工程師以及在產(chǎn)品開發(fā)過程中功能安全工程師做什么。

　　1

　　報價階段

　　1. 安全要求的分析與澄清：

　　功能安全工程師要對客戶的安全輸入進行分析，以確認公司內(nèi)部產(chǎn)品的安全要求是否與客戶匹配。通常會以會議的形式跟客戶討論和澄清相關安全要求。

　　2. 執(zhí)行影響分析：

　　分析完客戶的安全要求之后，一般功能安全工程師還會做影響分析，以確定公司內(nèi)部的平臺項目或者已經(jīng)量產(chǎn)的其他客戶項目是否有可以直接復用的功能，或者修改之后可以復用的功能。如果是全新的產(chǎn)品開發(fā)，則客戶忽略影響分析。

　　3. 開發(fā)接口協(xié)議（DIA）責任劃分：

　　弄清楚產(chǎn)品的開發(fā)邊界之后，功能安全工程師要跟客戶去確定每一方的開發(fā)責任范圍，并明確開發(fā)過程中的產(chǎn)出物的責任方以及雙方如何進行產(chǎn)出物的交互，雙方對以上內(nèi)容都打成一致后，DIA也就完成了。最后別忘了雙方都需要在DIA上簽字。

　　4. 準備項目功能安全計劃和安全檔案：

　　在報價階段，功能安全工程師要根據(jù)項目的時間計劃以及客戶的安全輸入來準備初版的項目功能安全計劃（主要內(nèi)容是計劃管理和指導整個項目開發(fā)過程中的安全活動的執(zhí)行，包含日期、關鍵節(jié)點、任務、可交付的成果、職責和資源等）以及安全檔案（主要內(nèi)容是與客戶闡明所開發(fā)的產(chǎn)品已經(jīng)按照ISO 26262的要求進行開發(fā)并實現(xiàn)了功能安全所準備的證據(jù)，包含產(chǎn)品開發(fā)各個階段的關鍵產(chǎn)出物的記錄，產(chǎn)出物的評審記錄等）。

　　5. 準備評審會議：

　　以上內(nèi)容都完成之后，功能安全工程師就可以跟審核員（Assessor）約評審會議了。在會上，審核員會根據(jù)功能安全工程師準備的證據(jù)對該項目的產(chǎn)品開發(fā)成熟度進行評估以確認是否滿足當前的開發(fā)需要，以及是否有安全相關的風險，并輸出當前階段的評估報告。【注】：由于每家公司的開發(fā)流程不同，所以對功能安全評估次數(shù)要求也不同，但基本都會在項目的關鍵節(jié)點進行功能安全評估。

　　6. 相關項定義以及危害分析：

　　如果站在主機廠角度，功能安全工程師要完成所開發(fā)產(chǎn)品的相關頂定義（主要內(nèi)容是在整車層面對相關項進行定義和描述，包括功能，及其與駕駛員、環(huán)境和其他相關項之間的依賴性和相互之間的影響），并對其進行危害分析和風險評估（主要是識別并分類由相關項中的功能異常表現(xiàn)引起的危害事件，以及定制防止危害事件發(fā)聲或者減輕危害程度的安全目標及其安全等級，來避免不合理的風險），以便得出產(chǎn)品的頂層功能安全目標，以及功能安全概念，并打包發(fā)給供應商。

　　2

　　概念設計階段

　　功能安全概念/要求開發(fā)：功能安全工程師要完成功能安全概念/要求（FSC/FSRs）的開發(fā)。功能安全概念的主要目的如下：

　　1） 要根據(jù)功能安全目標定義產(chǎn)品的功能性或者降級的功能性行為；

　　2） 要根據(jù)功能安全目標定義關于合理地、及時地檢測和控制相關故障的約束條件；

　　3） 要定義產(chǎn)品層面的策略或者是措施，以通過產(chǎn)品本身、司機或者外部的措施來實現(xiàn)故障容錯或者減小對相關故障的影響；

　　4） 把功能安全要求分配給系統(tǒng)架構(gòu)設計；

　　5） 確認功能安全概念并且定義號安全確認的準則；

　　圖4：功能安全目標和安全要求層級

　　3

　　開發(fā)設計階段

　　系統(tǒng)開發(fā)設計

　　1. 技術(shù)安全概念/要求開發(fā)：

　　功能安全工程師要完成（或者協(xié)助系統(tǒng)需求工程師完成）TSC/TSRs的開發(fā)。技術(shù)安全概念的主要目的如下：

　　a. 制定系統(tǒng)要素和接口關于功能、相關性、約束和屬性方面實施中所需的技術(shù)安全要求；

　　b. 制定系統(tǒng)要素和接口實施安全機制的技術(shù)安全要求；

　　c. 制定在生產(chǎn)、運行、服務和報廢中系統(tǒng)及其要素功能安全的相關要求；

　　d. 驗證技術(shù)安全要求在系統(tǒng)層級是否符合功能安全要求并與功能安全要求一致；

　　e. 制定滿足安全要求且不與非安全相關要求沖突的系統(tǒng)架構(gòu)設計和技術(shù)安全概念；

　　f. 分析系統(tǒng)架構(gòu)設計，防止故障并為生產(chǎn)和服務得出必要的安全相關特殊特性；

　　g. 按照各自的ASIL等級，驗證系統(tǒng)架構(gòu)設計和技術(shù)安全概念是否適用于滿足安全要求；

　　圖5：系統(tǒng)層面的產(chǎn)品開發(fā)

　　2. 安全機制的裁剪：

　　一般在產(chǎn)品設計初期，開發(fā)人員已經(jīng)完成了關鍵芯片（比如：Micro-controller, SBC, ASIC, Driver ICs, Intelligence Sensor等）的選型。功能安全工程師在此階段還要主導完成對芯片手冊安全機制的裁剪活動，哪些是產(chǎn)品所必須用到的，哪些是可以裁剪的，并給出充分的理由。

　　3. 系統(tǒng)安全架構(gòu)開發(fā)：

　　有了系統(tǒng)需求，系統(tǒng)架構(gòu)，功能安全要求和技術(shù)安全要求后，功能安全工程師就可以開始設計（或者協(xié)助系統(tǒng)架構(gòu)工程師設計）系統(tǒng)安全架構(gòu)了。設計系統(tǒng)安全架構(gòu)要注意以下幾點：

　　a. 確保系統(tǒng)安全架構(gòu)和前面階段的系統(tǒng)架構(gòu)設計的一致性；

　　b. 系統(tǒng)安全架構(gòu)要能實現(xiàn)技術(shù)安全要求；（相應的安全要求和安全機制最好能體現(xiàn)在系統(tǒng)安全架構(gòu)中）

　　c. 設計的系統(tǒng)安全架構(gòu)能否被充分驗證，預期的軟硬件設計是否能滿足此系統(tǒng)安全架構(gòu)，是否方便于系統(tǒng)集成時測試的執(zhí)行；

　　d. 設計時要充分考慮安全相關的內(nèi)部和外部接口；

　　e. 如果此階段需要進行ASIL等級的降級分解，要按照ASIL的要求進行分解；

　　4. 啟動系統(tǒng)層面的安全分析：

　　有了完整的安全要求和系統(tǒng)安全架構(gòu)之后，功能安全工程師就可以啟動系統(tǒng)層面的安全分析（FMEA分析，F(xiàn)TA分析，DFA分析）了。執(zhí)行安全分析的主要目的在于：提供證據(jù)證明系統(tǒng)設計實現(xiàn)了相應ASIL等級的功能安全要求、識別失效原因和故障影響、識別或者確認安全相關系統(tǒng)組件和接口。

　　a. FMEA分析：FMEA是一種定性的、歸納式的單點故障分析方法，主要是在早期檢測和消除產(chǎn)品設計和制造過程中的薄弱點。

　　b. FTA分析：FTA是一種演繹式故障分析，它使用布爾邏輯來分析系統(tǒng)不期望的狀態(tài)，以結(jié)合一系列較低級的事件。FTA的目標是分析在系統(tǒng)中發(fā)生的實際故障的路徑，以定位系統(tǒng)故障的原因。

　　c. DFA分析：DFA的主要目的是通過分析潛在原因或者誘發(fā)因素，來確認設計中已經(jīng)充分實現(xiàn)了要求的獨立性（Independence獨立性是指在兩個或者多個元素之間沒有級聯(lián)故障和共因故障，從而可能導致違背安全目標），或相互之間免于干擾（FFI免于干擾是指在兩個或者多個元素之間沒有可能導致違反安全要求的級聯(lián)故障）。如果有必要的話，也可以制定相應安全措施，來減輕可能的相關失效。

　　圖６：不同類型的相關性失效之間的關系

　　硬件開發(fā)設計

　　1. 硬件安全要求開發(fā)：

　　有了系統(tǒng)層面的安全要求、安全架構(gòu)和安全分析的輸入后，功能安全工程師就可以開始開發(fā)（或者協(xié)助硬件工程師開發(fā)）硬件安全要求了。硬件安全要求主要從分配給硬件的技術(shù)安全要求和系統(tǒng)架構(gòu)設計中導出。

　　圖７：硬件層面的產(chǎn)品開發(fā)

　　2. 硬件安全架構(gòu)設計：

　　硬件安全架構(gòu)設計主要是硬件架構(gòu)師來負責，功能安全工程師協(xié)助支持，并支持做硬件架構(gòu)的評審。硬件安全架構(gòu)應盡量滿足模塊化、適當?shù)牧６人健⒑唵涡缘忍卣鳌Ｔ谟布軜?gòu)設計過程中，也可以參考ISO 26262第５部分中硬件架構(gòu)的設計方法（Table1）。

　　圖８－硬件架構(gòu)設計原則

　　3. 軟硬件接口列表（HSI）：

　　在硬件設計階段，功能安全工程師還要協(xié)助硬件工程師完成軟硬件接口列表的設計。在定義軟硬件接口時，要考慮好以下的要素：

　　a. 存儲器（RAM,ROM等）；

　　b. 總線接口（CAN, LIN等）；

　　c. 轉(zhuǎn)換器　（A/D，D/A，ＰＷＭ）；

　　d. Ｉ/O口；

　　e. 看門狗（內(nèi)狗，外狗）；

　　f. 多路轉(zhuǎn)換器；

　　【注】：每家公司對HSI的責任劃分也是不同的，有的可能要求系統(tǒng)工程師或者軟件工程師主導HSI的定義。

　　圖９：軟硬件接口概覽

　　4. 硬件安全分析：

　　功能安全工程師要協(xié)助硬件工程師進行硬件層面的安全分析，包括FMEA和FMEDA分析。

　　a. FMEA分析：硬件FMEA分析直接在系統(tǒng)FMEA分析的基礎上繼續(xù)對硬件組件進行分析就可以了。

　　b. FMEDA分析：FMEDA的計算，需要的輸入比較多（如：安全目標，硬件失效率目標值，安全要求，安全架構(gòu)，BOM表，Mission Profile，安全機制列表，SN29500的基礎失效率等），有了這些輸入就可以開始FMEDA的計算了，以檢查所設計的硬件產(chǎn)品的三個指標值（SPFM，LFM，PMHF）是否滿足相應ASIL等級的要求。

　　圖10：硬件失效率度量指標值

　　軟件開發(fā)設計

　　1. 軟件安全要求開發(fā)：

　　與硬件開發(fā)類似，有了技術(shù)安全要求、系統(tǒng)需求和系統(tǒng)架構(gòu)、硬件設計規(guī)范、軟硬件接口列表和軟件開發(fā)環(huán)境的輸入后，功能安全工程師就可以協(xié)助軟件需求工程師來開發(fā)軟件安全要求了。軟件安全要求一般來源于分配給軟件的技術(shù)安全要求或者軟件功能和特性的要求（如：能夠安全執(zhí)行相關功能，能夠使系統(tǒng)達到或者維持安全狀態(tài)的相關功能等）。

　　圖11：軟件層面的產(chǎn)品開發(fā)

　　2. 軟件安全架構(gòu)：

　　軟件安全架構(gòu)設計主要是軟件架構(gòu)師來負責，功能安全工程師協(xié)助支持，并支持做軟件架構(gòu)的評審活動。軟件架構(gòu)的設計要盡量滿足一致性、簡單性、可驗證性、模塊化、可維護性等特征。在軟件架構(gòu)設計中也可以參考ISO 26262第６部分中軟件架構(gòu)設計的方法（Table2, Table3 和Table４）。

　　圖12：軟件架構(gòu)設計原則

　　3. 軟件單元設計和實現(xiàn)：

　　軟件單元設計與實現(xiàn)主要由軟件開發(fā)人員負責，功能安全工程師能提供的支持相對有限。與軟件架構(gòu)設計類似，軟件單元設計也應盡量滿足一致性、可維護性、可驗證性等特性。在軟件單元設計和實現(xiàn)的活動中，也可以參考ISO 26262第６部分中軟件單元設計的方法（Table5, Table6）。

　　圖13：軟件單元設計和實現(xiàn)的設計原則

　　4. 軟件安全分析：

　　功能安全工程師要協(xié)助軟件工程師完成軟件的安全分析。與硬件相比，軟件安全分析沒有特定的方法，有的公司要求做軟件FMEA分析；而有的公司覺得用FMEA的思路來做軟件安全分析也并不是特別合適，這時候通常采用一種軟件關鍵路徑分析的方法來對軟件進行安全分析（需要軟件的動態(tài)架構(gòu)和靜態(tài)架構(gòu)來支持分析）。

　　4

　　測試驗證階段

　　對于各個階段的測試話題，由于很少有公司要求功能安全工程師去執(zhí)行測試活動，這里只簡單聊一聊各個階段的測試以及功能安全工程師在測試驗證階段要做些什么。

　　在各個階段的測試開始之前，功能安全工程師要主導ISO 26262方法的裁剪活動。功能安全工程師要跟系統(tǒng)、軟硬件和相關測試工程師一起，完成對ISO 26262方法的裁剪，被裁剪掉的方法要給出充分合理的理由。（“＋＋“代表高度推薦該方法，一般不能裁剪掉；“＋”代表推薦該方法，如果有合理的理由可以進行裁剪；“ｏ”代表不推薦該方法）

　　系統(tǒng)測試驗證

　　系統(tǒng)階段的測試一般包含以下幾種：

　　a） 系統(tǒng)功能測試：驗證系統(tǒng)功能是否滿足系統(tǒng)要求

　　b） 系統(tǒng)集成測試：驗證組件之間的接口是否滿足設計要求

　　c） DV測試：DV是設計驗證，驗證產(chǎn)品設計是否滿足要求，其中DV測試又包含環(huán)境耐久測試、電磁兼容測試、電氣特性測試

　　d） PV測試：PV是產(chǎn)品驗證，主要驗證產(chǎn)線上生產(chǎn)出來的產(chǎn)品是否符合要求。一般PV之后的產(chǎn)品，就具備了批量生產(chǎn)的資格了。

　　硬件測試驗證

　　硬件階段的測試一般比較關注硬件功能測試，也就是基于相關硬件需求的測試，以確認硬件電路設計與硬件需求是一致的。

　　軟件測試驗證

　　硬件階段的測試一般包含以下幾種：

　　a） 軟件功能測試：驗證軟件實現(xiàn)是否與軟件需求一致。

　　b） 軟件單元測試：驗證單元設計是否與單元設計需求規(guī)范一致。

　　c） 軟件集成測試：驗證集成的軟件是否滿足軟件需求，以及軟件組件之間的接口是否一致。

　　上述系統(tǒng)、硬件和軟件層面的測試驗證分別由系統(tǒng)、硬件和軟件測試工程師來負責。功能安全工程師主要關注相關的測試結(jié)果是否都通過，測試覆蓋度是否滿足100％。如果有測試失敗項，該測試會不會對產(chǎn)品的功能安全有影響。如果有失效項，復測結(jié)果如何。

　　【注】：通常故障注入測試會涵蓋在功能測試里，所以這里沒有單獨把故障注入測試拎出來。對于有些產(chǎn)品，如果用到的ASIC有安全手冊，也需要對裁剪后的安全機制進行故障注入測試，以確保實現(xiàn)的安全機制滿足要求。

更多信息可以來這里獲取==>>電子技術(shù)應用-AET<<