基于故障注入技術的航天器系統級軟件測試方法研究

(北京空間飛行器總體設計部，北京 100094)

隨著我國航天技術的快速發展，航天器在軌任務越來越復雜，航天器智能自主功能變得越來越強大，星載軟件的質量和可靠性直接影響航天器在軌使用壽命。航天器自主運行能力是考核航天器可靠性的重要標準，星載軟件故障防護模式測試是直接檢驗星載軟件自主故障恢復能力和冗余設計的關鍵手段，如何對航天器系統級星載軟件故障模式進行安全、有效、準確、全面的測試設計成為航天器系統級測試設計的關鍵因素。

航天器系統級星載軟件測試涉及航天器全生命周期的總裝集成測試階段，即組裝、集成、試驗與測試(Assembly Integration Test，AIT)階段。如果把測試實施前的準備工作分為：測試用例設計、測試文件編寫、測試設備研制、測試系統調試四部分，測試用例設計約占總工作量的40%[1-2]。星載軟件故障模式測試設計是利用故障注入測試技術，對軟件的容錯性和健壯性進行測試驗證，系統級星載軟件故障模式測試不僅是針對軟件本身邏輯正確性進行驗證，還要在系統級層面對輸入故障激勵后的執行機構動作進行確認。

目前，軟件工程理論中故障注入技術(針對晶體管故障、門級故障等)已經在航天器單機級軟件故障模式驗證中得到廣泛應用[3-4]，但礙于航天器系統級測試階段中無法提供基于上述技術的故障注入接口及故障模式驗證環境，需要研究適用于系統級故障防護模式測試驗證技術來滿足航天器系統級星載軟件故障防護模式測試需求。本文根據現有工程實踐經驗，結合系統級故障模式測試設計理論，從基于原型的故障注入技術及故障注入實現方式兩方面進行分析，總結了3種系統級故障注入技術的適用場景及優缺點，可為航天器電測中的軟件測試設計提供參考。

1 系統級軟件故障注入測試分析

1.1 軟件故障注入測試特點及難點

由于被測對象的已知性以及測試需求的明確性，系統級軟件故障注入測試廣泛采用“面向對象”和“自下而上”的測試設計理念。利用地面測試設備產生的模擬故障信號作為輸入激勵注入被測系統中，通過觀察被測系統的響應動作或報警信息驗證系統級軟件故障模式設計的正確性。系統級軟件故障模式測試與單機級、分系統級測試驗證不同點在于故障注入點的選取。針對系統級軟件故障模式測試中整星提供特定測試點的約束，故障信號激勵注入點僅能從系統設備采集終端、激勵信號傳輸總線及系統軟件內部程序進行選擇。

系統級軟件故障模式測試的難點在于以下四方面：

(1)整星測試結構狀態對故障注入點的影響：整星合板狀態下，故障注入點在星體內，通過外接測試電纜引入故障激勵受到限制。

(2)故障時序性對故障注入技術的影響：對于強時序故障邏輯驗證，一個判讀周期的延時就有可能影響系統對故障響應的判斷。

(3)故障模型復雜度對故障注入技術的影響：對于復雜系統故障邏輯驗證往往涉及多個激勵信號長時間相互作用，系統會采集多個信號的變化趨勢作為響應動作的依據，單一故障激勵的變化難以滿足系統故障模擬需求。

(4)故障注入安全性的影響：整星測試期間，響應部件均為真實產品，當系統做出故障響應動作之前需要識別響應部件的轉動、擺動以及切備份等動作是否會對整星狀態帶來影響。

軟件故障模式測試驗證設計的核心是對故障注入技術的研究。

所謂故障注入是指：向被測目標系統注入人為設置的故障，該故障能夠觸發系統失效或者進行冗余設置，通過監測被測系統，提取系統接收故障激勵后的動作與故障模式發生后設計預想動作進行比對，從而檢查被測系統容錯機制的正確性[5]。

航天器系統級軟件故障注入原理如圖1所示[6]。

圖1 航天器系統級軟件故障注入原理Fig.1 Principle diagram of software fault injection for spacecraft system-level

1.2 軟件故障注入技術分類

故障注入技術分類方式可以從故障抽象級別、實驗所處系統開發階段、故障類型、實現方法等不同方面進行劃分[7]。本文從故障注入對象角度出發，分為基于仿真的故障注入技術及基于原型的故障注入技術，如圖2所示。

基于仿真的故障注入技術主要適用于航天器單機級軟件故障模式驗證，該類技術需要對被測點、被測邏輯、被測功能建立軟件仿真模型，在模型中加入故障機制[8]。

基于原型的故障注入技術適用于航天器系統級軟件故障模式驗證，該類技術是在原有系統的基礎上，通過各種手段將故障激勵輸入被測系統，通過檢測實際系統的響應動作完成故障模式的驗證?；谠偷墓收献⑷爰夹g可分為3類：采集終端實現、總線介質實現、軟件實現。

圖2 故障注入技術分類

2 基于原型的故障注入技術

采集終端實現的故障注入技術是指選取系統參數采集終端作為故障激勵的引入點，通過硬件設備或者工具直接模擬導致系統故障模式發生的電阻量、電壓量、電流量等。應用此方法，需要將原有系統的采集終端接插件或者可插拔引腳與被測系統斷開，通過特定的轉接插頭及電纜將被測系統與故障模擬硬件設備連接，達到將故障引入被測系統的目的，如圖3所示。

圖3 采集終端實現故障注入示意

數據總線實現故障注入技術是指通過采用特定的總線接入技術，在接收原總線數據的基礎上，通過故障注入激勵控制機制將需要的故障轉換成總線數據的形式再注回系統總線數據中，達到將故障引入被測系統的目的，如圖4所示。

軟件實現的故障注入技術是指通過可編輯腳本或者程序從系統應用層入手，直接將故障注入系統軟件中；或者通過系統應用層修改故障門限，達到滿足觸發故障模式的條件，不通過物理手段進行實現。

圖4 總線介質實現故障注入示意Fig.4 Schematic diagram of fault injection in bus media

3 基于原型的航天器系統級故障模式測試技術應用

3.1 采集終端實現故障注入技術應用

采集終端實現故障注入技術為利用地面測試終端模擬發生故障情況下的輸入激勵，通過星上遙測采集設備將故障激勵通過數據總線直接送給星務軟件處理，不通過中轉，不存在故障注入時延問題，適用于強時序性故障測試驗證。目前在熱控分系統、控制分系統等測試中被廣泛使用。

3.1.1 熱控分系統故障模式測試應用

以熱控分系統熱敏電阻故障模式測試為例，蓄電池加熱回路有2個控溫熱敏電阻，蓄電池加熱回路故障要求是當前控溫熱敏電阻大于+80 ℃或小于-35 ℃時切換至另一控溫熱敏電阻進行控溫，如果另一個熱敏電阻也發生故障則停止切換，向地面發出報警信號。

對于熱敏電阻故障模式類型可以選擇采集終端實現技術也可以選擇總線介質實現技術，本節介紹選用采集終端實現技術的設計驗證方式。

熱敏電阻反映當前測溫點溫度，模擬溫度故障即可以此為切入點，斷開遙測輸入端即采集終端接插件，利用熱敏電阻等效器對當前故障模式電阻值進行模擬注入。

熱敏電阻等效器連接示意圖如圖5所示，斷開星上遙測采集設備與熱敏電阻的接插件，將遙測采集設備與熱敏電阻等效器通過測試電纜連接。該設備通過工控機控制數控電阻阻值變化，達到模擬星上熱敏電阻故障模式的目的。在實際故障測試驗證中，分別設置等效器中主份控溫點為大于+80 ℃或小于-35 ℃時，觀察星上自主控溫熱敏電阻選擇是否切換為備份控溫熱敏電阻，然后再設置等效器中備份控溫熱敏電阻為大于+80 ℃或小于-35 ℃時，是否停止切換并且下傳報警信號，即完成此故障模式測試驗證工作。

圖5 熱敏電阻等效器連接示意圖

3.1.2 控制分系統故障模式測試應用

以控制分系統慣性姿態敏感器故障模式測試為例，某衛星中配置4個陀螺，只要保證3個陀螺能夠正常工作，即可進行姿態控制。陀螺故障主要有陀螺電機、力矩器、傳感器故障或者控制線路失效，導致陀螺漂移增大、輸出常零、加速度超差、飽和超差和陀螺數據不變化等[9]。

控制分系統故障模式測試時采用閉環測試，動力學仿真軟件是地面系統的核心，完成衛星的姿態及軌道動力學計算、敏感器模型計算、控制接口信號采集及發送功能；姿態敏感器模擬部件設置驅動陀螺儀的激勵源，模擬陀螺儀輸出的陀螺信號源，模擬太陽敏感器輸出的太陽敏感器信號源等功能；執行部件模擬器在地面測試中由于執行機構不能實際動作，因此采用動量輪模擬器等進行模擬，其主要作用是采集姿態控制計算機(Attitude Control Computer，ACC)給出的姿態調整信號?？刂频孛鏈y試系統如圖6所示。

圖6 控制地面測試系統Fig.6 Ground test system for attitude and orbit control subsystem

通過敏感器模擬部件設置常值輸出角度及輸出周期，模擬常零故障及飽和超差故障，對4個陀螺分別疊加隨機噪聲輸出，模擬加速度超差，可以驗證衛星對陀螺數據有效性自主診斷和重構，當診斷出某一陀螺出現故障時，剔除該陀螺，采用其它3個陀螺進行姿態軌道控制。

通過動力學仿真軟件計算出的陀螺輸出信息上疊加常值漂移輸出，可以驗證衛星陀螺漂移算法的正確性，當設置多個陀螺故障時，控制系統自主進入安全模式。

3.2 總線介質實現故障注入技術應用

總線介質實現故障注入技術與采集終端實現在故障注入方式上有本質區別，將故障輸入激勵由遙測采集設備端轉移到星載數據總線，將真實輸入激勵的模擬轉移為總線傳輸數據的模擬，來實現滿足星載軟件故障防護觸發條件，驗證星載軟件故障防護處理的能力，本節以1553B總線故障注入系統為例進行介紹。

1553B總線故障注入系統可以對1553B總線的協議層進行故障注入，協議層故障包括同步頭錯誤、校驗位錯誤、消息替換故障注入3種類型，系統結構和信息流如圖7所示。

圖7 1553B總線故障注入系統結構及信息流Fig.7 Structural and signal flow of 1553B bus fault injection system

系統工作過程中有上行遙控指令信息流和下行遙測數據信息流2個通道實現信息的流轉，遙控指令信息流采取透明轉發形式，遙測數據信息流采取截斷替換形式[10]，具體如下。

(1)遙控上行數據：總線控制器(BC)端通過總線發出指令→地面系統內仿遠程終端(RT)端板卡接收指令→系統內部透明轉發→地面系統內仿BC端發出指令→RT端接收總線指令。

(2)遙測下行數據： 星載總線RT端將接收的原始遙測信息發送→地面系統仿BC端接收遙測信息→按照總線通信協議將模擬的故障信息替換原始數據→地面系統仿RT端將注入故障激勵的整幀總線數據發出→星載總線BC端接收帶有故障的遙測信息，完成故障注入過程。

1553B總線故障注入系統接入整星，需要將原數據總線與遠程終端設備斷開，將總線故障注入系統輸出端與遠程終端設備總線接插件電纜端進行連接，將總線故障注入系統輸入端與遠程終端設備總線接插件設備端進行連接，完成地面系統串入整星系統操作，如圖8所示。

對于總線故障注入設備來說，故障轉發時延是一個大問題，為了不影響被測系統的正常運行及邏輯處理，需盡可能的將遙測數據轉發(包含故障激勵)控制在一個周期內，圖9為總線故障轉發時序邏輯，圖中1553B總線周期為T1(單位ms),從總線控制消息發出到故障注入轉發完畢全過程需要時間為T2(單位ms)。按照實際應用情況，故障注入全過程可以在2個總線周期內完成，對于強時序性故障邏輯驗證有一個總線周期的故障觸發誤差。

圖8 1553B總線故障注入系統Fig.8 1553B bus fault injection system

圖9 1553B總線故障注入系統時序邏輯分析Fig.9 Sequential logic analysis diagram of 1553B bus fault injection system

以熱控分系統熱敏電阻短路斷路故障為例，進行實際應用說明。當系統中熱敏電阻發生斷路或者短路故障時，系統自動將故障熱敏電阻剔除，選用備份熱敏電阻進行控溫。此種故障反映的熱敏電阻為極大值或者極小值，采集終端實現技術難以滿足該需求，而采用總線介質實現技術則較輕松。通過總線數據注入模擬的熱敏電阻斷路或者短路遙測源碼值，完成熱敏電阻斷路短路故障功能驗證。

3.3 軟件實現故障注入技術應用

整星系統級層面軟件實現故障模式測試驗證有一定的條件限制，此方法主要應用在由于總裝流程限制，衛星各艙板閉合，無法連接測試電纜的情況下，通過內存修改指令，將故障模式的系統默認值進行放寬處理，使其在正常信號激勵的情況下仍能觸發故障邏輯，驗證故障模式的正確性。該技術不涉及對遙測采集數據進行修改及中轉，能夠滿足強時序性故障模式驗證需求。

以熱控分系統熱敏電阻斷路短路故障為例，該技術實現如圖10所示。

圖10 內存修改實現故障模式驗證邏輯圖Fig.10 Logic diagram of memory modification to implement failure mode verification

1個電阻的故障閾值在程序中表現為2個16位無符號整型數，圖10中所給的地址為存儲2個16位閾值的起始地址，從該地址開始向后的連續4個地址內存放的2個16位數據作為相應的閾值。通過內存修改指令，將故障閾值進行適當放寬，修改后閾值參考常溫下熱敏電阻溫度源碼進行選定，就可以不通過外接設備完成熱敏電阻故障模式的驗證。

3.4 系統級故障注入技術優缺點分析

通過前3節對基于原型的故障注入技術在整星系統級故障模式測試驗證的應用分析，本文提出的3種方法優缺點如表1所示。表1中時序性是指被測系統軟件對接收故障激勵的響應有效周期，在軟件測試需求中會明確提出，該指標是反映系統軟件故障處理響應速度的關鍵因素，影響系統級故障注入技術的應用選擇。對于采集終端實現的故障注入技術，故障激勵直接作用于采集終端，待接收到總線消息控制字后，采集終端將故障激勵在一個總線周期內送給被測系統軟件，故障注入沒有時延，適用于強時序系統功能驗證。而總線介質實現的故障注入技術經3.2節分析后得出地面測試系統待接收到總線消息控制字后，被測系統軟件接收到故障激勵信號會有一個總線周期的延時，適用于弱時序系統功能驗證?；谲浖崿F的故障注入技術，其根本是改變被測系統軟件對故障激勵的閾值，測試過程中不會帶來時延。

表1 系統級故障注入技術優缺點

4 結束語

本文提出了3種適用于航天器系統級的故障注入技術，并對其實現原理和實現方式進行分析總結。以上3種故障注入技術已在各領域航天器整星綜合測試階段實際應用。測試結果表明：3種基于原型的故障注入技術滿足航天器系統級軟件測試驗證需求，符合軟件測試覆蓋性、有效性、安全性設計要求，可以為整星結構、系統故障響應時序等諸多約束條件下系統級故障注入技術的選擇提供參考。對于本課題的進一步深入研究建議如下：①總線介質實現的故障注入技術可以從總線消息控制字與被測BC端消息字同步方面進行突破，降低故障模擬響應延時；②不局限于當前對故障注入點的識別，研究新的故障注入途徑，變不可測故障模式為可測故障模式，提高系統級層面軟件功能地面驗證能力。