マスメモリとオンボードデータ蓄積 — 可視時間の外で生まれるデータをどう守るか

この回で学ぶこと

中継通信アーキテクチャの回では、火星のローバーが周回機のパスという限られた時間帯でしかデータを送れないこと、そしてその制約を埋め合わせるために**Store-and-Forward(蓄積転送)**という運用方式が必要になることを見ました。そこでは

$$R_{gen}\, T_{sol} \;\lesssim\; \sum_{i} R_{b,1}\, T_{pass,i}$$

という不等式で、「1ソルあたりに生成されるデータ量」と「その日のパスで転送できるデータ量」を比較し、両者のバランスが崩れると機上メモリが日に日に埋まっていくと述べました。しかし前回はそこで止まり、「機上メモリ」そのものの中身には踏み込みませんでした。

この回では、その「Store」の部分——探査機が観測データを一時的に溜め込んでおくマスメモリ(mass memory)——を主役にします。中継衛星のパスだけでなく、深宇宙探査機がフライバイ観測のために姿勢を変え、地球にアンテナを向けられない時間帯が生じる場合も、事情はまったく同じです。**「データはいつでも生まれるが、送れるのは一部の時間帯だけ」**という構図がある限り、その間データを保持し続ける記憶装置が必要になります。

この回で扱うのは3つの問いです。(1) 生成レートとダウンリンクレートのミスマッチから、必要なバッファ容量をどう数式で見積もるか。(2) 宇宙放射線環境でビットが勝手に反転する中、そのメモリの中身をどう守るか。(3) 全データを保存しきれないとき、何を残し何を捨てるべきかをどう決めるか。最後に、New Horizons、JWST、火星探査車といった実機のマスメモリ容量と運用サイクルを見ながら、これらの数式が現実の設計にどう反映されているかを確認します。

直感的導入: 「送れない時間」は中継衛星だけの話ではない

中継通信アーキテクチャの回で見たパス(pass)の制約は、周回機を介した2ホップ通信に固有の話のように見えるかもしれません。しかし実際には、探査機がダウンリンクできない時間帯が生じる原因はもっと広く存在します。

• 中継のパス: 周回機がローバーの上空を通過する数分〜十数分だけしかHop 1のリンクが開かない(relay-architectures)。
• アンテナ指向の競合: 深宇宙探査機がフライバイ観測やサンプリング作業のために、観測機器を目標天体に向ける姿勢を取ると、HGAを同時に地球へ向けられないことがある。この間、地球への実時間ダウンリンクは物理的に不可能になる。
• DSNの可視性そのもの: DSN概論で見たように、地球の自転や局のスケジューリングの都合上、24時間365日ある探査機を専有できるとは限らない。

原因が中継衛星のパスであれ、観測姿勢の競合であれ、DSN局のスケジュール制約であれ、探査機側から見える現象は共通しています。観測機器はほぼ絶え間なくデータを生成し続けるのに対し、そのデータを外部に送り出せる時間帯は間欠的にしか訪れない。 この生成と転送のリズムのズレを吸収する緩衝材が、機上のマスメモリです。

生成レートとダウンリンクレートのミスマッチを定式化する

バッファ占有量の積分式

時刻 $t$ における観測データの瞬時生成レートを $R_{gen}(t)$、瞬時ダウンリンクレートを $R_{down}(t)$ とします(通信できない時間帯は $R_{down}(t)=0$)。機上メモリの占有量(蓄積されているビット数)を $B(t)$ とすると、これは単純な収支の積分で表せます。

$$B(t) = B(t_0) + \int_{t_0}^{t} \big[R_{gen}(\tau) - R_{down}(\tau)\big] \, d\tau$$

この $B(t)$ が満たすべき制約は2つあります。まず当然ながら負にはなり得ません($B(t)\geq 0$)。そしてもう一つ、搭載しているメモリの物理容量 $C_{mem}$ を超えることもできません。

$$0 \;\leq\; B(t) \;\leq\; C_{mem} \qquad \text{for all } t$$

もし $B(t)$ がこの上限に達すれば、それ以上のデータは保存できず、失われるか、あるいは既存の低優先度データを上書きするしかありません(この処理は後述します)。つまりミッション設計者にとっての第一の仕事は、想定される観測プロファイル $R_{gen}(t)$ とダウンリンク計画 $R_{down}(t)$ のもとで、$B(t)$ が現実に取り得る最大値を見積もり、それを下回らないだけの容量 $C_{mem}$ を確保することです。

$$C_{mem} \;\geq\; \max_t B(t)$$

単純化した2相サイクルモデル

実際の運用プロファイルは複雑ですが、本質を掴むために単純化したモデルで考えてみましょう。探査機が「観測フェーズ(継続時間 $T_{obs}$、生成レート $R_{gen}$ 一定、ダウンリンクなし)」と「通信フェーズ(継続時間 $T_{pass}$、ダウンリンクレート $R_{down}$ 一定、新規生成なしとする)」を交互に繰り返すサイクルを考えます。観測フェーズの直後にバッファ占有量は最大になり、

$$B_{max} = R_{gen}\, T_{obs}$$

これがバッファに求められる最低限の容量です。続く通信フェーズでこのデータをすべて掃き出せるかどうかは、次の条件で決まります。

$$R_{down}\, T_{pass} \;\geq\; R_{gen}\, T_{obs}$$

これはまさに前回のStore-and-Forwardの不等式を1サイクル単位に書き直したものです。この条件が満たされれば、バッファは毎サイクルきれいにゼロへ戻り、$C_{mem}\geq R_{gen}T_{obs}$ だけ確保しておけば定常的に運用できます。しかしこの条件が破れる、つまり1回の通信フェーズで生成分を掃き出しきれない場合は事態が変わります。$n$ サイクル後のバッファ占有量(オーバーフローが起きないと仮定した場合)はおおよそ

$$B_n \;\approx\; n\big(R_{gen}T_{obs} - R_{down}T_{pass}\big)$$

と、サイクルを重ねるごとに単調に増加していきます。これは有限容量 $C_{mem}$ のメモリでは早晩破綻する成長であり、実際のミッションでは「毎サイクルで完全に掃き出す」ことを前提とせず、複数サイクル分の余裕を見込んだ容量を積み、かつ後述する優先順位付けによって低価値データを計画的に上書きする運用が組み込まれます。

放射線環境とメモリの信頼性: EDACとスクラビング

なぜメモリの中身が勝手に壊れるのか

地上のコンピュータと違い、探査機のメモリは大気圏に守られない環境で、宇宙線や van Allen帯・木星磁気圏などの捕捉放射線帯からの高エネルギー荷電粒子に常時さらされています。1個の荷電粒子がメモリセルを通過すると、記憶されているビットの値が反転してしまうことがあります。これを**SEU(Single Event Upset、単一事象アップセット)と呼びます。ECC(誤り訂正符号)やReed-Solomon符号を通信路のビット誤りに対して使ってきたこれまでの回とまったく同じ発想を、今度は通信路ではなくメモリセルというもう1つの「誤りが起きうる媒体」**に対して適用する必要があります。

最も基本的な保護方式は、メモリのワード(たとえば32ビットや64ビットの記憶単位)ごとに検査ビットを付加する**EDAC(Error Detection And Correction)**です。代表的な符号がHamming符号で、$k$ ビットの情報に対して $r$ 個の検査ビットを付加し、全長 $n=k+r$ のワードとして

$$2^r \;\geq\; n+1$$

を満たす最小の $r$ を選べば、1ビット誤りを訂正できます。実用上はさらに検査ビットを1つ追加した拡張Hamming符号(SEC-DED: Single Error Correction, Double Error Detection)がよく使われ、1ビット誤りは訂正、2ビット誤りは(訂正はできなくても)検出できるようにします。たとえば $k=32$ の情報ビットに対しては $r=7$ 個の検査ビット(SEC-DEDならさらに1ビット追加して計8ビット)を付加する構成が典型的で、オーバーヘッド比は

$$\frac{r}{k} = \frac{7}{32} \approx 22\%$$

程度になります。この冗長ビット分だけ実効的なメモリ容量は目減りしますが、放射線環境で信頼できるデータを保持するための必要経費です。

スクラビングと多重ビット誤りの確率

SEC-DED符号は1ワード中に2ビット以上の誤りが同時に蓄積すると訂正できなくなります(検出はできても、正しい値には戻せません)。ここで重要になるのが**メモリスクラビング(memory scrubbing)**という運用です。これは一定間隔でメモリ全体を読み出し、EDACで検査・訂正し、訂正結果を書き戻すことで、単発の1ビット誤りが次の1ビット誤りと重なって「訂正不能な2ビット誤り」に育つ前に取り除いてしまう予防措置です。

この効果をポアソン過程で見積もってみましょう。1ビットあたりの単位時間あたりSEU発生率を $\lambda_{SEU}$(単位: upsets/bit/時間)とし、$n$ ビットのワードにおいてスクラビング間隔 $T_{scrub}$ の間に発生する期待アップセット数を

$$\mu = n\,\lambda_{SEU}\, T_{scrub}$$

とすると、この間隔内にそのワードで2個以上のアップセットが発生し、SEC-DEDでも訂正できなくなる確率は

$$P(\text{uncorrectable}) = P(N\geq 2) = 1 - e^{-\mu}(1+\mu)$$

で近似できます($N$ はポアソン分布に従うアップセット数)。$\mu \ll 1$ のとき、この式は $P(\text{uncorrectable}) \approx \mu^2/2$ と2次で効いてくるため、スクラビング間隔 $T_{scrub}$ を半分にすれば訂正不能確率はおよそ4分の1に減ります。搭載メモリの総ビット数が大きいほど1ワードあたりの $\mu$ は小さくても総ワード数が多くなるため、実務ではミッション全体の許容故障率から逆算して $T_{scrub}$ の上限を設計します。

フラッシュメモリの書き込み回数制限

もう一つの物理的な制約が、NAND型フラッシュメモリに特有の**書き込み・消去回数の上限(エンデュランス)です。フラッシュメモリはフローティングゲートに電荷を注入・放出することで記憶しますが、この操作を繰り返すと絶縁膜が劣化し、典型的な民生グレードのNANDフラッシュでは $10^4$〜$10^5$ 回程度で書き込みが不安定になります。マスメモリは同じ領域に何度もデータを上書きする(観測→ダウンリンク完了→次の観測データで上書き、を毎日繰り返す)運用のため、この制限は無視できません。対策として、書き込みを特定のセルに偏らせないウェアレベリング(wear leveling)**をコントローラが行い、また特に書き換え頻度の高い制御パラメータやブートコードには、書き換え回数の制約が原理的に存在しないMRAM(磁気抵抗メモリ)やEEPROMを併用する設計もよく見られます。

データ優先順位付け: 何を残し、何を捨てるか

価値密度による貪欲法

バッファが容量上限 $C_{mem}$ に達しそうなとき、探査機は「これ以上は保存できない」という判断を迫られます。理想的には、保存されている各データセグメント $i$(サイズ $s_i$、科学的価値 $v_i$)の中から、総サイズが容量に収まる範囲で総価値を最大化する部分集合を選びたいところです。これは組合せ最適化の言葉で言えばナップサック問題そのものです。

$$\max \sum_i v_i x_i \quad \text{s.t.} \quad \sum_i s_i x_i \leq C_{mem}, \qquad x_i \in \{0,1\}$$

しかし0-1ナップサック問題は一般にNP困難であり、耐放射線設計ゆえに処理性能が地上の計算機よりずっと控えめな搭載計算機で、リアルタイムに厳密解を求めるのは現実的ではありません。そこで実務では、この問題の連続緩和(fractional relaxation)が最適となることが知られている性質を利用し、各セグメントの価値密度 $v_i/s_i$(単位容量あたりの科学的価値)でソートし、密度の高い順に貪欲に採用していくヒューリスティックが使われます。

$$\text{優先順位} \;=\; \text{降順に整列された} \ \frac{v_i}{s_i}$$

具体的な実装としては、多くの探査機がデータの種類ごとに固定の優先度クラス(たとえば「緊急ヘルスモニタリング」「主要科学観測」「補助観測」「エンジニアリングログ」)を割り当て、バッファをクラスごとの領域に分割した循環バッファ(circular buffer)として運用します。容量が逼迫すると、最も優先度の低いクラスの、最も古いデータから順に新しいデータで上書きされていきます(FIFO overwrite)。これはQoSの回で見た「ダウンリンク帯域をどう配分するか」という伝送順序の優先度制御とは別の階層の問題であることに注意してください。ここで扱っているのは伝送順序ではなく、そもそも地球に送られる前に、限られたメモリの中に生き残れるかどうかという保存順位の問題です。実際の運用では両者が組み合わさり、「高優先度クラスは長く保持され、かつダウンリンクキューでも先に送られる」という二重の優先制御が行われます。

実務での使われ方

深宇宙フライバイの記録再生: New Horizons

2015年にNASAのNew Horizonsが冥王星をフライバイした際、探査機は接近時間帯のほとんどで観測機器を冥王星方向に向け続ける必要があり、地球方向へのHGAを同時に向けることはできませんでした。New Horizonsは容量各8GBのソリッドステートレコーダ(SSR)を2基搭載しており、フライバイ中に生成された画像・分光データはいったんこの合計約16GBのメモリに蓄積されました。フライバイ後、探査機は姿勢を地球方向に戻してダウンリンクを開始しましたが、当時の探査機-地球間距離(約32〜33 AU)ではリンクバジェットの制約からダウンリンクレートはわずか1〜2 kbpsのオーダーしか出せず、蓄積した全データを完全に地球へ送り切るまでに約15か月を要しました。これは本文の2相サイクルモデルで言えば、$T_{obs}$(数時間のフライバイ)に対して $T_{pass}$ にあたる通信期間が1年以上にまで引き延ばされた、極端な非対称の実例です。

double-buffering運用: JWST

ジェイムズ・ウェッブ宇宙望遠鏡(JWST)は、搭載するソリッドステートレコーダ(公表値でおよそ68 Gbit規模の容量)に観測データを蓄積し、1日に約2回、DSNとのKa帯コンタクトでまとめてダウンリンクする運用サイクルを取っています。観測は途切れることなく継続する一方、ダウンリンクは1日のうち数時間のコンタクトウィンドウに限られるため、まさに本文で見た $R_{gen}(t)$ が常時正、$R_{down}(t)$ が間欠的というモデルそのものの運用です。メモリ容量は、1回のコンタクト間隔で生成される観測データ量に十分な余裕を持たせて設計されており、仮にコンタクトが1回失敗しても即座にデータを失わないだけのマージンが確保されています。

火星探査車の搭載計算機

火星探査車Curiosity(MSL)の搭載計算機(RAD750ベース)は、公表資料によれば2GBのフラッシュメモリと256MBのRAMを備えています。これは地上の民生機器と比べれば驚くほど小容量ですが、中継アーキテクチャの回で見た通り、周回機とのパスは1ソルあたり数回・合計十数分程度しかなく、しかもローバーが1ソルで生成する科学データ量自体もミッション設計段階で周回機の中継能力に見合うよう調整されているため、このオーダーの容量でも運用が成立しています。逆に言えば、マスメモリの容量設計とダウンリンク能力の設計は独立ではなく、観測計画そのものを含めた全体最適化の対象であるということです。

歴史的前史: Voyagerのテープレコーダ

半導体フラッシュメモリが実用化される以前、1970年代打ち上げのVoyager探査機は8トラックのデジタルテープレコーダ(DTR)、容量約536 Mbitを搭載していました。木星・土星のフライバイでは、探査機の自転や観測姿勢の都合上、実時間でデータを送り続けられない期間があり、このテープに一時的に記録してから後日再生・ダウンリンクするという、まさに本文で扱った「観測フェーズと通信フェーズの分離」の考え方がすでに使われていました。半世紀近く前から、深宇宙探査機は「送れない時間、どう溜めるか」という同じ問題に向き合い続けてきたのです。

演習問題

1. ある探査機が観測フェーズ(継続時間 $T_{obs}=20$ 時間、生成レート $R_{gen}=500$ kbps 一定)と通信フェーズ(継続時間 $T_{pass}=4$ 時間)を1ソルごとに繰り返す。この1サイクルでバッファを完全に空にするために必要な最低限のダウンリンクレート $R_{down}$ を求めよ。また、その際に必要となる最小バッファ容量 $C_{mem}$(Gbit単位)を求めよ。

2. New Horizonsの冥王星フライバイ後、合計16GB(=128 Gbit)のデータをダウンリンクレート1.2 kbps で送り切るのに理論上何日かかるか計算し、本文で述べた「約15か月」という実績値との差について、実際の運用でレートが一定でない要因(距離の変化、アンテナ切り替え、優先度による分割送信など)を挙げて考察せよ。

3. $k=32$ ビットのメモリワードにSEC-DED拡張Hamming符号を適用し、1ビットあたりのSEU発生率を $\lambda_{SEU}=10^{-9}$ upsets/bit/時間とする。スクラビング間隔 $T_{scrub}=24$ 時間のとき、期待アップセット数 $\mu=n\lambda_{SEU}T_{scrub}$($n$ は検査ビットを含めた全ビット数、SEC-DEDでは $n\approx40$ とする)を求め、$P(\text{uncorrectable})\approx \mu^2/2$ の近似でこのワードが訂正不能になる確率を評価せよ。またこの確率を1桁下げるには $T_{scrub}$ をどう変えればよいか論じよ。

4. あるバッファに4種類のデータセグメントがあり、(サイズ, 科学的価値)がそれぞれ A: (3GB, 9), B: (5GB, 10), C: (2GB, 5), D: (4GB, 6) だとする。バッファの残り容量が7GBしかないとき、価値密度 $v_i/s_i$ による貪欲法でどのセグメントを優先的に保持すべきか順位を求め、実際にどこまで収まるか判定せよ。さらに、この貪欲法による選択が厳密な0-1ナップサック最適解と必ずしも一致しない理由を、この例を使って説明せよ。

まとめと次回予告

マスメモリは、探査機が「データを生成できる時間」と「データを送り出せる時間」のズレを吸収する緩衝材です。この回では、そのバッファサイズを生成レートとダウンリンクレートの差の積分で見積もる方法、宇宙放射線によるビット反転にEDACとスクラビングでどう対抗するか、そして容量が逼迫したときに科学的価値の高いデータをどう優先して残すかという3つの観点から、この「蓄積」の技術を数式で追いました。前回で導入した「限られた接続時間の中でどう運用するか」という問いに対する、探査機側からの具体的な答えの1つがこれだったと言えます。

このカリキュラムも全117回のうち残りわずかとなりました。次回は視点を変え、探査機やRF機器そのものの性能を実際に「測る」計測技術——スペクトラムアナライザとVNA(ベクトルネットワークアナライザ)——を扱います。そして最終回では、これまで積み上げてきた技術を振り返りながら、DSN刷新やLunaNet、AI受信機まで含む深宇宙通信の将来ロードマップを展望し、このカリキュラム全体の締めくくりとします。

参考文献

• C. D. Edwards Jr. et al., “Relay Communications Strategies for Mars Exploration through 2020,” Acta Astronautica
• G. C. Messenger, M. S. Ash, Single Event Phenomena, Springer
• NASA/JHUAPL, New Horizons Mission Fact Sheets and Post-Encounter Data Return Status Reports
• NASA/STScI, James Webb Space Telescope Observatory Documentation(Solid State Recorder仕様)
• NASA/JPL, Mars Science Laboratory (Curiosity) Spacecraft Fact Sheet
• J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
• DSN Telecommunications Link Design Handbook, DSN No. 810-005