引言

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

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

01

什么是功能安全

1

背景簡介

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

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

圖1: 安全相關系統

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

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

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

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

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

2

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

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

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

3

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

在HARA過程中，OEM為每個已識別的潛在風險分配了一個ASIL （AutomotiveSafety Integrity Level）等級。ASIL在開發過程中就已經確定了。根據可能存在的風險。

圖2：功能安全等級評定

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

為了適當地解決這些情況，ISO 26262使用ASIL評級來確定供應商必須采取的開發步驟的嚴格性，并定義了安全目標（safetygoal）的要求：

1. FIT率（FailureIn Time）: FIT率是車輛在給定時間段內可接受的故障率。車輛必須滿足ASIL評級所規定的FIT率，但OEM也可以靈活地為系統內的基礎組件選擇FIT率。

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

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

4

持續的測試和集成

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

圖3：V字開發模型

OEM，供應商或者獨立的第三方公司對所有相關的工作產出物進行功能安全審核和評估，以確保功能安全的實現。功能安全需求一個全面的管理過程，以確保適當的監督和完整的系統集成。

02

什么是功能安全工程師，

功能安全工程師做什么？

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

1

報價階段

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

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

2. 執行影響分析：

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

3.開發接口協議（DIA）責任劃分：

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

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

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

5.準備評審會議：

以上內容都完成之后，功能安全工程師就可以跟審核員（Assessor）約評審會議了。在會上，審核員會根據功能安全工程師準備的證據對該項目的產品開發成熟度進行評估以確認是否滿足當前的開發需要，以及是否有安全相關的風險，并輸出當前階段的評估報告。

【注】：由于每家公司的開發流程不同，所以對功能安全評估次數要求也不同，但基本都會在項目的關鍵節點進行功能安全評估。

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

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

2

概念設計階段

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

1)要根據功能安全目標定義產品的功能性或者降級的功能性行為；

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

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

4)把功能安全要求分配給系統架構設計；

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

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

3

開發設計階段

系統開發設計

1. 技術安全概念/要求開發：

功能安全工程師要完成（或者協助系統需求工程師完成）TSC/TSRs的開發。技術安全概念的主要目的如下：

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

b. 制定系統要素和接口實施安全機制的技術安全要求；

c. 制定在生產、運行、服務和報廢中系統及其要素功能安全的相關要求；

d. 驗證技術安全要求在系統層級是否符合功能安全要求并與功能安全要求一致；

e. 制定滿足安全要求且不與非安全相關要求沖突的系統架構設計和技術安全概念；

f. 分析系統架構設計，防止故障并為生產和服務得出必要的安全相關特殊特性；

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

圖5：系統層面的產品開發

2. 安全機制的裁剪：

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

3. 系統安全架構開發：

有了系統需求，系統架構，功能安全要求和技術安全要求后，功能安全工程師就可以開始設計（或者協助系統架構工程師設計）系統安全架構了。設計系統安全架構要注意以下幾點：

a. 確保系統安全架構和前面階段的系統架構設計的一致性；

b. 系統安全架構要能實現技術安全要求；（相應的安全要求和安全機制最好能體現在系統安全架構中）

c. 設計的系統安全架構能否被充分驗證，預期的軟硬件設計是否能滿足此系統安全架構，是否方便于系統集成時測試的執行；

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

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

4. 啟動系統層面的安全分析：

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

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

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

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

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

硬件開發設計

1. 硬件安全要求開發：

有了系統層面的安全要求、安全架構和安全分析的輸入后，功能安全工程師就可以開始開發（或者協助硬件工程師開發）硬件安全要求了。硬件安全要求主要從分配給硬件的技術安全要求和系統架構設計中導出。

圖７：硬件層面的產品開發

2. 硬件安全架構設計：

硬件安全架構設計主要是硬件架構師來負責，功能安全工程師協助支持，并支持做硬件架構的評審。硬件安全架構應盡量滿足模塊化、適當的粒度水平、簡單性等特征。在硬件架構設計過程中，也可以參考ISO 26262第５部分中硬件架構的設計方法（Table1）。

圖８－硬件架構設計原則

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

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

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

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

c. 轉換器（A/D，D/A，ＰＷＭ）；

d. Ｉ/O口；

e. 看門狗（內狗，外狗）；

f. 多路轉換器；

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

圖９：軟硬件接口概覽

4. 硬件安全分析：

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

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

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

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

軟件開發設計

1. 軟件安全要求開發：

與硬件開發類似，有了技術安全要求、系統需求和系統架構、硬件設計規范、軟硬件接口列表和軟件開發環境的輸入后，功能安全工程師就可以協助軟件需求工程師來開發軟件安全要求了。軟件安全要求一般來源于分配給軟件的技術安全要求或者軟件功能和特性的要求（如：能夠安全執行相關功能，能夠使系統達到或者維持安全狀態的相關功能等）。

圖11：軟件層面的產品開發

2. 軟件安全架構：

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

圖12：軟件架構設計原則

3. 軟件單元設計和實現：

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

圖13：軟件單元設計和實現的設計原則

4. 軟件安全分析：

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

4

測試驗證階段

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

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

系統測試驗證

系統階段的測試一般包含以下幾種：

a)系統功能測試：驗證系統功能是否滿足系統要求

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

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

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

硬件測試驗證

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

軟件測試驗證

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

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

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

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

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

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

審核編輯：劉清