9月18日，在 “2022世界智能網(wǎng)聯(lián)汽車大會” 上，中國汽車工業(yè)協(xié)會軟件分會理事長、AUTOSEMO輪值主席、中汽創(chuàng)智CEO李豐軍先生代表AUTOSEMO通過視頻的方式發(fā)布了《中國汽車基礎(chǔ)軟件發(fā)展白皮書3.0》。 本文節(jié)選自此次發(fā)布的白皮書，主要介紹功能安全軟件架構(gòu)。

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

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

圖1常用電子電氣硬件系統(tǒng)

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

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

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

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

（1） Level1 功能實(shí)現(xiàn)層

Level1 是功能實(shí)現(xiàn)層，完成具體的功能實(shí)現(xiàn)，比如對于電機(jī)控制器來說，這一層實(shí)現(xiàn)了將請求的扭矩轉(zhuǎn)換為電機(jī)的扭矩輸出。

（2） Level2 功能監(jiān)控層

Level2 是功能監(jiān)控層，用于監(jiān)控 Level1 功能的運(yùn)行是否正常。Level2 的核心是設(shè)計(jì)一套方法去判斷Level1 的運(yùn)行是否正常。雖然判斷 Level1 運(yùn)行是否正常的方法，往往跟被監(jiān)控的功能相關(guān)，不同被監(jiān)控功能有不同的判定方法，比如 : 通過軟件多樣化冗余。但也有一些適用范圍較廣的判斷方法，比如合理性校驗(yàn)。

圖3 合理性檢查

如上圖 所示，Level2 在使用合理性校驗(yàn)方法判斷 Level1 功能是否正常運(yùn)行時，先根據(jù)傳感器輸入的信號，計(jì)算控制量允許輸出的合理范圍，再計(jì)算從執(zhí)行器反饋的實(shí)際輸出量，最后判定 Level1 的實(shí)際輸出量是否在允許的合理范圍，如果超出了合理的范圍，則判定 Level1 功能異常，執(zhí)行錯誤處理。

（3） Level3 控制器監(jiān)控層

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

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

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

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

圖4Level3功能框圖

2. 國外功能安全軟件架構(gòu)發(fā)展情況

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

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

后者側(cè)重點(diǎn)是從嵌入式軟件系統(tǒng)角度看對系統(tǒng)級功能安全的支撐?；?E-Gas 安全架構(gòu)的思想，我們認(rèn)為 “分層監(jiān)視思想” 、“安全措施” 和 “診斷框架” 是 “功能安全軟件架構(gòu)” 的核心，“分層監(jiān)視思想”和 “安全措施” 在上文有說明，本節(jié)接下來內(nèi)容主要圍繞 “診斷框架” 進(jìn)行說明。無論我們使用的基礎(chǔ)軟件開發(fā)平臺是 AUTOSAR CP、AP 或者是非 AUTOSAR，功能安全軟件架的設(shè)計(jì)思路是類似的，這里基于 AUTOSAR CP 進(jìn)行說明。

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

圖5故障響應(yīng)時間和容錯時間間隔

我們結(jié)合 FTTI（故障容忍時間間隔，fault tolerant time interval）理解故障診斷過程。從故障發(fā)生到產(chǎn)生可能危害之間的這段時間就是 FTTI 時間，此期間主要有診斷測試、故障響應(yīng)過程，并且希望在產(chǎn)生可能危害之前進(jìn)入安全狀態(tài) ( 圖 4.1-8)。診斷測試過程需要考慮診斷測試觸發(fā)、故障確認(rèn)（去抖）等，
故障響應(yīng)過程需要考慮進(jìn)入合理的操作模式（如：Fail safe, Fail operational, Emergency operation 等）、故障存儲等。

綜上，“診斷框架” 的核心設(shè)計(jì)需要考慮覆蓋診斷測試、故障響應(yīng)過程。主要的功能安全診斷框架技術(shù)要求有：

故障統(tǒng)一管理：對 E-GAS 多層監(jiān)視框架各故障監(jiān)視層上報(bào)的故障進(jìn)行狀態(tài)統(tǒng)一管理

故障響應(yīng)時間要求：故障檢出到進(jìn)入安全狀態(tài)需滿足故障容忍時間間隔（FTTI）的要求

獨(dú)立性要求：片上安全機(jī)制與功能存在共因問題，需支持獨(dú)立性監(jiān)視（MCU 片外監(jiān)視）

多樣化要求：軟件架構(gòu)須滿足框架設(shè)計(jì)通用化和支持安全策略多樣化（不同項(xiàng)目對安全機(jī)制有不同要求）

診斷測試時機(jī)：上下電，周期，條件觸發(fā)等

故障去抖 / 延時檢查：需支持安全機(jī)制的去抖測試功能，至少支持基于時間和基于計(jì)數(shù)去抖算法

診斷事件和功能解耦：診斷事件和功能獨(dú)立管理，之間存在映射關(guān)系

故障存儲：支持故障信息非易失存儲

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

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

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

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

b. 運(yùn)行時：一般分周期性診斷測試和條件診斷測試。診斷周期的定義需要考慮 FDTI（fault detection time interval）的約束，而條件診斷測試一般是發(fā)生狀態(tài)遷移時或在激活某個功能前對功能進(jìn)行的診斷。

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

② 建議 2：進(jìn)行分組診斷測試

為了便于診斷管理（包括診斷觸發(fā)和故障響應(yīng)等），根據(jù)臨界故障 / 非臨界故障，診斷測試時機(jī)等因素進(jìn)行分組。上電時如果檢出臨界故障（Critical fault），比如：核故障（Core Fault）、易失性存儲器測試故障（Ram Test Fault）等，這時故障響應(yīng)可以選擇處在一個靜默狀態(tài)處理（如：MCU 處在連續(xù)復(fù)位狀態(tài)）。

圖6 “功能安全診斷框架”與“功能安全診斷控制流”

E-Gas 三 層 監(jiān) 視 框 架 的 Level1(function level） 及 Level2(function monitoring level） 位 于 ASW(application software, 即 : 圖 4.1-9 中 的 SWC) 層，Level3(controller monitoring level） 位 于BSW(basic software) 層?！霸\斷框架” 同樣也位于 BSW 層，如上文所述主要覆蓋診斷測試、故障響應(yīng)過程，下文對其構(gòu)成和工作過程展開介紹：

BswM、 EcuM 主要負(fù)責(zé)上下電管理，在 STARTUP、UP、SHUTDOWN 階段分別進(jìn)行上電時、運(yùn)行時、下電時的診斷測試

ASW-Level1（E-Gas Level1）覆蓋功能輸入 / 輸出的診斷；ASW-Level2（E-Gas Level2）一般實(shí)現(xiàn)為 ASW-Level1 功能的冗余算法，實(shí)現(xiàn) ASW-Level1 ASIL 等級的分解；TestLib（E-GasLevel3）監(jiān)視 ECU、MCU 層面的硬件失效（建議參考 ISO26262(2018)-Part5 Annex D 及 MCU安全手冊），覆蓋 Level1 和 Level2 共因失效的診斷，并和 “監(jiān)視控制器” 實(shí)現(xiàn)用于邏輯及時間獨(dú)立性診斷的問答看門狗機(jī)制

TestManager 負(fù)責(zé)對 TestLib 安全機(jī)制的診斷測試觸發(fā)及相應(yīng)測試結(jié)果的收集

DEM 收集 E-Gas Level1/2/3 的測試結(jié)果，診斷事件去抖，標(biāo)記故障碼及通過 NvM 進(jìn)行故障信息存儲。FiM 根據(jù) DEM 診斷測試結(jié)果（去抖后）標(biāo)記已配置的功能，功能軟件（ASW-Level1）根據(jù)標(biāo)記來決定對功能的抑制。

AUTOSEMO背景

在全球汽車產(chǎn)業(yè)以電動化、智能化、網(wǎng)聯(lián)化、共享化為代表的“新四化”的趨勢下，智能化已成為汽車工業(yè)發(fā)展不可逆轉(zhuǎn)的趨勢?！败浖x汽車”已經(jīng)成為全企業(yè)的戰(zhàn)略共識，軟件在整車成本中所占比重逐年增大，成為企業(yè)核心價值和戰(zhàn)略制高點(diǎn)。汽車創(chuàng)新的主要方向，包括自動駕駛在內(nèi)的大量車內(nèi)的軟件由于高度的復(fù)雜性，將很難由單一的整車企業(yè)或零部件供應(yīng)商獨(dú)立完成，同時大量新的傳感器和控制器以及專用芯片也開始出現(xiàn)在汽車的硬件平臺上，整車企業(yè)希望能夠快速的將這些新的硬件和功能應(yīng)用到車輛的系統(tǒng)中，并能夠通過不斷的軟硬件升級給客戶帶來新的體驗(yàn)。為了順應(yīng)全球變革帶給中國車廠的影響，對于本土車廠對智能網(wǎng)聯(lián)、自動駕駛的需求。鼓勵發(fā)展具有我國自主知識產(chǎn)權(quán)的汽車基礎(chǔ)軟件生態(tài)體系尤為重要，是解決中國汽車產(chǎn)業(yè)做大做強(qiáng)的堅(jiān)實(shí)基礎(chǔ)。

鑒于中國汽車基礎(chǔ)軟件發(fā)展的重要性，應(yīng)國內(nèi)主要汽車企業(yè)的要求，并經(jīng)主管部門認(rèn)可，中國汽車工業(yè)協(xié)會（以下簡稱：中汽協(xié)），于2019年12月決定組建中國汽車基礎(chǔ)軟件生態(tài)委員會（英文China Automotive Basic Software Ecosystem Committee，簡稱AUTOSEMO）。旨在聯(lián)合汽車及軟件產(chǎn)業(yè)內(nèi)的成員，形成由本土企業(yè)主導(dǎo)的共同規(guī)劃和創(chuàng)建適應(yīng)新需求的軟件架構(gòu)和接口規(guī)范，做強(qiáng)本土基礎(chǔ)軟件，推動行業(yè)開放和協(xié)作，促進(jìn)產(chǎn)業(yè)向更智能化的方向發(fā)展。在當(dāng)前復(fù)雜多變的國際產(chǎn)業(yè)競爭趨勢下，設(shè)立AUTOSEMO具有十分重要的戰(zhàn)略意義和現(xiàn)實(shí)意義。

審核編輯 ：李倩