基于故障樹的靶標回收系統軟件可靠性測試分析?

王艷軍 張海軍

（91404部隊 秦皇島 066001）

1 引言

靶標回收系統是某型水下試驗靶的回收控制系統，負責完成水下試驗靶試驗完成或意外情況下的靶體回收任務，在整個靶標系統中具有極其重要的作用。系統由嵌入式系統平臺、各類傳感器和控制軟件等多個組成［1］，在水下工作過程中一旦出現失效，可能會導致靶標丟失等情況，系統是否可靠會直接影響到一次任務的成敗。目前各有關工業部門、軍兵種越來越重視可靠性管理，可靠性技術已經貫穿于產品的各個環節［2］，針對嵌入式軟件系統進行安全性分析已成為現代嵌入式系統安全性保障的重要方法和研究熱點［3］。針對靶標回收系統各底事件及中間事件發生的概率無法確定的現狀，基于靶標回收系統的系統設計方案，建立靶標回收系統的故障樹模型，通過對故障樹進行分析，幫助軟件測試人員快速判明會導致系統失效的潛在故障發生路徑，對系統的可靠性驗證和軟件測試［4］用例設計提供有效指導［5］。

2 故障樹

SEFT（State/Event Fault Tree），狀態/事件故障樹是Kaiser博士于2007年提出的一種安全性建模方法，將傳統的故障樹中的元素與基于狀態機的元素結合起來，區分了事件與狀態，既能有效地建模軟件系統的行為又能表達系統失效因果鏈［3］。SEFT能夠通過系統行為有效地表達軟件系統中構件的失效與系統危害發生之間的因果關系，適用于建模構件化軟件系統的危害場景。SEFT能夠建模較低層次的系統，且可以很好地填補安全性分析與形式化方法之間的空缺。故障樹分析法已被國內外大量應用于各個行業，如裝甲裝備的故障診斷與定位［6］，魚雷動力系統故障樹診斷模式識別［7］等，是系統可靠性分析中最常見的方法之一，是一種自頂向下的分析方法，即從軟件系統不希望發生的事件（主事件或頂事件）［8］，特別是對人員和設備的安全產生重大影響的事件開始，向下主保護追查導致主事件發生的原因，直至基本事件（底事件）［9］。

3 系統故障樹模型構建

3.1 靶標回收系統設計

靶標回收系統是一個典型的嵌入式系統平臺。軟件模塊包括遙控指令接收處理、深度判斷、電量判斷、距離判斷、事件判斷、回收操控指令生成處理。硬件模塊由遙控模塊、定時器、壓力傳感器、深度傳感器、電量傳感器、定位模塊，舵機控制模塊、氣泵等模塊組成。

按照系統設計，在典型任務情況下，系統可以通過兩種方式進行回收：

1）遙控回收：當回收系統的遙控模塊接收到遙控回收命令，系統生成回收控制指令并執行，控制舵機執行靶體上浮動作，當檢測到靶體已出水（在水下深度小于5m）時，控制氣泵放氣，拋出回收網。回收動作執行完成。

2）自動回收：當系統工作超時（＞4h）、靶體深度超限（＞500m）、電池電量低（＜20%），靶體距離指控點超出安全距離（大于5km）時，系統自動生成回收控制指令并執行回收操作。

3.2 故障樹模型構建

一個系統，不同的應用活動包括不同的故障原因，將系統故障轉化為故障樹的結構，必須要考慮具體的應用信息［10］。故障樹分析是把系統不希望發生的失效事件作為失效分析的目標，這一目標在故障樹分析中定義為“主事件”。針對回收系統，可以利用故障樹中故障現象和故障源之間的邏輯關系建立規則［11］，將“回收系統失效”設置為主事件，將“回收系統失效”主事件分解，得到兩個中間事件：“回收控制指令生成失敗”和“回收控制指令執行失敗”。通過對系統各個軟硬件模塊之間的安全性依賴關系進行詳細地分析，將各個中間事件逐步向下分解，最終建立系統故障樹模型，見圖1。

圖中頂層事件F1表示回收系統失效：事件M1表示未能有效生成回收控制指令，M2表示未能有效執行回收動作。當M1和M2之一出現失效就會導致F1失效事件發生。從圖1中可以看出，通過對頂事件和中間事件進行分解最終得到會導致系統失效的基本事件共有14個，其中軟件基本事件7個，見表1。

表1 系統基本狀態/事件

4 系統安全性分析與用例設計

根據圖1，可以列出全部的失效序列。

F1=M1∪M2；M1=M3∩M7；M2=X21∪X22∪M21；M3=X1∩M4∩M5∩M6；M4=X2∪X3；M5=X7∪X8；M6=X4∪X5∪X6；M7=X9∪X10；M21=X23∪X24。將各個中間事件用基本事件替換帶入，最終得到系統的失效序列：

F1=（（X1∩（X2∪X3）∩（X7∪X8）∩（X4∪X5∪X6））∩（X9∪X10））∪（X21∪X22∪X23∪X24）。

4.1 最小割集計算

最小割集是導致主事件發生的基本事件的集合，即全部發生時會導致系統失效。即當任一個最小割集中全部基本事件為“失效”時，主事件必然為“失效”。

七十年代以來，國內外研究出多種求解故障樹最小割集的算法。這里采用下行法［12］進行計算，從主事件開始，由上到下，順次把上一級事件置換為下一級事件，通過對上面的F1失效序列進行化簡和計算，最終得到導致系統失效的最小割集，見表2。

表2 系統最小割集

從這些最小割集中可以看出引起系統失效的所有最小場景。此外，還可以看出X21（回收指令執行失效）、X22（舵機上浮控制失效）、X23（氣泵控制失效）、X24（出水判斷失效）分別是系統的關鍵事件和關鍵狀態。這些關鍵事件和狀態在系統測試過程中應重點關注，在系統設計和測試過程中，在測試用例生成［13］以及軟件模型檢驗屬性的生成時充分考慮，從而進一步提高軟件系統的可靠性。

4.2 最小徑集計算

最小徑集是指使主事件狀態為失效不發生的最低限度的基本事件的集合。即當集合中的基本事件全部不發生（安全），則必然主事件不發生（安全）。將故障樹轉換為安全樹［14］，然后計算該安全樹的最小割集，即為對應故障樹的最小徑集。

通過對圖1中的故障樹進行轉換計算，最終得到系統故障樹的最小徑集5個，見表3。

表3 系統最小徑集

4.3 結構重要度判斷

通過對故障樹中基本事件的結構重要程度進行分析，可以得到各個基本事件的重要度如下：

考慮到系統中硬件的可靠性普遍要高于軟件模塊，且軟件為新開發產品，因此單獨列出各個軟件模塊基本事件的重要度關系。

①（X21，X24）＞ ②（X10，X9，X8，X3）＞ ③（X6）

在對系統可靠性進行測試用例設計時，應該考慮各個軟件模塊對系統失效影響的重要程度，必要時對關鍵軟件模塊進行深入分析和重點測試。

4.4 測試用例設計

按照表1中基本事件，每個基本事件有兩種狀態（失效/安全），則全部的狀態組合共有214=16384個。顯然這對于測試用例設計來說是一個天文數字，如想覆蓋全部基本事件狀態，成本是不可承受的。

在測試過程中，針對系統軟件安全性分析的結果，將基本事件狀態作為用例輸入條件，根據系統輸出結果（系統最終狀態F1），我們可以根據最小割集設計得到基礎失效用例（當測試用例中的輸入條件均為失效時，系統必然失效，為避免影響其他基本事件，其他基本事件均應設置為“安全”）28個。根據最小徑集設計基礎安全用例（當測試用例中的輸入條件均為安全時，系統必然安全，為避免其他基本事件的影響，其他基本事件均應設置為“失效”）5個。

考慮到對各個最小割集內基本事件的組合，可以設計補充安全用例，以割集（X1，X2，X4，X7，X9）為例：

由割集的定義可知，當其他基本事件的狀態為“安全”時，當割集（X1，X2，X4，X7，X9）中任一事件為“安全”，最終系統狀態（F1）就不會為“失效”。由此可以設計補充安全用例25-1=31個。

表4為以割集（X1，X2，X4，X7，X9）為例設計的測試用例。

針對全部最小割集數量m，每個最小割集中基本事件數量n，得到補充安全用例數量a的計算公式

表4 割集（X1，X2，X4，X7，X9）測試用例設計

計算得到全部最小割集的補充安全用例數量a=24*31+4*0=744個。

同樣我們還可以對各個最小徑集內基本事件的組合設計補充失效用例，以徑集（X1，X21，X22，X23，X24）為例：當其他基本事件的狀態為“失效”時，當徑集（X1，X21，X22，X23，X24）中任一事件為“失效”，最終系統狀態（F1）就不會為“安全”。由此可以設計補充失效用例25-1=31個。針對全部最小徑集計算得到合計補充失效用例個數b=31+63*3+127=347個。

顯然通過故障樹分析方法可以高效指導系統軟件的安全性測試用例的設計工作，從上面的分析可以看出，通過故障樹的最小割集和最小徑集設計33個基礎用例，即可覆蓋系統軟件最小失效和安全關鍵路徑，考慮補充設計的測試用例，全部用例為1124個，有效提高了軟件測試的效率。

5 結語

故障樹分析方法在硬件系統的應用已很廣泛［15］，但在軟件測試過程中的應用較少。通過建立回收系統故障樹，可以明確影響系統可靠性的各個軟硬件基本事件之間的邏輯關系，有助于測試人員對系統失效出現的原因進行較為深入的分析研究，驗證系統設計與實現的一致性。通過對系統失效樹的分析，可以幫助測試人員高效地設計測試用例，有針對性對關鍵的軟硬件模塊進行重點分析驗證。