李 劍,鄒雪梅,王 成
(北京航天飛行控制中心,北京 100094)
空間站作為壽命大多長達10余年的在軌航天器,其運營管理任務的順利實施需要在其全壽命周期內進行不間斷的任務規劃[1]。空間站運行控制任務規劃是指針對空間站某一任務周期內的飛行任務(空間站平臺操作、有效載荷試驗和航天員駐留等),根據飛控任務需求,通過一定的規劃手段,獲得空間站在軌運行的飛控計劃和操作指令序列。
自上世紀80年代起,美國就展開了空間站運營任務規劃概念模型的相關研究,并經過一系列的工程論證,初步形成了任務規劃概念體系框架[2-3],包括載人航天任務的分布式規劃概念[4]、基于空間站運營任務規劃基準規劃周期的分層規劃概念[5]及各層規劃的具體規劃內容及執行流程[6]等。
經過40余年的空間站建造發展[7],美、俄等國已掌握了相對成熟的空間站任務規劃技術,研制出功能較為完善的任務規劃系統[8-9],并經過長期實際在軌運營的應用檢驗,其工程實用性和可靠性都已達到領先水平,為空間站運營管理提供了強大的技術支撐。
國際空間站運行控制任務規劃由分布在全球的各合作國規劃機構共同協作開展,其運行控制任務規劃流程如圖1所示[5],主要體現了“分層規劃、分布式協同、集中式管理”的思想。

圖1 國際空間站任務規劃流程[5]Fig.1 The mission planning process of International Space Station[5]
我國經過神舟飛船系列任務以及空間實驗室任務,已經掌握了載人航天短周期集中式任務規劃技術,并形成了基于“計劃工作模式”的任務規劃方法[11]。根據我國載人航天工程戰略布局,將于2020至2022年完成空間站建造任務[10],之后進入空間站運營管理階段。在空間站運營管理階段,將會面臨航天員長期在軌駐留、多航天器協同飛控、多領域載荷統籌規劃、飛控需求快速迭代以及在軌資源優化配置等新需求,目前亟需研究面向未來空間站任務的運行控制任務規劃體系,并在統一體系架構指導下推進相關系統建設。
從我國空間站任務特點出發,其運行控制任務規劃需求應主要包括以下6個方面:
1)在軌航天器多、協同控制復雜,存在多種組合體飛行模式,需要對在軌航天器實施多目標整體規劃。
2)地面參試系統和專業領域多,需要運控中心與各支持中心開展高效協同規劃,并建立多邊協調機制,完善分布式協同技術手段。
3)飛控資源有限、飛控需求多樣,需要優化配置資源、合理安排約束,在滿足飛控需求的基礎上,充分發揮空間站應用效率。
4)天地往返和貨物補給常態化后,任務準備周期縮短、規劃任務繁重,需要提高任務規劃準備和驗證效率。
5)針對空間站應急響應需求及各類測控網和平臺故障等突發情況,提高快速實施應急處置的能力,需要快速重規劃,保障空間站安全穩定運行。
6)空間站在軌試驗任務的控制需求多樣、方式靈活,需要拓展傳統計劃遙控方式,探索基于閉環實時控制的遙控作業,發展基于遠程授權控制的載荷遙操作技術。
借鑒國際空間站成功的運營管理經驗,我國空間站運營管理可初步劃分為四個層次:戰略規劃、中期規劃、任務規劃和實施規劃,其中空間站運行控制任務規劃屬于實施層規劃,為了滿足上述空間站運行控制任務規劃需求,其體系架構及其系統建設可設定為以下6項目標:
1)滿足空間站四層規劃體系中實施層規劃的任務要求;
2)滿足空間站任務的飛控組織指揮和操控模式要求;
3)滿足空間站任務長壽命周期內的多樣性、擴展性任務需求;
4)提高任務規劃效率和自動化水平,降低人工成本;
5)提高任務規劃的正確性和可靠性,降低風險成本;
6)提高任務規劃的靈活性和兼容性,降低維護成本。
空間站運行控制任務規劃體系如圖2所示,包括:分布式任務規劃工作模式、分布式任務規劃接口規范、運行控制信息管理平臺以及分布式任務規劃系統(1+N)等4個部分。

圖2 空間站運行控制任務規劃體系結構Fig.2 The mission planning architecture for operation control of the CSS
1)分布式任務規劃工作模式(圖2中①):明確了運控中心和各支持中心(分布式專項規劃系統)在運行控制任務規劃中的職責分工和工作流程。
2)分布式任務規劃接口規范(圖2中②):明確了任務規劃過程中各參與單位數據交互的標準規程、數據類型、接口定義和交互關系。
3)運行控制信息管理平臺(圖2中③):該平臺提供基于Web服務和實時數據分發服務的信息化網絡環境。
4)分布式任務規劃系統(圖2中④):該系統由空間站運控中心的“分布式協同任務規劃系統”和各支持中心的“專項規劃系統”共同組成。
上述工作模式與接口規范是頂層的指導性文件,信息管理系統和分布式任務規劃系統是需落地的建設項目。
空間站運行控制任務規劃需要對有限飛控資源進行優化配置,對各類飛控事件進行統籌安排,最終獲得滿足飛控任務需求的飛控計劃安排。空間站運行控制任務規劃業務流程上承任務層規劃,下接飛控實施,需要在工作計劃、規劃粒度、迭代周期上做好上下游業務銜接。
任務層規劃由空間站運營規劃與管理中心組織編制,對單次載人飛行任務周期內的在軌事件進行編排,以月為單位明確主要在軌操作,從任務前18個月開始制訂,前12個月發布基線方案,并根據需求更新,發射前6個月明確任務狀態。
運控中心結合上述任務層規劃的迭代周期以及飛控任務特點,將一個任務周期的規劃過程劃分為三個階段:規劃建模階段、射前規劃階段和實施規劃階段,如圖3所示。射前規劃階段和實施規劃階段基于“分層規劃”思想,包括事件層規劃和操作層規劃。
1)事件層規劃
事件層規劃將飛控事件作為整體,統籌協調各領域飛控需求與可用資源和環境約束之間的關系,以及各飛控事件之間的資源競爭關系,明確各飛控事件的資源配置和日程安排。事件層規劃需要對有限資源進行優化配置,對沖突事件進行優化排解,是任務規劃的關鍵環節。
2)操作層規劃
操作層規劃將飛控事件模型中的具體飛行程序和操作邏輯進行展開,在指令和操作層面進行優化編排和沖突消解。操作層規劃結果面向飛控實施的最終可執行文件,包括指令計劃、注入安排、遙控作業、在軌操作程序以及協同工作程序等。

圖3 空間站任務層和實施層規劃周期示意圖Fig.3 The planning period for pre-increment planning and increment execution planning of the CSS
規劃建模工作一般在一個任務周期開始前1年啟動(此時任務層規劃第一版基線方案已經發布,各項在軌試驗安排已經初步明確),任務開始前6個月結束(此時任務層規劃最終任務方案已經發布),為期半年。空間站運控任務的規劃模型主要包括飛控基礎模型和飛控事件模型。
3.2.1 飛控基礎模型
飛控基礎模型用于描述各類飛控資源和約束條件的數學和物理特性,包括航天器能源模型、測控資源模型、鏈路帶寬模型、航天員人時資源模型、平臺設備負載能力模型以及軌道約束條件模型等。飛控基礎模型一般是空間站系統、航天員系統以及測控通信系統的內在固有特性(客觀能力),具有一定的穩定性,一般在規劃系統的建設階段完成相關建模工作。
3.2.2 飛控事件模型
飛控事件是空間站運行控制的基本任務單元,是飛行控制任務過程中為了達到一定的飛行試驗目的而采取的一個在時間上連續、在過程上完整、在功能上獨立的一系列操作或活動,飛控事件模型即是對一段相對獨立飛控過程的邏輯封裝。
飛控事件模型具有樹形數據結構,如圖4所示。一個飛控事件由多個動作和子事件組成,動作是針對某類資源占用或狀態約束的封裝,其內部具有統一的資源占用和約束依賴性。動作與動作之間,具有一定邏輯關系和時序關系,同時也具有較大的優化調整空間。動作則由一系列指令和操作組成,一般具有固定的時序邏輯,具有很小的優化調整空間。因此,事件層的規劃粒度是“動作”,操作層的規劃粒度是“指令/操作”。

圖4 飛控事件概念模型Fig.4 The conceptual model of flight control events
一般情況下,一類飛控事件只對應一個飛控事件模型,模型需要對飛控事件內部穩定部分進行封裝,對外部變化部分開放接口。在任務規劃的“飛控需求申請”中,各支持中心只是通過數據接口明確相關模型的參數設置,從而將某一飛控事件模型實例化。
3.2.3 規劃模型會簽確認
完成上述飛控基礎模型和飛控事件模型建立后,運控中心與各支持中心需對各類模型進行測試、評審、會簽和最終確認,確保模型的正確性和權威性。

圖7 空間站日常運營管理期間任務規劃時間安排Fig.7 The time arrangement for mission planning during the space station daily operation management
射前規劃階段一般在任務開始前6個月啟動,在任務層規劃結果(已經明確了所有飛控事件的月計劃安排)的指導下開展,在任務開始前完成規劃,其工作流程如圖5所示。

圖5 射前預規劃階段工作流程示意圖 Fig.5 The workflow of the pre-launch planning
在空間站日常運營管理期間,運行控制任務規劃采用短周期迭代更新的方式實施。為了匹配測控資源申請周期,該階段規劃周期設定為一周;考慮規劃準備期間的系統間迭代交互工作,需提前3周啟動規劃工作,其工作流程如圖6所示。一次典型的空間站日常運營管理期間任務規劃時間安排如圖7所示。

圖6 實施規劃階段工作流程示意圖Fig.6 The workflow of increment execution planning
空間站分布式任務規劃接口規范主要包括數據傳輸規程、接口形式定義和數據交互三個方面。
1)數據傳輸規程
數據傳輸規程描述了數據傳輸的協議約定,在鏈路層采用以太網協議,在網絡層采用IP協議,在傳輸層采用TCP和UDP協議。對于應用層,需要基于傳輸數據類型選擇不同的數據交互協議,Web業務數據采用HTTP協議,實時業務數據采用PDXP協議(包數據交換協議),非實時業務數據采用FEP協議(文件交換協議)。
2)接口形式定義
系統接口形式包括三種類型:一是模型接口,該接口既是系統軟件集成接口,也是模型設計的人機接口,采用結構化的專用模型描述語言作為接口規范;二是算法封裝接口,該接口僅是系統軟件集成接口,采用軟件組件技術作為接口規范;三是數據交互接口,該接口是數據的結構化定義,采用XML作為接口描述標準。
3)數據交互關系
系統數據交換關系包括三個方向:一是分布式任務規劃系統之間的數據交互;二是任務規劃系統與飛控實戰系統的數據交互;三是任務規劃系統與運營管理任務層規劃系統的數據交互。
空間站運控任務信息管理平臺是分布式任務規劃系統互聯互通的基礎,用于承載業務流程流轉、任務數據傳遞和狀態確認管理,并應具備開放擴展能力,能夠兼容基于標準接口接入的國際合作機構的規劃子系統。信息管理平臺的系統構成設計為兩個部分:
1)基于C/S架構的傳統試驗任務數據實時分發系統,確保各系統之間業務數據流轉的可靠性和實時性。
2)基于B/S架構的Web系統,為業務數據管理、狀態確認、審批放行等有人參與環節提供便捷管理手段。
基于“分布規劃、集中管理”的思路,運控中心的分布式協同任務規劃系統設定為主要負責飛控需求集成和最終規劃發布工作,分布式部署在各支持中心的專項規劃系統主要負責各自業務領域的任務規劃工作。
運控中心分布式協同任務規劃系統包括部署于運控中心的本地終端(圖2中,統一任務規劃系統),以及分布部署于各支持中心的遠程終端。各終端通過信息管理平臺進行數據同步,實現實時在線協同規劃設計。為了提高任務規劃系統的靈活性和可擴展性,運控中心統一任務規劃系統劃分為4個功能層,如圖8所示。

圖8 空間站運行控制分布式協同任務規劃系統結構Fig.8 Architecture of distributed collaborative mission planning for the space station operation control
1)模型層
包括3個規劃模型庫:針對飛控資源和狀態約束進行建模的通用基礎模型庫,針對具有實時重規劃需求的關鍵平臺控制事件的基礎模型庫,針對各支持中心提交的飛控事件需求建立的模型庫。三種模型庫均基于標準接口設計,具備可擴展性,能夠集成第三方規劃模型。
2)算法層
包括6個算法功能模塊,分別解決某一方面的規劃求解問題。
3)驗證層
包括5個檢查驗證模塊,對外部輸入數據、算法層產品進行合法性、正確性驗證,并提供的日志信息和調整建議。
4)交互層
包括5個人機交互模塊,同時實現本地與遠程終端的數據同步。
空間站任務各支持中心需要根據各自專業領域建設各自的專項任務規劃系統,并基于標準接口規范和信息管理平臺與運控中心任務規劃系統實現數據交互和協同規劃。
主要業務領域的專項任務規劃系統設定如下:
1)軌道控制專項規劃系統:主要完成空間站軌道控制策略的規劃計算,并將軌道控制策略封裝成統一的飛控需求和約束模型。
2)空間站平臺專項規劃系統:主要完成空間站平臺各分系統的在軌管理和控制的任務規劃,如平臺巡檢、熱控管理、環控管理、GNC狀態維護以及在軌維修等任務。
3)航天員專項規劃系統:主要完成航天員相關的事務規劃,如航天員作息起居、航天員醫學試驗等。
4)有效載荷專項規劃系統:主要完成所有在軌有效載荷的工作計劃和操作安排,并根據空間應用系統的接口約定,在資源約束包絡內對各類載荷工作進行規劃。
5)機械臂遙操作專項規劃系統:主要完成空間站機械臂地面遙操作相關的控制事件規劃,形成基于標準接口的飛控需求模型和詳細操作序列。
6)空間站在軌規劃系統:該專項規劃系統部署在空間站,通過天地IP業務數據接入分布式協同任務規劃系統,航天員可通過該系統參與部分飛控需求和規劃結果的調整與確認。
本文提出了一種我國空間站運行控制任務規劃的基本體系架構方案,相對于載人航天傳統“計劃工作模式”任務規劃方法[11],在分布協同、智能規劃、開放兼容和信息化管理等方面有一定突破,可為我國空間站運行控制任務規劃系統建設提供參考。