鄧兵 韓笑冬 宮江雷 安衛(wèi)鈺

(中國空間技術(shù)研究院通信衛(wèi)星事業(yè)部，北京 100094)

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

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

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

本文從通信衛(wèi)星星務(wù)軟件研制實際情況出發(fā)，針對星務(wù)軟件特點，結(jié)合模型驅(qū)動開發(fā)思想，提出3個層次的邏輯模型。圍繞該邏輯模型，設(shè)計并實現(xiàn)一套具有通用化、自動化、高可靠特點且與通信衛(wèi)星研制流程緊密結(jié)合的軟件架構(gòu)，可解決星務(wù)軟件研制效率低、數(shù)據(jù)量大、研制過程依靠個人經(jīng)驗等問題。

1 通用化軟件架構(gòu)設(shè)計

1.1 設(shè)計思路

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

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

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

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

圖1 以往星務(wù)軟件架構(gòu)Fig.1 Housekeeping software framework before

針對上述問題，借鑒模型驅(qū)動開發(fā)設(shè)計思想，本文設(shè)計并實現(xiàn)了通用星務(wù)軟件架構(gòu)(見圖2)，為邏輯模型的提取、設(shè)計、執(zhí)行提供基礎(chǔ)運行環(huán)境。它主要包括應(yīng)用軟件模塊、服務(wù)軟件模塊和數(shù)據(jù)管理模塊。

(1)應(yīng)用軟件模塊是通用星務(wù)軟件架構(gòu)的核心，通信衛(wèi)星平臺的主要業(yè)務(wù)功能都在該模塊中實現(xiàn)。各個軟件功能主要功能邏輯都基于邏輯模型實現(xiàn)，邏輯模型執(zhí)行引擎是應(yīng)用軟件模塊的核心，對邏輯模型裝訂數(shù)據(jù)進行解析，執(zhí)行相應(yīng)邏輯模型動作實現(xiàn)軟件功能。

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

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

圖2 通用星務(wù)軟件架構(gòu)Fig.2 General housekeeping software framework

通用星務(wù)軟件架構(gòu)具備如下優(yōu)點。

(1)制定標(biāo)準(zhǔn)化、數(shù)據(jù)化的邏輯模型。結(jié)合經(jīng)驗，總結(jié)提取通用的邏輯模型，各邏輯模型對應(yīng)固定的需求模板，分系統(tǒng)設(shè)計人員在邏輯模型軟件需求模板的約束下提出軟件需求，實現(xiàn)軟件需求的數(shù)據(jù)化、標(biāo)準(zhǔn)化，能提升需求與軟件實現(xiàn)的契合度，防止由于需求理解錯誤造成軟件實現(xiàn)問題。

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

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

1.2 邏輯模型抽象

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

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

(2)能源管理功能：獲取能源分系統(tǒng)相關(guān)系數(shù)，通過相關(guān)公式進行計算，判斷通信衛(wèi)星能源狀態(tài)，發(fā)送指令完成能源控制。

(3)FDIR功能：依據(jù)裝訂的故障判據(jù)，獲取通信衛(wèi)星健康狀態(tài)參數(shù)，檢測整星故障，依據(jù)判斷結(jié)果執(zhí)行相應(yīng)的故障隔離、故障恢復(fù)策略。

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

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

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

(1)邏輯子動作?；趯νㄐ判l(wèi)星星務(wù)軟件的分析，功能實現(xiàn)的基本動作包括指令發(fā)送、參數(shù)訪問、參數(shù)改寫、閾值訪問、自定義表達式、等待、跳轉(zhuǎn)、自定義函數(shù)等。本文把這些動作進行抽象提取，提供統(tǒng)一的動作實現(xiàn)，定義為邏輯子動作。

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

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

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

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

1.3 技術(shù)難點及解決途徑

通用星務(wù)軟件架構(gòu)設(shè)計重點集中在邏輯模型執(zhí)行引擎、通信衛(wèi)星數(shù)據(jù)中間件、自定義函數(shù)在軌維護和自適應(yīng)1553B總線協(xié)議的設(shè)計上。通過邏輯模型實現(xiàn)軟件邏輯的抽象化、通用化，通過數(shù)據(jù)中間件分離軟件邏輯與硬件設(shè)計，通過總線協(xié)議實現(xiàn)中心機與下位機的解耦。

1.3.1 邏輯模型執(zhí)行引擎設(shè)計

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

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

1.3.2 通信衛(wèi)星數(shù)據(jù)中間件設(shè)計

數(shù)據(jù)管理模塊的核心是通信衛(wèi)星數(shù)據(jù)中間件，中間件內(nèi)部維護1份整星參數(shù)緩存區(qū)，緩存區(qū)基于空間數(shù)據(jù)系統(tǒng)咨詢委員會(CCSDS)包協(xié)議[7]，包括所有的通信衛(wèi)星參數(shù)數(shù)據(jù)。該數(shù)據(jù)中間件對應(yīng)用軟件和下層驅(qū)動軟件提供獨特的參數(shù)訪問接口，實現(xiàn)應(yīng)用軟件與驅(qū)動軟件的數(shù)據(jù)隔離。通信衛(wèi)星數(shù)據(jù)中間件結(jié)構(gòu)見圖5。

圖5 通信衛(wèi)星數(shù)據(jù)中間件結(jié)構(gòu)Fig.5 Construction of telecommunication satellite data middleware

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

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

1.3.3 自定義函數(shù)在軌維護

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

當(dāng)軟件函數(shù)被調(diào)用時，把當(dāng)前的指令寄存器壓入函數(shù)堆棧，當(dāng)函數(shù)執(zhí)行完成后，還原指令寄存器的地址繼續(xù)執(zhí)行。在被調(diào)用函數(shù)內(nèi)部，首先保存上層函數(shù)堆棧的地址和初始化當(dāng)前函數(shù)堆棧地址。函數(shù)執(zhí)行完成后，恢復(fù)上層函數(shù)堆棧[8-9]。

基于函數(shù)調(diào)用指令執(zhí)行過程，通過在軌維護對函數(shù)調(diào)用指令進行更改，在軌動態(tài)實現(xiàn)新函數(shù)替換舊函數(shù)。①在新函數(shù)頭部增加出棧指令；②在預(yù)留的內(nèi)存空間位置中上注更改后的新函數(shù)；③在舊函數(shù)的開始位置增加新函數(shù)的函數(shù)調(diào)用指令。

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

圖6 自定義函數(shù)在軌維護實現(xiàn)Fig.6 Implementation of user-defined function on-orbit maintenance

1.3.4 自適應(yīng)1553B總線協(xié)議設(shè)計

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

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

2 應(yīng)用效果

應(yīng)用通用星務(wù)軟件架構(gòu)，使軟件研制模式發(fā)生了變化，從傳統(tǒng)的需求文件驅(qū)動轉(zhuǎn)化成為基于邏輯模型的數(shù)字化需求表格驅(qū)動，軟件需求方填寫統(tǒng)一的需求表格，軟件研制方依據(jù)需求表格自動化生成邏輯模型裝訂數(shù)據(jù)，形成基于邏輯模型的衛(wèi)星控制邏輯。在這個過程中，編寫代碼工作量大大減少，各主要軟件功能需要編寫代碼量對比見表1。

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

注：不包含裝訂參數(shù)。

依據(jù)統(tǒng)一、標(biāo)準(zhǔn)的邏輯模型，采用標(biāo)準(zhǔn)化的邏輯執(zhí)行方式，減少了軟件運行邏輯問題數(shù)。采用自動化數(shù)據(jù)裝訂替代手動數(shù)據(jù)裝訂，軟件數(shù)據(jù)裝訂錯誤率大大降低。通過自適應(yīng)總線協(xié)議設(shè)計和數(shù)據(jù)中間件實現(xiàn)軟件和硬件分離，減少了聯(lián)試期間出現(xiàn)的問題。研制過程中出現(xiàn)問題數(shù)量對比見表2。

表2 研制過程中出現(xiàn)問題數(shù)量對比

基于通用星務(wù)軟件架構(gòu)研制的星務(wù)軟件，在功能點增多、研發(fā)人員減少的情況下，仍能在更短研制周期下完成軟件研制，并在整星測試階段出現(xiàn)更少的軟件錯誤，取得了較好的應(yīng)用效果，見表3。

表3 星務(wù)軟件研制過程信息對比

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

3 結(jié)束語

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