(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)。

圖4.1-6 合理性檢查

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

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

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

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

·  獨(dú)立監(jiān)控：控制器相關(guān)的故障發(fā)生后，此時(shí)控制器已經(jīng)無(wú)法可靠地執(zhí)行安全相關(guān)邏輯，為了保證安全性，需要外部額外的獨(dú)立監(jiān)控模塊，來(lái)確保即使 MCU 發(fā)生嚴(yán)重故障后，依然能夠進(jìn)入安全狀態(tài)。這個(gè)額外的獨(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ī)定的時(shí)間內(nèi)執(zhí)行，則程序流檢查失敗，無(wú)法正常喂狗，從而進(jìn)入系統(tǒng)安全狀態(tài)。

圖4.1-7 Level3功能框圖

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

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

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

※ 限于篇幅，“軟件架構(gòu)設(shè)計(jì)” 更詳細(xì)的內(nèi)容請(qǐng)參考 ISO26262(2018)-Part6，“安全分析”   更詳細(xì)的內(nèi)容請(qǐng)參考 ISO26262(2018)-Part9。

后者側(cè)重點(diǎn)是從嵌入式軟件系統(tǒng)角度看對(duì)系統(tǒng)級(jí)功能安全的支撐。基于 E-Gas 安全架構(gòu)的思想，我們認(rèn)為 “分層監(jiān)視思想” 、“安全措施” 和 “診斷框架” 是 “功能安全軟件架構(gòu)” 的核心，“分層監(jiān)視思想” 和 “安全措施” 在上文有說明，本節(jié)接下來(lái)內(nèi)容主要圍繞 “診斷框架” 進(jìn)行說明。

無(wú)論我們使用的基礎(chǔ)軟件開發(fā)平臺(tái)是 AUTOSAR CP、AP 或者是非 AUTOSAR，功能安全軟件架構(gòu)的設(shè)計(jì)思路是類似的，這里基于 AUTOSAR CP 進(jìn)行說明。

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

圖4.1-8 故障響應(yīng)時(shí)間和容錯(cuò)時(shí)間間隔

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

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

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

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

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

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

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

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

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

• 故障存儲(chǔ)：支持故障信息非易失存儲(chǔ)

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

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

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

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

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

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

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