　だがこの太陽センサーは、太陽の方向が分かるのは20度までであるものの、太陽の有無だけなら、41度まで検出することができた。この機能を使えば、41度以上ズレた時点で姿勢異常と判断できる。また、もっと計測範囲が広い太陽センサーを使うという方法もあっただろう。しかし、どちらの方法も採用されることはなかった。

　もし太陽センサーが姿勢異常の判断に使われていれば、より早い段階でセーフホールドモードに移行していたはずだ。ひとみは今回、スラスターでセーフホールドモードに移行しようとしたときに事故を起こしたが、この段階であれば、まだリアクションホイールが使えた。これなら正常にセーフホールドモードに移行できた可能性が高い。

異常2の動作遷移図。異常を検出できず事故へとつながった

なぜ間違ったパラメータが送られたのか

　そして致命傷となった3つ目の異常は、セーフホールドモードへの移行時に、スラスターが回転を加速し続けたことだ。各スラスターの噴射時間を計算するためには、「RCS駆動マトリクス」という行列が用いられる。このパラメータは地上で計算し、それから衛星に送るのだが、この作業でミスが起き、間違ったパラメータを送っていた。

　しかし、人間でも機械でも、ミスは起こり得るもの。当然、間違えてもそれを検出する仕組みがあり、ひとみの運用でも姿勢制御系シミュレーターで確認することになっていたのだが、運用支援業者の担当者はこれを実施しなかった。またJAXA側の担当者も、実施を確認していなかった。

今回の事故では、データ入力ミスと検証漏れという、2つのミスが重なった

　ひとみは打ち上げ後に、伸展式光学ベンチ（EOB）という大きな構造の展開があり、質量バランスが変わる。そのため、展開前と展開後では、別々のRCS駆動マトリクスが必要になるわけだ。今回のミスは、EOB展開後の新しいRCS駆動マトリクスを作成したときに起きた。

　EOB展開前のパラメータについては、手順通り検証が行われており、問題は無かった。しかし、打ち上げ後のパラメータ変更運用については、事前の運用計画から漏れており、文書に明確な記述がなかった。そのため、JAXA/運用支援業者の間で詳細が共有されておらず、当日の業務も混乱。作業指示が曖昧となったという。

　また、パラメータの生成には2つのツールが使われ、そのツール間のデータ入力でミスが起きたのだが、このツールは開発者が使う開発ツールであり、運用ツールにはなっていなかった。そのため手順書はなく、当日の作業担当者も本番で使うのは初めてだった。数値のマイナスをプラスに直す必要があることも知らなかった。

　JAXAによれば事前の運用訓練は、打ち上げ当日、クリティカルフェーズ初日、定常運用のみに集中しており、「幅広い目配りが不足していた」という。衛星が大規模化し、運用も複雑で高度になってきており、運用準備には十分な時間をかける必要があったが、それができていなかった。

事故が起きたのは初期機能確認フェーズ。打ち上げからわずか1カ月だった

　今回の事故を見て分かるように、スラスターの制御パラメータというのは、本来、非常にクリティカルな要素である。それを変更する重大な運用であるのに、ずさんすぎたと言うほかない。

　EOB展開後のパラメータについては、打ち上げ前に衛星側へ搭載しておいて、展開後に切り替えるだけにする方法もあった。ひとみでは、最新のスラスター推力の値を元に再計算していたが、初期機能確認フェーズはただでさえ作業が多くて忙しい。事前に用意しておけば、効率は多少落ちるものの、作業リスクを減らすことができる。

問題の本質はどこにあったのか

　今回の事故については発生した事象がかなり詳しく分かっており、同じ原因での再発の防止はそれほど難しくはない。しかし、問題の本質はそこではない。今回の事故で明らかになったのは、ISASという組織の体質にも問題があったということだ。これに手を付けず、パッチ当ての対策をしたところで、いずれまた別の形で失敗を繰り返すだろう。

　次回は、今後の対策について焦点を当てたい。