Ｈ３ロケット二段目ロケットの冗長化に伴う再起動・リトライを追ってみる
注意！！！
このシリーズは、Ｈ３ロケットの初回ミッション失敗に伴い、いくつかの情報が開示されたこと、有識者会合でのリトライは出来なかったのか？という質問があったことから、ロケットのロの字も分かってないWebプログラマが自分の情報整理を含めて、開示された情報から冗長化とリトライについて追ってみる、と言うモノです。なので憶測ばかりで真実ではないし、邪推などなどあるので、全面的にファンタジーなフィクションだと思って読んでください。
別にあれが悪い、これが悪いということを論じたい訳でなく、情報整理と憶測の羅列ということを忘れてはいけない。
あときっと分かりにくいし、専門的な事はさっぱりである。
今回のお題
→ Ｈ３ロケット二段目ロケットの冗長化に伴う再起動・リトライを追ってみる。
・結論
JAXAの方も言っていたけど、地上から出来ることは指令破壊をすることだけなので、手動リトライは無理。
・冗長化と可用性
冗長化（じょうちょうか）とは、システムの一部に何らかの障害が発生した場合に備えて、障害発生後でもシステム全体の機能を維持し続けられるように、予備装置を平常時からバックアップとして配置し運用しておくこと。冗長化によって得られる安全性は冗長性と呼ばれ、英語ではリダンダンシー（英: redundancy）と呼ぶ。
(https://ja.m.wikipedia.org/wiki/冗長化 より抜粋)
バックアップと何が違うんだ？と思うかもしれないけども、バックアップは冗長化の手段の一つということ。説明文にあるしね。
ただバックアップと言うと、データとかを本体ファイルとは別のところに移しておくとか考えると思うので、ロケットのバックアップとは？となってしまうので分かりにくいな、と。
身近で分かりやすいのは、電気の冗長化だと思われる。
もし電線が切れても停電するのは一部だけ（なんなら停電しない場合もある）で、大部分は停電しない。
これは家に来てる電線が冗長化されていて、別ルートで電気が届くからだ。
今回のＨ３ロケットも電源を冗長化しているけど、これと全く同じ事だと思う。たぶんきっと、暴論かも？
可用性（かようせい、英: availability; アベイラビリティ）とは、システムが継続して稼働できる度合いや能力のこと。
(https://ja.m.wikipedia.org/wiki/可用性 より抜粋)
更に聞き慣れない言葉だし、Ｈ３ロケットの有識者会合でも出てこなかった言葉だと思うのだけど、皆が言ってるリトライはこっちの話。
知ってる範囲では％で表されることが多いので、ここで％で表示となる予定。
・365日24時間フルサポート！ → 可用性は100％
・365日7時〜23時まで開店！ → 可用性は約67％(23-7)/24
くらいに考えて貰って良いです。
もっと考慮する要素もあるんだけども、少なくともここではこれでいいです。
可用性と冗長化
高可用性を維持する方法として冗長化する。というのがWebのサーバサイドのお仕事では普通なのだが、どういうことなのかはよくわからないと思うので、上の365日24時間フルサポート！を例に説明しようと思う。
登場人物
・お客さんＡ
・お客さんＢ
・サポートセンターＣ
・サポートセンターＤ
ケース1 サポートセンターに一人しかいない。
Ａさん電話、Ｃさん取る。
Ｂさん電話、Ｃさん取れない
結果 Ｂさん、フルサポートじゃないじゃないか！！とクレーム。
じゃあ人を増やせばいいじゃない。
ケース2 サポートセンターに二人いる。
Ａさん電話、Ｃさん取る。
Ｂさん電話、Ｄさん取る。
結果 Ｃさん、Ｄさんがブラック企業は嫌だ！休みがほしい！！
じゃあシフト制にしようetc.etc.
人を増やす＝冗長化
シフト制にする＝冗長化
冗長化することにより、可用性を高めますよ。ということ。
・Ｈ３ロケット二段目の冗長構成
まずＨ３ロケットの電気部分については冗長化されている。
これはJAXAの人も言ってたけども民生品を使っているが、宇宙での活動実績がない（今回初フライトだから当然なんだけど）ということは言ってたと思うけども、恐らく念のための冗長化だったと思う。実績を積んだら冗長構成ではなくすかもしれないけど、設計思想によるので今回の話からは除外。情報が手に入ったらまたそのときに。
開示されてる資料から分かることは、エンジン部のシステムは一つしかなく、電源から各エンジン部への指令系統と電力系統が２構成になっているということと、Ｈ２Ａとの比較資料からエンジンの制御系の電力系のラインは元から冗長構成となっていることが分かる。
・制御系のボックスが一つ。あれ、冗長化したのでは？？
資料から制御系が一つのボックスにあって、冗長化してないように見えるが、見方で変わると思われる。一つの場所に置くとその場所が燃えたりすると失ってしまうが、冗長化手段はいくつかあるため、これが設計的なのか、エンジン部の制御系の設計思想であるのか分からない。だがこれも冗長化してると言えるので、該当箇所の故障リスク以外は問題はないと思う。
・テレメトリから分かること
テレメトリは公式動画で公開されている範囲だと速度と高度だったかと思う。二段目が着火しなかった事はテレメトリの速度が２段目着火であれば増えるところが増えなかったことから判断したのだと思われるが、どう判断したのは公開されていない。
また今回追加で公開されたのは機器ＢＩＴと呼ばれる情報や信号の情報、電圧系である。
２系統両方のテレメトリが取得されていることから、どちらも電力が供給されていることがわかる。機器ＢＩＴ異常検知後、システムＡの電圧が検知できないのは、電力を供給を止めたからとも言っているため、正常動作と言える。
またシステムＢでも電圧が下がっている事から、同一の原因から電力を遮断し始めたモノと推測でき、正常動作だろう。
・構成とテレメトリで何が分かるのか？
追加公開されたテレメトリは極短時間の情報だけである。微々たる事しか分からない。分からないが、分かることもある。
まず、冗長化されたシステムはホットスタンバイ。つまりどちらも起動している状態でフライトしていたということ。
冗長化する上でこれは非常に悩ましい問題で、起動状態だとどちらの電池も消費していく。コスト面という意味では、コールドスタンバイのほうが良い。勿論高速でフェールオーバーできないというデメリットを抱えるため、ホットスタンバイであることは明白ではあるが。
次にエラー時の挙動が分かる。エラーが起きたためにフェールオーバー(冗長構成のBルートに処理権限を移譲する。)が起きたのは確実で、このあとAルートはテレメトリの情報が得れなくなっている。個人的なことを言えば、エンジンの制御システムへの電力供給は正常であるはずなので情報だけでも得て居ても良いと思うが、遮断されてる事からルートＡの電源自体を落としてる可能性が高い。
・リトライは出来なかったのか？
エラー原因やエラー内容にもよるが、地上からの指示でリトライは不可能(JAXAの人も言ってたが出来るのは司令破壊だけ。ただ技術的には可能だがセキュリティ的に問題があり、実装していない。)と見るのが良いと思う。
・指令破壊までの時間
２段目エンジンの着火がされなかったのは、速度が上がるべきところが下がり始めたので、ほぼ確定だったと思う。
だが司令破壊までの時間は割と長く、到達する見込みが無いから司令破壊したというアナウンスになっていた。
この期間、当然どういうことなのかとか色々と調べていたと思うが、時間にして約400秒程度だったはずである。
400秒。システムが再起動するには十分な時間だ。
自分がプログラムを組むならメモリの許す範囲で、再起動か再着火プログラムを実装しておくと思う。
Ｈ３ロケットの２段目エンジンには再燃焼試験も組まれてはずで、これを利用して万が一のために仕込んでおくと思うのだ。
この期間、実はシステム的にリトライが実行されていたが、再起動、２段目エンジン着火信号、再エラー。までを確認していた。とかあるとなかなか面白いかもしれない。まぁただの妄想なのだが。
・リトライ
ここまで割と余計な話をしていたが、ホットスタンバイの再起動、再接続はかなり難しい。AWSのスケーリングやECSを使っていたりすれば分かると思うが、スケーリングなどで可用性は維持されるが、インスタンス数が正常に戻るまでの時間は出来てしまう。この時間はロケット関連においては致命的な時間だろう。
冗長化を２ではなく、４にすれば今度は制御系の問題(ハード側の制約は分からないが)や、電源、回路の重さが増えてしまい、難しいと考えられる。
最初にも言ったが、手動でのリトライは出来ない。自動リトライは許容時間内であれば可能かもしれない(再起動や別系統からのアプローチが可能ならと言う前提がつくが。)
以上。
これを書いてる間に、Ｈ３もＨ２Ａも８月くらいまで延期？火星探査系のやつを打ち上げるのが８月くらいまで延期？と言うのを見たが、まだ原因が分かってないのかな？と思う。
早くの原因究明と対策を打って、ロケットを打ち上げられるようになって欲しいと心から思っている。
参考資料
H3ロケット試験機1号機の 打上げ失敗について
(https://www.jaxa.jp/press/2023/03/files/20230308-mxt_uchukai01-000027909_1.pdf)