JAXAイプシロンロケット打ち上げ中止の原因が判明！信号伝達に0.07秒の遅延。
計画では発射２０秒前、地上の計算機が機体に搭載した計算機に対し、機体の姿勢を計算するよう命令。
１秒後、機体から地上にデータが伝達され、姿勢を判断する仕組みだった。
調査の結果、命令の伝達過程で演算処理などに時間を要し、機体側の計算機に命令が届くのが０・０７秒遅れた。この影響で地上側への伝達にも遅れが生じ、データを受信しないまま姿勢を判断したため異常と判定、発射１９秒前に打ち上げを自動停止した。
信号の遅れは２０日、機体を発射位置に移動するリハーサルでも生じたが、見落としていた。
また、２１日のリハーサルでは雨天のため機体移動を行わず、適切な確認作業をしていなかった。
会見した森田泰弘プロジェクトマネージャは「当然生じる時間の遅れに気付ける人がいなかった。反省している」と述べ、判断ミスを認めた。
今後は遅れが起きた原因をさらに究明し、再発防止策を検討するほか、他の場所でも同様の問題が起きないか特別点検を行う。
ソース：産経
http://sankei.jp.msn.com/science/news/130831/scn13083101250000-n1.htm
ｽﾎﾟﾝｻｰﾘﾝｸ
0.07秒（1/14秒）操作が送れるコントローラーでスーパーマリオ遊んでみればわかると思うよ。
昔デジタル液晶テレビでロックマンやって発狂した。
音ゲーなんかだと1/216秒の世界とからしいぞ。判定の基準って。
0.07秒遅れるのも1時間遅れるのも一緒。
もっと言えば0.000000001秒遅れるのも一緒。
データが後から届いたら何の役にも立たない。
ifの話で悪いんだが宇宙空間でロケットはピストルの弾より早く飛ぶからなぁ。
秒速11200m以上で飛んでる物体だから0.01秒で112m、0.07だったら800m近く進む。
その間に姿勢がずれたら、すべての面で直さないといけないのでロケットはシビアなわけだ。
まあ、文句をいうのは簡単だが携わってる方々は同業種からみてもエリートだわ。
0.07秒＝70ミリ秒。
処理スピードから言ってハードウエアの遅延としたら特殊な遅延回路が入ってないと不可能。
汚まいらが使ってるＵＳＢ１．１のマウスでもそれより早い。
機能テストばっかやってて、非機能テストをしてなかった場合の典型的なミス。
でも、こんなの機能テストしてる時に気づけると思うんだけど、
リハーサルの時のテスト項目がよっぽどザルだったとしか思えないｗ
「点検で見落とす」とか嫌な言い方だな…
は？？？？？？？？？
>信号伝達の０．０７秒の遅れが原因… こんなの実際にやってみないと発見できない不具合だよ、
ｱﾌﾟﾘｹｰｼｮﾝ設計者なら普通にそういういいわけをする。
設計時に情況設定の抜けがあり本番まで判明しないとか、
素人設計も酷すぎる。億単位の回路が入っているﾏｲｸﾛﾌﾟﾛｾｯｻの中身の
設計が量産してみないと判明しないとかバカ言うわけないだろ。
ｱﾌﾟﾘｹｰｼｮﾝでは普通に不具合が許されてもIntelのCoreﾌﾟﾛｾｯｻで量産後に
たった1個でも見つかったらﾛｹｯﾄ打ち上げのｺｽﾄより巨額な被害額になる。
普通にμコード対応出来るようになったから結構CPUにバグ有ったりするぞ（ｗ
エラッタリストとかねえ。
特に今回は既存ハードの流用が多いから逆に油断が心配だ
俺が居たらこんなドジ踏ませなかった
ここまで緻密にしないとロケットって打ち上がらないのか
いや本体はもっとおおざっぱでもあがるんだが
安全上の機構のトラブルだからなあ
１．システムSTOP
２．ログの出力するだけ
どっちにするのが正解？
STOPさせなければならないなら止めるし、止めなくて良いならログだけ残す。
今回みたいにクリティカルな制御の場合は必ず止めることになる。
それより本当の問題は
地上とロケットは連携しなければならないが、
それぞれのコンピュータは完全に個別に動いているので、
絶対に指定の時間に通信できると想定することが間違っている。
今回の発表を見ると双方が発射時刻をゼロ点とした絶対時間を基準に
アクションしてタイミングをあわせることになってた様だがそんな設計そのものがありえない。
いくら事前テストしてもこんな設計じゃ無駄だよ。
だから開発費も恐ろしく少ない故に設計まで簡素化されてしまったんだろう。
数十から数百人が担当していたところを数名に減らした内容に見合う
開発人数で設計から作成、テストまですべて少人数でやってなければ
こんなことは起きるなら日本の技術も怪しい。
下手すれば技術担当者１名ってこともあるかもな。
部品の不具合をコンピュータが見つけて中止のほうがまだましな気がする
もちろん反省と検証は必要だが、今までの大勢でやってたことを大幅に省いてしまうんだから、同様のトラブルはまだ起こる可能性はある。周りはもっと肩の力を抜いて応援しよう。
自動点検はロケット部に関してだけで地上側の設備の絡む点検は人間様のはず
地上処理系も相当自動化しないと無理なコンセプトだぞこれ
PCの1画面内に一覧表示されたパラメータ群の話ならそれでも良いんだが
逆だろ？自動チェックがしっかり働いたからカウントが止まって点火されなかった。
初物はバグの洗い出しが大変なんだよ。
１秒間に１０個以上の音符を入れ、その一つ一つにニュアンスや表情をつけるという、
コンマ１秒以下の世界を垣間見ることができる神業が身についてるからな。
この伝達速度ならＰＣの存在価値ねーぞｗ
実際にロケット立ててのテストって20日の1回しかしてなくてそれを見逃したってこと？
仮にロケットの射場の姿勢決めを油圧でやってるとして、
射場の気温が違えば油の粘度も変わって、何十トンもあるロケットを傾けるのに数秒ぐらい違うかもしれない。
ほかにもいろんなイベントがいろいろあるのをコンピュータは処理し続けるのですべて同じタイミングに
バッチリ合うかどうかは極端な厳密を持って事前に分かる事は難しい。
情報thx
どうも俺がイメージしてるレベルのエラーじゃないっぽいな
どうやら命令するタイミングによってロケットからの返答に要する所要時間に揺らぎがあると思われる。テストではたまたま問題が出なかったのだろう
なるほどさすがに事前テスト1回だけって訳じゃないのね
おっと、21日のテスト段階から遅れは生じていたのだな。これは揺らぎの問題ではなく、ログが持つメッセージに気づけなかったミスとしか言いようがない。
本番じゃトラフィック増えるからな。
近所の電気屋でブリッジとケーブルもう１セット買って来いよ。
また完成後に点検するような事か？
コンピュータ制御のいろはだろ
君がやってるシステムより規模が大きいですからねぇ
複雑なシステムになればなるほど縦割りが増えていって
I/F設計で遅延問題とか割とよく見落とすんだよ
だからこそ基本のいろはだってうるさく言われるんだが
誤差設計したら両者が反対側の両極端取ってミスったIFなんて多々ある
予算の浪費だってすごく叩かれた
関係者の心労は相当なものだったろう
しかし、その反省があるから後の成功があった
イプシロンにしても最初から成功しなくてよかったとも言える
ｽﾎﾟﾝｻｰﾘﾝｸ
おすすめ記事
ツイッターで更新情報をお届け☆
コメント
トラックバックは利用できません。
コメント (0)
この記事へのコメントはありません。