一種應(yīng)用邏輯模型的通用星務(wù)軟件架構(gòu)設(shè)計(jì)

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

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

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

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

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

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

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

1.1 設(shè)計(jì)思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2 邏輯模型抽象

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)管理模塊的核心是通信衛(wèi)星數(shù)據(jù)中間件，中間件內(nèi)部維護(hù)1份整星參數(shù)緩存區(qū)，緩存區(qū)基于空間數(shù)據(jù)系統(tǒng)咨詢委員會(huì)(CCSDS)包協(xié)議[7]，包括所有的通信衛(wèi)星參數(shù)數(shù)據(jù)。該數(shù)據(jù)中間件對(duì)應(yīng)用軟件和下層驅(qū)動(dòng)軟件提供獨(dú)特的參數(shù)訪問接口，實(shí)現(xiàn)應(yīng)用軟件與驅(qū)動(dòng)軟件的數(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ù)中間件在不具備錯(cuò)誤檢測(cè)與糾正(EDAC)功能的硬件設(shè)備上，每次訪問時(shí)都會(huì)對(duì)數(shù)據(jù)進(jìn)行逐字節(jié)的三取二校驗(yàn)，若由于空間環(huán)境影響出現(xiàn)數(shù)據(jù)位翻轉(zhuǎn)，可以通過該方法對(duì)數(shù)據(jù)進(jìn)行恢復(fù)。

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

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

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

當(dāng)軟件函數(shù)被調(diào)用時(shí)，把當(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í)行過程，通過在軌維護(hù)對(duì)函數(shù)調(diào)用指令進(jìn)行更改，在軌動(dòng)態(tài)實(shí)現(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ù)地址；新函數(shù)開始調(diào)用時(shí)，執(zhí)行在新函數(shù)頭部增加的出棧動(dòng)作，使新函數(shù)地址出棧，此時(shí)堆棧中只有舊函數(shù)地址；之后，在新函數(shù)中保存外部函數(shù)堆棧，執(zhí)行新函數(shù)內(nèi)容，新函數(shù)內(nèi)容執(zhí)行完成后，返回到舊函數(shù)地址，實(shí)現(xiàn)新函數(shù)替換舊函數(shù)。自定義函數(shù)在軌維護(hù)實(shí)現(xiàn)見圖6。

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

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

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

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

2 應(yīng)用效果

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

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

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

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

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

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

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

注：AIT為總裝、集成和測(cè)試。

3 結(jié)束語(yǔ)

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