摘要

如今，汽車電子嵌入式系統(tǒng)的復(fù)雜性和關(guān)鍵性正不斷提升，軟件開發(fā)領(lǐng)域尤為突出。ISO 26262 功能安全標(biāo)準(zhǔn)是應(yīng)對這些挑戰(zhàn)的重要舉措之一。該標(biāo)準(zhǔn)對開發(fā)過程提出了一系列要求以確保安全性，其中故障注入（FI）被列為評估安全機制有效性和驗證安全需求正確實現(xiàn)的專用技術(shù)。

本文的研究目標(biāo)是開發(fā)一種方法，助力將故障注入以連續(xù)的方式整合到從系統(tǒng)需求到驗證與確認階段的整個開發(fā)流程中。為此，我們探索了各類安全分析方法（如失效模式影響及危害性分析（FMECA）、故障樹分析（FTA）、關(guān)鍵路徑分析（CPA）或無干擾分析（FFI）等）在測試計劃制定、高效故障注入測試用例設(shè)計中的應(yīng)用價值。

本文探討了故障注入在驗證與確認過程中的目標(biāo)和作用，并通過一個基于 AUTOSAR 4.X 的平臺進行實例說明 —— 該平臺集成了一個可信的前燈管理器應(yīng)用（汽車安全完整性等級 - ASIL B）和一個非可信（質(zhì)量管理 - QM）應(yīng)用。所提出的架構(gòu)通過專用安全機制以及時間和空間分區(qū)技術(shù)，確保了安全需求的滿足和無干擾（FFI）特性。最后，本文呈現(xiàn)了在法雷奧 GEEDS 開發(fā)的運行前燈管理器應(yīng)用的原型上獲得的故障注入測試結(jié)果。

為應(yīng)對汽車電氣和電子系統(tǒng)的關(guān)鍵性及日益增長的復(fù)雜性，汽車行業(yè)引入了 ISO 26262 道路車輛功能安全標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)針對開發(fā)過程中應(yīng)采用的各類方法和技術(shù)提出了建議，以確保 “電氣和電子系統(tǒng)的故障行為不會導(dǎo)致不合理的風(fēng)險”。故障注入（FI）是實現(xiàn)安全需求驗證的專用技術(shù)之一。目前，故障注入已成為 ISO 26262 標(biāo)準(zhǔn)中高度推薦的方法（V 模型的不同階段共包含 10 項與故障注入使用相關(guān)的要求），尤其在第 6 部分（軟件開發(fā)）中有著明確規(guī)定。故障注入能夠驗證安全機制的有效性，而這是其他測試方法無法實現(xiàn)的。

1、研究現(xiàn)狀

1.1 ISO 26262 功能安全標(biāo)準(zhǔn)

1.1.1 安全開發(fā)流程

在先前的研究中，我們已探討了在 ISO 26262 標(biāo)準(zhǔn)背景下，將故障注入整合到汽車關(guān)鍵系統(tǒng)開發(fā)早期階段的相關(guān)問題，并論證了如何將故障注入分析結(jié)果整合到失效模式影響及危害性分析（FMECA）表格中。該流程還有助于捕捉架構(gòu)各層級之間的故障傳播路徑。這些分析的價值體現(xiàn)在兩個方面：（i）識別必須集成到系統(tǒng)中的安全機制的性質(zhì)和位置；（ii）為實施后階段的故障注入實驗提供指導(dǎo)。

安全分析中識別的關(guān)鍵路徑顯著提升了安全需求的可追溯性。

1.1.2 確保無干擾（FFI）

如今，汽車系統(tǒng)所用微控制器的處理能力不斷增強，能夠支持更復(fù)雜產(chǎn)品的設(shè)計。特別是在軟件設(shè)計方面，借助這些資源優(yōu)勢，可以在單個微控制器上集成多個應(yīng)用。與此同時，這些系統(tǒng)也嵌入了更多關(guān)鍵功能。當(dāng)集成具有不同關(guān)鍵性等級（即不同汽車安全完整性等級（ASIL））的應(yīng)用時，會出現(xiàn)一個重要的安全問題。根據(jù) ISO 26262 標(biāo)準(zhǔn)，由于這些應(yīng)用之間存在強烈的相互關(guān)聯(lián)，微控制器上的所有模塊都應(yīng)按照微控制器適用的最高 ASIL 等級進行開發(fā)。這一要求的主要弊端在于，較低 ASIL 等級的應(yīng)用需要按照 ISO 26262 標(biāo)準(zhǔn)進行不必要的額外開發(fā)工作 —— 因為較高 ASIL 等級的模塊需要應(yīng)用更多的技術(shù)和方法。

然而，ISO 26262 標(biāo)準(zhǔn)允許集成不同 ASIL 等級的模塊，但要求必須證明已確保無干擾（FFI）。無干擾（FFI）被定義為 “兩個或多個元素之間不存在可能導(dǎo)致安全需求被違反的級聯(lián)失效”。從實際應(yīng)用角度而言，只有在能夠證明質(zhì)量管理（QM）或較低 ASIL 等級的模塊不會直接或間接干擾任何較高 ASIL 等級模塊的行為時，才能對其進行集成。兩個軟件應(yīng)用之間需要考慮的干擾包括：（i）共享數(shù)據(jù)損壞；（ii）應(yīng)用程序接口（API）服務(wù)調(diào)用；（iii）實時行為（調(diào)度、任務(wù)搶占等）；（iv）共享內(nèi)存訪問；（v）共享硬件外設(shè)。

1.2 驗證與確認活動中的故障注入

1.2.1 故障注入技術(shù)

故障注入是一項成熟的技術(shù)，已通過多種技術(shù)在不同目標(biāo)上成功應(yīng)用。

故障注入技術(shù)的發(fā)展由來已久，最初主要用于驗證安全機制（錯誤檢測和恢復(fù)）。失效模型是容錯系統(tǒng)設(shè)計的輸入條件，錯誤檢測和恢復(fù)機制的開發(fā)應(yīng)能高效地處理錯誤。其效率可通過錯誤檢測覆蓋率（EDC）等條件概率指標(biāo)進行評估：當(dāng)注入失效模型中的某一故障時，相應(yīng)的錯誤檢測機制應(yīng)被激活，并在必要時觸發(fā)恢復(fù)機制。其次，故障注入還可用于評估組件（硬件 - HW 或軟件 - SW）在特定故障假設(shè)下的魯棒性。這通常是為了評估內(nèi)置錯誤檢測機制防止違反安全需求的失效模式出現(xiàn)的有效性。此外，ISO 26262 標(biāo)準(zhǔn)中對故障注入的引入，重新激發(fā)了汽車行業(yè)對該領(lǐng)域的關(guān)注。

故障注入通過驗證應(yīng)用程序?qū)碜怨蚕斫M件的系統(tǒng)性或隨機性故障的整體反應(yīng)，補充了其他測試技術(shù)的不足。此外，它還能在系統(tǒng)和產(chǎn)品層面評估隨機性故障（硬件老化、單粒子翻轉(zhuǎn)）和系統(tǒng)性失效（編碼 / 實現(xiàn)錯誤）。在軟件層面，故障注入僅用于驗證所考慮應(yīng)用中是否不存在系統(tǒng)性失效。

1.2.2 FARM 模型

故障注入的核心特征要素包括：待注入故障集（失效模型）、注入故障時的系統(tǒng)活動（激活條件）、實驗結(jié)果的讀取數(shù)據(jù)以及基于讀取數(shù)據(jù)評估的指標(biāo)。這些要素構(gòu)成了執(zhí)行故障注入的 FARM 模型的基礎(chǔ)。FARM 模型能夠有效描述故障注入環(huán)境，本研究將其作為故障注入實驗設(shè)計的參考依據(jù)。

值得注意的是，首先需要定義待評估的指標(biāo)，因為這些指標(biāo)將指導(dǎo)整個故障注入過程。然而，指標(biāo)數(shù)值的評估需在最后一步通過處理讀取數(shù)據(jù)提供的信息來完成。失效模型、系統(tǒng)激活條件和讀取數(shù)據(jù)的定義應(yīng)確保能夠有意義且高效地獲取各項指標(biāo)。

FARM 模型在本文中具有重要意義，所有故障注入實驗均遵循該模型進行設(shè)計。

2、用于驗證與確認的故障注入

前文已闡述了安全分析在識別關(guān)鍵要素和關(guān)鍵傳播路徑方面的重要性。此外，為確保各架構(gòu)層級的安全需求得到滿足，還需識別并實施多種檢測和緩解手段。

本節(jié)將說明安全分析如何助力故障注入測試的設(shè)計。特別是，故障注入通過提供安全機制覆蓋率和關(guān)鍵路徑正確緩解的專用指標(biāo)，能夠驗證安全需求和無干擾（FFI）的實現(xiàn)情況。

關(guān)于驗證與確認活動，ISO 26262 標(biāo)準(zhǔn)的第 4 部分、第 5 部分和第 6 部分均對故障注入提出了要求。本研究重點關(guān)注第 4 部分（系統(tǒng)層面）和第 6 部分（軟件層面）的相關(guān)要求。

2.1 ISO 26262 標(biāo)準(zhǔn)對故障注入的要求

2.1.1 軟件單元測試與軟件集成測試

在這兩個層面，應(yīng)應(yīng)用故障注入以證明軟件單元實現(xiàn)以下目標(biāo)：a) 符合軟件單元設(shè)計規(guī)范；b) 符合軟硬件接口規(guī)范；c) 具備規(guī)定的功能；d) 確保不存在非預(yù)期功能；e) 具備魯棒性；示例：無不可訪問的軟件，錯誤檢測和錯誤處理機制有效。f) 擁有支持其功能所需的充足資源。

在該層面，故障注入（包括通過破壞變量值、引入代碼變異或破壞中央處理器（CPU）寄存器值等方式注入任意故障）至少在所有層級都被推薦使用，對于 ASIL D 等級以及軟件集成測試中的 ASIL C 等級則特別推薦。

此外，ISO 26262 標(biāo)準(zhǔn)要求執(zhí)行 “基于需求的測試”。這意味著必須對為確保任何 ASIL 等級安全需求而確定的所有安全機制進行測試。這些測試的設(shè)計需要采用故障注入技術(shù)。因此，應(yīng)為所有 ASIL 等級執(zhí)行故障注入實驗，以證明不存在非預(yù)期功能或目標(biāo)（軟件單元或軟件架構(gòu)）具備魯棒性。

綜上所述，在系統(tǒng)層面，為驗證安全分析中識別的潛在原因的傳播情況、驗證已實施安全機制的錯誤檢測覆蓋率，所有 ASIL 等級都必須進行故障注入。僅 ASIL D 等級要求注入任意故障，軟件集成測試中的 ASIL C 等級也有此要求。之所以僅對較高等級有此要求，是因為隨著故障注入強度的增加（如隨機故障注入），測試工作量會顯著增大。

2.1.2 系統(tǒng)測試

在 ISO 26262 標(biāo)準(zhǔn)的第 4 部分中，要求在軟硬件集成層面以及產(chǎn)品和系統(tǒng)層面（根據(jù)所選命名方式）應(yīng)用故障注入。

在這些層面，ISO 26262 標(biāo)準(zhǔn)要求故障注入實現(xiàn)以下目標(biāo)：

· 證明安全機制的診斷覆蓋率有效性；

· 證明安全需求的正確實現(xiàn)。

與第 6 部分類似，至少在 ASIL C 等級以下強烈推薦使用故障注入，對于 ASIL B 等級，在軟硬件集成層面特別推薦使用故障注入以證明安全需求的正確實現(xiàn)。此外，為驗證功能和非功能需求，也強烈推薦執(zhí)行基于需求的測試。必須使用故障注入技術(shù)驗證所有 ASIL 等級的安全需求。

2.2 故障注入測試的目標(biāo)與設(shè)計

本節(jié)將探討定義的 FARM 方法在確定故障注入測試目標(biāo)和規(guī)劃測試中的適用性。

2.2.1 實驗?zāi)繕?biāo)定義

借助 ASIL 各層級之間的可追溯性，安全分析有助于識別架構(gòu)中最關(guān)鍵的要素和最關(guān)鍵的傳播路徑。為證明導(dǎo)致安全需求違反的原因已得到緩解，需要對這些關(guān)鍵要素和路徑進行重點驗證。

首先選擇 ASIL 等級最高的對象作為實驗?zāi)繕?biāo)，然后按照關(guān)鍵性遞減的順序選擇其他可能的目標(biāo)。

盡管如此，所選目標(biāo)通常至少需要實施一項安全機制。因此，還需要證明其針對所考慮失效模型的有效性。

2.2.2 待評估指標(biāo)

故障注入主要有兩個目標(biāo)。一方面，驗證安全需求未被違反：確保安全分析中的失效模型不會通過關(guān)鍵路徑傳播并違反安全需求。這可以通過識別失效模式分布來量化（將失效模式與安全需求相關(guān)聯(lián)）。失效模式分布可通過 “餅圖”“柱狀圖” 或 “直方圖” 表示，能夠評估導(dǎo)致安全需求違反的失效發(fā)生率。

另一方面，故障注入用于驗證安全機制的有效性：確保安全分析中的失效模型能夠被安全機制妥善處理。在此，目標(biāo)是根據(jù)分析中識別的失效模型，評估安全機制的錯誤檢測覆蓋率（EDC）和 / 或錯誤恢復(fù)覆蓋率（ERC）。通常，這些結(jié)果通過 “餅圖” 呈現(xiàn)，以直觀展示已覆蓋故障和未覆蓋失效之間的差異。

然而，這些指標(biāo)僅量化了安全機制的有效性和所提出架構(gòu)的容錯能力，以防止非預(yù)期事件（UEs）的發(fā)生。此外，故障注入還能獲得一些定性指標(biāo)。

因此，它有助于識別安全機制的覆蓋率不足問題，特別是針對那些已聲明并用于定量安全分析的 “診斷覆蓋率” 或 “覆蓋因子”。其主要差異在于所考慮的失效模型 —— 因為需要驗證安全機制聲稱要處理的整個失效模型。此外，覆蓋率不足可能導(dǎo)致以下結(jié)果：

· 重新實施安全機制；

· 添加其他機制以緩解特定故障或修改設(shè)計。

最后，在評估故障分布時，可能會發(fā)現(xiàn)實施前階段未識別的失效模式。這主要有兩個原因：一方面，安全分析執(zhí)行不當(dāng)，導(dǎo)致失效模型的故障傳播路徑不正確，或由于設(shè)計復(fù)雜性導(dǎo)致失效模式難以識別；另一方面，功能需求和安全需求的規(guī)范存在錯誤。事實上，如果需求缺失或相互干擾過多，這些故障可能導(dǎo)致意外行為。

這些定性結(jié)果旨在驗證安全分析中所做的假設(shè)和選擇是否合理。

2.2.3 待注入故障

失效模型可從針對每個關(guān)鍵要素或路徑識別的潛在故障原因的安全分析中提取。有兩種可能的故障注入策略：

驗證已識別的失效模式（例如 FMECA 表格中的某一行）是否能被已實施的安全機制正確處理。因此，通過注入導(dǎo)致所考慮失效模式的代表性故障原因，可以激活已識別的安全需求，從而便于測試。

假設(shè)在安全分析中已識別出 “n” 個潛在原因，這些原因能夠激活軟件模塊失效模式（FM）的 “n” 個等價類（EC）。注入這些原因可以驗證安全機制是否能正確緩解軟件模塊的失效模式，或發(fā)現(xiàn)覆蓋率不足的問題。

在此，安全分析會識別出一組潛在原因。實驗包括注入所有可能的原因，以檢查安全分析中識別的傳播路徑是否有效。在這種情況下，必須驗證傳播是否得到了妥善緩解。

在該活動中，策略的選擇與可用故障注入工具提供的故障注入能力無關(guān)。其目標(biāo)僅在于定義為獲得所需指標(biāo)而應(yīng)注入的故障集。

2.2.4 激活模型

激活模型是一組數(shù)據(jù)模式，旨在觸發(fā)注入的故障。一般而言，解決方案是使用目標(biāo)的代表性環(huán)境，以評估目標(biāo)在代表性使用場景中出現(xiàn)故障時的行為。激活模型可根據(jù)目標(biāo)的頻率、關(guān)鍵性等因素進行選擇。

然而，利用目標(biāo)及其環(huán)境動態(tài)的行為模型，可以顯著改進激活集的確定。系統(tǒng)設(shè)計階段開發(fā)的行為模型（如用于描述功能和非功能行為的序列圖、時序圖或用例）在設(shè)計代表性故障注入測試中具有重要意義。基于這些模型，可以確定觸發(fā)注入的時機：（i）基于目標(biāo)組件的狀態(tài)；（ii）基于來自環(huán)境的輸入。

2.2.5 讀取數(shù)據(jù)

獲取讀取數(shù)據(jù)的目的是根據(jù)安全需求驗證和確認系統(tǒng)，并驗證安全機制的有效性（即計算相關(guān)指標(biāo)）。

為定義這些讀取數(shù)據(jù)，建議利用安全分析結(jié)果，特別是 FMECA 表格中的以下列：失效模式、影響（局部影響和對較高架構(gòu)層級的影響）以及描述安全機制的列。

這些列描述了故障傳播的各種影響，因此應(yīng)用于定義必須在目標(biāo)上觀察和采集的變量（物理或數(shù)字變量）。還應(yīng)記錄這些測量點的更多細節(jié)（如狀態(tài)或事件，例如時間戳、變量日志文件）。這組變量 / 狀態(tài)能夠指示：（i）安全機制是否已被觸發(fā)；（ii）錯誤處理是否正確。

然后，基于讀取數(shù)據(jù)，可以建立目標(biāo)狀態(tài)的邏輯表達式（或安全屬性），以檢測安全需求何時被違反。

對讀取數(shù)據(jù)的分析有助于評估過程初期定義的指標(biāo)。然而，結(jié)果可能存在模糊性，需要進行深入分析。這些實驗可分為四類（見表 1）。此處的實驗是在至少實施了一項防止安全需求違反的安全機制的目標(biāo)上進行的。該表格忽略了未被激活的故障（通常屬于 “無觀察結(jié)果” 類別）。

表 1、讀取數(shù)據(jù)分析

預(yù)期行為（類別 α）是在故障存在時激活安全機制，防止安全需求被違反。這種行為應(yīng)具有最高的概率。顯然，在其他所有情況下，需要借助實驗的詳細執(zhí)行軌跡對安全機制進行深入分析。類別 β 對應(yīng)已實施安全機制的覆蓋率不足；類別 γ 通常意味著設(shè)計或?qū)崿F(xiàn)存在問題（因為安全機制未被激活）；類別 δ 的可能原因包括故障注入實驗本身的缺陷：（i）錯誤仍處于潛伏狀態(tài)，未被測試場景激活；（ii）故障已被其他機制或設(shè)計（如在使用前重新初始化被注入損壞的數(shù)據(jù)）所容忍。

然而，在傳統(tǒng)的故障注入活動中，輸出結(jié)果通常是由上述類別組成的餅圖。理想情況下，100% 的錯誤都能被檢測和恢復(fù)，從而確保安全需求不被違反。但在實際情況中，部分錯誤可能無法被內(nèi)部錯誤檢測機制檢測到或無法恢復(fù)。此時，高層級的安全機制應(yīng)防止安全需求被違反。

綜上所述，安全分析檢查 / 推薦應(yīng)實施的安全機制，而故障注入測試量化這些機制的效率（即檢測和恢復(fù)覆蓋率）。由于安全機制可以防止非預(yù)期事件（UEs）的發(fā)生，因此能夠驗證安全需求是否得到滿足或無干擾（FFI）是否得到確保。

當(dāng)安全屬性被違反時，結(jié)論主要有兩點：（i）安全機制的覆蓋率不足，應(yīng)分析該機制的實現(xiàn)以必要時提高覆蓋率；（ii）缺少安全機制，因此需要修訂設(shè)計。

3、案例研究描述：前燈系統(tǒng)

本文通過一個前燈系統(tǒng)對所提出的方法進行說明。該電子系統(tǒng)控制汽車的兩個前燈。

作者認為這是一個非常簡單的系統(tǒng)，其安全關(guān)鍵性等級適中（ASIL B）。在該等級下，ISO 26262 標(biāo)準(zhǔn)并未 “強烈推薦” 所有與故障注入相關(guān)的要求。

然而，仍可對所提出的方法進行 “概念驗證”。

為了說明軟件架構(gòu)的背景，本節(jié)首先描述系統(tǒng)層面和產(chǎn)品層面的相關(guān)內(nèi)容。實際上，故障注入測試的目標(biāo)是基于較高架構(gòu)層級的假設(shè)和分析確定的。這有助于實現(xiàn)需求的可追溯性，從而識別高效的故障注入測試用例。測試的主要目標(biāo)是軟件架構(gòu)和看門狗管理器（WdgM）。

本節(jié)旨在為該架構(gòu)的驗證與確認奠定基礎(chǔ)。

3.1 系統(tǒng)和產(chǎn)品架構(gòu)層面的描述

前燈系統(tǒng)有兩個系統(tǒng)功能需求：

· 前燈系統(tǒng)必須根據(jù)駕駛員的請求照亮道路；

· 前燈系統(tǒng)必須設(shè)置儀表盤燈光指示器。

初步危害分析（PHA）識別出兩個非預(yù)期事件（UEs）（見表 2）。這兩個與安全相關(guān)的非預(yù)期事件（UE01 和 UE02）均被評定為 ASIL B 等級。

表 2、初步危害分析（PHA）中的非預(yù)期事件（UEs）及其 ASIL 等級

因此，可以定義兩個安全需求（稱為安全目標(biāo)（SG））。根據(jù)初步危害分析（PHA），為每個安全目標(biāo)分配了相應(yīng)的 ASIL 等級。

SG1：系統(tǒng)不得無故關(guān)閉兩個前燈（ASIL B）SG2：系統(tǒng)應(yīng)防止前燈閃爍（ASIL B）

需要說明的是，定量分析不在本研究的范圍內(nèi)。

圖 1、前燈系統(tǒng)架構(gòu)

3.2 系統(tǒng)架構(gòu)層面的描述

系統(tǒng)架構(gòu)如圖 1 所示。核心產(chǎn)品是前燈電子控制單元（ECU），其通過收集點火開關(guān) ECU 和燈光開關(guān) ECU 的信息，控制前燈的開啟 / 關(guān)閉并點亮儀表盤指示器。當(dāng)前燈開關(guān)狀態(tài)和點火開關(guān)狀態(tài)均為開啟時，前燈 ECU 必須點亮汽車的兩個前燈和儀表盤指示器。

所有產(chǎn)品功能需求匯總于表 3。

表 3、前燈系統(tǒng)功能描述（重點關(guān)注前燈 ECU）

隨后，執(zhí)行了失效模式影響及危害性分析（FMECA），以識別可能導(dǎo)致安全目標(biāo)（SGs）被違反的失效模式（前燈 ECU 的兩個失效模式見表 4）。FMECA 還能夠為產(chǎn)品分配 ASIL 等級并定義系統(tǒng)安全機制。

表 4、FMECA 中識別的導(dǎo)致安全目標(biāo)違反的前燈 ECU 失效模式

3.3 產(chǎn)品層面的信息

在該層面，僅考慮運行軟件應(yīng)用的微控制器，因此不詳細描述電子卡的設(shè)計和所選解決方案。

產(chǎn)品層面的輸入和輸出鏈路與系統(tǒng)層面類似，未新增相關(guān)失效模式。特別是，表 4 中定義的兩個產(chǎn)品級非預(yù)期事件（P-UEs）也可視為兩個軟件級非預(yù)期事件（SW-UE01 和 SW-UE02）。

然而，需要考慮微控制器的以下失效模式：硬件失效以及微控制器上運行的應(yīng)用之間的無干擾（FFI）問題。

3.3.1 硬件平臺

Leopard SPC56EL70 微控制器基于 PowerPC 架構(gòu)，包含兩個相同的處理器（e200z4d 內(nèi)核），并連接到一個共享主內(nèi)存。該微控制器可配置為鎖步模式或解耦模式。

在鎖步模式下，兩個內(nèi)核執(zhí)行相同的指令并比較結(jié)果。這種模式通過對瞬態(tài)硬件失效提供容錯能力，確保關(guān)鍵功能（如 ASIL C 和 D 等級）的安全性。解耦模式允許每個內(nèi)核執(zhí)行不同的指令，從而并行執(zhí)行多個任務(wù)。該模式提供的資源可用于提升應(yīng)用性能和 / 或?qū)嵤┌踩珯C制。

該微控制器符合 ISO 26262 第 10 章中關(guān)于脫離上下文的安全元素（SEooC）的安全要求，滿足 ASIL D 等級的需求。

3.3.2 無干擾（FFI）分析

通過分析干擾通道，無干擾（FFI）分析可能識別出導(dǎo)致較高 ASIL 等級應(yīng)用故障的多種原因。這些已識別的原因還需要緩解手段（即定義安全機制），以防止安全目標(biāo)被違反。

簡而言之，微控制器上分配了兩個具有不同關(guān)鍵性等級的應(yīng)用：一個 ASIL B 等級應(yīng)用和一個 QM 等級應(yīng)用，分別對應(yīng)功能 FL-ECU_F01 和 FL-ECU_F02。

在實際應(yīng)用中，QM 等級應(yīng)用不得通過以下通道干擾 ASIL B 等級應(yīng)用：

1. 實時行為干擾：例如，QM 等級應(yīng)用的錯誤執(zhí)行（執(zhí)行時間過長、周期錯誤）；

2. 服務(wù)調(diào)用干擾：例如，QM 等級應(yīng)用向 ASIL B 等級應(yīng)用提供錯誤輸入；

3. 共享數(shù)據(jù)干擾：例如，QM 等級應(yīng)用損壞 ASIL B 等級應(yīng)用的關(guān)鍵數(shù)據(jù)；

4. 共享內(nèi)存干擾：例如，QM 等級應(yīng)用通過共享內(nèi)存（ROM、RAM、堆棧）損壞關(guān)鍵數(shù)據(jù)。

這些干擾均可定義為軟件級非預(yù)期事件（SW-UEs），分別標(biāo)記為 SW-UE03 至 SW-UE06。由于這些非預(yù)期事件的發(fā)生可能導(dǎo)致 SG1 或 SG2 被違反，因此均被評定為 ASIL B 等級。

為提供一個允許軟件組件無意外干擾執(zhí)行的運行環(huán)境，需要對計算和通信資源進行時間和空間分區(qū)。

· 空間分區(qū)：確保一個軟件組件無法修改另一個軟件組件的代碼或私有數(shù)據(jù)，同時防止軟件組件干擾其他軟件組件對外部設(shè)備（如執(zhí)行器）的控制。

· 時間分區(qū)：確保一個軟件組件不會影響其他軟件組件訪問共享資源（如公共網(wǎng)絡(luò)或共享 CPU）的能力，包括資源提供服務(wù)的時間行為（延遲、抖動、調(diào)度訪問期間的可用時長）。

3.4 軟件架構(gòu)描述

3.4.1 AUTOSAR：汽車開放系統(tǒng)架構(gòu)

AUTOSAR是由主要原始設(shè)備制造商（OEMs）和供應(yīng)商聯(lián)合開發(fā)的汽車電子 / 電氣（E/E）軟件架構(gòu)標(biāo)準(zhǔn)，是汽車行業(yè)軟件開發(fā)的重要組成部分。

AUTOSAR 倡導(dǎo)基于應(yīng)用的汽車軟件開發(fā)方法，而非基于電子控制單元（ECU）的方法。因此，只要應(yīng)用遵循指定的流程并使用提供的接口，就能實現(xiàn)平臺無關(guān)性。AUTOSAR 架構(gòu)主要包括應(yīng)用層（由軟件組件（SWC）組成）、運行時環(huán)境（RTE）和基礎(chǔ)軟件（BSW）。

基礎(chǔ)軟件（BSW）由三個主要層級組成：服務(wù)層、ECU 抽象層和微控制器層。

這些層級進一步分解為五個棧（每個棧跨層級）：服務(wù)棧、內(nèi)存棧、通信棧、輸入 / 輸出硬件抽象棧和復(fù)雜設(shè)備驅(qū)動棧。

為實現(xiàn)無干擾（FFI）的分區(qū)要求，使用了以下 AUTOSAR 概念和模塊：

· OS - 應(yīng)用程序：AUTOSAR-OS 允許將不同的 OS 對象（任務(wù)、中斷服務(wù)程序（ISRs）、警報等）分組為所謂的 OS - 應(yīng)用程序。同一 OS - 應(yīng)用程序內(nèi)的所有對象共享其內(nèi)存保護方案和訪問權(quán)限。

根據(jù) AUTOSAR-OS 規(guī)范，OS - 應(yīng)用程序可分為可信和非可信兩類。可信 OS - 應(yīng)用程序允許在 CPU 管理模式下無限制運行，而非可信 OS - 應(yīng)用程序則在 CPU 用戶模式下運行，對 OS 和硬件資源的訪問受到限制。

· MMU/MPU：OS 應(yīng)滿足的基本內(nèi)存保護要求是保護 OS - 應(yīng)用程序的數(shù)據(jù)、代碼和堆棧段。在 AUTOSAR OS 標(biāo)準(zhǔn)中，這種保護在非可信 OS - 應(yīng)用程序執(zhí)行期間激活，以防止可信 OS - 應(yīng)用程序的內(nèi)存段被損壞。此外，如有必要，還可用于保護同一 OS - 應(yīng)用程序內(nèi)的私有數(shù)據(jù)和堆棧。

內(nèi)存保護需要微控制器具備內(nèi)存管理單元（MMU）和 / 或內(nèi)存保護單元（MPU）的硬件支持。

· AUTOSAR OS - 應(yīng)用程序間通信器（IOC）：兩個 OS - 應(yīng)用程序之間的通信也需要受到保護。實際上，OS - 應(yīng)用程序旨在創(chuàng)建內(nèi)存保護邊界，因此需要專用的通信機制來跨越這些邊界。此功能在 AUTOSAR-OS 中實現(xiàn)，稱為 IOC（OS - 應(yīng)用程序間通信器）。它是 OS - 應(yīng)用程序之間的專用通信手段，無論 OS - 應(yīng)用程序是否分配到同一個內(nèi)核（通信可發(fā)生在同一內(nèi)核上的兩個 OS - 應(yīng)用程序之間，或多核架構(gòu)中分配到不同內(nèi)核的 OS - 應(yīng)用程序之間）。其主要功能是通過緩沖區(qū)確保傳輸消息的完整性，這些消息可以是數(shù)據(jù)結(jié)構(gòu)或通知（如任務(wù)激活、回調(diào)等）。

3.4.2 前燈管理器的軟件架構(gòu)

該軟件架構(gòu)相對簡單，全部由一個基于微控制器最高 ASIL 等級（即 ASIL B）開發(fā)的 AUTOSAR-OS 控制。

如無干擾（FFI）分析中所定義，系統(tǒng)包含兩個 OS - 應(yīng)用程序。可信 OS - 應(yīng)用程序管理安全關(guān)鍵功能（ASIL B），包括：四個軟件組件（開關(guān)事件、燈光請求、前燈管理器和前燈）、一個可信運行時環(huán)境（RTE）、系統(tǒng)服務(wù)（BSWM、WdgM）、輸入 / 輸出硬件抽象棧、IOC 和端到端（E2E）保護（用于解除燈光開關(guān)狀態(tài)的保護）。該 OS - 應(yīng)用程序運行軟件組件的關(guān)鍵可運行實體，其目的是收集燈光開關(guān)和點火開關(guān)的信息，并處理儀表盤指示器和前燈的狀態(tài)。

此外，非可信 OS - 應(yīng)用程序由兩個軟件組件（ComStackDemoApp 和另一個應(yīng)用程序 SystackDemoApp）、一個非可信運行時環(huán)境（RTE）以及用于 CAN 傳輸和接收的通信棧組成。

端到端（E2E）保護是設(shè)計中的一個重要環(huán)節(jié)。來自點火開關(guān)的信號屬于 ASIL B 等級，但該信號由 QM 等級 OS - 應(yīng)用程序的模塊處理。端到端（E2E）保護可防止 QM 等級應(yīng)用程序造成的數(shù)據(jù)損壞，并確保關(guān)鍵路徑上 ASIL B 等級的需求得到滿足。

對圖 2 中描述的架構(gòu)執(zhí)行了軟件失效模式影響及危害性分析（FMECA），以詳細說明軟件架構(gòu)上的故障傳播路徑。表 5 給出了完整表格中的一個示例行。需要說明的是，完整表格包含 116 行失效模式，所考慮的失效模式包括時序錯誤（如任務(wù)周期過快或過慢、調(diào)度錯誤、執(zhí)行超時）、數(shù)據(jù)錯誤（數(shù)據(jù)損壞：超出范圍、有效錯誤或數(shù)據(jù)丟失）、函數(shù)調(diào)用錯誤（函數(shù)未被調(diào)用、函數(shù)調(diào)用參數(shù)錯誤）。

圖 2、前燈管理器的軟件架構(gòu)

表 5、對圖2中描述的軟件架構(gòu)執(zhí)行的軟件 FMECA 中的一行示例

已識別出用于處理軟件模塊失效模式的安全機制。配置了看門狗管理器（WdgM）的三個活性監(jiān)控，以確保關(guān)鍵軟件組件仍在執(zhí)行。同時，還監(jiān)控 ComStackDemoApp 和 CAN 棧的活性，以防止對提供給燈光請求的點火開關(guān)狀態(tài)造成干擾。實施了控制流和截止時間監(jiān)控，以監(jiān)控 ASIL B 等級軟件組件的執(zhí)行。

在該應(yīng)用中，關(guān)鍵路徑上多個模塊提供的有效錯誤可能無法被檢測到，從而導(dǎo)致安全需求被違反。由于這種情況發(fā)生的概率極低，因此其覆蓋率不足問題未被重視，可通過重新設(shè)計安全機制來解決。

3.4.3 聚焦一項軟件安全機制：看門狗管理器（WdgM）

在提出的安全機制中，我們特意選擇聚焦于看門狗管理器（WdgM）（表 5 中識別的機制）。

看門狗管理器（WdgM）模塊是基于 AUTOSAR 架構(gòu)的關(guān)鍵軟件模塊，用于確保應(yīng)用程序的安全運行，檢測時序和邏輯約束的違反。WdgM 屬于系統(tǒng)服務(wù)層，負責(zé)錯誤檢測、隔離和恢復(fù)。它提供三種監(jiān)控機制：活性監(jiān)控、截止時間監(jiān)控和控制流監(jiān)控；以及四種錯誤響應(yīng)：向其他 AUTOSAR 模塊發(fā)送錯誤信號、將錯誤記錄到診斷事件管理器或開發(fā)錯誤跟蹤器模塊、分區(qū)復(fù)位（重啟特定 OS - 應(yīng)用程序）和微控制器復(fù)位。WdgM 通過監(jiān)控所謂的受監(jiān)控實體（SE）來監(jiān)督軟件的執(zhí)行。這些受監(jiān)控實體（SE）與 AUTOSAR 中的架構(gòu)構(gòu)建塊（如軟件組件（SWC）、復(fù)雜設(shè)備驅(qū)動（CDD）、運行時環(huán)境（RTE）、基礎(chǔ)軟件（BSW）模塊等）沒有固定關(guān)系。

在每個受監(jiān)控實體（SE）中，可以定義多種監(jiān)控（活性、截止時間、控制流）。每個受監(jiān)控實體（SE）通過檢查點及其之間的轉(zhuǎn)換來定義，形成一個受監(jiān)控實體（SE）的圖，其中檢查點對應(yīng)圖的狀態(tài)。一個圖可能有一個或多個初始檢查點和一個或多個最終檢查點。這些圖在 WdgM 配置期間靜態(tài)定義。

在運行時，受監(jiān)控實體（SE）到達檢查點時會調(diào)用 WdgM API。然后，WdgM 驗證接收到的檢查點序列（從任何初始檢查點開始，到任何最終檢查點結(jié)束）是否正確。

具體而言，活性監(jiān)控通過受監(jiān)控實體調(diào)用一個檢查點來實現(xiàn)。WdgM 定期檢查該檢查點是否在給定范圍內(nèi)到達（既不過于頻繁也不過于稀疏）。截止時間監(jiān)控檢查受監(jiān)控實體（SE）兩個檢查點之間的時序轉(zhuǎn)換。最后，邏輯監(jiān)控確保受監(jiān)控實體（SE）的圖正確執(zhí)行。

因此，每次受監(jiān)控實體（SE）報告新的檢查點時，WdgM 必須驗證前一個檢查點和報告的檢查點之間是否配置了轉(zhuǎn)換。

首先實現(xiàn)了一個符合 AUTOSAR 需求的版本（QM 版本）。然后，將該模塊視為脫離上下文的安全元素（SEooC）進行安全分析。

該模塊的失效模式主要有兩類：（i）誤報：WdgM 意外觸發(fā)重新配置（發(fā)送錯誤信號、記錄錯誤、復(fù)位目標(biāo)等）；（ii）漏報：錯誤檢測或管理的覆蓋率不足，即 WdgM 未檢測到錯誤行為。

安全分析突顯了 WdgM 實現(xiàn)中的一個缺陷：部分錯誤可能無法被檢測到。

· 截止時間錯誤：截止時間違反可能未被檢測到，或檢測過晚。實際上，如果未收到最終檢查點，則不會檢測到任何錯誤。

· 控制流錯誤：如果應(yīng)用程序在控制流圖中間停止發(fā)送檢查點，則 WdgM 不會檢測到任何錯誤，盡管該圖未完成。

此外，安全分析還揭示了導(dǎo)致 WdgM 失效模式的多種潛在原因，并定義了緩解這些原因的安全機制。例如，之前使用一個全局變量存儲 WdgM 的狀態(tài)，該數(shù)據(jù)的損壞可能導(dǎo)致失效模式的發(fā)生，具有關(guān)鍵性。為防止這種情況，決定在內(nèi)存中三重存儲該變量的值，以避免 WdgM 設(shè)計中的單點錯誤。這種安全機制通過多數(shù)投票來屏蔽其中一個副本中的錯誤。

為處理這些情況，實現(xiàn)了 WdgM 的第二個版本（“安全版本”），該版本實現(xiàn)了安全分析識別的需求。

4、案例研究的概念驗證

本節(jié)將說明故障注入測試計劃，并描述和分析這些測試的結(jié)果。測試聚焦于表 5 中描述的軟件失效模式影響及危害性分析（FMECA）行。該行定義了兩個注入目標(biāo)：首先，所考慮失效模式的傳播可能違反無干擾（FFI），并可能導(dǎo)致安全目標(biāo) SG1 或 SG2 被違反；其次，該行還將 WdgM 識別為緩解關(guān)鍵路徑的手段，從而確保無干擾（FFI）和安全需求的滿足。

盡管在整個案例研究中沒有明確顯示和說明，但所有故障注入實驗均遵循 FARM 模型進行設(shè)計。

4.1 故障注入目標(biāo)

4.1.1 關(guān)鍵路徑驗證

實驗?zāi)繕?biāo)如下：“ComStackDemoApp 必須通過非可信運行時環(huán)境（RTE）定期（10 毫秒）從 COM 模塊讀取點火開關(guān)位置”。失效模式 “周期過慢” 可能通過提供錯誤的點火開關(guān)位置，對 ASIL B 等級的燈光請求軟件組件（SWC）造成干擾。ComStackDemoApp 可能干擾前燈管理器的關(guān)鍵應(yīng)用程序，最終可能在系統(tǒng)層面違反安全目標(biāo) SG1 和 / 或 SG2。

為驗證安全需求，注入失效模式的潛在原因應(yīng)能證明對關(guān)鍵應(yīng)用程序輸出無影響，且 WdgM 能夠正確檢測和處理該失效。

因此，應(yīng)定義失效模型以模擬失效模式 “周期過慢” 的發(fā)生。需要確定該失效模式的原因，一個簡單的例子是終止負責(zé)執(zhí)行該功能的任務(wù)。

然而，為考慮更多失效模式變體，決定測試該功能的不同周期值。在正常行為下，可運行實體的周期為 10 毫秒。測試的周期值范圍為 20 毫秒至 100 毫秒，步長為 10 毫秒。

從激活模型來看，很容易發(fā)現(xiàn)有兩個用例可能導(dǎo)致安全目標(biāo)被違反。實際上，當(dāng) ComStackDemoApp 無法向 IOC 提供點火開關(guān)的新值時，該失效模式具有關(guān)鍵性。

一方面，應(yīng)在前燈已開啟時注入錯誤。在這種情況下，前燈可能閃爍或關(guān)閉。另一方面，對應(yīng)的用例是前燈關(guān)閉、燈光開關(guān)已開啟，且通過 CAN 接收到點火開關(guān)命令。在這種情況下，如果 ComStackDemoApp 的周期過長，前燈可能會延遲點亮。圖 3 展示了周期暫時加倍時的第二個用例。

圖 3、前燈激活的簡化序列圖

分析實驗結(jié)果需要以下讀取數(shù)據(jù)：表 5 中的局部影響 “使用錯誤的點火開關(guān)位置” 應(yīng)在燈光請求軟件組件（SWC）中進行監(jiān)控，同時監(jiān)控前燈狀態(tài)。此外，還應(yīng)監(jiān)控 WdgM 以驗證其是否檢測并處理了該錯誤。最后，如果安全機制有效，前燈將開啟；否則，前燈將保持關(guān)閉。

4.1.2 安全機制

在前面提出了一種安全機制來處理該失效模式：使用 WdgM 的活性監(jiān)控來檢測故障，首先復(fù)位應(yīng)用程序，如果錯誤未得到糾正，則將系統(tǒng)置于安全模式（兩個前燈始終保持開啟）。如前所述，故障注入還應(yīng)用于評估 WdgM 的覆蓋率有效性（其分配的 ASIL 等級與關(guān)鍵應(yīng)用程序相同：ASIL B）。

預(yù)期的主要指標(biāo)是 WdgM 的錯誤檢測覆蓋率（EDC）和錯誤恢復(fù)覆蓋率（ERC）。還應(yīng)評估 WdgM 實現(xiàn)的魯棒性 —— 在這種情況下，評估 WdgM 的內(nèi)存（RAM/ROM/ 堆棧）被損壞時的行為。這可以評估代碼質(zhì)量，并發(fā)現(xiàn)潛在的弱點。在 WdgM 案例研究中，已發(fā)現(xiàn)導(dǎo)致誤報和漏報的錯誤。

最后，相同的方法可應(yīng)用于失效模式影響及危害性分析（FMECA）的每一行，或通過分析識別的關(guān)鍵路徑。

4.2 測試平臺描述

從實際應(yīng)用角度而言，法雷奧 GEEDS 開發(fā)的故障注入工具提供了實施故障注入所需的所有功能。該平臺采用兩種故障注入技術(shù)：軟件實現(xiàn)故障注入（SWIFI）和基于 Nexus 的故障注入。軟件實現(xiàn)故障注入（SWIFI）基于修改應(yīng)用程序的源代碼；基于 Nexus 的故障注入利用部分微控制器的片上調(diào)試功能訪問內(nèi)存并損壞數(shù)據(jù)。

圖 4 展示了故障注入工具鏈的概述，包括：目標(biāo)、控制器、源代碼和基于 Eclipse 的應(yīng)用程序。目標(biāo)是運行在前面描述的 SPC56EL70 微控制器上的前燈管理器應(yīng)用程序（二進制文件）。

圖 4、故障注入工具鏈概述

控制器由 Lauterbach 調(diào)試器組成，通過 Nexus 探針連接到微控制器。該調(diào)試器能夠訪問微控制器的所有內(nèi)存段，特別是通過監(jiān)控應(yīng)用程序的執(zhí)行軌跡。它還可作為故障注入器，允許損壞 / 修改內(nèi)存（可在應(yīng)用程序執(zhí)行期間實時進行）。該調(diào)試器實現(xiàn)了 Nexus 5001 論壇?定義的 Nexus Class 3 + 標(biāo)準(zhǔn)。這類調(diào)試器提供兩項重要功能，可在不影響應(yīng)用程序?qū)崟r執(zhí)行的情況下進行故障注入：“實時” 運行時內(nèi)存訪問和片上觀察點。觀察點能夠觸發(fā)故障注入或發(fā)出應(yīng)用程序事件信號，而無需停止應(yīng)用程序。“實時” 內(nèi)存訪問功能解決了在不增加時間開銷的情況下寫入或讀取內(nèi)存的問題。

調(diào)試器由 Trace32 軟件解釋的腳本文件（PRACTICE 語言）控制，該軟件與探針進行交互。

源代碼通過 Wind River 編譯生成.elf 文件（二進制文件），然后燒錄到微控制器中。軟件實現(xiàn)故障注入（SWIFI）可通過修改應(yīng)用程序源代碼的一部分來實現(xiàn)，修改后的源代碼經(jīng)編譯后在微控制器上執(zhí)行。基于 Eclipse 的應(yīng)用程序能夠自動為平臺上執(zhí)行的所有測試生成報告。該應(yīng)用程序的輸入是故障注入測試用例描述和故障注入測試日志（讀取數(shù)據(jù)）。

4.3 測試設(shè)置

首先，假設(shè)微控制器和內(nèi)存通過直接在微控制器電路中實施的錯誤檢測和糾正機制，能夠有效抵御隨機故障。

其次，為防止其他損壞，任何故障注入實驗之前的首要操作是將應(yīng)用程序燒錄到目標(biāo)中。這一步驟會加載應(yīng)用程序，并驗證加載的應(yīng)用程序是否未被損壞。

此外，故障注入測試用例主要針對內(nèi)存中靜態(tài)定義的全局變量。因此，在實驗期間可以有效控制這些變量的值。

4.4 關(guān)鍵路徑上獲得的結(jié)果

假設(shè)點亮前燈的響應(yīng)時間必須小于 600 毫秒。應(yīng)用程序必須在該時間內(nèi)達到預(yù)期狀態(tài)（在所考慮的用例中為前燈開啟）。

針對所考慮的關(guān)鍵路徑執(zhí)行了 18 個測試用例：每個用例 9 個。結(jié)果可分為以下幾類：

· 容忍錯誤：WdgM 未檢測到錯誤（根據(jù)其配置），即使周期部分降級（輸出刷新頻率低于規(guī)定值），系統(tǒng)仍能正常運行。[周期 = 20 毫秒]

· 檢測并容忍錯誤：WdgM 檢測到錯誤，但未執(zhí)行任何恢復(fù)操作。系統(tǒng)在降級模式下運行（輸出刷新頻率低于規(guī)定值）。[周期 = 30 毫秒或 40 毫秒]

· 檢測并恢復(fù)錯誤：在這些情況下，WdgM 檢測到活性錯誤，并啟動微控制器復(fù)位。在第一個用例中，前燈會閃爍（復(fù)位期間關(guān)閉 37 毫秒），然后系統(tǒng)恢復(fù)正常運行（前燈開啟）；在第二個用例中，從注入錯誤和接收到點火開關(guān)命令到系統(tǒng)切換狀態(tài)的最長時間為 220 毫秒（對應(yīng) WdgM 檢測錯誤和應(yīng)用程序復(fù)位的時間）。

測試結(jié)果的定性分析（即評估測試的讀取數(shù)據(jù)）可能具有挑戰(zhàn)性。由于外部環(huán)境的復(fù)雜性，應(yīng)用程序的行為可能難以評估。然而，在前燈管理器的案例中，復(fù)雜性較低。結(jié)果定性分析可通過觀察已識別的輸出信號（如前燈狀態(tài)）或選定的參數(shù)（檢測標(biāo)志）或異常來完成。

所有測試均可歸類為表 1 中的 α 類和 δ 類，未出現(xiàn)違反 SG1 或 SG2 的情況。

綜上所述，已實施的應(yīng)用程序能夠滿足需求，安全機制在響應(yīng)時間內(nèi)正確處理故障行為。在最壞情況下，即使發(fā)生失效模式，復(fù)位也能快速觸發(fā)，不會被察覺。單一故障不足以單獨違反安全目標(biāo)，已實施的安全機制足以處理表 5 中所考慮的失效模式。

之后，應(yīng)對失效模式影響及危害性分析（FMECA）中識別的每個失效模式執(zhí)行相同的方法。

4.5 看門狗管理器（WdgM）上獲得的結(jié)果

4.5.1 兩個 WdgM 實現(xiàn)的錯誤檢測覆蓋率評估

對前面描述的 WdgM 實現(xiàn)進行了測試，以評估其檢測和恢復(fù)活性 / 截止時間 / 控制流錯誤的有效性。換句話說，這些測試旨在驗證 WdgM 實現(xiàn)集成后是否滿足其功能規(guī)范，并衡量兩個版本之間的改進。

在此，所考慮的失效模型為：（i）軟件組件（SWC）向 WdgM 發(fā)送錯誤的檢查點；（ii）檢查點的發(fā)送具有錯誤的時序行為。

為執(zhí)行測試，每個監(jiān)控都配置了兩個實例：一個實例在測試使用的模式下啟用，另一個實例在應(yīng)用程序使用的模式下禁用。這能夠驗證未配置的檢查點、已配置但未激活的檢查點和已激活的檢查點。共有 2562 種可能的檢查點：256 個受監(jiān)控實體，每個實體有 256 個檢查點。已實施的配置包括兩個活性監(jiān)控檢查點、兩個控制流監(jiān)控（每個有 6 個檢查點和 6 個轉(zhuǎn)換）以及兩個截止時間監(jiān)控（每個有 2 個檢查點）。

為注入故障，設(shè)計了一個軟件組件（SWC），用于模擬檢查點的所有可能行為。然后，監(jiān)控 WdgM 的內(nèi)部變量和微控制器的復(fù)位情況。這些變量有助于驗證是否已檢測到預(yù)期的監(jiān)控錯誤，微控制器復(fù)位則能驗證錯誤是否已被恢復(fù)。

獲得的結(jié)果如圖 5 所示。

圖 5、兩個 WdgM 實現(xiàn)針對相同失效模型的有效性（104 個測試用例）

可以觀察到，QM 版本檢測并恢復(fù)了 94% 的測試用例（表 1 中的 α 類和 β 類）。該范圍包括兩個類別：

· 檢測并容忍錯誤：錯誤被檢測到，但無需復(fù)位微控制器。這對應(yīng)于調(diào)用未配置檢查點的測試。在這種情況下，WdgM 返回發(fā)生錯誤，但不執(zhí)行任何恢復(fù)操作。

· 檢測并復(fù)位目標(biāo)的錯誤：錯誤被檢測到，WdgM 重啟微控制器。

6% 的 “無觀察結(jié)果”（即 WdgM 未檢測到任何錯誤）與安全分析中識別的情況完全一致（表 1 中的 γ 類和 δ 類）。結(jié)果表明，這些情況已通過安全版本得到處理。此處的故障注入測試提高了對 WdgM 新實現(xiàn)所處理的錯誤檢測覆蓋率的信心。

考慮到表 5 中關(guān)鍵路徑的驗證，這些結(jié)果表明兩個實現(xiàn)在活性監(jiān)控方面沒有差異。因此，兩者均可用于處理該失效模式。

4.5.2 WdgM 實現(xiàn)的魯棒性

然而，驗證 WdgM 實現(xiàn)的魯棒性也同樣重要。實際上，需要評估 WdgM 抵御來自硬件失效（內(nèi)存 / 寄存器中的位翻轉(zhuǎn)）/ 實時故障的干擾的能力。

這一評估至關(guān)重要，因為 WdgM 是一個現(xiàn)成組件（COTS），需要具備魯棒的實現(xiàn)才能實現(xiàn)復(fù)用。

值得注意的是，WdgM 上的干擾可能不會直接影響系統(tǒng)安全（其故障表現(xiàn)為導(dǎo)致復(fù)位的誤報），但干擾可能與二階割集相關(guān)聯(lián)，具有安全相關(guān)性。在這種情況下，應(yīng)用程序錯誤可能被掩蓋（未檢測到截止時間 / 活性 / 控制流錯誤），從而可能導(dǎo)致安全目標(biāo)被違反。

這些測試所用的失效模型是 WdgM 變量的損壞。基于對 WdgM 執(zhí)行的安全分析，識別出了這些變量。如果這些變量被損壞，可能導(dǎo)致 WdgM 失效模式。

已識別出兩個激活用例。第一個用例中，注入故障旨在產(chǎn)生誤報，因此在注入故障時應(yīng)用程序處于正常模式；第二個用例旨在展示 WdgM 損壞可能掩蓋錯誤，在此需要模擬活性、截止時間和控制流錯誤，且 WdgM 錯誤（變量損壞）的激活先于活性 / 截止時間 / 控制流錯誤。

對于這些測試，已識別的關(guān)鍵路徑和所有需求均可作為測試用例的判定標(biāo)準(zhǔn)。然后，利用調(diào)試器的片上觀察點，監(jiān)控關(guān)鍵路徑上的多個變量和函數(shù)調(diào)用。通常，這些是存儲 WdgM 錯誤檢測結(jié)果的標(biāo)志 / 變量、恢復(fù)操作的調(diào)用以及復(fù)位的發(fā)生情況。其目標(biāo)是驗證重新配置是否由 WdgM 引起，以及是否檢測到了正確的錯誤。

圖 6 展示了這些測試獲得的餅圖。結(jié)果分類如下：

· “未觀察到偏差”：注入故障后，WdgM 的行為與無故障時相同。例如，損壞的變量被刷新為正確值。（表 1 中的 α 類和 δ 類）。

· “觀察到暫時性內(nèi)部偏差”：錯誤發(fā)生傳播，但在達到 WdgM 失效模式之前被容忍。（表 1 中的 α 類和 δ 類）。

· “內(nèi)部潛伏錯誤”：未達到 WdgM 失效模式，但損壞或錯誤傳播仍處于潛伏狀態(tài)，未被目標(biāo)的激活所觸發(fā)。（表 1 中的 α 類和 δ 類）。這些實驗對應(yīng)于 WdgM 內(nèi)存中未被激活的故障注入損壞，在測試結(jié)束（超時）時仍保持損壞狀態(tài)。內(nèi)存仍處于損壞狀態(tài)，但可能被其他激活所觸發(fā)。

· “達到失效模式”：觀察到誤報或漏報（表 1 中的 β 類和 γ 類）。特別是，在導(dǎo)致失效模式的 76 個測試中，有 15 個測試未檢測到活性 / 截止時間 / 控制流錯誤（漏報）。

圖 6、WdgM 實現(xiàn)的魯棒性（217 個測試用例）

結(jié)果表明，基于安全分析的測試用例是有效的，僅有 35% 的測試 “未觀察到偏差”。結(jié)果還突顯了在實現(xiàn)方面需要做出的努力，重點關(guān)注導(dǎo)致失效模式的基本事件（紅色部分）和仍處于潛伏狀態(tài)的錯誤（橙色部分）。例如，可以建議對某些變量進行三重存儲，以通過多數(shù)投票對其進行保護。然而，需要在內(nèi)存消耗、性能和安全性之間進行權(quán)衡。

5、總結(jié)/結(jié)論

首先，對故障注入（FI）范圍的研究表明，ISO 26262 標(biāo)準(zhǔn)的要求可能會對汽車關(guān)鍵系統(tǒng)的開發(fā)過程產(chǎn)生重大影響。實際上，ISO 26262 標(biāo)準(zhǔn)要求所有 ASIL 等級都需進行故障注入，以驗證故障傳播和安全機制的緩解效果。

其次，本文討論了故障注入的目標(biāo)，并提出了一種基于安全分析的方法，用于定義 FARM 模型的故障注入屬性：目標(biāo)、指標(biāo)、失效模型、激活模型和讀取數(shù)據(jù)。

該方法的主要優(yōu)勢在于依托開發(fā)過程中的前期活動，有助于增強對安全分析的依賴。此外，該方法能夠保持安全需求的可追溯性，從而減少實驗數(shù)量。

然而，該方法的主要缺點是對安全分析的成熟度要求較高。特別是，為獲得更好的結(jié)果，應(yīng)優(yōu)先使用失效模式影響及危害性分析（FMECA），因為它是更全面的分析方法。

在一個簡單的汽車應(yīng)用（前燈系統(tǒng)）上實現(xiàn)了該方法的概念驗證。該案例研究的軟件架構(gòu)基于 AUTOSAR 4.X。本文在不同開發(fā)層級描述了該系統(tǒng)，并結(jié)合安全分析，展示了需求的可追溯性及其在故障注入指標(biāo)評估中的重要性。

然后，在故障注入測試平臺上規(guī)劃并執(zhí)行了故障注入測試。實驗指標(biāo)獲得的第一個有趣結(jié)果是注入故障的有效性 —— 大多數(shù)注入的故障對目標(biāo)產(chǎn)生了影響（導(dǎo)致失效模式或觸發(fā)安全機制）。

獲得的指標(biāo)為證明安全機制（WdgM）的有效性、安全需求和無干擾（FFI）的正確實現(xiàn)提供了合理依據(jù)。我們目前的工作旨在從故障注入實驗中獲取全局指標(biāo)，并通過定義最優(yōu)實驗集來優(yōu)化整個開發(fā)過程。

綜上所述，該方法為將故障注入整合到符合 ISO 26262 標(biāo)準(zhǔn)要求的汽車開發(fā)過程中提供了有價值的結(jié)果。然而，在完整架構(gòu)上實施該方法可能會導(dǎo)致大量的工作量和時間開銷。因此，必須謹慎選擇故障注入實驗。

此外，應(yīng)以標(biāo)準(zhǔn)安全機制模塊（特別是 AUTOSAR 模塊）為優(yōu)先目標(biāo)，因為它們可在多個項目中復(fù)用。這也有助于定義故障注入測試，用于對這些模塊的不同實現(xiàn)進行基準(zhǔn)測試。

（添加微信號NewCarRen咨詢）