傳統故障余度處理方式將故障余度減緩切除，造成飛控計算機子系統的降級，如果剩余的余度再出現故障可能危及飛行安全。有些余度通道故障可以通過重啟余度通道來恢復正常運行。通過分析余度通道正常啟動流程，以及飛控計算機子系統余度控制應用軟件重啟流程，研究了雙CPU命令監控模式和雙命令模式下的重啟流程。最后針對仿真設備節點故障、飛控節點故障以及飛控多余度故障進行了實驗驗證，84個故障驗證項經驗證測試后全部通過。

引言

高可靠性是飛機的重要研究方向，飛控系統很大程度上影響著飛機的可靠性。因此，要提高飛機可靠性，必須提高飛控系統的可靠性。飛控系統的核心是飛控計算機子系統。為了提高飛控系統的可靠性，工程實踐中廣泛使用多余度飛控計算機子系統架構，二余度結構、三余度結構、四余度架構是工程上最常用的幾種架構。在四余度飛控計算機子系統中，余度通道故障的應對策略一般為減緩切除方法，即連續指定周期或累計指定周期被判定異常就會將該余度通道切除。這樣的策略下，如果繼續有通道發生故障，飛控功能將快速降級，最終可能影響飛機任務的完成度。

在工程實踐中，發現有些飛控計算機余度故障是單粒子效應等原因引起的，系統器件在經過復位或者重新上電后，可以恢復功能。如果因為這些故障原因就將整個余度通道隔離切除，系統的效能會受到較大的影響。因此需要對這些故障進行具體分析，并提出系統功能及性能容忍的、非余度切除的恢復性處理措施，即余度通道空中重啟。在余度通道重啟的過程中，引發故障的硬件故障原因消除，系統恢復正常，系統得以繼續運行。或者，當余度通道進行重啟后，系統原有的某些故障狀態可能會恢復。這類故障是因為系統中未被研制過程中的驗證環節所發現的系統缺陷引起的。缺陷在系統特定的運用狀態下被觸發，引發余度故障甚至系統失效。在系統重啟后，因為系統狀態的改變，又避開了觸發條件，使得系統可以繼續運行，系統部件可繼續發揮作用，因此重啟故障余度不失為一種可利用的系統容錯策略。

余度通道正常啟動流程

余度通道系統正常啟動的流程如下： 1）通道控制計算機上電重啟； 2）系統軟件根據空中/地面狀態判定進行自檢、初始化； 3）系統軟件根據空中/地面狀態判定確定是否進行控制程序映像校驗； 4）系統軟件加載控制程序到內存； 5）余度同步，即同步采用握手的算法進行。在余度通道內部，還會采用指令通道與監控通道配合以對本通道進行自檢的技術手段。指令通道與監控通道也需要進行同步。余度通道內部的這類同步需要在余度間同步前進行； 6）啟動控制功能及故障檢測：同步結束后，通道系統軟件啟動控制功能程序，控制功能程序開始進行控制邏輯運行。系統軟件在進行控制功能程序周期調度時，在每個控制周期的開始，為消除各個通道同步誤差，還需要進行控制周期同步。同步仍采用高低電平握手方式。在同步成功后，通道系統軟件再啟動下一個周期的控制功能程序調度。

飛控計算機子系統余度重啟流程分析

在實際系統中，如判定一個飛控計算機子系統余度通道出現故障，一般對其進行故障減緩切除處理，但切除故障余度后，如果剩余的正常運行的余度發生故障，可能導致系統快速降級，影響任務的完成。美國SpaceX公司在“獵鷹9號”（Falcon 9）火箭上采用了商用的X86處理器，控制系統使用了三個處理器，組成了3×2的6余度系統，所有的6個余度之間的結果數據進行互傳校驗，計算出錯的處理器進行復位，復位后拷貝相關狀態數據后重新上線運行以提高系統的可靠性。由于飛控系統的高安全、高可靠和高實時性的要求，以及在計算機和通信總線技術上與商業領域的差別，本文借鑒了國外商用分布式系統的余度重啟上線思路，對切除的故障余度進行重啟，即自身或其余通道（或作動器遠程終端子系統）輸出強制故障余度重啟的指令。

故障通道如果得到了強制其重啟的指令，仍然可以在兩個層面上進行，一個是系統級上電重啟，另一個是控制應用軟件重啟，可恢復不同范圍的故障。如采用整個系統上電重啟的措施，則故障余度通道上電重啟并完成操作系統和飛控應用的加載。如果是單獨的軟件重啟，則飛控應用退出并重新加載運行。由于第四章的實驗針對控制器軟件重啟，本章主要描述故障余度控制應用軟件重啟流程。

余度通道控制應用軟件重啟流程如下： 1）系統軟件根據空中/地面狀態判定確定是否進行控制程序映像校驗； 2）系統軟件加載控制程序到內存； 3）余度同步：同步采用握手的算法進行。同正常啟動流程。通道間的握手同步信號傳輸需要具有可接受的時效，不能耗時過長，以免失去及時握手的意義。因此，可以采用通道間直接的電平信號連接；而系統中其他通道根據余度表決的時序要求，也正進行控制周期同步。控制周期同步算法與啟動同步一致。只是同步等待的時間不同。啟動同步的握手超時時間可以設計的略長，可以大于控制周期，以確保不因時間太短而不能建立與其他通道的同步。重啟通道正常情況下可以與系統中其他通道完成同步。同步成功結束后，各個通道標記重啟通道為重啟同步成功狀態。

4）系統軟件進行余度間數據遷移：同步結束后，需要進行余度間數據遷移工作，同步余度控制程序間的狀態數據。因為一般的控制應用軟件都是所謂“有狀態”程序，程序輸出依賴于當前的程序狀態。如果不進行狀態數據同步，導致通道間輸出超出差異閾值，重啟通道仍然會被認為故障； 重啟通道上的系統軟件在同步成功后，根據控制功能程序的周期執行耗時，延遲一段時間即開始啟動后續數據遷移工作和控制工作。其他通道只要在控制周期同步時，發現有新通道為重啟同步成功狀態，即在同步成功后的同一個控制周期內，啟動數據遷移工作。如果和重啟通道同步上的其他通道有多個，簡單起見，重啟通道按系統設定的優先級先后持續接收通道發送的遷移數據。和重啟通道同步上的其他通道仍然需要發送遷移數據給重啟通道，以避免重啟通道優先認定的數據來源通道不能發送數據的情況。

余度間數據遷移在不透明方式（不透明方式需要控制功能程序的數據段及BSS段的內存部署位置是系統軟件已知的）處理視角下，程序的狀態數據從抽象的程序二進制實現上看，保存在程序進程空間的數據段、BSS段以及棧段上。重啟通道的控制程序可不遷移棧段數據。因為此時棧上保留的狀態信息，對控制邏輯而言并非必要。重啟通道控制程序可以重新建立自身的棧內容而不影響控制。 系統中其他通道在和重啟通道同步上的控制周期中，待正常的控制程序周期運行結束后，由系統軟件將控制功能程序數據段及BSS段內存數據內容通過CCDL一次性發送給重啟通道。 對于有指令支路及監控支路的系統，CCDL一般同時將數據傳輸給兩個支路。因此，遷移數據也同時傳輸給兩個支路，兩個支路的數據遷移工作可同時進行。

雙CPU運行模式對余度通道重啟的影響

當前工程所用飛控計算機一般為雙CPU架構，具有雙CPU的余度通道，又根據兩個CPU能否訪問外部外設而分為兩種模式：命令監控模式、雙命令模式。下面就雙CPU運行模式對余度通道重啟的影響進行分析。 一、命令監控模式 如本雙CPU余度通道故障，整個飛控計算機余度通道會被判故障，系統會減緩切除該余度通道。如不能恢復，則飛控計算機子系統其他通道表決出重啟指令使其重啟。該重啟指令也經過兩CPU間數據通道傳輸到監控通道（如圖1所示）。其他通道發出的重啟信號經兩個CPU板上的硬件重啟邏輯綜合后，可以發出使CPU外部中斷的信號，CPU系統軟件進行相應的中斷處理，如果需要進行系統級重啟，則向其他余度通告本通道重啟，通過系統重啟硬件端口輸出使能重啟信號。

圖1 命令監控重啟 重啟時，兩支路同時重啟。每個支路重啟過程如下： 1）CPU支路上電重啟； 2）系統軟件根據空中/地面狀態判定進行自檢、初始化； 3）系統軟件根據空中/地面狀態判定來確定是否進行控制程序映像校驗； 4）系統軟件加載控制程序到內存； 5）余度通道支路間同步：在余度通道作為一個整體與其他余度進行同步之前，兩個CPU支路間要先進行支路間同步。支路間同步需要的硬件支持是兩支路間的一對信號線連接。同樣是采用高低電平握手的方式進行同步； 6）余度通道同步：余度通道內支路同步成功后，指令支路輸出與其他余度通道進行高低握手的指令，指令支路也都獲取其他支路的電平信號，進行通道同步判斷； 7）系統軟件進行余度間數據遷移：余度通道的支路CPU與其他通道同步成功后，指令支路接收其他通道給本通道的遷移數據并轉發給監控支路。兩個支路的遷移過程同單CPU設計余度通道； 8）啟動控制功能及故障檢測：數據遷移結束后，相應支路的系統軟件啟動控制功能程序。

在下一個控制周期時刻到來時，系統軟件調度功能程序運行。控制功能程序因為是重啟后第一次被操作系統軟件調度，程序應從初始化運行。初始化又可能會破壞遷移過來的數據，因此，在程序入口設置一個表征是否已經初始化的全局變量。在數據遷移后，該全局變量已經設置為真，程序判斷為真，則不再進行相關初始化了，而直接進行控制功能。但是，某些通道號相關的變量若需要特殊處理，則需要進行初始化。后續，控制功能程序開始進行控制邏輯運行。同時，系統中其他余度通道，在數據遷移結束后的下一個控制周期，也將重啟通道的狀態置為有效，相應支路的狀態也在兩支路余度表決硬件邏輯中置為有效。

二、雙命令模式

1、 “主主”模式 雙命令模式下，當系統采用“主主”方式運行處理故障時，整個飛控計算機余度通道會被判故，系統對該通道實行減緩切除策略。如該通道最終被切除，即故障不能恢復，則飛控計算機子系統其他通道表決出重啟指令使其重啟，如圖2所示。 重啟時，兩支路同時重啟。支路重啟過程與命令監控模式的重啟過程相似，不同點在于：步驟6）余度通道同步。

圖2 “主主”模式重啟 “主主”模式下，余度通道內支路同步成功后，兩個支路輸出與其他余度通道進行高低握手的指令，兩支路余度表決硬件邏輯在指令未分離的情況下優選一路，并通過離散信號端口輸出高低電平給其他余度。兩個支路也都獲取其他支路的電平信號，進行通道同步判斷。 2、 “主備”模式 當系統采用“主備”方式運行處理故障時，整個余度通道仍然有一路CPU輸出，該余度通道不會被其他通道判故。系統會對通道內選出的（或主動報告的）故障支路實施減緩切除余度算法，直至多次重試失敗后，由兩支路余度表決硬件邏輯向故障支路發出重啟信號，如圖3所示。

故障支路重啟過程如下： 1）—4）與命令監控模式相同； 5）支路間同步:故障CPU支路間要先與正常支路進行支路間同步； 支路間同步后，不再如同“主主”故障處理方式，不再需要進行余度通道同步。

圖3 “主備”模式重啟 6）系統軟件進行支路間數據遷移:支路間同步成功后，正常支路獲知重啟支路同步成功狀態，開始在控制功能程序周期運行結束后，由系統軟件通過雙口RAM或PCI總線給重啟CPU支路發送遷移數據。重啟CPU支路接收遷移數據。遷移過程同單CPU設計余度通道； 7）啟動控制功能及故障檢測：數據遷移結束后，重啟支路的系統軟件啟動控制功能程序。控制功能程序進行控制，系統也重新開始故障檢測，包括兩支路間的自監控。

實驗與驗證

驗證環境由四余度飛控仿真計算機、仿真PC機和PC宿主機組成的硬件環境以及在各硬件上所運行的軟件組成的軟件環境共同構成，如圖4所示。實驗所用飛控計算機CPU為命令監控模式。 主機端軟件包括飛控機載軟件開發環境、主機端余度故障注入軟件（見圖5）、主機端余度運行與重啟過程監控軟件（見圖6）。

圖4 演示驗證環境構成圖

圖5 主機端余度故障注入軟件

圖6 主機端余度運行與重啟過程監控軟件 針對仿真設備節點故障、飛控節點故障以及飛控多余度故障進行驗證，具體情況如表1所示。 表1 仿真設備節點驗證測試項

在正確搭建驗證環境的情況下，飛控計算機故障驗證操作通用流程如下：

1）打開數據集中交換程序（即DataComm通信框架中心服務器）、飛控PC端代理軟件、各個仿真程序、主機端余度運行與重啟過程監控軟件和主機端故障注入軟件及操作連接上網絡服務節點；

2）給仿真飛控計算機上電；

3）等待主機端余度運行與重啟過程監控軟件顯示各仿真設備節點以及飛控余度各節點狀態正常；

4）操作主機端余度故障注入軟件對需要驗證的飛控余度節點注入測試故障；

5）觀察主機端余度運行與重啟過程監控軟件對應被測對象飛控余度節點狀態變化，即是否產生故障，根據具體故障類型，進入自動復位狀態或是等待用戶手動操作復位，復位后恢復正常運行狀態，同時可查看其它非被測飛控余度節點中其它通道狀態是否發生變化； 表1中“飛控余度的20個故障”包括：

1）同步故障導致的余度失效：故障模型使故障注入的飛控計算機余度不進行同步操作，不能與其它余度完成同步；

2）CCDL故障導致的余度失效：故障模型使故障注入的飛控計算機停止CCDL的輸入和輸出，模擬CCDL故障狀態；

3）通道故障邏輯導致的余度失效：故障模型使故障注入的飛控計算機停止通道故障邏輯的離散量輸入和輸出，模擬通道故障邏輯的故障狀態；

4）飛控計算機易失存儲器可持續故障導致的飛控計算機失效：故障模型持續的修改對飛控計算機輸出指令有影響的狀態或積分變量為一個錯誤值，引起飛控計算機余度輸出指令與其它余度產生足夠大的差異；

5）飛控計算機易失存儲器瞬時故障導致的飛控計算機失效：故障模型連續多個（3個以上）幀周期內修改對飛控計算機輸出指令有影響的狀態和積分變量為一個錯誤值，引起飛控計算機余度輸出指令與其它余度產生足夠大的差異；

6）飛控計算機輸入信號/通信可持續故障導致的飛控計算機失效：故障模型停止本飛控計算機余度的數據輸入，讓本飛控計算機余度認為沒有數據被接收進來，觸發余度飛控應用的對應處理程序；

7）飛控計算機輸入信號/通信瞬時故障導致的飛控計算機失效：故障模型連續多個（3個以上）幀周期停止本飛控計算機余度的數據輸入，讓本飛控計算機余度認為沒有數據被接收進來，觸發余度飛控應用的對應處理程序；

8）飛控計算機輸出信號/通信可持續故障導致的飛控計算機失效：故障模型停止本飛控計算機余度的數據輸出，讓其它飛控計算機余度發現本余度沒有數據輸出； 9）飛控計算機輸出信號/通信瞬時故障導致的飛控計算機失效：故障模型連續多個（3個以上）幀周期停止本飛控計算機余度的數據輸出，讓其它飛控計算機余度發現本余度沒有數據輸出；

10）飛控計算機處理單元可持續故障導致的飛控計算機失效：故障模型停止本飛控計算機余度的所有軟件（操作系統和應用軟件）運行，但由于操作系統的一些底層操作無法被完全停止，因此主要是停止應用軟件和操作系統對定時器中斷的響應，模擬處理單元故障導致的軟件完全停止運行的情況；

11）飛控計算機處理單元瞬時故障導致的飛控計算機失效：故障模型連續多個（3個以上）幀周期停止本飛控計算機余度的所有軟件（操作系統和應用軟件）運行，但由于操作系統的一些底層操作無法被完全停止，因此主要是停止應用軟件和操作系統對定時器中斷的響應，模擬處理單元故障導致的軟件在一段時間內停止運行的情況；

12）系統初始化軟件故障導致的飛控計算機操作系統失效：這種故障模型無法在飛控軟件運行過程中進行模擬，因為對應的初始化過程已經運行結束了，只能通過單獨給預期發生故障的余度固化一個特殊修改后的軟件映像，對應的軟件映像中會在第一次上電運行的系統初始化時觸發故障；

13）中斷/異常管理軟件故障導致的飛控計算機操作系統失效：故障模型在飛控軟件正常運行的過程中，模擬中斷/異常管理軟件，不對正常中斷進行處理，導致本余度飛控軟件運行出現故障；

14）設備驅動軟件故障導致的飛控計算機操作系統失效：故障模型在飛控軟件中模擬設備驅動軟件發生故障而不能正常工作，使得飛控軟件無法進行數據的輸入和輸出；

15）內存管理軟件故障導致的飛控計算機操作系統失效：這種故障模型無法在飛控軟件運行過程中進行模擬，因為飛控軟件在運行的內存分配都是靜態的，對應的內存分配是在系統初始化時進行的，在飛控軟件正常運行后對應的初始化過程已經運行結束了，只能通過單獨給預期發生故障的余度固化一個特殊修改后的軟件映像，對應的軟件映像中會在第一次上電運行的系統初始化時模擬內存管理軟件故障，使得操作系統在分配內存時出現故障；

16）運行調度軟件故障導致的飛控計算機操作系統失效：故障模型模擬飛控軟件中操作系統的運行調度軟件發生故障，讓各飛控應用軟件分區中的部分分區不能被調度運行；

17）時鐘管理軟件故障導致的飛控計算機操作系統失效：故障模型模擬飛控軟件中操作系統的時鐘軟件發生故障，讓操作系統無法有效的獲得時鐘數據；

18）輸入與監控軟件故障導致的飛控計算機應用軟件失效：故障模型模擬飛控軟件中應用軟件的輸入與監控軟件分區發生故障，不能有效的獲取該余度飛控計算機的輸入數據；

19）控制律解算軟件故障導致的飛控計算機應用軟件失效：故障模型模擬飛控軟件中應用軟件的控制律解算軟件分區發生故障，不能計算出正確的輸出指令數據；

20）輸出表決監控軟件故障導致的飛控計算機應用軟件失效：故障模型模擬飛控軟件中應用軟件的輸出表決監控軟件分區發生故障，使得該飛控計算機余度不能輸出指令數據； 實驗結果為： 對于飛控節點單余度故障驗證，余度運行與重啟過程監控軟件界面被測飛控計算機節點狀態變化如下：

1）被測飛控計算機節點注入故障后，通道狀態先由正常運行狀態切換為故障觸發狀態，其它飛控節點的其它余度通道狀態按照相對絕對通道轉換關系反應出被測飛控計算機余度故障；

2）被測節點本余度通道狀態切換為重啟狀態；

3）被測飛控計算機節點復位同步成功，并且恢復數據，余度系統計數也恢復正常。 對于硬件永久故障不可恢復驗證余度運行與重啟過程監控軟件界面被測飛控計算機節點狀態變化如下：

1）被測飛控計算機節點注入故障后，通道狀態先由正常運行狀態切換為故障觸發狀態，其它飛控節點的其它余度通道狀態按照相對絕對通道轉換關系反應出被測飛控計算機余度故障；

2）被測節點本余度通道狀態切換為重啟狀態； 3）被測飛控計算機節點無法自動復位成功，手動在“主機端余度故障注入軟件”點擊該通道重啟后，依舊無法復位成功，保持被切除狀態。 被測84個測試用例全部通過實驗。

結論

1）飛控計算機余度通道的CPU運行模式（命令監控模式以及雙命令模式）對通道重啟流程的大框架影響不大，區別主要在支路間同步算法；

2）飛控計算機單故障余度通道重啟可以恢復第四章實驗所羅列的20類故障，使重啟余度與正常余度同步并恢復正常運行。而對于永久性的硬件故障，無法通過重啟余度恢復；

3）余度重啟機制效果穩定，能夠在四余度飛控計算機的環境中，在單故障余度的情況下，使重啟故障余度能夠與正常運行的余度同步，從而提高飛控系統的可靠性，保證飛行控制系統的品質。

審核編輯：黃飛