軟件可靠性分析技術

雷云 陳圣斌 丁杰

（中國直升機設計研究所，江西景德鎮 333001）

0.引言

本文研究對象是應用領域有經驗機構開發的重大軟件和其所經受的試驗以及其他演示/驗證技術。該種軟件不是因編制101程序太繁瑣而引發編碼差錯造成失效或故障。硬件的發展在一定程度上降低了“有效編程”在使用處理步驟和內存時強調經濟的要求。自動程序生成器、高級語言和先進的編譯程序，實際上已經消除了編碼差錯。這樣，防止軟件故障就意味著關注需求階段和設計階段潛在的或可能的差錯源。當軟件遇到了未經試驗的條件或者已經試驗但并未確認失效的狀態時，軟件就會故障。因此，該文重要的一部分就是要認可以下兩方面中的關鍵功能：它們干擾了提供基本服務；它們引起不安全狀態。確認這些領域的模式是故障樹分析、故障模式和影響分析。對于這兩種分析，本文將以實例詳細說明。

1.使用剖面

1.1 定義

（1）軟件失效（software failure）— 軟件失效（另一種稱呼即稱之為缺陷）即是軟件有缺陷或差錯（這可能是因錯誤編碼、設計差錯或需求和規范問題產生的），這種缺陷或差錯有可能引起軟件故障或內部缺陷。（2）使用（operation）— 使用定義為主要的邏輯工作，這種邏輯工作與其他工作或任務是很不相同的，一個主要的工作或任務通常與功能需求相關。（3）使用剖面（operation profile）— 一組完整的使用和它們發生的概率。（4）否認或拒絕。當考慮減少軟件相關故障時，人們需對故障進行限止和按優先順序處理。是考慮故障導致降低可靠性和使用性還是關注故障可能引起災難性/重大的系統故障，這二者之間是排它性的。

1.2 研發使用剖面所需的步驟

開發使用剖面是一循序漸進的過程。（1）確定使用。通常是根據參與者（系統用戶和系統操作人員）列表來完成。（2）確定第一步所確定的每一項使用的發生率。根據系統類型，以各種方法收集發生率。如果系統是在現有系統上改進，那么可使用現有系統的實際應用剖面。如果是一新的系統，便可從相似系統和從將要實現自動化的手動系統中收集使用信息。其使用的發生可以是近似值，并且隨著新版本的發展予以修改[1]。（3）確定發生的概率。這是根據發生率來確定的，是對測試工作進行優先處理所需輸入。

2.軟件FMEA

2.1 軟件FMEA作用

故障模式和影響分析（FMEA）的應用在硬件中是標準化的，其作用與獲益是很明確的：

在確認安全性關鍵硬件時，FMEA是一種標準（文件）；確保審查過程的完整性；確定重大故障的發生者；驗證保護和降低（故障影響）的程序；彌補系統和部件工程師之間間隙或差距。

FMEA在驗證軟件方面的作用和獲益與硬件是很相似的。圖1所示FMEA的結構形式適用于軟件。軟件專家負責故障定義、原因、中間級影響、部件識別（identification parts）以及軟件級降低影響措施。系統工程師們的任務是確認最終影響（系統級）和故障識別及糾正措施[2]。

圖1 應用于軟件的FMEA結構

2.2 軟件FMEA實例

以一個主/輔系統為例。這一系統可以描述為一個雙余度的服務器系統，雙套的無人裝備系統或任何其他具有主/輔作用的余度系統。在這一實例中，主、輔系統能互換“心跳”，從而使它們能持續的實現其功能。失效的心跳將觸發一個開關，于是余度或輔助系統→主系統。（跟隨者→主導者；余度服務器→主服務器等）。

圖2所示描述了這樣一個計算機系統使用情景，它們能互換心跳。失效心跳將引起“建立作用”動作的發生，一個從“主”到“備用”作用的開關或轉換也將發生。這一示例情景描述強調動作的發生，這啟示人們可考慮面向對象設計。這些就是一個軟件FMEA中的“部件”。

圖2 主/備構型的交換心跳的2臺計算機狀態圖

以“計數器”為對象舉例，它接受心跳以及對心跳計數，同時檢查連續心跳之間的時間。

計數器有下列“方法”：接受心跳；心跳計數；時間間隔開始；時間間隔結束；第二次再起動。

每一種方法有多種故障模式，在FMEA中全部都要予以分析，詳見表1。

表1 計數器為對象的FMEA表

列在FMEA（表1）的最終影響，它包括主裝置失效時，“無法轉換”的嚴重結果，最終影響嚴酷度為Ⅰ，這是安全性危險事件。當沒有故障時，這種不必要的轉換也沒有嚴重后果。必須指出，當單獨考慮這一系統時，它便沒有補償措施，并且檢測方法都是外部的。這樣就完成了一個系統級的FMEA分析。

3.軟件故障樹分析

當審查安全性關鍵和任務關鍵系統時，普遍使用故障樹分析（FTA）。FTA，在用于硬件時，往往是定量分析。這包括故障率，某一輸入和狀態的概率值，其能產生系統級的最終影響概率值。當軟件處于混合狀態時，通常無法定量分析，定性分析也是有效的。

3.1 軟件故障樹分析的簡化

軟件可能是遍布的、復雜的，有很多簡化和方法用來使軟件的故障分析能易于實現[3]。（1）規模（大小）的簡化：首先審查整個系統故障樹以便找到可能僅影響系統安全性的這些模塊。這樣僅對與故障樹接口且導致嚴重的（安全性或任務關鍵）最終影響的部分進行故障樹分析。（2）截去分支或支路。在達成一個邏輯上的矛盾之前（參見上面），通過包括斷言或異常狀態，對分析表明能導致危險的不安全狀態進行檢測且采取緩解措施，可以終結這些分支。（3）模板使用。FTA通過常用的語言模板（例如通過IF-THEN-ELSE block進行追溯的模板）便能使故障樹分析自動化。（4）在部件級工作。這正如產生故障模式和影響分析的情況一樣，在部件級的工作能簡化故障樹分析。

3.2 軟件故障樹實例

以圖2描述的主/輔余度系統互換心跳的實例作簡單的故障樹。這一故障樹是在方法層次上進行的，它表示了無法轉換這一最嚴重的最終影響，主裝置的故障沒有觸發所要求的開關接通到輔助裝置。“無法轉換”的最終影響是由于“計數器”丟失故障造成，這可能是由4種目標方法的任一個不工作造成的：接受心跳、第二次再起動、時間間隔結束或心跳計數，如圖3所示。

圖3 基于圖2所示系統的軟件FTA實例

4.總結

本文闡述了與軟件相關的故障源和提出多種能減少故障（特別是嚴重故障）或降低它們后果的方法和策略，包括軟件FMEA、軟件FTA。這些方法和對策能應用于安全性/任務關鍵系統，或用于高可靠性系統。另外，應用于這兩個領域的方法是很不同的，從可靠性定義和要實現的目標開始就要正確處理和對待。