支持任務自主接入的星務軟件重構方法

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

1.中國空間技術研究院 通信與導航衛星總體部,北京 100094

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

1 引言

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

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

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

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

2)傳統星務管理軟件的設計中,衛星在軌執行的任務是預先規劃好的,在軌無法進行擴展和重新規劃,而且任務相關資源也是靜態配置好,無法在軌動態重配。在實際應用中,時常需要通過任務的重構來重新定義衛星的功能及應用場景,并且實現上注任務動態加載,即插即用,現有機制無法支撐衛星任務動態擴展的需求。

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

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

2 支持任務重構的星務軟件架構設計

2.1 相關硬件環境概述

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

圖1 衛星硬件系統結構示意

(1)中心計算機

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

圖2 中心計算機組成示意

(2)容錯SRAM

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

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

圖3 容錯SRAM交叉連接示意

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

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

2.2 星務軟件架構設計

(1)分層設計

星務軟件架構遵循“軟件定義”的設計理念,通過分層設計及協議優化實現軟件組件與模塊的即插即用,提高衛星軟件產品的功能可擴展性[9],具體架構如圖4所示。

圖4 星務軟件架構示意

圖5 軟總線通信示意

該框架從子網層到支持層,再到用戶應用層均采用自適應的交互協議,可實現自定義任務的即插即用。

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

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

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

(2)軟總線設計

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

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

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

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

(3)鏈接腳本設計

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

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

圖6 定點鏈接原理示意

圖7 任務重構流程示意

可以看出,星務軟件架構中的分層設計保證了新增任務與已有任務邏輯層面的分離,而基于鏈接腳本的定點鏈接設計,則實現了新增任務與已有任務物理空間的分離,進一步保證了新增任務對已有星務軟件系統的影響是嚴格可控的。

3 任務上注、接入及恢復機制

目前,衛星軟件在軌重構主要通過在軌維護方式實現,傳統在軌維護方式重構的顆粒度較大,維護方式過于粗放,且對上行信道資源占用時間開銷很大,效率較低。

本文在現有軟件維護的基礎上進行優化,采用定點鏈接技術,實現新型的支持任務自主接入的重構機制,全面支持用戶任務的自適應擴展。同時設計任務重構的數據封裝協議,支持任務動態的新增、刪除和修改,對重構后的新功能提供斷電后自主恢復服務。

3.1 任務上注及自主接入流程

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

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

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

圖8 新任務上注流程示意

步驟如下:

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

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

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

3.2 數據補丁協議

任務重構是一個動態過程,需要分成兩步來完成:一是任務所含所有函數及變量內容,即任務數據補丁的上注,二是任務動態啟動的指令,即任務啟動補丁的上注。

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

圖9 任務數據補丁協議及操作流程

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

在變量/函數注入完成后還需進行任務啟動補丁的上注,完成對重構任務的動態加載。任務啟動補丁協議如圖10所示。

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

3.3 補丁容錯及自主恢復

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

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

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

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

圖11 任務補丁儲存示意

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

硬件復位后,星務軟件恢復,從本機容錯SRAM重要數據保存區中讀取維護的數據補丁,重新調用在軌維護接口,實現維護補丁的恢復。

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

4 仿真驗證

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

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

圖12 仿真系統結構示意

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

表1 目標硬件性能指標

以上述原型系統為基礎開展自定義任務的上注功能驗證。在上述硬件條件下建立軟件多任務運行環境,搭載高可靠的實時嵌入式操作系統,支持基于優先級搶占的任務調度機制。

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

表2 仿真任務列表

所有任務均在1s周期內至少運行一遍,運行周期排布如圖13所示。

圖13 任務運行周期示意

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

圖14 新增任務示意

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

表3 任務運行時間統計

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

圖15 任務時間開銷曲線

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

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

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

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

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

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

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

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

5 結論

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

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

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

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