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

圖4.1-9 “功能安全診斷框架”與“功能安全診斷控制流”

E-Gas 三層監(jiān)視框架的 Level1(function level） 及 Level2(function monitoring level） 位于 AS- W(application software, 即 : 圖 4.1-9 中 的 SWC) 層，Level3(controller monitoring level） 位 于BSW(basic software) 層。“診斷框架” 同樣也位于 BSW 層，如上文所述主要覆蓋診斷測試、故障響應(yīng)過程 ( 圖 4.1-9)，下文對其構(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-Gas Level3）監(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)記來決定對功能的抑制

4.1.3  內(nèi)存分區(qū)靜態(tài)分析技術(shù)解讀

內(nèi)存分區(qū)靜態(tài)分析技術(shù)是靜態(tài)分析層面的 Safety Checker 技術(shù)，用于靜態(tài)分析各軟件要素之間實(shí)際上是否實(shí)現(xiàn)有效的隔離，達(dá)到免于干擾的目的。

在應(yīng)用軟件這個層面上，軟件要素可以認(rèn)為具有控制流或數(shù)據(jù)流的屬性。如果要證明不同分區(qū)的兩個軟件要素互相不干擾，必須展示它們之間有不允許控制流或者數(shù)據(jù)流交互的機(jī)制。Safety Checker 技術(shù)基于軟件要素的控制流和數(shù)據(jù)流進(jìn)行分析，可以用于源代碼或者目標(biāo)文件，在軟件的構(gòu)建階段進(jìn)行內(nèi)存的干擾檢測。該技術(shù)以軟件分區(qū)的設(shè)計(jì)文檔或者需求文檔為輸入，檢測實(shí)際的軟件代碼是否真正符合設(shè)計(jì)的需求，對于防止內(nèi)存干擾的設(shè)計(jì)進(jìn)行驗(yàn)證，形成一個軟件開發(fā)到分析檢測的閉環(huán)。

圖4.1-10 Safety Checker的使用方式

靜態(tài)分析之前，首先需要定義軟件安全級別分類（如：ASIL A/B/C/D 等），接下來需要分配不同安全級別間的分區(qū)訪問權(quán)限（讀，寫，執(zhí)行），最后將程序中的符號和資源（代碼，變量，存儲空間等）分配相應(yīng)的安全級別。上圖是 Safety Checker 進(jìn)行代碼靜態(tài)分析的方法和流程。部分或者全部的源代碼都可以使用該技術(shù)進(jìn)行內(nèi)存干擾的分析，將配置好的內(nèi)存分區(qū)信息文件（partitioning.saf）和源文件作為輸入，就可以獲得分析結(jié)果。根據(jù)軟件設(shè)計(jì)或者需求文檔，可以通過軟件分區(qū)信息文件 partitioning.saf 對于整個工程用腳本的形式做一些規(guī)則的編輯，這些規(guī)則包括以下內(nèi)容：

·  軟件安全級別

·  分區(qū)間訪問權(quán)限

·  關(guān)鍵函數(shù)和數(shù)據(jù)對象（變量、數(shù)組、指定內(nèi)存空間）的安全級別

內(nèi)存分區(qū)可以有效解決免于內(nèi)存干擾問題，Safety Checker 技術(shù)則是對這個方案的有效補(bǔ)充，該技術(shù)能夠分析位于 ECU 上的所有軟件的行為，找出軟件分區(qū)間干擾和分區(qū)內(nèi)干擾。在軟件的開發(fā)階段發(fā)現(xiàn)違背設(shè)計(jì)目標(biāo)的內(nèi)存干擾項(xiàng)，可以減少測試驗(yàn)證階段的壓力，縮短項(xiàng)目的開發(fā)周期。

4.1.4  工具鏈的功能安全要求

開發(fā)符合功能安全要求的軟件，使用的軟件工具鏈同樣需要符合功能安全要求。ISO 26262-8 第 11 章討論確定了軟件工具的置信度水平（TCL），并提供了對工具進(jìn)行資格認(rèn)證的方法，以創(chuàng)建證據(jù)來證明軟件工具適合用于功能安全相關(guān)軟件開發(fā) ( 圖 4.1-11 和圖 4.1-12)。

圖4.1-11 工具置信度活動的概覽

圖4.1-12 工具評估與鑒定流程

工具影響等級和工具錯誤探測等級兩個維度，共同決定了工具的置信度水平。

其中工具影響（TI）等級反應(yīng)的是軟件工具的異常，可引入或者不能探測開發(fā)中安全相關(guān)項(xiàng)或要素中錯誤的可能性。

·  有論據(jù)表明沒有這樣的可能性，確保軟件工具的異常不會引入到安全相關(guān)軟件要素，應(yīng)選擇 TI1；

·  其他所有的情況下，都選擇 TI2。

工具錯誤探測（TD）等級，反應(yīng)的是用于預(yù)防軟件工具功能異常并產(chǎn)生相應(yīng)錯誤輸出的措施的置信度， 或用于探測軟件工具存在功能異常并已產(chǎn)生相應(yīng)錯誤輸出的措施的置信度。

·  當(dāng)對預(yù)防或探測出功能異常及其相應(yīng)錯誤輸出具有高置信度時，應(yīng)選擇 TD1；

·  當(dāng)對預(yù)防或探測出功能異常及其相應(yīng)錯誤輸出具有中等置信度時，應(yīng)選擇 TD2；

·  在所有其他情況下應(yīng)選擇 TD3。

如果對 TI 或 TD 選擇的正確性是不清楚的或可疑的，宜對 TI 和 TD 進(jìn)行保守評估，即選擇最高級?；跒?TI 和 TD 等級確定的值，按照下表 4.1-2 確定所要求的軟件工具的置信度水平。

表4.1-2 軟件工具的置信度水平

其中針對 TCL1 等級的軟件工具無需進(jìn)行認(rèn)證，針對 TCL2 和 TCL3 的軟件還需要結(jié)合實(shí)際的功能安全需求進(jìn)行下一步的認(rèn)證。下表 4.1-3 中總結(jié)了 TCL2 和 TCL3 等級的軟件工具在不同 ASIL 等級的要求。可以看出，兩者僅在 ASIL-C 等級鑒定要求有所不同。

表4.1-3 TCL2和TCL3等級的軟件工具鑒定

注：++ 表示該方法被強(qiáng)烈建議用于所對應(yīng)的 ASIL，+ 表示該方法被建議用于所對應(yīng)的 ASIL。標(biāo)準(zhǔn)中提供四種方法來鑒定軟件工具：

·  使用中積累置信度。顧名思義，在之前的開發(fā)中，對于軟件的使用積累了足夠的數(shù)據(jù)和經(jīng)驗(yàn)，對于當(dāng)前所應(yīng)用的項(xiàng)目，軟件工具具有相似的使用案例、相似的運(yùn)行環(huán)境和相似的功能約束。

·  工具開發(fā)流程評估。就是用于開發(fā)軟件工具的流程應(yīng)當(dāng)滿足適當(dāng)?shù)臉?biāo)準(zhǔn)，同時提供該流程被應(yīng)用的證據(jù)。例如，ASPICE 或者 CMMI 的認(rèn)證。

·  軟件工具確認(rèn)。確認(rèn)措施應(yīng)提供軟件工具符合分類中指定用途的特定要求的證據(jù)；應(yīng)對確認(rèn)中發(fā) 生的軟件工具功能異常及其相應(yīng)錯誤輸出、其可能的后果信息及避免或探測它們的措施進(jìn)行分析；應(yīng)檢查軟件工具對異常運(yùn)行條件的響應(yīng)。

·  按照安全標(biāo)準(zhǔn)開發(fā)。安全標(biāo)準(zhǔn)如 ISO 26262、IEC61508、GB/T 34590-XXXX、GB/T 20438、EN50128 等，并不完全適用于軟件工具的開發(fā)，可從安全標(biāo)準(zhǔn)中選擇相關(guān)的一組要求。

至此，結(jié)合我們項(xiàng)目中 ASIL 的需求，以及軟件工具的 TCL 等級，可以選擇適當(dāng)?shù)姆椒ㄨb定軟件工具。對于前兩種方法，只適合 ASIL-A、ASIL-B 以及軟件工具被鑒定為 TCL2 的 ASIL-C 的項(xiàng)目應(yīng)用。

對于 ASIL-C（TCL3）和 ASIL-D 等級的項(xiàng)目，只有后兩種方法適用。在汽車軟件工具領(lǐng)域，普遍采用 “軟件工具確認(rèn)” 的方法。從本質(zhì)上講，“軟件工具確認(rèn)” 意味著使用驗(yàn)證措施來證明軟件工具滿足其目的的指定要求。

有兩種不同的方式被用來實(shí)現(xiàn) ISO 26262 的 “軟件工具確認(rèn)” 要求。

一種是軟件工具供應(yīng)商進(jìn)行 “軟件工具確認(rèn)” ，邀請合格評估機(jī)構(gòu)來對軟件工具進(jìn)行鑒定，并提供證明符合 ASIL-C 乃 ASIL-D 的認(rèn)證證書。在這種情況下，軟件工具的客戶將會得到經(jīng)過認(rèn)證的軟件工具以及一個安全手冊?？蛻糁恍枰獞?yīng)用安全手冊中的指導(dǎo)方針，以證明它的用例與合格的用例是兼容的。

另外一種方式是軟件工具的使用方，按照軟件工具確認(rèn)的方法，自行去尋找合適的評估機(jī)構(gòu)對軟件工具進(jìn)行鑒定，證明工具符合 ASIL-C 或 ASIL-D 等級要求。工具鑒定的方法通常是經(jīng)過認(rèn)證的，工具鑒定的內(nèi)容可以總結(jié)為：

• 指定用例，以定義工具需要滿足的需求

• 選擇適當(dāng)?shù)臏y試來驗(yàn)證這些需求

• 執(zhí)行測試

• 分析測試結(jié)果

• 生成安全文檔

• 應(yīng)用安全文檔中的指導(dǎo)

  
  

后一種方式的缺點(diǎn)是存在相當(dāng)多的隱性成本，例如：學(xué)習(xí)資格認(rèn)證方法和相關(guān)工具，必要的測試套件許可，執(zhí)行工具驗(yàn)證過程，與驗(yàn)證者交互，最后如果測試失敗如何處理。

4.2  信息安全與基礎(chǔ)軟件

4.2.1  相關(guān)標(biāo)準(zhǔn)介紹