智慧汽車功能安全軟體架構
- WBOY轉載
- 2023-04-27 18:55:072019瀏覽
01 E-GAS 安全架構思想
汽車功能安全旨在把電子電氣系統失效而導致的人身危害風險控制在合理範圍內。下圖是常見的電子電氣系統硬體組成圖，一個電子電氣系統的構成要素，除了圖中可見的硬體外，還包含圖中不可見的軟體。
#圖1 常用電子電氣硬體系統
#電子電氣系統的失效，既包含因軟硬體設計錯誤所造成的系統性失效，也包含隨機硬體故障所造成的失效。根據系統架構，需要設計各種安全機制去預防和探測功能故障，並且能夠在故障發生時，避免或降低危害的發生。這就需要一個強壯的功能安全軟體架構來管理和控制這些安全機制，降低功能安全整體開發難度。
目前，E-GAS（Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units）無疑是目前使用最廣泛的一個安全軟體架構方案。雖然E-GAS 最初只是針對汽/ 柴油引擎管理系統而提出的安全架構方案，但是經過簡單的適配，也可以用於車身系統，變速箱系統以及新能源的三電系統等，具有非常良好的擴展性，應用非常廣泛。
下圖是E-GAS 的三層軟體架構設計方案，由上到下，軟體分為Level1~3 總共三層，Level1是功能實作層（function level） ，Level2 是功能監控層（function monitoring level），Level3 是控制器監控層（controller monitoring level）。該架構形成了很好的分層監視框架，並有效實現了功能安全分解，通常採用QM（ASIL X） ASIL X（ASIL X）的安全分解策略，即將功能實現軟體（Level1）按照QM 等級開發，功能冗餘軟體或安全措施（Level2、Level3）依照最高的要求等級ASIL X（ASIL X）進行開發，這樣可以有效降低功能軟體的安全開發成本。
#圖2 E-GAS三層監視架構方案
#圖2 E-GAS三層監視架構方案
Level1 功能實現層
#Level1 是功能實現層，完成具體的功能實現，例如對於馬達控制器來說，這一層實現了將請求的扭力轉換為馬達的扭力輸出。
Level2 功能監控層
#圖3 合理性檢定
如上圖所示，Level2 在使用合理性校驗方法判斷Level1 功能是否正常運作時，先根據感測器輸入的訊號，計算控制量允許輸出的合理範圍，再計算從執行器回授的實際輸出量，最後判定Level1 的實際輸出量是否在允許的合理範圍，如果超出了合理的範圍，則判定Level1 功能異常，執行錯誤處理。
Level3 控制器監控層
#############Level3 是控制器監控層，主要由三部分功能構成。 ######電子電氣系統硬體診斷：監控電子電氣系統硬體故障，例如 : 控制器的 CPU 核故障、RAM 故障、ROM 故障等。
獨立監控：控制器相關的故障發生後，此時控制器已經無法可靠地執行安全相關邏輯，為了確保安全性，需要外部額外的獨立監控模組，來確保即使MCU 發生嚴重故障後，仍能進入安全狀態。這個額外的獨立監控模組，通常是整合看門狗的電源管理晶片。
應用程式流程檢查：監控 Level1 和 Level2 的監控程式是否運作正常。此監控功能透過將程式流程檢查和看門狗餵狗綁定實現。如果 Level1 和 Level2 相關的監控程序沒有按照設定的順序運行，或者沒有在規定的時間內執行，則程序流程檢查失敗，無法正常餵狗，從而進入系統安全狀態。
#圖4 Level3功能方塊圖
## 02 國外功能安全軟體架構發展情況
提到功能安全與軟體架構，我們可以從「符合功能安全的軟體架構」 與「功能安全軟體架構」 這兩個維度去看待它們之間的關係。
前者重點在於從軟體開發角度來看我們的軟體架構設計流程對功能安全的符合性，也就是我們的軟體架構設計過程需要滿足ISO 26262 所提出的各種要求，如：標記方法、設計原則、設計要素需求、安全分析需求、錯誤偵測機制需求、錯誤處理機制以及設計驗證方法等，其中，軟體架構層面的安全分析主流手段是「軟體FMEA（Failure Mode and Effects Analysis）” 和“軟體DFA（Dependent Failure Analysis）” 。
後者重點是從內嵌軟體系統角度看對系統級功能安全的支撐。基於E-Gas 安全架構的思想，我們認為「分層監視思想」 、「安全措施」 和「診斷框架」 是「功能安全軟體架構」 的核心，「分層監視思想」和「安全措施」 在上文有說明，本節接下來內容主要圍繞「診斷架構」 進行說明。無論我們使用的基礎軟體開發平台是 AUTOSAR CP、AP 或是非 AUTOSAR，功能安全軟體架的設計想法是類似的，這裡基於 AUTOSAR CP 進行說明。
1）功能安全診斷框架技術需求
圖5 故障回應時間與容錯時間間隔
#######我們結合FTTI（故障容忍時間間隔，fault tolerant time interval）理解故障診斷過程。從故障發生到產生可能危害之間的這段時間就是 FTTI 時間，此期間主要有診斷測試、故障反應過程，並且希望在產生可能危害之前進入安全狀態 ( 圖 4.1-8)。診斷測試過程需要考慮診斷測試觸發、故障確認（去抖）等，###故障回應過程需要考慮進入合理的操作模式（如：Fail safe, Fail operational, Emergency operation 等）、故障儲存等。 ############綜上，「診斷框架」 的核心設計需要考慮覆蓋診斷測試、故障回應過程。主要的功能安全診斷框架技術要求有：#######- 故障統一管理：對E-GAS 多層監視框架各故障監視層上報的故障進行狀態統一管理
- 故障回應時間需求：故障檢出到進入安全狀態需滿足故障容忍時間間隔（FTTI）的要求
- 獨立性要求：片上安全機制與功能有共因問題，需支援獨立性監視（MCU片外監視）
- 多樣化需求：軟體架構必須滿足框架設計通用化和支援安全策略多樣化（不同專案對安全機制有不同要求）
- 診斷測試時機：上下電，週期，條件觸發等
- 故障去抖/ 延時檢查：需支援安全機制的去抖動測試功能，至少支援基於時間和基於計數去抖演算法
- 診斷事件和功能解耦：診斷事件和功能獨立管理，之間存在映射關係
- 故障儲存：支援故障訊息非揮發性儲存
2） 國外診斷框架技術狀況解讀
在對診斷框架技術展開解讀之前，有兩個面向的建議供參考。
① 建議 1：根據需求決定診斷測試的時機
a. 上電時：這裡結合一個典型應用需求來說明。安全機制（safety mechanism）和對應的功能構成了雙點，為了降低潛伏多點故障失效率，一般在系統啟動階段（上電時），安全機制需要做自檢。此外，在多處理器系統中還需要考慮診斷測試同步問題。
b. 執行時期：一般分週期性診斷測試和條件診斷測試。診斷週期的定義需要考慮 FDTI（fault detection time interval）的約束，而條件診斷測試一般是發生狀態遷移時或在啟動某個功能前對功能進行的診斷。
c. 下電時：可以選擇執行一些比較耗時的測試，而測試結果一般放在下次啟動時處理。
② 建議2：進行分組診斷測試
#為了便於診斷管理（包括診斷觸發和故障回應等），根據臨界故障/非臨界故障，診斷測試時機等因素進行分組。上電時如果檢出臨界故障（Critical fault），例如：核故障（Core Fault）、易失性記憶體測試故障（Ram Test Fault）等，這時故障響應可以選擇處在一個靜默狀態處理（如： MCU 處在連續重設狀態）。
#圖6 「功能安全診斷架構」與「功能性診斷控制流程」
E-Gas 三層監視框架的Level1(function level） 及Level2(function monitoring level） 位於ASW(application software, 即: 圖4.1-9 中的SWC) 層，Level33 (controller monitoring level） 位於BSW(basic software) 層。 「診斷架構」 同樣也位於 BSW 層，如上所述主要涵蓋診斷測試、故障回應過程，下文對其構成和工作過程展開介紹：
#- BswM、 EcuM 主要負責上電管理，在STARTUP、UP、SHUTDOWN 階段分別進行上電時、運行時、下電時的診斷測試
- #ASW-Level1（E-Gas Level1）涵蓋功能輸入/ 輸出的診斷；ASW-Level2（E-Gas Level2）一般實現為ASW-Level1 功能的冗餘演算法，實現ASW-Level1 ASIL 等級的分解；TestLib （E-GasLevel3）監控ECU、MCU 層面的硬體失效（建議參考ISO26262(2018)-Part5 Annex D 及MCU安全手冊），覆蓋Level1 和Level2 共因失效的診斷，並和「監視控制器」 實現用於邏輯及時間獨立性診斷的問答看門狗機制
- TestManager 負責對TestLib 安全機制的診斷測試觸發及相應測試結果的收集
- #DEM 收集E-Gas Level1/2/3 的測試結果，診斷事件去抖，標記故障碼及透過NvM 進行故障訊息儲存。 FiM 根據 DEM 診斷測試結果（去抖動後）標記已配置的功能，功能軟體（ASW-Level1）根據標記來決定功能的抑制。
以上是智慧汽車功能安全軟體架構的詳細內容。更多資訊請關注PHP中文網其他相關文章！