適用于行星巡視探測的集中式載荷控制方法*

王連國，朱 巖，馬 苗，饒家寧，梁耀明，王 蔚

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

圍繞行星科學領域進行太陽系內的地外天體探測活動，尤其是通過巡視器(rover)開展行星表面巡視探測，具有重大科學意義，國際上的主要航天組織規劃了一系列行星巡視探測計劃[1]。

行星巡視探測器與地球軌道探測器有許多不同之處。首先是資源約束極其苛刻，重量、體積、能源、數據量都有嚴格要求。其次是探測器與地面的通信機會有限且時間間隔較長，必須在長時間沒有監控的情況下運行和進行科學探測。因此，除了需要自主導航，還應對探測器的工作狀態進行自主監測，能夠在一定范圍內自主決定要進行的任務，并能對出現的一些故障進行在軌自主定位、診斷和修復或重構[2]。

對于有效載荷，一是要實現輕小型化，低功耗，提高有效數據比重，降低數據冗余；二是要具備一定的自主任務執行能力，減少對地面控制的依賴，高效地完成科學探測任務；三是要具有健康管理能力，對出現異常的設備，采取修復或隔離措施。

美國國家航空航天局(National Aeronautics and Space Administration, NASA)和歐洲航天局(European Space Agency, ESA)的深空探測研究起步早，技術先進，探測器可提供較多能源，具有高性能的計算能力[3-5]。在自主探測方面，進行了深入的研究和應用，具有自主任務規劃、智能目標選取、科學現象在軌發現能力[6-8]。

國內方面，受技術基礎和工程約束限制，探測器可提供的資源有限，故在“嫦娥三號”探測器中，采用一種與NASA及ESA的有效載荷控制方式不同的方案，首次實現載荷數管與多載荷電子學緊耦合輕小型一體化設計。“嫦娥五號”探測器的有效載荷也是采用這種電子學一體化設計。僅使用一臺載荷數管設備(載荷電控箱)完成有效載荷的管理，最大限度地實現了系統資源共享和信息綜合處理。存在的問題是：各電子學單元直接掛接到CPU的數據總線、地址總線、控制線上，這種方式在載荷電控箱集成前，各載荷單獨調試和試驗時，需要公用部分CPU的配合，需要的地檢資源多。同時由于所有有效載荷電子學共用CPU總線，也會產生相互影響和時序競爭。另外，在載荷運行控制方面，主要依靠地面上注立即指令和延時指令，自主能力較弱。

本文針對行星巡視探測需求和存在的問題，采取了新型有效載荷集中式控制方法。一是采用新型的載荷電子學和載荷數管集成一體化架構，將集成在機箱內的各電子學單元之間接口串行化，目的是在各電子學板功能集成的前提下，降低接口耦合度。二是采用立即指令、事件表和工作模式表等控制方式，可自主控制各載荷工作。三是采取基于預設規則的監控措施和故障影響最小化的隔離方法，能夠依據預設的規則監控載荷的工作狀態，自主對故障載荷采取恢復和隔離措施而不影響整個有效載荷系統自主探測過程。

本文的集中式控制方法在我國首次火星探測任務中進行了應用，用于對火星車有效載荷進行控制。本方法有以下優點：①實現了有效載荷功能和資源復用，既提高了系統功能密度，解決了系統重量、體積和功耗嚴重不足的問題，又優化了各電子學間的接口；②具備較強的自主控制載荷進行科學探測的能力，能夠適應深空探測通信延遲大、無實時測控的特點。

1 具體實現

1.1 集成一體化架構

通過對行星巡視探測任務進行需求分析，距離遙遠的探測任務，并不需要高性能的處理能力，但對重量、功耗、數據量等約束苛刻。故本文提出了中等處理性能、低功耗、低成本的載荷電子學和載荷數管一體化集成化方案，系統架構如圖1所示。公用部分，即載荷數管，是高度集成的計算機與數據處理單元、電源單元。計算機與數據處理單元的原理框圖見圖2，CPU采用AT697F，運行頻率64 MHz，現場可編程門陣列(Field Programmable Gate Array, FPGA)集成了1553B控制器、NAND FLASH存儲控制、科學數據處理、命令/狀態處理、OC指令發送、模擬量采集等功能。各載荷電子學完成各載荷探測儀器的控制，公用部分集中完成整個有效載荷系統的數據管理，包括轉發各載荷命令，組織各載荷遙測參數，采集各載荷的科學數據，對載荷數據進行壓縮、組包、存儲等。

圖1 新型集成一體化載荷數管體系結構Fig.1 Novel integrated architecture of payload OBDH

公用部分與載荷電子學之間的控制接口使用雙向RS422方式，數據接口使用單向RS422方式，都是點對點連接，采用標準通用異步收發傳輸器(Universal Asynchronous Receiver/Transmitter, UART)協議，控制接口比特率115 200 bit/s，數據接口比特率1 Mbit/s。通過分析目前和未來一些深空探測任務的需求，控制接口比特率115 200 bit/s可滿足需求，受對地通信限制，載荷產生的數據量不能太大，故載荷的數據率不高，1 Mbit/s可滿足載荷數據傳輸需求。

該體系結構有以下創新點：

1)內部控制接口和數據接口都使用點對點串口。該接口方式簡單，占用資源少，成本低，方便各電子學單元獨立調試和測試，容易進行故障檢測、隔離。

2)設計了適合深空探測應用的控制接口。該控制接口用于向載荷電子學發送串行數據指令，獲取載荷的工作狀態參數。采用RS422主從式半雙工接口方式，為減少接口信號數量，使用同一對差分線，分時進行發送和接收。采用主從式通信方式，公用部分為主機，各載荷電子學為從機，采用主動應答式的握手協議。為保證通信可靠性，制定了完備的通信協議，包括響應時間、超時時間、字節間距、重傳機制、錯誤狀態等。

針對深空探測對地通信能力弱和延遲大的特點，優化設計了數據指令，縮短指令長度，統一各載荷的指令格式，對指令應答碼和應答遙測數據格式也進行了統一，如圖3所示。地面注入時，載荷單條指令的有效部分僅為4 B，即載荷編號、命令類型、命令參數高低字節。其優點是：便于在軌自主按工作模式表執行指令，便于進行在軌健康管理；大大減少數據注入指令長度。

圖2 計算機與數據處理單元原理框圖Fig.2 Functional block diagram of computer and data process unit

圖3 控制接口數據格式Fig.3 Data format of control interface

1.2 載荷控制方式

1.2.1 軟件控制模型

本文借鑒了ESA的Rosetta探測器軟件[9]和NASA的火星探測漫游者(Mars Exploration Rover，MER)軟件[10]，在面向對象模型分析、分層次自主運行、正常運行任務與異常處理配合等方面的設計思想。軟件基于實時嵌入式操作系統VxWorks設計，NASA的MER和火星科學實驗室(Mars Science Laboratory，MSL)任務也都使用VxWorks操作系統。

軟件的主要任務是進行總線通信管理、載荷遙測遙控管理、載荷運行管理、載荷健康管理、數據采集及存儲管理等。設計的軟件控制模型見圖4，由五個模塊組成：數據注入模塊、決策模塊、執行模塊、在線監控模塊、報告模塊。

數據注入模塊負責解析地面應用系統上行的數據注入。數據注入分為三種，見圖5。第一種是沒有時間標簽的立即指令，軟件收到后立即執行；第二種是由帶有絕對時間標簽的指令組成的事件表，軟件根據各指令的時間標簽執行；第三種是由指令和等待時間組成的工作模式表，軟件執行指令，并等待相應的等待時間后再執行下一條指令。工作模式表由立即指令或事件表中的指令啟動。

決策模塊負責查詢事件表和立即指令表，判斷是否有事件需要執行，對于需要執行的事件交由執行模塊來處理，并刪除異常事件和已執行事件。對于立即指令，則立即執行。

執行模塊負責具體的事件執行任務，對于低級指令直接執行，對于高級指令則依據工作模式表拆分為多個低級指令來執行。

在線監控模塊負責監視各載荷的運行情況，當出現異常情況時采取一定的措施對載荷進行控制。

報告模塊負責匯總整理有效載荷系統的運行情況。

圖4 軟件控制模型Fig.4 Software control model

圖5 數據指令類型Fig.5 Data instruction type

1.2.2 基于事件表的控制方式

事件表由帶有絕對時間標簽的指令組成，每一條指令稱為一個事件。事件表用于使用絕對時間控制指令執行的情況。軟件的決策模塊對事件表中的所有事件判斷是否執行的依據為時間標簽。

定義Ts為系統當前時間，Te為事件指定的執行時間碼：若Te>Ts+2 s，表明時間未到達，不對該事件做任何操作，繼續保留在事件表中；若Ts-2 s≤Te≤Ts+2 s，表明到達事件的執行時間，交由執行模塊處理，并將其從事件表中刪除；若Te

傳統的做法是將事件表設計為一個無序的數組，即不按事件所指定的時間碼來排序，這樣經過多次添加刪除事件后，數組中已使用的元素位置并不連續。

記數組容量為N，添加一個事件的時間復雜度為O(N)，刪除一個事件的時間復雜度為O(1)。由于數組中的事件無序，決策算法需要依次對所有事件進行查詢判斷，查詢事件表的時間復雜度則為O(N)。

本文使用基于優先級隊列的堆排序(heap sort)，將事件表設計為最小堆的數據結構，最小堆是一棵完全二叉樹，特點為每個節點的值都小于它的子節點的值，因此根節點的值即為整個堆的最小值。由于嵌入式軟件內存資源有限，不適合動態分配空間，所以使用數組而非鏈表來實現最小堆結構。為了保持最小堆的特性，插入任一節點、刪除根節點的時候都要對堆的其他節點進行調整。對于有N個節點的最小堆來說，樹的高度為lgN，因此插入一個節點、刪除根節點的復雜度為O(lgN)，獲取最小節點(即根節點)的復雜度為O(1)。

決策算法只需獲取事件表中時間碼最小的事件(即根節點)，因此，查詢事件表的時間復雜度為O(1)。對事件表的刪除操作都是刪除距當前事件表中時間碼最近的事件，即最小堆的根節點，因此，刪除一個事件的時間復雜度為O(1)。

兩種數據結構的性能對比如表1所示。

表1 兩種數據結構性能比較

對本文設計的軟件，查詢最近事件的頻率遠遠高于插入新事件以及刪除最近事件的頻率，因此采用最小堆算法效率更高。

1.2.3 基于工作模式表的控制方式

對于深空探測，通信能力有限，如地球與火星的環回通信時間約8～42 min，每天只有幾次通信機會，地面規劃人員需規劃下一個火星日的工作計劃并上注，探測器自主按工作計劃運行，而無地面人員干預[5]。

本文的工作模式表即工作計劃，工作模式表中指令執行時刻是相對時間的，如果工作計劃不變，可重復調用之前的工作模式表。

1)工作模式表設計

軟件支持10個模式表(模式表0，模式表1，…，模式表9)，每個模式表的容量為128個指令。將模式表設置為兩種優先級，其中模式表0為高優先級，模式表1～9為低優先級，同一優先級的模式表可同時執行。

每個模式表中可以包含多個載荷的指令，也可以只包含單個載荷的指令。對于等待延時指令，其動作內容為3 B的等待時間，以100 ms為單位。

2)模式表控制過程

對模式表的控制作為一個單獨的任務，100 ms調度一次。圖6是模式表調度任務的控制流程，圖7是單個模式表的處理流程。

圖6 自主運行任務控制流程Fig.6 Flowchart of autonomous control task

圖7 工作模式表運行流程Fig.7 Flowchart of work modeTable

3)執行時間分析

模式表任務每次調度最多執行模式表中的一條動作，在不考慮模式表1～9運行過程中被模式表0打斷的情況下：

①若兩條指令之間沒有等待動作，則它們之間的時間間隔為100 ms；

②若兩條指令間有1條等待動作，則它們的時間間隔為該等待動作所指定的時間；

③若兩條指令間有連續N條等待動作，則它們之間的時間間隔為T1+T2+…+TN-0.1×(N-1) s，Ti為等待動作指定的時間；

④模式表存儲。模式表存儲在NAND FLASH中的載荷工作模式表存儲區，每個模式表單獨占用FLASH中的1塊數據空間(約為2 MB)，每個模式表存儲三份。FLASH存儲器采用多種保護措施，包括使用(12，8)漢明碼進行存儲器使用信息保護，使用RS(256，252)編譯碼對存儲數據進行保護[11]。

系統上電時，從FLASH中讀取模式表，放入SRAM模式表運行區。模式表在SRAM中也存儲三份，采取三取二冗余設計。

系統復位時，首先校驗SRAM模式表運行區是否有效，若無效，則從FLASH中讀取該模式表；若有效，則不必再從FLASH中讀取。

可通過數據注入指令修改在SRAM運行的模式表區內容。可以每個模式表單獨注入，也可以整個模式表一起修改，還可以修改模式表中的單個動作。需要將更新的模式表存儲時，則存儲到FLASH中。

1.3 健康管理

健康管理的原則為：①監測系統設備狀態，而不是事件狀態，恢復的是系統設備狀態。②監測點離故障點越近越好，即在軟件的最底層監測并執行動作。這也是NASA的火星科學實驗室(Mars Science Laboratory, MSL)探測器軟件采取的原則[12]。另外，對于所有監控，啟動一次異常處理之后，自動禁止監控。各項監控可通過注入指令使能、禁止。監控閾值可通過注入指令修改。采取的健康管理策略見表2。

表2(續)

2 實現結果及分析

本文提出的集成一體化架構，將載荷電子學和公用控制部分集成到一起，用高集成度、高性能的公用控制部分(載荷數管)實現載荷集中控制。各電路板為6U尺寸，公用部分的電源單元在一塊電路板上實現主備份冗余，計算機與數據處理單元有2塊板，組成主備份冗余。通過采取輕小型化措施，公用部分僅重3 kg，功耗6 W。

控制軟件基于VxWorks操作系統，軟件任務設計見表3。

表3 軟件任務設計

其中，1553B總線通信任務、RS422通信任務、自主運行任務和主任務是周期性調度任務。使用操作系統的getUserTime()函數(獲取當前系統時間碼，時間碼分辨率為1 ms)記錄各個任務每次調度的時間，得到各個任務的實際調度周期。圖8給出了周期性任務的設計調度周期和實際調度周期最小、最大值。從圖中可以看出，優先級高的1553B總線通信任務、RS422通信任務、自主運行任務，實際調度周期和設計調度周期相差很小。圖中的任務實際調度周期是軟件多次運行的統計結果，1553B總線通信任務調度23 670次，RS422通信任務調度47 349次，自主運行任務調度9469次，主任務調度47 314次。

各任務運行時間的測試方法是使用FPGA內的時間碼標簽寄存器，分辨率為20 μs。各任務執行時間如圖9所示，除數據壓縮任務外，其他有實時性要求的任務運行時間很短。FLASH管理任務與讀、寫、擦除動作相關，運行時間不一，此處未列出。

圖8 周期性任務設計和運行情況Fig.8 Periodic task design and running result

圖9 任務運行時間Fig.9 Running time of task

使用getUserTime()函數記錄事件表和工作模式表中各指令的執行時刻，得出各指令執行時刻的抖動情況。圖10為事件表中指令執行時刻抖動情況，該結果為由64條指令組成的事件表在不同負荷下運行結果，最大偏差小于40 ms，優于誤差2 s的指標要求。圖11為工作模式表中指令執行時刻抖動情況，該結果為9個模式表(模式表1～9)并行運行時的結果，最大偏差為3 ms，遠優于誤差2 s的指標要求。

圖10 事件表指令執行時刻抖動情況Fig.10 Jitter of eventTable instruction executing time

圖11 工作模式表指令執行時刻抖動情況Fig.11 Jitter of work modeTable instruction executing time

3 應用情況

我國首次火星探測任務已進入研制階段，火星車巡視探測科學任務著眼于火星局部地區，開展高精度科學探測。本文的集中式載荷控制方法在火星車有效載荷系統中進行了應用。將各載荷專用的電子學和公用的載荷數管集成到載荷控制器機箱中，由公用部分統一提供二次電源，統一進行各載荷的運行控制和數據獲取，統一提供與探測器平臺接口。

地面應用系統科學家將規劃好的下一火星日工作計劃(即載荷工作模式表)上傳至火星探測器平臺，平臺數管將載荷工作模式表轉發給載荷數管。當日探測時，載荷數管根據載荷工作模式表自主控制各載荷進行科學探測，并存儲科學數據。在探測工作結束后，將科學數據發送至平臺數管存儲，平臺數管在通信弧段將數據下行地面。

該集中式載荷控制方法經過了初樣階段有效載荷系統聯試和探測器整器測試，整個有效載荷系統運行良好，驗證了該方法的有效性。該方法具有簡捷、高效、可靠、功耗低、成本低的優點，適合行星巡視探測類任務對載荷進行管理。

4 結論

本文根據行星巡視探測任務對載荷輕小型化和自主探測能力的需求，提出一種集中式載荷控制方法。硬件平臺采用新型的載荷電子學與載荷數管集成一體化設計，在結構、功能集成的基礎上，盡可能降低接口的耦合度，以方便各單機調試和試驗。軟件采用基于事件表和工作模式表的控制方式自主控制載荷工作，可在一個工作模式表中規劃多個載荷的探測動作，也可在不同的模式表中分別規劃載荷的探測動作，多個模式表可同時運行，具有較高的靈活性。同時采取了一系列健康管理措施，能夠在長時間無人干預的情況下，保證載荷設備安全，并隔離故障載荷或恢復故障載荷的工作流程。該方法經過了實際工程驗證，可滿足實際工程任務需要，具有很好的工程借鑒意義。