地上局運用の自動化 — 無人局とGround-Station-as-a-Serviceがもたらした運用モデルの転換

この回で学ぶこと

前回、DSNのアンテナという有限資源を数十のミッションがどう取り合っているかを、パス要求の制約充足問題として定式化しました。しかし、スケジューラが「アンテナ$a$、時間スロット$[e_r, l_r]$を要求$r$に割り当てる」と決めた後、実際にそのパスを誰が、どうやって実行するのかという問いにはまだ触れていません。

歴史的には、この実行フェーズには多くの人手がかかっていました。パス開始の数十分前から運用要員が管制室に入り、その探査機の軌道要素(エフェメリス)をもとにアンテナの指向角を手動で計算・入力し、受信機の受信周波数をドップラーシフトの予測値に合わせて手動で追い込み、信号がロックしたことを目視でモニタし、パス終了後にはテープや磁気ディスクの記録を手作業で回収してアーカイブする——といった作業が、パスのたびに繰り返されていました。深宇宙探査の黎明期には、これはやむを得ない姿でした。探査機の数も少なく、地上局も高価な専用設備であり、経験豊富な運用者の判断がなければ弱い信号を確実に捕捉できなかったからです。

しかし現代では状況が大きく変わっています。1つのミッション運用センターが1日に何十パスも処理しなければならない小型衛星群(コンステレーション)の時代になり、しかも各パスの継続時間はLEO(低軌道)ではせいぜい数分から十数分と短い。人手を介していては間に合いませんし、コストも見合いません。この回では、地上局運用が**「毎回同じ手順を、決められたタイミングで正確に実行するソフトウェア」**によって自律化されていく仕組みを、(1) 自動運用シーケンス、(2) 異常検知とフェイルオーバー、(3) 商用地上局ネットワーク(GSaaS)という3つの軸から見ていきます。

直感的な導入: パスは「決まった手順の連続実行」である

なぜ地上局の運用は自動化に向いているのでしょうか。ここで前回の枠組みを思い出すと、答えが見えてきます。前回定式化したスケジューリング問題は、要求$r$に対してアンテナ$a$と時間窓$[e_r, l_r]$を確定させるところまでがゴールでした。この確定した割当情報——「いつ、どの探査機を、どのアンテナで、どの周波数帯で追跡するか」——さえ与えられれば、あとの作業は原理的にはすべて探査機の軌道要素(エフェメリス)とパスパラメータから機械的に導出できる手続きの繰り返しです。

• アンテナをどの方向(方位角・仰角)に向けるべきかは、探査機の軌道要素から計算できる。
• 受信機がどの周波数で信号を待ち受けるべきかは、送信周波数とドップラーシフトの予測式から計算できる。
• 受信したデータが正しく記録・保存されたかどうかは、フレーム同期や誤り検出符号のチェックサムで機械的に検証できる。

つまり、人間の運用者がパスのたびに行っていた判断の多くは、実は「決まった入力から決まった出力を導く計算」であり、これは本質的にプログラムが得意とする仕事です。人間の判断が真に必要なのは、想定外の事態が起きたとき——信号がロックしない、機器がエラーを返す、探査機が予期しないテレメトリを送ってきた、といった例外処理の場面に限られてきます。この「定型作業は自動化し、例外処理だけを人間(または高度な自律系)に委ねる」という設計思想が、現代の地上局自動化の核にあります。

自動運用シーケンスの定式化

自動化された地上局が1回のパスをどう処理するか、時系列で追ってみましょう。パス開始予定時刻を$t_{AOS}$(Acquisition of Signal、可視開始)、終了予定時刻を$t_{LOS}$(Loss of Signal、可視終了)とします。これらは前回の記法で言えば、確定したパス要求$r$の可視ウィンドウ$[e_r, l_r]$そのものです。

フェーズ1: 事前指向(pre-pass pointing)、$t < t_{AOS}$

パス開始前のある時刻$t_{lead}$(典型的には数分前)から、地上局のアンテナ制御システムは自動的に指向を開始します。探査機の軌道要素(2行軌道要素形式=TLEや、より高精度な状態ベクトル)から、地上局を原点とするトポセントリック座標系での方位角$\mathrm{Az}(t)$・仰角$\mathrm{El}(t)$の予測軌跡を計算し、これをアンテナ制御装置(ACU: Antenna Control Unit)に事前ロードします。

$$(\mathrm{Az}(t), \mathrm{El}(t)) = f_{\text{orbit}}\big(\mathbf{r}(t), \mathbf{r}_{\text{station}}\big), \qquad t \in [t_{lead}, t_{LOS}]$$

ここで$\mathbf{r}(t)$は探査機の慣性系での位置ベクトル(軌道伝播式から得る)、$\mathbf{r}_{\text{station}}$は地上局の位置です。事前にアンテナを可視開始点の方向へ向けておくことで、$t_{AOS}$の瞬間には既にビームが探査機の方向を捉えている状態を作ります。

フェーズ2: 周波数捕捉(acquisition)、$t \approx t_{AOS}$

アンテナが正しい方向を向いていても、受信機がまだ信号を検出できていなければ意味がありません。探査機からの信号は、探査機と地上局の相対速度によるドップラーシフトを受けています。

$$f_{\text{received}}(t) = f_{\text{nominal}} \left(1 - \frac{\dot{\rho}(t)}{c}\right)$$

ここで$f_{\text{nominal}}$は無変調時の公称送信周波数、$\dot{\rho}(t)$は視線方向の相対速度(レンジレート)、$c$は光速です。$\dot{\rho}(t)$も同じ軌道要素から予測できるため、自動化された受信機はこの予測ドップラー軌跡$f_{\text{received}}(t)$を中心とした狭い探索窓を設定し、PLL(位相同期ループ、以前のレッスンで扱った搬送波追尾の仕組み)を自動的にスイープさせて、ロック(lock)状態に持ち込みます。ロックの成立は、PLLのループフィルタ出力や信号対雑音比(SNR)モニタの値があらかじめ定めたしきい値を超えたかどうかで、ソフトウェアが機械的に判定します。

フェーズ3: 追尾とデータ収集、$t_{AOS} < t < t_{LOS}$

ロックが成立すると、アンテナはリアルタイムの追尾誤差フィードバック(モノパルス方式やコニカルスキャンなど)と軌道予測を組み合わせて指向を微調整し続けます。受信機・復調器はテレメトリフレームを連続的に復調し、フレーム同期パターン(CCSDSでは規定の同期マーカ)を検出してフレーム境界を確定し、誤り訂正復号(畳み込み符号やリードソロモン符号、あるいはより新しいミッションではLDPC符号)を適用したうえで、地上のデータサーバへストリーミングまたはバッファリングして送ります。この間、システムはSNR・ロック状態・フレーム同期率といった健全性指標を継続的にログします。

フェーズ4: パス終了処理とデータ検証、$t \ge t_{LOS}$

可視ウィンドウを過ぎて信号が失われると(LOS)、アンテナは自動的にスタンバイ位置(たとえば天頂や次のパスに向けた事前指向位置)に戻ります。同時に、そのパスで受信したデータに対する自動検証が走ります。典型的な検証項目は次のようなものです。

• 受信したフレーム数と、期待されるフレーム数(パス継続時間とデータレートから逆算)の比較による欠損率のチェック
• 誤り訂正復号の訂正ビット数やCRC(巡回冗長検査)失敗率からのリンク品質のサマリ生成
• ファイル転送プロトコル(CCSDSではCFDP: CCSDS File Delivery Protocolがよく使われる)のチェックサム検証による完全性確認

これらの検証が自動的に通れば、データは正式にミッション運用側のアーカイブ(長期保存システム)へ自動転送され、パスの記録簿(パスレポート)が自動生成されます。人間の運用者が介入するのは、これらの自動検証のいずれかが失敗を報告した場合に限られます。

異常検知と自動フェイルオーバー

無人化された地上局が信頼して運用できる最大の理由は、異常を自ら検知し、あらかじめ定義された対応手順に自律的に移行できるという設計にあります。この考え方を、簡単な状態機械として整理してみましょう。

地上局の状態を有限集合$S = \{\text{IDLE}, \text{ACQUIRING}, \text{LOCKED}, \text{DEGRADED}, \text{FAULT}\}$のいずれかとし、健全性指標のベクトル$\mathbf{h}(t)$(SNR、ロック指示、フレーム同期率、機器温度など)を継続的に監視するとします。状態遷移は、あらかじめ定めたしきい値$\theta$との比較によって自動的に決まります。

$$\text{LOCKED} \xrightarrow{\text{SNR}(t) < \theta_{\text{warn}}} \text{DEGRADED}, \qquad \text{DEGRADED} \xrightarrow{\text{SNR}(t) < \theta_{\text{fault}}} \text{FAULT}$$

• リンクロック外れの検知。 PLLのロック指示信号が一定時間$\tau$以上「アンロック」を示し続けた場合、システムは自動的にFAULT状態へ遷移し、再捕捉シーケンス(フェーズ2への回帰)を試みます。この再試行が既定回数を超えて失敗すると、単なる一時的な瞬断ではなく機器または探査機側の異常の可能性が高いと判断され、次の対応に移ります。
• 自動フェイルオーバー。 冗長構成を持つ地上局(受信機を2系統持つ、あるいは近傍に代替アンテナがある)では、主系統がFAULT状態に陥ると、あらかじめ定義された切り替えロジックに従って副系統に自動的に切り替わります。これはちょうど、前回扱ったMSPA(1アンテナで複数機受信)とは逆に、「1つの追跡対象に対して複数の受信経路を用意しておき、片方が故障してももう片方が引き継ぐ」という冗長化の考え方です。
• 遠隔アラートの発報。 自動的な再捕捉やフェイルオーバーでも状態がFAULTのまま回復しない場合、システムは人間が介入すべき事態と判断し、当直の運用者(多くの場合、無人局から離れた中央の運用管制センターに常駐している)へメール・SMS・ページャ・運用ダッシュボード上のアラートといった形で通知を送ります。この通知には、健全性指標$\mathbf{h}(t)$の時系列ログや、それまでに自動システムが試みた復旧操作の履歴が添付され、遠隔の運用者が状況を素早く把握できるようになっています。

この設計の核心は、「無人局に運用者を常駐させる」のではなく「異常時にだけ遠隔の運用者を呼び出す」という発想の転換にあります。正常系のパス処理は完全に自動化し、例外系の判断だけを人間に委ねることで、1人の運用者が多数の無人局を並行して監視できるようになります。

小型・低コスト地上局ネットワークの台頭: Ground-Station-as-a-Service

自動化がここまで進んだ背景には、地上局のハードウェア自体の小型化・低コスト化という技術トレンドもあります。かつては、ミッションを立ち上げるには自前で高価な専用パラボラアンテナと管制設備を建設・運用するのが当たり前でした。これは初期投資も運用人件費も非常に大きく、大学の超小型衛星プロジェクトのような予算規模のミッションにはハードルが高いものでした。

しかし、次のような変化がこの前提を覆しつつあります。

1. アンテナ自体の低コスト化。 位相配列アンテナやコンパクトなパラボラアンテナの製造コストが下がり、S帯・X帯対応の小型地上局を、従来より格段に低い設備投資で構築できるようになった。
2. 自動化ソフトウェアの成熟。 本節でここまで見てきたような、指向・捕捉・記録・検証の自動化ソフトウェアがパッケージ化され、専門の運用要員を各サイトに常駐させなくても地上局を運用できるようになった。
3. クラウド的な従量課金モデルの登場。 これら自動化された小型地上局を世界中の複数拠点に分散配置し、ミッション運用者がパス単位(あるいは時間単位)で必要なときだけ利用料を払って使う、**Ground-Station-as-a-Service(GSaaS)**という事業モデルが成立するようになった。

このGSaaSの考え方は、クラウドコンピューティングにおける「自前でサーバを保有・運用する代わりに、必要な分だけ計算資源を借りる」というパラダイムシフトと構造的によく似ています。GSaaS事業者は世界中に地上局サイトを分散配置し、Webベースの予約システム(APIも提供されることが多い)を通じて、ミッション運用者が可視パスを検索し、必要なパスだけを予約して使う、というサービスを提供します。

この変化が運用モデルにもたらした影響は大きく、次のように整理できます。

• 参入障壁の低下。 小型衛星ミッションが、自前の地上局網を一切持たずに、必要なパスだけをGSaaS事業者から調達して運用を成立させられるようになった。これにより、大学・スタートアップ規模の予算でもグローバルな地上局カバレッジを実質的に手に入れられる。
• 地理的カバレッジの向上。 GSaaS事業者は複数国にまたがってサイトを保有していることが多く、単独のミッションが自前で同等の地理的分散を実現するよりもはるかに低コストで、1周回あたりの可視パス数(≒ダウンリンク機会)を増やせる。
• 需要の弾力化。 ミッションの運用フェーズによって必要なパス数は変動します(打ち上げ直後のクリティカルフェーズは頻繁な接触が必要だが、定常運用期は間欠的でよい、など)。自前設備であれば設備規模はピーク需要に合わせて固定的に決めるしかありませんが、GSaaSであれば必要な時期に必要な量だけ調達する弾力的な運用が可能になります。

もっとも、GSaaSにも制約はあります。多数の顧客が同じ地上局サイトを共有するため、前回学んだスケジューリング問題(パス要求の競合)がGSaaS事業者の内部でも同様に発生しますし、独自のアンテナ口径・周波数帯を必要とする大型・高データレートミッション(深宇宙探査機など)は、依然としてDSNのような専用の大型地上局網に頼らざるを得ません。GSaaSが主に威力を発揮するのは、比較的小口径のアンテナで十分な、LEOの小型衛星・キューブサット規模のミッションです。

実務での使われ方

DSNの無人化・遠隔監視化。 NASAのDSNでも、局そのものを完全無人化するのではなく、複数のアンテナを1か所の運用管制室から遠隔で監視・操作する体制への移行が進められてきました。個々のパスの指向・捕捉・記録といった定型作業はモニタ&コントロール(M&C)システムによって自動化され、オペレータは複数アンテナの状態を統合的に監視するコンソールから、異常時のみ介入します。これは本節で述べた「正常系は自動化、例外系だけ人間」という設計思想が、深宇宙用の大型アンテナ運用にも適用されている例です。

商用GSaaSプロバイダの実例。 民間企業が世界各地に自動化された小型地上局サイトを展開し、S帯・X帯を中心に、Webベースの予約インターフェースやAPI経由でパスを従量課金で提供するサービスが実際に運用されています。これらのプロバイダは、本節で述べた自動指向・自動周波数捕捉・自動データ検証のパイプラインを各サイトに実装しており、地上局を新設するたびに専属の運用要員を配置するのではなく、少人数の遠隔監視チームで多数のサイトをカバーする運用体制を取っています。

小型衛星運用者による活用。 大学の超小型衛星プロジェクトや、独自の地上局網を構築する予算のない新興の商業衛星事業者は、自前のアンテナを一切持たずに、こうした商用GSaaSのみでミッション運用(コマンド送信・テレメトリ受信・観測データのダウンリンク)を完結させる例が増えています。これはかつて「地上局は自分たちで建てるもの」だった時代からの、運用モデルの大きな転換を象徴しています。

演習問題

1. 本文で扱ったパスの4フェーズ(事前指向・周波数捕捉・追尾とデータ収集・パス終了処理)のうち、前回で学んだ可視ウィンドウ$[e_r, l_r]$との関係を明示しながら、各フェーズがいつ($t$の範囲として)実行されるかを整理せよ。
2. ある探査機のダウンリンク公称周波数が$f_{\text{nominal}} = 8.4\,\text{GHz}$(Xバンド)、パス中の最大視線方向相対速度が$\dot{\rho} = 7.5\,\text{km/s}$(接近方向)であるとき、受信機が探索すべきドップラーシフトの大きさ$\Delta f = f_{\text{nominal}} - f_{\text{received}}$を計算せよ。光速は$c = 3.0 \times 10^5\,\text{km/s}$とする。
3. ある無人地上局の健全性監視システムが、SNRが警戒しきい値$\theta_{\text{warn}}$を下回ってから$\tau = 30$秒間その状態が継続した場合にFAULT状態へ遷移し、再捕捉を3回試みてすべて失敗したら遠隔アラートを発報する、という設計になっているとする。この設計が「無人局に運用者を常駐させない」という目的をどう実現しているか、本文中の「正常系と例外系の分離」という考え方を使って説明せよ。また、$\tau$の値を極端に短く(たとえば1秒)設定した場合、あるいは極端に長く(たとえば10分)設定した場合、それぞれどのような運用上の問題が生じ得るか論じよ。
4. 自前の専用地上局網とGSaaSという2つの選択肢について、(a) 打ち上げ直後の頻繁なクリティカルフェーズパスが必要な期間と、(b) 定常運用期の低頻度な間欠的パスで足りる期間、それぞれについてどちらが有利になりやすいか、本文中の「需要の弾力化」の議論をもとに論じよ。

まとめと次回予告

この回では、DSNスケジューリングが確定させた「いつ・どのアンテナで・どの探査機を追跡するか」という割当情報を出発点に、実際のパス実行がどのように自動化されているかを見てきました。事前指向・周波数捕捉・追尾とデータ収集・パス終了処理という4フェーズの自動運用シーケンスは、いずれも探査機の軌道要素という共通の入力から機械的に導出できる手続きであり、これが自動化を可能にしている本質的な理由でした。また、異常検知と自動フェイルオーバーの仕組みは「正常系は完全自動化し、例外系だけ人間に委ねる」という設計思想によって、1人の運用者が多数の無人局を遠隔監視できる体制を実現していること、そして地上局ハードウェアの低コスト化とこの自動化ソフトウェアの成熟が、Ground-Station-as-a-Serviceという新しい従量課金型の運用モデルを可能にし、小型衛星運用者が自前の地上局網を持たずにミッションを成立させられる時代を切り拓いたことを確認しました。

次回は、こうして自動化・多様化が進む地上局・ミッション運用システムどうしを、標準化されたインターフェースでどう相互接続するかという課題に触れます。具体的にはCCSDS Mission Operations(MO)サービスという、ミッション運用ソフトウェアの相互運用性を確保するための標準規格の考え方を軽く紹介します。

参考文献

• CCSDS 727.0-B, CCSDS File Delivery Protocol (CFDP)
• CCSDS 132.0-B, TM Space Data Link Protocol
• DSN Telecommunications Link Design Handbook, DSN No. 810-005
• J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
• NASA/JPL, Deep Space Network 公式解説資料(局の遠隔監視・自動化運用に関する記述)
• J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD