IEEE Spectrumの記事は、NASA JPLが火星探査車Curiosityをどうやって13年も動かし続けているのかを、かなり面白く掘り下げています。
まず前提として、Curiosityはただの「火星に置いてある機械」ではありません。火星の地表を走り、岩を掘り、試料を採取し、写真を撮り、科学データを地球へ送る、れっきとした移動式の研究所です。しかも地球から約2億キロメートルも離れた場所にある。
この距離感、あらためて考えると狂っています。修理に行けないどころか、電話して「ちょっと再起動してみて」で済む相手でもない。だからこそ、JPLのエンジニアは“壊れたら現地で直す”のではなく、“壊れそうなものをソフトウェアで何とかする”という発想を積み上げてきたわけです。ここが本当にすごい。
記事によれば、Curiosityは着陸以来、約37kmを走り、42個の岩石を掘削・採取し、公開時点で約76万3,000枚もの写真を撮っています。13年たってこれだけ働いているなら、もう十分どころか、正直「まだ現役なの？」と驚くレベルです。
記事の中で印象的なのは、JPLのAlexandra Holloway氏の言葉です。彼女は、長寿の理由は単に最初から頑丈に作ったからではなく、運用中もずっと努力し続けてきたからだと話しています。
これは地味だけど大事なポイントです。
ロボットや機械って、しばしば「設計時に勝負が決まる」と思われがちですが、Curiosityの例を見ると、実際には“運用で寿命を延ばす”余地がかなり大きいことがわかります。しかもその手段が、現地で工具を持って直すのではなく、慎重な software update。火星版の延命治療みたいなものです。
Curiosityの9年後輩にあたるPerseveranceは、見た目や基本構成がかなり似ています。どちらも RAD 750 processor を使い、memory も同じ量だそうです。
ただしPerseveranceには、visual odometry 用の追加processorがあります。visual odometry というのは、カメラ画像を使って「どれだけ進んだか」「どの方向へ動いたか」を推定する仕組みです。簡単に言うと、目で見ながら自分の位置を把握して自律走行しやすくする機能ですね。
ここにはミッションの違いが出ています。
Curiosityは「止まって調べる」ことが強い探査車。Perseveranceは、より長距離を効率よく走ることを重視した設計。実際、Perseveranceはわずか3年ほどでCuriosityの走行距離を超えたそうです。これは設計思想の違いが、そのまま行動の差として出ている好例だと思います。
記事のハイライトは、やはりコンピューターとmemoryの話です。
CuriosityにはAとB、2台のcomputerがあります。着陸時はAを使っていたものの、早い段階で NAND memory anomaly が起きたため、Bに切り替えたそうです。
NAND memory はデータを保存する記憶装置の一種で、身近なところだとスマホやSSDにも使われています。要するに、長く使っていると不具合が出ることがある場所です。
その後しばらくBで順調に動いていたのですが、今度はBが起動しても drive partition をマウントできない、つまり「記憶装置の中身を読み込めない」状態になってしまいました。そこで、まだ信頼できるAに戻してデータを守り、BからAへ、さらに地球へと慎重にデータ移送したそうです。
ところがAも同じように怪しくなってきた。
ここでJPLが選んだ策が本当におもしろい。Aのために確保していた memory の別の領域、しかも flight software の古いコピーが入っていた NOR memory を、ファイルシステムとして再利用したのです。
これがすごくないですか。
普通なら「予備領域にソフトを置いている」だけで安心しそうなものですが、Curiosityではその“予備”を、使えるなら使えるだけ使い切る。しかも4つあった flight software のコピーのうち古いものを捨て、その64MBをAのファイル領域に転用した。結果、Aは本来のmemoryの1%未満で動くようになったそうです。
しかもこの更新版の名前が “R-Hope”。
「うまくいってほしい」という願いがそのまま名前になっていて、なんだか泣けます。技術ってこういうところがいいんですよね。超合理的なのに、最後は祈りが混ざる。とても人間っぽいです。
Curiosityの寿命を縮める最大の要因は、まず wheel wear、つまりタイヤの摩耗です。
最初は「砂地に少し岩が混じっているくらいなら大丈夫だろう」と考えていたところ、実際にはその小さな岩が地下の大きな岩塊の先端だった。しかもそれが鋭利で、タイヤをどんどん傷つけたのだそうです。
だからCuriosityは前向きに走るだけでなく、後ろ向きに走ることも増やしました。これはかなり面白い対策です。前輪を守るために、あえて“バック走行”を使うわけです。火星でバック運転が常態化するローバー、なかなかシュールです。
ほかにも、アクチュエータの使用回数も消耗品として数えています。アクチュエータは関節や腕を動かすためのモーターのようなものです。これを使えば使うほど寿命に効いてくるので、たとえば自撮りをしばらくやめるのも、その負担を減らすため。
ロマンは少し減るけれど、探査機の長生きにはかなり現実的な判断です。
そして、最大の消耗品は電力。CuriosityはRTG、つまり放射性同位体を使った原子力電源を積んでいますが、これは時間とともに出力が落ちていきます。さらにCuriosityのRAD 750 processor は、最近の省電力系processorに比べるとかなり電気を食うそうです。
そこでJPLは、できるだけ早く作業を終えたらスリープに入り、computerやヒーターを止める運用を増やしています。加えて、通信しながら走る、腕を動かす、といった処理を並列化する工夫も進めているとのこと。
要するに、1回の起動でできるだけまとめて仕事を終わらせる方向です。これは家庭の節電でも仕事でも、けっこう共通する発想だなと思います。限られた電力を、いかにムダなく配分するか。火星でもやることは同じです。
この記事で個人的に重要だと思ったのは、Curiosityで得た教訓が、単なる延命テクニックにとどまらないことです。
Holloway氏は、将来の mission を作るなら、設計の早い段階から運用者の意見を入れるべきだと話しています。
たとえば「どの部品が、どれだけ電力を消費しているかを、もっと細かく知りたい」「そのデータをどう見せてほしいかを、設計の最初から考えたい」という意見です。
これは非常にまっとうです。
作る側は「こういうデータを取れるようにしよう」と考えがちですが、実際に毎日それを使う人は、「この情報がこの粒度でほしい」「この表示なら運用判断しやすい」と思っていることが多い。設計時にそこを詰めておかないと、あとから便利そうなデータが足りない、ということが起こる。Curiosityの経験は、その典型例を教えてくれているように見えます。
記事は途中で省略されていますが、Curiosityの長期的な未来については、かなり繊細な議論が続いているようです。特に robotic arm が使えなくなった場合、どんな science ができるのか、という話が出ていました。
これはかなり切実です。
ローバーは全部が全部、同じように壊れるわけではありません。腕が動かなくなれば接触観測や採取は難しくなる。でも、遠隔観測や移動観測など、できることは残るかもしれない。つまり「何が壊れたら何ができなくなるのか」を、あらかじめ考え続ける必要があるわけです。
火星探査機は、完成した瞬間がゴールではないんですね。むしろそこからが本番で、しかも本番の舞台は200百万キロメートル先。こういう話を読むと、宇宙開発は“派手な打ち上げ”よりも、“地味な運用の積み重ね”で支えられているんだと実感します。
Curiosityが13年も生き残っている理由は、単に丈夫だからではありません。
壊れたら別のcomputerへ切り替える、使えないmemoryを別用途に回す、タイヤを守るために後ろ向きに走る、電力を節約するためにスリープを増やす。そういう“小さな知恵”の積み重ねが、火星での長寿を支えています。
正直、これはかなり感動的です。
火星探査というと、どうしてもロケットや着陸の華々しさに目が行きますが、実際に13年も成果を出し続けているのは、地球側で毎日知恵を絞っている人たちです。Curiosityは火星を走るロボットですが、その寿命を延ばしているのは、間違いなく人間の執念と創意工夫だと思います。
参考: Curiosity’s 13 Years of Software Hacks Keeps It Alive on Mars
