航天器在軌基線控制系統設計與實現

儲海洋

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

0 引言

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

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

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

表1 單機狀態管理示意表

表2 軟件狀態管理示意表

1 任務需求

1.1 功能需求

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

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

2)能夠實時對照飛行狀態與基線狀態的一致性，當發現飛行狀態與基線狀態不一致時，系統進行報警，由設計師進行處置。

3)記錄基線狀態的變更歷史，實現基線變更留記錄，可追溯。

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

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

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

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

(2)軟件版本狀態：

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

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

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

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

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

(3)運行模式狀態：

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

表3 運行模式狀態管理示意表

(4)自主功能狀態：

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

表4 自主功能狀態管理示意表

圖1 航天器在軌基線控制系統架構圖

1.2 設計約束

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

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

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

2 系統設計

2.1 方案設計

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

2.2 功能設計

對系統功能進行詳細設計，框圖如圖2所示，整體上分為四個部分：系統管理、基線管理、監控報警和數據分析。

圖2 航天器在軌基線控制系統功能框圖

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

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

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

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

2.3 性能設計

2.3.1 數據庫檢索性能設計

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

圖3 兩種數據庫處理多型號數據模式

與單數據庫模式相比，多數據庫模式具有以下優勢：

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

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

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

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

2.3.2 數據判讀監視性能設計

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

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

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

3 實驗結果與分析

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

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

終端呈現效果參考圖4所示。

圖4 基線監控首頁(數據為填充數據)

4 結束語

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

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