火星へ行った8ビット
マーズ・パスファインダーの旅とリセットの謎

地球を離れたあとは、太陽のまわりを半周弱(155°)回って火星に追いつくタイプ1と呼ばれる航路です。7か月の間に4回、小さな噴射で軌道を修正しました(TCM)。いちばん大きかった1回目でも秒速約30m。最後の4回目は秒速1.9cmという、歩くよりずっと遅い速さの調整でした。

1997年7月4日 16時51分(世界時)、着陸機は高さ約130km、秒速7.3kmで火星の大気に突入しました。着地まではわずか5分半。そのあいだの操作はすべて着陸機のコンピュータが自分で行います。熱シールドで減速し、パラシュートを開き、20mのひもで着陸機を吊り下げ、レーダーで地面を測り、エアバッグをふくらませ、逆噴射ロケットで止まり、ひもを切って落ちる。ここから先の図は、着陸機に積まれていた加速度計と大気計測の実際の記録(NASA PDS)から描いています。

記録から分かること

減速がいちばん強いのは、突入から約114秒後の15.9g。NASA PDSの降下の時刻表にある「パラシュートを開くときの16g」とほぼ同じ値です。

着地の直前、加速度計は約3gの減速を約2.3秒記録したあと、急にほぼ0gになります。逆噴射ロケットで止まった着陸機がひもを切られ、約3.7秒間、自由落下したところです。高さ21.5mから火星の重力で落ちると約3.4秒。そのあと、最初の衝撃 18.5g が記録されています(16時56分54秒 UTC)。

記録の中には、加速度計の測る範囲を切り替えた直後の大きな値(36.6g など)があります。PDSの説明に「切り替えから1秒間は使わない」とあるため、図では除いています。

重さ10.6kg、電子レンジほどの大きさのソジャーナを動かしていたのは、Intel 80C85。1970年代に生まれた8ビットのCPU 8085を、低い電力で動くCMOSにしたものです。日本でもNECのワンボードマイコン TK-85(1980年)などで親しまれた8085の仲間が、火星を走りました。

なぜ8ビットなのか。ソフトウェアを書いたJPLの技術者は、「飛ぶものには、実績があって放射線に強い部品が必要で、電力と重さの制約がとても厳しい」と書いています。CPUとメモリを合わせたコンピュータは0.5kg、消費電力は1.5Wでした。

着陸機には、32ビットのコンピュータが1台だけ積まれていました。IBMのワークステーションRS/6000の設計をもとに、放射線に強くして1枚の基板にしたRAD6000(製造はLockheed Martin Federal Systems)です。この1台が、7か月の巡航、5分半の着陸、着陸後の運用をすべて受け持ちました。

OSはWind River社のVxWorks。複数の仕事(タスク)に優先度を付けて、優先度の高いものから先に動かす「リアルタイムOS」です。Wind Riverはこの計画のために、VxWorksをRS6000へ移植しました。

タスクと優先度

ソフト責任者のGlenn Reevesが1997年12月に書いた説明によると、問題に関わったタスクの優先度は次のとおりです。タスクどうしは、共有メモリの「情報バス」と、VxWorksのパイプでデータを受け渡していました。

着陸の翌日、7月5日に1回目のリセットが起きました。リセットすると、着陸機は安全な状態に戻って地球からの指示を待ちます。壊れはしませんが、その日の予定は消えてしまいます。

7月11日(金)の夕方には、送られてくるはずの電波が届きませんでした。低利得アンテナで呼びかけると返事があり、運用チームは「18時47分から20時47分(米国太平洋夏時間)のどこかで、コンピュータがリセットした」と判断します。7月14日の午前1時6分には、2時間の通信の途中でリセット。JPLは「どちらも、着陸機とローバーのあいだの通信が多い時間帯に起きている」と発表し、運用では仕事を1つずつ順に行う(直列化する)ことでしのぎました。7月15日、ソフト責任者のGlenn Reevesは、リセットは7月5日・10日・11日・14日の計4回と説明しています。

地上で再現する

着陸機から地上に送らせた記録(7月13日に約3MB)を手がかりに、JPLは地上にある同じ構成の試験機で、記録(トレース)を取りながら同じ動きを再現しようとしました。Reevesによると、問題を起こせるようになるまで18時間かかりませんでした。分かったのは次の流れです。

なぜ打ち上げ前に見つからなかったのか

Reevesは、打ち上げ前の試験は「データ量が多く、科学観測も盛んな、いちばん条件の良い場合」に限られていたと書いています。気象データの収集と、通信の多い時間帯がちょうど重なる組み合わせは、火星で初めて起きました。

7月17日のJPLの記者向けの発表では、飛行の責任者(フライトディレクター)のBrian Muirheadが「時間内に終わらないタスクがあり、優先度が足りなかった。命令を1つ足して優先度を上げる」と説明しています。次の章の「優先度継承」は、まさに資源を持っているあいだだけ、低いタスクの優先度を一時的に上げる仕組みです。

優先度継承(priority inheritance)は、1990年にカーネギーメロン大学のSha、Rajkumar、Lehoczkyが論文にまとめた方法です。高いタスクが資源を待ち始めたら、その資源を持っている低いタスクを一時的に同じ高さまで引き上げ、先に資源を返させます。上のシミュレーションで「優先度継承」を入れると、「中」に割り込まれていた ASI/MET が赤く上がって資源を返し、bc_dist が周期の中で終わるのが見られます。

VxWorksのミューテックスには、作るときに優先度継承を付けるかどうかを選ぶ設定がありました。ところが select() の中で使われる資源では、Wind Riverが速さのために既定で付けていなかったのです。Reevesは「付けないと決めたわけではなかった」と書いています。

修正は、select() の資源を作るときに使われる大域変数を書き換えて、優先度継承を付けるようにすることでした。書き換えたあとに作られる資源から効きます。地上の試験機で十分に確かめてから、機上のソフトと新しいソフトの差分を火星へ送りました。よく「着陸機のC言語のインタプリタ(VxWorksのシェル)に打ち込んで直した」と紹介されますが、Reeves本人は「シェルは使っていない」と書いています。

パスファインダーのあとも、火星のローバーは耐放射線のCPUとVxWorksで動き続けています。2004年には、スピリットが着陸18 sol目にフラッシュメモリのファイルが増えすぎてリセットをくり返し、地上から「フラッシュを使わずに起動する」命令を送り、不要なファイルを消してフラッシュを初期化して立ち直りました。ここでも、遠く離れたコンピュータを地上から直しています。

次の世代として、NASAはRISC-Vの多コアのチップ(HPSC、Microchip社のPIC64-HPSC)を開発しています。2026年5月のJPLの発表では、試験の初期の結果で「いま使っている耐放射線チップの500倍の性能」が出ています。8ビットの80C85から数えると、30年で処理の速さは何万倍にもなりました。それでも、遠くのコンピュータが止まったときに地上から原因を探して直す、という仕事の形はパスファインダーのときと変わっていません。