衛星綜合軟件的體系結構研究

王 磊，袁 利

(北京控制工程研究所,北京 100190)

隨著衛星功能的復雜性不斷提高，衛星電子線路的集成度也越來越高，軟件也逐漸集中在一起運行，形成綜合軟件.不僅其功能復雜，而且規模變大，這對于軟件的開發和維護都提出了新的挑戰.目前國內的衛星軟件開發技術和軟件架構的局限性已經表現得非常明顯.

對于復雜的大型衛星綜合軟件，需要系統地宏觀結構設計，能夠長期準確地把握用戶需求和系統構成的實質和特點，并指導以后的設計和實施活動，包括對系統的性能進行預測和分析、設計和管理、測試和維護.與傳統設計方法中各種系統結構描述不同，體系結構在系統構成、內部關系和實現約束的描述方面更深入、更細致，而且包括系統設計的各個方面.因此，軟件體系結構是整個項目設計的第一步，對以后各種設計和實施具有指導、控制和管理作用.體系結構的設計成為關系到復雜系統設計成敗的關鍵步驟，其作用表現在軟件設計開發的規劃、需求分析、設計、實施、評估和維護等各個階段.

20世紀90年代以來，美國和歐洲新研制的衛星平臺大多數使用集成的電子系統和實時多任務的操作系統(以VxWorks和RTEMS兩大系統為主)，在規劃和需求分析階段建立軟件的體系結構，并為此后的設計提供指導.例如MER(mars explorer rover)[1]的應用軟件從下向上分為5個層次，包括硬件存取、硬件驅動、核心應用、載荷及任務應用以及行為層；德國的CubeSat小衛星平臺[2]的軟件從內向外分為3個層次，包括系統內核、應用和接口，另外還包括一個獨立的支持軟件庫；法國的Space bus 4000B通訊衛星平臺[3]的軟件從下向上分為3層，包括：操作系統、平臺服務和應用.星載軟件按照分層設計的還有Smart-1月球衛星[4]、CHAMP衛星[5]、PROBA衛星[6]、SAX衛星[7]、Spot衛星[8]等，涵蓋了從低軌到高軌，從小衛星到導航通訊衛星，從地球軌道到深空探測等各類衛星.

目前國際上在星載軟件體系結構方面的研究和應用比較多，方便了同一個衛星平臺的多顆衛星的軟件研制.然而，雖然層次型結構是星載軟件普遍適用的思想方法，但目前國際上星載軟件體系結構與衛星平臺的結合過于緊密，分層不能進一步清晰化，妨礙了衛星平臺之間在體系結構上的通用.

國內衛星一般采用分布式設計，主要的姿軌控分系統、數管分系統和有效載荷分系統的軟件均在各自的處理器上運行，以結構化設計方法和分時多任務設計為主，軟件體系結構的概念不夠清晰.但電子線路集成是國內今后衛星電子線路研制的發展趨勢，原屬于各個分系統的獨立軟件也將集成到單個計算機上運行，軟件的功能復雜度和規模均有大幅度的提升.

本文針對國際星載軟件體系結構在不同衛星平臺間通用性不強的特點，提出一種跨平臺的衛星綜合軟件的分層模塊化體系結構，在明確的系統應用層中體現不同衛星平臺的共性和差異，適用于國內今后采用綜合電子系統的各類衛星平臺.對該體系結構的組成、功能和層次結構進行了詳細描述，對該體系結構在軟件復用、設計與測試等方面帶來的優勢進行了深入分析.

1 綜合軟件的分層模塊化體系結構

從軟件研究和設計的發展歷史看，層次型結構一直都是軟件分析和實際實施的基本、普遍適用的思想方法.盡管每個衛星軟件的功能千差萬別，但都是可以建立在描述層次上的，層次性是軟件體系結構的不變性，是軟件構成的共同規律，也是嵌入式實時系統普遍采用的結構模型.本文所描述的分層模塊化體系結構如圖1所示.

圖1 綜合軟件的體系結構

分層體系結構自下往上包括3個大的層次，分別為系統軟件層、系統應用層和用戶應用層，每個層次又可以根據功能細分為幾個不同的層.其中系統軟件層和用戶應用層的配置是國際上星載軟件體系結構的一般性認識，本文所述體系結構的重點集中在系統應用層.

1.1 系統軟件層

系統軟件層包括硬件描述層、操作系統層和端口驅動層.

硬件描述層是對計算機以及外圍器件的描述，通常用一組描述文件來定義，這組文件稱為BSP(board support package).不同的衛星平臺，雖然其計算機系統硬件的不同，但可根據不同的CPU體系在模塊組成上具有統一的形式.操作系統層包含兩個部分，一部分是用于啟動和加載的引導程序，另外一部分是嵌入式實時多任務操作系統.引導程序用于加載軟件和處理加載過程中出現的問題.嵌入式實時多任務操作系統具有一個多任務的內核，內核調度的基本單位是任務，允許將實時應用構造成一套獨立的任務集合，每個任務擁有各自的執行線程和自己的系統資源集合，來完成不同的功能.實時多任務操作系統是按照事件實施調度，不同于分時操作系統的按照時間進行調度的策略.國外90年代以來衛星平臺上使用的實時多任務操作系統有VxWorks、RTEMS等，國內也有多個單位在研發適合于我國衛星使用的實時多任務操作系統.

端口驅動層在端口配置文件支持下，提供一組針對不同的端口可在實時多任務操作系統下運行的驅動程序，包括查詢模式和中斷模式兩種操作方法.端口驅動層構成了對硬件的完全封裝，應用軟件可以不再考慮硬件問題.

1.2 系統應用層

1.2.1 輸入輸出層

輸入輸出層是應用軟件和硬件系統的接口層，該層調用端口驅動層的驅動程序，完成應用軟件對外部設備的數據輸入和輸出，所包含的模塊對應于系統所包含的接口(如RS422、CAN、LVDS、1394、1553B等).在實時多任務操作系統的環境下，輸入輸出層的每個模塊用于對指定端口的管理，由于存在多個任務可能向同一端口(總線端口或片選端口)發出(和接收)數據的可能，因此，輸入輸出層的管理就是為了保證在實時前提下有序地發送數據和接收數據.

通常采用消息隊列或管道方式.例如多個應用層任務需要向同一端口發送數據時，可以按照各自的優先級在獲取可發送信號量的前提下向一個發送隊列傳遞消息，輸入輸出層的對應模塊從隊列中取得消息，然后發送.當某一個接口進入數據時，輸入輸出層的對應模塊將讀入的數據按照包格式發往一個接收消息隊列，數據應用層的模塊負責從消息隊列接收數據包，進行解包.

不同的衛星平臺，其接口有所不同，在輸入輸出層按照接口進行模塊化設計，便于裁剪，可以完成不同衛星平臺硬件接口的完全封裝.

1.2.2 數據應用層

數據應用層是應用任務和輸入輸出層之間的翻譯層，用于實現所有外接設備的數據通訊協議.即應用任務需發出的數據經過數據應用層的對應模塊根據通訊協議打包后發往輸入輸出層，同樣的，輸入輸出層接收到的外接設備的數據包，由數據應用層根據通訊協議解包后經數據交換提供給應用任務.

向掛接在同一總線上的外部設備發送指令或數據時，只要向對應接口的消息隊列發送消息數據包即可，對于實時性要求高的外部設備，可將消息數據包的優先級提高.

數據應用層的模塊按照外接設備定義，一個外接設備對應于一個模塊.例如可以包括如下模塊：數字太陽敏感器、紅外地球敏感器、星敏感器、相機、動量輪線路盒、帆板驅動線路、有效載荷線路盒等.這些模塊可以隨著不同衛星平臺的設備配置增加或刪除.每一個模塊根據與對應設備的通訊協議編寫.而產品化的敏感器和執行機構的數據應用層模塊可以在多個型號中通用.

1.2.3 數據交換層

數據交換層完成應用模塊的任務之間的數據交換以及應用模塊的任務和數據應用層之間的數據交換.分為4個模塊，如表1所示.

表1 數據交換模塊

數據交換層是信號量、隊列和全局變量之間對應關系的集合，這些關系表達了任務之間的數據耦合和時序耦合.不同衛星平臺，當功能有差異時，實現功能的任務集合也會增加或減少，對任務的解耦以及聚合均在數據交換層體現.

數據交換層的4個模塊涵蓋了多任務之間的數據交換方式，在針對具體衛星型號時，可根據實際需要進行裁剪.

1.2.4 核心調度層

核心調度層可以包括4個模塊：遙控處理模塊、故障診斷隔離和恢復模塊、在軌任務管理模塊和系統管理模塊.其中遙控模塊用于處理地面遙控指令，對接收到的遙控指令進行驗證、解釋并發起對應的任務執行或傳遞指定的參數到其他任務.故障診斷隔離和恢復模塊用于執行用戶定義的故障診斷、隔離和恢復功能，這個模塊是由用戶自定義，在系統級處理故障問題，將原分散于各個模塊的故障診斷功能集中到一起，包括健康管理.在軌任務管理模塊用于處理地面的任務級指令、程控指令、自主操作等工作.系統管理模塊用于處理衛星自身硬件和軟件的維持、維護、監控、通道的管理、時序的安排等工作，也包括應急處理和安全監控.

核心調度層是保障接收地面指令、維護系統安全、提供應用管理的模塊集成，是應用軟件的核心，由該層來表征應用軟件自身的健康狀態，可用于發送針對容錯線路的清狗指令.

核心調度層是不同衛星平臺差異最大的部分，根據特定衛星平臺的設計要求，核心調度層可以增加或刪除以上模塊中的子模塊，并且每個模塊的內容在不同平臺下也很可能不一樣.將不同衛星平臺的差異限制在核心調度層內，有利于提高軟件體系結構的穩定性.

1.3 用戶應用層

用戶應用層包含幾個大的模塊，有平臺應用模塊、AOCS模塊、溫度控制模塊、有效載荷管理模塊和存儲管理模塊，這些模塊可以根據不同衛星平臺的分系統的配置情況進行設置.

一般地，平臺應用模塊包括：遙測模塊、采樣模塊、時間管理模塊等；AOCS模塊主要包括姿控和軌控的算法；溫度控制模塊主要用于星上自主溫控的控制律實現和工作模式管理；有效載荷模塊針對不同衛星型號的載荷不同，其功能也不同，原則上都是對有效載荷的工作實施調度；存儲管理模塊專門針對星上大容量存儲器的數據進行管理，復雜一些的設計可以采用可靠文件系統.

2 分層模塊化體系結構下的設計與測試

2.1 模塊設計

分層模塊化的體系結構通過分層來明確衛星綜合軟件的組成結構，通過模塊化來覆蓋軟件的功能.每一個模塊均采用封裝的方式，定義其輸入輸出接口，模塊之間的數據交換全部在數據交換層實現，模塊的調用由核心調度層完成，核心調度層不僅能夠調用模塊，還可刪除模塊，以保證整體軟件安全.

每一個模塊可以采用結構化的設計方法或基于對象的分析設計方法實現，只要符合輸入輸出接口的規定即可.在實時多任務環境下，一般地，每個模塊用一個主任務和幾個從任務實現，從任務可選.而任務的優先級則作為調用時的模塊輸入參數指定，這樣可以不破壞軟件整體時序結構.

每一個模塊由于采用封裝方式，因此不會干預其他模塊的運行，而數據交換僅通過專門的數據交換層進行，保證不會出現數據的交叉覆蓋，所交換數據的可靠性由模塊自行判斷，每個模塊的運行情況通過一個全局的錯誤變量向核心調度層反饋.

2.2 實時多任務設計

包含多個功能模塊的體系結構，是把這些模塊按照一定的規則組織起來，既適應于不同型號之間的差異，也能適應同一個型號用戶需求的不斷修改，讓軟件明晰化，方便分工和過程管理.

基于實時多任務的軟件體系結構包括如下幾個方面：任務的劃分；優先級結構；發起和退出規則；任務之間的同步與互斥關系；任務之間的數據通信機制；任務與中斷的相互關系.

任務的劃分則需遵守H.Gama原則，包括：

(1)I/O原則：對于單獨的接口，應該使用單獨的任務處理，不同的接口使用不同的任務；

(2)優先級原則：對于突發性事件，應劃分為不同優先級的不同任務；

(3)同優先級原則：對于功能類似，而接口不同的功能，應劃分為優先級相同的任務；

(4)大量運算：服務于大量運算的功能部分，其優先級應安排的低一些；

(5)功能耦合：將關系密切的若干功能組合起來，歸為一個任務；

(6)偶然耦合：歸為一個任務；

(7)頻率組合：對于經常重復發生的事件，發生頻率不同的事件劃分為不同的任務.

進行任務劃分時，除了遵循以上原則以外，還需考慮所實現功能間的異步關系.如果在具體分析一個功能時發生原則沖突，則要為每一個原則針對具體的功能設定“權重”，必要時可以通過計算“權重”來最終確定如何劃分任務.

任務劃分可以歸為3類：

(1)周期任務：是指有固定周期要求，每個周期必須完成一次的任務；

(2)事件任務：是指等待某一事件的發生而采取行動的任務，一般地，事件是以消息的方式產生；

(3)異步任務：是非周期性任務，根據命令執行和用于處理內部事務的任務.

2.3 軟件復用

軟件復用按不同階段軟件產品抽象程度的高低，可分為代碼的復用、分析的復用、設計的復用和測試信息的復用等類型.在國內衛星軟件開發過程中，這幾種類型的復用都涉及到了，但復用水平并不高，其中一個主要原因是幾乎沒有可復用的體系結構，復用主要針對某個具體的函數或某段相同功能的源代碼進行，使得衛星軟件復用的層次不高，范圍較窄.

分層模塊化體系結構可以解決體系結構層面和構件層面的復用問題.一個新的衛星軟件，可以直接引用本文所描述的軟件體系結構及其代碼框架，衛星硬件的不同可以在硬件描述層通過修改BSP文件來解決；接口的不同可以通過在端口驅動層增刪驅動程序來解決；外接設備的不同，可以在數據應用層根據通訊協議增刪新的產品模塊，而用戶應用層可根據不同分系統的具體軟件需求進行模塊增刪或模塊改進.總之，需求變化引起的軟件改動僅影響模塊的增加或刪除，并且限制在一個層內，而不影響其他層.由此可以實現體系結構的復用.

體系結構內的模塊由于采用封裝方法，因此，如果兩顆衛星所采用的產品是相同的，則軟件體系結構中對應的模塊是可以直接復用的，前提是在體系結構已經復用的基礎上.在硬件產品化的基礎上，就可以實現對應軟件模塊的產品化.例如：針對不同CPU體系的BSP可以模塊化復用；針對不同端口的驅動可以模塊化復用，針對指定敏感器或執行機構的數據應用層模塊可以復用，AOCS模塊里可以通過規范化算法進行復用等等.于是，產品化的軟件模塊即構成了可復用的構件.

因此，在具有可復用的體系結構的前提下，構件(模塊)的復用可以大幅度提高軟件生產效率.

2.4 軟件測試

在以體系結構為指導的軟件設計思想下，軟件的測試將與以往大不相同.測試的工作提前到設計階段，即在設計階段考慮測試問題，形成可測試設計，可以在測試階段提高測試效率.

采用跨平臺的星載綜合軟件體系結構，設計工作大致可以分為兩類，一類是可復用的分層模塊化體系結構和模塊的設計，一類是針對指定衛星的特殊模塊設計以及組裝.

前者首先根據不同的衛星平臺建立該平臺的分層模塊化體系結構，包括相關文檔和標準代碼架構，設計工具軟件用于自動生成該平臺的軟件系統的體系結構源代碼，這樣的體系結構系列是有限的，可在平臺的系列衛星上重復使用.其次在平臺內部整理端口和部件產品，對每一個端口和產品化的部件開發其在該體系結構下的對應標準模塊，將每一個模塊形成構件代碼，建立構件庫.在大部分時候，模塊是可以跨平臺形成構件庫的，前提是不同平臺的體系結構是復用的，而且操作系統是相同的.

后者是針對指定的單個衛星的軟件開發，首先生成所屬平臺的體系結構代碼，其次根據其端口和部件產品的配置選擇模塊構件，對于該衛星特有的模塊專門開發實現，最后組裝在一起，這樣可以避免大量的重復開發，大大提高效率.

在這樣的開發過程中，對于單個衛星的軟件測試相應的減少了很多工作.例如，可以取消體系結構代碼的測試和復用模塊的測試，僅對專有模塊進行單元測試以及對整個軟件進行回歸測試即可.這樣，可以節省軟件生產者的大量工作，可以快速地完成軟件，參與系統測試.

3 結 論

隨著衛星軟件集成度和復雜性的快速提高，軟件規模的不斷變大，軟件體系結構設計變得越來越重要，獨立的軟件體系結構設計階段是必不可少的，理論和實踐都證明，良好的、易于維護的體系結構設計，對于降低設計風險、提高軟件質量、保證開發速度都是至關重要的.本文提出的衛星綜合軟件的分層模塊化體系結構，在軟件的設計、測試和復用等方面都表現出優勢.