中型敏捷遙感衛星公用平臺數管分層軟件架構

張亞航 楊培堯 趙思陽

(北京空間飛行器總體設計部，北京 100094)

軟件架構用于軟件模塊與模塊，軟件與環境之間的關系進行全局描述[1-2]，軟件架構決定了軟件本身的通用性、靈活性和適應性[3]。傳統衛星的設計思路大多數是先根據任務需求確定硬件結構和配置，其次開發底層軟件處理各種硬件信號將硬件連通，然后在硬件功能基礎上設計開發軟件以實現相關功能；而軟件任務模塊之間的交互往往是事先約定數據格式和內容，然后進行調用或數據傳輸。這種模式下，首先軟件設計思路容易圍繞硬件，導致軟件對不同硬件的差異適應能力較差，其次軟件任務模塊與任務模塊之間的耦合性極高，難以對軟件功能進行拆分和重組。

本文描述的中型敏捷遙感衛星公用平臺(ZY2000 Remote Sensing Satellite Platform)開放式分層軟件架構明確了各個層次主體功能和對外接口，并最終建立了簡潔靈活的軟件架構，即開放式分層軟件架構。該軟件架構在更新換代、全面使用空間數據系統咨詢委員會(CCSDS)、歐洲航天標準合作組織(ECSS)等國際標準的基礎之上，在星地鏈路、星載鏈路、數據服務體系等方面構建了分層、開放的體系架構：其上行鏈路協議采用符合CCSDS遙控鏈路協議[4]，下行鏈路協議采用高級在軌系統(AOS)鏈路協議[5]，網絡層采用空間包協議[6]進行數據包轉發，應用支持層采用包應用標準(PUS)服務進行通用化設計。在這些通用協議的基礎之上，本文提出了基于軟總線的任務交互技術，使得任務與任務之間解耦合，方便軟件任務模塊拆分和重組；提出了硬件抽象和設備虛擬化技術屏蔽底層硬件和操作系統差異，從而實現該軟件架構在遙感和其他領域不同衛星硬件環境下移植。本文描述的開放式分層星載軟件架構已在測繪、對地觀測、海洋觀察和在軌維護等多個領域20多顆衛星應用，其中高分多模衛星(GFDM-1)等8顆衛星已經發射在軌，本文對其在軌驗證情況進行分析和總結。

1 傳統遙感衛星數管軟件體系結構

傳統遙感衛星中，數據系統軟件一般以進程的形式分為多個模塊。進程之間一般以消息通信和全局變量的方式進行交互，尤其是后者。每個功能模塊一般直接操作應用層、網絡層到底層硬件。以遙測功能為例[7-9]，如圖1所示。

圖1 傳統遙感衛星平臺軟件遙測模塊處理流程和結構Fig.1 TM module process and structure of satellite software based on traditional satellite

從第0個時間片到第5個時間片處理的業務可以看出，該體系結構是按照業務流程劃分，每個業務流程完成從底層1553B總線控制芯片獲取遙測數據，再到上層數據處理、鏈路層網絡層業務邏輯組包，再到底層遙測硬件操控輸出的全過程都在一個模塊(遙測模塊)中。由于每個衛星軟件、功能模塊的開發，其底層協議和硬件操作都各自不同，需重新開發，導致業務邏輯和硬件進行綁定，軟件架構難以適應不同衛星的硬件環境。

2 中型敏捷遙感衛星公用平臺開放式分層體系軟件架構

2.1 總體架構設計

為了將業務與邏輯結構、軟件與硬件解耦，提升邏輯代碼通用性和軟件架構跨硬件平臺適應性，本文提出了包含應用層、軟總線(星內路由)層、中間件與構件層、設備虛擬層和硬件層5個層次的開放式分層體系星載軟件架構，如圖2所示。

圖2 五層開放式分層星載軟件架構Fig.2 Five-layer open hierarchical on-board software architecture

在本文提出的架構中，應用層各進程間隔離，軟總線層、中間件與構件層實現跨衛星完整復用，通過設備虛擬層實現跨硬件移植。本章后續小節將分別對應用層、軟總線(星內路由)層、中間件與構件層的設計進行描述；硬件抽象與設備虛擬化層是本文提出實現軟件架構跨衛星硬件移植的關鍵技術，將單獨采用第3章對該層的設計和實現方法進行描述。

2.2 應用層設計

該層直接面向用戶需求，實現了與需求相關的各個功能。一般來說包括系統自檢、總線管理、電源管理、自主任務管理、載荷管理、指令管理、故障隔離與檢測等常規功能。為了實現這部分功能的通用化，該架構參考ECSS標準體系的包應用標準(PUS)，形成通用化的“新一代衛星軟件常規功能”，通過參數配置的方式以適應多個不同的遙感衛星需求。針對具體的遙感衛星，該軟件架構增加了姿態軌道計算、單性任務協同、快速軌道預報、星上自主健康等功能，用于支持衛星自身特殊空間任務，以及提升智能化和好用易用性。

應用層各個功能模塊以多進程的方式實現，各個進程之間不存在直接的調用關系，通過軟總線(星內路由)，以標準化數據接口驅動的方式實現各模塊之間的交互，以降低進程間的耦合，保持各個模塊的獨立性。

2.3 軟總線(星內路由)設計

軟總線(星內路由)主要負責將各進程、星內各終端的數據流轉，從而使得各進程之間通過標準的數據接口進行交互，而不像傳統衛星軟件架構一樣發生邏輯層調用關系，如圖3所示。軟總線對上層進程提供標準的數據接口，并且調用下層AOS鏈路協議、遙控鏈路協議、操作系統消息隊列和時間同步15553B協議相關程序進行數據分發和接收，從而使得上層應用程序與底層鏈路協議解耦，便于軟件移植。

圖3 路由/軟總線和其他進程拓撲結構Fig.3 Topology among Router/SoftBus and other Process

2.4 中間件與構件層設計

中間件與構件層封裝并復用大量邏輯操作。本層各個模塊必須嚴格保證是獨立存在的個體(具體來說就是能夠獨立編譯)，其向上提供應用接口并隱藏自身細節，以提供其他應用進程使用，其具體結構見文獻[10]。

本文所述的軟件架構設計了智能任務規劃算法庫構件群、指令序列調度構件群、緩存管理構件群、遙測數據池、基礎算法庫構件群、星內子網鏈路構件群等37類構件群，從而大力支持上層業務邏輯復用。

3 硬件抽象與設備虛擬化層設計和實現

為了屏蔽硬件的差異帶來上層軟件的差異擴散，需抽象出標準的硬件驅動對外接口，包括統一的操作接口和數據接口，這種位于硬件設備之上、數據鏈路層之下的接口稱為“軟”設備。軟件產品將建立在統一的設備驅動之上，并通過軟仿真技術對自動生成的軟件功能、性能進行仿真。

3.1 設備虛擬化層設計

3.1.1 “軟”設備的內部結構

對星載軟件常用的硬件接口進行抽象，提煉出每種接口通用的控制邏輯和數據緩存，形成每種接口的“軟”設備，其結構描述如下。

(1)控制邏輯。控制邏輯部分一方面完成“軟”設備對底層硬件的控制，并從底層硬件獲取硬件狀態信號，另一方面控制“軟”設備的存儲區地址訪問過程，并獲取存儲區的地址狀態。

(2)數據緩存。數據緩存在控制邏輯的控制下，存儲來自上層軟件的需要輸出的數據或來自底層硬件的需要輸入的數據，并返回數據緩存的狀態。

3.1.2 “軟”設備和上層軟件之間的數據傳輸關系

“軟”設備的設計也是基于構件化和層次化的綜合電子軟件體系思路的，每個“軟”設備為一個獨立的軟件單元，上層軟件需要訪問底層硬件時，調用相應“軟”設備的接口函數，完成數據在軟件和底層硬件接口之間的傳輸。“軟”設備和上層軟件之間的數據傳輸關系見圖4。

圖4 “軟”設備和上層軟件的數據傳輸關系Fig.4 Data transmission relationship between virtual device and upper software

3.1.3 “軟”設備和上層應用軟件的通信過程

1)數據輸出流程

(1)上層軟件完成航天器數據處理，生成滿足“軟”設備輸出要求的數據格式。

(2)上層軟件調用“軟”設備的狀態接口函數，判斷當前該“軟”設備是否為空閑，如果為空閑則進入下一步，如果為忙則繼續等待。

(3)上層軟件調用“軟”設備的傳輸接口函數，將航天器數據傳輸給“軟”設備。

(4)“軟”設備訪問底層硬件接口，將數據輸出。

2)數據輸入過程

分為兩種情況，第一種情況由上層軟件主動發起，按照預期的時序關系控制“軟”設備獲取需要的數據，第二種情況為上層軟件查詢“軟”設備是否接收數據，并根據查詢狀態從“軟”設備獲取數據。

(1)第一種情況的輸入流程：①上層軟件運行到數據接收時隙；②上層軟件調用“軟”設備的狀態接口函數，通知“軟”設備控制底層硬件采集數據；③上層軟件等待“軟”設備采集結束的時隙，調用“軟”設備的傳輸接口函數，從“軟”設備讀入數據。

(2)第二種情況的輸入流程：①上層軟件調用“軟”設備的狀態接口函數，查詢“軟”設備是否接收到數據；②如果“軟”設備狀態為接收到數據，則上層軟件從“軟”設備讀入數據。如果“軟”設備狀態為尚未接收到數據，則上層軟件繼續查詢；③底層硬件接收到數據(比如上行遙控數據)時通過中斷通知“軟”設備獲取數據。

3.2 硬件抽象與設備虛擬化實現

本文將實現跨衛星硬件平臺移植的關鍵技術——硬件抽象與設備虛擬化技術的一些關鍵點的設計與實現進行描述。

依據本項目的設計，硬件接口相關的處理函數都屬于硬件抽象與虛擬化層。硬件抽象與設備虛擬化層完成對硬件接口的二次封裝，從而保證當硬件設備發生變化時，上層不需要根據硬件設備的變更情況進行任何接口相關的修改。

3.2.1 存儲器設備虛擬實現

以高分二號衛星(GF-2)為例，大多數傳統遙感衛星使用的是帶電可擦寫可編程只讀存儲器(EEPROM)，以高分多模衛星為代表的新一代遙感衛星使用了閃存(FLASH)存儲器。為了將高分多模衛星的軟件移植到其他衛星，只需要修改硬件抽象與設備虛擬層的存儲器驅動程序，添加相應的FLASH操作接口即可。

1)定義并實現存儲器設備操作函數

FLASH操作除了讀寫方法不一樣，比EEPROM多了擦除操作。為保持一致，EEPROM的接口也要留一個空的擦除操作接口。

最終，FLASH和EEPROM的讀寫操作函數如表1所示。

表1 存儲設備虛擬化操作函數列表Table 1 Operate Function List of Storage device virtualization

2)配置虛擬設備接口函數

存儲器虛擬設備接口函數采用統一的讀寫擦做，即PromRead和PromWrite，通過參數配置和函數綁定的方式，使得PromRead和PromWrite調用表1中不同的操作函數，從而實現虛擬設備接口統一化，上層軟件進行存儲器訪問時調用下層設備，無需關注存儲器設備硬件細節，進而實現存儲器設備虛擬化。

3.2.2 總線傳輸設備虛擬實現

以GF-2、嫦娥五號(CE-5)和GFDM-1等衛星為例，以上3種硬件平臺都采用了1553B總線進行設備間的通信。為了提高總線通信效率，本軟件架構參考ECSS相關國際標準[11]，提出了基于時間同步的1553B總線通信技術和對應的協議[12]。對此，在本架構中在進行1553B處理跨硬件移植時，所進行的修改包括以下幾部分內容。

1)創建設備接口

首先補充定義了1553B總線的設備結構體bus_1553B_struct，其中包含的關鍵字段包括： 1553B總線的寄存器基地址、1553B總線的RAM基地址、1553B總線數據存儲相關信息、1553B總線各項操作對應的在軌維護函數指針。

其次在構件初始化接口函數中，完成對1553B總線設備結構體的創建與初始化操作，其中具體操作包括各項關鍵字段的定義，以及在軌維護函數指針的掛接操作。

2)配置設備接口函數

由于聲明了設備結構體，因此在定義新的修改設備接口函數時，需要通過設備結構體內的關鍵字段進行數據交換。接口的配置方法同存儲器硬件虛擬配置部分的內容，即通過函數指針完成對設備接口函數的掛接。

3.2.3 遙測/遙控硬件虛擬配置實現

與總線芯片虛擬配置的原理相同，在標準化星載軟件框架中，首先定義遙測或遙控模塊相對應的設備結構體。隨后，完成相應處理函數與面向應用層的接口函數的綁定工作。應用層通過聲明的設備結構體對象中的接口函數，即可完成遙測或遙控硬件的操作。

表2給出了遙測硬件虛擬配置中的關鍵參數和關鍵接口。

表2 遙測硬件虛擬化關鍵參數和關鍵接口Table 2 Key parameters and interfaces list of telemetry device virtualization

3.2.4 其他硬件設備虛擬化

衛星綜合處理單元除了以上硬件設備，還可能包括CPU、時間管理芯片、內總線、指令譯碼等硬件模塊，其設備虛擬化方法與上述硬件抽象與設備虛擬配置的原理相同，即首先定義模塊相對應的設備虛擬結構體，其次完成相應處理模塊的設計，最后完成面向應用層的通用化接口函數的設計，并與對應邏輯處理模塊綁定。由于篇幅原因，不再展開說明。

4 結束語

經過“十三五”期間多顆衛星的實踐，本文提出的開放式分層軟件架構已經在測繪、對地觀測、海洋觀察等遙感和在軌維護等多個領域得到應用和驗證。基本情況如下。

(1)本軟件架構在高分十一號01衛星、高分十一號02衛星、高分十三號衛星、高分十四號衛星、新技術驗證六號01衛星、新技術驗證六號02衛星、新技術驗證七號衛星、高分多模衛星等9顆衛星在軌飛行驗證，基于該軟件架構實現的數管和綜合電子分系統軟件運行良好，衛星各項任務個管理功能運行順暢，軟件架構在軌可靠性得到充分驗證確認。

(2)本軟件架構同時應用于多顆在研衛星，采用該架構之后，多個衛星之間采用通用化設計，衛星數據管理或綜合電子系統軟件復用率(邏輯函數或源文件級完整復用)由5%～10%[9]增長至70%～87%。

(3)本軟件架構提出了硬件抽象與設備虛擬化技術，將軟件與硬件解耦，從而使得僅需要修改與硬件的最底層接口，即可支持多個衛星甚至多種平臺，跨硬件移植代碼修改量由3000行以上縮小至200行以內，效率提升10～15倍。

總之，基于中型敏捷遙感衛星公用平臺開發的、與國際標準接軌的遙感衛星數據系統開放式分層體系架構所實現的星載軟件，自2018年7月以來已經過多顆在軌衛星的應用和驗證。它實現了不同衛星應用中任務與任務之間的解耦，業務與邏輯結構、軟件與硬件的解耦，提升了邏輯代碼通用性和軟件架構跨硬件平臺的適應性，從而為實現系統軟件在不同領域遙感衛星硬件環境下的移植奠定了基礎。