空間飛行器主控計算機軟件架構研究

賀彥博 徐曉輝 彭立章 徐峰

摘 ?要：空間飛行器研制正在由專用化向通用化方向轉型，因此必須改變當前為每個型號重新開發業務軟件的現狀。本文闡述了層次化軟件基礎平臺的設計思想，引入國際標準，結合空間飛行器業務需求建立了可通用的主控計算機軟件架構。

關鍵詞：空間飛行器;飛行軟件;軟件架構

中圖分類號：TP311.1 ? ? 文獻標識碼：A

Abstract：Spacecraft development is transforming from specialization to generalization，so the current status of software redevelopment for each project must be changed.This paper describes the design hierarchy based software platform，introduces international standards，establishes a main control computer software architecture that can be generalized in combination with the requirements of spacecraft industry.

Keywords：spacecraft;flight software;software architecture

1 ? 引言（Introduction）

隨著航天科技的持續發展，航天工業部門面臨日益增長的研制壓力。相比以往，研制任務更加繁重而研制周期不斷縮短，同時客戶又對航天器任務提出了更高的可擴展性要求。包括美國航空航天局和歐空局在內的主要國際航天組織均面臨空間任務愈加復雜、軟件規模持續增長的情況。以歐空局為例，該組織管轄下的空間任務飛行器主控計算機軟件的規模在過去的30多年里持續增長，如表1所示。

軟件規模的持續增長使得歐空局面臨較大的研制壓力，于是歐空局提出了空間航電開放接口體系（SAVOIR）作為空間電子設備的參考體系，該參考體系提出如下軟件工程要求[1]：

（a）軟件生產效率

縮短軟件開發時間，節省軟件確認和驗證消耗，避免重復開發，提高效費比，保持并提高軟件產品質量。

（b）增加反應性

緩解項目后期需求變動帶來的沖擊，簡化并協調故障檢測、隔離和恢復（FDIR）。

（c）增加靈活性

支持不同類型的系統集成策略，支持工業界策略和商用標準，支持多軟件供應商策略，支持分發活動，以及未來其他需求。

滿足上述要求的關鍵是軟件構件的可重用性：

（a）體系結構重用：標準化、可組裝、功能可組合的組件模型。

（b）功能重用：業務的標準化及軟件組件的可重用性。

以往針對特定任務目標重新研制專用飛行軟件的方式使得空間飛行器的成本高昂，因此亟待改變研制模式，在未來用途廣泛、性能先進而價格可承受的通用空間飛行器基礎軟件平臺將是研制的主流方向?？臻g飛行器基礎軟件平臺需在各個型號中復用，在軌運行過程中也需要持續拓展飛行任務，因此要求軟件基礎平臺具備架構易復用、模塊易維護、功能易擴展、在軌易重構和研制成本可負擔的特性。

2 ? 當前面臨的問題（Current problems）

對于空間高可靠性計算機系統而言，特別是對器件中的各種存儲單元，單粒子效應是影響并制約系統可靠性及其使用壽命的主要因素。

在傳統的飛行器中，主控計算機一般使用具有抗輻射指標的可編程只讀存儲器（PROM）、SRAM的硬件配置。由于PROM在抗單粒子方面具有高可靠性，飛行軟件一般在PROM中運行，而將SRAM作為程序運行的緩存區。在默認流程中系統自動執行飛行軟件業務流程以完成系統主要功能，當需要進行軟件調試時，則啟動調試功能從串口加載測試軟件。

該模式在行業內廣泛應用，技術成熟，爭議最少，但該模式具有明顯的缺陷。具體如表2所示。

現階段空間飛行器中，大多將軟件劃分為設備管理軟件和應用軟件兩個層次，在應用軟件層并未做更具體的分層設計，該模式適用于針對專用裝備研制專用軟件的任務，易于硬件研制單位與總體設計單位分工協作。

目前已存在部分新型號將軟件劃分為設備訪問層、服務組件層和應用任務層，具備了現代大型軟件架構的雛形，但缺乏參考標準和操作系統支持，層次劃分不夠清晰、業務軟件組件間的耦合仍然較多、軟件復用率較低，若面臨新的業務需求仍會引發大規模代碼變更。

傳統的軟件設計方法在當下型號研制工作中仍然具有參考價值，但新型的多用途空間飛行器對軟件提出了更高的可復用性和可維護性要求，因此亟待將更先進的軟件技術投入工程應用。需解決的問題如下所示：

（a）降低軟件維護的代價

目前，飛行器研制過程中軟件部署流程復雜且固化后難以更改，導致軟件研制成本居高不下、軟件難以快速迭代，進而影響軟件產品的質量;若在飛行器型號正樣階段軟件固化后再次發現程序缺陷，由此帶來的計算機下器處理會導致型號進度受到嚴重影響;處于在軌飛行階段時進行大規模軟件升級較為困難，也會極大制約飛行器空間任務拓展能力。

（b）建立軟件參考架構

現階段軟件架構層次劃分不清、模塊間耦合過多、各型號軟件架構差異過大，導致軟件復用率較低，研發效率不高，研制成本居高不下。歐空局、NASA等機構的軟件參考架構難以直接在我國工業部門的軟件研制中落地，因此需要根據具體業務有針對性的引入行業標準，并設計適合于我國空間飛行器需求的軟件參考架構。

3 ? 軟件參考體系設計（Software reference architecture）

3.1 ? 部署與運行

為解決軟件在研和在軌過程中維護代價過高的問題，要求空間飛行器主控計算機平臺配置的存儲硬件為PROM、FLASH/EEPROM和SRAM三者結合的方式。相比傳統模式，由于FLASH/EEPROM的抗單粒子性能遠不及PROM，在該新模式下如何應對單粒子效應的影響是較為重要的問題。另外，基于FLASH/EEPROM芯片的固有特性，通過設計在線燒寫軟件功能，使得系統具備了更加靈活的軟件部署能力。芯片特性對軟件的影響情況如表3所示。

基于該硬件配置，軟件系統在PROM中部署系統bootloader（啟動、加載）軟件和最小模式軟件，在FLASH/EEPROM中部署飛行軟件。其中boot功能實現計算機資源的初始化，loader功能實現從串口或從FLASH/EEPROM加載飛行軟件兩種運行模式，最小模式軟件用以進行緊急故障應對和大規模軟件在軌重構。

最小模式軟件可實現系統在軌應急狀況下的安全處置，并支持在軌和地面研制過程中對軟件進行全部更新。在軌期間，當系統出現嚴重故障或者需要大規模修改時，將軟件切換至最小模式，該模式以系統最簡配置保證平臺的姿態、能源安全，建立應急通信通道和故障反饋機制，使得飛行器具備通過地面干預而恢復正常工作狀態的能力。

啟動加載軟件運行后通過倒計時等待用戶選擇加載對象，若超過倒計時無操作則自動加載飛行軟件，工作模式如下所示：

（a）默認模式

在軌期間飛行器平臺上電或復位后，首先從PROM運行啟動加載軟件，而后自動以三取二方式加載FLASH/EEPROM中的飛行軟件到RAM中，并跳轉到RAM中開始執行飛行軟件功能。

（b）故障模式

當系統發生嚴重故障或需要大規模重構時可切換進入最小模式軟件，在保障系統能源、溫控與姿態安全的基礎上進行故障監測和在軌軟件重構。

（c）調試模式

在地面研制過程中，可在倒計時時刻選擇串口接收加載功能，用于對FLASH/EEPROM中的程序和數據進行重新編程。

3.2 ? 軟件架構設計

軟件系統實現飛行器核心管理控制，整合程控、導航、姿軌控、機構控制、遙控遙測、能源管理、溫度控制、健康安全維護等功能。

應用實時操作系統，建立層次化、組件化和標準化的開放式軟件架構，提高產品的靈活性、減小維護升級的代價，實現系統的靈活管理控制，為核心軟件組件及飛行任務的持續革新提供良好的基礎平臺。

3.2.1 ? 軟件層次設計

軟件設計方式由以往面向系統硬件資源處理的設計方式，轉而面向基于系統需求的功能組織[2];軟件設計中將設備面與應用面分離，以設備面實現硬件資源的訪問處理，以應用面實現系統平臺的靈活功能定義。

設計遵循策略與機制分離的原則，以軟件定義飛行器為基本設計思想，建立基于分層體系結構的開放式軟件架構。

（a）策略與機制分離

軟件設計中將平臺的管理和控制功能劃分為飛行任務策略和平臺基礎機制兩部分，加強平臺基礎機制的完備性和穩定性，并以此為基礎構建靈活多變的飛行任務策略，同時要求任務策略具備可快速全面重構的能力。

（b）體系結構開放性

借鑒工業界軟件定義網絡與歐空局軟件定義衛星的設計思想，確立將應用面與設備面分離的原則，以應用面重定義實現飛行任務的靈活擴展。

軟件設計實現縱向層次化和橫向組件化，支持設備的即插即用管理，支持因適應技術進步或任務變化而對局部或全部軟件實施快速變更，使得體系結構具有良好的開放性和較強的適應性。

軟件實施層次化設計，借鑒通用開放式結構（GOA）標準將各項功能分解到應用任務管理、系統服務組件和設備資源訪問三個層次[3]，如圖5所示。

（a）應用任務管理層使用實時操作系統調度各系統任務，實現平臺資源的管理和試驗流程的控制。

（b）系統服務組件層包含程控機制、平臺內務管理、姿態軌道控制、機構控制、安全可靠性支持和應用支持庫等，為任務系統提供基礎應用組件支持。

（c）設備資源訪問層管理平臺硬件資源并提供平臺狀態信息和平臺命令執行的操作接口。

3.2.2 ? 軟件多維度解耦及可維護性設計

主控計算機軟件實現操作系統內核與應用軟件、控制面與設備面、應用軟件與應用軟件之間等多個層次和緯度的解耦，如圖6所示。

（a）建立平臺設備抽象層以將應用業務與設備資源分離，并實現應用面的通用化和可維護性。

（b）將操作系統內核與應用軟件分離編譯[4]，并啟用權限分級機制。

（c）應用RTP實時進程機制[4]，實現應用軟件之間的空間隔離。

（d）將基礎業務框架實現為動態鏈接庫，以供各個應用程序調用。

（e）應用SOIS星上接口業務標準，實現設備與平臺設備管理軟件的解耦。

飛行軟件將各應用業務作為獨立的應用程序，操作系統實時進程（RTP）機制保證了任務調度的實時性、存儲空間與時間資源的確定性[4]。內核與應用軟件的隔離保證了應用程序的崩潰不影響內核的穩定性，應用軟件之間的隔離保證系統的整體穩定性，具體飛行任務與基礎業務框架的分離使得軟件基礎平臺的可復用程度得以提高。

系統基于實時操作系統內核系統調用和用戶層軟件組件庫，支持應用軟件和基礎業務框架的獨立開發和調試，并支持通過安裝不同的應用程序實現地面快速集成和部署。在軌飛行期間，通過增加、刪除或更改應用程序和動態鏈接庫以實現飛行任務的快速重構。

3.2.3 ? 行業標準參考

可通過應用行業標準降低研制成本和提高產品質量，可參照的行業標準或協議如表4所示。

3.2.4 ? 軟件架構設計

依據軟件協同設計思想，通過縱向分層和橫向組件化設計，建立資源訪問、服務組件和系統任務等三個軟件層面，制定各層次和各組件的標準業務及接口規范，如圖8所示。

各層次功能劃分如下所示：

（a）資源訪問層——設備層和驅動層

設備層由構成飛行器的各種硬件設備構成。除處理器、存儲器、時基、通訊接口、看門狗等計算機資源外，還包括通過總線連接的推進、載荷、電源、姿軌控傳感器與執行器等飛行器設備。

驅動層包含了實時操作系統和各類設備驅動，為上層應用提供訪問底層設備的API接口、三模輸出數據表決和多任務管理機制等支持。

（b）資源訪問層——平臺設備抽象層

抽象層根據平臺敏感器、執行器等設備的不同類別，對驅動層提供的操作接口進行封裝，向上提供設備訪問的標準接口，屏蔽底層軟件實現細節，屏蔽硬件設備的細節差異，使得服務組件層的設計不至過度耦合平臺設備特殊性。

通過平臺設備抽象設計，實現了上層軟件與設備特殊性的解耦，降低對硬件平臺的依賴，最大限度保證軟件的可復用性，推動未來發展中平臺設備功能與接口的標準化。

（c）服務組件層

服務層包含飛行器管理控制領域常用的應用組件，為任務系統提供基礎支撐。業務、通信和內務管理組件參照歐空局星地操控基礎協議建立監視業務、測試業務和事件報告業務等16個子服務[7]，利用遙控包和遙測源包監視和控制星上各分系統，以及有效載荷;軌道與姿態控制組件包括導航、姿控和軌控等常用基礎算法模塊;機構控制組件包括天線、太陽翼等常用機構控制算法庫;應用支持庫包括常用數學庫、安全C語言庫等;數據與任務管理器提供整器狀態數據的集中管理、飛行器設備狀態采集和指令分發等基礎管理。

（d）應用任務層

任務層包括了系統配置與設備管理、規劃與自動執行、在軌測試管理、系統模式管理、AOCS管理、能源管理、中心FDIR和固態存儲管理等飛行器頂層功能。

其中系統配置與設備管理任務實現飛行器設備配置的動態管理;系統模式管理任務負責飛行器在不同硬件配置情況或不同飛行階段時工作模式的預置和切換;規劃與自動執行任務負責飛行器飛行任務的子事件規劃、動作執行和反饋狀態監控等;在軌測試管理任務負責整器的自動測試與狀態報告匯總下行功能;中心FDIR負責故障的自主診斷、隔離和處理功能;在軌維護模塊負責軟件的在軌重構功能[4]。

4 ? 應用情況（Application situation）

經實踐檢驗，基于FLASH/EEPROM的軟件部署與運行模式可有效增強軟件研制過程中的可維護能力和在軌飛行過程中的可重構能力，大大提高了型號軟件研制的效率和質量。但對于需要長期留軌執行任務的空間飛行器，該模式在復雜空間環境中的可靠性和安全性仍有待進一步驗證。

引入工業界技術成熟的操作系統可解決軟件研制中目前存在的業務間高耦合、程序難維護等問題，但由于目前星載設備中處理器性能和存儲空間均嚴重受限，且對軟件的可靠性、安全性要求較高，因此對操作系統實時進程、動態鏈接庫和可加載內核模塊等技術的應用仍處于試驗驗證階段。

軟件參考架構的制定使得空間飛行器主控軟件的開發工作有章可循，軟件模塊的復用率有所提高。隨著軟件設計方法的改進和軟件組件復用率的提高，輔助以地面研制階段在線更新和在軌運行階段軟件任務拓展等技術手段，軟件的研制效率、反應性和靈活性均有所提升，推動了型號整體研制效率的提高并有效降低了綜合研發成本。但該參考框架中提及的ESA-PUS等標準協議在當前星載軟件業務中的應用仍處于探索階段，需要在對現有成熟業務模式進行充分分析的基礎上，結合用戶實際需求，從器地一體化設計的角度對飛行器操控模式和地面應用系統進行整體技術革新。

5 ? 結論（Conclusion）

隨著空間飛行器平臺由專用化向通用化的發展，必須改變針對特定飛行器重新開發飛行軟件的研制模式，對飛行軟件的可維護性、可復用性和研制成本等提出了更高的要求，因此構建通用化基礎軟件平臺具有重要意義。本文描述了空間飛行器軟件基礎平臺的設計要點，參照國際標準，確立了層次化、組件化的設計原則，設計了可通用的新型主控計算機軟件參考架構。

新型軟件參考架構在實際項目中的落地仍需一個長期持續的過程，需要改進軟件設計方法，并建立與之適應的技術管理體制，才能真正提高星載軟件的研制質量和研制效率。

參考文獻（References）

[1] ESA.SAVOIR-FAIRE[EB/OL].http：//savoir.estec.esa.int，2018-5-29.

[2] 蒲小勃.現代航空電子系統與綜合[M].北京：航空工業出版社，2013：386.

[3] AS4893，Generic open architecture （GOA） framework[S].USA：SAE，2002.

[4] 美國風河系統公司北京辦事處.風河全面整合DO-178B和IEC 61508新安全平臺[EB/OL].http：//www.ipcm.com.cn/yjdt/20101020162643.htm，2010-10-20.

[5] CCSDS 732.0-B-3，AOS Space Data Link Protocol[S].Washington，DC，USA：CCSDS，2015.

[6] CCSDS 850.0-G-2，Spacecraft Onboard Interface Services[S].Washington，DC，USA：CCSDS，2013.

[7] ECSS-E-70-41A，Space engineering—Ground systems and operations[S].Noordwijk，The Netherlands：ESA-ESTEC，2003.

作者簡介：

賀彥博（1984-），男，碩士，高級工程師.研究領域：航天器軟件設計.

徐曉輝（1975-），男，碩士，高級工程師.研究領域：航天項目管理.

彭立章（1984-），男，碩士，高級工程師.研究領域：航天器軟件設計.

徐 ?峰（1976-），男，碩士，研究員.研究領域：航天器總體設計.