呂良慶

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

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

支持自主能力的航天器架構(gòu)和軟件系統(tǒng)必須具有控制靈活性和可擴展的特點，在研發(fā)過程中就必須加以考慮，并體現(xiàn)在實際運行過程中。

1 航天器軟件的研發(fā)路線

1.1 路線1：傳統(tǒng)研發(fā)路線

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

1.2 路線2：與地面對等的研發(fā)路線

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

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

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

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

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

1.3 路線3：模型化研發(fā)路線

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

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

1.4 路線4：數(shù)據(jù)化研發(fā)路線

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

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

1.5 路線5：研發(fā)路線的綜合

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

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

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

2 系統(tǒng)架構(gòu)的構(gòu)建思路

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

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

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

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

3 即插即用概念的擴展

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

3.1 設備即插即用

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

圖1 異構(gòu)系統(tǒng)之間的EDS轉(zhuǎn)換過程[27]Fig.1 EDS conversion process between heterogeneous systems[27]

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

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

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

3.2 業(yè)務即插即用

按照程序設計原理，一個業(yè)務主要由程序代碼和數(shù)據(jù)結(jié)構(gòu)兩部分組成。要實現(xiàn)功能業(yè)務的即插即用，需要建立可識別EDS的業(yè)務模型，如圖2所示。

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

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

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

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

圖3 智能規(guī)劃業(yè)務模型的設計Fig.3 Design of intelligent plan service model

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

4 結(jié)論

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