ultrageek 曰く、47Newsの記事によれば、探査機「はやぶさ」が小惑星「イトカワ」に着陸した際に、岩石採取のための金属球を発射できなかったのは地上から送ったプログラムにミスがあったのが原因だったこと分かったらしい。はやぶさは着陸と同時に金属球を発射して、砕いた岩石をカプセルに取り込む計画だったが、このプログラムに「着陸のために地表に水平な姿勢を取ったら、金属球の発射を止める安全装置を作動させる」という誤った内容が含まれていたとのことである。結果的に、微粒子の採取には成功したので、まあドンマイということで。
ははあ、つまりサンドボックスで (スコア:5, おもしろおかしい)
テストしていなかった。と。
史上では些細な（結果の）バグですね (スコア:3, すばらしい洞察)
ロケットまるまる吹っ飛んだ [youtube.com] アリアン5の初飛行 [wikipedia.org]とか、単位換算のミスで火星周回軌道投入に失敗したマーズ・クライメイト・オービター [wikipedia.org]とかに比べれば。
＃ロケットや人工衛星・惑星なんて代物は、どかんと爆発したり通信が途絶して行方不明になったりするのが当たり前の代物だと思う。米ソのあれやこれやを文献で読んでいると。
＃最終的には一発勝負で、いざとなったらリセットボタンや緊急停止スイッチを押すなんて事もできない、あんな複雑な代物が、（たいていは）ちゃんと動くのは不思議で仕方ない。
自動化を目指す次世代固体推進剤ロケット (スコア:3, 参考になる)
>＃最終的には一発勝負で、いざとなったらリセットボタンや緊急停止
>スイッチを押すなんて事もできない、あんな複雑な代物が、（たいていは）
>ちゃんと動くのは不思議で仕方ない。
2013年打ち上げを目指して開発中のイプシロンロケットは
複雑なロケットの打ち上げシステムの自動化を目指すようです
http://www.jaxa.jp/article/interview/vol58/index_j.html [www.jaxa.jp]
オープンソース (スコア:2)
きっと遠い未来(じゃないかもしれないけど)にはこういうプログラム自体もオープンソースでやるようになるんじゃないかな。
kernel 1.1 姿勢制御に問題がありましたが対処しました。
kernel 1.2 試験的に有人飛行に対応しました。
kernel 1.3 緊急脱出装置が稼動しないバグに対処しました。
kernel 1.4 着陸時のランディングに問題がありましたが対処しました。
こんな感じになるんでしょうか。
Re: (スコア:0)
世の中トライアンドエラーで済むものばかりじゃないというか探査衛星の制御プログラムなんて済まないものの最たる例だと思うんですが。
Re:オープンソース (スコア:1)
もともと、ただのエンジン試験衛星じゃなかったっけ。探査はおまけ。
Re:オープンソース (スコア:2, おもしろおかしい)
>探査はおまけ。
おまけ目当てってのが結構、世の中にあってだな。
ビックリマンチョコとか顕著な例だけど、萌え系外装の米や飲料とかさ。
そういったオマケにつられやすい人って、多いみたいだよ。
Re: (スコア:0)
今回のはやぶさだって飛行中に何度もプログラム更新してたじゃないですか。
っていうか、それが出来なかったら帰還できなかったというのに・・・・
Re: (スコア:0)
資金の問題もあるからね～
でも今回みたいにトライしてみないとわからないこともあるからより多くの目で見てみるというのには賛成かな。
だれがどうコミットするとかは別として。
うーん (スコア:1)
日本語の問題としてそれは本当に「プログラムミス」だったの？
仕様が間違ってたとかじゃなくて。
あと作ったものが数年間評価されなくて白黒付かないってぇのは
なかなか微妙なプロセスですね。
数年経っちゃうと他人事になるのかな。数ヶ月だとその間は
結構緊張するような…。
# 宇宙関連、一度はやってみたいかも
そもそも、予め準備していたプログラムじゃなくて (スコア:3, 興味深い)
元記事にも
着陸の２日前、指令なしで自律的に動くためのプログラムが送信された。
とあるように、予め準備していたプログラムではなくて、間に合わせのプログラムだったはず。
ちょうど、幻冬舎新書から出ている「はやぶさ―不死身の探査機と宇宙研の物語」を読んだところなんだけど、そもそも、着陸するまでにリアクションホイールが壊れたりして、当初予定していたのとは、だいぶ違うやり方で着陸することになったようで、その為にその場であれこれ工夫して作ったプログラムだから、通常のソフトウェア開発と同じに考えると、少し違うような気がします。
ま、バグはバグなんだけど
Re:うーん (スコア:1)
だが、このプログラムには「着陸のために地表に水平な姿勢を取ったら、金属球の発射を止める安全装置を作動させる」という、誤った内容が含まれていた。
安全装置は本来、機体に危険が及ぶ恐れがあるときに使うものだが、このミスにより作動してしまったため、着陸して発射の指令が出たのに球は発射されなかった。
バグが混入したのがコーディングの時点なのかそれ以前なのかは分かりませんが、上記を読む限り仕様という訳ではないのでは。
Re:うーん (スコア:1, すばらしい洞察)
日本語でプログラミング [sciencehouse.co.jp]でないことを前提とすると、
上記を読む限りでは、「誤りの内容」を広報向けに日本語に翻訳したのか、上記文面の仕様書通りにプログラミングして結果として誤った動作になったかは判別できません。
"禁止する機能",disable,inhibitとかをそのまま、"○○の機能をオフにする[有効/無効]"だとか書いてしまうと"真"がどちらの状態を示すか混乱する可能性があります。
仕様書を書くときにはNagetive表現はなるべく避けるべきでしょう。かえって回りくどくなるようではまずいですが。
水平な姿勢を取ったら、金属球の発射を止める安全装置を解除させる
↓
水平な姿勢を取ったら、(安全装置に)金属球の発射を許可させる
いまごろなぜ？ (スコア:0)
2005年12月13日には既に、弾丸発射に失敗した可能性について発表がありました。
http://www.hayabusa.isas.jaxa.jp/j/index_41.html [isas.jaxa.jp]
29日に正式発表があったのでしょうか？
でもそれらしき発表が見つけられないのですが・・・。
Re:いまごろなぜ？ (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
不具合の「状況」と「原因」じゃね？
Re: (スコア:0)
当時の発表では
>ただし、システム全般の電源が広い範囲でリセットされたことによる影響も
>考えられ、１１月２６日の着陸前後に実施されたシーケンスの確認も含め、
>詳細を解析中です。
というレベルでした。
47NEWSの記事では「29日までの検証で分かった」とあるので、今回微粒子を
採取できていることが分かって、どのような動作で取得したのか当時の記録を
洗い直して、検証中だったのではないでしょうか。
Re:いまごろなぜ？ (スコア:5, おもしろおかしい)
「イトカワの砂を確認！大成功です！」
「万歳！」
「さあ皆で祝杯だ！」
「おめでとう！おめでとう！」
「金属球が出なくて泣いたことも今じゃいい思い出だな！」
「この雰囲気なら言える！実はあれの原因はおれの…」
Re:いまごろなぜ？ (スコア:2, すばらしい洞察)
＞「この雰囲気なら言える！実はあれの原因は〜
まさにそれを組織としてやってしまったのではなかろうか。
日本の学者や研究者の書くプログラムは品質がお粗末すぎる (スコア:0)
ぜったいにAC。
Re:日本の学者や研究者の書くプログラムは品質がお粗末すぎる (スコア:2, すばらしい洞察)
そういう門外漢の助けをするのがてめーの仕事じゃないのか？
研究者？ (スコア:2)
どこに研究者が書いたコードだと発表が？ 普通に考えたら、JAXAの技術者や外注先の技術者が書いた可能性が高いと思うのだが。研究者は研究が本業なのだから。
Re:日本の学者や研究者の書くプログラムは品質がお粗末すぎる (スコア:1)
役割が違うのでそれでいいんじゃないんでしょうかね？
個人的には楽しかったですよ。
研究成果を元にした製品作るのって。
Re:日本の学者や研究者の書くプログラムは品質がお粗末すぎる (スコア:1)
それを理解して実運用向けに安全なものにコーディングするのが
事業部の仕事でなんじゃないの？
と、いう話を昔聞いたんだけど。
実際たまに研究所筋には切れる人いるよね。切れてる人も結構いるけど。
Re: (スコア:0)
(うちの)事業部が自信満々に書くコードの汚さっていったら、結局全部(うちの)研究所の人間が書いたほうが早かったレベル。
# こっちもAC
びっくり！ (スコア:0)
Re:あと百年は (スコア:3, すばらしい洞察)
＞こんな簡単なバグをつぶせないようでは。
その発想は間違っている
試験出来ないバグは簡単なバグなどではなく，潰すのが非常に難しいバグだ
組込系では実地にテストするのが難しい異常対応処理のコードにバグがあって作った意味がなかった－という話は良くあるものだ
有人宇宙飛行のような高信頼性が要求されるシステムでは，試験を念入りにおこなった上で，バグは完全に無くせないことを前提にさらに独立して実装した別系統の制御システムも加える
たしかスペースシャトルの飛行制御システムは複数のコンピュータの多数決＋別機種のコンピュータ・別実装のバックアップ系という構成になっていたはず
バグや故障の存在を前提とした信頼性保証を目指すという発想が出来なければ有人宇宙飛行は出来ない
それが米国人と日本人の違い
（はやぶさはもとより一発勝負だし，失敗したって人が死ぬわけじゃないから，そこまで考えてないし考える必要もない）
鉄道でも考え方の違いがあるとおもうだよ (スコア:4, すばらしい洞察)
これ、鉄道と航空宇宙だと、関係が逆になるけど、
日本の鉄道は、ぶつからせないことを前提にして、何重にも安全装置とかまわりの環境を整えていく（減速させたり）。
なので、ぶつかったらえらいことになる。
アメリカの鉄道は、衝突することがありうることを前提にして、ぶつかったときどうするかの仕組みが手厚い
なので、ぶつかったらぶつけたやつをふっ飛ばしたり、ぶつかりそうなとき目立つような色になってたりする。
たぶん前提がちがうし、仮に金属玉を途中で落としてなくしたりしないように細心の注意を払った結果、
本来ならＯｋしてもいいところまで、ＮＧを返しちゃったんじゃないかとおもう。
例外のなかで唯一ＯＫな条件だけど、このときは出さないように安全装置を仕掛ける、とか
前後のコメントにもあるけど実体験できない場所での想定条件判定は相当難儀ですよ。
ツブでも得られたからオーライ。まじで。
( ´・ω・`)いままでとこれからを比べる生活
ぱんかれ
Re:あと百年は (スコア:2)
バグであることは間違いないですが、はやぶさのプロジェクト使命と、
送信できるプログラムの長さ（通信速度）、メモリ量、CPUなどを考えると、
アポロのような３つのCPUによる、多数決処理、なんてことはできない環境だとおもいます。
>それが米国人と日本人の違い
勿論有人飛行なら、「日本人」でもこのようなレベルでの適用はしないと思いますよ。
Re:あと百年は (スコア:1)
はやぶさのような人工衛星の場合は、
物理演算した仮想宇宙空間でシミュレートでもしてみたらいいのでしょうかね。
この場合例外ではなく、正常な採取プロセスで望まぬ動作を指示しているのですから
シミュレータで一度でも試していれば気がつけたようにも思えます。
Re:あと百年は (スコア:1, 興味深い)
詳細は忘れたが、アメリカの宇宙開発関連で命を落とした人の名前を刻んだ追悼碑には、まだ十分な空きスペースがある、と言う話を聞いたことがある。
Re:あと百年は (スコア:3, おもしろおかしい)
> いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。
現地でデバッグ辛いです＞＜
-------- tear straight across --------
Re:あと百年は (スコア: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]みたいに探査機を２機打ち上げて別々に運用するのが理想なのかもしれませんが…
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]という感じでしたし。
ガムテープが岩に張り付いて、はやぶさ２が引っ張られてビターンッとぶつかるところを妄想。
Re: (スコア:0)
== と != を間違えるようなのをいまさら試験しなくてもいいように思いますがｗ
#なんでも“ベータ版”で済ますのはよくないよね
#バグバグの免罪符にはならないし
Re:次につながる (スコア:1)
物事は具象的にだけでなく抽象的にも捉えないとな。
てか、一般化するなら抽象化するのは当然だが。
例えば「セーフティが働いて何かが中止になった時はassertっぽくソースコード中の位置をメッセージに含める」とか。
問題発生から原因解明までの時間を短縮できるから時間切れまでに修正できる可能性が高くなるだろ？
コードサイズ気にするならメッセージにはソースラインコードを出力させて、ビルド時に作る対応表牽くようにすればいい。
Re:あと百年は (スコア:2, おもしろおかしい)
ちがうちがう。現地デバッガーとして人間を積むことが是非とも必要ということだよ。
日本の過酷労働条件下ではたらくプログラマーの中には
「はやぶさに積まれていた方がずっとまし」
という人もいるに違いない（涙）
Re:あと百年は (スコア:1)
>「はやぶさに積まれていた方がずっとまし」
ミネルバということですね。
さようならぁ....(;_;)
本体は帰ってきても、焼かれちゃうし....
本投稿は、あくまで冗談につき……(Re:あと百年は) (スコア:1)
地球上で、この手のバグを完全に潰す為のコスト(実運用に近いテストとか)>>>(超えられない壁)>>>有人宇宙飛行で何か有った際のコスト(遺族に支払う賠償金とか)
∴バグが少々残ってて、事故が起きても、コスト的には問題無し
Re: (スコア:0)
NASAも有人宇宙飛行はするべきではありませんね
Re: (スコア:0)
こんなのもありました。
マリナー1号 [wikipedia.org]
Re:ダメだろ (スコア:1)
>なんだかわからないけど動いたからOK、レベルで止まるんだよな。
動いているモンに触らないってのがあるよね。
>でイレギュラーに極めて弱い低品質のまま出荷される。
意外とイレギュラーでもドンマイなところがあったりする。
>ほんと、ダメすぎ。
だめかどうかは、実績が決めるらしいよ。
先日開かれていた宙（そら）博では (スコア:2, 興味深い)
はやぶさのリチウムイオン電池を開発した古河電気の展示区画にいた
解説員に聞いた所、「もしはやぶさ２をやるならはやぶさに搭載した
電池より容量が大きい電池を開発して載せたい」と語っていました
更に、はやぶさで問題になった電池の過放電対策も打ちたいとの事
電池の容量が増えれば同じサイズであればより長時間の可動が出来、
はやぶさと同じ持続時間であれば良いならより小さく軽量化出来、
過放電対策も取れば、万が一のトラブルでも最悪の状態は避けられるとの事でした
関係者はリベンジに燃えているようです
しっかり受け継がれた教訓 (スコア:2, 参考になる)
補足ですが、12月7日に金星周回軌道に投入予定の金星探査機あかつきに
搭載されたリチウムイオン電池にははやぶさで問題となった過放電に対して
対策が打たれているとの事でした。電池の使い方がはやぶさと決定的に
違うのは更に金星周回軌道に入る為、ミッション中は何度も金星の陰に
入って長時間駆動と電池の放電を繰り返す為、はやぶさの電池より容量が
大きいモノを開発して搭載した。と古河電気の解説員が語っていました
直近のあかつきですら既に改善された電池を搭載しているので
おそらくはやぶさ２は更に改善された電池が搭載されるかもしれません