アカウント名:
パスワード:
有人宇宙飛行はできませんね。こんな簡単なバグをつぶせないようでは。いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。私は、辞退します。
これ、鉄道と航空宇宙だと、関係が逆になるけど、日本の鉄道は、ぶつからせないことを前提にして、何重にも安全装置とかまわりの環境を整えていく(減速させたり)。なので、ぶつかったらえらいことになる。
アメリカの鉄道は、衝突することがありうることを前提にして、ぶつかったときどうするかの仕組みが手厚いなので、ぶつかったらぶつけたやつをふっ飛ばしたり、ぶつかりそうなとき目立つような色になってたりする。
たぶん前提がちがうし、仮に金属玉を途中で落としてなくしたりしないように細心の注意を払った結果、本来ならOkしてもいいところまで、NGを返しちゃったんじゃないかとおもう。例外のなかで唯一OKな条件だけど、このときは出さないように安全装置を仕掛ける、とか前後のコメントにもあるけど実体験できない場所での想定条件判定は相当難儀ですよ。
ツブでも得られたからオーライ。まじで。
じゃあ、もしも日本の列車が全部JR西日本の様になると考えてみてください
はやぶさのような人工衛星の場合は、物理演算した仮想宇宙空間でシミュレートでもしてみたらいいのでしょうかね。
この場合例外ではなく、正常な採取プロセスで望まぬ動作を指示しているのですからシミュレータで一度でも試していれば気がつけたようにも思えます。
熱くなる気持ちは理解できますが、今回のようなミスについては、真空や温度、放射線全てを無視しても発見できそうですよね。
> というか、今回のは「物理演算」でない、ごく普通のシミュレーターで良さそうですが。
その普通のシミュレータすら作る予算か何かがなかったのでは??
#シミュレータって簡単に言うけど、楽じゃない・・・
どんなに対策しても事故・犠牲をゼロにすることは不可能。犠牲が出ても前に進み続ける気構えと覚悟が無ければ有人宇宙飛行は出来ない。それがアメリカと日本の最大の違いだと思う。
詳細は忘れたが、アメリカの宇宙開発関連で命を落とした人の名前を刻んだ追悼碑には、まだ十分な空きスペースがある、と言う話を聞いたことがある。
> いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。
現地でデバッグ辛いです><
>> いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。
>現地でデバッグ辛いです><
証拠隠滅の方かと思った。
この知見が「はやぶさ2」に活かせれば良いのです。そのための工学試験衛星なんですから。
次は岩石取得方法を多重冗長化できないものでしょうかね。今回うまくいかなかったシステムを修正するほかに何か別の方法も。ガムテープ飛ばして引きずり回して引き戻して格納すればいいんじゃないの、といっている人もいましたが。
http://www.itmedia.co.jp/news/articles/1011/16/news083.html [itmedia.co.jp]
エアロゲルなどを使わない、コンタミ(汚染)のない状態の回収もはやぶさが初めて
とのことなので、粘着剤を使わない方式に意義はあるのでしょう。
あと、原因がソフトウェアの問題だったということは、採取用のハードウェアを冗長化してどうにかなる問題ではないってことだと思います。冗長性という点なら、さきがけ [wikipedia.org]・すいせい [wikipedia.org]みたいに探査機を2機打ち上げて別々に運用するのが理想なのかもしれませんが…
ソフトウェアを多重化しよう↓待機系のソフトを別のベンダに開発させる↓結合試験で微妙な「挙動の違い」が発見される↓どちらかに合わせて修正↓…元の木阿弥?
# いやこれが起きたとしても意味はもちろんあるんですけどね…
トリモチ方式については、1. 宇宙空間で粘着力を長期間維持することが困難。2. ターゲット表面の物質が必ずしもトリモチにくっつくとは限らない。3. トリモチからサンプルを取り外すことが困難。という話を聞いたことがあります。
また、高温になる小惑星表面にとどまる時間を最小限にする(=ごく短時間でサンプルを採取する)という点でも、現行の方式が優れているようです。
「はやぶさ2」においても現行方式の改善版で望む方針のようですので、それなりに自信のある方法なのではないでしょうか(以下、PDF注意)。http://www.mext.go.jp/component/b_menu/shingi/toushin/__icsFiles/afiel... [mext.go.jp]
「プログラムミス」については、こちらにもあるように運用の中でソフトウェアを更新することもあったようなので、その中で発生したミスなのかもしれませんね(全くの憶測ですが)。http://www.nec.co.jp/ad/hayabusa/story/04/ [nec.co.jp]
宇宙空間で変質しないガムテープを発明できたらノーベル賞もらえますよ。あるいはその特許をNASAが買い取ってくれるかもね。
== と != を間違えるようなのをいまさら試験しなくてもいいように思いますがw
#なんでも“ベータ版”で済ますのはよくないよね#バグバグの免罪符にはならないし
ソフトウェア上のバグの知見というのは、どういう形で一般化し継承されるのでしょうか。ハードウェア上の不具合については、知見としてデータベース化しやすいと思いますが。
例えば今回のバグは、どんな知見として蓄積され、今後の同様のプロジェクトの成功率を上げるために役立つのでしょうか。
物事は具象的にだけでなく抽象的にも捉えないとな。てか、一般化するなら抽象化するのは当然だが。
例えば「セーフティが働いて何かが中止になった時はassertっぽくソースコード中の位置をメッセージに含める」とか。問題発生から原因解明までの時間を短縮できるから時間切れまでに修正できる可能性が高くなるだろ?コードサイズ気にするならメッセージにはソースラインコードを出力させて、ビルド時に作る対応表牽くようにすればいい。
ちがうちがう。現地デバッガーとして人間を積むことが是非とも必要ということだよ。日本の過酷労働条件下ではたらくプログラマーの中には「はやぶさに積まれていた方がずっとまし」という人もいるに違いない(涙)
>「はやぶさに積まれていた方がずっとまし」
ミネルバということですね。さようならぁ....(;_;)
本体は帰ってきても、焼かれちゃうし....
有人宇宙飛行はできませんね。 こんな簡単なバグをつぶせないようでは。
地球上で、この手のバグを完全に潰す為のコスト(実運用に近いテストとか)>>>(超えられない壁)>>>有人宇宙飛行で何か有った際のコスト(遺族に支払う賠償金とか) ∴バグが少々残ってて、事故が起きても、コスト的には問題無し
こんなのもありました。マリナー1号 [wikipedia.org]
有人飛行だったら人間が自分でどうにか出来るから簡単なんだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
あと百年は (スコア:-1, 荒らし)
有人宇宙飛行はできませんね。
こんな簡単なバグをつぶせないようでは。
いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。
私は、辞退します。
Re:あと百年は (スコア:3, すばらしい洞察)
>こんな簡単なバグをつぶせないようでは。
その発想は間違っている
試験出来ないバグは簡単なバグなどではなく,潰すのが非常に難しいバグだ
組込系では実地にテストするのが難しい異常対応処理のコードにバグがあって作った意味がなかった-という話は良くあるものだ
有人宇宙飛行のような高信頼性が要求されるシステムでは,試験を念入りにおこなった上で,バグは完全に無くせないことを前提にさらに独立して実装した別系統の制御システムも加える
たしかスペースシャトルの飛行制御システムは複数のコンピュータの多数決+別機種のコンピュータ・別実装のバックアップ系という構成になっていたはず
バグや故障の存在を前提とした信頼性保証を目指すという発想が出来なければ有人宇宙飛行は出来ない
それが米国人と日本人の違い
(はやぶさはもとより一発勝負だし,失敗したって人が死ぬわけじゃないから,そこまで考えてないし考える必要もない)
鉄道でも考え方の違いがあるとおもうだよ (スコア:4, すばらしい洞察)
これ、鉄道と航空宇宙だと、関係が逆になるけど、
日本の鉄道は、ぶつからせないことを前提にして、何重にも安全装置とかまわりの環境を整えていく(減速させたり)。
なので、ぶつかったらえらいことになる。
アメリカの鉄道は、衝突することがありうることを前提にして、ぶつかったときどうするかの仕組みが手厚い
なので、ぶつかったらぶつけたやつをふっ飛ばしたり、ぶつかりそうなとき目立つような色になってたりする。
たぶん前提がちがうし、仮に金属玉を途中で落としてなくしたりしないように細心の注意を払った結果、
本来ならOkしてもいいところまで、NGを返しちゃったんじゃないかとおもう。
例外のなかで唯一OKな条件だけど、このときは出さないように安全装置を仕掛ける、とか
前後のコメントにもあるけど実体験できない場所での想定条件判定は相当難儀ですよ。
ツブでも得られたからオーライ。まじで。
( ´・ω・`)いままでとこれからを比べる生活
ぱんかれ
Re: (スコア:0)
じゃあ、もしも日本の列車が全部JR西日本の様になると考えてみてください
Re:あと百年は (スコア:2)
バグであることは間違いないですが、はやぶさのプロジェクト使命と、
送信できるプログラムの長さ(通信速度)、メモリ量、CPUなどを考えると、
アポロのような3つのCPUによる、多数決処理、なんてことはできない環境だとおもいます。
>それが米国人と日本人の違い
勿論有人飛行なら、「日本人」でもこのようなレベルでの適用はしないと思いますよ。
Re:あと百年は (スコア:1)
はやぶさのような人工衛星の場合は、
物理演算した仮想宇宙空間でシミュレートでもしてみたらいいのでしょうかね。
この場合例外ではなく、正常な採取プロセスで望まぬ動作を指示しているのですから
シミュレータで一度でも試していれば気がつけたようにも思えます。
Re: (スコア:0, オフトピック)
「仮想環境」は、的外れといえましょう。
真空中・高温・低温・放射線などの環境で、しかも何カ月・何年もたって、モノが設計通りに動いてくれるのか?
それが分かれば「工学試験衛星」なんて不要です。
Re: (スコア:0)
熱くなる気持ちは理解できますが、今回のようなミスについては、真空や温度、放射線全てを無視しても発見できそうですよね。
Re: (スコア:0)
というか、今回のは「物理演算」でない、ごく普通のシミュレーターで良さそうですが。
Re: (スコア:0)
> というか、今回のは「物理演算」でない、ごく普通のシミュレーターで良さそうですが。
その普通のシミュレータすら作る予算か何かがなかったのでは??
#シミュレータって簡単に言うけど、楽じゃない・・・
Re: (スコア:0)
どんなに対策しても事故・犠牲をゼロにすることは不可能。
犠牲が出ても前に進み続ける気構えと覚悟が無ければ有人宇宙飛行は出来ない。
それがアメリカと日本の最大の違いだと思う。
Re:あと百年は (スコア:1, 興味深い)
詳細は忘れたが、アメリカの宇宙開発関連で命を落とした人の名前を刻んだ追悼碑には、まだ十分な空きスペースがある、と言う話を聞いたことがある。
Re:あと百年は (スコア:3, おもしろおかしい)
> いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。
現地でデバッグ辛いです><
-------- tear straight across --------
Re:あと百年は (スコア:2)
>> いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。
>現地でデバッグ辛いです><
証拠隠滅の方かと思った。
次につながる (スコア:2)
この知見が「はやぶさ2」に活かせれば良いのです。
そのための工学試験衛星なんですから。
And now for something completely different...
Re: (スコア:0)
次は岩石取得方法を多重冗長化できないものでしょうかね。
今回うまくいかなかったシステムを修正するほかに何か別の方法も。
ガムテープ飛ばして引きずり回して引き戻して格納すればいいんじゃないの、といっている人もいましたが。
Re:次につながる (スコア:2, 興味深い)
http://www.itmedia.co.jp/news/articles/1011/16/news083.html [itmedia.co.jp]
エアロゲルなどを使わない、コンタミ(汚染)のない状態の回収もはやぶさが初めて
とのことなので、粘着剤を使わない方式に意義はあるのでしょう。
あと、原因がソフトウェアの問題だったということは、採取用のハードウェアを冗長化してどうにかなる問題ではないってことだと思います。
冗長性という点なら、さきがけ [wikipedia.org]・すいせい [wikipedia.org]みたいに探査機を2機打ち上げて別々に運用するのが理想なのかもしれませんが…
Re: (スコア:0)
障害で待機系に切り換えたら、そこでも同じ障害が発生・・・原因はソフトウェアなんてのは、ありがちな話のはずなのに。
Re:次につながる (スコア:1, 興味深い)
ソフトウェアを多重化しよう
↓
待機系のソフトを別のベンダに開発させる
↓
結合試験で微妙な「挙動の違い」が発見される
↓
どちらかに合わせて修正
↓
…元の木阿弥?
# いやこれが起きたとしても意味はもちろんあるんですけどね…
Re:次につながる (スコア:2, 参考になる)
トリモチ方式については、
1. 宇宙空間で粘着力を長期間維持することが困難。
2. ターゲット表面の物質が必ずしもトリモチにくっつくとは限らない。
3. トリモチからサンプルを取り外すことが困難。
という話を聞いたことがあります。
また、高温になる小惑星表面にとどまる時間を最小限にする(=ごく短時間でサンプルを採取する)という点でも、現行の方式が優れているようです。
「はやぶさ2」においても現行方式の改善版で望む方針のようですので、それなりに自信のある方法なのではないでしょうか(以下、PDF注意)。
http://www.mext.go.jp/component/b_menu/shingi/toushin/__icsFiles/afiel... [mext.go.jp]
「プログラムミス」については、こちらにもあるように運用の中でソフトウェアを更新することもあったようなので、その中で発生したミスなのかもしれませんね(全くの憶測ですが)。
http://www.nec.co.jp/ad/hayabusa/story/04/ [nec.co.jp]
Re:次につながる (スコア:1)
次のターゲットとなる小惑星の表面がどんな固さか、とかは近づいてみないと分からないところが難しいところですよね。
イトカワも、行ってびっくりレゴリスだらけ [www.jaxa.jp]という感じでしたし。
ガムテープが岩に張り付いて、はやぶさ2が引っ張られてビターンッとぶつかるところを妄想。
Re: (スコア:0)
宇宙空間で変質しないガムテープを発明できたらノーベル賞もらえますよ。
あるいはその特許をNASAが買い取ってくれるかもね。
Re: (スコア:0)
Re: (スコア:0)
なにせリアクションホイールの機数も切り詰めたくらいですから。
また粘着材を使用しなかったのは、できれば表面に積もった粒子ではなく、
破片が欲しかったということもあると思われます。
Re: (スコア:0)
== と != を間違えるようなのをいまさら試験しなくてもいいように思いますがw
#なんでも“ベータ版”で済ますのはよくないよね
#バグバグの免罪符にはならないし
Re: (スコア:0)
ソフトウェア上のバグの知見というのは、どういう形で一般化し継承されるのでしょうか。
ハードウェア上の不具合については、知見としてデータベース化しやすいと思いますが。
例えば今回のバグは、どんな知見として蓄積され、今後の同様のプロジェクトの成功率を
上げるために役立つのでしょうか。
Re:次につながる (スコア:1)
物事は具象的にだけでなく抽象的にも捉えないとな。
てか、一般化するなら抽象化するのは当然だが。
例えば「セーフティが働いて何かが中止になった時はassertっぽくソースコード中の位置をメッセージに含める」とか。
問題発生から原因解明までの時間を短縮できるから時間切れまでに修正できる可能性が高くなるだろ?
コードサイズ気にするならメッセージにはソースラインコードを出力させて、ビルド時に作る対応表牽くようにすればいい。
Re:あと百年は (スコア:2, おもしろおかしい)
ちがうちがう。現地デバッガーとして人間を積むことが是非とも必要ということだよ。
日本の過酷労働条件下ではたらくプログラマーの中には
「はやぶさに積まれていた方がずっとまし」
という人もいるに違いない(涙)
Re:あと百年は (スコア:1)
>「はやぶさに積まれていた方がずっとまし」
ミネルバということですね。
さようならぁ....(;_;)
本体は帰ってきても、焼かれちゃうし....
本投稿は、あくまで冗談につき……(Re:あと百年は) (スコア:1)
地球上で、この手のバグを完全に潰す為のコスト(実運用に近いテストとか)>>>(超えられない壁)>>>有人宇宙飛行で何か有った際のコスト(遺族に支払う賠償金とか)
∴バグが少々残ってて、事故が起きても、コスト的には問題無し
Re: (スコア:0)
NASAも有人宇宙飛行はするべきではありませんね
Re: (スコア:0)
こんなのもありました。
マリナー1号 [wikipedia.org]
Re: (スコア:0)
Re: (スコア:0)
有人飛行だったら人間が自分でどうにか出来るから簡単なんだけど。