深空探測運載火箭多彈道選擇技術(shù)全系統(tǒng)測試研究

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

（北京宇航系統(tǒng)工程研究所，北京100076）

1 引言

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

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

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

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

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

上述系統(tǒng)方案初看起來沒有問題，但最終的事故調(diào)查結(jié)果表明，系統(tǒng)方案的具體實現(xiàn)細節(jié)存在以下重大安全問題：

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

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

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

2 運載火箭多彈道選擇技術(shù)

2.1 多彈道選擇技術(shù)的提出

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

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

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

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

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

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

（1）控制系統(tǒng)單機諸元：慣性器件誤差系數(shù)等；

（2）光學(xué)瞄準諸元：光學(xué)瞄準參數(shù)等；

（3）發(fā)射點及彈道諸元：發(fā)射點參數(shù)、理論發(fā)射方位角、導(dǎo)引計算參數(shù)、飛行程序角、迭代制導(dǎo)諸元、關(guān)機計算與控制諸元等。

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

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

2.3 多彈道選擇技術(shù)電氣實現(xiàn)方案

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

2.3.1 發(fā)射窗口時間的確定

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

X

h

X

min

X

s），在任務(wù)發(fā)射前確定。

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

2.3.2 發(fā)射時間選取的原則

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

圖1 點火時間與彈道選擇區(qū)間關(guān)系圖Fig.1 Relationship between fire time and time zone for trajectory selection

如果發(fā)射時間處于這5 個窄窗口中的某一個區(qū)間內(nèi)，則控制系統(tǒng)地面軟件在發(fā)射前就會自動選擇該區(qū)間對應(yīng)的彈道，點火后火箭就會使用該彈道飛行。

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

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

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

2.3.3 最終飛行彈道的確定

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

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

（1）為提高發(fā)射流程可靠性，盡量避免多次重新選擇彈道?？紤]到射前流程的各個環(huán)節(jié)均有推遲發(fā)射的可能，因此選擇確認最終飛行彈道的時機，應(yīng)盡量靠近點火，以避免多次選擇確認最終飛行彈道。

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

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

（4）考慮因故障而推遲的情況，若彈道選擇完成后，沒有在本窗口時間內(nèi)完成點火任務(wù)，控制系統(tǒng)地面主控計算機應(yīng)在本條彈道即將結(jié)束的前

N

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

N

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

3 多彈道選擇技術(shù)的測試策略

3.1 全系統(tǒng)測試的難點

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

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

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

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

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

由于多彈道選擇技術(shù)實現(xiàn)的復(fù)雜性、真實發(fā)射時測試發(fā)射流程中多個系統(tǒng)協(xié)同工作時工況的多樣性，開展專門針對多彈道選擇技術(shù)應(yīng)用的全系統(tǒng)測試，就成了保障深空探測任務(wù)成功的重要一環(huán)。

3.2 基于需求的系統(tǒng)測試技術(shù)［11～14］

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

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

由于系統(tǒng)本身的固有復(fù)雜性，在測試發(fā)射流程中，還經(jīng)常會有大大小小的異?，F(xiàn)象，這都對相關(guān)系統(tǒng)的射前流程動作有著較大的影響，在全系統(tǒng)測試時，必須考慮這些可能發(fā)生的故障對射前流程的影響。在設(shè)計系統(tǒng)測試用例時，必須考慮到系統(tǒng)應(yīng)用的這種需求，考慮如何在測試發(fā)射流程中注入故障［8～10，19］。

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

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

4 多彈道選擇技術(shù)全系統(tǒng)測試方案

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

4.1 系統(tǒng)真實應(yīng)用場景

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

4.1.1 開算及彈道選擇過程

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

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

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

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

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

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

4.1.2 彈道選擇結(jié)果確認過程

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

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

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

4.1.3 點火過程

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

4.2 測試方案設(shè)計原則

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

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

（2）正常狀態(tài)分為模飛狀態(tài)測試和發(fā)射狀態(tài)測試；

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

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

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

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

4.3 測試用例設(shè)計

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

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

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

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

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

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

故障模式實現(xiàn)情況：發(fā)射狀態(tài)，計劃實際飛行彈道諸元2，但由于故障處置，導(dǎo)致從彈道2 推遲至彈道4。

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

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

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

故障模式實現(xiàn)情況：在彈道1 點火窗口前沿-3min啟伺服機構(gòu)、-90s 轉(zhuǎn)電后又推遲到彈道2。

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

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

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

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

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

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

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

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

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

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

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

故障模式實現(xiàn)情況：在彈道1 點火窗口前沿-3min啟伺服機構(gòu)、-90s 轉(zhuǎn)電后又推遲到彈道2。

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

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

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

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

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

之后當(dāng)時間已經(jīng)超出五條彈道的50min 窗口后，重新組織發(fā)射。重新給控制系統(tǒng)箭上設(shè)備加電，按照超出全部窗口時間后默認選擇彈道5 組織發(fā)射。

4.4 小結(jié)

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

5 結(jié)束語

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