MOサービス (Mission Operations Services) — ミッション運用センター内部のソフトウェア連携を標準化する

この回で学ぶこと

SLEの回では、地上局のアンテナが受信したフレームが、どうやって物理的に離れたミッション運用センター(Mission Operations Center, MOC)まで届けられるかを見ました。SLEは、地上局のRFハードウェアとMOCの運用ソフトウェアという2つの「箱」の間を、BIND-START-TRANSFER-DATA-STOP-UNBINDという共通の骨格を持つ標準インターフェースで疎結合にする——いわば配管(パイプ)を標準化する規格でした。

しかし、ここでもう一段、視点を進めてみましょう。SLEによってフレームが無事にMOCまで届いたとして、そのMOCの中で何が起きているのでしょうか。 MOCは決して単一の巨大なプログラムではありません。実際には、テレメトリの値を監視し限界値超過を検出する「監視制御(Monitoring & Control, M&C)」ソフトウェア、送信するコマンドの計画を立てる「コマンド計画」ソフトウェア、探査機の軌道を推定する「軌道決定(Orbit Determination, OD)」ソフトウェア、過去のデータをすべて記録しておく「アーカイブ」ソフトウェア、これらの活動全体のスケジュールを管理する「プランニング」ソフトウェアなど、性質の異なる多数のソフトウェアコンポーネントが、しばしば異なる開発元によって作られ、互いに連携しながら動いています。

この「MOC内部のソフトウェアコンポーネントどうしの連携」もまた、標準化されていなければ、SLEが解決した問題とよく似た問題——機関ごと、あるいはミッションごとに、その場しのぎの独自インターフェースでソフトウェアを繋ぎ合わせるという状況——を引き起こします。この回のテーマである**MOサービス(Mission Operations Services)**は、CCSDSがこの問題に対して定めたフレームワークで、サービス指向アーキテクチャ(Service-Oriented Architecture, SOA)の考え方に基づき、MOC内部(および、必要であればMOCを越えた先)のソフトウェアコンポーネント間のやり取りを標準化します。この回では、MOサービスの設計思想、その基盤となるMAL(Message Abstraction Layer)の相互作用パターン、代表的なサービス群の概観、そしてSLEとの役割分担の整理を見ていきます。

直感的導入: なぜMOCの「中」もまた標準化が必要なのか

まず、MOサービスがなかったらどうなるかを想像してみましょう。

ある宇宙機関が新しいミッションのMOCを構築するとします。監視制御ソフトウェア、コマンド計画ソフトウェア、軌道決定ソフトウェア、アーカイブソフトウェアを、それぞれ異なるチーム(あるいは異なる契約企業)が開発することはよくあります。このとき、たとえば監視制御ソフトウェアが「テレメトリのパラメータ値が限界値を超えた」というイベントをアーカイブソフトウェアに記録させたい、あるいはコマンド計画ソフトウェアが軌道決定ソフトウェアから最新の軌道推定値を取得したい、といった連携が必ず必要になります。

MOサービスのような標準がなければ、これらの連携は、その都度、開発チーム間で個別に取り決めた独自のAPI・ファイル形式・通信プロトコルによって実装されることになります。これはSLEの回で見た「相対型(bespoke)アプローチ」が、今度は地上局とMOCの間ではなく、MOCの内部で繰り返されるということです。しかもMOCの中には連携すべきコンポーネントの組がいくつも存在するため、コンポーネントの数が $n$ 個あれば、最悪の場合 $O(n^2)$ 通りの個別インターフェースが必要になり得ます——これは国際相互運用の回で見た、標準化なしの相互運用協定のコストがちょうど同じ構造で増大する、という議論の相似形です。

さらに問題は、あるミッションのために苦労して作った監視制御ソフトウェアとアーカイブソフトウェアの連携の仕組みが、次のミッションではまったく再利用できない、という点です。ミッションごとに探査機は違っても、「テレメトリを監視し、限界値超過をアーカイブに記録する」という機能自体は本質的に同じです。にもかかわらず、内部の連携インターフェースがミッション固有の作り込みになっていれば、宇宙機関は毎回このソフトウェア統合作業をゼロからやり直すことになります。

MOサービスが解決するのはこの問題です。MOCを構成する個々の機能(監視制御、アーカイブ、プランニングなど)を、標準化されたインターフェースを持つ「サービス」として定義し、開発元の異なるソフトウェアコンポーネントどうしを、あたかも同じ言葉を話す部品のように組み合わせられるようにする、というのがMOサービスフレームワークの設計思想です。SLEの回で見た「地上局のプロバイダとMOCのユーザを標準インターフェースで疎結合にする」という発想を、そのままMOCの内側の1つ1つのソフトウェアコンポーネントの間にまで適用したもの、とイメージすると理解しやすいでしょう。

定式化・整理その1: サービス指向アーキテクチャとMAL

プロバイダ・コンシューマという役割の再登場

MOサービスのアーキテクチャは、CCSDS 520.0-G(Mission Operations Services Concept)にコンセプトが、CCSDS 520.1-M(Mission Operations Reference Model)に参照モデルが示されています。ここでもSLEの回と同様に、2つの役割が登場します。

• プロバイダ (Provider): あるサービス(たとえば「テレメトリパラメータの値を提供する」という機能)を実装し、外部に公開するソフトウェアコンポーネント。
• コンシューマ (Consumer): プロバイダが公開するサービスを呼び出し、利用するソフトウェアコンポーネント。

SLEとの決定的な違いは、プロバイダとコンシューマの組み合わせが、地上局とMOCという特定の2者間に限定されないことです。MOCの内部で監視制御ソフトウェアがプロバイダ、アーカイブソフトウェアがコンシューマになることもあれば、逆に軌道決定ソフトウェアがプロバイダとなり、複数のコンシューマ(コマンド計画ソフトウェア、可視化ダッシュボード、別のMOCの解析チームなど)が同時にそのサービスを利用することもあります。この柔軟性こそが、サービス指向アーキテクチャ(SOA)という設計思想の核心です。

MAL: 相互作用パターンを技術非依存に抽象化する

ここでMOサービスのアーキテクチャ上、最も重要な層が**MAL (Message Abstraction Layer)です(CCSDS 521.0-B)。MALは、プロバイダとコンシューマがメッセージをやり取りする際の相互作用パターン(interaction pattern)**を、具体的な通信技術(TCP/IP上のソケットなのか、宇宙パケットプロトコルなのか、あるいはメッセージキューなのか)から切り離して抽象的に定義します。

これはSLEの回で見た「BIND-START-TRANSFER-DATA-STOP-UNBINDという共通の骨格の上に、サービスごとに異なるデータの中身を載せ替える」という設計と発想はよく似ていますが、MOサービスではこの抽象化がさらに一段階層化されています。MALが定義する相互作用パターンの上に、COM(Common Object Model, CCSDS 521.1-B)が「オブジェクト・属性・関係」という共通の型システムを提供し、さらにその上に監視制御サービスやプランニングサービスといった個々のMOサービス(CCSDS 522.x系列)が定義される、という3層構造です。そして最下層では、MALが定義した抽象的な相互作用パターンを、TCP/IP・宇宙パケットプロトコル(SPP)・HTTPなど、具体的などの伝送技術の上に実装するかという「トランスポートバインディング」が別途定義されます。上位のサービス定義は、この最下層の技術選択が何であっても変わりません。

MALは、相互作用パターンとして次の6種類を定義しています。コンシューマを $C$、プロバイダを $P$ とし、メッセージの往復を矢印で表すと、次のように整理できます。

パターン	メッセージの流れ	性質
SEND	$C \to P$ (1往復のみ、応答なし)	送りっぱなしの一方向通知
SUBMIT	$C \to P$, $P \to C$(受理確認)	実行を依頼し、成否だけを確認する
REQUEST	$C \to P$, $P \to C$(結果データ)	古典的な問い合わせ・応答(RPC的)
INVOKE	$C \to P$, $P \to C$(即時受理確認), $P \to C$(非同期の結果)	「受理された」と「結果が出た」を分離する
PROGRESS	$C \to P$, $P \to C$(即時受理確認), $P \to C$(中間経過)$\times k$, $P \to C$(最終結果)	長時間かかる処理の途中経過を逐次報告する
PUBLISH-SUBSCRIBE	$C \to \text{Broker}$(購読登録), $P \to \text{Broker} \to \{C_1,\dots,C_m\}$(配信)	複数のコンシューマに非同期に一斉配信する

この整理から分かる重要な点は、「同期的に即座に応答が欲しい処理」と「時間のかかる処理」と「多数の受け手に配る処理」が、それぞれ別の相互作用パターンとして明示的に区別されているということです。たとえば、軌道決定ソフトウェアに「今すぐ最新の推定軌道を1つ返してほしい」という問い合わせはREQUESTで表現できますが、「これから数分かかる精密軌道決定計算を実行し、完了したら結果をよこしてほしい」という要求はINVOKEやPROGRESSの方が適切です。また、監視制御ソフトウェアが検出したテレメトリの限界値超過イベントを、アーカイブ・アラーム表示・別チームの端末など複数のコンシューマに同時に届けたい場合は、PUBLISH-SUBSCRIBEパターンが使われます。コンシューマが後から増えても、プロバイダ側のコード変更は不要という疎結合性が、この一斉配信の場面で特に効いてきます。

定式化・整理その2: 代表的なMOサービス群の概観

MAL・COMという共通の基盤の上に、CCSDSはいくつかの具体的なMOサービスを定義しています。この回ではサービスの内部仕様の詳細には立ち入りませんが(そのアプローチはSLEの回でRAF・RCF・FSP・CLTUの詳細に立ち入ったのとは対照的に、ここでは「どんな種類のサービスがあるか」という全体像の把握を優先します)、代表的な分類は次の通りです。

• 共通サービス (Common Services): どのサービスからも共通して使われる基盤的な機能。利用可能なサービスを検索する「ディレクトリ」機能や、任意のイベントを記録・配信する「イベント」機能、オブジェクトの永続的な保存・検索を行う「アーカイブ」機能などが含まれます。
• 監視制御サービス (Monitor & Control, M&C Services): CCSDS 522.1-Bに規定される、テレメトリパラメータの取得・集約・限界値監視によるアラート通知・遠隔アクション(コマンド)の実行といった、SLEの回で扱ったRAF・RCFがMOC手前まで届けた生のフレームを、MOC内部で「意味のあるパラメータ値」として扱うための一連の機能を提供します。
• ミッションプランニングサービス: 観測計画やコマンドシーケンスのタイムラインを管理し、活動のスケジュールをコンシューマに提供します。
• 自動化サービス: 定型的な運用手順(プロシージャ)の実行を扱います。

これらのサービスはすべて、前節で見たMAL・COMという共通の型システムと相互作用パターンの上に定義されているため、あるサービスの実装者が別のサービスの実装作法を新たに学び直す必要が少なく、また異なるベンダーが開発したサービス実装どうしでも、同じMAL・COMに準拠している限り技術的に組み合わせ可能である、という一貫性が保たれます。

定式化・整理その3: 「配管」の標準化と「アプリケーション」の標準化 — SLEとの役割分担

ここまで見てきたMOサービスとSLEの関係を整理すると、次のように役割分担できます。

• SLE: 地上局のRFフロントエンドとMOCのソフトウェアという、性質の異なる2つの「箱」の間で、フレームという単純な単位のデータを、遅延なく確実に運ぶことに特化した標準です。いわば、OSI参照モデルでいうトランスポート層に近い、データを右から左へ運ぶ配管の標準化です。SLEのプロバイダ・ユーザは、運んでいるフレームの「意味」(どのパラメータの値なのか、限界値を超えているのかどうか)には関知しません。
• MOサービス: 配管を通って届いたデータが、MOC内部でパラメータ値として解釈され、監視され、計画に反映され、アーカイブされ、他のソフトウェアコンポーネントに配られていく、その意味のあるやり取り(セマンティクス)そのものを標準化する、いわばアプリケーション層の標準です。

重要なのは、MOサービスの適用範囲が厳密に「1つのMOCの内部」だけに限定されるわけではないという点です。MALが伝送技術に依存しない抽象層として設計されているため、同じMOサービスのインターフェースは、1つのMOC内部のコンポーネント間だけでなく、ネットワークで結ばれた別々のMOC間、あるいは遠隔地の解析チームの端末とMOCの間といった、より広い範囲の連携にも適用できます。つまりMOサービスは、SLEの回で「地上局とMOCの境界」に対して実現した疎結合という発想を、MOCの内部やその先にあるあらゆるソフトウェア境界に一般化したものだと捉えることができます。

この役割分担が国際協力ミッションや複数ミッションでのソフトウェア再利用にとって持つ価値は明確です。SLEがなければクロスサポートにおける「地上局↔MOC」の配管を毎回作り直すことになったのと同様に、MOサービスがなければ、監視制御ソフトウェア・軌道決定ソフトウェア・プランニングソフトウェアといったMOC内部のコンポーネントを、ミッションのたびに、あるいは供給元企業が変わるたびに、統合作業からやり直すことになります。MOサービスに準拠したコンポーネントであれば、あるミッションで採用した監視制御ソフトウェアを、別のミッションでも(探査機固有のパラメータ定義だけ差し替えて)ほぼそのまま再利用できる可能性が生まれます。

実務での使われ方

ESAのEGS-CC (European Ground Systems – Common Core)

MOサービスフレームワークの採用が最も体系的に進んでいる例が、欧州宇宙機関(ESA)が主導する**EGS-CC (European Ground Systems – Common Core)**です。EGS-CCは、ESA・欧州各国の宇宙機関(フランスのCNES、ドイツのDLR、イタリアのASI、英国宇宙庁など)、そして欧州の宇宙産業各社(エアバス・ディフェンス・アンド・スペース、タレス・アレニア・スペース、OHB、テレスパツィオ、GMVなど)が協力して、打ち上げ前の組立・試験(AIT)段階から打ち上げ後の運用段階まで、あらゆる種類のミッションに共通して使える「ミッション非依存」な地上系ソフトウェア基盤を構築するプログラムです。EGS-CCの外部インターフェースは、CCSDS MOサービス(Mission Operations Services Concept, CCSDS 520.0-G-3を含む)を基盤として設計されており、異なる企業が開発したMCS(ミッション制御システム)コンポーネントが、MOサービスの標準インターフェースを介して相互運用できることを狙っています。

これにより、たとえばある企業が開発した監視制御コンポーネントと、別の企業が開発したプランニングコンポーネントを、同じEGS-CC基盤の上で組み合わせて使う、という**マルチベンダーな「プラグ・アンド・プレイ」**が技術的に可能になります。これは、SLEの回で見た「地上局のハードウェアがどのメーカー製であろうと、MOCのソフトウェアがどの機関の独自システムであろうと、SLEという共通の言葉を話せる限り組み合わせは自由」という利点を、MOC内部のソフトウェア部品どうしの関係に持ち込んだものだと言えます。

衛星コンステレーションでの活用

MOサービスは、多数の衛星を同時に運用するコンステレーションミッションの運用調整でも活用が進んでいます。多数の衛星を扱う運用では、衛星ごとに個別のインターフェースを持つ運用ソフトウェアを都度統合していては、衛星の数が増えるほど統合コストが積み上がってしまいます。標準化されたMOサービスインターフェースを介して各衛星の運用機能(監視制御やコマンド計画)にアクセスできれば、衛星の追加・入れ替えのたびにソフトウェア統合をゼロからやり直す必要がなくなります。

ドイツDLR/GSOCでの実装

ドイツ航空宇宙センター(DLR)の衛星運用管制センターGSOC (German Space Operations Center) でも、CCSDS MOサービスの実装・評価が行われています。実運用のMOCソフトウェアにMOサービスを組み込むにあたっては、MAL・COMという抽象層の学習コストや、既存の(MOサービス以前に構築された)レガシーなMCSとの統合をどう進めるかといった、標準化にはつきものの移行期の課題も報告されており、MOサービスの普及は、SLEほど確立し切ってはいないものの、着実に広がりつつある段階にあるといえます。

演習問題

1. SLEとMOサービスは、どちらも「プロバイダ」と「ユーザ(コンシューマ)」という役割分担を持つ標準ですが、標準化している対象のレイヤーが異なります。「軌道決定ソフトウェアが最新の軌道推定値をコマンド計画ソフトウェアに提供する」という連携は、SLEとMOサービスのどちらの標準化対象に該当するか、理由とともに説明してください。

2. MALのREQUESTパターンとINVOKEパターンは、どちらもコンシューマからの問い合わせに対してプロバイダが結果を返す点は共通していますが、メッセージのやり取りの回数と非同期性が異なります。本文中の表を参考に、それぞれのパターンがMOC内のどのような処理(たとえば即座に返せる問い合わせと、数分かかる計算)に向いているか、具体例を挙げて説明してください。

3. なぜ「テレメトリの限界値超過イベントを、アーカイブ・アラーム表示・別チームの端末という複数のコンシューマに同時に届ける」という場面では、REQUESTパターンよりPUBLISH-SUBSCRIBEパターンの方が適しているのか、疎結合性という観点から論じてください。

4. 国際相互運用の回で学んだ「標準化によって相互運用協定のコストが機関数の2乗のオーダーから線形のオーダーに縮小する」という議論を、今度はMOC内部のソフトウェアコンポーネント統合の文脈に当てはめて考えてください。ESAのEGS-CCのように複数企業が開発したコンポーネントを組み合わせる場合、MOサービスへの準拠がなぜ統合コストの増大を抑えることにつながるか説明してください。

まとめと次回予告

この回では、SLEの回で扱った「地上局とMOCの間の配管の標準化」から視点を一段進め、MOC内部のソフトウェアコンポーネントどうしの連携を標準化するCCSDS Mission Operations (MO) サービスフレームワークを見ました。MOサービスは、サービス指向アーキテクチャの考え方に基づき、プロバイダ・コンシューマという役割と、MAL(Message Abstraction Layer)が定義するSEND・SUBMIT・REQUEST・INVOKE・PROGRESS・PUBLISH-SUBSCRIBEという6種類の相互作用パターンを共通基盤とし、その上にCOM(共通オブジェクトモデル)、さらにその上に監視制御・プランニング・アーカイブといった具体的なMOサービス群を積み重ねる、階層化された標準です。SLEが「配管」を標準化したのに対し、MOサービスは「アプリケーション層」を標準化するという整理は、両者がMOCという同じ現場の異なる断面を担っていることを示しています。実務面では、ESAが主導するEGS-CCという欧州各国・各企業共同の地上系ソフトウェア基盤が、この標準を軸にマルチベンダーな相互運用性を実現しようとしている様子も見ました。

次回は、これまで見てきた「探査機と地球の間の通信」というテーマそのものを歴史的に振り返り、深宇宙通信がどのように発展してきたかという流れに軽く触れていきます。

参考文献

• CCSDS, Mission Operations Services Concept, CCSDS 520.0-G-3 (Green Book)
• CCSDS, Mission Operations Reference Model, CCSDS 520.1-M-1 (Magenta Book)
• CCSDS, Mission Operations Message Abstraction Layer, CCSDS 521.0-B-2 (Blue Book)
• CCSDS, Mission Operations Common Object Model, CCSDS 521.1-B-1 (Blue Book)
• CCSDS, Mission Operations Monitor & Control Services, CCSDS 522.1-B-1 (Blue Book)
• ESA, European Ground Systems – Common Core (EGS-CC), Programme overview (egscc.esa.int)
• S. Gärtner et al., Implementation of CCSDS MO Services at GSOC, DLR
• CCSDS, Overview of Space Communications Protocols, CCSDS 130.0-G (Green Book)