アカウント名:
パスワード:
第1段エンジン燃焼開始の判断なら、停止する方向に倒すのは正しい。リトライできるから。まさに今回の延期がそう。一方、空に上がってからなら、例え爆発の可能性があろうとも、継続するのが正しい。なぜならエンジン着火しない判断は即座にミッション失敗になるから。(※有人飛行なら別かもしれない)
つまり、そういう方針で設計していなかったという、設計ミスだね。宇宙開発で良く聞く「ロバスト」になってなかった。例えば他にも、フライトのシーケンスのなかで手遅れにならないタイミングで何度も再起動を試す、とかもやって良かったはずだが、おそらくやって
ストーリーにもあるけど、冗長系の両方を止めてしまうのは設計ミスに見えるね。電源が燃えるより破壊するより、電源止めてしまえばもっと悲惨なことになるのは目に見えてるのだから。
異常系の設計を一通り見直すとしたら、次の打ち上げはかなり先になりそう。電源だけ見直すならすぐ飛ばせるだろうけど、それだとリスク抱えたままになってしまう。
これが飛行のもっと早い段階における筐体GNDへのショートなどであれば、そこから発火に繋がり機体が爆発するような可能性も考えられます。すでにFTSを停止してもよいような領域で飛んでいるのだからイケイケ精神に切り替えるべきであった、というのも大概が後知恵だと思います。
それより電源ユニットが同じ箇所に同じ信号を受け取る2基を並べる方法で冗長化されていたことへの批判の方が気になりますね。信号からアクチュエータまでの経路が分散したSPoFの鎖になってるんですよ、これ。
今回H3では車載用のIC多数採用してるそうですが、車載のECUでは正にそういう制御をしてますよ。ブレーキ作動中でなければエラー時に動作停止しますが、ブレーキ作動中であればエラーは通知だけしてブレーキ継続し、ブレーキ終了後に動作停止します。こういうのは車載に限らずプラントや航空機等の止めるほうが危険な用途では一般的な制御です。
それって少なくとも 1)継続で被害は縮小する可能性が高い 2)作動でユーザを傷つけるおそれはない とか条件がないでしょうか。
アクチュエータを作動する命令を発したら駆動電源電圧が異常に低下した、というおそらく想定になかった事態において、これは止める方が危険なのか止めない方が危険なのかを事前に言い切れたとは思いづらいです。ロケットは制御を失っていない限り、飛行経路上の前方どこか一点に落下します(慣性があるので直下には落ちません)が、崩れていてエンジンが作動していれば、落下しうる範囲は経路外の八方にも広がります。もしこの電源電圧降下が姿勢制御を失うような性質のものであれば、それは切って正解とも言えるんじゃないでしょうか。
そりゃ衛星が投入できてた方が嬉しいですけど、変な弾道軌道になってカリマンタン島とかに突っ込まれたら人災ですよ。
>これが飛行のもっと早い段階における筐体GNDへのショートなどであれば、そこから発火に繋がり機体が爆発するような可能性も考えられます。
あなたのこの発言に対して、条件によって異常時の動作を変えるのはこの手のシステムでは普通だと言ってるだけです。今回のシステムで動作継続と停止のどちらが正しいか、私には判断できる情報がありませんが。
指令破壊の仕組みがない状況だっらたその通りだとは思う。ただ、今回は指令破壊という最終手段が別途存在する状態なのだから飛行継続の一択だと思う。
なんかフクイチへの海水注入を思い出すわ。「そんなことしたら現状復帰できなくなる」「そんなこと言ってる場合か！」って。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
設計ミスかなー (スコア:4, 興味深い)
第1段エンジン燃焼開始の判断なら、停止する方向に倒すのは正しい。リトライできるから。まさに今回の延期がそう。
一方、空に上がってからなら、例え爆発の可能性があろうとも、継続するのが正しい。なぜならエンジン着火しない判断は即座にミッション失敗になるから。(※有人飛行なら別かもしれない)
つまり、そういう方針で設計していなかったという、設計ミスだね。
宇宙開発で良く聞く「ロバスト」になってなかった。
例えば他にも、フライトのシーケンスのなかで手遅れにならないタイミングで何度も再起動を試す、とかもやって良かったはずだが、おそらくやって
Re: (スコア:1)
ストーリーにもあるけど、冗長系の両方を止めてしまうのは設計ミスに見えるね。
電源が燃えるより破壊するより、電源止めてしまえばもっと悲惨なことになるのは目に見えてるのだから。
異常系の設計を一通り見直すとしたら、次の打ち上げはかなり先になりそう。
電源だけ見直すならすぐ飛ばせるだろうけど、それだとリスク抱えたままになってしまう。
Re: (スコア:3)
これが飛行のもっと早い段階における筐体GNDへのショートなどであれば、そこから発火に繋がり機体が爆発するような可能性も考えられます。すでにFTSを停止してもよいような領域で飛んでいるのだからイケイケ精神に切り替えるべきであった、というのも大概が後知恵だと思います。
それより電源ユニットが同じ箇所に同じ信号を受け取る2基を並べる方法で冗長化されていたことへの批判の方が気になりますね。信号からアクチュエータまでの経路が分散したSPoFの鎖になってるんですよ、これ。
Re:設計ミスかなー (スコア:0)
今回H3では車載用のIC多数採用してるそうですが、車載のECUでは正にそういう制御をしてますよ。
ブレーキ作動中でなければエラー時に動作停止しますが、ブレーキ作動中であればエラーは通知だけしてブレーキ継続し、ブレーキ終了後に動作停止します。
こういうのは車載に限らずプラントや航空機等の止めるほうが危険な用途では一般的な制御です。
Re:設計ミスかなー (スコア:2)
それって少なくとも 1)継続で被害は縮小する可能性が高い 2)作動でユーザを傷つけるおそれはない とか条件がないでしょうか。
アクチュエータを作動する命令を発したら駆動電源電圧が異常に低下した、というおそらく想定になかった事態において、これは止める方が危険なのか止めない方が危険なのかを事前に言い切れたとは思いづらいです。ロケットは制御を失っていない限り、飛行経路上の前方どこか一点に落下します(慣性があるので直下には落ちません)が、崩れていてエンジンが作動していれば、落下しうる範囲は経路外の八方にも広がります。もしこの電源電圧降下が姿勢制御を失うような性質のものであれば、それは切って正解とも言えるんじゃないでしょうか。
そりゃ衛星が投入できてた方が嬉しいですけど、変な弾道軌道になってカリマンタン島とかに突っ込まれたら人災ですよ。
Re: (スコア:0)
>これが飛行のもっと早い段階における筐体GNDへのショートなどであれば、そこから発火に繋がり機体が爆発するような可能性も考えられます。
あなたのこの発言に対して、条件によって異常時の動作を変えるのはこの手のシステムでは普通だと言ってるだけです。
今回のシステムで動作継続と停止のどちらが正しいか、私には判断できる情報がありませんが。
Re: (スコア:0)
指令破壊の仕組みがない状況だっらたその通りだとは思う。
ただ、今回は指令破壊という最終手段が別途存在する状態なのだから飛行継続の一択だと思う。
Re: (スコア:0)
なんかフクイチへの海水注入を思い出すわ。「そんなことしたら現状復帰できなくなる」「そんなこと言ってる場合か！」って。