ひとみに何が起きたのか

ひとみとの通信が途絶したのは3月26日。かに星雲を観測していたひとみは、3時1分から姿勢変更を行い、活動銀河核の観測に移行していたところだった。内之浦局と最後に通信できたのは3時2分。その後、5時49分、7時31分、9時52分と、海外局で3回の通信を行ったものの、16時40分の通信に失敗。ここで異常が明らかになった。

異常発生前後のひとみの状態。直前に姿勢変更を行っていた

その後に実施した地上からの光学/レーダー観測により、ひとみが高速に回転しており、いくつかのパーツが分離した状態であることはほぼ確実だ。破片の軌道から逆算して、分離は10時42分前後に起きたと見られる。ひとみは構造的に、1周3秒程度の高速回転(20rpm)で一部が分離する可能性があることが分かっている。

JSpOCの観測では、軌道上に11物体が見つかっている

3時2分の段階で、衛星の状態は正常だった。それから半日もしない間に、どうして衛星が壊れるほどの高速回転になったのか。宇宙航空研究開発機構(JAXA)のこれまでの解析では、衛星の姿勢制御系において、以下に述べる3つの異常事態が連鎖的に起きたらしいということが分かってきている。

(事象1)姿勢決定の異常

ひとみはIRUとSTTを使い、現在の姿勢を推定する。ひとみは3時1分~3時22分に姿勢変更を実施。ちょうど3時20分~4時0分はSTTの地蝕だったため、STTは待機モードになっていたが、IRUの補正を行うために、4時9分に立ち上げて(補足モード)、4時10分頃よりデータの出力を開始(追尾モード)したと見られる。

IRUの出力には必ず誤差があるため、その誤差を推定しておいて、誤差を補正する方法がとられている。たとえば、静止した状態ならIRUの出力は0のはずだが、実際にはバイアスが乗って完全に0にはならない。IRUの出力値から誤差推定値を引いておけば、より正しい角速度が分かる、というわけだ。

姿勢変更を行った後は、IRUの誤差は大きくなる傾向がある。4時10分頃にSTTの計測値(=実際の姿勢)が届き始めると、誤差推定値も計算上、一時的に大きくなったが、この動き自体は正常だ。ただ、通常は時間が経過するとすぐ収束するはずだったのに、今回は直後にSTTがリセットするという、想定外の事象が起きたようだ。

STTの出力が止まってしまったせいで、IRUの誤差推定値は更新がストップ。Z軸では21.7deg/hという大きな値が保持され続けた。STTは4時14分頃には出力を再開したとみられるが、すでに誤差が蓄積されており、IRUによる姿勢値と、STTによる姿勢値の差が大きくなっていた。

Z軸の誤差推定値が21.7deg/hのまま保持されてしまった(赤線)

ひとみでは、両者の差が1degを超えていた場合、IRUの方を優先するようになっており、STTの値は棄却され続けたという。この結果、実際に衛星は回転しておらず、IRUが計測していた角速度も0に近かったと思われるが、誤差推定値の分だけ衛星が回転していると思い込んでしまい、リアクションホイールを制御、衛星が回転を始めた。

結果的には、IRUとSTTの姿勢値が違ったとき、「IRUが正しい」と判断したことが誤りであったわけだが、このようなケースで、どちらが正しいのか、衛星が自律的に判断するのは簡単なことではない。今回とは逆に、STTの方が間違える場合もあるだろう。故障などさまざまな状況が考えられ、あらゆるケースで正しく判断するのはかなり難しい。

なお今回のように、一度STTの姿勢値が棄却され始めると、いつまでたっても正常な状況に戻らないように思えるが、こうした場合には、地上側で判断。衛星が日本上空に来て、内之浦局と通信できるようになったときに、コマンドを送って手動で復旧させるような運用が想定されていたようだ。

(事象2)アンローディングの異常

最初の異常により、衛星のZ軸まわりの回転が始まってしまったわけだが、回転速度は1時間に20deg程度というゆっくりしたもので、このままなら衛星が壊れることはなかった。しかし、ここで起きたのが2つめの異常。アンローディングが正常に機能しなかったのだ。

地球近傍では、重力傾斜による外乱トルクが大きく働く。この重力傾斜は、ひとみのように細長い物体に対しては、直立させるような力となる。しかし、ひとみは姿勢を維持しなければならないから、リアクションホイールで外乱トルクに対抗。結果として、リアクションホイールの回転数が上昇していく。

通常の運用では、回転数が上がりすぎないように、アンローディングを常時行っている。ところがこのときは、アンローディングが正常に機能せず、最後の通信時(9時52分)には、蓄積された角運動量が112Nmsに達していたことが分かっている。これは、制限値である120Nmsにかなり近い値だ。

なぜ正常にアンローディングが機能しなかったのか、詳しい状況はまだ不明だが、姿勢異常で衛星が回転していたことが関係していると考えられる。IRUによる姿勢値をもとに磁気トルカを制御していたとしたら、実際の姿勢はそれとは数10~100degレベルで違っていたわけで、逆効果になってた可能性もある。

最後に通信できた9時52分の時点で、太陽電池に光が当たらないほど回転していた

(事象3)セーフホールドモードの異常

リアクションホイールの角運動量が制限値を超えた場合、ひとみはセーフホールドモードに移行するよう設計されていた。リアクションホイールの制御でセーフホールドモードに移行するケースもあるが、今回はそもそもリアクションホイールが原因なので、RCSを使って行われたはずだ(スラスタセーフホールドモード)。

スラスタセーフホールドモードでは、太陽センサーで太陽の方角を検出し、太陽電池をそちらに向けるよう、噴射が行われる。ところが、事後の検証により、スラスタを制御するパラメータが適切な値ではなかったことが明らかになっている。間違ったパラメータ設定のせいで、回転が加速したと見られる。

正常なセーフホールドモード(左)と、今回の異常時(右)

RCSを使った太陽捕捉制御は、2月17日の打ち上げ直後にも実施されている。このときは正常に行われたのだが、その後、観測用の伸展式光学ベンチなどを展開したことで質量バランスが変化しており、2月28日に制御パラメータを再設定したという。RCSは基本的にほとんど使わないため、2月28日以降、RCSの噴射は一度も行われていなかった。

ひとみにとって、致命傷になったのはこのミスだった。セーフホールドモードでは、IRUやSTTは使わず、太陽センサーのみを使って制御する。最初の2つの事象が起きたとしても、RCSの制御パラメータさえ正しく設定されていれば、無事にセーフホールドモードに移行できていた可能性は高いと思われる。

この制御パラメータについては、送信時のエラーのようなものではなく、作成したデータそのものが間違っていたことが分かっている。どの段階でミスが混入したのか、詳細については調査中とのことだが、送信前の検証が十分だったのかは、疑問が残るところだ。