航天器軟件的研發路線*

呂良慶

(中國科學院國家空間科學中心 復雜航天系統電子信息技術重點實驗室， 北京 100190)

隨著航天器的種類、數量不斷增加，任務需求也不斷增多且更復雜化、精確化，新的、未知的有效載荷探測設備不斷加入，這些設備的工作特點各不相同，并且有可能需要維護、更換、變更任務目標和功能配置，完全依靠地面的管控將會是一項工作量巨大而又復雜的任務，其應對及時性、有效性、精確性都會受到影響。為此建設和提高航天器的智能自主能力是一條勢在必行的途徑。

支持自主能力的航天器架構和軟件系統必須具有控制靈活性和可擴展的特點，在研發過程中就必須加以考慮，并體現在實際運行過程中。

1 航天器軟件的研發路線

1.1 路線1：傳統研發路線

目前，國內航天軟件工程的主流研發路線是基于結構化設計和瀑布模型的，按照用戶需求，針對性地研發軟件及其部件。之所以可以這么做，主要是因為航天領域的應用需求具有長時間的穩定性，變化少，各方面質量要求高。它的優勢是現行軟件工程體系完全能夠支持，有其存在的基礎和必要性。但是隨著航天領域應用業務的不斷擴展，這一根基已經在動搖，存在著研發效率低下、不夠靈活、成本高和難以重用的問題，難以適應日益復雜、多變的用戶任務需求。因此這種路線是需要改造的對象。

1.2 路線2：與地面對等的研發路線

該路線主張航天器上的軟件可以使用與地面相同的研發方式，與地面需要的服務和功能有明確的業務對應關系，雙方采用對等的協議棧和架構。

以空間數據系統咨詢委員會(Consultative Committee for Space Data System,CCSDS)的任務操作和信息管理業務(Mission Operations and Information Management Services，MOIMS)領域[1-2]為代表的地面研發方式主要是縱向考慮問題的，即按照用戶需求，采用數據流分析方法逐層分解，形成相應的架構。這種思路方法也適用于星上軟件，可以與路線1結合運用。該方法簡單易懂，內容明確固定，但適應用戶需求變化的能力差，而且星上和地面系統的構成一定是不同的。

硬件方面：受到空間環境的制約，星地的數據處理能力(計算能力、存儲能力、網絡通信能力)有差距。雖然星上能力也在不斷提高，但是需求增長得更快，這種差距會長期存在。

軟件方面：地面軟件運行時由于可以有人的參與，因此對可靠性和適應未知的要求可以不高，但是在星上無人環境下，需要構建具有智能自主能力的應用層次，以代理地面的(部分)人類智能。

因此，星上軟件的架構一定存在與地面架構不同的需要考慮的問題和設計，其研發路線也有其特殊性。

1.3 路線3：模型化研發路線

這種路線期望通過標準化，橫向考慮應用支持問題，盡可能提煉公共的部分進行通用化設計，形成標準業務模型(函數庫、類庫)，而不是直接針對用戶需求本身。在有具體用戶需求時再進行搭積木式的系統構建。這種方式下，用戶需求的研發可以基于標準業務模型(如歐洲空間局(European Space Agency，ESA)的包應用標準[3](Package Utilization Standard，PUS))進行研發、積累和重用，而且特定的用戶業務模型也可以轉化為標準業務模型。

這種路線適合于長期的標準化模塊的研發和積累，但是用戶需求的滿足以及應用的多樣性、未知性仍然留給了具體任務自行解決。

1.4 路線4：數據化研發路線

在航天器上采用電子數據單(Electronic Data Sheet，EDS)技術，與地面的研發方式、提供的業務沒有明確的對應關系，只要能夠響應和滿足地面所需要的服務即可。

這種路線使用數據描述接口和功能，通過數據配置實現對已有系統的繼承、重用，并且其代碼自動生成的目標也為星上智能能力的研發、靈活的運控和應對未知問題提供了可能性。它將注意力放在了數據設計上，需要解決EDS的設計和工具鏈的建設問題，以支持EDS的編輯、傳遞、解析及系統內部的管理信息庫[4-5](Management Information Base, MIB)配置過程。但是，數據化設計需要基于已有的系統架構才能發揮作用、顯現出優勢，而且對數據的管理是一個需要深入探討的問題，并不比程序設計簡單和容易理解。程序設計變成了輔助性的，考慮的首要問題是通用性，而不是針對性滿足用戶需求，對研發者提出了更高的要求。

1.5 路線5：研發路線的綜合

上述4種路線不是簡單的選擇問題，而是相互融合的問題，即以路線1為基礎和出發點，承認其有效性，繼承其研發的已有對象和產品，進行重用性改造，形成標準業務，納入函數庫、類庫；采用路線2的數據流分析設計方法和協議棧，并基于路線1的標準業務，進行系統架構的建造和描述；采用路線3，如PUS的方式對標準業務進行歸一化設計，并允許標準業務的增加和積累；采用路線4的數據化設計思想，進行各種標準業務的解耦合設計，從而增強各種標準業務的通用性和可重用性，適應需求多樣化和未知的特點。這種綜合可以稱為路線5。

路線5的思路是：在歸一化的系統架構下，采用標準業務模型，設計用戶業務模型；業務模型以MIB作為內部數據結構，以EDS作為外部數據接口；對MIB和EDS的數據格式(語法)和內容(語義)進行模型化設計，以支持對業務模型的靈活配置和適應性改造；描述的方式語言化和標準化，采用可擴展標示語言[6](eXtensive Markup Language，XML)描述，按照CCSDS的遙測遙控交換(XML Telemetric and Command Exchange，XTCE)標準[7-9]和航天器接口業務(Spacecraft Onboard Interface Service，SOIS)的電子數據單[10-11](SOIS EDS，SEDS)標準，設計相應的編輯器、解析器工具，從而增強系統的自適應性和開發者、用戶使用的友好性，融入模型驅動的開發方式(Model-Driven Development，MDD)中。

下面按照這一思路，做一初步探討。

2 系統架構的構建思路

CCSDS的SOIS領域工作組提出了SOIS架構[12]，并針對架構中的各項業務制定了標準建議書。近年來，其研究重心逐漸轉移到EDS技術方面[13-14]，主張以SEDS描述設備訪問業務。

按照SOIS架構，系統構建需要自底向上逐層進行。最下層是設備級接入的亞網層[15]，解決各個子網內部即插即用協議設計和設備級EDS設計問題。按照SEDS標準，采用XML，形成SEDS模板，供工具鏈設計和接入方使用。在各子網之上構建匯聚層協議，設計歸一化的5項設備訪問業務[16-20]，向上層提供標準化的訪問接口，實現系統上層對設備和各子網訪問的透明性和接口標準化。而承上啟下的數據關系均通過SEDS進行描述，以實現業務的即插即用，創造通用的系統構建方法，以適應需求多樣、復雜和未知的特點，為以后的智能能力增長和在軌自動編程提供一致的數據基礎。

不同機構組織都有自己的體系架構，例如NASA的核心飛行軟件執行/核心飛行軟件或核心飛行軟件系統[21-23](core Flight software Executive/core Flight Software、core Flight software System，cFE/cFS)和歐空局的航天航空開放接口架構[24](Space AVionics Open Interface aRchitecture，SAVOIR)等。在已有架構的基礎上，按照SOIS架構思路，采用SEDS技術進行數據化描述，結合PUS進行歸一化、服務化改造，形成以功能為業務單元、MIB為單元核心、EDS為單元間的紐帶，可配置、可即插即用，基礎夯實，向上開放并可不斷擴展的體系架構。在架構的最上層，可以部屬不同專業領域的智能算法，以應對不同學科、不同類型的應用需求，而同時又可以繼承已有的歸一化架構。

在航天器上可以自主閉環管控的基礎上，還需要與地面構成閉環管控的關系，從而與傳統航天器運控體系相銜接。這種銜接設計有兩個要點：一是SEDS和XTCE標準均采用XML，具有互通性。XTCE主要描述遙測遙控數據，可以在地面形成通用遙控指令庫和遙測報告庫。SEDS適用于星上設備、業務和應用的描述，對XTCE描述的遙控遙測數據可以直接引用，從而構成星地一致的數據規范和實例積累。二是按照PUS標準業務模型和用戶業務模型進行剪裁、歸納，在星地兩端按照各自的研發方式設計實現，為星地和星上智能自主控制兩層閉環管控系統提供一致的模型規范。

3 即插即用概念的擴展

即插即用是指當一個設備接入系統時，由系統在運行過程中動態地進行檢測和配置的能力[25-26]。這一概念在航天器上可擴展為不僅是設備的即插即用，也包括了功能業務的即插即用，表現為可以提供的服務是即插即用的。

3.1 設備即插即用

航天工程中設備即插即用可以用于研發過程中的接口設計、協調和系統自動集成的工作。異構系統是由不同機構組織按照各自的思路設計的，在需要進行互聯互通時，異構系統及其軟件系統提供的功能業務往往是繼承使用，而不是重新設計。為實現異構系統之間的即插即用，采用EDS的形式傳遞相互的配置信息，傳遞的過程如圖1所示。

圖1 異構系統之間的EDS轉換過程[27]Fig.1 EDS conversion process between heterogeneous systems[27]

圖1中，設備方可以將自身的信息按照系統要求的實現一致性聲明[10](Implementation Conformance Statement, ICS)的規則，使用ICS編輯工具生成或手工填寫數據表單，再使用SEDS編輯工具或手工編輯一次性生成SEDS的XML文件，從而最大限度地降低了設備方使用EDS的難度和工作量，且不改變約定接口數據單(Interface Data Sheet，IDS)的工作習慣。系統方則按照SEDS標準解析接入方的XML文件，形成系統可識別的個性化EDS文件。通過這一轉換過程，互聯雙方可以表達自身的需求，了解對方提供的服務能力，達到需求自動匹配的效果，有利于接口標準化以及非標準化設備的繼承使用。

個性化EDS是系統對外的數據隔離，可以用以繼承系統內部已有的、未必規范的數據設計。這是因為系統內部不同業務的MIB和使用的EDS內容千差萬別，且都是針對性的，難以統一。在進行系統新增業務設計時，按照ICS、SEDS XML和個性化EDS的思路進行規范化設計，可以實現新增部分和繼承部分在EDS表達方式上的統一，方便系統業務的積累。

圖1的系統互聯互通有三種使用場景：一是單純的設備接入系統的場景，設備的SEDS XML文件表達的是自描述信息，可以被任何能識別這種信息的系統所接納。二是互聯雙方是對等系統，以SEDS XML文件為界，各自研發各自的工具。雙方各有自己的ICS編輯工具、SEDS編輯和解析工具。三是將這種EDS的編輯和解析能力配置在航天器上，就有可能實現兩個互不相識的航天器系統在軌飛行過程中的互相自動識別和配置。

3.2 業務即插即用

按照程序設計原理，一個業務主要由程序代碼和數據結構兩部分組成。要實現功能業務的即插即用，需要建立可識別EDS的業務模型，如圖2所示。

圖2 即插即用業務模型Fig.2 Service model with plug-and-play

圖2中，業務的內部數據結構可以統一在MIB的概念下，按照架構中的MIB和EDS組織規則[5]進行設計，因業務的功能模型不同而不同。其主要思路是MIB應有明確的格式，內容可配置；EDS格式應可動態修改和擴充，以允許同屬一個業務模型的不同業務實例的設計，適應不同系統的不同配置需要。業務程序部分除了常規的業務功能及其輸入、輸出外，為了解決業務可配置和自描述的問題，可基于MIB設計相應EDS轉換功能。如果輸入輸出的EDS與業務MIB中的EDS項的內容格式是匹配的，則可以省略這種轉換，與功能業務的輸入輸出相統一。

按照這一業務模型，以智能規劃業務為例，其業務模型設計如圖3所示。

圖3中，為支持任務規劃，需要構建規劃知識庫，內容包括規劃模型庫、規劃規則庫和指令庫。這3種庫可以通過個性化的EDS進行配置，如果存在知識表示的不一致，就需要進行配置信息轉換。同樣，如果提供本業務的知識庫描述EDS給其他業務，也存在這種轉換的需要。

圖3 智能規劃業務模型的設計Fig.3 Design of intelligent plan service model

在常規的業務功能設計上，規劃調度器可以采用現成的調度規劃算法(如基于分層任務網絡(Hierarchical Task Networks,HTN)算法的JSHOP2規劃器[28])進行設計改造。輸入的當前系統狀態和要達到的任務目標需要根據規劃調度器的需要進行轉換，轉換的依據是規劃模型，而轉換結果又可以作為新的規劃模型保存。規劃調度器按照規劃規則執行規劃算法，輸出結果需要根據系統已有的指令配置進行轉換，形成具體的可執行計劃輸出，從而與具體的系統執行機制相銜接，同時也可以包裝成更為高級的指令保存，作為后續更高級規劃的基礎，表現為自學習能力。

4 結論

路線5的研發路線不是單一路線的選擇和改進，而是貫徹模型化、數據化設計思想的綜合。它的首要目標不是直接滿足用戶需求，而是系統設計內容是否具有歸一化、標準化、可配置、可重用的特征?；谶@一認識所建立的星地閉環系統，其適應用戶需求的能力會得到增強，不僅表現在技術指標方面，還表現在研發效率和成本上。在設計上需要解決EDS標準的采用、內容格式設計，以及工具鏈的設計問題，是設備級、功能業務級乃至系統級即插即用能力建設的主要內容。在可持續方面需要走標準化道路，以支持這個方向的研究工作走向工程實用階段。