C&DHサブシステム — 探査機の「頭脳」がコマンドとテレメトリを統べる仕組み

この回で学ぶこと

これまでの回で、私たちは探査機の通信系を「部品」と「データの形式」という2つの角度から見てきました。探査機RFフロントエンドの回では、トランスポンダ・TWTA・LNA・ダイプレクサが1本のアンテナを共用しながら送受信をこなす配線図を追いました。Space Packetの回では、観測機器やサブシステムが生成するデータが、APIDやシーケンスカウントを持った小包(パケット)へと仕分けられる仕組みを見ました。

しかしここで、素朴だが本質的な問いが残っています。そのSpace Packetは、いったいどこで、何が組み立てているのでしょうか。トランスポンダが受信して復調したコマンドのビット列は、いったい誰が読み解いて、姿勢制御系やカメラに「これを実行せよ」と指示を出しているのでしょうか。

答えは、探査機に搭載された1台(あるいは冗長化された複数台)の搭載コンピュータです。これを中心とするサブシステムを C&DH(Command and Data Handling、コマンド・データ処理系) と呼びます。C&DHは、探査機のあらゆるサブシステム・観測機器と電気的・論理的に接続された、文字通り探査機の「頭脳」であり「神経系」にあたる中枢システムです。この回では、これまで個別に学んできたRF系統やパケット構造が、探査機内部でどのサブシステムによって生成・解釈・統合されているのかという視点から、C&DHの全体像を見ていきます。具体的には次の4つの機能を扱います。

• コマンド受信・実行管理: 復調されたコマンドのビット列を解釈し、宛先のサブシステムへ配信する仕組み。
• テレメトリ収集・フォーマット化: 各観測機器・サブシステムのデータを集約し、Space Packetへと整形する仕組み。
• 時刻管理: CCSDS時刻コードの回で学んだ時刻系を、機体全体で一貫して維持する仕組み。
• FDIR(Fault Detection, Isolation and Recovery、故障検出・分離・復旧): 異常が起きたサブシステムを機体から論理的に切り離し、安全な状態を確保してから復旧を試みる、段階的な自己防衛の考え方。

あわせて、深宇宙の放射線環境がコンピュータの信頼性に突きつける固有の制約と、それに対する耐放射線設計の考え方にも触れます。

直感的導入: なぜ「中枢」が必要なのか

探査機の中に搭載されている機器の数を思い浮かべてみましょう。姿勢制御用のスタートラッカーとリアクションホイール、電源系のバッテリと太陽電池パネル、熱制御系のヒーターとサーミスタ、そして複数の観測機器――カメラ、分光計、磁力計。もしこれらすべてが、地球からのコマンドをそれぞれ独立に受信し、それぞれ独立にテレメトリを送信していたら何が起きるでしょうか。

まず、RFフロントエンドの回で見たように、探査機の送受信機は基本的に1系統(冗長込みでも数系統)しかありません。すべての機器がバラバラに送受信を試みれば、電波の奪い合いが起きて収拾がつきません。また、Space Packetの回で見たAPIDによる仕分けも、誰かが「この機器にはこのAPIDを割り当てる」「このコマンドはこの機器宛てだ」という対応関係を一元的に管理していなければ機能しません。

C&DHは、ちょうど人間の脳が感覚器官からの信号を統合し、筋肉への指令を発するように、探査機内のすべての情報の流れを一手に引き受けます。地上から届いたコマンドはまずC&DHに届き、C&DHがその中身を解釈して該当するサブシステムに伝えます。各サブシステムが生成したデータはまずC&DHに集まり、C&DHがそれをパケット化・整形してから1本の送信機に渡します。この「すべての情報がいったんC&DHを経由する」という構造こそが、探査機というひとつの機体を、バラバラな部品の集まりではなく、統合されたシステムとして機能させている土台です。

もう1つの直感は「唯一の意思決定者」という側面です。地上との通信には片道光時間にして数分から数時間かかることがあり、探査機は多くの時間、地上からの指示なしに自律的に動作しなければなりません。異常が起きたときに「これは危険な状態だ、安全策を取ろう」と判断し実行するのも、C&DHの重要な役割です。この判断ロジックがFDIRであり、後半で詳しく見ます。

コマンド受信・実行管理

RFフロントエンドの回で見たように、地上局からのアップリンク信号はトランスポンダで復調され、ビット列として取り出されます。このビット列は、地上のインターネットで言えばまだ「電線を流れる生の電気信号」に相当する段階であり、そのままでは「何をせよ」という意味を持ちません。C&DHの最初の仕事は、このビット列をコマンドとして解釈することです。

CCSDSの規格では、地上から探査機へのコマンドは Telecommand (TC) と呼ばれ、Space Packetの回で見た一次ヘッダのPacket Typeフィールドが 1 に設定されたパケットとして表現されます。C&DHの搭載ソフトウェアは、受信したTCパケットの一次ヘッダにあるAPIDを見て、そのコマンドがどのサブシステム(あるいはどのアプリケーションプロセス)宛てなのかを判別し、機体内部のデータバス(多くはMIL-STD-1553やSpaceWireといった規格)を通じて該当するサブシステムへ配信します。

コマンドの実行管理には、大きく分けて2つの方式があります。

• リアルタイムコマンド: 地上局とのコンタクト(通信可能時間帯)中に受信し、ほぼ即座に実行されるコマンド。緊急の指示や、運用者が探査機の応答を見ながら対話的に送るコマンドに使われます。
• 時刻タグ付きコマンド(タイムタグドコマンド): あらかじめ「この時刻(あるいはこの条件)になったら実行せよ」という時刻情報(タイムタグ)を付けて地上から送っておき、C&DHの搭載ソフトウェアが機体の時計を監視しながら、指定時刻が来た時点で自動的に実行するコマンド。次のコンタクトまで数時間から数日にわたって地上との通信がない深宇宙探査機では、こちらの方式が運用の大部分を占めます。あらかじめ数百から数千件のコマンドをまとめて コマンドシーケンス として地上でアップリンクし、C&DHがそれを機体内部のスケジューラで管理・逐次実行する、というのが典型的な運用形態です。

このタイムタグドコマンドの仕組みが正しく機能するためには、C&DHが正確な機体時刻を維持し続けている必要があります。これが次に見る時刻管理の役割です。

テレメトリ収集・フォーマット化

コマンドの流れとちょうど逆方向に位置するのが、テレメトリの収集です。姿勢制御系の角速度センサ、電源系のバッテリ電圧、熱制御系の温度センサ、そして各観測機器が生成する科学データ――これらはすべて、それぞれのサブシステム内部で独立に生成されるデータですが、最終的には1本のダウンリンクにまとめて乗せなければなりません。

C&DHのテレメトリ収集機能は、機体内部のデータバスを通じて各サブシステムからデータを定期的に(あるいはイベント駆動で)取得し、Space Packetの回で見た一次ヘッダ・二次ヘッダを付与してパケット化します。このとき、データの発生元ごとに異なるAPIDが割り当てられ、パケット化と同時にPacket Sequence Countが刻まれることで、地上局側での欠落検出が可能になります。生成されたパケット群は、C&DHの管理下で優先度に応じてバッファリングされ、Space Packetの回の階層図で示した通り、この先のSpace Data Link Protocol層でフレームへと多重化されたのち、送信機に渡されてダウンリンクされます。

ここで重要なのは、すべてのテレメトリが生成された瞬間にすぐダウンリンクされるわけではないという点です。深宇宙探査機は、地上局とのコンタクトが得られる時間帯が限られている一方、観測機器は地球との通信の有無に関わらずデータを生成し続けます。したがってC&DHは、生成されたテレメトリ(特に大容量の科学データ)を機体搭載のマス・メモリに一時的に蓄積し、次回のコンタクトでまとめてダウンリンクする、という時間差運用を日常的に行います。このマス・メモリへのデータ蓄積と、限られたダウンリンク時間の中でどのデータを優先してダウンリンクするかという待機データ管理の仕組みは、次回のテーマとして扱います。

また、C&DHはすべてのテレメトリを平等に扱うわけではありません。バッテリ電圧や機器温度のようなハウスキーピングデータは、機体の健全性を監視するために優先的に、比較的低いデータレートで定常的にダウンリンクされる一方、カメラの画像データのような科学データは、コンタクト時間帯の中でも帯域に余裕があるときにまとめてダウンリンクされる、といった優先度制御が搭載ソフトウェアのレベルで設計されます。

時刻管理: 機体全体で時計を合わせる

タイムタグドコマンドの実行タイミングも、テレメトリに付与されるタイムスタンプも、すべて機体が一貫した時刻系を持っていることが前提になります。CCSDS時刻コードの回で見たように、探査機は地上のUTCのようなうるう秒を含む時刻系ではなく、エポックからの単調増加する秒数で表される連続時刻系(CUCフォーマットなど)で運用されます。

この機体時刻の「原器」となるのが、C&DHに搭載されたミッションエラプストタイマ(Mission Elapsed Timer, MET)、あるいは高精度な発振器を基準とするオンボードクロックです。C&DHはこのクロックを常時カウントし続け、機体内部のデータバスを通じて他のすべてのサブシステムに時刻情報を配信します。各サブシステムがテレメトリにタイムスタンプを付ける際も、観測機器が露光開始時刻を記録する際も、参照するのはこのC&DHが維持する機体時刻です。

一方、水晶発振器であっても長期間の運用では周波数ドリフト(経年変化や温度変化による発振周波数のずれ)が蓄積し、機体時刻と真の経過時間との間に無視できないずれが生じます。このため運用チームは、地上局とのコンタクトのたびに、地上の基準時刻(UTC、あるいはDSNの原子時計が刻む時刻)と機体時刻を比較し、そのオフセットを求めて地上のデータ処理系で補正する**時刻相関(タイムコリレーション)**という作業を定期的に行います。C&DHのクロック自体を頻繁に書き換えるのではなく、「機体時刻と真の時刻の対応関係」を地上側で管理するというこのアプローチは、タイムタグドコマンドの実行タイミングが運用中に不用意にずれてしまうことを防ぐための、実務上の安全策でもあります。

耐放射線設計: 深宇宙の放射線とビット反転

C&DHが探査機の中枢である以上、その心臓部である搭載コンピュータ(オンボードコンピュータ、OBC)の信頼性は機体全体の生死を左右します。ここで深宇宙特有の脅威となるのが放射線環境です。

地球の大気と磁気圏に守られた地上のコンピュータとは異なり、深宇宙を飛行する探査機は、太陽から飛来する高エネルギー荷電粒子(太陽フレアに伴う陽子など)や、銀河系外から降り注ぐ**銀河宇宙線(Galactic Cosmic Ray, GCR)**に絶えずさらされています。これらの高エネルギー粒子が半導体メモリやロジック回路のシリコン結晶を通過すると、その経路に沿って電子・正孔対を大量に発生させ、メモリに蓄えられたビットの値を反転させてしまうことがあります。この現象を 単一事象効果(Single Event Effect, SEE) と呼び、その中でもメモリの1ビットが $0$ から $1$(あるいはその逆)に書き換わってしまう現象を 単一事象アップセット(Single Event Upset, SEU) と呼びます。

SEUが起きた場合、影響はビットが格納されていた場所によって大きく異なります。単なる観測データの1ビットが反転しただけなら、その画素値がわずかにずれる程度の軽微な影響で済むかもしれません。しかし、そのビットがプログラムカウンタや重要な制御フラグ、あるいはコマンドシーケンスの実行条件を保持するメモリ領域にあった場合、搭載ソフトウェアの実行フローそのものが破綻し、機体の制御を失いかねません。さらに、SEUよりも深刻な**単一事象ラッチアップ(Single Event Latchup, SEL)**と呼ばれる現象では、荷電粒子の通過が半導体内部に意図しない低抵抗の電流経路を作り出し、過大電流によって素子が永久に破損してしまうことすらあります。

この脅威に対して、C&DHのハードウェア・ソフトウェアは何重もの対策を講じます。

• 耐放射線プロセッサ(Radiation-Hardened Processor): 通常の商用プロセッサとは異なる製造プロセスや回路設計(トランジスタ構造の変更、感度の高い回路の冗長化など)によって、SEUやSELそのものが発生しにくいように作られたプロセッサ。
• ECCメモリ(Error-Correcting Code Memory): メモリの各ワードに誤り訂正符号(多くはハミング符号を拡張したもの)を付加し、1ビットの反転を自動的に検出・訂正する仕組みを持つメモリ。Reed-Solomon符号の回で見た通信路上の誤り訂正と、発想としては同じ「冗長ビットを付加して誤りを検出・訂正する」という原理を、メモリチップの内部に適用したものだと考えられます。
• ウォッチドッグタイマ: 搭載ソフトウェアが正常に動作していることを一定間隔ごとに確認し、応答がなければハードウェアリセットを強制的にかけるタイマ。SEUによってプログラムが暴走・停止した場合の最後の砦として機能します。

これらの対策はいずれも、放射線によるビット反転そのものを完全にゼロにすることはできません。したがって設計思想は「反転が起きること自体は避けられない前提で、それを検出し、訂正し、あるいは訂正できないほど深刻な異常が起きたときには安全な状態に切り替える」という、次に見るFDIRの考え方へと接続していきます。

FDIR: 検出・分離・復旧という段階的アプローチ

FDIR(Fault Detection, Isolation and Recovery、故障検出・分離・復旧) は、C&DHが機体の異常に対処する際の基本的な設計思想です。名前が示す通り、FDIRは次の3段階に分けて考えられます。

1. 検出(Fault Detection): センサ値が許容範囲(リミット)を逸脱していないか、ウォッチドッグタイマへの応答が途絶えていないか、通信リンクの品質が閾値を下回っていないかなど、あらかじめ定義された監視項目を常時チェックし、異常の兆候を捉える段階。
2. 分離(Isolation): 異常を引き起こしていると判断されたサブシステムや機能を、機体全体の制御ループから論理的に切り離す段階。RFフロントエンドの回で見た冗長系設計と同様に、異常が疑われる系統を切り離し、健全なバックアップ系統(あるいは最小限の生存に必要な機能だけ)に切り替えることで、問題の波及を食い止めます。
3. 復旧(Recovery): 安全な状態を確保した上で、可能であれば異常の原因を取り除き、正常な運用状態へ段階的に復帰させる段階。地上からの診断・コマンドを待って復旧作業を進める場合もあれば、あらかじめ定義された自動復旧手順(たとえば疑わしいサブシステムの電源を一度落として再起動する)をC&DHが自律的に実行する場合もあります。

このFDIRの考え方が最も劇的な形で現れるのが、セーフモード通信の回で扱ったセーフモード移行です。C&DHが監視している何らかのパラメータが致命的な異常を示したとき(たとえば姿勢制御が破綻し太陽電池パネルが太陽を向かなくなった、あるいは複数のサブシステムから矛盾した応答が続いた場合)、C&DHはFDIRのロジックに従って「これ以上通常運用を続けることは危険だ」と判断し、非重要な機器の電源を落とし、姿勢を太陽指向・地球指向に固定し、低利得アンテナと残留搬送波への回帰といった最低限の生存確認手段だけを残す、というセーフモードへの移行コマンドを機体自身に対して発行します。つまりFDIRとは、セーフモードという「最終防衛ライン」に至るまでの、異常検知から段階的な切り離しへと続く一連の判断ロジックそのものであり、C&DHはこの判断を人間の介在なしに、多くの場合数秒から数分というごく短い時間スケールで実行しなければなりません。

FDIRの設計で特に重要なのは、「検出」と「分離」を切り離して考えるという点です。異常の根本原因を完全に特定できなくても(検出の精度が不完全であっても)、疑わしい系統を機体全体から切り離すことさえできれば、機体全体を守ることができます。逆に、原因の完全な特定を待ってから行動しようとすると、判断が遅れて被害が拡大しかねません。この「疑わしきは罰する」に近い保守的な設計哲学は、修理不可能で自律的な判断が要求される深宇宙探査機ならではのものです。

実務での使われ方

耐放射線プロセッサの実例。 深宇宙・惑星探査ミッションで広く使われてきた代表的な耐放射線プロセッサに、BAEシステムズ社の RAD750 があります。RAD750はPowerPCアーキテクチャをベースにした耐放射線版プロセッサで、動作クロックは数百MHz程度と地上の民生用プロセッサに比べればかなり控えめですが、数百krad(シリコン)オーダーの総放射線量に耐え、SEUの発生率を大幅に低減する設計が施されています。NASAの火星探査機キュリオシティやパーサヴィアランス、木星探査機ジュノーなど、多くのフラッグシップ級ミッションのC&DHにRAD750系のプロセッサが採用されてきました。より最近のミッションでは、後継の**HPSC(High-Performance Spaceflight Computing)**プロセッサのように、マルチコア化によって耐放射線性を保ちながら演算性能を大きく引き上げる開発も進められています。

リアルタイムOSの採用。 C&DHの搭載ソフトウェアは、コマンド処理・テレメトリ収集・FDIR監視といった複数のタスクを、決められた時間内に確実に処理しなければなりません。このため多くのミッションでは、タスクの実行順序と実行時間を厳密に保証できる**リアルタイムオペレーティングシステム(RTOS)**が採用されます。代表的なものに、Wind River社の VxWorks や、NASA Goddard宇宙飛行センターが開発したオープンソースのフライトソフトウェアフレームワーク cFS(core Flight System) があります。VxWorksは火星探査機やニューホライズンズなど数多くの深宇宙ミッションで実績があり、cFSはアプリケーションをプラグイン形式で追加・差し替えできるモジュール性の高さから、近年の中小規模ミッションで採用が広がっています。

コマンドシーケンスの地上運用。 NASA/JPLの運用系では、地上のミッション運用チームが、タイムタグドコマンドの集合体である「シーケンス」を専用のシーケンス生成ソフトウェア(たとえばJPLのSEQGEN)で作成・検証し、C&DHのスケジューラにアップリンクします。C&DHはこのシーケンスを機体内部に保持し、あらかじめ指定された時刻(あるいは条件)が到来するたびに、ちょうど列車の時刻表のようにコマンドを1つずつ淡々と実行していきます。数億km彼方への即応的なリアルタイム制御が原理的に不可能な深宇宙探査機にとって、この「あらかじめ計画を作り込み、機体に自律実行させる」運用形態こそが、実務上のデフォルトです。

演習問題

1. 銀河宇宙線などの高エネルギー荷電粒子がメモリのビットを反転させてしまう現象を何と呼ぶか、略称とともに答えてください。また、この現象がプログラムカウンタのような重要な領域で起きた場合と、単なる観測データの1画素で起きた場合とで、機体への影響がどう異なるか説明してください。
2. FDIRの3段階(検出・分離・復旧)のうち、「検出」の精度が不完全であっても機体を保護できるのはなぜですか。「分離」の役割に着目して説明してください。
3. C&DHが維持する機体時刻(ミッションエラプストタイマ)は、なぜ地上のUTCとは別の連続時刻系で運用されるのでしょうか。またその機体時刻と地上の基準時刻とのずれを補正するために、運用チームが定期的に行っている作業の名前を挙げてください。
4. タイムタグドコマンドによる運用形態が、深宇宙探査機にとってリアルタイムコマンドよりも中心的な運用手段になっている理由を、地球との通信にかかる時間の観点から自分の言葉で説明してください。

まとめと次回予告

この回では、RFフロントエンドで受信したコマンドと、Space Packetとしてまとめられるテレメトリが、探査機内部のどこで、どのサブシステムによって統合的に処理されているのかという視点から、C&DH(Command and Data Handling)サブシステムの全体像を見ました。C&DHはコマンドの解釈・配信、テレメトリの収集・パケット化、機体全体で共有する時刻の維持という3つの日常的な機能を担うと同時に、深宇宙特有の放射線環境がもたらすビット反転のリスクに耐放射線プロセッサやECCメモリで備え、それでも防ぎきれない異常には検出・分離・復旧というFDIRの段階的なロジックで対処する、まさに探査機の頭脳と呼ぶにふさわしい中枢システムでした。

次回は、C&DHがテレメトリを一時的に蓄積する場所として触れたマス・メモリに焦点を当て、地上局とのコンタクトが得られるまでの間、探査機が生成し続ける大量の観測データをどう機体内部に保持し、限られたダウンリンク時間の中で何を優先して地球に送るか、というダウンリンク待機データ管理の考え方を見ていきます。

参考文献

• J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD
• J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
• CCSDS 133.0-B-2, Space Packet Protocol, Blue Book
• CCSDS 301.0-B, Time Code Formats, Blue Book
• NASA JPL, RAD750 Radiation-Hardened PowerPC Microprocessor, BAE Systems Product Documentation
• NASA Goddard Space Flight Center, core Flight System (cFS) Overview and Architecture Guide