張亞琳,李 浩,胡 驍,趙晨希

(中國運載火箭技術研究院,北京 100076)

1 引言

隨著計算機技術的飛速發(fā)展,航空和航天飛行器等系統(tǒng)的復雜化程度不斷提高。在這些系統(tǒng)中,計算機一旦失效,將導致巨大的經濟損失。飛行器控制系統(tǒng)是其計算機的核心,要求能夠克服外界干擾環(huán)境的影響把飛行器的運動控制在相應的速度和相應的軌跡,對控制的精度、穩(wěn)定性及魯棒性要求非常高。飛行控制系統(tǒng)作為一個對安全可靠苛求的系統(tǒng),其安全性測試具有極其重要的意義。然而,飛行器在實際中發(fā)生的故障種類繁多,有些故障是內部故障,有些卻是外界干擾所致,且這些故障具有一定的潛伏期,其產生的破壞性效果可能波及到系統(tǒng)的多個部分,傳統(tǒng)的測試方法已難以確保系統(tǒng)準確快速地檢測故障。

故障注入技術是一種通過引入外部故障,觀測系統(tǒng)運行狀態(tài)來提高測試覆蓋性的測試方法,該技術可以有效發(fā)現(xiàn)目標系統(tǒng)中的潛伏故障,縮短故障暴露時間,以改進系統(tǒng)架構,目前已廣泛應用于各類容錯系統(tǒng)中[1,2]。因此,研究飛行器控制系統(tǒng)的故障注入技術,對于提高飛行器航行的安全性與可靠性具有重要意義。

本文根據飛行器控制系統(tǒng)的運行特性,通過特定的技術模擬實際運行中發(fā)生的各類故障,人為地將其注入到系統(tǒng)中,監(jiān)控并分析系統(tǒng)的運行情況,使系統(tǒng)能夠快速檢測故障、隔離故障和修復故障。

現(xiàn)有國內外故障注入技術的具體實現(xiàn)方式多種多樣,其實現(xiàn)形式分為硬件實現(xiàn)和軟件實現(xiàn)[3]。硬件實現(xiàn)的故障注入方法通常利用特殊的設備或工具直接連接到目標系統(tǒng)上實施故障注入。軟件實現(xiàn)的故障注入方法通常采用程序或者腳本來控制故障注入全過程,以避免額外的硬件開銷,并且具有更大的靈活性。飛行器整個控制系統(tǒng)涉及的產品眾多,且功能各異、鏈路復雜以及集成方式多樣。硬件故障注入方法開銷太大,測試周期長,且無法覆蓋全面[4]。典型的軟件故障注入工具有卡內基梅隆大學開發(fā)的FIAT,該工具可以模擬各種分布式系統(tǒng)體系結構,向系統(tǒng)內存和CPU注入故障[5];美國德克薩斯大學提出的FERRARI通過修改進程的控制進程,使用陷阱和系統(tǒng)調用以實現(xiàn)故障注入[6];伊利諾伊大學與美國宇航局合作開發(fā)的FINE主要分析UNIX的內核故障傳播[7];葡萄牙科英布拉大學提出的Xception要求處理器具有硬件編程接口,通用性不強[8];密歇根大學提出的DOCTOR主要是針對集成的軟件環(huán)境進行瞬時、間歇或永久性故障注入。但這些系統(tǒng)都只能解決某一個方面的問題,無法覆蓋系統(tǒng)的全部,而且均是通用型的,并未考慮結合領域背景,而往往結合領域背景的故障才是系統(tǒng)最需要的。

本文提出了一種高效的、可構建領域背景的、支持多種異構平臺和接口的實時故障注入系統(tǒng),構建了從故障產生、故障注入、故障監(jiān)控、數(shù)據分析挖掘、故障預測的全鏈路故障管理平臺。

2 系統(tǒng)概述

系統(tǒng)分為應用層、服務器層和目標系統(tǒng)三大部分,應用層負責完成故障加載、故障生成、系統(tǒng)參數(shù)配置、接口參數(shù)配置和智能分析與預測等,支持用戶自定義的故障錄入;服務器層負責故障管理、故障注入、故障存儲、故障分析、結果數(shù)據收集;目標系統(tǒng)完成狀態(tài)監(jiān)控等功能,目標系統(tǒng)也會駐留部分功能代碼,包括數(shù)據收集模塊和綜合控制功能模塊。故障注入模塊可以支持不同的故障類型、故障位置和故障注入時間,系統(tǒng)架構如圖1所示。

圖1 系統(tǒng)架構

3 故障生成方法

為保證故障測試的覆蓋性,本文采用經典案例故障庫、面向任務定制的故障和用戶自定義故障相結合的方式生成故障。經典故障案例錄來源于結合領域背景知識的故障啟示錄,充分考慮可能出現(xiàn)的接口、中斷、并發(fā)處理、數(shù)據和計算以及控制流錯誤等各種問題,從多種角度充分考核系統(tǒng)的可靠性。

本文將每種具體的故障抽象為故障模型,系統(tǒng)通過故障注入器,根據故障模型在故障注入時刻實現(xiàn)對特定故障的模擬。故障模型用故障的公共屬性來表征,本文采用四個屬性來描述目標系統(tǒng)的故障模型,即故障位置、故障類型、故障持續(xù)時間和故障注入時刻。在故障注入時刻可以選擇以上幾種模型的任意組合作為注入條件,對每一種故障類型進行了說明。

表1 故障模型

表2 故障注入實例

4 故障注入機制

本文從系統(tǒng)的優(yōu)化性、靈活性和可重用性等方面出發(fā),結合動態(tài)注入和靜態(tài)注入的特點,提出了一種動態(tài)生成-靜態(tài)存儲-動態(tài)觸發(fā)的故障注入模型,架構圖見圖2。

圖2 故障注入架構圖

服務器端負責將用戶設定的各種故障場景依次注入到目標端,故障描述信息以線性表的方式存放在主機的緩沖區(qū)中。目標端程序添加掃描故障描述信息表的語句塊,并加載故障描述符,進行故障模式解析,根據故障類型生成故障注入決策,內容包括故障注入時機、故障注入位置和故障內容,如生成多個決策,需依次注入執(zhí)行。故障的生成是動態(tài)的,故障的存儲是靜態(tài)的,故障是運行時動態(tài)觸發(fā)的,從而實現(xiàn)了系統(tǒng)的靈活性和可重用性。

5 故障觸發(fā)機制

故障觸發(fā)模塊主要完成兩個功能:運行目標程序和觸發(fā)故障。具體實現(xiàn)方式為:設計后臺監(jiān)控進程,對故障注入的全過程進行管理;在原執(zhí)行軟件上進行故障插樁改造。

被注入故障軟件的插樁方式通過在被測的系統(tǒng)內可能發(fā)生故障的位置添加故障提取語句實現(xiàn)。如在某個“查詢系統(tǒng)狀態(tài)是否正?！钡姆种袛嗾Z句前添加查詢語句,則可根據用戶注入故障的參數(shù)執(zhí)行不同的分支。當程序執(zhí)行到插樁的這個位置時,會查詢故障表內是否有觸發(fā)型故障,如有,則觸發(fā)該故障。后臺監(jiān)控進程實時查詢故障表內是否有未被注入的故障,如果有,則根據故障類型,則將對應故障觸發(fā)系統(tǒng)變量置為1,由被測軟件根據故障類型來調用不同的故障體。

6 故障監(jiān)測機制

實時故障監(jiān)測系統(tǒng)由故障任務生成器、故障任務追蹤器、目標系統(tǒng)控制模塊和系統(tǒng)狀態(tài)監(jiān)控器組成,系統(tǒng)架構圖如圖3所示。故障生成器生成具體的故障任務并提交給服務器,服務器啟動對應的故障任務追蹤器,并激活駐留在目標系統(tǒng)中對應該類故障任務的后臺追蹤進程,隨后將任務描述信息傳遞給目標系統(tǒng)控制模塊。由系統(tǒng)控制模塊調用對應的系統(tǒng)狀態(tài)監(jiān)控進程,由于故障模式不同,對系統(tǒng)的影響域將有極大不同,所以不同的狀態(tài)監(jiān)控進程開啟的監(jiān)控項也會不同。在故障的有效作用時間范圍內,目標機追蹤器會以心跳的方式定期向服務器返回系統(tǒng)運行狀態(tài),這樣可以保證在目標系統(tǒng)失效的情況下依然可以得到目標機的狀態(tài)信息,而不是完全依賴于數(shù)據收集功能對目標系統(tǒng)狀態(tài)的監(jiān)測和傳送,這樣,當目標系統(tǒng)失效或者數(shù)據收集功能出現(xiàn)異常時,服務器還可以得到目標機的狀態(tài)。

圖3 故障觸發(fā)機制流程圖

圖4 故障實時監(jiān)測系統(tǒng)

為維護任務信息的完整性以及保證每個任務的可追蹤性,將每個任務的控制信息均存儲在數(shù)據庫中。任務在生成時,會創(chuàng)建任務ID,每個任務將ID向任務追蹤器注冊,并且在故障注入時,任務ID會隨著任務具體信息一起注入到目標系統(tǒng),并作為任務的唯一標識,關聯(lián)任務故障信息和運行狀態(tài)信息。

7 故障預測機制

故障預測部分采用回歸和分類結合的方法,回歸模型用來學習基于時空維度的多變量之間的關聯(lián)關系,分類用于對回歸結果進行矯正,以獲得更準確的預測數(shù)據。首先,從飛行器綜合試驗的大量數(shù)據中提取出不同流程和試驗條件下的正常數(shù)據和異常數(shù)據,并提取電量采集值、時序和傳感器采集值等大量參數(shù),經過數(shù)據特征提取后轉化為學習模型的輸入;劃分訓練集和測試集,并進行多輪訓練;將訓練后的值輸入分類模型中,將分類模型的輸出值作為最后的預測值;計算損失函數(shù),并調整參數(shù);反復迭代,生成最終的訓練模型。

飛行器由成千上萬的零部件組成,可提取的參數(shù)數(shù)量極為龐大。經過大量的參數(shù)篩選實驗,挑選了與預測飛行器故障相關的動態(tài)性能參數(shù),并對不同參數(shù)進行了加權處理,使得決定飛行器成敗的參數(shù)占據較大權重,預測結果更符合實際需要。經過實驗驗證,該方法能較好的預測系統(tǒng)的表現(xiàn)趨勢。

8 試驗驗證

8.1 系統(tǒng)容錯測試

對某飛行器控制系統(tǒng)涉及的所有軟硬件進行故障注入測試,全系統(tǒng)分為控制計算機、時序設備、執(zhí)行機構、信息采集機構和遙測系統(tǒng)。針對每個系統(tǒng)功能和軟硬件特性,制定如圖5所示故障注入計劃。

圖5 各系統(tǒng)故障注入測試用例首次不通過率

對每一種故障實例選取的依據是圖5的故障分類模式,故障注入的實例和測試運行結果存儲在系統(tǒng)日志中,測試的統(tǒng)計結果如圖5所示。

各系統(tǒng)軟件運行平臺和功能差異較大,對于同樣的故障,表現(xiàn)出的可靠性差別較大,但是在所有系統(tǒng)中,幾乎均是通信過程可靠性程度不高,證明各系統(tǒng)在接口匹配上存在較大問題。對于時序設備和遙測系統(tǒng)此類含F(xiàn)PGA軟件的設備,在時序匹配方面存在個別問題?？刂朴嬎銠C軟件采用多線程架構,在多線程使用方面存在問題。對嵌入式軟件,通常有多中斷交互功能,經過強行激發(fā)連續(xù)中斷信號的考核,時序設備和信息采集機構的軟件出現(xiàn)中斷處理丟失的問題。通過激發(fā)鏈路故障,也測試出系統(tǒng)容錯設計的缺陷。

8.2 系統(tǒng)改進測試

對經過初次故障注入系統(tǒng)考核的設備,待改善之后,對其再次進行考核,并且重新生成故障實例,如此迭代多次,直到各設備連續(xù)三次通過全部故障用例。在每次迭代測試中,各設備的故障通過率不斷提升,平均迭代測試10次,基本可以達到通過全部故障用例。系統(tǒng)能夠通過故障用例的個數(shù),反映著系統(tǒng)的可靠度,在前幾次測試時,系統(tǒng)可靠度可大幅提升,因為初期測試時發(fā)現(xiàn)的都是共性問題,而到后期,能夠發(fā)現(xiàn)的問題趨于個性化,并且發(fā)生的條件較為復雜,所以可測試出問題的個數(shù)大幅減少,系統(tǒng)可靠度提升趨于緩慢,最終達到較為穩(wěn)定的狀態(tài)。

9 總結

本文設計并實現(xiàn)了面向飛行器控制系統(tǒng)的高實時故障診斷系統(tǒng),可結合具體應用場景生成定制化的故障用例,并實現(xiàn)動靜結合的故障注入機制,通過高效的故障監(jiān)控手段實現(xiàn)實時性,并能將測試結果存儲,用于故障分析和預測。通過試驗證明,該故障注入系統(tǒng)可輔助提升飛行器系統(tǒng)的可靠性,對于提升飛行試驗的成功率具有重要意義。