一種應用邏輯模型的通用星務軟件架構設計

鄧兵 韓笑冬 宮江雷 安衛鈺

(中國空間技術研究院通信衛星事業部，北京 100094)

隨著國內外航天產業模式的變化，商業航天產業模式迅猛發展，過去高可靠、高成本、長周期的衛星研制模式不再適用，低成本、短周期、通用化的設計理念已經成為當前航天發展的方向[1-2]。衛星研制模式正在向“硬件標準化研制，軟件定義衛星”的方向發展，隨著衛星功能需求的增多、研制進度的縮緊，采用原有研制模式及軟件技術，已無法高效率、高質量地完成軟件的研制及驗證工作。

星務軟件作為通信衛星信息系統的中樞[3]，通過總線對通信衛星平臺及載荷各單機進行集中控制與管理，具有功能模塊多、代碼規模大、測試任務重等特點，在很大程度上決定了通信衛星在軌運行的穩定性和可靠性。星務軟件負責通信衛星日常功能管理，參與多個分系統的管理與交互，與多個分系統之間存在數據交互接口，具有需求變更量多、變更頻率高、開發工作量大、版本升級頻繁等特點，因此，其研制進度和效果決定著通信衛星整體功能的交付質量和交付時間，直接影響通信衛星研制進度和效果。

當前，在衛星研制工作中，每個軟件配置項都對應一個軟件研制方，雖然各軟件配置項具有獨立的軟件研制過程，但研制周期受限于整星研制進度，以衛星研制進度為主線。通信衛星總體設計人員依據衛星要求提出軟件研制需求，軟件研制方基于需求及相關配套數據，依據軟件工程化思想完成設計、研制、調試和測試工作[4]。在這個過程中，存在較多潛在風險：①軟件設計人員對需求理解不充分會造成功能點實現的疏漏；②星務軟件需要裝訂大量的指令碼字、參數波道等信息，任何數據錯誤都會影響整星功能；③代碼更改正確性依賴開發人員業務熟悉程度，研制人員的人事調動對軟件研制影響較大。雖然模型驅動開發研制模式[2]能夠較好地緩和上述問題，建立總體設計與軟件實現的溝通渠道，自動生成代碼，數字化配套信息，但是，當前主流模型驅動開發工具多提供較低粒度的計算和動作，針對性不強，需要結合通信衛星自身特點和協議，形成更加通用的上層研制模型，實現通信衛星整體設計與星務軟件研制的一致，提升星務軟件研制的效率及可靠性。

本文從通信衛星星務軟件研制實際情況出發，針對星務軟件特點，結合模型驅動開發思想，提出3個層次的邏輯模型。圍繞該邏輯模型，設計并實現一套具有通用化、自動化、高可靠特點且與通信衛星研制流程緊密結合的軟件架構，可解決星務軟件研制效率低、數據量大、研制過程依靠個人經驗等問題。

1 通用化軟件架構設計

1.1 設計思路

衛星綜合電子系統是以數據總線網絡為信息傳輸中樞的多級分布式系統，星務軟件運行于星務管理單元，是綜合電子系統的大腦。星務軟件通過總線從各終端采集整星參數，形成參數數據包，經過源包處理、虛擬信道生成后，形成整星遙測幀，傳送給地面。星務軟件接收到地面發送的衛星指令后，完成數據解碼、校驗等工作；指令通過總線進行處理，再分發給各總線終端。星務軟件主要實現熱控管理，能源管理，故障檢測隔離與恢復(FDIR)，程控管理等頂層功能。以往星務軟件架構見圖1，多個模塊相對獨立，公共服務較少，存在如下缺點。

(1)軟件邏輯與硬件結合緊密。軟件與硬件設備在數據、時間上沒有進行分離，硬件的更改會影響軟件邏輯實現。

(2)軟件功能實現相對獨立。熱控、能源等頂層功能獨立編寫，軟件內部單獨管理裝訂數據，可使用的軟件基礎服務較少，而且軟件多為開發人員獨立設計，與開發人員設計思路結合緊密。

(3)軟件實現過程自動化水平不高。軟件實現所使用的裝訂數據和軟件邏輯都為人工準備并編寫，效率較低且出錯率高。

圖1 以往星務軟件架構Fig.1 Housekeeping software framework before

針對上述問題，借鑒模型驅動開發設計思想，本文設計并實現了通用星務軟件架構(見圖2)，為邏輯模型的提取、設計、執行提供基礎運行環境。它主要包括應用軟件模塊、服務軟件模塊和數據管理模塊。

(1)應用軟件模塊是通用星務軟件架構的核心，通信衛星平臺的主要業務功能都在該模塊中實現。各個軟件功能主要功能邏輯都基于邏輯模型實現，邏輯模型執行引擎是應用軟件模塊的核心，對邏輯模型裝訂數據進行解析，執行相應邏輯模型動作實現軟件功能。

(2)服務軟件模塊為通用軟件架構提供通用化底層服務，主要包括遙測組幀、指令轉發、總線管理、時間管理等功能。服務軟件模塊采用通用化設計，遙測組幀、指令轉發等功能都基于通用的星地協議格式完成開發。為了提升中心機與下位機的耦合性，總線管理模塊基于自適應總線協議研發，實現了下位機的熱插拔和動態輪詢。

(3)數據管理模塊負責整星數據的集中化管理，為數據提供數據存儲、訪問、檢驗等功能。衛星數據包括衛星參數和初始化裝訂數據兩部分。邏輯模型以裝訂數據的形式存儲于數據管理模塊，裝訂數據主要包括參數波道數據、指令碼字、功能判斷閾值數據和邏輯模型裝訂數據。數據管理模塊的核心是衛星數據中間件，該中間件存儲所有衛星參數，為上下層提供數據訪問接口，從數據層面上解耦上層應用軟件和下層硬件邏輯。

圖2 通用星務軟件架構Fig.2 General housekeeping software framework

通用星務軟件架構具備如下優點。

(1)制定標準化、數據化的邏輯模型。結合經驗，總結提取通用的邏輯模型，各邏輯模型對應固定的需求模板，分系統設計人員在邏輯模型軟件需求模板的約束下提出軟件需求，實現軟件需求的數據化、標準化，能提升需求與軟件實現的契合度，防止由于需求理解錯誤造成軟件實現問題。

(2)自動化生成軟件數據裝訂與邏輯。各個邏輯模型對應固定的軟件裝訂方式及運行邏輯，基于邏輯模型的通用需求模板和衛星基礎數據，自動化生成軟件代碼。對于特殊軟件邏輯，留有自定義處理函數，為軟件開發人員定制開發留有接口。

(3)建立通用軟件底層服務。通過約定統一的數據協議，設計衛星參數、初始化裝訂數據的集中管理方法和自適應總線協議，從數據、時間上隔離軟件底層框架與軟件功能實現[5-6]。

1.2 邏輯模型抽象

星務軟件主要實現熱控管理、能源管理、FDIR、程控管理等頂層功能。除了上述通用頂層功能外，不同衛星具有獨有的功能需求，例如天線、太陽翼驅動控制，星間、器間消息路由。

(1)熱控管理功能：對熱控回路進行控制，通過獲取熱敏電阻采集的溫度值，與裝訂的熱控閾值進行比較，根據比較結果發送指令對加熱器開關進行控制。

(2)能源管理功能：獲取能源分系統相關系數，通過相關公式進行計算，判斷通信衛星能源狀態，發送指令完成能源控制。

(3)FDIR功能：依據裝訂的故障判據，獲取通信衛星健康狀態參數，檢測整星故障，依據判斷結果執行相應的故障隔離、故障恢復策略。

(4)程控管理功能：依據自動化控制策略，判斷整星參數，明確通信衛星狀態，自主完成星箭分離后姿態控制、太陽翼展開等動作。

從上述分析可以發現，星務軟件實現邏輯具有共同特點：從總線獲取的參數，通過相關的計算和可靠性處理后，與裝訂閾值進行比較，依據比較結果采取相關的控制策略，發送控制指令，修改控制標志參數。本文基于這些共性，對參數、指令、閾值等裝訂數據進行集中管理并提供統一的訪問接口，抽象化參數判斷、指令發送等動作，按照特定順序和邏輯組織上述數據，形成通用星務軟件邏輯模型。

通過對通信衛星平臺主要業務功能的實現邏輯進行抽象，本文對軟件邏輯的實現抽象為邏輯子動作、邏輯動作和邏輯序列3個層次的模型。邏輯子動作為邏輯動作的每個動作，邏輯序列由邏輯動作組成。邏輯動作和邏輯子動作具有不同的分類及模板，可以像搭積木一樣組合在一起，形成具有獨特特點的動作序列，實現軟件功能。

(1)邏輯子動作。基于對通信衛星星務軟件的分析，功能實現的基本動作包括指令發送、參數訪問、參數改寫、閾值訪問、自定義表達式、等待、跳轉、自定義函數等。本文把這些動作進行抽象提取，提供統一的動作實現，定義為邏輯子動作。

(2)邏輯動作。星務軟件的實現往往基于“判斷條件-采取動作”的模式，例如，熱控軟件判斷溫度后發送開關控制指令。通過對實現模式進行抽象，提取通用的條件判斷和動作的組合模板，定義為邏輯動作。邏輯動作具有不同的實現模版，各個模板針對具體的軟件實現邏輯進行設計。

(3)邏輯序列。單個邏輯動作無法實現軟件功能，基于不同模板的邏輯動作按照順序組成序列，按照特定順序執行，才能實現軟件的具體業務邏輯。邏輯動作組成的序列即邏輯序列，每個邏輯序列對應一項業務處理邏輯。

如圖3所示，通過對軟件業務邏輯的分析總結，在執行邏輯序列時，設計“成功則繼續執行邏輯子動作，失敗則跳至下一個邏輯動作”的邏輯動作執行原則。例如，一個邏輯序列只包括邏輯動作1，邏輯動作1包括邏輯動作1.1和邏輯動作1.2，邏輯動作1.1包括邏輯動作1.1.1。當執行邏輯動作1.1成功時，繼續執行邏輯動作1.1.1，但當邏輯動作1.1任意子動作執行失敗時，直接退出邏輯動作1.1，繼續執行邏輯動作1.2。

圖3 邏輯序列及其執行流程Fig.3 Logical sequence and its execution flow

1.3 技術難點及解決途徑

通用星務軟件架構設計重點集中在邏輯模型執行引擎、通信衛星數據中間件、自定義函數在軌維護和自適應1553B總線協議的設計上。通過邏輯模型實現軟件邏輯的抽象化、通用化，通過數據中間件分離軟件邏輯與硬件設計，通過總線協議實現中心機與下位機的解耦。

1.3.1 邏輯模型執行引擎設計

邏輯序列在邏輯執行引擎的調度下執行。邏輯執行引擎由邏輯序列執行隊列、邏輯序列等待隊列和邏輯執行器組成。應用軟件初始化時，加載邏輯序列到執行隊列中，邏輯執行器每個周期運行執行隊列中等待執行的邏輯序列；邏輯序列執行完成后，設置邏輯隊列為已執行，需要每個周期執行的常駐序列，會重新退回到執行隊列中；周期結束后，設置為等待執行，等待下個周期被邏輯執行器執行，僅需要執行1次的邏輯序列不退回執行隊列中。邏輯執行引擎運行機制見圖4。

圖4 邏輯執行引擎運行機制Fig.4 Operating mechanism of logical execution engine

1.3.2 通信衛星數據中間件設計

數據管理模塊的核心是通信衛星數據中間件，中間件內部維護1份整星參數緩存區，緩存區基于空間數據系統咨詢委員會(CCSDS)包協議[7]，包括所有的通信衛星參數數據。該數據中間件對應用軟件和下層驅動軟件提供獨特的參數訪問接口，實現應用軟件與驅動軟件的數據隔離。通信衛星數據中間件結構見圖5。

圖5 通信衛星數據中間件結構Fig.5 Construction of telecommunication satellite data middleware

通信衛星數據中間件在不具備錯誤檢測與糾正(EDAC)功能的硬件設備上，每次訪問時都會對數據進行逐字節的三取二校驗，若由于空間環境影響出現數據位翻轉，可以通過該方法對數據進行恢復。

每個下位機數據包都有數據更新標志，總線管理任務獲取下位機最新包數據，更新至通信衛星數據緩存區，數據更新標志更改為“已更新”；若下位機3次沒有更新該數據包，數據更新標志更改為“不更新”。應用軟件模塊在訪問下位機數據包時，提前判斷數據是否更新：若更新，采用當前數據進行控制；若不更新，采取相應的故障處理邏輯。

1.3.3 自定義函數在軌維護

目前，通信衛星星載軟件在軌維護一般包括參數級和配置項級在軌維護，這2種方式無法對模型中的自定義函數進行在軌維護和修改。為了實現自定義函數的在軌維護，本文基于函數調用指令的在軌更改，設計適應于任何函數的在軌維護方法。

當軟件函數被調用時，把當前的指令寄存器壓入函數堆棧，當函數執行完成后，還原指令寄存器的地址繼續執行。在被調用函數內部，首先保存上層函數堆棧的地址和初始化當前函數堆棧地址。函數執行完成后，恢復上層函數堆棧[8-9]。

基于函數調用指令執行過程，通過在軌維護對函數調用指令進行更改，在軌動態實現新函數替換舊函數。①在新函數頭部增加出棧指令；②在預留的內存空間位置中上注更改后的新函數；③在舊函數的開始位置增加新函數的函數調用指令。

經過上述更改，軟件程序中外部函數調用的仍然是舊函數地址，但在調用舊函數之后，并未保存外部函數堆棧，而是馬上調用新函數，此時堆棧中保存為新函數地址和舊函數地址；新函數開始調用時，執行在新函數頭部增加的出棧動作，使新函數地址出棧，此時堆棧中只有舊函數地址；之后，在新函數中保存外部函數堆棧，執行新函數內容，新函數內容執行完成后，返回到舊函數地址，實現新函數替換舊函數。自定義函數在軌維護實現見圖6。

圖6 自定義函數在軌維護實現Fig.6 Implementation of user-defined function on-orbit maintenance

1.3.4 自適應1553B總線協議設計

為了實現中心機與下位機的邏輯分離，本文設計并實現了自適應總線通信協議。一方面，在不修改總線控制端軟件的情況下，實現新研制總線終端設備即插即用，提升系統級星務軟件的通用性；另一方面，通過建立總線終端狀態表，降低總線通信過程中子地址理解錯誤等問題發生的概率。自適應1553B總線協議結構見圖7。

自適應總線協議的核心是總線終端設備狀態表，總線控制端總線終端設備狀態表用于描述當前總線總線終端設備的測控業務需求，總線控制端應用軟件完成對該狀態表的維護，并根據狀態表的信息向總線終端設備提供相應的數據服務。總線終端自描述字段描述著總線終端設備所需要的具體服務內容，自描述字段的具體內容需要與總線控制端總線終端設備狀態表中定義的內容相對應。該總線管理模塊采用定期A、B總線上的設備狀態，獲取在線總線終端端得運行狀態，輪詢機制解決總線終端在上電或者工作期間的即插即用。

2 應用效果

應用通用星務軟件架構，使軟件研制模式發生了變化，從傳統的需求文件驅動轉化成為基于邏輯模型的數字化需求表格驅動，軟件需求方填寫統一的需求表格，軟件研制方依據需求表格自動化生成邏輯模型裝訂數據，形成基于邏輯模型的衛星控制邏輯。在這個過程中，編寫代碼工作量大大減少，各主要軟件功能需要編寫代碼量對比見表1。

表1 星務軟件主要功能需要編寫代碼量對比

注：不包含裝訂參數。

依據統一、標準的邏輯模型，采用標準化的邏輯執行方式，減少了軟件運行邏輯問題數。采用自動化數據裝訂替代手動數據裝訂，軟件數據裝訂錯誤率大大降低。通過自適應總線協議設計和數據中間件實現軟件和硬件分離，減少了聯試期間出現的問題。研制過程中出現問題數量對比見表2。

表2 研制過程中出現問題數量對比

基于通用星務軟件架構研制的星務軟件，在功能點增多、研發人員減少的情況下，仍能在更短研制周期下完成軟件研制，并在整星測試階段出現更少的軟件錯誤，取得了較好的應用效果，見表3。

表3 星務軟件研制過程信息對比

注：AIT為總裝、集成和測試。

3 結束語

本文通過設計通信衛星通用星務軟件架構，為軟件開發、需求設計提取標準的邏輯模型，標準化需求邏輯的同時，實現了需求邏輯到軟件代碼的自動映射。同時，采用自動化手段實現邏輯模型數據和初始化裝訂數據的自動生成，采用數據中間件實現軟件和硬件設計的解耦，設計自適應總線協議實現中心機與下位機的分離，提升軟件的穩定性，降低軟件的維護成本。與以往星務軟件研制相比，通用星務軟件框架能有效地減少代碼編寫工作量和研制過程中出現的問題數量，在功能點增多的情況下只需要花費更短的研制時間，獲得了良好的應用效果。