宇宙航空研究開発機構（JAXA)のX線天文衛星「ひとみ」喪失事故に関する解説の2回目となる今回は、「ひとみ」の開発から運用にかけての、組織的な問題を見ていくことにする。
設計者はリスクを知っていた
前回の解説で、「ひとみ」は天文衛星としての観測能力を高めるため、いろいろな点で性能を優先した余裕のない設計をしていたことを指摘した。しかし当然のことだが、そのような設計をした当人は、それがリスクになることを誰よりも知っている。
「ひとみ」が最初に姿勢を乱したのは、衛星の姿勢を測定するセンサー「スタートラッカ（STT）」が不意にリセットしてしまったことだった。しかも、そのときに過剰な姿勢修正をしてしまい、STT復帰後に誤差が大きくなったことを検出したソフトウェアは、STTが故障したと判定。予備のSTTに切り替えると姿勢が変動して観測に差し支えることから、切り替えは行わないようになっていた。
このような設計では、一度STTが故障と判定されると自動では切り替えも復帰もしない。そこで「ひとみ」の姿勢制御システムの設計担当者は、STTが故障と判定された状態が続いた場合は地上からの監視で、手動で対応することにした。
運用でカバーするはずが、していなかった
ところが、この運用上の引き継ぎは徹底されなかった。まず、STTの故障判定が続いた場合は自動的に警報を出す機能が検討されたが、実装されることはなかった。その一方で、運用担当者が監視するという申し送りも行われなかった。つまり、性能を上げる代わりに監視が必要という考えで設計されたにもかかわらず、その監視を誰もしていなかったのだ。
今回の事故は、20時間もの間「ひとみ」が日本の地上アンテナと通信できない、そのタイミングで起きてしまった。しかし実際にはこの間にも、オーストラリアやスペインの地上アンテナ付近を通るときに「ひとみ」の現在の状態データだけを送信しており、そのデータは日本の運用システムにも送られて記録されていた。これまでの経緯を考えれば、このデータをチェックしてSTTの状態を確認するべきだったのだが、運用担当者はそれを知らされていなかったのである。
最後の砦、セーフホールドモードに失敗
こうして姿勢が乱れた「ひとみ」は、搭載ソフトウェアによる姿勢制御ができなくなっていく。通常「ひとみ」は内蔵されたコマのような「リアクションホイール（RW）」を回転させることで姿勢を変えるのだが、ソフトが推定した姿勢と実際の姿勢の関係がデタラメになってしまったため、RWの姿勢制御能力が限界を迎えた。
こうなった場合、姿勢制御システムはそれまでの制御をやめ、別のシステムに切り替わる。スラスター（小型ロケット）を使って衛星の向きを直し、とりあえず衛星の電池が切れないようバッテリーを太陽へ向ける「セーフホールドモード」だ。「どうすれば良いかわからなくなってしまいました、助けて下さい」とSOSを発信し、地上からの操作を待つ。
ところがこのセーフホールドモードで「ひとみ」は、自ら回転をどんどん速めて、最後は太陽電池パネルが根元から折れてしまうという最悪の結果に至ってしまった。その原因は、単純な数値の転記ミスだったことがわかった。
スラスターを使った姿勢制御
「ひとみ」は通常の運用では、スラスターを使用しない。最初に使用するのは、H-IIAロケットで宇宙へ運ばれ、分離したあとだ。分離直後はいわば「放り出された」ようなものだから、衛星は回転している。それを止めるためにスラスターを使用する。
そのあと「ひとみ」は「伸展式光学ベンチ（EOB）」という長いしっぽのような物を伸ばす。一般的な望遠鏡や望遠レンズも使用するときに「筒を伸ばす」ことがあるが、X線という特殊な天体観測でも原理は同じことで、ロケットに収まるよう小さく畳んだ状態からX線望遠鏡を伸ばす操作をしたのだ。
さて、物体は長くなるほど、回転させにくくなる。そのため「ひとみ」では、EOBを伸ばした後に姿勢制御システムの調整が必要になった。ある速度で回転させるにはどのスラスターを何秒間噴射すれば良いか、を定めた「姿勢制御パラメタ」の調整だ。これは初期設定のようなもので、一度設定してしまえば基本的には変える必要はないので、実際に設定するのは打ち上げ前とEOB伸展後ぐらいだ。
「言われなければわからない」致命的な引き継ぎミス
パラメータの変更手順はこうだ。まず、パラメータの計算ツールを使って必要な数値を算出する。次に、数値をシミュレータに設定して、正しく動作することを確認する。確認できたら、数値を「ひとみ」のメモリーに書き込む。打ち上げ前なら直接書き込めるが、打ち上げ後の書き換えでは数値ファイルを送信システムにセットして、書き換え命令を送ることになる。
パラメータの設定を行っていたのは運用を委託された運用支援業者だったが、作業を行ったのは打ち上げ前の作業者とは別人で、今回が初めてだった。ここで2つの致命的ミスが起きる。
ひとつは、パラメータも計算ツールが算出した数値は、算出結果がプラスであってもマイナスであっても「ひとみ」に書き込むときにはプラスにしなければならない、という重要なことが引き継がれていなかったことだ。たとえば「3,-5,2」という数値だったら「3,5,2」と入力しろというのだ。これは、言われなければわかるはずがないだろう。実際に作業した担当者は、そのことを知らずにそのまま入力してしまった。
止めるつもりが加速、アクロバット並みの回転で破壊
「ひとみ」のコンピューターは、マイナスの数値を「逆向きの操作」と解釈するように作られていたため、結果として指示とは逆の操作をするように設定されてしまった。「車が左へそれたら、ハンドルを右へマイナス10度切れ」と書いてあったら、コンピューターは律儀に左へハンドルを切ってしまうわけだ。
本来とは逆の動作をプログラミングされた「ひとみ」は、回転を止めようとすればするほど回転を速めてしまい、EOBや太陽電池が千切れて機能喪失したと考えられる。太陽電池の強度から逆算すると、「ひとみ」は2、3秒で1回という高速回転に陥ったと思われる。「ひとみ」は全長13mで、「ブルーインパルス」のT-4ジェット機とほぼ同じ大きさだ。それが3秒以下で回転するというのだから、アクロバット機でもない「ひとみ」が耐えられるはずはなかった。
手順書も入力エラー判定もなし
もうひとつは、運用支援業者によるシミュレーションが不充分だったことだ。シミュレーションをしていれば「ひとみ」に送信する前に気付いていたはずだが、このパラメータ変更作業の手順書が不充分だった。運用支援業者は口頭指示で作業を行い、ミスに気付かなかった。
姿勢制御システムのパラメータ設定は、打ち上げ前とEOB伸展後ぐらいしか行わない。何度も繰り返し行う作業なら丁寧に作業手順書を作ったり、「マイナスの数値はプラスに直せ」などという単純なルールであれば入力ミスを検知してエラー返すようなソフトを作っておくだろう。しかし1回しかしない作業では、そこまで手を掛けるのが億劫なのもわからないでもない。だが、このたった1回の作業を明確に文書化しておかなかったことが、「ひとみ」の最後の安全策だったはずのセーフホールドモードを失敗させてしまった。
これらのミスは運用支援業者によるミスだが、作業の重要性を考えるとJAXAから作業手順の確認や文書化の指示といった管理が不足していたと言わざるを得ないだろう。
裏目に出た「ISAS流」
このように「ひとみ」の開発過程では、初めは綿密な検討が行われていたものの、課題が正しく引き継がれず未解決のままだったり、委託先に必要な指示が出されていなかったという問題点がいくつも報告された。報告書では、宇宙科学研究所（ISAS）でもJAXA全体の文書管理や品質記録の規定を順守するよう求めている。逆に言えば、「ひとみ」の開発ではJAXA全体の規定が守られていなかったということだ。また「記述が偏っており、より良い観測条 件を確保する要求は詳細である一方、安全・信頼性に関する要求が少なく」とも指摘されており、前回の記事でも述べたようにより高度な目標を達成しようとする一方で、安全管理は運用支援業者任せになりがちだったことが伺える。
ISASは、JAXAの母体となった宇宙3機関のひとつだ。残り2つ、宇宙開発事業団（NASDA）と航空宇宙技術研究所（NAL）と異なり、現在もその名称をそのまま引き継いでいる点など、JAXAの中でも独自性を保ってきた。そういった「ISAS流」は良いところも多々あるが、今回の「ひとみ」では次々に裏目に出てしまったと、常田佐久ISAS所長も指摘している。
次回はISASの特殊性についてさらに考えていく。
Image Credit: 池下章裕、JAXA
