深空探測運載火箭多彈道選擇技術全系統測試研究

董余紅 王建明 黃 兵 劉 秉 李 茂 胡元威

（北京宇航系統工程研究所，北京100076）

1 引言

深空探測一般是指月球探測以及更遙遠星體、空間的宇宙探測活動，比如火星探測、太陽探測、小行星探測、木星探測以及太陽系邊界探測活動等。深空探測任務也是航天技術發展到一定階段的必然方向。

由于任務特點，深空探測任務（月球探測、火星探測等）的發射機會都很寶貴，例如，火星探測任務每隔26 個月才有一個發射機會，且發射窗口寬度也嚴格受限。探測器在飛行過程中，也需要進行多次軌道中途修正。為提高發射成功率，拓展發射窗口寬度，同時節省探測器系統在軌道修正過程中的推進劑消耗量，運載火箭系統在發射流程中采用了在多彈道裝訂及自動選擇技術。

國內及國外航空航天領域多年實踐經驗證明，在系統正式投入使用前，進行充分的測試，是保證系統能夠正常工作的重要保證。在航空航天飛行器飛行前若沒有對系統進行充分的測試，尤其是在某些故障工況下測試不夠充分，則飛行過程中萬一發生故障，往往會造成災難性后果。

2018年10月29日，印尼獅航JT610 航班的波音737 MAX8 客機，起飛13min 后墜海。2019年3月10日，埃塞俄比亞航空ET302 航班的波音737 MAX8 客機起飛6min 后即墜毀。從雷達數據上看，這兩架失事的波音737 MAX8 客機最后的飛行軌跡都是高速俯沖墜地。

為了可靠采集飛行中的攻角狀態，波音737 MAX8 客機設置了3 個冗余的攻角傳感器。為了確保該型飛機在飛行中不發生災難性的失速風險，該型飛機的自動駕駛系統設置了一個失速保護子程序，以攻角傳感器測得的飛行中攻角信息為輸入，當飛行中攻角越來越大以至于將要發生失速風險時，失速保護子程序就通過控制水平尾翼來壓低機頭，從而避免即將到來的失速風險。

上述系統方案初看起來沒有問題，但最終的事故調查結果表明，系統方案的具體實現細節存在以下重大安全問題：

（1）失速保護子程序未能正確的利用冗余的攻角傳感器給出的冗余信息，而是僅僅根據主攻角傳感器的輸入信息來進行故障處置。在主攻角傳感器故障情況下，若異常輸出為攻角變大，這時即使另兩個攻角傳感器輸出均為正常，失速保護子程序仍然會錯誤地只根據異常的主攻角傳感器數據啟動故障處置程序。在只有主攻角傳感器輸出異常的情況下，若能采取“三取二”的方式進行故障判決，就能避免上述故障。

（2）飛機飛行軟件設計時，對飛行軟件主觀能動性考慮太少，當軟件認為有失速危險時，在手動模式下也剝奪了飛行員正確干預飛行過程的權力。在飛行員發現飛機異常俯沖后，立即手動將飛機設置成抬頭狀態，但稍后失速保護子程序仍然會將飛機設置成俯沖狀態，且這個過程會一直進行下去。

從上述分析過程可見，如果波音737 MAX8 客機在投入正式飛行前，在進行全系統測試時，測試用例中包含了“主攻角傳感器故障”這一用例，那么還是很有可能提前發現這一重大安全隱患并及時進行方案改進設計的。由此可見，對包含軟件在內的全系統進行包含各種故障工況下的全面測試的極端重要性。

2 運載火箭多彈道選擇技術

2.1 多彈道選擇技術的提出

深空探測任務（月球探測器任務、火星探測器任務等）一般均要求運載火箭具有較大的運載能力，因此一般采用大型低溫液體運載火箭來執行相應的探測器發射任務。

運載火箭在探測器允許的發射窗口范圍內，采取了“窄窗口、多彈道”發射方案，即將探測器允許的發射窗口劃分為多個寬度相同、連續的發射彈道窗口，多個窄窗口的總寬度即為探測器允許的發射窗口寬度。

對每個窄窗口均設計一條對應的發射彈道（如果在該窄窗口點火發射，在飛行中就使用該條彈道），在運載火箭發射流程中，根據具體的發射點火時間，由火箭系統自動選擇飛行使用的發射彈道。由于在每個發射窗口可有針對性的設計飛行彈道，因此這也拓展發射窗口寬度。

這樣，如果由于某種原因在第一個發射窗口未能將火箭發射出去，只要推遲發射時間還在探測器允許的發射窗口內，就可根據重新確定的發射時間，選擇最合適的發射彈道，再次組織發射，既達到了拓展探測器發射窗口、提高發射概率的目的，又達到了節省探測器系統在后續軌道修正過程中的推進劑消耗量的目的。

2.2 運載火箭射前需要裝訂的諸元

運載火箭控制系統射前需要裝訂的諸元參數一般分為以下三類：

（1）控制系統單機諸元：慣性器件誤差系數等；

（2）光學瞄準諸元：光學瞄準參數等；

（3）發射點及彈道諸元：發射點參數、理論發射方位角、導引計算參數、飛行程序角、迭代制導諸元、關機計算與控制諸元等。

上述三類諸元由多個諸元文件表示，分別為控制系統單機諸元文件、光學瞄準諸元文件、發射點及彈道諸元文件。其中，控制系統單機諸元和瞄準諸元與發射日當天選擇的飛行彈道無關，而發射點及彈道諸元，與飛行彈道密切相關。

因此，對采用了“窄窗口、多彈道”發射方案的深空探測任務，對每一條彈道，都需要設置一個同具體彈道密切相關的發射點及彈道諸元文件，在射前流程中，將多個彈道的發射點及彈道諸元文件均上傳給箭載計算機，并在發射前由運載火箭系統根據具體的發射點火時間，來自動選擇飛行過程中所使用的彈道諸元。

2.3 多彈道選擇技術電氣實現方案

對采用了“窄窗口、多彈道”發射方案的深空探測任務，在運載火箭發射流程中要裝訂多條彈道諸元，并在發射點火前來最終選擇、確認具體飛行中使用的彈道諸元。

2.3.1 發射窗口時間的確定

深空探測任務探測器的發射窗口，由相關設計文件提前確定，因此進入發射流程前，發射窗口時間是已知的。發射任務的具體北京時間（

X

h

X

min

X

s），在任務發射前確定。

給定這兩個輸入后，在射前流程中，就可由控制系統地面軟件根據該探測器的發射窗口開始、結束時間及窄窗口的個數與寬度，計算出多條彈道窗口的具體開始、結束時間，并在軟件界面直觀的顯示出當前時間與多個發射窄窗口之間的關系（距發射窗口還有多長時間、已在某個發射窗口等）。

2.3.2 發射時間選取的原則

以某深空探測器任務為例進行說明。該探測器允許的發射窗口為50min 窗口，彈道設計時將該50min 窗口劃分為5 個窄窗口，分別對應5 條彈道，其中每條彈道的窗口寬度為10min，如圖1所示。

圖1 點火時間與彈道選擇區間關系圖Fig.1 Relationship between fire time and time zone for trajectory selection

如果發射時間處于這5 個窄窗口中的某一個區間內，則控制系統地面軟件在發射前就會自動選擇該區間對應的彈道，點火后火箭就會使用該彈道飛行。

雖然對于每條彈道的10min 窗口寬度，都對應一條彈道，但實際上該彈道是按照在該10min 區間的中點發射最優來設計的，即點火時間應盡量靠近每條軌道的中點時間，這樣從節省器箭分離后探測器實施軌道機動耗費的推進劑量最少的角度考慮，效果是最好的。

當然，發射時間的確定，還需要考慮很多其他因素。一般來說，大型低溫運載火箭同常規推進劑運載火箭相比，射前更容易出現狀況，而深空探測任務的發射窗口一般間隔也較長（如火星探測器每隔26 個月才有一次組織發射的機會）。

為了確保在寶貴的任務窗口期成功組織發射，在確定任務第一條彈道的發射窗口時，還是應該盡可能的預留較長的發射窗口，選擇第一條彈道窗口的開始時間作為發射時間，而后續推遲發射后的發射時間，可按照后續彈道窗口的中點進行選擇。

2.3.3 最終飛行彈道的確定

最終飛行彈道的選擇，取決于點火時間處于發射窗口的位置，最終飛行彈道的確認流程如圖2所示。在考慮具體實現方案時，需考慮如下因素：

圖2 最終飛行彈道確認流程Fig.2 Confirmation process for final trajectory

（1）為提高發射流程可靠性，盡量避免多次重新選擇彈道。考慮到射前流程的各個環節均有推遲發射的可能，因此選擇確認最終飛行彈道的時機，應盡量靠近點火，以避免多次選擇確認最終飛行彈道。

（2）為確保彈道選擇的正確性，箭載計算機在明確了飛行使用的彈道諸元后，具備點火前進行人工確認的條件。控制系統地面主控計算機軟件在確認彈道號，并上傳給箭載計算機后，箭載計算機在進行必要的計算后，將同該條彈道相關的具體計算結果信息回傳給地面主控計算機，并將最終發射諸元并顯示在地面主控軟件界面上，供人工確認。

（3）由于箭載計算機飛行軟件開算后需要使用最終飛行彈道諸元數據來建立參考坐標系初始值，因此確認最終飛行彈道的時間不能晚于箭載計算機飛行軟件開算建立初值的時間。

（4）考慮因故障而推遲的情況，若彈道選擇完成后，沒有在本窗口時間內完成點火任務，控制系統地面主控計算機應在本條彈道即將結束的前

N

s（即下一條彈道窗口開始前

N

s）進行提示，允許再次選擇彈道。重新選擇彈道后，箭上飛行軟件重新進行發射慣性坐標系初值計算；且重新選擇彈道可以在控制系統箭上設備不斷電、不重新上傳飛行程序的條件下進行。

3 多彈道選擇技術的測試策略

3.1 全系統測試的難點

如前所述，多彈道選擇技術的正確應用，是確保深空探測技術成功的重要保障。

軟件系統在研制完成后，需要進行軟件本身相關的測試項目，如軟件單元測試、配置項測試、第三方評測等。軟件本身的這些測試項目，對于軟件在自己的運行環境中的可靠性，可以給出初步的評價，但軟件在復雜的真實發射流程中，且在可能存在各種故障的情況下，整個系統的工作如何，就需要通過全系統測試來進行考核了。

全系統測試為在真實使用環境下，對包含軟件、硬件的整個系統進行的全面測試，驗證軟件、硬件對系統定義的滿足性，系統測試需要軟件測試人員同系統人員共同參加。

運載火箭系統是一個復雜航天巨系統，用來實現多彈道選擇技術的軟、硬件系統，也是一個包含了多套設備、多個軟件、不同通信鏈路、箭上地面設備協同工作才能實現的系統，且為了確保航天任務的萬無一失，這些設備、軟件大多采取了不同程度的冗余設計。

多彈道選擇過程是在點火前25s 開始進行，時間非常緊迫，且點火前各系統發射操作較多，在多彈道選擇技術應用過程中，除了考慮本系統的主要設備可能出現故障外，還要考慮在多彈道選擇過程中外系統出現故障時對本系統操作的影響，系統要能夠正確應對這些不利影響，并通過相應的故障處置措施，將這些點火前故障的影響控制在最小范圍。

由于多彈道選擇技術實現的復雜性、真實發射時測試發射流程中多個系統協同工作時工況的多樣性，開展專門針對多彈道選擇技術應用的全系統測試，就成了保障深空探測任務成功的重要一環。

3.2 基于需求的系統測試技術［11～14］

基于需求的測試是一種系統化的測試用例設計方法。采用這種方法來開展測試用例設計，不僅需要對系統本身的功能、性能需求有較為深刻的掌握，更重要的是還需要對在大系統協同工作的情況下，當工作流程中由于本系統或外系統的原因而發生故障時的故障處置措施。

火箭發射過程就是個典型的多個復雜系統協同工作程度特別高、工作時間節點要求特別嚴的一個大系統工程。在射前工作流程中，控制系統、動力系統、測量系統、總控系統、發射支持系統等多個系統的射前動作特別多、各大系統的主要動作之間還存在著互相制約、互為前提的復雜關系，且某些動作之間還有這極其嚴格的時間約束關系。

由于系統本身的固有復雜性，在測試發射流程中，還經常會有大大小小的異常現象，這都對相關系統的射前流程動作有著較大的影響，在全系統測試時，必須考慮這些可能發生的故障對射前流程的影響。在設計系統測試用例時，必須考慮到系統應用的這種需求，考慮如何在測試發射流程中注入故障［8～10，19］。

對于實現多彈道選擇技術的軟硬件系統，各軟、硬件大多進行了不同程度的冗余設計，這種基于測試發射流程的系統，在全系統測試階段進行故障注入時，一般采用基于測試流程的操作注入方法。

由于航天系統工程的固有復雜性，考慮多系統協同工作時可能發生的故障模式，如果再考慮到多個系統的這些故障模式組合互相組合的各種情況，則系統故障模式數量將是一個較為龐大的數字。但任何工程問題都會有一定的資源、時間周期等種種約束。為了能在給定的資源和時間周期內完成全系統測試任務，就需要針對最有可能發生的，以及發生后危害影響較大的故障模式，有重點的開展全系統測試用例設計。這同樣也需要設計者對系統需求有著極為深刻的理解。

4 多彈道選擇技術全系統測試方案

深空探測任務中應用的多彈道選擇技術，大大增加了控制系統射前流程的復雜性，同時由于彈道選擇時間非常靠近點火時刻，因此對操作的準確性、快速性都有極高的要求。為確保發射過程中的萬無一失，需要對相關軟、硬件的工作情況進行充分的測試，同時通過充分測試，也提高了參試人員對射前操作的熟練程度。

4.1 系統真實應用場景

基于需求的系統測試過程，首先需要深入了解、掌握系統的真實應用場景。多彈道選擇技術的真實應用場景，也就是運載火箭測試發射流程中的多彈道選擇過程，具體包括開算及彈道選擇過程、彈道選擇結果確認過程、點火過程。

4.1.1 開算及彈道選擇過程

控制系統地面主控軟件在點火前25s（該時間為考慮到射前流程的各種限制因素后確定的時間）彈出軌道確認對話框1，如圖3所示。

圖3 彈道確認對話框1Fig.3 1st trajectory confirmation dialog

主控軟件操作手按下“Ctrl+b”鍵后，即將主控軟件自動選擇的當前彈道序號發送給箭載計算機飛行控制軟件。

飛行控制軟件收到地面主控軟件發出的軌道選擇序號后，建立參考坐標系初值。初值建立好后，向主控計算機下傳彈道號、關鍵諸元、初值建立好標志等關鍵參數信息。

這里值得注意的是地面主控軟件在點火前25s彈出軌道確認對話框1，這里的25s 為考慮到射前流程的各種限制因素后確定的時間，稱為彈道確認時間，在每一條彈道對應的彈道窗口區間開始前25s，一直到該彈道窗口區間開始時間這段寬度為25s 的小區間，被稱為該條彈道的確認時間區間。

每當當前時刻進入到下一條彈道的確認時間區間后，主控軟件即彈出下一條彈道的確認對話框，提示用戶可將當前彈道切換到下一條彈道。此時，如果主控軟件操作手按下“Ctrl +b”鍵后，則將當前彈道切換到下一條彈道；若不進行任何操作，則箭上飛行軟件仍保持為上一次按下“Ctrl +b”鍵時選擇的彈道號，即使當前時間已經進入到下一條彈道的窗口區間內。

4.1.2 彈道選擇結果確認過程

地面主控軟件在收到飛行控制軟件下傳的彈道信息之后，會彈出彈道確認對話框2，如圖4所示。

圖4 彈道確認對話框2Fig.4 2nd trajectory confirmation dialog

主控軟件操作手需要在該對話框中點擊“確定”按鈕，并確認相關信息均為正確后，向控制系統指揮員報告“可以接通允許點火”。

4.1.3 點火過程

主控軟件操作手向控制系統指揮員報告“可以接通允許點火”后，控制系統指揮員向發控臺操作手下達“接通允許點火”口令，控制系統指揮員在發控臺接通允許點火后，向01 指揮員報告：“允許點火接通”。之后，01 指揮員適時開始點火倒計時步驟，倒計時結束后下達“點火”指令，再由控制系統指揮員最終向發控臺操作手轉述“點火”指令，并由發控臺操作手完成點火操作。

4.2 測試方案設計原則

在深空探測任務多彈道選擇功能的全系統測試方案設計上，采用基于需求的系統測試技術，通過深入分析運載火箭測試發射流程中的多彈道選擇過程中，所涉及到的各個環節、各種正常工作、異常工況下的系統應用需求；同時在測試資源、時間受限的情況下，結合系統真實應用中的風險模式、影響及危害性分析以及失效危害性分析、失效可能性分析工作結果，對測試優先級進行排序；同時考慮到在系統測試過程中所能采取的故障模式注入方法—“基于測試流程的操作注入”，擬定了如下測試方案設計原則，并按此原則設計了相應的測試用例。

（1）既要對正常功能下的多個測試狀態進行測試覆蓋，也要對多彈道選擇的各種異常模式進行測試覆蓋；

（2）正常狀態分為模飛狀態測試和發射狀態測試；

（3）在全系統模飛（模擬飛行）測試時，對于5條彈道的模飛諸元，也都要測試到，通過對飛行結果的判讀，確認彈道選擇、裝訂的正確性；

（4）發射狀態裝訂到箭載計算機內的彈道諸元為飛行時使用的正式諸元，對于5 條彈道的每一條正式彈道諸元，都要測試其自定選擇、裝訂、校驗功能的正確性；

（5）在設計異常模式的測試用例時，要考慮到彈道選擇的各種臨界情況，如：點火時刻處于彈道發射窗口前沿、后沿的，點火時刻超出窗口情況的等等；

（6）在設計異常模式的測試用例時，還要考慮彈道選擇過程中，執行彈道選擇操作的主控計算機出現故障，需要切換到備份機繼續完成彈道選擇過程的極端工況。

4.3 測試用例設計

按照上述原則，在某深空探測任務中，按照正常流程、異常流程分為兩個大類，正常流程中，覆蓋模飛狀態選擇5 條彈道和發射狀態5 條彈道；異常流程中，按照發射流程各個關鍵節點，模擬發生各類故障后需要推遲發射的情況，對于多彈道選擇技術，共開展全系統級的測試23 次，其中覆蓋正常彈道選擇14 次，異常情況9 次。

通過本文設計的全系統測試用例檢驗，證明目前電氣系統實現方案可以滿足深空探測任務5 條彈道自動裝訂及選擇的要求。

以下給出異常情況下的測試用例：

（1）故障模式：推遲發射，重選彈道。

故障模式實現情況：控制系統啟動主控軟件測試程序時，設定點火時間為彈道1 窗口前沿，進入-5min 流程時，由01 下達推遲15min 口令，將點火時間推遲至彈道2 窗口中點。

（2）故障模式：推遲發射，直接選擇彈道4。

故障模式實現情況：發射狀態，計劃實際飛行彈道諸元2，但由于故障處置，導致從彈道2 推遲至彈道4。

（3）故障模式：推遲發射，選擇彈道后終止發射。

故障模式實現情況：模擬在彈道4 的點火時間-3min 啟伺服機構、 -90s 轉電后又推遲到彈道5窗口，之后又終止發射的過程。

（4）故障模式：推遲發射，選擇彈道，推遲發射，重選彈道。

故障模式實現情況：在彈道1 點火窗口前沿-3min啟伺服機構、-90s 轉電后又推遲到彈道2。

按照彈道2 組織發射，確認完彈道2 之后，又由于某種原因，推遲到彈道3。

之后按照彈道3 的點火窗口前沿組織發射。

（5）故障模式：推遲發射，選擇彈道后沿點火。

在點火前彈出彈道確認對話框，提示確認下一條彈道，不理會該提示。

故障模式實現情況：對在彈道2 窗口后沿先確認彈道2，在點火前進入彈道3 的彈道確認窗口，但最終仍在彈道2 的點火窗口內點火的過程進行驗證。

在彈道2 點火窗口后沿7min 時進入-3min 程序，啟伺服機構、 -90s 轉電，之后準備在彈道2 組織發射時，在確認彈道2 之后，在接通允許點火前，主控軟件提示需要確認上傳彈道3，不理會該提示，直接在彈道2 的窗口后沿點火。

（6）故障模式：推遲發射，計劃選擇彈道后沿點火。在點火前彈出彈道確認對話框，提示確認下一條彈道，此時重選下一條彈道，按照下一條彈道組織發射。

故障模式實現情況：對在彈道2 窗口后沿先確認彈道2，在點火前進入彈道3 的窗口，確認彈道3，最終在彈道3 的點火窗口內點火的過程進行驗證。

（7）故障模式：在前一個彈道窗口后沿組織發射，臨近點火時，進入下一個彈道的窗口前沿，仍然按照前一個彈道發射。

故障模式實現情況：預定彈道2 窗口后沿點火。在選擇彈道2 之后不久，主控軟件彈出提示框，提示可以選擇彈道3，不理會提示，在進入彈道3的點火窗口后，按照彈道2 點火。

（8）故障模式：推遲發射，箭上斷電，重新進入-1小時發射流程，重新上傳飛行程序，選擇彈道。

故障模式實現情況：在彈道1 點火窗口前沿-3min啟伺服機構、-90s 轉電后又推遲到彈道2。

之后又由于需要推遲較長時間，需要給控制系統箭上設備斷電，之后按照彈道4 的點火窗口前沿重新組織發射的過程。

（9）故障模式：推遲發射，后端主控計算機甲乙機切換，箭上斷電，重新進入-1 小時發射流程，重新上傳飛行程序，選擇彈道。

故障模式實現情況：在彈道1 點火窗口前沿-3min啟伺服機構、-90s 轉電，之后準備在彈道1組織發射時，在確認彈道1 的兩個步驟中（第1 步為上傳，第2 步為確認是否正確），當完成了第一個步驟的確認后，模擬后端主控計算機甲機故障，切換到乙機，在乙機上接著進行彈道1 確認流程的第二個步驟。

在主控計算機乙機完成對彈道1 的確認流程后，又由于故障，需要推遲到彈道2 發射。此時控制系統僅斷助推、一級伺服機構，箭上設備不斷電。

當準備在彈道2 組織發射時，又由于故障需要推遲較長的時間，需要給控制系統箭上設備斷電，在主控乙機上完成斷電流程。

之后當時間已經超出五條彈道的50min 窗口后，重新組織發射。重新給控制系統箭上設備加電，按照超出全部窗口時間后默認選擇彈道5 組織發射。

4.4 小結

通過對多彈道選擇技術進行全系統的測試，覆蓋了多彈道原則射前流程中可能遇到的窗口前沿、后沿等各種臨界條件及設備主、副機切換等惡劣工況，對正式執行任務過程中全系統箭上、地面，軟、硬件在各種情況下的工作的正確性、系統可靠性進行了全面驗證，確保深空探測任務能夠按時發射。

5 結束語

本文通過從深空探測任務的需求出發，提出在運載火箭測試發射中應用多彈道選擇技術，既拓展了探測器發射窗口、提高了發射概率，又節省了探測器系統在后續軌道修正過程中的推進劑消耗量。為確保多彈道選擇技術應用的萬無一失，采用了基于需求的系統測試技術，深入分析運載火箭測試發射流程中的多彈道選擇過程中，所涉及到的各個環節、各種正常工作、異常工況下的系統應用需求，對多彈道選擇技術進行全系統的測試，確保了多彈道選擇技術在“天問一號”和“嫦娥五號”兩次深空探測任務中的成功應用。