コンピューティング基盤部の小林（kobkaz）です。

アークエッジ・スペースでは現在複数の衛星が軌道上で運用されており、その運用業務には私たちのチームが開発している衛星管制システムが用いられています。

衛星管制システムの概要については、以前にもこの技術ブログにて取り上げていますので、あわせてお読みください。

今回は、この衛星管制システムを用いて衛星との通信を行う際に何が起きるのか、技術的な裏側を交えてもう少し詳しい内容をお見せします。また、システムの効率化のための最近の取り組みについてもご紹介します。

衛星運用の実際

運用の様子

アークエッジ・スペースの衛星管制システムでは、衛星が地上局からの可視範囲を通過することを「パス」、パス中に行う地上局と衛星との通信を「コンタクト」とよんでいます。

コンタクトの開始時刻が近づくと、「運用室」とよばれる部屋に何人かの担当者が集まります。参加するのは、全体の意思決定をする「スーパーバイザー(SV)」と、衛星へのコマンド送信など機器の操作を担当する「コマンダー」。さらに必要に応じて、姿勢系、熱系、搭載ミッション機器といったサブシステムの専門家が運用室内またはリモートでリアルタイムの情報分析のために参加します。

こうした担当者の多くはコンタクト中、グラフや数値などが表示された画面を見ています。この画面は運用室のモニター上に、あるいはVPN経由でアクセスすることで各担当者の手元のブラウザ上に表示され、コンタクトごとに発行されるURLを入力することでそのコンタクトの情報を表示することができます。ここに表示される情報には、衛星から受信したテレメトリデータに加えて、アンテナの角度や衛星からの電波の受信強度といった地上局に関するものも含まれます。

コマンダーはこれに加えて、コマンド送信画面の操作を担当します。コマンド送信画面には、実行しているコマンドスクリプト、スクリプトのログ、送信モードの設定やコマンドの送信状況などが表示されており、コマンダーはこれらを通じて地上局設備の操作や衛星へのコマンド送信をします。

通信開始の直前になると、地上局のパラボラアンテナが動きはじめ、各担当者の画面にもアンテナの角度など地上局に関する情報が流れ始めます。

コマンド送信画面では、スクリプトの実行が始まります。一度のコンタクトで通信できる時間は、衛星がどれだけ地上局に近いところを通るかにもよりますが、数分から10分程度です。限られた時間を有効活用するため、作業は基本的に予め計画され、スクリプトとして記述されています。スクリプトの実行は半自動化されており、実行が開始されると完了するかコマンダーが停止操作をするまで自動的に処理が進行します。

スクリプトはまず、アンテナの仰角が5度になるのを待ちます。アンテナは軌道情報に基づき予測される衛星の位置を自動的に指向しますが、地上の人や物への影響を避けるため電波を発射してよいのは5度以上の時に限られるからです。電波を発射してよい条件が満たされると、今度は衛星との通信を確立するための一連のコマンド発行や状態チェックを実行します。

通信確立の手順の最後に、地上局は衛星に対してコマンドのシーケンス番号を設定する命令を送ります。このシーケンス番号は宇宙機関の国際標準化団体CCSDS（Consultative Committee for Space Data Systems）が制定しているCOP-1（Command Operation Procedure-1）というプロトコルに定められたものです。このプロトコルは、地上局から送るコマンドにシーケンス番号を含め、衛星からはシーケンス番号を含んだ確認応答を受け取り、確認応答を受け取れなかった場合はコマンドを自動的に再送することで衛星へ確実にコマンドが届けるものです。衛星側のシーケンス番号が変わったことを確認して、通信確立の手順は終了となります。

通信が確立した後は、衛星のメンテナンスやミッションの実行のための様々なコマンドが発行されていきます。発行されたコマンドは画面右側のコマンド履歴に表示され、ここにはコマンドの内容自体に加え、確認応答の受信状況や、自動再送が行われた場合はその状況も表示されます。

SVやコマンダーは、こうしたスクリプトの進行を監視しつつ、必要に応じてスクリプトの中断、再実行、実行箇所の変更や、場合によっては臨時のコマンド実行をすることになります。

運用の裏側

コンタクトの始まる少し前、衛星管制システムもコンタクトに向けた準備を始めます。コンタクト予約管理サービスが事前に登録されているコンタクトの時刻情報を基にAWS ECS上にひとつのタスクを起動します。

「コンタクトタスク」とよばれるこのタスクでは、コンタクト中に必要な機能を担う様々なコンテナが稼働しています。コンテナ群はそれぞれがAPIを提供するサービスとして相互に通信するマイクロサービス的構成となっています。ほとんどのサービスはgRPCもしくはgRPC-Webのサーバーであり、Rustを実装言語としてgRPCライブラリのtonicを使用して開発されています。

地上局サービス

コンタクトタスクが起動されるのと同じ頃、地上局の機器に接続されているコンピューターでもいくつかのサービスが立ち上がります。地上局の機器はTCPによる操作インターフェースを備えており、機器メーカーの独自プロトコルで操作や状態の取得が可能です。地上局のサービスはこうしたプロトコルを実装し、機能を抽象化してAPIとして提供します。これらのサービスもRustで実装されており、クラウド上のコンタクトタスクからVPNを介して利用されます。

地上局のサービスは通信開始時刻が近づくと各種機器の状態の監視を始め、どの衛星との通信であるかに応じて通信に用いる周波数などを機器に対して設定します。また、アンテナ制御装置に対して衛星の軌道情報を送信し、アンテナが動き始めます。

地上局のサービスはコンタクト中常にアンテナの角度を監視しており、仰角が5度を下回ると電波を止めることで、低い仰角で電波が発射されないように保ちます。

テレメトリ・コマンド処理サービス(tmtc)

コンタクトタスクの中核となるのは、テレメトリとコマンド（併せて「テレコマ」とも）の処理を担うサービスです。ここではCCSDSが定める通信プロトコルに従って、コマンドの送信要求を基に衛星に送るバイナリデータを生成したり、逆に受信したデータからテレメトリを抽出したりします。また、このサービスは衛星との間のテレコマだけではなく、地上局の機器に関する操作や情報の取得も同じインターフェースで扱っており、これらは地上局のサービスが提供するAPIを利用するなどして処理されます。

情報表示画面

運用担当者が見る情報表示画面では、フロントエンドにGrafanaが用いられています。 Grafanaでは主に2つのデータソースが利用されており、一つは衛星の運用開始以来の過去のデータが保存されているInfluxDB、もう一つはこの衛星管制システムの独自プラグインとなっています。独自プラグインはコンタクト内で受信したデータのみを比較的低いレイテンシで表示することを役割とし、コンタクトタスク内でバックエンドのサービスが動いています。バックエンドのAPIはそのコンタクト内のテレメトリのデータを提供するのに加えて、衛星のテレメトリのスキーマ情報も取得できるようになっています。このスキーマ情報を用いて、フロントエンドのGrafanaプラグインはダッシュボードの編集画面において存在するフィールドの選択肢をドロップダウンなどの形式で作業者に提示することができます。表示できるフィールドの数は数千以上もあるので、作業者の負担を減らすこうした機能は重要です。

コマンド送信画面

コマンド送信画面のフロントエンドは、TypeScriptとReactを用いて、通常のWeb UIとして実装されています。この画面についても、コンタクトタスク内のgRPC-Webサーバーをバックエンドとしています。このバックエンドサービスの中心はスクリプトを記述するDSLの処理系となっていて、コマンド構文を実行する際にはテレコマ処理サービスへとコマンド送信要求を送り、逆に取得したテレメトリを使ってスクリプト中のテレメトリ変数の値を評価します。

コンタクトタスク内ではこれらの他に、実行ログを書き込むコンテナなどが動いています。

効率化に向けた取り組み

開発の経緯と目標

2024年5月に開発が始まった衛星管制システムは、2024年12月から実際の衛星運用のために稼働を開始しました。この約半年間の開発は、自分にとって未経験だったAWSの開発を学んだり、アンテナや変復調器といった見慣れない機器を操作するためドキュメントと格闘したり、自社保有の衛星が軌道上に存在しないために統合試験の実施が難しかったりと、非常に慌ただしいものでした。幸い衛星放出のしばらく前にはシステムが一定の完成度となり、稼働初日こそは朝の6時から運用を見守っていた開発チームも数日後には通常の開発業務体制に戻ることができ、大きな障害はないままに年を越すことができました。

そして、今年に入ってからはより利便性・効率性を向上するための開発が始まっています。アークエッジ・スペースでは今後も多くの衛星の打ち上げが予定されており、これに対応するため、開発チームでは「衛星が100機、地上局が10局になっても人手を増やさずに運用ができる」ことを目標として掲げています。人手の要らない運用を実現するには、コンタクトの自動化・無人化が不可欠です。例えば、現在スクリプトは半自動で人間の監視のもと実行されていますが、これを自動化するということも重要な目標となります。

ここでは、スクリプト実行の自動化に向けた取り組みを一つご紹介します。

型検査の導入

スクリプトには独自のDSLが用いられており、文法定義は https://github.com/arkedge/opslang で公開されています。これは衛星管制システム開発プロジェクトの発足前から社内で用いられていたものであり、既存のプログラミング言語への移行も検討しましたが、運用上の特有の条件などもあって引き続きこのDSLを使用することになりました。システム稼働開始当初、このスクリプトによる運用には一つの課題がありました。それは、コンタクト中にコマンド名や変数名などの間違いによってエラーが発生し実行が中断されるということが度々発生する、というものです。この場合、運用者はその都度スクリプトを修正して再実行する必要がありました。こうした手作業による介入が必要である限り、コンタクトの自動化は難しいでしょう。

この課題に対する解決策として、スクリプトに対する型検査が実装されました。通常の静的型付き言語と同様の型検査を行えば、コマンド名や変数名の間違いは全て事前に検出できます。 DSLは言語としての機能自体は少ないため、型検査の実装そのものに大きな非自明性はありませんでした。しかし、型検査において参照すべきコマンドやテレメトリのスキーマをいかに管理するかには、少し課題がありました。

スキーマ管理の課題

テレコマ処理サービス(tmtc)では衛星との間で送受信されるテレコマと地上局の設備などの状態把握や操作に用いられるテレコマの両方を扱っており、それぞれを「衛星テレコマ」、「局テレコマ」とよんでいます。 tmtcのAPIはgRPCであり型がありますが、コマンド要求のメソッドは

message CommandRequest {
  string name = 1;
  repeated Value params = 2;
}

のように、パラメーターとしてコマンド名を表す文字列をとるインターフェースになっており、実質的に「型のない」構造になっています。テレメトリも同様にテレメトリ名を表す文字列を使ったインターフェースとなっており、従ってprotoファイルからスキーマを抽出できるというわけではありません。なぜ衛星のコマンドごとにgRPCのメソッドを分けるのではなく単一のメソッドによる型のないインターフェースになっているかというと、衛星には非常に多数のテレメトリやコマンドがあることに加え、衛星ごとにその内容には差異があるからです。 tmtcは特定の衛星のテレコマに依存せずに実装したいため、衛星テレコマのスキーマについては従来から社内で用いられてきた表現形式である tlmcmddb (https://github.com/arkedge/c2a-tlmcmddb) によって記述し、それを実行時に読み込む方式となっているのです。

一方、局テレコマは衛星テレコマとは違って数は多くないものの、tmtcにおいては衛星テレコマと局テレコマを同一のインターフェースで扱えるようにしているため、同じく型のないインターフェースとなっていました。衛星コマンドの処理についてはtmtcの処理は衛星へと送るバイナリ列をtlmcmddbの内容に従って構成するだけです。これに対して局コマンドの場合は地上局の操作など様々な機能を実装しています。したがって、Rustで書かれた処理が実質的なスキーマを決定していました。

ここまでの状況をまとめると、

テレコマは「型のない」インターフェースによって処理される
衛星テレコマはtlmcmddbでスキーマが管理されている
局テレコマはRustの実装が実質的なスキーマを決定している

ということになります。

衛星テレコマだけであれば型検査器がtlmcmddbを読み込めば解決するのですが、型検査には局テレコマも含めなければなりません。これは単に局テレコマの情報をtlmcmddbとして記述すればよいようにも思われます。しかし、tlmcmddbは単なる型情報ではなく衛星との通信のための項目も含まれていて局テレコマの記述に適さないことや、入れ子のような構造を記述するための機能が必ずしも十分ではないといった問題がありました。また、Rustの実装が定める実質的なスキーマと型検査器に与える情報の合致を担保する仕組みも必要でした。

現在の型検査システム

こうしたスキーマ管理についての課題を解決するため、型検査においては新しくスキーマ記述の形式を設定し、これを用いることにしました。まず、衛星テレコマについては、tlmcmddbから型に関連する情報のみを抜き出して型検査用のスキーマ記述を生成します。一方局テレコマについては、逆にスキーマ記述を基準としてそこからRustの実装に用いるための型定義やトレイト定義を生成しています。そしてtmtcは、生成された型定義やトレイト定義に従って局テレコマを実装しています。この仕組みは、protoファイルからtonicなどのツールを用いてRustやその他のプログラミング言語のソースコードが生成されるのと同様のものです。最後に、型検査器はこのスキーマ記述を読み込んで、スクリプトに対する型検査を行います。

衛星のスクリプトはGitHub リポジトリで管理されており、ここで実装した型検査をCIに導入することで、現在2万行以上のスクリプトに対してコマンド名等の正しさが常に保証されています。

結び

この記事では衛星運用の実際の様子と、その裏側で動く衛星管制システムの仕組み、特にコンタクトタスクの概要を紹介しました。また、自動化に向けたスクリプトへの型検査の導入についても紹介しました。

アークエッジ・スペースの衛星管制システムではこの記事で取り上げた取り組みなどにより、最近ではコマンダーとSVを兼任して一人で運用できたコンタクトや、監視をするものの実際のコンタクト中には一度も手動操作をしないで済むコンタクトが増えつつあり、自動化へ向けた実績と検証を着々と積み重ねています。

最後に、衛星管制システムの開発チームでは現在さらなる自動化・省力化を推進していくチームのメンバーを積極的に募集しています。多数の衛星を管制するシステムを作ることに興味を持たれた方は、ぜひ以下から詳細をご確認ください。