李翔,宮江雷,2,郭莉芳,韓笑冬,*,王超,楊凱飛

1.中國空間技術(shù)研究院 通信與導航衛(wèi)星總體部,北京 100094

2.西安電子科技大學,西安 710126

1 引言

隨著軟件定義理念在航天領(lǐng)域的大力推廣,衛(wèi)星軟件技術(shù)逐步向著自主化、易重構(gòu)的方向飛速發(fā)展。衛(wèi)星所處的物理空間環(huán)境惡劣,硬件設(shè)計時出于抗輻照、防單粒子效應(yīng)等因素的考慮,大多采用宇航級元器件,導致單機計算和存儲資源有限[1-4],因此星務(wù)軟件設(shè)計及操作系統(tǒng)選型上以簡單可靠為核心目標,無法支持復雜的上層應(yīng)用如文件系統(tǒng)、補丁發(fā)布等功能,這對提升整個軟件系統(tǒng)的可重構(gòu)性帶來了較大的難度。

星載綜合電子系統(tǒng)作為衛(wèi)星數(shù)據(jù)流與指令流交互的核心系統(tǒng),時刻扮演著衛(wèi)星大腦的角色。而綜合電子系統(tǒng)的主要功能及任務(wù)都是依托于星務(wù)管理軟件來實現(xiàn)。在軌期間由于器件老化、設(shè)備損壞等原因,衛(wèi)星狀態(tài)及相關(guān)性能會發(fā)生變化,軟件控制策略隨之可能發(fā)生改變,此時存在上注補丁修改星務(wù)管理軟件的需求[5];同時隨著技術(shù)的發(fā)展,現(xiàn)有的星務(wù)控制策略和任務(wù)設(shè)計已無法滿足未來用戶需求和技術(shù)的更新?lián)Q代要求,通常需要通過更新星務(wù)管理軟件的方式來適配新的應(yīng)用需求,延長衛(wèi)星在軌的服務(wù)時間[6-7]。

但是星務(wù)管理軟件一旦固化后,在軌更改的手段很匱乏,目前只能通過在軌維護的方式對軟件進行修改,傳統(tǒng)的在軌維護方式存在以下幾個問題:

1)目前星務(wù)管理軟件在軌維護手段偏少,能力偏弱,無法支持在軌擴展自定義任務(wù)的需求?，F(xiàn)有軟件設(shè)計主要提供函數(shù)級和整個配置項級的維護能力。配置項級維護方式作為軟件修復的最后一道防線,維護顆粒度過于粗放,且對上行信道資源占用時間開銷較大,除非現(xiàn)有程序無法正常運行,一般情況下不予采用。而目前函數(shù)級維護只能對預先設(shè)計好的固定類型的函數(shù)進行維護,無法引入自定義類型的函數(shù)。傳統(tǒng)的函數(shù)維護方法,是在軟件設(shè)計階段篩選出可能被維護的目標函數(shù),根據(jù)目標函數(shù)類型生成函數(shù)指針列表,并在程序里預埋鉤子函數(shù),實際維護過程中不能超過配置好的函數(shù)列表的范圍。同時當前的函數(shù)維護機制無法支持自定義類型的函數(shù)的上注,因此具有一定的局限性。

2)傳統(tǒng)星務(wù)管理軟件的設(shè)計中,衛(wèi)星在軌執(zhí)行的任務(wù)是預先規(guī)劃好的,在軌無法進行擴展和重新規(guī)劃,而且任務(wù)相關(guān)資源也是靜態(tài)配置好,無法在軌動態(tài)重配。在實際應(yīng)用中,時常需要通過任務(wù)的重構(gòu)來重新定義衛(wèi)星的功能及應(yīng)用場景,并且實現(xiàn)上注任務(wù)動態(tài)加載,即插即用,現(xiàn)有機制無法支撐衛(wèi)星任務(wù)動態(tài)擴展的需求。

3)在軌維護上注的數(shù)據(jù)具有掉電即失的特點,星載計算機復位或切機的情況下,存在維護補丁失效的風險?，F(xiàn)有維護機制下,補丁上注后,軟件會修改內(nèi)存中的數(shù)據(jù)段或代碼段內(nèi)容,星載計算機復位或者斷電后內(nèi)存上內(nèi)容會被清除,軟件再次啟動時,補丁失效。即使在某些研究中,存在通過非易失器件保存維護補丁的設(shè)計,但其僅能解決本機重啟后恢復問題,發(fā)生系統(tǒng)故障切機后仍然無法恢復補丁。通常在軌維護補丁用于對星務(wù)軟件的算法性能進行優(yōu)化,對軟件潛在BUG進行修復,一旦星載計算機復位或切機,軟件恢復到維護前舊狀態(tài),地面需重新上注補丁進行軟件維護,存在維護不及時導致軟件性能降低或BUG復現(xiàn)的風險。

因此,基于以上的問題現(xiàn)狀,需要設(shè)計一種安全靈活的軟件在軌重構(gòu)方法,支持衛(wèi)星任務(wù)的動態(tài)擴展及自適應(yīng)接入,確保任務(wù)補丁的常駐存儲及重啟后自主恢復,進一步提升衛(wèi)星重構(gòu)的安全性與靈活性,滿足衛(wèi)星快速響應(yīng)的需要。

2 支持任務(wù)重構(gòu)的星務(wù)軟件架構(gòu)設(shè)計

2.1 相關(guān)硬件環(huán)境概述

典型衛(wèi)星硬件系統(tǒng)由中心計算機、星內(nèi)總線、遙測遙控單元、敏感器及執(zhí)行機構(gòu)、載荷計算機以及其他遠置單元構(gòu)成,如圖1所示。中心計算機是整星信息、數(shù)據(jù)、指令交互的中樞,物理層由CPU搭配異構(gòu)計算單元提供面向用戶應(yīng)用的計算和存儲能力,并且匯聚了多種高中低速總線接口,提供不同需求的星內(nèi)數(shù)據(jù)訪問以及星間通信能力。

圖1 衛(wèi)星硬件系統(tǒng)結(jié)構(gòu)示意

(1)中心計算機

中心計算機系統(tǒng)以CPU模塊為核心,與搭載軟件一起構(gòu)成自主管理與控制系統(tǒng),一般由CPU,外圍存儲器如RAM,PROM,FLASH,總線通信模塊以及容錯模塊等構(gòu)成,如圖2所示。

圖2 中心計算機組成示意

(2)容錯SRAM

容錯SRAM用于保存衛(wèi)星運行期間內(nèi)的重要數(shù)據(jù)及相關(guān)參數(shù),在設(shè)計時,利用主備機熱備工作的SRAM以實現(xiàn)重要數(shù)據(jù)的保存。當班機異常導致切機后,對方機上電后,從容錯SRAM中恢復之前保存的重要數(shù)據(jù)。例如,CPU主機故障后,CPU備機上電從容錯SRAM中恢復CPU運行所需的重要數(shù)據(jù)[8]。

容錯SRAM與CPU-主、CPU-備之間采用交叉的連接關(guān)系,如圖3所示。

圖3 容錯SRAM交叉連接示意

CPU-主機、CPU-備機之間通過隔離電路實現(xiàn)與SRAM的交叉訪問,通過對數(shù)據(jù)方向的控制來實現(xiàn)故障的隔離,CPU-主機(或CPU-備機)發(fā)生故障時,不會影響另一機對主備SRAM的正常訪問。

當班CPU模塊正常工作期間,依次對主備容錯SRAM進行讀寫,并將重要數(shù)據(jù)保存至雙份容錯SRAM,當完成容錯SRAM的寫操作后,CPU模塊會自動地回讀寫入的數(shù)據(jù),并進行數(shù)據(jù)比對,當數(shù)據(jù)與寫入數(shù)據(jù)不符時,CPU模塊會將無效標志寫入容錯SRAM,當連續(xù)三個周期都出現(xiàn)比對錯誤時,則CPU模塊會將錯誤狀態(tài)通過遙測下傳地面,并停止對故障容錯SRAM進行訪問操作。當CPU模塊發(fā)生切機后,對方機CPU模塊上電后會依次讀取主備容錯SRAM中的重要數(shù)據(jù)。CPU模塊首先對容錯SRAM有效標志進行判斷,如為無效狀態(tài),則CPU模塊停止對當前容錯SRAM進行訪問,CPU模塊判斷完有效標志后,對重要數(shù)據(jù)校驗和進行計算,CPU模塊只選擇校驗和正確的重要數(shù)據(jù)進行恢復,當主備容錯SRAM重要數(shù)據(jù)均正確,則CPU模塊選擇星時大的重要數(shù)據(jù)。如果上電后,CPU模塊讀取的主備容錯SRAM均為無效狀態(tài),則對主備容錯SRAM初始化清零處理。

2.2 星務(wù)軟件架構(gòu)設(shè)計

(1)分層設(shè)計

星務(wù)軟件架構(gòu)遵循“軟件定義”的設(shè)計理念,通過分層設(shè)計及協(xié)議優(yōu)化實現(xiàn)軟件組件與模塊的即插即用,提高衛(wèi)星軟件產(chǎn)品的功能可擴展性[9],具體架構(gòu)如圖4所示。

圖4 星務(wù)軟件架構(gòu)示意

圖5 軟總線通信示意

該框架從子網(wǎng)層到支持層,再到用戶應(yīng)用層均采用自適應(yīng)的交互協(xié)議,可實現(xiàn)自定義任務(wù)的即插即用。

1)子網(wǎng)層:其中物理層主要是指星載計算機硬件設(shè)備;數(shù)據(jù)鏈路層主要用來屏蔽底層硬件,進行基本硬件系統(tǒng)的初始化和驅(qū)動;子網(wǎng)業(yè)務(wù)層主要提供底層硬件服務(wù)任務(wù),實現(xiàn)總線通信協(xié)議、串口通信協(xié)議等。其中總線協(xié)議采用自適應(yīng)的通信協(xié)議,符合該協(xié)議的總線設(shè)備接入時通過握手通信實現(xiàn)自動注冊,合法設(shè)備可實時加入系統(tǒng)中,無需提前配置,真正實現(xiàn)接入設(shè)備的即插即用,為可編程載荷的實現(xiàn)提供了可能。

2)應(yīng)用支持層:其中專用業(yè)務(wù)層提供通用管理任務(wù),將應(yīng)用軟件與數(shù)據(jù)鏈路層的物理拓撲結(jié)構(gòu)和數(shù)據(jù)子網(wǎng)隔離開;而軟總線層,提供通用的數(shù)據(jù)和信息交互的管道,向下將總線設(shè)備進一步抽象為共享緩存區(qū)的數(shù)據(jù)源,往上向應(yīng)用層開放訪問接口,合法模塊只要注冊成功均可實現(xiàn)對共享緩存區(qū)中數(shù)據(jù)的訪問,隨時注冊隨時訪問,實現(xiàn)了軟件組件的即插即用,為實現(xiàn)軟組件重構(gòu)提供了基礎(chǔ)。

3)應(yīng)用層:星務(wù)任務(wù)的集合,根據(jù)獲取的數(shù)據(jù)進行星上任務(wù)的管理。平臺任務(wù)層為衛(wèi)星系統(tǒng)維持平臺正常工作而設(shè)計的最小任務(wù)包絡(luò),完成對在軌工作中能源、信息、結(jié)構(gòu)等系統(tǒng)的正常工況保持和故障檢測。用戶任務(wù)層為面向用戶開放的自定義任務(wù)集合,在現(xiàn)有的自適應(yīng)總線和軟總線協(xié)議基礎(chǔ)上,用戶通過任務(wù)級維護的方式實現(xiàn)功能重構(gòu),重新定義用戶的應(yīng)用場景。

(2)軟總線設(shè)計

軟總線的設(shè)計思路是將軟件系統(tǒng)看成是具有總線拓撲結(jié)構(gòu)的網(wǎng)絡(luò),通過軟總線實現(xiàn)類似于硬件總線的橋梁功能,任何一個符合一定標準的應(yīng)用程序都可以通過插件方式獲得軟總線的支持,與總線上的其他部件相互通信、協(xié)調(diào)與控制[10]。采用軟總線體系結(jié)構(gòu)的系統(tǒng)集成方式,可以有效地降低需要集成的系統(tǒng)之間的耦合程度,具有良好的可擴展性、可復用性、可維護性[11-12]。

具體到上一節(jié)的軟件框架中,軟總線將底層驅(qū)動及通用業(yè)務(wù)進行抽象,形成與硬件無關(guān)的資源分配及讀寫操作,提供星上遙測及遙控信息流驅(qū)動接口,上層應(yīng)用任務(wù)通過對軟總線層的接口調(diào)用完成遙測獲取、遙測下傳、指令接收、指令分發(fā)等任務(wù),實現(xiàn)對下位機設(shè)備的控制[13]。從而使應(yīng)用任務(wù)在設(shè)計上屏蔽具體總線接口和硬件設(shè)備形式,只需專注于應(yīng)用具體任務(wù)的實現(xiàn),便于軟件在不同型號不同平臺衛(wèi)星上的移植。

應(yīng)用任務(wù)初始化時,將該任務(wù)模塊進行注冊,獲取對應(yīng)下位機設(shè)備數(shù)據(jù)源的操作權(quán)限。初始化完成后,軟件模塊與對應(yīng)的遙測包號完成配對,自動完成軟總線兩端“設(shè)備”,即軟件模塊與下位機設(shè)備的通信建立。應(yīng)用任務(wù)在獲取數(shù)據(jù)之前,會自動判斷對應(yīng)的數(shù)據(jù)包的狀態(tài),如果硬件通信狀態(tài)不正常,則獲取的數(shù)據(jù)包為無效或者不更新狀態(tài),此時軟件模塊無法通過軟總線獲取正常更新的數(shù)據(jù),軟件會將錯誤信息下傳地面。如果通信狀態(tài)正常,則軟件模塊可通過讀數(shù)據(jù)接口獲取總線上的遙測數(shù)據(jù)。軟總線提供了多個從硬件總線緩存中獲取遙測數(shù)據(jù)的接口,可按位、按字節(jié)、按字、按遙測包號來獲取或者回寫不同類型的數(shù)據(jù),并且按照數(shù)據(jù)協(xié)議格式進行自動校驗。

同時,通過軟總線的指令接口,軟件模塊可以實現(xiàn)對硬件設(shè)備的主動控制。軟總線提供寫指令接口,由底層驅(qū)動完成相關(guān)時序的匹配,發(fā)送指令。而且軟件模塊在運行過程中會收到由地面設(shè)備發(fā)送的遙控指令,軟總線對上行通道的指令緩存的讀取進行了封裝,通過讀指令接口直接獲取遙控指令,從而完成地面對軟件模塊的控制。

(3)鏈接腳本設(shè)計

軟件工程中,軟件功能實現(xiàn)是從源代碼開始,編譯鏈接后形成可執(zhí)行文件,在此基礎(chǔ)上生成機器可識別的bin文件,生成過程中,一般由集成開發(fā)環(huán)境中嵌入的連接器自動分配程序中text段、data段、bss段的位置,這樣會導致自定義任務(wù)與原有任務(wù)的空間界限不清晰,不便于單獨管理新增任務(wù)的內(nèi)存空間[15]。

此時可以采用定點鏈接的方式,自定義指定新任務(wù)各個段在程序運行時的地址空間布局,指定新增任務(wù)的text段、data段及bss段的位置,同時預留出足夠大的空間給預擴展任務(wù)使用,實現(xiàn)與原有軟件任務(wù)內(nèi)存空間的隔離,如圖6所示。定點鏈接通過改寫鏈接腳本,通過SECTIONS和MEMORY等關(guān)鍵字,完成對目標文件各段空間分布的約束,實現(xiàn)原有代碼與維護代碼的定向隔離,避免新任務(wù)內(nèi)存空間與原任務(wù)內(nèi)存空間之間的沖突和污染。

圖6 定點鏈接原理示意

圖7 任務(wù)重構(gòu)流程示意

可以看出,星務(wù)軟件架構(gòu)中的分層設(shè)計保證了新增任務(wù)與已有任務(wù)邏輯層面的分離,而基于鏈接腳本的定點鏈接設(shè)計,則實現(xiàn)了新增任務(wù)與已有任務(wù)物理空間的分離,進一步保證了新增任務(wù)對已有星務(wù)軟件系統(tǒng)的影響是嚴格可控的。

3 任務(wù)上注、接入及恢復機制

目前,衛(wèi)星軟件在軌重構(gòu)主要通過在軌維護方式實現(xiàn),傳統(tǒng)在軌維護方式重構(gòu)的顆粒度較大,維護方式過于粗放,且對上行信道資源占用時間開銷很大,效率較低。

本文在現(xiàn)有軟件維護的基礎(chǔ)上進行優(yōu)化,采用定點鏈接技術(shù),實現(xiàn)新型的支持任務(wù)自主接入的重構(gòu)機制,全面支持用戶任務(wù)的自適應(yīng)擴展。同時設(shè)計任務(wù)重構(gòu)的數(shù)據(jù)封裝協(xié)議,支持任務(wù)動態(tài)的新增、刪除和修改,對重構(gòu)后的新功能提供斷電后自主恢復服務(wù)。

3.1 任務(wù)上注及自主接入流程

任務(wù)重構(gòu)的核心目標是以應(yīng)用任務(wù)為基本單位,在軌進行動態(tài)的增刪改操作,主要流程是上注一個新的任務(wù)模塊實體,替換任務(wù)池中已有的應(yīng)用任務(wù),或者在原有任務(wù)集合基礎(chǔ)上新增一個任務(wù)模塊,并且動態(tài)地加載運行。

一般來說,描述一個任務(wù)除了任務(wù)體內(nèi)容外,還需要定義任務(wù)ID、任務(wù)名稱、主函數(shù)入口、堆棧大小等配置信息。所以一個任務(wù)補丁至少需包含一個函數(shù)和若干全局變量。任務(wù)上注流程主要分為兩大步驟:一是上傳任務(wù)體內(nèi)容,即函數(shù)及變量的靜態(tài)上注,二是發(fā)送任務(wù)新增或替換請求,隨即啟動任務(wù)。

在用戶任務(wù)上注并成功啟動后,通過操作系統(tǒng)的任務(wù)加載接口可實現(xiàn)將新增任務(wù)插入星務(wù)軟件任務(wù)池中,但新任務(wù)要完成具體的業(yè)務(wù)功能,還需要獲取星上通信資源池的訪問權(quán)限,用戶才能通過星上遙控遙測資源完成與新任務(wù)的信息交互。星務(wù)軟件設(shè)計中可通過一鍵注冊的方式實現(xiàn)新任務(wù)與通信資源池的對接,無需地面介入,新任務(wù)通過資源注冊接口可獲取專屬的指令與數(shù)據(jù)空間及操作資源,自主獲取資源池訪問權(quán)限。而星務(wù)軟件可對外提供星務(wù)通信資源池的操作訪問接口,作為API接口文件面向用戶或第三方開放,通過調(diào)用該接口可實現(xiàn)自定義任務(wù)在成功加載后自主接入星務(wù)通信資源池中。星務(wù)通信資源池通過共享緩存區(qū)來實現(xiàn)星內(nèi)以及星地信息流和指令流訪問與管理,原理如圖8所示。

圖8 新任務(wù)上注流程示意

步驟如下:

1)用戶在編寫自定義任務(wù)程序時,在任務(wù)入口處進行初始化操作時,調(diào)用軟件資源管理模塊中的任務(wù)注冊接口Register_Cmd、Register_PK,輸入唯一且合法的任務(wù)ID,可自動獲取該任務(wù)專屬的指令與數(shù)據(jù)緩存區(qū),空間大小可作為入口函數(shù)的輸入?yún)?shù)由用戶自定義。

2)注冊完成后,自定義任務(wù)成功獲得緩存區(qū)操作權(quán)限,可通過Read_Cmd、Read_PK接口獲取任務(wù)的輸入信息。Read_Cmd用于獲取地面發(fā)送的遙控指令,通過ID號從星地遙控指令緩存區(qū)中識別并讀取發(fā)往該任務(wù)的遙控指令,任務(wù)根據(jù)指令類型做出響應(yīng)。Read_PK則用于獲取下位機遙測信息,通過ID號從星內(nèi)總線遙測緩存區(qū)中讀取該任務(wù)被授權(quán)操作的下位機采集的遙測包數(shù)據(jù),作為該任務(wù)工作的輸入條件。

3)任務(wù)在運行過程中可通過Write_Cmd、Write_PK接口輸出軟件控制與狀態(tài)信息。Write_Cmd用于向下位機發(fā)送控制指令,通過ID號向分配的專屬星內(nèi)總線指令緩存區(qū)中寫入指令,由總線發(fā)送給對應(yīng)的下位機,實現(xiàn)軟件對目標設(shè)備的控制。Write_PK則用于將任務(wù)運行狀態(tài)、控制參數(shù)等軟件信息寫入分配好的專屬PK包遙測緩存區(qū)中,通過遙測下行通道傳至地面,實現(xiàn)地面對自定義任務(wù)狀態(tài)的監(jiān)測。

3.2 數(shù)據(jù)補丁協(xié)議

任務(wù)重構(gòu)是一個動態(tài)過程,需要分成兩步來完成:一是任務(wù)所含所有函數(shù)及變量內(nèi)容,即任務(wù)數(shù)據(jù)補丁的上注,二是任務(wù)動態(tài)啟動的指令,即任務(wù)啟動補丁的上注。

要完成上述兩種補丁的上注,需要按照一定的數(shù)據(jù)格式要求進行對生成的任務(wù)體內(nèi)容文件進行分割及封裝,工作量較大,采用操作系統(tǒng)在軌維護工具來自動配置完成在軌維護序列的生成。生成的數(shù)據(jù)塊,可以通過地面總控發(fā)送在軌維護指令至衛(wèi)星,將對應(yīng)的數(shù)據(jù)塊寫入到配置的地址上,然后發(fā)送在軌維護啟動指令,軟件調(diào)用在軌維護接口加載對應(yīng)的數(shù)據(jù)塊,完成相應(yīng)類型的數(shù)據(jù)/函數(shù)注入功能。具體協(xié)議及操作流程如圖9所示。

圖9 任務(wù)數(shù)據(jù)補丁協(xié)議及操作流程

數(shù)據(jù)補丁分為補丁頭和補丁內(nèi)容兩部分,補丁頭由校驗和、標志位、序列號、維護類型及數(shù)據(jù)載荷大小組成,其中維護類型分為三種:數(shù)據(jù)和函數(shù)注入、新增任務(wù)、刪除任務(wù)。補丁內(nèi)容由注入頭、相關(guān)任務(wù)區(qū)、數(shù)據(jù)變量區(qū)和函數(shù)代碼區(qū)組成,注入頭包括數(shù)據(jù)補丁中相關(guān)任務(wù)數(shù)量、變量數(shù)量和函數(shù)數(shù)量,相關(guān)任務(wù)指的是與重構(gòu)任務(wù)有共享變量或者競爭關(guān)系且優(yōu)先級不同的任務(wù),重構(gòu)過程中會先將競爭關(guān)系任務(wù)掛起,等重構(gòu)任務(wù)啟動后再依次喚醒相關(guān)任務(wù),保護重構(gòu)過程的原子性。補丁制作完成后需按照星地遙控指令長度進行分割,然后按照星地遙控指令格式進行封裝[13]。

在變量/函數(shù)注入完成后還需進行任務(wù)啟動補丁的上注,完成對重構(gòu)任務(wù)的動態(tài)加載。任務(wù)啟動補丁協(xié)議如圖10所示。

任務(wù)啟動補丁也分為兩部分內(nèi)容,啟動補丁頭包括校驗和、標志位、序列號、維護類型、載荷大小。任務(wù)啟動補丁內(nèi)容中任務(wù)ID、任務(wù)名稱、任務(wù)優(yōu)先級、任務(wù)堆棧、堆棧大小、入口函數(shù)地址、任務(wù)參數(shù)等均為新建任務(wù)所需傳遞的參數(shù)。

3.3 補丁容錯及自主恢復

在軌維護場景發(fā)生一般是衛(wèi)星功能需要更新或BUG需要修復,維護完成后新增功能是插入到當前RAM區(qū)啟動運行,如果中心計算機在軌切機或者復位后,新增的任務(wù)就丟失了,此時仍然會回到舊版軟件運行。而往往地面不能及時發(fā)現(xiàn),此時維護任務(wù)就失敗了。

為了避免這種情況,在更新時代碼上注到中心計算機后,將該補丁數(shù)據(jù)拷貝到容錯SRAM中,作為重要數(shù)據(jù)保存下來,在硬件重啟或切機后,軟件初始化時對任務(wù)補丁進行逐個恢復。

上注到應(yīng)用層的新增任務(wù)是插入到內(nèi)存RAM區(qū)啟動運行的,如果星載計算機切機或者軟件復位后,上注的新增任務(wù)就丟失了,此時用戶任務(wù)的功能將無法正常運行。為了避免這種情況,在新增任務(wù)上注到星載計算機后,將該任務(wù)數(shù)據(jù)拷貝到常加電的容錯SRAM中,作為重要數(shù)據(jù)保存下來,在硬件重啟或切機后,星務(wù)軟件初始化時對用戶層任務(wù)進行逐個恢復。

任務(wù)補丁在上注時若選擇重要數(shù)據(jù)保存,星務(wù)軟件在容錯SRAM中會依次保存三份相同補丁內(nèi)容,如圖11所示。

圖11 任務(wù)補丁儲存示意

存儲成功后,星務(wù)軟件會定時讀取本機及對方機容錯SRAM內(nèi)容,采用三模冗余糾錯機制,定時刷新容錯SRAM內(nèi)容,減少單粒子效應(yīng)對SRAM的影響。刷新周期的設(shè)計需考慮對任務(wù)空閑時間的充分利用并兼顧任務(wù)負載的均衡,一般設(shè)計為10s刷新一次。

硬件復位后,星務(wù)軟件恢復,從本機容錯SRAM重要數(shù)據(jù)保存區(qū)中讀取維護的數(shù)據(jù)補丁,重新調(diào)用在軌維護接口,實現(xiàn)維護補丁的恢復。

硬件切機后,星務(wù)軟件恢復,從對方機容錯SRAM重要數(shù)據(jù)保存區(qū)中讀取維護補丁數(shù)據(jù),重新調(diào)用在軌維護接口,實現(xiàn)維護補丁的恢復?；謴瓦^程對用戶來說是透明的,復位或切機過程完成后,維護補丁第一時間恢復。

4 仿真驗證

基于以上技術(shù)方法,搭建仿真驗證系統(tǒng),以任務(wù)即插即用典型應(yīng)用場景為示例,開展仿真驗證。通過地面演示系統(tǒng),驗證技術(shù)路線的可行性,展示程序可靠接入及安全卸載的能力,為探索出快速靈活的軟件在軌重配置方法奠定基礎(chǔ)。

在實驗室搭建目標硬件環(huán)境,進行仿真驗證,組成如圖12所示。

圖12 仿真系統(tǒng)結(jié)構(gòu)示意

目標硬件性能指標如表1所示。

表1 目標硬件性能指標

以上述原型系統(tǒng)為基礎(chǔ)開展自定義任務(wù)的上注功能驗證。在上述硬件條件下建立軟件多任務(wù)運行環(huán)境,搭載高可靠的實時嵌入式操作系統(tǒng),支持基于優(yōu)先級搶占的任務(wù)調(diào)度機制。

以星務(wù)管理軟件常規(guī)功能為例,共設(shè)計9個應(yīng)用任務(wù),主要包括重要數(shù)據(jù)保存(SLIP)、熱控(TCS)、能源(PCS)、程控(EM)、故障監(jiān)測(FDIR)、在軌維護(OMT)、遙控(TC)、遙測(TM)、延時遙測(DTM)、新增任務(wù)為載荷管理(PLCS)、優(yōu)先級配置如表2所示,主要分為三檔,遙測和延時遙測最高,以確保星地遙測碼流連續(xù),遙控次之,其他應(yīng)用任務(wù)同優(yōu)先級。

表2 仿真任務(wù)列表

所有任務(wù)均在1s周期內(nèi)至少運行一遍,運行周期排布如圖13所示。

圖13 任務(wù)運行周期示意

根據(jù)在軌正常工況,模擬任務(wù)全負荷運行狀態(tài)(全功能使能,采集遙測全輸入),隨后上注新增任務(wù),流程如圖14所示。

圖14 新增任務(wù)示意

新增任務(wù)完成載荷自主管理功能,實現(xiàn)對載荷設(shè)備狀態(tài)的采集和數(shù)據(jù)預處理,該任務(wù)獨立編譯后目標碼占空間大小45kbyte,在上述硬件平臺上運行平均時間為42ms,通過指令上注實現(xiàn)任務(wù)重構(gòu),該過程共耗時18min。任務(wù)運行時間統(tǒng)計結(jié)果如表3所示。

表3 任務(wù)運行時間統(tǒng)計

表中T1代表上注前平均運行時間,T2代表上注過程中平均運行時間,T3代表上注完成后瞬態(tài)運行時間,T4代表上注完成后穩(wěn)態(tài)下運行時間,T5表示復位后恢復到穩(wěn)態(tài)情況下的任務(wù)運行時間,T6表示硬件切機后恢復到穩(wěn)態(tài)情況下的任務(wù)運行時間。上注前平均時間是通過在任務(wù)代碼中打樁插入調(diào)試信息,計算對應(yīng)任務(wù)的運行耗時數(shù)據(jù),實際運行1h后,對調(diào)試數(shù)據(jù)進行統(tǒng)計計算得到的平均值。上注完成后瞬態(tài)為地面發(fā)送重構(gòu)啟動指令后的3個運行周期。表中標紅數(shù)字表示在上注前后有明顯變化的時間信息,詳細變化趨勢如圖15所示。

圖15 任務(wù)時間開銷曲線

經(jīng)過分析,將表3中標注的任務(wù)時間信息變化原因分別描述如下:

1)上注過程中在軌維護模塊由于負載變大導致運行時間增加,在上注期間該模塊負責解析上注指令塊并實時寫入待搬移內(nèi)存空間上。

2)啟動指令由遙控任務(wù)進行處理,任務(wù)開銷略微增大,處理完成后調(diào)用加載任務(wù)接口將自定義任務(wù)加入當前就緒任務(wù)隊列中,在下一個周期任務(wù)調(diào)度時自定義任務(wù)隨即運行。

3)上注完成后的瞬態(tài),自定義任務(wù)需先進行星載資源注冊,主要完成遙測遙控緩存區(qū)資源、任務(wù)堆棧資源的注冊,被認定為注冊合法后,再啟動周期任務(wù)。因此瞬態(tài)下自定義任務(wù)運行時間較正常運行變大,進入穩(wěn)態(tài)后運行時間與獨立運行工況下一致。

4)由于新增任務(wù)的加入,原有任務(wù)中遙測與延時遙測任務(wù)運行時間變長,因為自定義任務(wù)引入了其專屬的遙測數(shù)據(jù),需原有遙測與延時遙測任務(wù)進行處理,導致其任務(wù)工作量增大,但在可控范圍內(nèi)。除此之外,其他任務(wù)未受影響。

5)在復位和切機情況后的一段時間內(nèi),重要數(shù)據(jù)恢復任務(wù)運行時間會上升至90ms左右,這是因為新增任務(wù)補丁的恢復和重啟功能在重要數(shù)據(jù)保存及恢復任務(wù)中實現(xiàn),完成從非易失存儲器中讀取補丁數(shù)據(jù)并動態(tài)加載的過程,待新增任務(wù)正常運行后,重要數(shù)據(jù)任務(wù)的運行時間隨之恢復至穩(wěn)態(tài)60ms左右的水平。

通過上注試驗可以看出,新增任務(wù)的上注對其他非相關(guān)任務(wù)的運行特性基本無影響,在新增任務(wù)加載和接入過程中的瞬態(tài)對相關(guān)任務(wù)會造成其時間性能上的抖動,加載完成后,各任務(wù)運行性能迅速恢復到穩(wěn)定狀態(tài),總的任務(wù)機時仍滿足1s周期的要求。在整個驗證過程中,各任務(wù)調(diào)度正常,未出現(xiàn)任務(wù)中斷或超時的情況,即使在硬件出現(xiàn)復位或切機的故障情況下,軟件會自動恢復新增任務(wù)補丁,重新加載該任務(wù),恢復到正常狀態(tài),說明該方法能確保重構(gòu)過程的安全性。

對于用戶來說,自定義任務(wù)的啟動和加載過程幾乎無感,且可靠。地面發(fā)送完數(shù)據(jù)塊上注指令后,只需發(fā)一條任務(wù)啟動指令,軟件會自主完成任務(wù)動態(tài)加載、遙測遙控資源注冊、數(shù)據(jù)補丁保存及故障下恢復等功能,無需地面參與,實現(xiàn)一鍵接入,大大提升現(xiàn)有重構(gòu)方法的靈活性。

5 結(jié)論

本文提出了一種支持任務(wù)重構(gòu)及自主接入的星務(wù)軟件架構(gòu),開展對任務(wù)自主接入及硬件重啟后自主恢復機制的研究,提出支持任務(wù)自主接入的星務(wù)軟件重構(gòu)流程及補丁協(xié)議,最終針對新型軟件架構(gòu)和任務(wù)接入方法進行仿真,結(jié)論如下:

1)結(jié)果驗證了在軌任務(wù)級重構(gòu)的可行性與正確性,為星務(wù)軟件設(shè)計打破硬件資源緊張帶來的條件約束提供了解決方案,大大提升了星務(wù)軟件的可擴展性。

2)方法中容錯SRAM的設(shè)計提供了軟件切機后恢復補丁數(shù)據(jù)的能力,解決了硬件復位或切機情況下新任務(wù)數(shù)據(jù)丟失且無法恢復的難題,提升了重構(gòu)功能的安全性。

3)自主接入策略完善了現(xiàn)有任務(wù)加載后新資源的分配與獲取功能,實現(xiàn)了資源一鍵注冊,自主加載,減少了地面介入,具備較好的靈活性。