摘要

軟件故障注入是功能安全驗證的重要技術手段。本文旨在為軟件故障注入提供一個基本概述，以及簡介現有的故障注入技術。

01

故障注入方法簡介

在功能安全相關關鍵場景中，密集的測試活動對于確保新系統和內置容錯機制按預期運行至關重要。確保系統在出現故障時正常運行（Fail Operational）是一個需要比傳統測試內容復雜的問題。在系統中引入故障以評估其行為并測量容錯機制的效率（即覆蓋率和延遲）的過程稱為故障注入。

故障注入方法的發展是隨著數字化的發展同步進行的。

最開始，數字系統只使用了簡單的硬件系統。因此，第一種故障注入方法包括通過假設簡單的硬件故障模型（如位翻轉或位卡死）將物理故障注入目標系統硬件（例如，使用輻射、引腳電平、電源干擾等）。

硬件的日益復雜使這些物理方法的使用變得相當困難，甚至不可能，一個新的故障注入方法，即基于通過軟件（軟件實現的故障注入SWIFI）對硬件故障進行運行時仿真，變得非常流行。

隨著關鍵系統在其他應用領域的擴展，我們看到這些系統的軟件部分越來越復雜，這成為系統故障的一個不可忽視的原因。阿麗亞娜5號火箭的第一次試飛（1996年6月4日）就是一個例子。在試飛過程中，火箭偏離了飛行路線，在起飛后不到一分鐘就發生了爆炸，造成了5億美元的損失。爆炸是由軟件中的錯誤數據轉換引起的，從64位浮點到16位有符號整數表示。該漏洞源于對以往任務中軟件子系統的重用，而沒有進行實質性的重新測試，開發人員認為該任務與新系統兼容。

SWIFI工具用于在程序狀態（例如，數據和地址寄存器、堆棧和堆內存）和程序代碼（例如，在程序執行之前或期間存儲代碼的內存區域）中注入錯誤。不幸的是，在復雜的軟件密集型系統中，通過SWIFI無法準確模擬真實軟件故障的影響。因為在過去三十年中，汽車中使用的代碼行的規模從數萬行呈指數增長到數億行。

與第一種故障注入方法相比，使用故障注入來模擬真實軟件故障（即bug）的影響，即軟件故障注入（SFI），是相對較新的方法。實際上，軟件故障的注入包括在目標程序代碼中引入小的更改，創建不同版本的程序（每個版本有一個注入的軟件故障）。

ISO 26262標準規定了軟件中錯誤檢測和處理機制的使用，以及通過故障注入進行驗證。

軟件故障注入是一種假設實驗，它可能起源于軟件開發過程的任何階段，包括需求分析、設計和編碼活動。在給定的工作負載下執行目標，并將故障插入目標系統的特定軟件組件中。主要目標是觀察系統在存在注入故障的情況下的行為，考慮到這些故障會重現可能在運行期間影響系統給定軟件組件的合理故障。

02

故障注入方法關鍵特性

//

故障是系統狀態不正確的判定或假設的原因，稱為錯誤。故障是在提供錯誤服務時發生的事件，即用戶或外部系統感知到錯誤狀態。

故障注入活動獲得的結果的準確性在很大程度上取決于實驗的幾個關鍵特性，即：

代表性

是指故障負載和工作負載代表系統在運行期間將經歷的真實故障和輸入的能力。通過定義一個真實的故障模型，并在實驗過程中準確再現該故障模型，可以實現故障的代表性。

非侵入性

要求故障注入過程中采用的儀器（如故障插入和數據收集）不應顯著改變實際系統的行為。例如，執行額外的代碼來破壞軟件狀態可能會導致侵入。

重復性

是指當在同一環境中使用同一程序多次執行故障注入活動時，可確保統計結果等效的特性。由于計算機系統中存在許多不確定性的來源，例如線程調度和事件計時，要實現這一特性并非易事。

實用性

是指故障注入在成本和時間方面的有效性。這些因素包括實現和設置故障注入環境所需的時間、執行實驗的時間以及分析結果的時間。該屬性要求實驗由自動工具支持，以滿足時間和預算限制。

可移植性

要求故障注入技術或工具能夠輕松地應用于不同的系統，以便進行比較。故障注入工具的可移植性還指該工具支持多個故障模型并用新的故障模型進行擴展的能力。

03

軟件故障特征

軟件故障的注入需要對要注入的故障進行精確定義，這反過來又需要對軟件故障進行清晰的理解和描述。這并不容易實現，因為軟件故障是由于開發過程中發生的人為錯誤造成的，這些錯誤會以程序中錯誤指令的形式影響軟件工件。

為了提高軟件可靠性，人們提出了幾種故障分類模式。在故障分類模式中，正交缺陷分類（Orthogonal Defect classification，ODC）是研究人員和實踐者最廣泛采用的模式之一，并已在多個研究中用于定義軟件故障注入的故障模型。ODC是一個對軟件故障進行分類的框架，目的是獲得軟件開發過程的度量和定量反饋；

04

軟件故障注入技術

//

許多SFI技術和工具是在20多年的時間里發展起來的。這里，我們通過區分兩種基本方法來說明和討論這些工作：注入故障效應（也稱為錯誤注入），其中通過擾動系統狀態引入錯誤，以及注入實際故障，其中更改程序代碼以模擬代碼中的軟件故障。以下小節分別回顧了軟件故障注入技術：

· 數據錯誤注入的方法最早，這些方法基于當時存在的硬件故障注入技術；

· 接口錯誤注入方法，旨在測試組件與其他組件交互的穩健性；

·注入實際故障的方法，在程序代碼中引入小的故障更改。

4.1數據錯誤注入

早期注入故障效應的方法是在通過SWIFI研究硬件故障的背景下發展起來的。SWIFI旨在通過軟件干擾內存或硬件寄存器的狀態，再現硬件故障（如CPU、總線和內存故障）的影響（即錯誤）。根據以下標準，SWIFI方法將內存位置或寄存器的內容替換為損壞的值：

· 注入什么。內存位置或寄存器中單個位、字節或字的內容已損壞。通過對電氣或門級故障產生的錯誤的分析，定義了錯誤類型。常見的錯誤類型是用固定值（卡在0和卡在1故障）或相反值（位翻轉）替換位。

· 注入的地方。由于內存位置眾多，注入內存的錯誤通常針對位置的子集。注入可以集中在特定內存區域中隨機選擇的位置（例如堆棧、堆、全局數據）或用戶選擇的位置（例如內存中的特定變量）。在寄存器中注入的錯誤可以針對那些可以通過軟件訪問的寄存器（例如，數據和地址寄存器）。

· 何時注入。錯誤注入可能與時間或事件有關。在前一種情況下，在經過給定的實驗時間后注入錯誤，該時間由用戶或根據概率分布選擇。在后一種情況下，當特定事件在執行期間發生時，例如在第一次訪問或每次訪問目標位置時，會注入錯誤。可以模擬三種類型的硬件故障，分別是瞬時故障（即偶然故障）、間歇性故障（即多次重復故障）和永久性故障。

值得注意的是，SWIFI工具注入的硬件錯誤可以在程序狀態（例如，數據和地址寄存器、堆棧和堆內存）和程序代碼（例如，在程序執行之前或執行期間存儲代碼的內存區域）中注入。這是軟件故障注入的一個重要區別：程序狀態中的損壞旨在反映軟件故障的影響，即錯誤程序的執行導致的錯誤，例如錯誤的指針、標志或控制流，SWIFI工具可以直接引入此類錯誤；相反，程序代碼中的故障旨在反映代碼中的實際軟件故障。

4.2 接口錯誤的注入

在輸入參數處注入錯誤旨在模擬目標外部故障產生的影響，包括外部軟件組件中軟件故障的影響，并評估目標檢測和處理損壞輸入的能力。以類似的方式，輸出值的損壞被用來模擬故障部件的輸出，并可用于評估故障對系統其余部分的影響。

輸入參數的故障可能會揭示目標的錯誤檢測和恢復機制（例如，輸入處理代碼）的設計和實施中的缺陷。它通常在穩健性測試中采用，該測試評估“系統或組件在存在無效輸入或壓力環境條件下能夠正確運行的程度”。應該注意的是，健壯性測試和接口錯誤注入的目標不同于功能測試技術，例如黑盒測試：健壯性測試旨在評估軟件模塊在面對無效輸入時的健壯行為（例如，避免了進程崩潰，或產生了警告信號），它與目標的功能正確性無關。

接口錯誤注入可以通過兩種方式執行。第一種方法基于鏈接到目標組件的測試驅動程序（例如，使用目標導出的API的程序），并通過提交無效輸入來執行該程序。這種方法類似于單元測試，但在這種情況下，評估的是健壯性，而不是功能正確性。第二種方法包括攔截和破壞目標與系統其余部分之間的交互，即在調用目標組件時觸發攔截器程序，并修改原始輸入以引入損壞的輸入。在這種情況下，目標組件將在集成目標的整個系統的上下文中進行測試。這種方法類似于SWIFI，因為流經系統的原始數據（在本例中為接口輸入）被損壞的數據替換。

在接口錯誤注入實驗中，在實驗期間發生的幾個輸入參數和目標API的幾個調用中，通常只有一個輸入參數和一個調用被破壞。生成無效輸入值的常用方法有三種：

· 模糊化：原始值被隨機生成的值替換。

· 位翻轉：通過反轉原始值的一個或多個位的值來生成損壞的值。

· 基于數據類型的注入：原始值被替換為無效值，該值是根據被破壞的輸入參數類型選擇的，其中類型是從目標導出的API派生的。這種方法為每種數據類型定義了一個無效值池，這些值是從類型域的分析中選擇的（例如，在C指針的情況下為“NULL”）。

4.3注入代碼的更改

前面小節討論的主要是通過使用SWIFI方法注入故障影響（即錯誤）來模擬軟件故障。這些方法的一個公開問題是注入錯誤（如位翻轉）的代表性，它不一定與軟件故障產生的錯誤匹配。

為了解決代表性問題，最近對SFI的研究集中在程序代碼中錯誤的注入（即代碼更改）。即可以采用注入代碼更改來模擬真實軟件故障，因為注入的故障會產生與真實軟件故障產生的錯誤和故障相似的錯誤和故障。一般可通過在進程的代碼存儲區或二進制可執行文件上應用SWIFI，在程序中注入錯誤。但要注意通過對這些程序進行徹底測試，需在有限的范圍內注入軟件故障，需要專門針對軟件故障注入的工具和技術。

05

結論

//

在為系統選擇方法時，應考慮所討論的故障注入方法的特點。

錯誤注入通常用于評估單個組件的健壯性，并改進代碼特定部分的錯誤處理。主要原因是，錯誤的注入允許對系統的特定部分進行實驗，因為它可以評估錯誤對特定組件接口或程序變量的影響。事實上，錯誤注入不需要等待錯誤生成并傳播到正在評估的程序狀態的特定部分。此外，由于錯誤注入可以應用于單個組件，因此可以在軟件驗證的早期階段執行。

相反，注入代碼更改的目的是作為一個整體評估容錯系統，并在備選設計選擇之間進行定量評估和比較。代碼更改更適合于這些目標，因為它們基于軟件故障的代表性模型，并密切模擬故障軟件的行為。這是定量評估和比較的一個重要要求，因為它們考慮了故障發生的相對概率，以反映系統在運行期間表現出的行為。這使得代碼更改的注入更適合于軟件驗證的后期階段，此時系統組件已經集成，開發人員的目標是評估系統在其運行壽命期間的預期容錯性（以及衍生的度量，如可用性）。

作者：鄭威，TüV北德功能安全總監

編輯：黃飛