★第５拡張★ はやぶさ２の隠れ機能？＃２
皆さんこんにちは！第５拡張です！
前回、「次回をお楽しみに」で終わってしまい、本当に楽しみにお待ちいただいているようで大変ありがたいです。そして、そんな皆さんのご期待に応えたいのに、また遅めの更新で申し訳ないと思いつつ、少しでも早めに投稿しようという筆者の心模様で今に至ります。
さて、前回に引き続き今回も、はやぶさ２の隠れ機能（＃２）という、気になるワードについて、お話ししていきたいと思います。今回の隠れ機能は、ズバリ「AOCS（姿勢軌道制御系）ソフトウェアの書き換え機能」です！
「え？ソフトウェアの書換え機能って、そんなにもったいぶるほどすごいもの？」と思われた方も、今の時代では少なくないでしょう。かく言う私自身もスマホやPCのソフウェアアップデートなんて、日常茶飯事ですし、珍しいものでも何でもありません。
しかし、探査機の、特に姿勢軌道制御系のソフトウェアアップデートは、そう簡単なものではないのです。それはやはり「ソフトウェア更新失敗時のリスク」に起因するものでしょう。
今回、ソフトウェアの書き換えを行なったAOCS（姿勢軌道制御系）というのは、その名の通り、探査機の姿勢や軌道の制御を司る機能を持ち合わせたサブシステムです。もし何の工夫も無しに、このAOCSソフトウェアを書き込み始めて、
その最中に通信が途絶えたり、予期せぬ事態で更新を中断せざるを得ない状況に陥ってしまうと、AOCSのソフトウェアがまともに動かなくなり、姿勢制御が機能しなくなります。
探査機の姿勢が制御できなくなってしまうと、通信をするためにアンテナを地球の方向に指向させることも、太陽電池パドルを太陽方向に向けておくこともできませんよね。発電が出来ないと、探査機はバッテリモードに切り替わり、そのバッテリが落ちると、もちろん探査機全体の電源がOFFとなります。また、通信を確立できないと、地上からの指令が届かず、ライフラインが絶たれてしまうような状況になってしまうのです。
その他にも、探査機の想定していない箇所に太陽光が当たって熱制御が破綻するというようなリスクもあります。AOCSソフトウェアの書換え、、、恐るべし…。
また、ここでは、運用上のリスクを挙げましたが、正しく書換えを実施できたとしても、そもそもソフトウェア自体に変なミスが入ってしまっていたら、一巻の終わりなので、地上でのソフトウェア検証も多くの労力と時間を割いて実施しています。これほどリスクが高い運用、かつ地上検証のために時間も労力もかかることなので、これまでもおいそれと書換えを行うことはできていませんでした。ただ、拡張ミッションに移って、さまざまな機器が設計寿命を超えて、いつ壊れてもおかしく無い状況を踏まえ、
機器が正常なうちに、姿勢制御のバックアップ機能を新しく付加するため、AOCSソフトウェアの開発・書換えという新しい一歩を踏み出すことにしたのです。
さあ、それでは、いつも通り前置きがだいぶ長くなってしまいましたが（笑）、いよいよ本題のAOCSソフトウェアの書換えの仕組みと、運用の詳細についてご紹介したいと思います！
上述したように、AOCSのソフトウェアを使えない状態にしてしまうのは、ほとんど自殺行為に近いので、動作中のAOCSソフトウェアに直接新しいものを上書きしてしまわないような工夫をしています。はやぶさ２のAOCSのプロセッサユニットの中には、RAM（Random Access Memory：揮発性メモリ）とEEPROM（Electrically Erasable Programmable Read-Only Memory：不揮発性メモリの一種）という二つの記憶領域が用意されています。地上から送信されるソフトウェアは、図1の上の図に示されるように、まずはEEPROMに書き込まれます。EEPROMに書き込まれたソフトウェアは、プロセッサを再立ち上げすることでRAMに展開され、RAMに書き込まれたソフトウェアが実際にAOCSのソフトウェアとして機能しています。 この仕組みにより、RAMに書き込まれたAOCSソフトウェアが現在進行形で姿勢制御を行いつつ、裏でEEPROMに対して新ソフトウェアを書き込むことが可能になります。
図1 AOCSソフトウェアの書込み時とプロセッサリセット時のイメージ図
仮にEEPROMに新ソフトウェアを書き込んでいる途中で、一旦中断せざるを得ないことになっても、RAM側のソフトウェアの方は再立ち上げをしない限りそのまま動いてくれているので、中断したところから改めてEEPROMに書き込みを実施することも可能です。 そして、ひとたび新ソフトウェアを全てEEPROMに書き込むことが出来れば、あとは図１の下の図のように、プロセッサをリセットしてEEPROM→RAMへと新ソフトウェアを展開させれば、めでたく新AOCSソフトウェアでの動作が開始される、ということになるわけですね！
ところで皆さん、お気付きでしょうか？
そう、前回お楽しみにさせてしまった、WSHの軌道上検証がなぜ行われたかについて、ここまで一切触れられていないことに！(汗)
上の話の中で、「プロセッサをリセットして」とか「ソフトウェアを再立ち上げして」という一文がさらっと出てきています。実は、プロセッサをリセットして、ソフトウェアを再立ち上げする際には、一旦AOCSの機能全体が初期化され、セーフホールドモードに移行するという仕様になっています。これは、打上げ直後や、プロセッサに何か問題が起こってリセットされるような場合に、探査機が速やかに安全な姿勢に移行できるようにと組み込まれているものです。従来、どういった異常ケースにでも出来るだけ対応ができるようにと、RCS（化学燃料スラスタ）を使ったセーフホールド（RCSセーフホールド）に入れて探査機の安全を確保するという思想でここまでやってきました。しかし、今回のソフトウェア書き換えは、特に異常ケースに対応するというわけではなく、わざとプロセッサのリセットを行って、セーフホールドモードに移行させようとしているわけです。このような時に、安定的に三軸姿勢制御を維持できている状態から、リセットすることでRSHモードに移行してわざわざスピンまでさせた上で（RSHモードに入れると自動的にスピン状態まで行ってしまうので）、
最後にまた三軸姿勢制御まで戻す、という運用上の手間や燃料消費のことを考えると、あまりにも勿体なさ過ぎるわけです。。。（涙）※
- ※ どのくらい勿体無いかを考えてみると…。一旦RCSのセーフホールドモードに入れて、また三軸姿勢制御に戻すのに想定している燃料を、普段行っているリアクションホイールのアンローディングの回数に換算すると、なんとアンローディング約1年分の燃料消費量となってしまうのです！！これから先、まだ10年近い運用を継続することを考えると、できるだけ節約しておきたいですよね！（仮にアンローディング1年分の燃料を消費したとしても、拡張ミッション全体の燃料としては問題になるレベルにはならないのでご安心を）
ここで白羽の矢が立ったのが、ここまで10年近く沈黙を守ってきた隠し機能WSH（ホイールセーフホールド）ということなのですね！！前回の日誌を読み返していただくと分かりますが、 WSHはリアクションホイールで三軸制御を維持したまま、太陽指向の制御を行うというものです。プロセッサのリセットを行う際、RSHではなく、WSHに移行する設定にしておけば、無駄に燃料を消費することもなければ、わざわざ三軸制御→スピン制御(RSH)→三軸制御という遠回りな運用をする必要も無く、三軸制御（定常）→三軸制御（WSH）→三軸制御（定常）というように、元の三軸姿勢維持の状態まで戻すことができるのです（図２）。こうして、燃料節約が至上命題となっている拡張ミッションにおいては、WSHを使用することの優位性が出てきたわけです。
図2 元々想定していたソフトウェア書換え運用と今回行なった運用との違い
このように良いことづくめのWSHモードを積極的に使ったソフトウェア書換え運用ではあったのですが、
WSHそのものを使用したことが無いという状況だったので、一旦まずはWSHを使ってみようという検証のための運用が前回の話でした。（ようやく伏線を回収できましたね ﾌｩ）
ともあれ、このWSHモードの活躍により、第二の隠し機能となっていた、AOCSソフトウェアのアップデートも無事に終了し、はやぶさ２はおよそ10年ぶりに書き変わった新たなAOCSソフトウェアで、現在も正常動作しています！(ﾟ∇ﾟﾉﾉ"☆ﾊﾟﾁﾊﾟﾁ
いやー、本当に感慨深いです。皆さんは10年前何していましたか？
今回はAOCSソフトウェアの更新について長々とお話しさせていただきました。
次回は、このAOCSソフトウェアの更新で新しく追加された、姿勢制御機能についてお話ししたいと思います！次も、、、頑張ります…。
2024.4.24 三桝裕也