謝 望，蘭旭東，高 飛，趙新航，衛(wèi)吉祥，徐 昕

（上海航天電子技術研究所，上海 201109）

0 引言

地面測發(fā)控系統(tǒng)是運載火箭地面系統(tǒng)的重要組成部分，負責完成運載火箭的集成綜合測試和發(fā)射試驗［1-5］。而在運載火箭地面測發(fā)控系統(tǒng)中，軟件是重要的一環(huán)。軟件質量和軟件的可靠性是軟件生存的基本條件［6-7］，也是軟件人員追求的目標，提高軟件質量是軟件開發(fā)過程中的關鍵問題［8］。提高軟件質量和可靠性通常有兩種方法：避開錯誤和容錯。任何軟件都不能做到?jīng)]有錯誤，因此完全避開錯誤是不可能的，容錯技術可以使錯誤發(fā)生時系統(tǒng)不受影響或受到的損害最小，冗余技術是容錯方法中的主要技術［9-11］。

為了避免某個部件故障給系統(tǒng)工作帶來影響，通常采用部件的備份冗余設計方案，在多軟件協(xié)同工作系統(tǒng)中，任何一個軟件發(fā)生故障，都與可能導致整個軟件系統(tǒng)無法正常工作，而通常軟件也可以進行備份冗余設計。在多軟件組成的軟件系統(tǒng)中，可以對某個軟件進行備份，如果這個軟件發(fā)生故障，則可以立即啟動備份計算機上的備份軟件繼續(xù)工作，達到不影響整體軟件系統(tǒng)運行的效果［12-13］。

目前航天八院運載地面測發(fā)控系統(tǒng)領域，還未開展核心軟件熱備冗余自主切換設計，地面核心軟件運行故障會直接導致試驗停滯，影響試驗進度及測試效率。隨著航天事業(yè)的迅猛發(fā)展，航天發(fā)射任務日益繁重，呈現(xiàn)任務高密度常態(tài)化、任務并行多和技術狀態(tài)新等新特點，對地面核心軟件系統(tǒng)的可靠性提出了更高要求，如何解決核心關鍵軟件可靠性問題是本論文研究的重點。

在運載火箭試驗中，地面測發(fā)控系統(tǒng)的前置測控軟件具有實時性強、可靠性高、數(shù)據(jù)量大和接口關系復雜等特性，主要完成測量數(shù)據(jù)實時采集、實時數(shù)據(jù)處理、狀態(tài)顯示和通道控制等任務，其重要性不言而喻。前置測控軟件的可靠運行，對實現(xiàn)實時測量與控制至關重要，如果前置測控軟件發(fā)生故障，則會直接導致試驗的停止。

在上述背景下，本論文從提升核心軟件可靠性方向出發(fā)，研究在線熱備冗余切換技術，在軟件一度故障情況下，可實現(xiàn)軟件冗余系統(tǒng)自主切換，提升軟件系統(tǒng)整體可靠性，降低個別軟件運行故障對試驗整體進程的影響，取消依托人工更換備份設備的模式。

1 熱備冗余系統(tǒng)軟件設計原理

1.1 數(shù)據(jù)鏈路和軟件模塊

本論文設計的軟件冗余為主備雙軟件冗余，前置測控軟件分為主前置測控軟件和備前置測控軟件兩份，在正常工作狀態(tài)下，主前置測控軟件保持在工作狀態(tài)，備前置測控軟件保持在待機狀態(tài)。若主前置測控軟件發(fā)生故障，熱備冗余系統(tǒng)可以及時發(fā)現(xiàn)故障并進行處理，備前置測控軟件在要求的時間內，可以從待機狀態(tài)切換為工作狀態(tài)，繼續(xù)接替原來的主前置測控軟件進行工作。

在進行數(shù)據(jù)鏈路的設計之前，需要將主前置測控軟件和主備前置測控軟件以及地面測發(fā)控軟件系統(tǒng)之間的信息流進行梳理：如圖1所示，在沒有故障發(fā)生的正常狀態(tài)下，一條控制指令的執(zhí)行會產(chǎn)生5條數(shù)據(jù)流，下面按照圖中的編號順序進行說明，數(shù)據(jù)流①是從主機控制軟件發(fā)送到服務器軟件的控制指令的數(shù)據(jù)流，主機控制軟件每發(fā)送一條控制指令，就會出現(xiàn)一條數(shù)據(jù)流①，當數(shù)據(jù)流①到達服務器軟件之后，服務器軟件會對數(shù)據(jù)流①進行解析，重點關注的是數(shù)據(jù)流①中包含的信宿信息，信宿信息代表了此條指令最終需要到達的目的地。在主備前置測控軟件均開啟之后，它們都會主動和服務器軟件進行網(wǎng)絡連接。服務器軟件會將主備前置測控軟件的信宿設置為相同，那么服務器軟件在解析數(shù)據(jù)流①之后，會給主前置測控軟件和備前置測控均進行轉發(fā)數(shù)據(jù)，也就產(chǎn)生了數(shù)據(jù)流②和數(shù)據(jù)流③，這兩份數(shù)據(jù)流中的信息完全相同，均從服務器軟件發(fā)出，到達主前置測控軟件和備前置測控軟件。主前置測控軟件在收到數(shù)據(jù)流②之后，主前置測控軟件根據(jù)自身的 “主”狀態(tài)，進行數(shù)據(jù)流②的解析，解析之后獲取數(shù)據(jù)流②中包含的控制指令，然后根據(jù)控制指令對下游硬件板卡進行相應的控制，控制指令執(zhí)行結束之后，主前置測控軟件會在軟件頁面上進行控制指令的流程顯示，這樣試驗人員就可以清楚地知道控制指令的執(zhí)行進度。除了進行控制指令的顯示之外，主前置測控軟件還要將指令執(zhí)行結果進行回令，因此主前置測控軟件會進行數(shù)據(jù)流④的發(fā)送。數(shù)據(jù)流④到達服務器軟件之后，服務器軟件會解析數(shù)據(jù)流④中包含的信宿信息，主前置測控軟件在組織數(shù)據(jù)流④的時候，會在信宿信息中填入主機控制軟件的信宿編號，因此服務器軟件就會將數(shù)據(jù)流④轉發(fā)給主機控制軟件，因此也就有了數(shù)據(jù)流⑤，也就是從服務器軟件到主機控制軟件的控制回令。主機控制軟件在收到數(shù)據(jù)流⑤之后，進行數(shù)據(jù)流⑤的解析，在確認控制回令的正確性之后，這條控制指令的執(zhí)行才算正式結束。需要注意的是，備前置測控軟件在收到數(shù)據(jù)流③之后，備前置測控軟件根據(jù)自身的 “備”狀態(tài)，也會進行數(shù)據(jù)流③的解析，解析之后獲取數(shù)據(jù)流③中包含的控制指令，但是它并不會對下游硬件板卡進行控制，并且備前置測控軟件也不會發(fā)送回令數(shù)據(jù)流。從圖1 也可以發(fā)現(xiàn)，從服務器軟件到備前置測控軟件的信息流是單向的。解析完數(shù)據(jù)流②之后，備前置測控軟件會在頁面上進行控制指令的流程顯示，這樣試驗人員也可以清楚的在備前置測控軟件的頁面上獲取當前控制指令的執(zhí)行進度。

圖1 熱備冗余系統(tǒng)數(shù)據(jù)鏈路圖

在設計了雙軟件冗余之后，自動控制組合之間需要進行狀態(tài)同步、故障監(jiān)測和狀態(tài)切換，因此主前置測控軟件和備前置測控軟件之間也需要進行網(wǎng)絡通信。主前置測控軟件和備前置測控軟件之間，除了需要隨時知道彼此的故障與否，還需要知道對方目前的工作狀態(tài)，以便進行主備軟件切換判斷和工作流程進度上的接續(xù)。因此，主前置測控軟件和備前置測控軟件之間，設計了從主前置測控軟件到備前置測控軟件的實時 “心跳”信號，根據(jù) “心跳”信號，備前置測控軟件就

能實時地獲取到主前置測控軟件的狀態(tài)和是否出現(xiàn)故障信息。主前置測控軟件和備前置測控軟件之間，除了“心跳”信號之外，有時候還需要進行其他信息的交換，所以主前置測控軟件和備前置測控軟件之間也是需要設計通信數(shù)據(jù)鏈路。因此，就形成了主機控制軟件、主前置測控軟件和備前置測控軟件三者之間的數(shù)據(jù)鏈路。

在設計完熱備冗余系統(tǒng)數(shù)據(jù)鏈路之后，前置測控軟件就需要增加之前沒有的模塊，除了它本身的初始化PXI板卡、接受并解析控制指令和執(zhí)行控制指令之外，為了實現(xiàn)熱備冗余系統(tǒng)，需要增加 “心跳”信號發(fā)送模塊、“心跳”信號解析模塊、主備切換模塊和時串計數(shù)發(fā)送模塊。因此此處介紹一下前置測控軟件的模塊劃分，如圖2所示：前置測控軟件的核心功能是下游PXI硬件板卡的控制和數(shù)據(jù)監(jiān)測，圖中的控制指令接收模塊、控制指令解析模塊和控制指令執(zhí)行模塊用于PXI硬件板卡的控制，PXI板卡初始化模塊用于對PXI硬件板卡的初始化工作，工作過程中PXI硬件板卡的數(shù)據(jù)會上傳到前置測控軟件內部的監(jiān)測模塊，實現(xiàn)對PXI硬件板卡的數(shù)據(jù)實時監(jiān)測。新增的用于熱備冗余系統(tǒng)的模塊包括：軟件初始化模塊、主備狀態(tài)切換模塊、“心跳”信號發(fā)送接收模塊和時串計數(shù)接收發(fā)送模塊，軟件初始化模塊除了進行軟件和硬件的初始化之外，還用于熱備冗余系統(tǒng)的熱備冗余機制啟動。主備狀態(tài)切換模塊，接收“心跳”信號接收模塊傳遞過來的 “心跳”信號和時串計數(shù)接收模塊發(fā)送過來的時串計數(shù)信號，根據(jù)“心跳”信號決定前置測控軟件的主備狀態(tài)和后續(xù)的跳變動作執(zhí)行。上述幾個模塊就是前置測控軟件的主體部分，使得前置測控軟件具備了測控和主備切換的功能。

圖2 前置測控軟件內部模塊示意圖

1.2 “心跳”系統(tǒng)設計

在1.1中已經(jīng)說明，主備前置測控軟件之間同樣也需要進行通信，其目的是為了讓互相冗余的軟件知道彼此的狀態(tài)，進而決定自己的工作狀態(tài)和后續(xù)動作。設計的系統(tǒng)中，將主備前置測控軟件之間的通信信號稱為 “心跳”信號。在正常工作情況下，主前置測控軟件通過UDP單播方式向備前置測控軟件發(fā)送 “心跳”信號，備前置測控軟件接收主前置測控軟件發(fā)來的 “心跳”信號并進行解析，通過“心跳”信號獲取對方的工作狀態(tài)。當備前置測控軟件切換成主前置測控軟件之后也需要對外發(fā)送 “心跳”信號，因此主備前置測控軟件都要能夠具備發(fā)送 “心跳”信號和接收解析對方發(fā)來的“心跳”信號的功能。

在設計的軟件熱備冗余系統(tǒng)中，在正常狀態(tài)下，主前置測控軟件正常工作，除了進行工作操作之外，還向備前置測控軟件發(fā)出正常的 “心跳”信號，備前置測控軟件在正常狀態(tài)下，接收到主前置測控軟件發(fā)來的 “心跳”信號。如果主前置測控軟件下游的硬件發(fā)生了故障，主前置測控軟件監(jiān)測并發(fā)現(xiàn)了故障，此時主前置軟件本身沒有出現(xiàn)故障，依然能對外發(fā)送 “心跳”信號，但此時需要改變發(fā)送的“心跳”信號的內容，改為發(fā)送異常 “心跳”信號。而對于備前置測控軟件來說，不管是正常的 “心跳”信號還是異常的“心跳”信號，都需要進行接收和解析。

下面進行 “心跳”信號的內容和判別算法的說明，設計的“心跳”信號數(shù)據(jù)幀為10個字節(jié)，數(shù)據(jù)幀的內容如表1所示。

表1 心跳信號數(shù)據(jù)幀內容

幀頭采用運載火箭地面測發(fā)控系統(tǒng)的幀頭，第一個字節(jié)為0XEB，第二個字節(jié)為0x90，作為一個數(shù)據(jù)幀的開始，數(shù)據(jù)幀發(fā)送時間一共4個字節(jié)，填充這個數(shù)據(jù)幀的發(fā)送時間，心跳內容一共分為2種，在正常情況下，“心跳”信號中的心跳內容字節(jié)填充的是0x00，異常情況下 “心跳”信號中填充的心跳內容為0x55。檢驗和占據(jù)2個字節(jié)，將整個數(shù)據(jù)幀除去這2個字節(jié)的其他8個字節(jié)進行累和之后按位取反再加1，將計算結果填入這2個字節(jié)之中，幀尾為1個字節(jié)，填入0xDD，表明這個數(shù)據(jù)幀的結束。在設計的主前置測控軟件中，以200ms一幀的速率定時向備前置測控軟件發(fā)送“心跳”信號數(shù)據(jù)幀，備前置測控軟件進行 “心跳”信號的接收和解析，而關于心跳信號的判別算法，在1.3中進行詳細描述。

1.3 熱備冗余系統(tǒng)設計

圖3和圖4分別是設計的主前置測控軟和備前置測控軟件工作流程圖。切換系統(tǒng)是根據(jù) “心跳”信號進行工作的。對于主前置測控軟件來說，在工作的過程中需要對軟件下游硬件是否進行故障進行判斷，如果沒有出現(xiàn)故障，則發(fā)送正常的“心跳”信號給備前置測控軟件，并正常執(zhí)行工作流程，對主機控制軟件發(fā)來的控制指令進行解析，對軟件下游硬件下達執(zhí)行指令，實時顯示執(zhí)行的流程進度，同時按照主機控制軟件的要求給主機控制軟件進行每一條指令的回令。如果監(jiān)測中發(fā)現(xiàn)了軟件下游的硬件故障，則主前置測控軟件立即給備前置測控軟件發(fā)送異常的 “心跳”信號。

圖3 主前置測控軟件工作流程圖

圖4 備前置測控軟件工作流程圖

對于備前置測控軟件來說，在沒有切換成主前置測控軟件之前，同樣會收到主機控制軟件的指令信息，不同于主前置測控軟件，備前置測控軟件在收到控制指令并解析之后并不會對下游硬件下達執(zhí)行指令，也不會對主機控制軟件進行回令，只是實時顯示收到的流程進度，保證了系統(tǒng)中的三個軟件均能對外顯示系統(tǒng)中的工作執(zhí)行進度。

備前置測控軟件會實時接收主前置測控軟件發(fā)來的“心跳”信號并進行檢測，因為主前置測控軟件發(fā)生故障之后，會發(fā)送出異常的 “心跳”信號給備前置測控軟件，備前置測控軟件在解析 “心跳”信號數(shù)據(jù)幀的時候，解析出來的心跳內容如果為0x00，則表明這幀 “心跳”信號為正常的心跳信號，如果解析出來的數(shù)據(jù)幀中的心跳內容為0x55，則可以判定這幀“心跳”信號為異常 “心跳”信號。此時備前置測控軟件就會進行主備狀態(tài)的切換，在切換完成之后，由備前置測控軟件代替原來的主前置測控軟件參與工作，此時對接受到的主機控制軟件發(fā)送來的指令進行解析，并對下游硬件發(fā)送控制指令，同時給主機控制軟件發(fā)送回令，并且繼續(xù)顯示執(zhí)行的流程進度，這樣就保證了工作流程進度的持續(xù)和完整。除此之外，切換之后的軟件也會和故障前的主前置測控軟件一樣，對外發(fā)送 “心跳”信號，表明本軟件已經(jīng)切換為主軟件狀態(tài)，如果此時有新的前置測控軟件增加到系統(tǒng)中來，也會收到 “心跳”信號，就可以獲取到此時系統(tǒng)中的主前置測控軟件的存在信息。

如果主前置測控軟件發(fā)生運行異常退出、宕機，或者是主前置測控軟件發(fā)生網(wǎng)絡異常，無法連接上局域網(wǎng)，無法對外發(fā)送網(wǎng)絡信號，都會影響到 “心跳”信號的發(fā)送，則此時備前置測控軟件就無法接收到 “心跳”信號，對于備前置測控軟件來說也就是 “心跳”信號暫停，備前置測控軟件設計的解析 “心跳”信號模塊中，會首先解析 “心跳”信號的心跳內容，如果心跳內容為0x00，則表明這個心跳信號目前為正常的心跳信號，再進行下面的 “心跳”信號中包含的時間信息的解析，將 “心跳”信號中的4個字節(jié)表示的信息幀的發(fā)送時間解析出來，并和當前的備前置測控軟件這臺計算機上的系統(tǒng)時間進行比對，如果時間誤差在20ms以為，則認為此時的 “心跳”信號的時間正常，如果沒有收到 “心跳”信號，則隨著備前置測控軟件所在的計算機上的系統(tǒng)時間的更新，則計算出來的時長也就會逐漸變大，然后對時長進行判斷，設定的時長閾值為5秒，在超出時間閾值之后，備前置測控軟件就可以判定主前置測控軟件發(fā)生了運行異常退出、宕機，或者是網(wǎng)絡異常，此時備前置測控軟件就進行切換成主前置測控軟件進行后續(xù)工作。設計的時長閾值進行了可配置設置，針對不同的系統(tǒng)，可以靈活設置不同的時長閾值，保證了不同系統(tǒng)都能在有效并且合適的時間內完成切換。

在工作人員發(fā)現(xiàn)故障并進行故障的排除之后，重新啟動軟件，此時系統(tǒng)中已經(jīng)存在主前置測控軟件并以相同的速率對外發(fā)送“心跳”信號，在接收到 “心跳”信號之后，重新啟動的軟件自動設置自身模式為備份狀態(tài)，成為此時系統(tǒng)中的備前置測控軟件，對此時系統(tǒng)中正在工作的主前置測控軟件進行冗余備份，和之前的備前置測控軟件完全一樣，在收到控制指令并解析之后并不會對下游硬件下達執(zhí)行指令，也不會對主機控制軟件進行回令，只是實時顯示收到的流程進度。圖3和圖4是主前置測控軟件和備前置測控軟件的工作流程圖。

在實際進入工作狀態(tài)之前，需要將整個熱備冗余系統(tǒng)進行啟動，并進行初始化。在初始化階段，不論是主前置測控軟件還是備前置測控軟件，初始化的時間點，初始化所需要的時長均不固定，此時在初始化之前，熱備冗余系統(tǒng)容易產(chǎn)生誤判，如果工作人員首先開啟備前置測控軟件，備前置測控軟件在開啟之后的一段時間內均沒有開啟主前置測控軟件，那么按照熱備冗余系統(tǒng)的設計，在5秒鐘沒有接收到“心跳”信號之后，備前置測控軟件就會自動的切換自身的狀態(tài)變?yōu)橹髑爸脺y控軟件，如果此時工作人員繼續(xù)開啟主前置測控軟件，主前置測控軟件初始化之后監(jiān)測到自己收到了 “心跳”信號，則會將自身的狀態(tài)切換成備份狀態(tài)，這種跳變就屬于是無效跳變，不僅會浪費時間并且可能會對試驗進程造成影響。為了讓設計的熱備冗余系統(tǒng)的跳變更加的靈活和實用，將主備熱備冗余軟件設計成在初始化之后的檢測和跳變設置為非使能狀態(tài)，換言之在主備前置測控軟件初始化的時候，不進行故障狀態(tài)的監(jiān)測和切換，而在主機控制軟件中添加一條熱備冗余機制開啟指令，只有在工作人員將這條指令發(fā)送給初始化完成好的主備前置測控軟件之后，主備前置測控軟件在收到這條控制指令之后，才會開啟故障監(jiān)測和心跳模塊，讓熱備冗余切換變得更加的有規(guī)律和穩(wěn)定，消除了初始化過程中容易出現(xiàn)的問題。

下面對設計的熱備冗余系統(tǒng)的初始化進行描述，首先開啟服務器軟件，然后開啟主機控制軟件并和服務器軟件進行網(wǎng)絡連接，然后開啟主前置測控組合的計算機，開啟主前置測控軟件，等待初始化PXI板卡完畢，然后主前置測控軟件連接服務器軟件，連接完成之后再開啟備前置測控組合的計算機，開啟備前置測控軟件，同樣等待初始化PXI板卡完畢，再和服務器軟件進行網(wǎng)絡連接，網(wǎng)絡連接都完成之后，從主機控制軟件上向主備前置測控軟件發(fā)送熱備冗余機制開啟指令，將主備前置測控軟件的熱備冗余機制開啟，至此主備前置監(jiān)測組合的初始化工作才算完成。

2 故障情況分析及應對

在實際的前置測控軟件熱備冗余系統(tǒng)中，結合運載火箭地面測發(fā)控系統(tǒng)日常工作，從硬件和軟件層面，總結出如下6種故障模式，列舉在表2中。

表2 故障類型說明

在梳理了這幾種故障類型之后，在實驗室進行這幾種故障類型的模擬，用于檢測設計的熱備冗余系統(tǒng)是否可以監(jiān)測到故障并完成熱備冗余的切換。故障的模擬的試驗在實驗室手動進行，考慮到前置測控軟件的實際工作狀態(tài)，將模擬試驗的前置條件均設置為如下兩種情況：第一種是主機控制軟件還沒有給主前置測控軟件發(fā)控制指令，指令執(zhí)行流程并沒有開始，第二種是主機控制軟件已經(jīng)開始給主前置測控軟件發(fā)送控制指令了，在某條指令的執(zhí)行流程完全結束之后進行故障類型的模擬。

1）前置測控軟件異常退出和前置測控軟件異常宕機：這兩種故障情況是考慮到軟件本身層面和硬件層面，因為運載火箭試驗時間久，指令多，在上位機上長時間運行的前置測控軟件可能會出現(xiàn)異常崩潰退出，或者出現(xiàn)異常宕機的情況。在實驗室進行這種故障類型的模擬，分為如下幾種情況，第一種是將主前置測控軟件所在的計算機進行突然掉電處理，第二種是將主前置測控軟件進程強制關閉，第三種是使用主前置測控軟件提供的 “主軟件異常關閉”故障模擬按鈕進行這種故障的模擬，這個按鈕的底層實現(xiàn)邏輯也是將本軟件的進程強制關閉。在實驗室中進行兩種前置條件下的三種不同故障方式的模擬。主前置測控軟件在出現(xiàn)異常之后，備前置測控軟件會在較短的時間內進行狀態(tài)切換，從 “備”狀態(tài)切換為 “主”狀態(tài)，然后繼續(xù)和其他系統(tǒng)軟件一起準備進入工作狀態(tài)或者是繼續(xù)工作狀態(tài)。這種故障能及時切換的原因如下：主前置測控軟件出現(xiàn)了異常退出或者宕機的情況，影響到整個主前置測控軟件的運行，那么此時主前置測控軟件對外發(fā)送 “心跳”信號的動作也就無法完成了，此時系統(tǒng)中從主前置測控軟件發(fā)往備前置測控軟件的 “心跳”信號也會消失。待機狀態(tài)的備前置測控軟件在沒收到 “心跳”信號之后，進行時長統(tǒng)計，如果未收到的時長超過5秒鐘，也就是說主前置測控軟件出現(xiàn)了超過5秒鐘的軟件異常退出或者宕機，則可以判定為主前置測控軟件發(fā)生了軟件故障，就會進行后續(xù)主備狀態(tài)切換處理。

2）前置測控組合網(wǎng)卡故障：這種故障情況是考慮到前置測控軟件所在的上位機的網(wǎng)卡可能會在長時間工作的過程中出現(xiàn)硬件和驅動上的問題，通過在上位機上進行網(wǎng)卡適配器突然禁止使用的方法進行這種故障的模擬。在實驗室中進行兩種前置條件下的這種故障方式的模擬，試驗的結果是主前置測控軟件在出現(xiàn)異常之后，備前置測控軟件會在較短的時間內進行狀態(tài)切換，從 “備”狀態(tài)切換為“主”狀態(tài)，然后繼續(xù)和其他系統(tǒng)軟件一起準備進入工作狀態(tài)或者是繼續(xù)工作狀態(tài)。這種故障能及時切換的原因和1）相同，在出現(xiàn)網(wǎng)卡故障之后，主前置測控軟件同樣無法對外發(fā)送“心跳”信號，那么備前置測控軟件超過5秒鐘沒有收到心跳信號，則也可以判定為前置測控軟件發(fā)生了網(wǎng)絡故障，同樣進行后續(xù)主備狀態(tài)切換處理。

3）前置測控組合通信網(wǎng)線物理損壞：這種故障情況是考慮到在試驗的過程中，使用的網(wǎng)線可能會出現(xiàn)老化故障，或者是外界物理因素導致網(wǎng)線物理損壞，失去網(wǎng)絡通信功能。實驗室中進行了兩種不同的故障模擬方法，第一種是直接將主前置測控軟件所在的上位機和地面測發(fā)控系統(tǒng)交換機之間的網(wǎng)線進行剪斷，第二種是手動將主前置測控軟件所在的計算機和測發(fā)控系統(tǒng)交換機之間的網(wǎng)線進行斷開物理連接。在實驗室中進行兩種前置條件下的這兩種故障方式的模擬，試驗的結果是主前置測控軟件在出現(xiàn)這種網(wǎng)絡故障之后，備前置測控軟件會在較短的時間內進行狀態(tài)切換，從 “備”狀態(tài)切換為 “主”狀態(tài)，然后繼續(xù)和其他系統(tǒng)軟件一起準備進入工作狀態(tài)或者是繼續(xù)工作狀態(tài)。這種故障能及時切換的原因也和1）相同，在出現(xiàn)網(wǎng)線故障之后，主前置測控軟件同樣無法對外發(fā)送 “心跳”信號，那么備前置測控軟件超過5秒鐘沒有收到心跳信號，則也可以判定為主前置測控軟件發(fā)生了網(wǎng)絡故障，同樣進行后續(xù)主備狀態(tài)切換處理。

4）PXI硬件板卡檢測到數(shù)據(jù)邊界值溢出：在試驗的進行過程中，前置測控軟件不僅僅是對PXI硬件板卡下達控制指令，還需要監(jiān)測外界系統(tǒng)電纜傳遞過來的較多的數(shù)據(jù)信息，前置測控軟件在設計的過程中需要提前將需要監(jiān)測的各項數(shù)據(jù)的邊界值進行預設，當數(shù)據(jù)到達PXI硬件板卡之后，前置測控軟件的監(jiān)測模塊會對板卡采集到的數(shù)據(jù)進行判斷，如果數(shù)據(jù)在預先設計的范圍之內，那么認為這這個數(shù)據(jù)是正常的，如果收到的數(shù)據(jù)在預先設置的范圍之外，此時無法確定是傳遞過來的數(shù)據(jù)異常還是PXI硬件板卡的采集出現(xiàn)問題，那么此時前置測控軟件均可以認為是PXI硬件板卡出現(xiàn)故障，那么此時也應該進行主備軟件的跳變切換。對于這種故障類型，實驗室中進行的方法是將輸入PXI機箱的某幾項數(shù)據(jù)手動的設置超出最大值的數(shù)據(jù)值，觀察到主前置測控軟件在監(jiān)測到異常數(shù)據(jù)值之后，備前置測控軟件在較短時間內從 “備”狀態(tài)切換為 “主”狀態(tài)，然后繼續(xù)和其他系統(tǒng)軟件一起準備進入工作狀態(tài)或者是繼續(xù)工作狀態(tài)。這種故障能及時切換的原因是因為主前置測控軟件在監(jiān)測到異常的數(shù)據(jù)之后，判定是主前置PXI硬件板卡故障，然后立即對備前置測控軟件發(fā)送異常的 “心跳”信號，備前置測控軟件在收到異常的 “心跳”信號之后，可以認為主前置測控軟件發(fā)生了網(wǎng)絡故障，同樣進行后續(xù)主備狀態(tài)切換處理。

5）PXI硬件板卡控制接口返回值不正確：在試驗的進行過程中，前置測控軟件需要對PXI硬件板卡下達控制指令，但是控制指令的執(zhí)行可能成功也有可能失敗，PXI硬件板卡的驅動提供的底層執(zhí)行函數(shù)上，通過函數(shù)的返回值來判斷控制指令的執(zhí)行成功與否，因此前置測控軟件在調用PXI硬件板卡驅動提供的執(zhí)行函數(shù)之后，需要對某些執(zhí)行函數(shù)的返回值進行判斷，如果執(zhí)行的函數(shù)返回值表明函數(shù)執(zhí)行失敗，那么表明此時前置測控軟件的這條控制指令就沒有執(zhí)行成功，此時前置測控軟件就可以判定PXI硬件板卡出現(xiàn)了故障，那么此時也應該進行主備軟件的跳變切換。對于這種故障類型，實驗室中進行的方法是在代碼中將PXI硬件板卡的驅動的底層執(zhí)行函數(shù)的返回值進行手動取反之后再提供給前置測控軟件的調用函數(shù)，這樣前置測控軟件的調用函數(shù)接收到的返回值就出現(xiàn)了異常，觀察到主前置測控軟件在監(jiān)測到異常的PXI硬件板卡控制接口返回值之后，備前置測控軟件在較短時間內從 “備”狀態(tài)切換為“主”狀態(tài)，然后繼續(xù)和其他系統(tǒng)軟件一起準備進入工作狀態(tài)或者是繼續(xù)工作狀態(tài)。這種故障能及時切換的原因是因為主前置測控軟件在監(jiān)測到異常的接口返回值之后，判定是主前置PXI硬件板卡故障，然后立即對備前置測控軟件發(fā)送異常的“心跳”信號，備前置測控軟件在收到異常的“心跳”信號之后，可以認為主前置測控軟件發(fā)生了網(wǎng)絡故障，同樣進行后續(xù)主備狀態(tài)切換處理。

6）PXI硬件板卡初始化失?。涸谠囼灥拈_始階段，前置測控軟件需要進行PXI硬件板卡初始化，PXI硬件板卡初始化工作完成之后，前置測控軟件才能和PXI硬件板卡配合工作，但是初始化工作可能會出現(xiàn)某塊板卡初始化失敗的情況，因此在主前置測控軟件的代碼中對PXI硬件板卡初始化函數(shù)的返回值進行判斷，如果返回值不正確或者PXI硬件板卡的初始化函數(shù)無法調用，則前置測控軟件也可以認為出現(xiàn)了PXI硬件板卡故障，那么此時也應該進行主備軟件的跳變切換。對于這種故障類型，實驗室中進行的方法是將某塊PXI硬件板卡的驅動進行單獨卸載，然后正常啟動前置測控軟件去嘗試初始化所有的PXI硬件板卡，出現(xiàn)的現(xiàn)象是軟件在啟動完畢后，卸載了驅動的PXI硬件板卡會出現(xiàn)初始化失敗，后續(xù)備前置測控軟件會在較短時間內從“備”狀態(tài)切換為 “主”狀態(tài)，然后繼續(xù)和主機控制軟件，服務器軟件一起準備進入工作狀態(tài)或者是繼續(xù)工作狀態(tài)。這種故障能及時切換的原因是因為主前置測控軟件在監(jiān)測到PXI硬件板卡初始化失敗之后，判定是主前置PXI硬件板卡故障，然后立即對備前置測控軟件發(fā)送異常的“心跳”信號，備前置測控軟件在收到異常的 “心跳”信號之后，可以認為主前置PXI硬件板卡發(fā)生了故障，同樣進行后續(xù)主備狀態(tài)切換處理。

圖5是對上文描述的6種故障的分類圖示，根據(jù)故障模塊將6種故障類型分為3大類，分別是前置測控軟件故障、前置測控組合網(wǎng)卡或者網(wǎng)線故障和PXI硬件故障。其中前面兩種故障大類包含故障類型1）-3），這3種故障類型對系統(tǒng)中心跳信號的影響都是會使得心跳信號的消失，第三種故障大類包含故障類型4）-6），這3種故障類型對系統(tǒng)中心跳信號的影響是使得心跳信號從正常信號變?yōu)楫惓Ｐ盘?，在實驗室的故障模擬中熱備冗余系統(tǒng)均能出現(xiàn)正確及時的故障監(jiān)測并進行主備前置測控軟件的跳變，保證系統(tǒng)的工作不受影響。

圖5 模擬故障類型列舉

需要說明的是，本論文設計的熱備冗余系統(tǒng)中的主備軟件中的 “主”和 “備”不是固定的，而是互為主備，主備軟件的代碼設計完全相同，軟件初次啟動的時候通過讀取配置文件的方式來確定主備狀態(tài)，或者是通過主機控制軟件來進行遠程控制軟件的主備狀態(tài)。在主前置測控軟件出現(xiàn)故障之后，主前置測控軟件從系統(tǒng)中暫時脫離，此時備前置測控軟件切換為主軟件狀態(tài)，而當工作人員將原來的主前置測控軟件中的故障進行恢復之后，重新啟動軟件，此時啟動的軟件能夠收到系統(tǒng)中的現(xiàn)存的主前置測控軟件發(fā)來的“心跳”信號，即使此時讀取的配置文件信息為主軟件狀態(tài)，但是設定 “心跳”信號的優(yōu)先級更高，因此重新啟動的軟件將保持為 “備”狀態(tài)。如果此時系統(tǒng)中正常工作的主前置測控軟件再次出現(xiàn)故障，那么此時重新啟動之后保持為備用狀態(tài)的前置測控軟件也可以切換為 “主”狀態(tài)進行工作，實現(xiàn)主備冗余的互相切換，保證了系統(tǒng)工作的穩(wěn)定性。

3 時串發(fā)送系統(tǒng)設計

實際的前置測控軟件，不僅需要接受主機控制軟件的控制指令并回令，也會給主機控制軟件發(fā)送時串，如果在發(fā)送時串的過程中出現(xiàn)故障，無論是軟件異常退出或者宕機、前置測控軟件出現(xiàn)網(wǎng)絡中斷和前置測控軟件下游的硬件異常中的哪一種故障模式，主前置測控軟件的時串發(fā)送過程都會中斷。

為了發(fā)生故障之后不影響時串發(fā)送，備前置測控軟件切換主備狀態(tài)之后不僅僅需要繼續(xù)給主機控制軟件發(fā)送時串，并且要準確的知道時串的發(fā)送進度，需要從下一個還沒有發(fā)送的時串處開始進行發(fā)送，不能出現(xiàn)某一條時串的重復發(fā)送，同樣也不能出現(xiàn)時串的發(fā)送遺漏。因此在主前置測控軟件給主機控制軟件發(fā)送時串的同時，需要在 “心跳”信號中添加已經(jīng)發(fā)送的時串計數(shù)，而備前置測控軟件在接受到“心跳”信號并檢測的同時，需要將時串計數(shù)保存，每次收到“心跳”信號之后都會進行時串計數(shù)的更新，保證此時此刻軟件中存儲的時串計數(shù)都是最新的。如果在主前置測控軟件在發(fā)送時串的過程中發(fā)生故障導致時串發(fā)送停止，那么在備前置測控軟件切換成主狀態(tài)之后，需要繼續(xù)給主機控制軟件發(fā)送時串，根據(jù)之前在 “心跳”信號中保存下來的時串計數(shù)，此時的切換主備狀態(tài)之后的前置測控軟件就可以從時串序列計數(shù)的下一個時串處開始發(fā)送，能夠保證時串的不中斷不重復發(fā)送，保證時串發(fā)送工作的連續(xù)性和完整性。圖6是主前置測控軟件發(fā)送時串時發(fā)生異常導致發(fā)送中斷之后的切換示意圖。

圖6 時串發(fā)送中止后切換示意圖

4 主備切換時間驗證

設計的熱備冗余軟件系統(tǒng)用于實際工作過程中，主備軟件的切換時間需要進行嚴格要求，在軟件出現(xiàn)故障之后，要在一定的時間內進行切換，這樣才能盡可能小地減少軟件發(fā)生故障對系統(tǒng)和試驗流程的影響。在代碼設計過程中，如上文所述將心跳信號為主備切換的依據(jù)，代碼設計的時候，在發(fā)生長時間的心跳信號消失或者是心跳信號跳變，那么在進行判斷之后如果確實符合主備切換的條件，則立即進行軟件中主備切換模塊的函數(shù)調用，中間不進行任何不必要的執(zhí)行過程，以節(jié)省切換的時間。除此之外，在心跳信號接收和解析部分的代碼中，網(wǎng)絡數(shù)據(jù)的處理上也采用延遲最低的一級緩存模式，采用兩個獨立的線程，其中一個進行心跳信號數(shù)據(jù)的接收和存儲，另外一個線程進行心跳信號的處理，網(wǎng)絡數(shù)據(jù)只經(jīng)過一次緩存，最大限度地減少處理數(shù)據(jù)過程中的時間消耗。而在熱備冗余系統(tǒng)設計完成之后，進行系統(tǒng)的切換試驗，首先在所內實驗室中進行人工計時的方式記錄軟件切換的時間，記錄結果為切換時間在1秒之內。為了更精確的進行切換時間的對比，在代碼設計中添加心跳信號的發(fā)送時間戳、接收時間戳和切換時間戳的記錄并保存在本地文件中，在試驗結束之后，進行接收時間戳和切換時間戳的比對，得到的結果為實際切換時間約為0.7秒。表3是在6種故障類型完成之后，心跳信號的3種時間戳記錄表，表中的數(shù)據(jù)是從主備前置測控軟件的心跳信號本地存盤文件中獲取的，從表3也可以看出，這6種故障類型下，主備前置測控軟件的實際切換時間為0.7秒左右，能夠很好地滿足目前運載火箭地面測發(fā)控系統(tǒng)的試驗要求。

表3 心跳信號時間戳記錄表

5 結束語

設計完成的軟件系統(tǒng)具備了在線熱備自主切換的能力，能夠實現(xiàn)故障之后不需要人工進行軟件切換。在系統(tǒng)開啟后，主機控制軟件也可以根據(jù)實際情況修改不同計算機上的軟件的主備優(yōu)先級。軟件冗余系統(tǒng)可以對主備軟件運行狀態(tài)進行實時監(jiān)測，如果出現(xiàn)軟件故障可以及時發(fā)現(xiàn)并采取處理。主備前置測控軟件之間通過狀態(tài)同步、故障監(jiān)測和狀態(tài)切換能實現(xiàn)雙機熱備冗余系統(tǒng)，每個前置測控軟件都具備自檢功能，可以根據(jù)自身和系統(tǒng)的當前狀態(tài)確定主備狀態(tài)。通過試驗驗證，確定在發(fā)生故障之后，3秒鐘之內完成軟件的主備切換，并且故障軟件的工作狀態(tài)信息也能進行保存，保證了主備軟件工作的連續(xù)性和準確性，提升了運載火箭地面測發(fā)控軟件系統(tǒng)的穩(wěn)定性。