儲海洋

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

0 引言

掌握航天器在軌狀態(tài)是地面飛行控制的前提，通過遙測數(shù)據(jù)對航天器狀態(tài)進行判讀是最常見也是最直接的方法，但是航天器測控技術的發(fā)展[1]使得遙測信息量爆發(fā)式增長，對于設計師人工審閱而言，這種傳統(tǒng)的狀態(tài)管理方法愈發(fā)顯得過于細節(jié)，不能幫助設計師從宏觀上快速掌握航天器的在軌狀態(tài)。

隨著我國在軌航天器數(shù)量的快速增加，采用信息化的方法，提綱挈領的快速掌握在軌航天器狀態(tài)，并讓其在設計師之間透明無歧義，已經成為減輕設計師人工閱讀航天器在軌狀態(tài)工作負擔、提升狀態(tài)管理水平的研究方向。在軌航天器的狀態(tài)包括諸如能源、姿態(tài)、單機工作狀態(tài)、軟件運行狀態(tài)等各個方面，在航天器的飛行過程中，地面對其狀態(tài)有一個明確的預期，這個預期可被定義為基線狀態(tài)[2]，而航天器在軌的實際狀態(tài)則可以稱為飛行狀態(tài)，若飛行狀態(tài)與基線狀態(tài)相符，表明航天器在軌飛行正常，若出現(xiàn)不符，則說明出現(xiàn)了異常情況，需要設計師提高警惕和處置。

目前，如何對在軌航天器的狀態(tài)進行全面而準確的描述仍然是一個值得研究的課題。在軌管理的設計師初步從以下四個方面對航天器在軌飛行狀態(tài)進行結構化描述和判讀。(1)單機工作狀態(tài)：描述星上單機及其模塊的工作狀態(tài)，比如“開機”、“關機”等；(2)軟件版本狀態(tài)：描述每個星載軟件的版本及補丁情況；(3)運行模式狀態(tài)：以分系統(tǒng)為單位，描述衛(wèi)星所處的運行模式，比如遙控處于“明態(tài)”，姿態(tài)處于“三軸穩(wěn)定”；(4)自主功能狀態(tài)：描述衛(wèi)星每項自主功能的使能/禁止狀態(tài)，比如：GPS自主校時處于使能狀態(tài)等。以此為基礎，提出了航天器在軌基線控制系統(tǒng)的研制需求，本文對設計師的任務需求進行了分析，設計和開發(fā)了航天器在軌基線控制系統(tǒng)，定義當前的預期工作狀態(tài)作為基線狀態(tài)，然后通過實時遙測結合預定義規(guī)則判定飛行狀態(tài)，將航天器基線狀態(tài)與飛行狀態(tài)實時比對，進行狀態(tài)監(jiān)控和報警，快速發(fā)現(xiàn)航天器飛行狀態(tài)異常；記錄航天器在軌基線變更歷史，形成航天器基線變更履歷，實現(xiàn)航天器基線狀態(tài)變更有記錄、可追溯。

表1 單機狀態(tài)管理示意表

表2 軟件狀態(tài)管理示意表

1 任務需求

1.1 功能需求

對任務進行分析，主要包括以下四方面功能需求:

1)選定一個在軌航天器，能夠查看其當前的基線狀態(tài)和飛行狀態(tài)。

2)能夠實時對照飛行狀態(tài)與基線狀態(tài)的一致性，當發(fā)現(xiàn)飛行狀態(tài)與基線狀態(tài)不一致時，系統(tǒng)進行報警，由設計師進行處置。

3)記錄基線狀態(tài)的變更歷史，實現(xiàn)基線變更留記錄，可追溯。

4)變更數(shù)據(jù)分析和挖掘，研究挖掘基線變更數(shù)據(jù)與航天器在軌壽命、產品質量等因素之間的關聯(lián)關系。

其中，基線狀態(tài)指地面預期，飛行狀態(tài)指通過實時遙測判定的實際工作狀態(tài)。內容包括以下四個方面。

(1)單機及模塊的工作狀態(tài)：

為了更加準確的描述單機的工作狀態(tài)，將單機狀態(tài)管理的粒度細化到模塊級別,每個模塊具有若干可能的工作狀態(tài)，這些狀態(tài)能夠通過遙測反應確定，在軌飛行中，地面對模塊的狀態(tài)預期構成單機的狀態(tài)基線，通過遙測判定各個模塊的飛行狀態(tài)，管理示意如表1。狀態(tài)判定采用邏輯表達式描述，若實時遙測使判定表達式為真，則單機或者模塊處于該狀態(tài)。

(2)軟件版本狀態(tài)：

每臺單機或者模塊下可以裝載軟件，對于每個軟件記錄其版本號和補丁情況作為基線狀態(tài)，示意如表2所示。

某些軟件版本號會通過實時遙測下傳本文根據(jù)當前遙測解析的實際情況，按照一個遙測參數(shù)標識軟件版本號中一位的參數(shù)解析模式，對下傳的遙測版本號與基線版本號比對方式做如下規(guī)定：

①一個完整的軟件版本號需要多個遙測參數(shù)進行標識，參數(shù)間使用‘.’進行分割。

②版本比對從低位向高位比對，若高位無對應的遙測，則默認高位一致。

③若存在版本號遙測復用，則使用邏輯與符號(&&)對條件和版本進行分割，比如軟件A的版本號關聯(lián)遙測為：‘VEP==0&&VER001.VER002.VER003’，表示當參數(shù)VEP為0時，VER001.VER002.VER003的值是軟件A的版本號，參數(shù)VEP不為0，則VER001.VER002.VER003可能是其他軟件的版本號。

(3)運行模式狀態(tài)：

運行模式是一個抽象概念，宏觀地描述航天器所處的狀態(tài)，比如遙測遙控的明密態(tài)模式，航天器的姿態(tài)模式等，每個運行模式有若干個可能的運行狀態(tài)，在航天器飛行過程中，地面控制系統(tǒng)對其同樣有明確的預期狀態(tài)作為基線，管理示意表如表3。運行模式的判定規(guī)則與單機及模塊的狀態(tài)判定規(guī)則類似，采用邏輯表達式描述。

表3 運行模式狀態(tài)管理示意表

(4)自主功能狀態(tài)：

隨著航天器智能化程度的提高，航天器上自主功能項越來越多，每個自主功能項都有使能和禁止兩種狀態(tài)，也納入系統(tǒng)管理的范圍，管理示意表如表4所示。

表4 自主功能狀態(tài)管理示意表

圖1 航天器在軌基線控制系統(tǒng)架構圖

1.2 設計約束

1)系統(tǒng)需面向多航天器任務開發(fā)，能夠支持不少于200顆航天器的在軌基線控制。

2)以秒為單位，實時完成遙測數(shù)據(jù)的接收、狀態(tài)判定、顯示和報警。

3)系統(tǒng)采用BS模式實現(xiàn)，設計師只需要通過瀏覽器即可訪問，不需要額外安裝任何客戶端軟件。

2 系統(tǒng)設計

2.1 方案設計

以消息總線為本系統(tǒng)與遙測接收解析系統(tǒng)的邊界，用戶通過瀏覽器完成基線及狀態(tài)判定規(guī)則設定，系統(tǒng)從消息總線獲取實時遙測，從數(shù)據(jù)庫中加載狀態(tài)判定規(guī)則進行判定，將判定結果分發(fā)到各終端用戶的瀏覽器上監(jiān)視和報警，整體方案如圖1所示。

2.2 功能設計

對系統(tǒng)功能進行詳細設計，框圖如圖2所示，整體上分為四個部分：系統(tǒng)管理、基線管理、監(jiān)控報警和數(shù)據(jù)分析。

圖2 航天器在軌基線控制系統(tǒng)功能框圖

系統(tǒng)管理和一般系統(tǒng)的系統(tǒng)管理功能差別不大，不做多余介紹。

基線管理，在每個航天器內，以分系統(tǒng)為單位進行數(shù)據(jù)組織和管理，其包含三個方面的內容：(1)基線信息管理，編輯航天器基線的基礎信息，如產品名稱、代號等，并支持導入導出以提升編輯效率；(2)判定規(guī)則管理，對每一個可能狀態(tài)的判定規(guī)則進行設定；(3)基線變更管理，隨著航天器狀態(tài)的變化，地面需要對基線狀態(tài)進行及時調整和變更，需要記錄每一次變更的申請單、變更內容、變更時間、操作人等信息，形成航天器在軌飛行時的基線變更履歷，以供后續(xù)分析。

監(jiān)控報警包括狀態(tài)監(jiān)控和狀態(tài)報警兩個部分，針對每一個航天器，設計狀態(tài)監(jiān)控頁，顯示航天器當前的基線狀態(tài)和飛行狀態(tài)，從而能夠對航天器狀態(tài)進行全面詳細的了解。鑒于航天器上單機、軟件、自主功能數(shù)量眾多，為便于設計師工作，系統(tǒng)設計報警頁，可以將基線狀態(tài)與飛行狀態(tài)不一致的情況進行集中顯示和報警，提供單機報警、軟件報警、運行模式報警、自主功能報警、單型號報警、多型號集中報警等多個層次的集中報警功能。

在基線變更數(shù)據(jù)記錄匯集之后，可以從時間、分系統(tǒng)、單機及模塊、軟件、運行模式、自主功能等多個維度進行統(tǒng)計分析，比如分析各單機的基線變更次數(shù)，為單機質量評價提供參考；分析軟件的基線變更次數(shù)，查看軟件版本升級與補丁情況等，進一步可以將多航天器的基線變更數(shù)據(jù)匯總分析，例如查看一年內各航天器的基線變更情況，分析變更次數(shù)與航天器在軌壽命的關聯(lián)性等。

2.3 性能設計

2.3.1 數(shù)據(jù)庫檢索性能設計

數(shù)據(jù)層一般采用數(shù)據(jù)庫系統(tǒng)實現(xiàn)，以往系統(tǒng)在處理多型號數(shù)據(jù)時，多采用數(shù)據(jù)庫內索引加外鍵的模式完成，將所有型號的數(shù)據(jù)存入一個邏輯數(shù)據(jù)庫中, 這種模式簡單快捷,但是各型號之間數(shù)據(jù)的邏輯隔離性差,因此,本文采用一個索引庫加若干型號庫的多數(shù)據(jù)庫模式, 一個型號一個獨立的邏輯數(shù)據(jù)庫，整個系統(tǒng)一個索引庫，索引庫記錄各個型號庫地址和其它公用信息。通過索引庫的管理，能夠快速完成型號數(shù)據(jù)在本系統(tǒng)中的掛載和卸載，如圖3所示。

圖3 兩種數(shù)據(jù)庫處理多型號數(shù)據(jù)模式

與單數(shù)據(jù)庫模式相比，多數(shù)據(jù)庫模式具有以下優(yōu)勢：

1)型號間數(shù)據(jù)邏輯隔離，一個型號內的數(shù)據(jù)出現(xiàn)邏輯錯誤，不會影響到其它型號。

2)索引庫數(shù)據(jù)量及其有限，各型號數(shù)據(jù)在其壽命期內也是有限的，不會像單數(shù)據(jù)庫模式那樣隨著型號數(shù)量的增長，導致系統(tǒng)數(shù)據(jù)庫中數(shù)據(jù)量的爆發(fā)增長，從而影響檢索速率。

3)以型號為單位組織邏輯數(shù)據(jù)庫，便于數(shù)據(jù)的遷移、備份和還原，有利于進行系統(tǒng)運維。

其劣勢在于，查詢多個型號數(shù)據(jù)進行橫向比對時，需要跨庫檢索，操作稍顯麻煩，但是這種應用場景相對較少，其劣勢可以接受。

2.3.2 數(shù)據(jù)判讀監(jiān)視性能設計

1)在瀏覽器端，通過Web Socket維持前后臺數(shù)據(jù)長連接，以訂閱發(fā)布的模式[3]，由終端根據(jù)當前呈現(xiàn)的內容需要，向后臺服務訂閱數(shù)據(jù)，后臺服務在收到遙測更新后，僅將需求的數(shù)據(jù)轉發(fā)，數(shù)據(jù)量極大減少，能夠有效保證系統(tǒng)響應性能。

2)在服務端，隨著型號數(shù)量的增加，實時遙測數(shù)據(jù)量激增，狀態(tài)判定、監(jiān)控報警的實時性能壓力將快速提升，為此，首先將狀態(tài)判定服務和消息分發(fā)服務的功能分解，獨立成兩個服務，分別部署，以減輕服務壓力。在此基礎上，將狀態(tài)判定服務按照型號分解，每個型號的狀態(tài)判定服務獨立部署，以解決型號數(shù)量增加可能帶來的性能瓶頸。消息分發(fā)服務主要是將消息總線上的消息按照各終端需求轉發(fā)，其不需要緩存任何消息總線上的數(shù)據(jù)，其性能壓力主要在于終端請求數(shù)量，采用分布式部署和負載均衡，減少每個服務需要處理的請求數(shù)量，以緩解終端請求數(shù)量增加的壓力。

3)按照上述設計，系統(tǒng)在處理多型號任務時,其性能瓶頸將主要受制于消息總線的吞吐能力。目前比較典型的分布式消息總線包括Microsoft MSMQ、RabbitMQ、ActiveMQ以及Kafka等[4]，其中Kafka在消息派發(fā)方面有著獨特的優(yōu)勢，它以可水平擴展、可靠性高、可異步通信和高吞吐率等特性而被廣泛使用[5]，測試數(shù)據(jù)表明，在3節(jié)點(物理機配置：32核CPU、64 G內存、千兆網卡)Kafka系統(tǒng)中，向一個6分區(qū)，1副本的主題發(fā)送消息時，吞吐率可達50 MB/s[6]，而航天器的實時遙測速率一般不超過50 Kb/s[7]，解析后，實時遙測數(shù)據(jù)速率不大于200 kB/s，按照200顆航天器計算，總速率不超過40 MB/s，系統(tǒng)性能余量已經足夠充裕，每秒可無延遲完成遙測數(shù)據(jù)的接收、狀態(tài)判定、顯示和報警，滿足性能要求。當型號數(shù)量繼續(xù)增長，一個消息總線的容量不能滿足要求時，可對型號進行分類掛載到不同的消息總線上，以進行橫向擴展。

3 實驗結果與分析

設計完成后，按照軟件工程化的方法進行開發(fā)和實現(xiàn)，開發(fā)語言及環(huán)境選型如下：開發(fā)語言：node.js[8]，V12.13.1；消息總線：Kafka，V2.4.1；數(shù)據(jù)庫：Mongodb[9], V3.4.24；Web框架：Thinkjs[10], V3.2.10；服務運行環(huán)境：Centos 7 X64, V7.4.1708；客戶端環(huán)境：Chrome瀏覽器 V80.0.3987.149。經過需求分析、概要設計、詳細設計、編碼實現(xiàn)、測試驗證等一系列工程活動后，最終完成了系統(tǒng)的研制，并部署使用。

系統(tǒng)部署后，選擇19顆北斗三號組網衛(wèi)星(包括GEO衛(wèi)星、IGSO衛(wèi)星、MEO三種軌道類型)的模型及實際遙測數(shù)據(jù)進行應用驗證，結果表明，基線模型信息化管理正確，飛行狀態(tài)實時判定延遲小于200 ms，無漏判，系統(tǒng)運行效果良好。

終端呈現(xiàn)效果參考圖4所示。

圖4 基線監(jiān)控首頁(數(shù)據(jù)為填充數(shù)據(jù))

4 結束語

本文圍繞航天器在軌狀態(tài)管理和控制，設計并研發(fā)了航天器在軌基線控制系統(tǒng)和平臺，從單機、軟件、運行模式和自主功能四個方面對航天器的基線和飛行狀態(tài)進行描述，實現(xiàn)了基線狀態(tài)的變更控制，飛行狀態(tài)的實時監(jiān)控及其與基線的實時比對報警，為地面進行飛行控制提供了基線參考。飛行狀態(tài)的實時監(jiān)控是對傳統(tǒng)遙測監(jiān)視的有益補充，其更加宏觀、簡潔。消息總線和基于Web Socket訂閱發(fā)布模式實現(xiàn)了瀏覽器端的數(shù)據(jù)實時監(jiān)控，也為后續(xù)遙測監(jiān)控系統(tǒng)的研制提供了新的思路和參考。

下一步，還需要繼續(xù)深化和拓展航天器在軌狀態(tài)描述的內容和方法，延伸基線的內涵，比如熱控控溫閾值、航天器自身溫度場狀態(tài)、軟件運行時狀態(tài)、所處空間環(huán)境等，然后將這些不同緯度不同來源的數(shù)據(jù)掛載到基線控制平臺上，更加全面準確的描述航天器在軌基線狀態(tài)和飛行狀態(tài)，并通過基線控制平臺使其在設計師之間透明，為航天器飛行控制的科學決策提供依據(jù)。