H2A、DASH分離失敗は回路の誤配線 19
ストーリー by Oliver
間違った回路図でテストって 部門より
間違った回路図でテストって 部門より
永遠のロケットボーイ曰く、"やっとこさH2Aのロケット自体の打ち上げに成功したと思ったら、今度は分離に失敗して関係者が肝を冷やしたDASHだが、朝日新聞などの記事によると、失敗の原因はどうやら回路の誤配線にあった模様。
親がH2A開発関係者なだけに気が気ではなかったのだが、とりあえずH2A自体の問題ではなかったようで一安心。とは言え、某メーカー関係者はそれどころではないかも。ハードウェアのバグと言えばそうなのかもしれないが、あまりに致命的すぎるミスに、我が身を振り返って背筋に寒いものを感じてしまった。6億円…。"
嵌合面か配線面か (スコア:2, 興味深い)
あまりにピン配置が違ってると、図面チェックで流石に気が付くでしょうからね。
嵌合面視の図面はピン配置が逆向けに見えますから、逆に違和感が無かったのかも。 :-p
っていうか、もしそういう理由なら、配線のミスというよりは、そもそも図面の読み方のハンドシェｰクが出来ていなかったという、情け無い話ですけど...
tink (tink@mail.le.to)
Re:嵌合面か配線面か (スコア:2, 興味深い)
宇宙開発事業団は図面通りにできてるかどうかのチェック。
動作チェックでも試験用の部分を試しただけ。
実動部位は調べなかったようです。
NECは完成品をテストしなかったのかな？
Re:嵌合面か配線面か (スコア:1)
しっかりしてよNEC!
設計図の写し間違いってどーゆーこと!
三菱に全部もってかれちゃうよ。
Re:嵌合面か配線面か (スコア:0)
そりゃ無理でしょ。１社で作れるものだと思ってるの？
Re:嵌合面か配線面か (スコア:1)
よく、ありがちだけど、間違った図面に基づいたテストをしたんじゃないでしょうか？
そういうテストなら当然パスしますよね。
＃でもナゼ受入検査にかからない？＞NASDA
気をつけよう (スコア:2, 興味深い)
で済ませてはいけない問題なのではないかな，と思います． 責任のなすり合いだけでは何の進歩もないですし，きっと同じミスが起こると思います．
むしろ，「どうしてこのミスが最後まで残ってしまったのか」「ミスを確実に取り除くためにはどのような工程管理を行ったらいいか」という観点に立って調査・検証していかなくてはならないのではないかな，と．
「人間はミスをし，機械はは故障する」電力会社の CM のセリフですが，このことを前提とした開発のシステム作りが必要，ということなのでしょう．
話変わって，「責任問題」ですが，発注元（なのかな）である宇宙研にもある程度の責任があるのではないかな，と思います． 検査・検収の体制が不十分，というあたりはあるか，と．
私の昔の仕事で，発振モジュールの設計の不具合を発見して，業者とやりとりしたことがありました． そのモジュールが私の会社向けに設計されたセミカスタム品で，開発当時の私の会社の検証で「合格」とされていたので，「検証がいい加減だった弊社側にも責任はあるよね」ということで，賠償なんかの話にはなりませんでした．
試験用端子っていったい… (スコア:1)
まあ、普通の電子回路の基板も通常の端子のほかに試験用の端子があったりするから、そんなもんなのかもしれませんね。
火工品（でよかったっけ？）を取り付けずに、実際とまったく同じ端子で試験できれば、今回のようなことは起きなかったのでしょうけど。
せっかくの高速再突入試験機が…。
もったいないことをしたもんです。
masamic
Re:試験用端子っていったい… (スコア:1)
ソフトでいうと、肝心の実行部分をコメントアウトしたまま納品ってやつだね・・・
Re:試験用端子っていったい… (スコア:1)
Re:試験用端子っていったい… (スコア:1)
> ソフトでいうと、肝心の実行部分をコメントアウトしたまま納品ってやつだね・・・
スクリプト言語で無い限り、こいつは表面化しませんです。
テスト・受入は実行形式でやられるためです。
コメントアウトしたとしてもメイク・ビルド・コンパイル（どれかお好きな物を）しなければ問題無しです。
不具合通知を受けて修正して現地でインストールする時は、大抵ソースその他一式を持っていってリコンパイルするので表面化しません。
#まぁ、ばれなければですが、開発会社内では指摘されて
#上司から袋叩きでしょうけども（＾＾；。
ある意味、ハードはスクリプト言語に近いですね。
#そのまま実行されるし、実行されない部分はそこが
#実行されるまで、バグに気付かない。
##えっ、コンパイル言語でも同じ？。その通りです＞僕
まぁ、こんな事をコメントしたのも、ＮＴスペースのＮＡＳＤＡ地上設備のＬＡＮ構成も駄目駄目だからです。
ＬＡＮを一切冗長化していません。各装置はＬＡＮケーブル1本で結ばれています（全てがです。）。
それなのに、
「運用中にＬＡＮケーブルが抜けたらどうなるのか。そのときの対処をソフトウェアでしてください」
とネットワークのド素人がシステムを設計したような造りになっています。
#そんなんしらんってに!。プロトコルもださださだし。
#SYN/ACK/SYN/ACK以前にハンドシェイクも知らんようだし。
以上、ちょっとした愚痴です。
-----------
今週の標語：愚痴は吐かずに居酒屋で食べよう！
-----------
閑話休題
よくある話なんですが (スコア:1, 興味深い)
２．それの検査を怠った側（ここでは「NASDA」）が悪い。
のどちらが悪いのか、というのは、あまりにも「使い古された」議論です。
なぜならば、宇宙ロケットのような複雑な技術では「人為的ミス」そのものは「ある」ことを前提として、製品の製造や検査というシステムが「何重にも」できあがっている、ということがあるべき姿だからです。この「システム」全体を見直さないと、今後も同じような事故は起きます。実際、これまでのシステムはそうなっていないはずがない。
普通、「訴訟を起こした側」は「はらを立てた」から、そうなった、ということで、「被害者」と見られがちですが、こういうものの製造に関しては上記の通り官、民混ざり合った複雑で大きな体制の中で行われているはずなので、100%どちらかが悪い、ということは通常ありえません。
ということは、今回の訴訟、そして前回の「不正アクセス」のNASDAがらみの問題は、なんらかの「意図的な」背景がある可能性が非常に高いと思います。その根拠は、
１．報道がNASDAの一方的主張のみであること
２．相手が「NEC東芝スペースシステム」のみであること
３．今までも同じようなことは大小含めあったはずなのに、今回だけ報道が大きい
という事実から、そう考えることができます。
きっと、予算を減らされる前に、担当役人のクビをつないでおくための、これは方便に使われた可能性も否定できません。私は内情を知っているわけではないけれども、経験上、そういうことは十分にかんがえられますね。
Re:よくある話なんですが (スコア:1)
か？
宇宙開発というプロジェクトの存続自体が危機的状況の現在、
以前なら
「しょうがねえなあ。失敗は避けられんし、あんたのとこが
抜けても困る。次はしっかりやってよね。」
というところで穏便に済ませていたところが、そのようなやり方
をする余裕がない、そして対外的な説明ができなくなったという
ことでは？
以前から言われていた情報の透明化が進んできた徴候かな、とも
思いますが。
＃以前と同じような落としどころを考えていたところに、
＃不正アクセスの件が発生して逆鱗に触れて切られたとかは
＃あるかもしれませんけどね。
某社の陰謀もありえる (スコア:0)
Re:某社の陰謀もありえる (スコア:0)
Re:よくある話なんですが (スコア:0)
元記事のどこにも訴訟を「起こした」とは書いてないですけど？「損害賠償などを含めて対応を検討する」ですよね。宇宙開発関係で、本気で損害賠償を求めることはまず無いです。
1. ロケット飛ばすときには当然保険に入ってるので、言われているほど金銭的な被害が大きいわけではない（もちろん、直接的な金銭以外に沢山のものを失ってますけどね）
2. 打ち上げ失敗の金銭的な責任をメーカが負うのであれば、（リスクと予算を天秤にかけて）明らかに商売が成立しないので、現在宇宙開発事業に関わっている全国内企業が
Re:よくある話なんですが (スコア:0)
責任の所在はともかくとして、装置の予測不可能な故障ではなく、明らかに人為的ミスが原因でも保険でカバーされるんでしょうか？
Re:よくある話なんですが (スコア:1)
一般的な保険契約では、故意または重大な過失がないと免責(保険のカバー範囲から外れること)されません。「重大な過失」ってのは、故意と同一視し得るほどの怠慢を指していますから、今回の例は免責にはならないのではないでしょうか。
Re:よくある話なんですが (スコア:0)
Re:よくある話なんですが (スコア:0)
「本気で損害賠償を考える」ことを「報道発表」したことで、それと同等の社会的制裁は受けていると思うが。それも一方的な。
あと、５年くらい前の報道にそういうのがあった、ということを多くの人が忘れるくらい、まぁ、事業団は注目されていないのかな、と思いましたです。ハイ。