基于動態庫的星載軟件可重構設計與實現

白 亮，邱 源，韋 杰，孫逸帆，高 潔

（1.上海航天智能計算技術重點實驗室，上海 201109；2.上海航天電子技術研究所，上海 201109）

0 引言

星載嵌入式操作系統處于遠程遙控的環境中，其軟件的維護與修復相較于本地系統故障恢復要困難許多，無法進行手工維護，只能依靠操作系統的自我維護功能，以及接受地面上傳的有限維護指令進行運行過程中的動態自我修復和更新。

針對星載嵌入式操作系統上運行的軟件在長時間的運行過程中不可避免出現“軟件衰老”現象［1］，即伴隨著軟件的運行，系統資源逐漸耗盡或運行錯誤逐漸積累所導致的系統性能持續下降甚至停機的現象，采取在軌可重構措施來恢復軟件性能。

星載嵌入式操作系統工作于惡劣環境中，星上的設備暴露于外太空，易受到外部環境的影響，從而對系統產生影響。而操作系統負責管理平臺所有外部設備，系統的可靠性和安全性對操作系統的管理具有依賴性［2］。而且，操作系統在運行過程中，也會暴露出一定的設計缺陷［3］，或是測試過程中沒有發現和排除潛在設計缺陷。但是可以通過在軌可重構技術對軟件進行修正與完善，進一步提高星載系統的安全性和可靠性。同時，還可以針對在軌運行衛星，通過可重構的方式，基于現有功能基礎，實現衛星功能的升級和擴展，實現衛星的“App”（應用程序）式的快速開發和快速集成。

隨著計算機技術的發展，基于動態庫的可重構技術被廣泛應用于商業等各個領域，主要由于動態鏈接庫與主程序之間通過接口調用產生依賴關系，只要保證動態鏈接庫輸出接口不變，更換動態庫不會對主程序造成任何影響，可以提高程序的可維護性和可擴展性；而且不同編程語言編寫的程序，只要遵守相同的應用程序調用約定（Application Binary Interface，ABI），就可以調用同一個動態鏈接庫；使用動態鏈接庫，適用于大規模的軟件開發，使得開發過程獨立、耦合度小，便于多人團隊間進行協同開發和測試；同時，多個應用程序使用相同的動態鏈接庫時，在磁盤中可以只存在一份動態鏈接庫文件，相比其他技術，可以節約磁盤空間。基于上述優點，在現代化大型軟件開發中，大量應用動態鏈接庫技術。而且利用動態鏈接庫技術的一個最大優點在于，針對動態鏈接庫更新升級后不用重新啟動主程序，只需將更新的動態鏈接庫重新載入程序的內存空間即可。基于該特點，將動態鏈接庫技術應用于星載嵌入式軟件的在軌重構實現中，既可以達到上述所有優勢，又不需要星載系統軟件重新啟動，即在軌重構的實現不會對既定星載任務（如程控、數傳、熱控等任務）運行產生影響。基于動態鏈接庫技術，在軌重構包是以文件的形式存在，即使衛星發生異常重啟后，前一次在軌重構生成的補丁包仍然在，且重啟運行后，直接使用重構后的程序，使得在軌重構技術對衛星可靠安全在軌運行提供支撐。

隨著星載系統的發展，星載嵌入式軟件在軌可重構技術也在持續不斷發展。目前常用的在軌可重構技術有基于RAM 型和微重啟等。隨著高性能處理器的發展，傳統在軌可重構方式能否在高性能處理器平臺上繼續適用，需要作全面評估和驗證測試。本文所提出的方案，以高性能處理器平臺為出發點，進行設計、實現和驗證。針對在軌衛星通過實際在軌可重構操作后，進一步驗證本方案的有效性、安全性和可靠性。

1 基于星載嵌入式操作系統的可重構軟件框架

本文中設計了一種基于星載嵌入式操作系統的可重構軟件框架，嵌入式操作系統的層次如圖1所示。本軟件框架實現的硬件平臺基于國產化處理器國微SM750，操作系統為風云翼輝（AIC-OS）嵌入式操作系統1.11.0，開發環境為RealEvo-IDE 3.9.10。整個系統可分為4 個層次：處理器層、操作系統內核服務及BSP 層、中間件層和應用層。其中，在本系統中中間件層由動態鏈接庫的形式來實現。應用層由嵌入式軟件框架和各個應用組件構成，在不同時刻加載不同應用組件時，應用層功能將可以隨之發生變化而無需重新加電或復位操作系統，從而實現了嵌入式軟件的功能可重構。而可重構軟件框架作為一個中間層的形式運行在操作系統與應用組件之間。一方面通過對應用組件的動態加卸載、系統資源管理、多組件管理等功能實現了嵌入式軟件功能的可重構；另一方面它為應用組件屏蔽了底層細節，使之與硬件和操作系統隔離，從而可以實現組件的二進制級復用。針對通用功能組件，無需重新修改和編譯，直接通過多組件動態重構即可完成應用軟件功能的重新定義，降低開發成本，同時縮短軟件開發周期。

圖1 星載軟件可重構框架層次圖Fig.1 Hierarchical diagram of reconfigurable framework for on-board software

2 星載軟件可重構的實現方案

2.1 利用嵌入式操作系統的微重啟實現可重構方案

嵌入式操作系統微重啟的可重構方案采取可遞歸恢復框架實現，具體由故障檢測代理、恢復管理器和恢復代理3 個模塊組成，如圖2 所示。故障監測代理負責實時監測系統的運行狀態，查找系統故障并將相關信息傳送給恢復管理器，故障監測代理將所有系統運行狀態的變化信息遞交給恢復管理器［4］。恢復管理器動態地保存系統的故障傳播信息，當它接收到從檢測代理發送過來的故障信息時，采用自動故障路徑推斷（Automatic Failure-Path Inference，AFPI）恢復策略，針對給定的遞歸重啟樹，計算最優的遞歸恢復路徑［5］，并觸發恢復代理，實現組件或者嵌入式操作系統的微重啟操作。通過裁剪嵌入式操作系統內核，將嵌入式操作系統原有功能模塊上移至用戶態組件層，同時確保裁剪后的嵌入式操作系統內核能夠穩定運行。將微重啟功能組件置于內核內，使微重啟功能組件的權限高于功能性組件，從而有效地控制功能性組件的微重啟動作。

圖2 嵌入式操作系統微重啟的可重構實現方案Fig.2 Reconfigurable scheme for embedded operating system micro-restart

2.2 基于RAM 型的軟件動態升級實現可重構方案

基于RAM 型的軟件動態升級主要過程如下：在軌運行系統中發現軟件故障或軟件缺陷后，由開發人員在軟件開發機中修改軟件，將修改信息形成軟件補丁，通過在地面目標機中進行模擬運行測試，驗證本次形成的軟件補丁的有效性和正確性；然后提交到地面監控系統，由地面監控系統發送至在軌設備上；接著在軌設備對在軌系統進行動態修改，通過反饋至地面監控系統在軌可重構的信息。

為了滿足上述需求，設計了在軌軟件維護系統，其功能分解如圖3 所示，3 個功能模塊分別為：1）補丁生成模塊，包括補丁信息獲取、補丁創建和補丁發送等；2）在軌修改模塊，包括補丁接收、變量修改、代碼修改、任務處理等；3）維護監控模塊，包括維護信息反饋、反饋信息接收與處理等。

圖3 基于RAM 型軟件動態升級的可重構方案Fig.3 Reconfigurable scheme based on the dynamic upgrade of RAM-type software

在圖3 中，基于RAM 型的軟件動態升級實現可重構方案由軟件開發機和地面目標機兩個子系統組成，整個系統各功能模塊分布于各個子系統之上，開發機和地面目標機之間通過以太網或者串口進行通信。兩個子系統協同工作，共同完成基于RAM 型的軟件動態升級可重構驗證［6］。

2.3 利用動態庫實現星載軟件的可重構方案

星載軟件在軌可重構是通過遙控注數的方式，將軟件的可執行代碼注入到星載計算機中，替換原有模塊實現。風云翼輝嵌入式操作系統在SM750平臺實現了虛擬內存管理技術，支持應用軟件以動態加載的方式設計實現和運行。

動態加載意味著編譯生成的可執行目標文件與地址無關，則可以利用動態鏈接庫實現對星載應用軟件中特定功能的封裝［7］。將具有相對獨立功能的模塊編寫為動態鏈接庫，應用軟件在實現需求中定義的功能時，為滿足特定的功能，可將具有該功能的動態庫鏈接進來，從而星載軟件最后的形態是以主程序加若干動態鏈接庫呈現。

動態庫中只實現特定功能，其規模可以做得較小，從而減輕每次在軌上注時信道的壓力。而且在功能升級或者缺陷修復實現可重構時，可以只針對單一模塊進行，從而提高星載軟件在軌可重構方案的安全性和可靠性。

基于動態庫實現星載軟件可重構流程主要包括重構軟件準備、重構軟件分發、重構軟件加載和重構結果反饋4個步驟。軟件重構流程如圖4所示。

圖4 基于動態庫實現可重構方案Fig.4 Reconfigurable scheme based on the dynamic library

2.4 可重構實現方案比較

相對于重啟整個系統而言，微重啟花費的代價較小。同時，重啟單個服務的速度遠比重啟整個系統快得多，并且微重啟僅對重啟的服務和服務的進程造成影響，而不會影響到系統中其他服務的正常運行。但是該種方案僅適用于部分數據不正常，重啟后修復原來錯誤的數據，而針對軟件缺陷或者軟件錯誤，該方案無法徹底修復。

基于RAM 型的軟件動態升級實現可重構過程的可靠性和安全性要求極高，一旦出現失誤有可能導致整個系統軟件的失效。

與地面系統不同，受天地通信速率、入站頻率及過站時間等多方面因素的限制，星載軟件的在軌升級很難達到與地面軟件升級相同的實時性。而且，上注的星載軟件可重構的內容存儲于內存中，軟件復位后，可重構的內容不復存在，還需要重新上傳。

基于動態庫實現的可重構方案，將已存在于在軌設備上的不同模塊進行動態的裝載與卸載，以提供不同功能，或提高系統運行速度。借助文件系統隨時停止、加載、運行某個或某幾個特定模塊，而不會影響系統當前運行的其他功能，且單個模塊編譯生成的目標文件都比較小，狀態控制和維護相對比較容易。

通過上述分析可知：使用動態庫中間件的形式應用于目前星載系統中，具有較高的可靠性和安全性。而且采用此方法實現星載軟件可重構，具有較強的軟件可擴展性，易于實現在軌星載軟件功能的全部替換和特定功能的可重構。

3 星載軟件可重構方案的設計與驗證

3.1 可重構設計

3.1.1 方案設計

本設計中，采用基于動態庫的形式實現星載軟件的可重構，利用嵌入式操作系統提供的動態加載功能，對在軌星載軟件的特定功能實現可重構，修復已有的軟件缺陷或者漏洞。

星載軟件在設計初時，已經將部分功能相對獨立的部分編寫成可鏈接的動態庫，后續在軌可重構既可以針對每個獨立的動態庫，也可以針對主模塊進行重構，設計方案如圖5 所示。

圖5 在軌可重構設計方案Fig.5 On-orbit reconfigurable design scheme

3.1.2 數據包格式設計

根據3.1.1 節方案所述，針對需要實施在軌可重構的模塊，編譯生成可執行目標文件后，需要將該文件中的二進制數據按著標準國際空間數據系統咨詢委員會（Consultative Committee for Space Data Systems，CCSDS）協議封裝為遙控包。為可重構設計了對應的上注重構數據包格式如圖6 所示。

圖6 可重構上注數據包格式Fig.6 Reconfigurable upload packet format

在圖6 中，首包格式同后續包差異較大，將地面生成的可執行目標文件所屬的進程編號、文件索引，以及文件的消息摘要算法（Message Digest Algorithm MD5，MD5）值打入首包。將這些信息上注給星載計算機，作為后續文件完整性校驗的依據。

引用該算法，是因為MD5 算法可以將任意長度的輸入串經過計算得到固定長度的輸出，而且只有在明文相同的情況下，才能等到相同的密文，并且這個算法是不可逆的，即便得到了加密以后的密文，也不可能通過解密算法反算出明文。針對文件完整性和安全性時，具有突出的優點。

在上注的每一個數據包中都有包序號，作為后續文件完整性校驗和接收結束的依據。當接收結束后，通過逐一判斷接收到包序號，當發現有缺包的情況時，會將缺少的包序號打入遙測量下傳，地面可以通過該遙測量確定補發動作。

3.1.3 實施流程

可重構數據包生成后，將這些數據包當作正常的遙控注數包，當衛星在測控弧段內時，上注給需要重構的在軌衛星，具體的實施流程如圖7 所示。

圖7 可重構實施流程Fig.7 Reconfigurable implementation flow chart

3.1.4 可靠性和安全性保證

衛星在軌自主運行時，無法像地面測試階段實時監視其運行狀態，只能通過有限的下行遙測量監控其運行狀態［8］。本方案設計中，設計了相應的可重構模塊的遙測量，包括正確包計數、錯誤包計數、錯誤包編號、可重構的模塊編號等遙測量。在遙控上注過程中，可以通過實時遙測查看當前在軌可重構情況。當有數據包校驗錯誤，會將錯誤包的包號下傳，此時，地面只需要補發錯誤的單個數據包，即可修復上注錯誤。

在上注的每包遙控包末尾都有相應的CRC 值校驗，可以完成本包數據的正確性校驗。上注的數據并不是立即寫入文件系統，而是暫存在內存空間，當接收完全部的數據包后，通過對整個文件的完整性校驗通過后，再將全部數據寫入文件系統，形成對應的文件，保證生成的文件的完整性。

每次實施在軌重構時，都會將之前的文件存儲為備份版本，并不會自主刪除。當啟動重構后的模塊運行后，通過下行遙測發現其功能不符合預期時，可以進行版本回退，保證星載系統軟件的安全。

在文件系統中，針對每一份可執行目標文件，都有相應的出廠版本，當某次可重構實施過程中出現失誤，造成星載系統軟件損壞［9］。此時，將整星進行瞬時斷電一次，全部可執行目標文件回到出廠版本，保證整星的安全。運行正常后，可以通過遙測上注，指定單個的應用或者某個動態庫使用最后可重構后的版本，啟動最新功能。

3.2 驗證實施

初始化時，針對需要在重構的模塊函數進行注冊，形成函數表［8］。在某一時刻，需要針對某一函數進行重構時，通過遙控命令的方式，完成新的模塊函數編成動態鏈接庫上載，星上系統根據相關信息打開動態鏈接庫，映射對應函數，替換已經創建函數表中對應函數指針，完成可重構。

為實現在AIC-OS 操作系統下的在軌可重構，需要把即將重構的模塊編寫到動態鏈接庫中［10］，生成一個動態鏈接庫文件，通過上行通道，將生成的動態鏈接庫文件上傳到星載計算機的文件系統中。當計算機收到重構遙控命令時，將接收文件存儲到文件系統中，并根據遙控命令類型，分別通知相應進程，同時分別打開動態鏈接庫，實現對應函數的映射。

為實現將目前定義的確定函數調用同重構后對應的函數調用間的無縫銜接，特定義如圖8 所示的結構體。其中，name 成員為該確定函數的名稱，名稱是實現正確映射的關鍵，所以名稱一定要保證正確；ready 標志只是用來表示是否映射成功，可以忽略不用；com_ptr 為函數指針，用于表示在沒有可重構之前的函數指針，類型為void*（*）（void*），即輸入參數為void*類型，返回類型為void*類型的函數指針，將輸入參數定義為void*類型的原因是為兼容不同函數對輸入參數類型的限定。當有多個參數時，可以定義為結構體，調用函數時，只需要將該結構體傳入即可。new_ptr 類型同com_ptr，用于表示當發生重構時新映射的函數指針。

圖8 實現可重構的結構體Fig.8 Reconfigurable structure

這樣的結構定義可以實現對多個模塊進行重構［11］，將多個可重構對象組成一個數組，根據索引進行相應的替換，如 onboard_func_obj_t onboard_func_obj［12］。當然，這個索引和對應的函數之前的關系需要自己定好。可重構模塊調用示例如圖9 所示。

圖9 實現可重構的函數調用示例Fig.9 Example of implementing a reconfigurable function call

可重構驗證過程中，分別給對應進程使用了不同的動態鏈接庫，即各自使用一個動態鏈接庫文件。其中，一個進程中將要實現可重構的函數定義如圖10 所示。

圖10 需要重構進程的原函數Fig.10 Original function of the reconstruction process

當上位機發送完遙控數據包后，嵌入式操作系統負責監視遙控信息的線程將動態鏈接庫文件寫入文件系統中，主動通知需要重構的進程，當需要重構的進程收到該信號后，調用dlopen（）打開動態鏈接庫文件［12］，對相應的函數進行映射，運行結果如圖11 所示。

圖11 實現可重構后的運行結果Fig.11 Results after reconfiguration

運行結果顯示，利用動態庫形式，能夠較便捷地實現星載軟件的可重構。

4 結束語

星載軟件的可重構機制對提高整星系統安全性和可靠性有著舉足輕重的作用，并為衛星長期在軌穩定運行和在軌任務的擴展提供保障。本文對3種實現星載軟件可重構方案的進行優缺點比較，選擇利用動態庫形式實現。詳細闡述了基于動態庫形式的星載軟件可重構實現方案、數據包格式、實施流程及實施過程中可靠性和安全性的保證。通過具體的實例，完成基于動態庫的星載軟件可重構驗證。結果表明：基于動態庫形式的可重構機制的運用，可以有效豐富和擴展星載軟件開發模式和架構設計，為未來實現“App”式的星載軟件開發奠定基礎。本重構實現方案可以有效提升在軌衛星實現星載軟件可重構過程中的安全性和可靠性。