01 E-GAS 安全架構(gòu)思想

汽車功能安全旨在把電子電氣系統(tǒng)失效而導致的人身危害風險控制在合理範圍內(nèi)。下圖是常見的電子電氣系統(tǒng)硬體組成圖，一個電子電氣系統(tǒng)的構(gòu)成要素，除了圖中可見的硬體外，還包含圖中不可見的軟體。

#圖1?常用電子電氣硬體系統(tǒng)

#電子電氣系統(tǒng)的失效，既包含因軟硬體設(shè)計錯誤所造成的系統(tǒng)性失效，也包含隨機硬體故障所造成的失效。根據(jù)系統(tǒng)架構(gòu)，需要設(shè)計各種安全機制去預防和探測功能故障，並且能夠在故障發(fā)生時，避免或降低危害的發(fā)生。這就需要一個強壯的功能安全軟體架構(gòu)來管理和控制這些安全機制，降低功能安全整體開發(fā)難度。

目前，E-GAS（Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units）無疑是目前使用最廣泛的一個安全軟體架構(gòu)方案。雖然E-GAS 最初只是針對汽/ 柴油引擎管理系統(tǒng)而提出的安全架構(gòu)方案，但是經(jīng)過簡單的適配，也可以用於車身系統(tǒng)，變速箱系統(tǒng)以及新能源的三電系統(tǒng)等，具有非常良好的擴展性，應用非常廣泛。

下圖是E-GAS 的三層軟體架構(gòu)設(shè)計方案，由上到下，軟體分為Level1~3 總共三層，Level1是功能實作層（function level） ，Level2 是功能監(jiān)控層（function monitoring level），Level3 是控制器監(jiān)控層（controller monitoring level）。該架構(gòu)形成了很好的分層監(jiān)視框架，並有效實現(xiàn)了功能安全分解，通常採用QM（ASIL X） ASIL X（ASIL X）的安全分解策略，即將功能實現(xiàn)軟體（Level1）按照QM 等級開發(fā)，功能冗餘軟體或安全措施（Level2、Level3）依照最高的要求等級ASIL X（ASIL X）進行開發(fā)，這樣可以有效降低功能軟體的安全開發(fā)成本。

#圖2?E-GAS三層監(jiān)視架構(gòu)方案

#圖2?E-GAS三層監(jiān)視架構(gòu)方案

Level1 功能實現(xiàn)層

#Level1 是功能實現(xiàn)層，完成具體的功能實現(xiàn)，例如對於馬達控制器來說，這一層實現(xiàn)了將請求的扭力轉(zhuǎn)換為馬達的扭力輸出。

Level2 功能監(jiān)控層

#Level2 是功能監(jiān)控層，用於監(jiān)控Level1功能的運作是否正常。 Level2 的核心是設(shè)計一套方法去判斷Level1 的運作是否正常。雖然判斷 Level1 運作是否正常的方法，往往跟被監(jiān)控的功能相關(guān)，不同被監(jiān)控功能有不同的判定方法，例如 : 透過軟體多樣化冗餘。但也有一些適用範圍較廣的判斷方法，例如合理性校驗。

#圖3?合理性檢定

如上圖所示，Level2 在使用合理性校驗方法判斷Level1 功能是否正常運作時，先根據(jù)感測器輸入的訊號，計算控制量允許輸出的合理範圍，再計算從執(zhí)行器回授的實際輸出量，最後判定Level1 的實際輸出量是否在允許的合理範圍，如果超出了合理的範圍，則判定Level1 功能異常，執(zhí)行錯誤處理。

Level3 控制器監(jiān)控層

#############Level3 是控制器監(jiān)控層，主要由三部分功能構(gòu)成。 ######

電子電氣系統(tǒng)硬體診斷：監(jiān)控電子電氣系統(tǒng)硬體故障，例如 : 控制器的 CPU 核故障、RAM 故障、ROM 故障等。

獨立監(jiān)控：控制器相關(guān)的故障發(fā)生後，此時控制器已經(jīng)無法可靠地執(zhí)行安全相關(guān)邏輯，為了確保安全性，需要外部額外的獨立監(jiān)控模組，來確保即使MCU 發(fā)生嚴重故障後，仍能進入安全狀態(tài)。這個額外的獨立監(jiān)控模組，通常是整合看門狗的電源管理晶片。

應用程式流程檢查：監(jiān)控 Level1 和 Level2 的監(jiān)控程式是否運作正常。此監(jiān)控功能透過將程式流程檢查和看門狗餵狗綁定實現(xiàn)。如果 Level1 和 Level2 相關(guān)的監(jiān)控程序沒有按照設(shè)定的順序運行，或者沒有在規(guī)定的時間內(nèi)執(zhí)行，則程序流程檢查失敗，無法正常餵狗，從而進入系統(tǒng)安全狀態(tài)。

#圖4?Level3功能方塊圖

## 02 國外功能安全軟體架構(gòu)發(fā)展情況

提到功能安全與軟體架構(gòu)，我們可以從「符合功能安全的軟體架構(gòu)」 與「功能安全軟體架構(gòu)」 這兩個維度去看待它們之間的關(guān)係。

前者重點在於從軟體開發(fā)角度來看我們的軟體架構(gòu)設(shè)計流程對功能安全的符合性，也就是我們的軟體架構(gòu)設(shè)計過程需要滿足ISO 26262 所提出的各種要求，如：標記方法、設(shè)計原則、設(shè)計要素需求、安全分析需求、錯誤偵測機制需求、錯誤處理機制以及設(shè)計驗證方法等，其中，軟體架構(gòu)層面的安全分析主流手段是「軟體FMEA（Failure Mode and Effects Analysis）” 和“軟體DFA（Dependent Failure Analysis）” 。

後者重點是從內(nèi)嵌軟體系統(tǒng)角度看對系統(tǒng)級功能安全的支撐?；禘-Gas 安全架構(gòu)的思想，我們認為「分層監(jiān)視思想」 、「安全措施」 和「診斷框架」 是「功能安全軟體架構(gòu)」 的核心，「分層監(jiān)視思想」和「安全措施」 在上文有說明，本節(jié)接下來內(nèi)容主要圍繞「診斷架構(gòu)」 進行說明。無論我們使用的基礎(chǔ)軟體開發(fā)平臺是 AUTOSAR CP、AP 或是非 AUTOSAR，功能安全軟體架的設(shè)計想法是類似的，這裡基於 AUTOSAR CP 進行說明。

1）功能安全診斷框架技術(shù)需求

圖5?故障回應時間與容錯時間間隔

#######我們結(jié)合FTTI（故障容忍時間間隔，fault tolerant time interval）理解故障診斷過程。從故障發(fā)生到產(chǎn)生可能危害之間的這段時間就是 FTTI 時間，此期間主要有診斷測試、故障反應過程，並且希望在產(chǎn)生可能危害之前進入安全狀態(tài) ( 圖 4.1-8)。診斷測試過程需要考慮診斷測試觸發(fā)、故障確認（去抖）等，###故障回應過程需要考慮進入合理的操作模式（如：Fail safe, Fail operational, Emergency operation 等）、故障儲存等。 ############綜上，「診斷框架」 的核心設(shè)計需要考慮覆蓋診斷測試、故障回應過程。主要的功能安全診斷框架技術(shù)要求有：#######

• 故障統(tǒng)一管理：對E-GAS 多層監(jiān)視框架各故障監(jiān)視層上報的故障進行狀態(tài)統(tǒng)一管理
• 故障回應時間需求：故障檢出到進入安全狀態(tài)需滿足故障容忍時間間隔（FTTI）的要求
• 獨立性要求：片上安全機制與功能有共因問題，需支援獨立性監(jiān)視（MCU片外監(jiān)視）
• 多樣化需求：軟體架構(gòu)必須滿足框架設(shè)計通用化和支援安全策略多樣化（不同專案對安全機制有不同要求）
• 診斷測試時機：上下電，週期，條件觸發(fā)等
• 故障去抖/ 延時檢查：需支援安全機制的去抖動測試功能，至少支援基於時間和基於計數(shù)去抖演算法
• 診斷事件和功能解耦：診斷事件和功能獨立管理，之間存在映射關(guān)係
• 故障儲存：支援故障訊息非揮發(fā)性儲存

2） 國外診斷框架技術(shù)狀況解讀

在對診斷框架技術(shù)展開解讀之前，有兩個面向的建議供參考。

① 建議 1：根據(jù)需求決定診斷測試的時機

a. 上電時：這裡結(jié)合一個典型應用需求來說明。安全機制（safety mechanism）和對應的功能構(gòu)成了雙點，為了降低潛伏多點故障失效率，一般在系統(tǒng)啟動階段（上電時），安全機制需要做自檢。此外，在多處理器系統(tǒng)中還需要考慮診斷測試同步問題。

b. 執(zhí)行時期：一般分週期性診斷測試和條件診斷測試。診斷週期的定義需要考慮 FDTI（fault detection time interval）的約束，而條件診斷測試一般是發(fā)生狀態(tài)遷移時或在啟動某個功能前對功能進行的診斷。

c. 下電時：可以選擇執(zhí)行一些比較耗時的測試，而測試結(jié)果一般放在下次啟動時處理。

② 建議2：進行分組診斷測試

#為了便於診斷管理（包括診斷觸發(fā)和??故障回應等），根據(jù)臨界故障/非臨界故障，診斷測試時機等因素進行分組。上電時如果檢出臨界故障（Critical fault），例如：核故障（Core Fault）、易失性記憶體測試故障（Ram Test Fault）等，這時故障響應可以選擇處在一個靜默狀態(tài)處理（如： MCU 處在連續(xù)重設(shè)狀態(tài)）。

#圖6?「功能安全診斷架構(gòu)」與「功能性診斷控制流程」

E-Gas 三層監(jiān)視框架的Level1(function level） 及Level2(function monitoring level） 位於ASW(application software, 即: 圖4.1-9 中的SWC) 層，Level33 (controller monitoring level） 位於BSW(basic software) 層。 「診斷架構(gòu)」 同樣也位於 BSW 層，如上所述主要涵蓋診斷測試、故障回應過程，下文對其構(gòu)成和工作過程展開介紹：

#

• BswM、 EcuM 主要負責上電管理，在STARTUP、UP、SHUTDOWN 階段分別進行上電時、運行時、下電時的診斷測試
• #ASW-Level1（E-Gas Level1）涵蓋功能輸入/ 輸出的診斷；ASW-Level2（E-Gas Level2）一般實現(xiàn)為ASW-Level1 功能的冗餘演算法，實現(xiàn)ASW-Level1 ASIL 等級的分解；TestLib （E-GasLevel3）監(jiān)控ECU、MCU 層面的硬體失效（建議參考ISO26262(2018)-Part5 Annex D 及MCU安全手冊），覆蓋Level1 和Level2 共因失效的診斷，並和「監(jiān)視控制器」 實現(xiàn)用於邏輯及時間獨立性診斷的問答看門狗機制
• TestManager 負責對TestLib 安全機制的診斷測試觸發(fā)及相應測試結(jié)果的收集
• #DEM 收集E-Gas Level1/2/3 的測試結(jié)果，診斷事件去抖，標記故障碼及透過NvM 進行故障訊息儲存。 FiM 根據(jù) DEM 診斷測試結(jié)果（去抖動後）標記已配置的功能，功能軟體（ASW-Level1）根據(jù)標記來決定功能的抑制。

#

以上是智慧汽車功能安全軟體架構(gòu)的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！