Mars Global Surveyor の通信途絶の真の原因はソフトウェア更新時の人為ミスか

space comp

昨年 11 月，NASA の火星探査機 Mars Global Surveyor (MGS) が突如通信を途絶した．運用中の他の探査機などを総動員して懸命の捜索が続けられたが，MGS からの通信は二度と戻らなかった．

12 月には ESA の Mars Express によって MGS らしきものがとらえられたが，姿勢を喪失していると推測され，復旧の見込みはほぼゼロとなった．当初，老朽化が原因の可能性が高いとされてきたが，ここへ来て 1/10 に NASA の調査で人為ミス説が浮上した．これに対し，Geek Counterpoint Blog というサイトで「MGS と似たアーキテクチャにかつて関わっていた人物」が MGS 関係者の話などを元に真の原因を推測している．これがまた自分にとっては非常にツボにはまった記事だった．文章はえらく長いが，英語は平明だしところどころに要点がまとまっているので，興味のある方はぜひ目を通してみてほしい．以下，ざっとまとめてみる．



NASA の John McNamee が語ったパブリックコメントによると，
  • 昨年 6 月にソフトウェア (2 台の CPU 同期用) を送信した際，アドレスが 2 箇所間違っていてメモリが上書きされた
  • 探査機は異状事態モードに移行した
  • バッテリのラジエータが太陽の方を向いてしまって過熱し，バッテリが逝った
というシナリオが推測されている．Geek Counterpoint はこのパブリックコメントは不正確であるとし，以下のただし書きのもとで自分の推測を述べている．
  • 自分は MGS に関わっていないし，かつて関わったこともないが，似たアーキテクチャを扱ったことがある．
  • NASA は現在調査委員会を招集している段階であり，したがって調査が終了しないうちは以下は全て仮説である．
  • 以下の情報の一部は過去に MGS に関わっていた友人から得たものなので，MGS 特有の話については基本的に 2 次情報である．
さて．まず MGS のアーキテクチャについて．
  • MGS の搭載電子機器は，Mars Observer (MO) という探査機のフライトモデル予備機を流用したものであり，MO は Satcom-K や DMSP / TIROS といった衛星に基づいて作られている．つまり MGS (1996 打上げ) のエレクトロニクスとソフトウェアアーキテクチャは 1980 年代初期のものである．
  • MGS に搭載されている多くのコンピュータのうち，SCP (Spacecraft Control Processor) と呼ばれる 2 台のメインコンピュータのメモリはわずか 128KB RAM であった (今時の携帯電話のメモリより遥かに少ない)．
  • SCP は Marconi 1750A マイクロプロセッサをベースとしていた．当時，国防総省は衛星ソフトウェア関連コスト削減のために 1750A の軍用規格で命令セットの仕様を定めており，当時の衛星の多くは 1750A を用いていた．その後次第に Intel *86 や IBM PowerPC などの商用アーキテクチャが国防総省や宇宙関連でも使われるようになり，1996 年以降は 1750A は使われていない．
  • 1750A のプログラミング手段としては，アセンブラ，JOVIAL (空軍特有の言語)，Ada か C，の 3 つの方法がある．MGS ではアセンブラと JOVIAL が使われていた．どちらも obsolete な言語であり，経験者を探すのが年々難しくなっている．
次に OS について．これがまたすごい．
  • Mars Pathfinder 以前の探査機は OS を積んでいない (そこまで計算資源に余裕がなかった)．よって，メモリ管理は「人間が手動で地上から」行うことになる．
  • 近年の衛星では，プログラム中の定数パラメータはオンボードのデータベースかファイルに格納されている．しかし MGS にはそもそも OS がなく，データベースもファイルシステムも存在しない．なので地上の人間が「メモリのどこにどんなパラメータが格納されているか」を常に追跡しつづけなければならない．
で，メモリ管理について．
  • MGS のメモリはワード (16 バイト) 単位でアドレシングを行うようになっている．単精度整数型は 1 ワードだが，倍精度整数型や浮動小数点型などは 2 ワード，もっと複雑なデータ型の場合はそれ以上のワード数をもってメモリ内に格納されている．
  • ここで問題になるのがビッグエンディアン/リトルエンディアンである．つまり，2 ワード以上のサイズのデータをメモリ内に格納する時，どっちのワードをどっちに格納するか? ということである．この件が今回の MGS 通信途絶に関係していたかどうかはわからないが，ともかく地上の人間がパラメータを更新する際，相当注意して作業しないと容易に混乱が起こり得る (地上系システムと衛星系システムとでエンディアンが違うことさえありうるらしい!)．
ここまでが背景．で，実際に何が起こったのか．考えられるシナリオ．
  • 2006 年夏，冗長系をなしている SCP の 1 台 (SCP-1) に問題が起こったため，バックアップである SCP-2 に切替えた．SCP-1 のメモリの内容に欠陥があったので，その後数ヵ月をかけて大量のコマンドを送信して欠陥を修復する作業が行われた．
  • この作業を行っていたのはたった一人だった．彼は 1750A や JOVIAL を扱った経験がわずか数ヵ月と浅かった．ミッション初期からずっとこの作業を行っていた人間が退職したため，彼が投入されたのだ．
  • この新人がパラメータを更新している時，2 ワードパラメータの開始アドレスをうっかり間違えた．
  • アドレスが 1 つずれたことによって，更新していたパラメータが余計に破損しただけでなく，近傍のメモリの内容も破損してしまった．その中には，異状事態モード時の太陽電池アレイの姿勢や，太陽電池アレイの機構に関するパラメータが含まれていた．
  • 2006 年夏のこのミスは数ヵ月誰にも気付かれなかった．11/5 の合運用からの復帰の際，太陽電池アレイを正しい向きに直すコマンドが送信された．この結果，一つの太陽電池アレイ機構が端まで動いた．通常はこれは全く問題ではない．しかしパラメータが破損していたため，衛星は太陽電池アレイが限界までねじれていることに気付かず，モータが故障したと判断して異状事態モードに移行した．
  • この過程で太陽がバッテリラジエータに直接当たってしまい，バッテリは過熱して破損した．他のバッテリは既に経年劣化しており，食の間に十分な電力供給をすることができなかった．
…ということだそうだ (一部，太陽電池アレイの挙動まわり，よく意味がつかめなかったけど)．どこまでが事実でどこからが推測なのか，ちょっと判然としない部分もあるけど，なんていうか，起こるべくして起こってしまったというか．ヒューマンエラーが今までなかったのが奇跡のような気もする．2006 年にもなって，地上から人間がアセンブラと独自言語でメモリ管理を行う衛星．すごいよ．



参考: Mariner 1，Mercury，Mars Climate Orbiter のソフトウェアバグ [2005-12-13]



追記 (2007-04-19): あれ，Geek Counterpoint Blog の当該記事がなくなっちゃってますね．がーんん．まさか消されたのか．



関連記事: 宇宙開発をめぐる噂の真相シリーズ