通用指揮顯示數據引擎架構及應用設計

周 宇，尹志鋒，李林峰，周 淦

(中國電子信息產業集團有限公司第六研究所，北京100083)

0 引言

隨著信息技術的高速發展，我國航天發射試驗任務已經進入以數據為中心的時代，高效易擴展的數據交換、管理是數據展示以及數據應用得以實現的基礎。當前，航天發射場的測發、測控、氣象等系統已經可以在網絡中完成數據的交互傳遞，且各發射場均已獨立實現了將各大業務系統信息初步融合的“一體化”試驗任務測發指揮監控系統，但是由于發射場原有業務系統之間并沒有統一規劃互聯、互通，實現方式方法各異，且在擴展性方面存在一定的不足，以及系統間的數據綜合服務需求各異，與航天發射場未來一體化發展目標具有一定差距。

本文通過總結發射場指揮顯示數據流轉過程和使用處理需求，提煉了包含數據收發、解析處理、存儲獲取共三大關鍵要素的發射場指揮顯示數據引擎“服務簇”，同時也引入了雙工、日志、網絡代理等配套服務。通過提出的高靈活、可擴展、統一服務的通用數據引擎架構，定義了標準服務間數據交互接口，可以有效實現服務靈活調度的同時，還實現對各發射場內外部不同數據協議、流程的高擴展支持。系統將有效推進我國航天發射場指揮顯示系統的“一體化”實現。

針對提出的面向試驗任務指揮顯示的通用數據引擎架構，本文從總體結構、工作原理、應用模式幾個方面進行了闡述。

1 航天試驗任務測發指揮監控系統

航天試驗任務測試發射指揮監控系統簡稱測發指揮監控系統，是航天發射任務指揮的支撐技術平臺。測發指揮監控系統針對的對象是“航天器的測試、發射”，實現的功能是“指揮”、“監控”，即匯集信息、監視顯示、輔助決策、指揮調度[1]。

1.1 綜合指揮顯示信息

航天發射場測試發射指揮員和各專業專家，通過指揮監控系統顯示的各系統的測試信息，了解當前火箭、衛星、航天器以及地面勤務系統的工作狀態，指揮測試發射進程[2-3]。在由航天員參加的發射任務中，還需要顯示航天員系統的相關信息。為此測發指揮監控系統需要匯集的信息包含任務的進程信息、航天器的無線測試信息、航天器的下傳測控信息、運載火箭的有線測試信息、運載火箭的遙測信息、航天員的生理信息、發射場的氣象信息、發射場的發射支持設備信息、發射場的通信和測控系統設備工作信息以及各關鍵部位的視頻信息等。先進的測發指揮監控系統還將提供運載火箭、發射場發射支持設備、待發段航天員逃逸等故障診斷系統以及任務進程輔助系統，相關信息也將便于專家和指揮人員更加深入地掌握系統狀態。

1.2 “一體化”發展目標

目前航天發射場指揮決策系統是由大業務功能驅動下的多模塊、多系統集成的應用系統。指揮監控“一體化”是實現試驗任務高效、靈活、可靠開展的必然發展路線。“一體化”包括：業務分系統監測數據展示一體化，業務分系統監測數據管理應用一體化，任務配置、組件共享一體化，系統部署、升級、維護的運營一體化，以及更進一步的各發射場任務統一管理一體化。

部分發射場已經實現了現有業務分系統監測數據展示一體化，但并未真正實現監測數據的一體化接入，一方面體現在部分數據展示僅通過頁面嵌入方式接入，無法形成有效的風格統一，也無法對接入的數據進行有效的管理；另一方面也體現在現有數據接入方式無法有效適應未來更加豐富的接入模式，也意味著無法向監測數據管理應用(數據治理)一體化邁進。對發射場現有各業務分系統進行升級改造無疑是條長遠而艱巨的發展道路，當前可行且長遠的指揮監控一體化發展解決方案將圍繞指揮顯示展開，其首要解決的問題是構建指揮顯示通用數據引擎[4]，從而支撐統一的指揮顯示數據的接入、存儲、管理與平臺顯示[5-6]。

2 數據引擎架構研究

考慮能夠滿足發射場各類崗位人員的多樣需求以及能夠滿足未來新的指顯數據接入需要，通用指揮顯示數據引擎采用“平臺+組件”的模式來支持對航天發射任務中指顯數據的多類任務、多個階段、多種形式的兼容[7-8]。其架構研究主要考慮以下兩點：

(1)統籌當前需求，實現平臺一體化

結合發射場和北京中心的指揮顯示需求以及當前指揮顯示相關系統建設情況，統籌考慮各類型發射任務，發射場各業務分系統特點，數據接入、管理、存儲、顯示需求，實現一體化。

(2)適應長遠發展，支持擴展開發

綜合考慮航天器、運載火箭等系統的不斷升級變化以及發射場基礎設施的新建、改造，數據引擎還要具備擴展開發支持能力，以組件、輔助工具升級為主要方式，以平臺升級改造為特殊手段，使系統具備長期適應能力。

2.1 開放式平臺

通用指揮顯示數據引擎采用“平臺+組件”的設計思想[9-11]，由主框架(平臺)及(可擴展)組件構成，架構如圖1所示。

圖1 數據引擎“平臺+組件”可擴展架構設計

(1)組件層：數據引擎支持通用組件以及專用組件的接入，以滿足不同任務、不同類用戶的需求。各類組件是支撐數據引擎各項服務的重要組成部分，負責相關服務的具體實現。對于數據引擎而言，需要實現數據解析服務，外部數據收發服務，數據存取服務以及雙工、日志、網絡代理等相關配套服務。

(2)服務層：數據引擎的服務層介于組件層與邏輯層之間，服務層是對組件實現的抽象，是對系統行為的定義，為業務邏輯層提供相關功能服務。服務層將具體的業務邏輯需求與具體的功能實現進行解耦，使得系統具有較高的可擴展性，有利于系統的升級。

(3)邏輯層：數據引擎的邏輯層是整個平臺穩定運行的核心，是航天發射任務指揮顯示數據流轉管理邏輯的具體實現。具體功能包括平臺初始化、運行中數據管理、狀態統計、服務調度等。

(4)交互層：數據引擎的交互層是與系統管理者直接交互的窗口。通過可視化或通信接口的方式，實現對各類服務的配置、運行管理、狀態統計等功能，數據引擎響應各類事件，驅動各類服務。

在數據引擎的架構中，組件是一個獨立可替代的模塊，它是對邏輯的封裝，隱藏了內部實現，只提供輸入輸出接口。組件化設計遵循獨立、完整、自由組合。“組件”式建模的優勢在于將整個指揮顯示數據的接入、管理等化簡為繁，各組件單獨開發與測試，極大降低系統的維護難度和模塊間的耦合度，并有效地提高系統的復用性和可擴展性，滿足一體化指揮監控系統快速靈活的服務要求。

2.2 數據引擎服務定義及使用

通用指揮顯示數據引擎的通用化依賴于數據引擎內部各類服務(組件)的標準接口以及服務調度的管理實現。而各類服務之間的標準接口主要依賴于一種能夠在各服務間進行流轉的通用數據表達方式。在通用指顯數據引擎中，各類服務的接口主要依賴于定義為“通用數據包”的數據組織進行信息傳遞。

2.2.1 通用數據包類

通用數據包是一種可直接在各服務間流轉的通用數據組織表達，各類服務將根據服務屬性配置以及通用數據包的各類屬性完成相關服務提供。通用數據包屬性如表1所示。

表1 通用數據包屬性

2.2.2 外部數據收發服務

數據引擎支持外部系統接口配置綁定對應的外部數據收發服務，當外部數據收發服務接收到所綁定接口接收到的數據后，生成一個通用數據包，并填充數據包管理標識、接口標識信息，提交給平臺進行數據管理以及服務調度。當需要數據收發服務將源碼向外轉發時，從通用數據包中取出數據包原始數據進行發送。當需要對數據包原始數據進行關鍵字段替換等處理時，則需要實現外部數據收發服務的二次開發，并需要向數據引擎暴露相關配置接口(詳見第2.2.5節)。

2.2.3數據解析服務

數據引擎支持外部系統接口綁定對應的數據解析服務，數據引擎在收到外部數據收發服務提交的通用數據包時，根據接口標識信息獲取接口所綁定的數據解析服務，并將通用數據包交由數據解析服務進行進一步處理。數據解析服務根據所綁定/內置的解析規則，將通用數據包中的源碼數據進行解析，轉換為解析后的數據集，并填充到通用數據包中。當接口有校驗配置時，在解析前進行校驗，并填充通用數據包對應字段對。另外，當數據引擎僅作為數據分發使用時，通常不需要調用數據解析服務，這種情況下，數據引擎直接將通用數據包交由數據收發及存取服務進行轉發和存儲。

對于數據引擎而言，數據解析服務以讀寫方式操作通用數據包，而數據存取服務、轉發服務以只讀方式操作數據包，也即數據轉發服務以及數據存儲服務需在數據解析服務完成后進行，并可以并行進行。而通用數據包的銷毀則由數據引擎平臺來進行管理。

2.2.4 數據存取服務

數據引擎支持外部系統接口綁定對應的數據存取服務，數據引擎在進行數據解析后，根據接口所綁定的數據解析服務，將通用數據包交由數據存儲服務進行數據存儲相關操作。數據存儲服務根據所配置/內置的存儲規則，將通用數據包中的源碼或解析后的數據集進行存儲。

2.2.5 服務插件擴展屬性配置

數據引擎對各類服務提供相關配置功能，其一方面依賴于對各類服務的核心功能抽象，另一方面也依賴各類服務的具體實現。數據引擎平臺的通用性，主要依賴于相關服務基本接口的通用性。

以數據存取服務為例，對于測發指揮監控系統而言，通常需要支持兩類數據存取服務，一類為源碼存儲，需要配置文件存儲根目錄等信息；另一類為關系數據庫存儲，需要配置關系數據庫地址、用戶名、密碼、驅動等信息。顯然數據引擎需要兩個數據存儲服務的子類來對數據存儲服務進行配置管理區分。而所有數據存取服務均可配置容量告警這一屬性。考慮未來出現新的指顯數據存儲需求，數據引擎可能需要為新引入的數據存取服務，并需要提供更多的配置接口給用戶，在數據引擎各類服務的標準接口中，均包含“獲取額外配置項”以及“應用額外配置項”的接口，當服務需要非標準配置時，需要各服務實現以上兩個接口。數據引擎將通過“獲取額外配置項”接口獲取相關服務非標準配置需求，并提供人機交互窗口，將配置結果使用“應用額外配置項”接口交由對應服務進行初始化。

2.3 數據引擎工作原理

通用指揮顯示數據引擎基于“平臺+組件”的設計思想實現，在平臺服務調度的組織下，實現指揮顯示數據的接入、解析、存儲、分發及實時管理的全流程調度[12]。數據引擎的服務調度具體實現依賴于監聽者/觀察者方式，以外部系統狀態數據為例，當接收/獲取到一組外部數據時，產生相關事件，而通過對相關接口的配置，實現數據轉發、解析、統計以及存儲相關組件對其事件進行響應[13-14]。

通用指揮顯示數據引擎主要涉及的交互及相關處理如下，其工作原理示意如圖2所示。

圖2 數據引擎工作原理示意

(1)外部業務系統：外部業務系統包括中心機系統、火箭測試系統、地面系統等系統，相關系統主要通過組播、可靠連接、網站訪問等方式提供各類系統業務相關數據。而數據引擎通過加載相關收發及解析組件實現外部業務系統的接入及轉換。

(2)各類指揮顯示軟件：數據引擎為各類指揮顯示類軟件提供數據支持服務，數據引擎提供數據訂閱、數據查詢以及數據分發三種數據支持子服務。其中無論是數據訂閱[15]、查詢還是分發，數據引擎與各類指揮顯示軟件均采用統一的接口以及統一的數據標識定義。數據標識定義在單一的域中唯一，其中域可使用發射場、任務ID等進行定義。

(3)其他同域數據引擎：引擎間通信主要實現指揮顯示數據的分發、交互以及可能出現單點故障時的數據恢復、熱備等，對于不同的數據引擎應用模式(詳見第3節)，引擎間通信內容略有區別。

(4)存儲系統：數據引擎將內外部接收處理的數據進行存儲管理，并為指揮顯示軟件提供數據查詢服務。

(5)管理維護及控制接口：數據引擎配置管理維護與控制接口，以實現整個試驗任務信息系統的統一監控管理。

3 數據引擎應用模式

航天試驗任務指揮顯示數據引擎需要綜合考慮現有發射場業務系統建設情況以及當前軟硬件環境，指顯數據引擎能夠支持集中式、分布式（及單點式）以及混合式三種試驗任務指揮顯示數據接入模式。其中混合式應用模式僅需現有環境做部分資源調整即可實現，同時也是更好支持發射場測發指揮監控系統向落實“一體化”邁進的一種應用模式。

3.1 集中式應用模式

數據引擎集中式應用模式的主要特點體現在外部顯示相關的數據在集中的機器上完成數據匯集、處理、存儲、分發等工作，而用戶顯示終端主要為系統使用人員提供多元的數據顯示并提供各類人機交互的接口，集中式應用模式如圖3(a)所示。

在集中式應用模式下，一般采用一組互為熱備的高性能服務器作為數據引擎的承載機器。通過這種方式，可以減輕用戶顯示終端的處理壓力，并可以有效保障內外部系統的解耦，方便保障系統各類數據的一致性。但另一方面，集中式應用模式在擴展性支持方面較弱，同時對集中式節點的數據依賴較高。

3.2 分布式/單點式應用模式

數據引擎分布式/單點式應用模式的主要特點體現在外部顯示相關的數據直接在各用戶顯示終端上完成數據匯集、處理、存儲等工作，顯示終端同時為系統使用人員提供多元的數據顯示并提供各類人機交互的接口，分布式/單點式應用模式如圖3(b)所示。

在分布式應用模式下，各顯示終端均配置完整的數據引擎，在單節點出現故障時不會影響其他終端用戶使用。分布式應用架構對用戶顯示終端計算性能有一定的要求，在數據存儲上存在一定的冗余，同時由于缺乏集中的分發處理，數據一致性以及內部數據差異化分發較弱。

3.3 混合式應用模式

數據引擎混合式應用模式的主要特點體現在外部顯示相關的數據可以差異化地在各用戶顯示終端上完成數據匯集、處理、存儲等工作，同時在集中的節點上實現試驗任務的全量數據管理，顯示終端可以直接為系統使用人員提供多元的數據顯示并提供各類人機交互的接口，也可依賴于集中節點完成全量數據的查詢。混合式應用模式如圖3(c)所示。

圖3 數據引擎應用模式

混合式應用模式下，在集中節點部署完整配置的數據引擎，而在各指顯終端，可以通過組件的靈活組合配置及不同需求，部署差異化配置的數據引擎。在正常運行情況下，指顯終端可以快速地從本地獲取所需數據，同時由于差異化的部署可以在一定程度上降低對指顯終端的計算性能需求，而在終端異常或需要額外的數據時，可向集中節點部署的數據引擎請求相關數據。除滿足基本試驗任務指顯數據需求保障的情況下，在數據一致性、擴展性方面均存在一定的優勢。

4 結論

通用指揮顯示數據引擎將發射場指揮顯示數據接入、存儲、轉發等功能轉變為具有一定功能、可替代的服務構件，在統一標準、統一服務、統一接口的基礎上，以“搭積木”的方式靈活構建出目前和未來所需的數據治理平臺。

該架構有效解決了各發射場內外部協議不統一、數據接入難以及數據應用擴展性差的問題。目前，該通用指揮顯示數據引擎架構已成功應用于某指揮顯示系統，對我國航天發射場的信息“一體化”發展具有重要的應用價值。