地上セグメントアーキテクチャ — バラバラに学んだ要素技術を『1つのシステム』として俯瞰する

この回で学ぶこと

ここまでのレッスンで、私たちは探査機と地球の間の通信を支える技術を、いくつもの回に分けて個別に学んできました。DSN概論の回ではアンテナと受信機というRFフロントエンドの物理層を、SLEの回では地上局とミッション運用センター(MOC)を結ぶデータ伝送の標準インターフェースを、そしてMOサービスの回ではMOC内部のソフトウェアコンポーネントどうしの連携を、それぞれ独立したテーマとして掘り下げてきました。

しかし、これらは決して無関係な3つの技術ではありません。探査機からのRF信号が、最終的に科学者の解析用ワークステーションにデータとして表示されるまでの1本の道のりの、異なる区間を担っている部品どうしです。この回では、視点をもう一段引いて、これらすべてを「地上セグメント (Ground Segment)」という1つの統合されたシステムとして俯瞰します。

具体的には、次の3つの問いに答えます。第一に、地上セグメントはどのような層(レイヤー)構造を持ち、これまで学んだ個々のレッスンはその構造のどこに位置するのか。第二に、探査機からのビットが科学者に届くまでのデータフローを、これまでのレッスンを結びつける「地図」として描くとどうなるか。第三に、リンク可用性の回で学んだ「単一のRFリンクの統計的可用性」という考え方を、地上セグメント全体というシステムレベルの可用性・冗長性設計にどう拡張できるか。最後に、実際のミッション運用センターがどのようなネットワーク構成を持ち、なぜ複数のミッションが地上セグメントインフラを共通化するのかという実務上の設計思想を見ます。

直感的導入: 「要素技術の寄せ集め」から「1つのシステム」へ

これまでのレッスンを読み終えた読者の頭の中には、おそらく次のような断片的な知識が並んでいるはずです。「PLLは搬送波をロックする」「ASMはフレームの先頭を見つける」「SLEはBIND-START-TRANSFER-DATAという手順でフレームを運ぶ」「MOサービスはMAL(Message Abstraction Layer)という抽象層で相互作用パターンを定義する」——どれも正しい知識ですが、これらが1つの探査機ミッションの中で、どの順番で、どうつながって動いているのかを一枚の絵として説明できるかというと、意外と難しいのではないでしょうか。

これは、大きなソフトウェアシステムを学ぶときによくある落とし穴です。個々のモジュールの内部動作を理解することと、モジュールどうしがどう組み合わさって全体のシステムを構成しているかを理解することは、別のスキルです。地上セグメントも同様で、アンテナ・受信機・SLEプロバイダ・SLEユーザ・監視制御ソフトウェア・アーカイブ・軌道決定ソフトウェアといった個々の構成要素を1つずつ理解しても、それらがなぜこの順番で、この責任分担で配置されているのかという全体設計の論理を掴まなければ、実際のミッション運用センターのネットワーク図を見たときに迷子になってしまいます。

この回でやることは、いわば「木を見て森を見ず」の状態から抜け出すことです。個々の要素技術の内部の数式(PLLのループフィルタ、ASMの相関検出、SLEのBIND手順)には、この回では立ち入りません。それらはすべて既習の各レッスンに譲り、代わりにそれらの要素が地上セグメントという大きなシステムの中でどこに位置し、どんな責任を負っているかという、いわば「地上セグメントの都市計画図」を描くことに専念します。

定式化・整理その1: 地上セグメントの4層構造

まず、地上セグメントを構成する層を整理します。探査機から届く電波が、最終的に科学者が扱えるデータになるまでには、性質の異なる4つの層を順に通過します。

層	役割	代表的な構成要素	既習レッスン
① 物理RF機器層	電波を受信し、ビット列に変換する	アンテナ、低雑音増幅器(LNA)、受信機、復調器、PLL	DSN概論、PCM/PSK/PM
② データ伝送層	ビット列(フレーム)を、地上局からMOCまでネットワーク越しに運ぶ	SLEプロバイダ・ユーザ(RAF・RCF・FSP・CLTU)	SLE
③ ミッション運用ソフトウェア層	届いたフレームを意味のあるデータとして解釈し、監視・計画・記録する	MOサービス(監視制御、プランニング、アーカイブ、MAL)	MOサービス
④ ユーザ層	データを最終的に利用する人間・システム	科学者、運用エンジニア、解析パイプライン、可視化ツール	(このレッスンで初めて登場)

この4層構造は、通信ネットワークの世界でおなじみのOSI参照モデル(物理層→データリンク層→…→アプリケーション層)と発想がよく似ています。実際、①は「物理層」、②は「トランスポート層」に近い性質(単純にデータを右から左へ、遅延なく確実に運ぶことに特化し、中身の意味には関知しない)を持ち、③は「アプリケーション層」(データの意味を解釈し、業務ロジックを実行する)に相当することは、SLEの回やMOサービスの回でもすでに触れた整理です。

重要なのは、各層の境界に、標準化されたインターフェースが置かれているという設計原則です。①と②の境界(地上局のフロントエンドとSLEプロバイダの間)は、局のハードウェア実装がCCSDS 401.0-Bなどの信号規格に準拠している限り、②の実装から独立に選べます。②と③の境界(SLEユーザとMOC内部のソフトウェア)は、SLEという標準インターフェースの向こう側に何があるかをSLEプロバイダ自身は知る必要がありません。③の内部(MOC内部のソフトウェアコンポーネントどうし)も、MALという標準インターフェースで疎結合になっているため、監視制御ソフトウェアの実装をベンダーAからベンダーBに入れ替えても、アーカイブソフトウェアや軌道決定ソフトウェアには影響しません。

この「層の境界を標準インターフェースで疎結合にする」という設計原則こそが、地上セグメント全体を貫く一貫した思想であり、SLEとMOサービスという2つの別々のレッスンで見てきた内容が、実は同じ設計原則の異なる適用例だったことがここで分かります。

定式化・整理その2: データフローの地図 — 探査機のビットが科学者に届くまで

次に、探査機が送信したビット1つが、どういう経路をたどって科学者のもとに届くかを、時系列に沿った「地図」として整理します。これまで学んできた個々のレッスンを、この経路上の座標にプロットしていきます。

1. RF受信: 探査機からの微弱な電波を、地上局のパラボラアンテナが受信する。DSN概論で見た3局体制がここに対応する。
2. 復調: 受信機・PLLが搬送波位相を追尾し、PCM/PSK/PMなどの変調方式に従ってサブキャリア・ベースバンド信号を復調する。
3. ビット同期・フレーム同期: 復調されたビット列の海から、フレーム同期の回で学んだASM(Attached Sync Marker)の相関検出によって、フレームの先頭が掘り当てられる。
4. 誤り訂正復号・フレーム構造化: 誤り訂正符号が復号され、宇宙データリンクプロトコルの回で見たトランスファーフレームの構造(仮想チャンネル、マスターチャンネル)に従って、フレームが仮想チャンネルごとに仕分けされる。
5. SLE転送: ここまでの処理はすべて①物理RF機器層の内部で完結している。完成したフレームは、SLEの回で学んだRAF・RCFサービスによって、②データ伝送層を通り、地上局からMOCへとネットワーク越しに転送される。
6. 意味解釈・監視制御: MOCに届いたフレームは、MOサービスの回で見た③ミッション運用ソフトウェア層で受け取られ、監視制御サービスによってテレメトリパラメータの値として解釈され、限界値監視やアラート判定にかけられる。
7. アーカイブ・配信: 解釈されたデータはアーカイブサービスに永続化され、同時にPUBLISH-SUBSCRIBEパターンなどを通じて、④ユーザ層の科学者の解析ツールや運用者のダッシュボードに配信される。

こうして地図として並べてみると、これまで別々の回として教わってきたレッスンが、実は1本の直線的なパイプラインの、隣り合う区間をそれぞれ担当していたことが分かります。逆に言えば、ミッション運用センターの設計者が「地上セグメントを設計する」という仕事は、この7つの区間それぞれに適切な技術を選び、かつ区間どうしの境界(層の境界)を標準インターフェースで整合させる、というシステム統合の仕事に他なりません。

なお、フォワードリンク(地球から探査機へコマンドを送る方向)はこの逆順、すなわち④ユーザ層(運用者がコマンドシーケンスを計画)→③ミッション運用ソフトウェア層(コマンド計画サービス)→②データ伝送層(SLEのFSP・CLTUサービス)→①物理RF機器層(CLTUの無線送信)という経路をたどります。SLEの回でFSPとCLTUという2つのフォワードリンクサービスを扱ったのは、この逆方向のデータフローの一部だったと位置づけ直すことができます。

定式化・整理その3: 可用性統計を「単一リンク」から「システム全体」へ拡張する

リンク可用性の回では、降雨減衰や太陽合といった確率的な劣化要因を積み重ね、1本のRFリンクが要求されたデータレートを維持できる時間割合としての可用性 $A_{RF}$ を定式化しました。この回では、この考え方を地上セグメント全体というシステムレベルに拡張します。

直列構成(シリーズ)の可用性

図で整理した①〜④の各層は、データが必ず順番に通過する直列(シリーズ)構成です。各層(あるいは各構成要素)$i$ の可用性を $A_i$(その要素が正常に機能している時間の割合)とすると、途中のどこか1箇所でも機能停止すればエンドツーエンドでデータが届かないため、システム全体の可用性は各要素の可用性の積で与えられます。

$$A_{E2E} = \prod_{i=1}^{n} A_i = A_{\text{RF}} \cdot A_{\text{復調}} \cdot A_{\text{SLE伝送}} \cdot A_{\text{MOCソフトウェア}} \cdot A_{\text{アーカイブ}} \cdots$$

これは信頼性工学における**信頼性ブロック図(Reliability Block Diagram, RBD)**の直列モデルそのものです。ここで重要な帰結は、個々の要素の可用性がどれだけ高くても、直列に並ぶ要素の数が増えるほど、全体の可用性は掛け算で下がっていくという点です。たとえば $A_{RF}=0.98$(降雨減衰などによるリンク可用性の回の議論)、地上ネットワークの可用性 $A_{\text{net}}=0.9995$、MOCソフトウェアの可用性 $A_{\text{MOC}}=0.999$ だとすると、

$$A_{E2E} \approx 0.98 \times 0.9995 \times 0.999 \approx 0.979$$

となり、個々の要素が99%を超える高可用性であっても、直列に連なることで全体の可用性は最も弱い要素(この例では $A_{RF}$)にほぼ支配されてしまいます。これは「システムの可用性は、その中で最も弱い環に律速される」という、地上セグメント設計における基本的な教訓です。

並列冗長化による可用性の底上げ

そこで、可用性を落としたくない重要な構成要素には**冗長化(redundancy)**が施されます。同じ機能を独立に果たせる予備系統を $m$ 個並列に用意し、どれか1つでも稼働していればシステムとして機能する場合、その部分の可用性は

$$A_{\text{parallel}} = 1 - \prod_{j=1}^{m} (1 - A_j)$$

で与えられます。たとえば可用性 $A=0.95$ の系統を2重化 ($m=2$) すると、$A_{\text{parallel}} = 1-(1-0.95)^2 = 0.9975$ まで底上げされます。地上セグメントにおける冗長化には、大きく分けて2つの形があります。

• アクティブ・スタンバイ型の冗長化: MOCの制御用計算機やネットワーク経路を、主系と予備系の2系統用意し、主系が停止したら予備系に切り替える。地上局運用の自動化の回で見た異常検知とフェイルオーバーの仕組みが、この切り替えを担う。
• 地理的・時間的な多重化による冗長化: DSN概論の回で見た、ゴールドストーン・マドリード・キャンベラが経度約120度おきに配置される3局体制は、地球の自転によって単一局では実現できない連続的な可視性を、地理的に分散した局の組み合わせによって実現するという、狭義の並列冗長化とは少し性質の異なる時間分割型の冗長性です。1つの局が保守作業やハードウェア故障で使えなくなっても、別の局が同じ探査機を追跡できるという意味では、これも広い意味での可用性向上策だといえます。

独立性の仮定への注意 — 共通原因故障

ここで数式上の重要な注意点があります。上記の並列冗長化の式 $A_{\text{parallel}} = 1-\prod(1-A_j)$ は、各系統の故障が互いに統計的に独立であるという仮定のもとで成り立ちます。しかし実際には、予備系が主系と同じ電源系統・同じデータセンター・同じソフトウェアの同じバージョンを使っていれば、1つの原因(停電、ソフトウェアのバグ、サイバー攻撃)が両系統を同時に停止させる**共通原因故障(common-cause failure)**が起こり得ます。この場合、実効的な可用性は独立性を仮定した式よりも悪化します。

MOサービスの回で見たEGS-CCのような、複数ベンダーが標準インターフェース(MAL)に準拠しつつ独立に開発したコンポーネントを組み合わせるマルチベンダー設計は、機能面での相互運用性というメリットだけでなく、単一ベンダー・単一実装への依存を減らすことで共通原因故障のリスクを下げるという可用性設計上の副次的な利点も持っている、と捉えることができます。

定式化・整理その4: 拡張性 — なぜ地上セグメントは「標準インターフェース」で設計されるのか

国際相互運用の回やMOサービスの回で見た議論をもう一度思い出しましょう。標準化されていない相対型(bespoke)のインターフェースでミッションごとに地上セグメントを作ると、機関数・ミッション数 $n$ に対して統合の組み合わせが最悪 $O(n^2)$ のオーダーで増大する一方、標準インターフェースに基づく設計では、新しい要素を追加するたびに標準への準拠を確認するだけでよく、コストの増大は $O(n)$ のオーダーに抑えられます。

この議論は、地上セグメントの**拡張性(scalability)**という観点からも同じ形で現れます。地上セグメントの各層の境界が①〜④で見たように標準インターフェース(SLE、MAL)で切られていれば、次のような拡張が、他の層に影響を与えずに行えます。

• 新しい地上局(たとえば新設のアンテナサイトや商用局)を、SLEプロバイダとして追加するだけで、既存のMOCソフトウェアを変更せずに接続できる。
• 新しいミッションのMOCソフトウェアを、既存の地上局網にSLEユーザとして接続するだけで、地上局側の実装を変更せずに運用を開始できる。
• MOC内部で新しい機能(たとえば新しい自動化サービス)を追加する際も、MALに準拠していれば、既存の監視制御・アーカイブサービスの実装を変更する必要がない。

この性質は、次節で見る「複数ミッションでの地上セグメント共通化」という実務上の設計判断を、技術的に可能にしている土台です。

実務での使われ方

複数ミッション共通の地上セグメント基盤

実際のミッション運用機関の多くは、ミッションごとに専用の地上セグメントをゼロから構築するのではなく、共通の地上セグメント基盤を複数のミッションで再利用するという設計判断を取っています。

NASA/JPLのAMMOS (Advanced Multi-Mission Operations System) は、その代表例です。AMMOSは、テレメトリ処理、コマンド計画、航法(軌道決定)、シーケンス生成、アーカイブといった地上セグメントの③ミッション運用ソフトウェア層の機能群を、個々のミッション専用にではなく、JPLが運用する数十件規模の深宇宙・地球周回ミッションで共通して使えるように設計されたソフトウェア基盤群として提供しています。新しいミッションが立ち上がるたびに、これらの機能をゼロから開発し直すのではなく、探査機固有のパラメータ定義やミッション運用手順だけを差し替えてAMMOSの上に構築することで、ミッションあたりの地上セグメント開発コストを大きく圧縮しています。

ESAのESOC (European Space Operations Centre) も同様に、MOサービスの回で見たEGS-CCやその前身であるSCOS-2000というミッション制御システム(MCS)基盤を土台に、1つの管制センターから同時に多数のミッションを運用しています。個々のミッションの探査機は異なっていても、③層のソフトウェア基盤とそれを支える運用要員・施設・②層のSLEインフラは共有されるため、ミッションを追加するたびに管制センターをまるごと新設する必要がありません。

地上局網(①層)の共通化も同じ発想で進んでいます。DSN概論の回で見たNASA/JPLのDSN、ESAのESTRACK、JAXAの臼田・美笹局などの地上局網は、それぞれ自機関の複数ミッションに共通利用されるだけでなく、国際相互運用の回で見たクロスサポートの枠組みによって、他機関のミッションからも一時的に利用されます。さらに近年は、地上局運用の自動化の回で見たKSAT、AWS Ground Station、Atlas Space Operationsのような商用GSaaS(Ground-Station-as-a-Service)事業者が、①層と②層(SLEインターフェース)を複数の異なる運用者に時間貸しするという、地上セグメントの共通化をさらに機関の壁を越えて推し進めています。

ミッション運用センターのネットワーク構成の実例

実際のMOCのネットワーク構成を模式的に描くと、複数の地上局(DSN、ESTRACK、商用局など)がそれぞれSLEプロバイダとしてMOCの外側に位置し、MOC内部にはSLEユーザとして機能するフロントエンド計算機群、その先にMAL経由で接続された監視制御・プランニング・軌道決定・アーカイブの各サブシステム、さらにその先に運用者端末や科学者向けデータ配信サーバーが連なる、という多段構成になります。この構成では、①〜④の各層の間に冗長化されたネットワーク経路(主経路と予備経路)、負荷分散されたサーバー群、地理的に離れた場所にあるバックアップ管制センター(たとえばESAは主管制センターの機能停止に備えた代替施設を運用しています)が配置され、前節で定式化した並列冗長化の考え方が、実際のハードウェア・ネットワーク構成として具体化されています。

演習問題

1. 本文中の4層構造(①物理RF機器層、②データ伝送層、③ミッション運用ソフトウェア層、④ユーザ層)について、フレーム同期の回のASM相関検出と、MOサービスの回のPUBLISH-SUBSCRIBEパターンは、それぞれどの層に属する処理か答え、その理由を説明してください。

2. ある地上セグメントが、①RF受信 ($A=0.99$)、②SLE伝送 ($A=0.9998$)、③MOCソフトウェア ($A=0.999$)、④アーカイブ ($A=0.9995$) という4つの直列構成要素からなるとします。エンドツーエンドの可用性 $A_{E2E}$ を計算してください。また、③MOCソフトウェアを独立な2系統で冗長化した場合(各系統 $A=0.999$)、新しい $A_{E2E}$ はどう変化するか計算してください。

3. 前問の冗長化において、もし2系統のMOCソフトウェアが同じデータセンターの同じ電源系統に接続されていた場合、計算した可用性の値が実際の運用でどのように過大評価となり得るか、共通原因故障の概念を用いて説明してください。

4. 国際相互運用の回で学んだ「標準化によって相互運用協定のコストが機関数の2乗のオーダーから線形のオーダーに縮小する」という議論を、AMMOSやESOCのような複数ミッション共通の地上セグメント基盤の文脈にあてはめ、なぜこうした基盤の共通化が経済的に合理的なのかを説明してください。

まとめと次回予告

この回では、DSN概論・SLE・MOサービスという個別のレッスンで学んできた技術を、①物理RF機器層、②データ伝送層、③ミッション運用ソフトウェア層、④ユーザ層という4層構造を持つ「地上セグメント」という1つの統合システムとして俯瞰し直しました。探査機のビットが科学者に届くまでのデータフローを地図として整理すると、これまでのレッスンがそれぞれこの経路のどこを担当していたかが明確になります。また、リンク可用性の回で単一のRFリンクについて学んだ統計的可用性の考え方を、直列構成と並列冗長化の信頼性ブロック図モデルによって、地上セグメント全体のシステムレベルの可用性設計へと拡張しました。そして実務面では、AMMOSやESOC、商用GSaaSといった、複数ミッションで地上セグメント基盤を共通化することによるコスト削減という設計思想を見ました。

次回は、周波数分配とITU電波規則の回で整理した制度的な枠組みを踏まえ、実際の深宇宙ミッションが新しい周波数利用を国際的に調整していく過程を、具体的な実例研究として軽く覗いてみます。

参考文献

• ECSS, Ground Systems and Operations, ECSS-E-ST-70C
• CCSDS, Overview of Space Communications Protocols, CCSDS 130.0-G (Green Book)
• CCSDS, Cross Support Reference Model—Part 1: Space Link Extension (SLE) Services, CCSDS 910.4-B
• CCSDS, Mission Operations Services Concept, CCSDS 520.0-G-3 (Green Book)
• J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD(地上セグメント設計の章)
• NASA/JPL, Advanced Multi-Mission Operations System (AMMOS), Programme overview (ammos.nasa.gov)
• ESA, European Ground Systems – Common Core (EGS-CC), Programme overview (egscc.esa.int)
• E. A. Elsayed, Reliability Engineering(信頼性ブロック図・冗長化設計の一般理論)