パスワードを忘れた? アカウント作成
16721 story

新しい材料には新しい検査が必要 77

ストーリー by mhatta
壊さず調べるのはむずかしいね 部門より

oddmake 曰く

Canada News Centreより。カナダ運輸安全委員会が11月22日、とある航空機事故について報告をまとめた中で、複合材料を使った部品の事故を防ぐにはこれまでとは異なる検査手法や指針が必要だとしている。
これは、2005年3月6日にエア・トランザット航空のエアバスA310-308機がラダーを損傷した事故への安全調査の最終報告である。問題のラダーはアラミド繊維のNomexからなるハニカム部分とそれを挟む炭素繊維強化プラスチック、外側に3枚のアルミ製の落雷防護用の板からなり、それらはガラス繊維強化プラスチックの部材によってまとめられていた。点検・補修は基準通りに正しく行われており、問題は見当たらなかったという。ただし、毎日の検査にはラダーが高所にあり検査者の視界が妨げられることなど、30ヶ月ごとの検査には視認可能な大きな傷以外は見落とすことなどの弱点があり、その有効性は限られたものだった。5年ごとのより綿密な検査もあるが、現行のtap testというコインのようなもので叩いて音を診る検査では、最終的に大きく成長して事故に繋がった内部の傷を、小さな段階で発見できずに見過ごしてしまったのだろうと運輸安全委員会では報告している。すなわち、今ある検査基準の想定では、複合材料・構造の部品を考慮に入れていないので、こうした部品でも事故が起きる前に確実に傷を検査できるような検査基準に改めるべきであると報告書は結論づけている。
超音波やX線やサーモグラフィーを例にあげ、そうした検査が他の部分では使われて有効性を発揮していたのに使われていなかったなどの記述もある。
新しい設計を取り入れたのに検査など他が古い基準のままであった事例に遭遇した話など、航空機に限らずスラッシュドット住民も自由に雑談して欲しい。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • コスト (スコア:5, 参考になる)

    by 335 (4199) on 2007年11月24日 8時59分 (#1254829) 日記
    >超音波やX線やサーモグラフィーを例にあげ、そうした検査が他の部分では使われて有効性を発揮していたのに使われていなかったなどの記述もある。

    航空機のコストの見積りは他の分野と違ってメンテナンスのコストを非常に重視します。
    一般的に、航空機の故障は、「故障しても破壊に至るまでに捕捉できれば良い」という発想があります。

    例えば、強度に関しては、単純な方法で(材料を増やして)強度をあげると直接燃費に影響するため、安全率を低く設定する、その変わりに保守の段階で検出できるように設計する。

    というように、航空機はメンテナンスによって得られる信頼性も、航空機自体のコストとして設計されています。

    コインタッピングとくらべて圧倒的にコストが高い非破壊検査方法が「実績があったのに使われなかった」というのは確かにそうかも知れませんが、おそらくそれを採用するとCFRPなどの複合材がそもそも採用できるかどうかのギリギリなのでしょう。(だから最近まで採用されてこなかった)。

    だから「実績があったのに使われなかった」というのは少し不平等な言い方だと思います。

    • Re:コスト (スコア:1, 興味深い)

      by Anonymous Coward on 2007年11月24日 10時24分 (#1254846)
      タッピング検査って、たたいて人が音で検知する方法?

      だとすると、今までの材料での経験は新しい材料では通用しないっていうのはないかな。
      検査する側も、経験が少ないからよくわからないだろう。
      で、見逃した、と。
      まぁ、検出器が人でなくても、同じことがいえるとおもうけど。

      もっと、こう、イメージングや数値化できるほうがわかりやすくて、安全かもしれない。
      親コメント
      • Re:コスト (スコア:5, 参考になる)

        by 335 (4199) on 2007年11月24日 14時42分 (#1254908) 日記
        >タッピング検査って、たたいて人が音で検知する方法?

        その通りです。超音波探傷の人間バージョンです
        CFRPの場合、ミルフィーユみたいな積層構造になっているので、欠陥がは
        いると、「カスっカスっ」という感じ、ちゃんとしてると「コツっコツっ」という感じ
        に聞こえます。

        金属の場合、本当は疲労を捕捉しなきゃいけないのですが、金属疲労での破壊はある程度
        見積りが可能ですし、塑性変形を伴うので異常があってもある程度表面からセンシング可能です。
        一方で、CFRPなどの積層複合材は表面が固まったまま、中で剥離してできた欠陥が急激に成長
        することが問題になります。

        >だとすると、今までの材料での経験は新しい材料では通用しないっていうのはないかな。
        >検査する側も、経験が少ないからよくわからないだろう。

        たとえば、トンネルなどのコンクリート検査ではハンマーで叩く方法が用いられてき
        ました。CFRPの成形をしている人なら経験はありますが、飛行機の整備をやってるひ
        とがそういう経験を持っているかは分かりませんね。ただ、練習すればできるように
        なる技術だし、彼らはそれが仕事です。

        いずれにしても、航空機の設計者は技術的な見積りをしたけれど、検査現場が対応しき
        れていないからリスクが増えたのか、設計者の見積り自体が根本的に甘すぎて潜在的な
        リスクが大きいのかというのを区別して検証したいところですね。

        親コメント
    • by OddEye (18936) on 2007年11月24日 10時25分 (#1254847)
      >一般的に、航空機の故障は、「故障しても破壊に至るまでに捕捉できれば良い」という発想があります。

      この表現はよくわからない。
      「故障」というのは、フォールト・トレラントが確保されていることが前提の故障だろうか?
      「破壊」と言うのは、割れたり欠けたりする程度でなく、完全に千切れたりしてラダーなどが機能を失うことを言っているのだろうか?

      すると、何らかの機能不全が起きる前にちびちび壊れるようになっていて、その段階で修理、交換するとか、そういうことだろうか?
      でもそんなうまい具合に壊れてくれるものだろうか?

      新幹線の車軸などは蛍光探傷(全般検査時)、超音波探傷(交番検査時)、さらに定期的に交換と、かなりコストかけているように思える。1本折れても代替が効かないからかもしれないが。

      ラダーは複数系統あれば代替が効くだろうけど、主翼支持など主要部分はそうもいかないだろうな。
      親コメント
      • Re:コスト (スコア:5, 興味深い)

        by 335 (4199) on 2007年11月24日 15時20分 (#1254925) 日記
        >すると、何らかの機能不全が起きる前にちびちび壊れるようになっていて、その段階で修理、交換するとか、そういうことだろうか?
        >でもそんなうまい具合に壊れてくれるものだろうか?

        基本的にはそういうことになっていて、うまい具合に壊れてくれないと現実に困ったことになります。大げさな言い方をすれば、検査工程が機能しないと航空機の場合いずれ墜落しうる設計となってるけど、自動車の場合そもそも多少壊れたからといって致命的な事故がおきるような設計にはしません。

        だから、航空機の検査とその他の機械の検査は意味合いが少し違うのです。メンテナンスをさぼったら致命的な事故になる自動車だったらリコールの対象になりますが、航空機はそもそもそういう設計手法をとっているということもできます。

        事故で航空機メーカーが責められるとき、整備検査工程に問題があったと航空機メーカーがしばしば主張できるのは、設計段階から整備検査工程に安全性を担保していることを皆が理解しているからです。自動車メーカーだったらそんな主張は許されないでしょう。

        親コメント
      • Re:コスト (スコア:4, 興味深い)

        by Another_View (29838) on 2007年11月24日 15時11分 (#1254924) ホームページ 日記
         旅客機にはリダンダンシが確保されている部分とされていない部分があります。
         ラダーを動かす油圧系統はリダンダンシが確保されていますが、ラダーそのものは1つしかありません。構造上、複数つけるのは難しい(双尾翼?)。
         破壊というのは文字通りで、そのパーツは担当していた機能を果たせなくなる状態のことでしょうね。

         原則として旅客機は、あなたのおっしゃるように「うまい具合に」壊れるように設計されています。早い段階で破損を検出し、修理・交換するわけです。重厚長大産業の現場に普及している3次元CADのCATIAは、元々航空業界で開発されたものです。

         旅客機のメンテナンスとは金属疲労に対する戦いでした。元祖ジェット旅客機のコメットは金属疲労が元で落ちました。結論としては、金属疲労をなくすことは不可能であるから、検査を徹底した上で不良パーツはどんどん交換することになっています。
         一方で経年劣化の避けられない金属をやめ、新しい材質を使うことも広く試みられてきました。軽くて丈夫なそれら新材質を使用すれば、より多く積めるし、検査や交換の頻度も減らせて、旅客機の運航コストを下げられることを期待しています。

         ですが、残念ながらそう上手くはいかなかったみたいです。設計段階では、このように内部破損することは予見できなかったのでしょう。

         鉄道と比較するのは不適当です。鉄道ってのはコストに優れているし、そもそも新幹線なんて国が作ってくれたんですから。でも、鉄道じゃ海を渡れません。
         旅客機は世界的な過当競争の中、ギリギリのコストでやっています。JALは国営企業でなかったら大昔に破綻していたでしょう。ANAだって国が保護していた国内線を主戦場にしていたから、なんとかなったわけです。こうした措置はもうありません。
         燃料高騰やテロ対策も相まって、航空会社はコストに大変にシビアです。航空機製造業者もコストに優れた飛行機を開発しなきゃ買ってもらえません。その辺を度外視したら、航空券が高すぎて客が乗りません。
        親コメント
        • Re:コスト (スコア:3, 参考になる)

          by Anonymous Coward on 2007年11月24日 18時16分 (#1255017)
          鉄道でも台車や車軸のように、リダンダンシを持たせることができないsingle point of failureな場所と、それ以外を区別する発想は少しはあります。
          ただ重量制限が航空機ほどきつくないので、何でもとにかく壊れないように頑丈に作るという発想なんですね。
          必要性があまりなかったから、製造時とメンテナンスでうまく分担してコストと重量を最小化するという航空機の設計の考え方には到達しなかったわけです。
          また、たいていの場合鉄道のコスト構造は人件費が大部分を占めていて、航空機ほど機材の減価償却費は大きくないということと関係しているのかもしれません。

          それと、とりあえずその場で列車を止めてしまえば絶対安全という鉄道と、止めては絶対にいけない航空機の発想の差もあるんでしょうね。
          鉄道は、何かあったら必ず止まるようなフェールセーフ設計にするということだけ考えられていて、そこで思考停止しているという主張も聞いたことがあります。

          でもって細かく突っ込みを入れると

          > 新幹線なんて国が作ってくれた

          国鉄時代の新幹線開業区間の建設費は国鉄の自己負担です。
          それがために国鉄の債務が膨れ上がって破綻して、結局国民負担に付け回されたという意味なら、確かに国が作ったことになるのかもしれませんが、
          JRが新幹線保有機構から新幹線設備を買い取った時の価格は当時の実勢価格以上だったので、新幹線分は鉄道が全額自己負担しているともいえます。
          整備新幹線は国が建設して保有していますが、JRは運行にあたって線路使用料を払っています。
          国が空港を建設して、着陸料を払って航空会社が利用しているのと同じです。
          航空機は鉄道のように経路上の路線を造る必要がないので、鉄道側の視点からはインフラも全部国持ちで「航空機はコスト面で有利」に見えます。
          親コメント
          • by OddEye (18936) on 2007年11月24日 19時31分 (#1255050)
            航空業界の、ダンピングのようなディスカウント攻勢は、ほんとハラハラするほどの勢いですね。
            ある程度の安全マージンを定量化して歯止めをかけないと危ない領域に突っ込みそうな気配さえ。
            新幹線は、規制もあるだろうけど、ある意味「自制」しているかのような高値安定。

            飛行機野郎のベンチャー気質と、安全確実を旨とする鉄道マンの違いだろうか?
            親コメント
            • Re:コスト (スコア:3, 参考になる)

              by Another_View (29838) on 2007年11月25日 1時12分 (#1255177) ホームページ 日記
              最近は燃油サーチャージだの航空保険だの取られますけどね。

              ヒコーキは空気を運ぶよりは多少の金を取ってでも人を乗せた方がいいわけです。ここに航空業界の抱える、根本的なディスカウント合戦のインセンティブがあるのです。

              とはいえ今時の料金でも黒字運行するために、航空会社はなかなか努力してますよ。目に見えるところでは、パイロットは3人から2人になったし、フライトアテンダントはずいぶん減らしたし、機内の飲食物もだいぶケチってます。目に見えないところでは、ヒコーキ自体が燃費が良くて故障の少ない、経済的な機体になりました。一つの便を複数の航空会社で集客することで(共同運航便)、搭乗率を向上させて不採算路線を整理することができました。先物市場に乗り込んで、燃料を確保することまでやってます。などなど。

              旅客機の安全性の確保は、法律や各種規制で細かく定められています。旅客機ではつまらんコンデンサの一つを交換するときでも、製造メーカの指定部品しか使えません。

              ま、それを遵守するかは航空会社の気質次第です。我が国の航空会社は高いレベルで遵守していますが、他ではそうでもないところもあります。
              親コメント
  • 安全係数 (スコア:3, 興味深い)

    by NOBAX (21937) on 2007年11月24日 11時16分 (#1254860)
    飛行機は過度に安全係数をとると重くなって飛びませんから、
    ギリギリの安全係数で設計して、その代わりに検査で問題点を摘出するというアプローチしか取れません。
    また、いったん飛び立ってしまえば着陸するまで修理は出来ないし、あちこち飛び回っているので、
    どの時点で修理をするかを決め、必要機材を先回りして準備しておかなければいけないといった事情あり、
    予測ということが重要でしょう。
    これが地上の構築物であれば思いっきり安全係数を掛けて、検査を軽くするという
    ライフサイクルコストを考えたアプローチも取れるのですが。

    ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。
    事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
    • Re:安全係数 (スコア:2, 興味深い)

      by OddEye (18936) on 2007年11月24日 11時34分 (#1254863)
      >ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。

      ただ、インターネット世代だと、日々出てくるセキュリティホールや、時代の変化による陳腐化に晒されるといった類のソフトウェアもあるので、定期的な見直し、修理点検も必要といえば必要ですね。

      >事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。

      これも、広くいろいろなハードウェア、条件でインストール、実行されると、思ってもみなかった不具合が出て来たり。
      オープン化以前の、用途特化した汎用機の時代のほうがやりやすかったのかも。
      親コメント
    • Re:安全係数 (スコア:2, 興味深い)

      by Anonymous Coward on 2007年11月24日 15時42分 (#1254931)
      >ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。

      裏を返せば恐ろしい事実が浮かび上がってきますね。

      つまり、ソフトウェアでは、
      上の人たちが話していたようなリアル物と違い、
      「予測不可能な」壊れ方が大半を占める、ということになるので。

      リアル物の疲労とかの壊れ方は、ある意味で予測可能なんですよね。
      これくらいの力がかかってるから確率的にこれくらいの時期に駄目になるだろうとか。

      ところがソフトはその発想が通用しない。
      時間によって壊れるのではない。
      実は最初から壊れてるだけで、それが発覚してないだけ。
      それがバグ。
      だから全く予想不可能なタイミングでとんでもない大バグで壊れたり…もとい実は最初から壊れてたのが発覚したり…する。

      お仕事開発(つまり企業)においてしばしばイタイとされてるのは、
      この「予測可能性」について勘違いしまくった人が開発工程を決める、
      という状況だと思います。

      #某通信系大手に「バグ率」という言葉を散々振りかざされてウンザリしたのでAC
      #バグが多いならまだしも、少な「すぎ」てもペナルティを科されたんだよね…
      #もしウチの社員がテメーラより3倍優秀だったらバグも1/3になることは全然おかしくないだろうに…
      親コメント
    • Re:安全係数 (スコア:1, 興味深い)

      by Anonymous Coward on 2007年11月24日 15時05分 (#1254918)
      ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。
      事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
      そうでもありませんよ。
      運用環境の違いや、それに合わせたコンフィギュレーションの差異なんかは個体差といって差し支えないし、そのような設定の変更を繰り返すうちに元に戻せなくなる場合も珍しくはない。交換=再インストールで解決したりとかね。
      これをオペレーションの問題でありソフトの不備では無いと言い張るならそれで構わないけれど、現実にはそんなに厳密なオペレーションが可能な設計でもなければマニュアル等が完備されてるわけでもない場合が珍しくないわけです。そのような不備をも含めて「バグ」と称するなら確かに元コメントの言うとおりではあるけれど、見方によっては「ソフトウェアも経年劣化や疲勞を起こすし、そうなったら交換すれば良い」という考えの元、コストダウンを図っているといえなくもないでしょう。

      個人的にそれよりも気になるのは「ソフトウェアに製造工程はなく試作品がそのまま出荷される」ということをよく理解してない開発者が非常に多いということですね。敢えて飛行機ではなくガレージキットで例えさせてもらいますが、ガレキなら試作品、つまり原型が「切った貼った削った盛った」のツギハギだらけであろうと、型さえしっかり取れば量産品は継目なしの一体成形で出荷することもできるわけです。ところがソフトウェアの場合、出荷される製品はあくまで試作品のコピー、ツギハギまでも含めた良くも悪くも完全なコピーなのです。
      酷い場合、バグを潰すのではなく、バグによって壊されたデータの修正ルーチンを別途組み込む、といった場当たり的なツギハギが、必然性もないまま放置され、出荷されてしまうことすらも。で試験に漏れた特定の条件で修正ルーチンが走らなかったり、2回以上走ったりとか。
      親コメント
    • バグがあろうが無かろうが、世の中には仕様変更という悪魔が居るんですよ!
      バグを潰しきったなんて、そんな夢物語!

      最近なんてハッピーマンデー砲なんて軍事兵器が投入されたばっかりでありますよ!?
      たとえ、バグがあろうが無かろうが、安全では無いし、経年劣化を防ぐためにメンテナンスは必要なのであります!

      ソースコードのフリーズ=メンテナンスの放棄なんて勘違いはしてないと思うけど!
      親コメント
    • by Anonymous Coward
      >事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。

      組み込み系、特にメカがかかわる奴とか、デバイスドライバ、あるいは通信系の低いレイヤーでは
      個体差、というか条件によって発生する問題もありますからね。
  • 検査項目の策定 (スコア:3, 参考になる)

    by pongchang (31613) on 2007年11月24日 12時53分 (#1254880) 日記
    国産旅客機に対するJAXAの貢献 [www.jaxa.jp]によると、そもそも新材料はなにをテストすれば、耐空証明を交付して良いという行政判断をくだせるか?という所から、検討しないとダメだという話らしい。
  • ITでも (スコア:2, 興味深い)

    by Anonymous Coward on 2007年11月24日 9時19分 (#1254831)
    IT畑でこれに似た話といえば、たとえば、

    新しい開発形態には新しいレビュー形態(視点)が必要

    ってことだな。

    例えばOOPコーディングを従来の手続きオンリーの視点で(だけ)レビューすると、的外れなレビュー結果が出かねない。

    (だからOOPをやめる、ってのは適切とは限らないぞ)
    • by nonta2005 (31048) on 2007年11月24日 10時58分 (#1254853)
      んー、手法寄りな喩えですな。
      トピ名が「材料」に寄ってるから、ここはプロジェクトで採用するフレームワークやライブラリの話の方が広がるかも?

      行数だけでプログラムの規模や品質測られるよーな笑い話も、減って来てると信じたい昨今ですし
      親コメント
      • by Anonymous Coward
        でもさあ、行数以外の測定方法の決定打がないんだもん。
        何かある?

        # ファンクションで測ろうったって「重み付け」で勘が入るし
        # 機能の複雑さは普通行数に比例するべ?と言われちゃうし
        • Re:ITでも (スコア:3, おもしろおかしい)

          by Anonymous Coward on 2007年11月24日 20時03分 (#1255066)
          ># 機能の複雑さは普通行数に比例するべ?と言われちゃうし

          逆に考えるんだ。

          「言われちゃう」のが不味いと考えたらどうだろう?
          つまり、その論拠の無い方法論に対して、
          これまた論拠の無い別の方法論をぶつけてみるんだ。

          「ためしに今日から関数の数でカウントすることにしまーす」
          とかね。

          そうするとあーら不思議、
          みんなみんな、関数分割をやたらと積極的にやるようになるぞ!
          もちろん昨日まで分割に消極的だったマネージャもだ!
          そしてその方向性に難色を示していた老人たちは即効で首だ!

          …なんか凄く幸せになるんじゃねーかこの方法論って?(w

          つまりさ。
          品質(あるいは生産性でもいいよ)を測る基準として、
          わざわざコードの質が実は下がることが経験的に判りきってる基準を
          採用するのを止めればいいんだ。
          実はコードの質を上げるかも知れない方法論に
          こっそり摩り替えてしまえばいいんだ。

          どーせ何で測ったらいいか判らないんだったら、
          それを悪用というか口実にしてしまって
          都合のよいやり方をやってしまえばいい。

          もちろんお客だって何も損をしてない。
          良いコードのほうが結果的にメンテしやすいという意味では
          お客のためにもなっている。背信行為は全く無いぞ。
          親コメント
          • by nim (10479) on 2007年11月26日 11時04分 (#1255586)
            >「ためしに今日から関数の数でカウントすることにしまーす」

            MAXLENGTH = 256;

            の代わりに、

            int getMaxLength(){
                return 256;
            }

            なんてのがはびこるならまだしも、

            int syutoku256(){
                return 256;
            }

            みたいのが大量に繁殖したコードが目に見えるようなんですが。
            親コメント
    • by bee (10028) on 2007年11月24日 14時56分 (#1254916) ホームページ 日記

      少し前までは、 コードカバレッジというのがもてはやされていました。要はプログラムの全箇所テストしたらバグは無い、とするものです。

      NTのおかけでマルチスレッドが普通に使われてくるとプログラムのある箇所と別のある箇所が同時に走行すると間違える、というケースが出てきました。こうなるとカバレッジ解析だけでは不足してしまいます。

      こういったマルチスレッド観点での試験方法が必要なのですが、なかなかやり方を変えようとはしてくれません。困ったものです。

      親コメント
      • Re:ITでも (スコア:2, 興味深い)

        by 335 (4199) on 2007年11月24日 15時43分 (#1254932) 日記
        それは多分マルチスレッドな部分で実際にスレッド同士がやりとりする箇所が少くて

        そこだけ注視すればよいと理解されているからではないでしょうか?

        あるいはスレッド同士のインタフェースを少くする(可能なら隠蔽する)よう
        に設計せよということじゃないでしょうか?

        親コメント
    • by Anonymous Coward
      >例えばOOPコーディングを

      オブジェクト指向プログラミングコーディング?
  • 先日のF-2の事故 [youtube.com]は、センサーの配線間違いが原因とのことでしたが、それが大きな事故につながってしまったのは、Fly-By-Wire(FBW) [jal.co.jp]機ならではのことだと思います。離陸直後に発覚したのは不幸中の幸い?

    FBW機の場合は電気系統が命なので、空自のF-2以前の従来型機と比べて電気系統の信頼性の重要さが違うことでしょう。整備にミスがあったとしても、どうして実際に飛ぶ前にそれを検知できなかったのかが不思議です。コネクターの事情はわかりませんが、同じ部品を使っているとすると、なおさらそれを間違えないあるいは間違えても致命傷にはならないような仕組みや点検体制にするとか、点検用のプログラムがあるとすれば、それを検出できるようにしておく必要がある気がします。前提が変われば、当然何をどのレベルで点検しないといけないかは変わるんではないでしょうか。

    ある系統にどんな問題が起こりうるか?またその時どんな事が起こりうるか?というのは、他のコメントにもあるように、例外処理を考える(バグつぶし)という話になると思いますが、それをどうやって知るかというのは、やはりその作動原理や特性、設計の意図、実装方法、どんな状況で操作されたり動作するかなどをどれだけ理解・把握できるかにかかってくるんでしょうか。今回のF-2の場合は、システムの設計としては飛行中、運用中のトラブルは考慮していても、社内整備中のトラブルは整備士を信頼して考慮していなかったのかな?

    ある意味、あらゆる分野に共通する教訓を残してくれた事故だと思います。
    • >センサーの配線間違いが原因

       一般の家電でさえ、内部の基板間のハーネス等のコネクタは、各々ピン数を変えておくとかして誤接続を防止するのが普通ですよねぇ。
      #/.erには、家電が故障したらとりあえず分解する(直せるかは別)人が多いと思いますので、本職じゃなくてもそういう種族なら納得して頂けるかと。
       もっとも、大量生産しない産業機械では、コネクタに貼られたラベルやケーブルのマークチューブが唯一の手がか(省略されました

       以下の点が問題、だと思います。
      ・誤配線「できてしまう」設計だったこと
      ・そして、そんな設計が通ってしまったこと
      ・さらに、欠陥がわかったのに、応急手当的な処置で済ませた [google.co.jp]こと

       応急手当ではまずいことは設計者自身がよくわかるはずなので、何故根本的な対策が取れなかったか、が最大の問題ではないでしょうか。
      #コの業界からそんな話をよく聞くような…

      >ある意味、あらゆる分野に共通する教訓を残してくれた事故だと思います。

       教訓ではありますが、50年ほど前に通り過ぎているはずの道でもあります。
      Mark-Iの最初の2台は、テスト時にコネクタの逆差しで機能を失った。コネクタは直ぐに逆差しを防ぐ設計に直された。
       1959年にMarkIはポラリスに搭載されて初飛行したが、(略)
      水城 徹 [biglobe.ne.jp], 2005, 宇宙の傑作機 No.10 アポロ誘導コンピュータ, 風虎通信, から引用)
      親コメント
      • もっとも、大量生産しない産業機械では、コネクタに貼られたラベルやケーブルのマークチューブが唯一の手がか(省略されました
        応急手当ではまずいことは設計者自身がよくわかるはずなので、何故根本的な対策が取れなかったか、が最大の問題ではないでしょうか。
        憶測ですが、戦闘機の場合は国内でオーバーホールしているのは1カ所 [google.co.jp]だけなので、部隊レベルで整備しないような箇所は整備作業員の正確な作業とチェック体制を担保として、誰が整備するか分からない自動車や一般家電ほどの部品側での徹底的な対策はとられていないのかもしれませんね。

        にしても、ハーネスの長さにまつわる設計と艤装のズレの問題も今に始まったことではないでしょうし。自動車でも、ハーネスが設計よりも長めに取りつけられていて、設計上は接触しない他の部品と接触して問題が起きてリコールなんていう話を聞いたことがあります。
        親コメント
        •  「部隊レベルで整備しないような箇所は整備作業員の正確な作業とチェック体制を担保として」なんてことがあったら、それ自体が大問題でしょうねぇ。

           #1255160 [srad.jp]にて、「マーフィーの法則ですなあ。」とのコメントがあります。ホント、まさにマーフィーの法則です。
          「線形減速に対する人間の耐性I(後ろ向きに座った姿勢の予備調査)」のため、1949年5月、カリフォルニア州のミューロック空軍基地(現・エドワーズ空軍基地)に来ていたマーフィーは、トラブルを起こした装置を調べて誰かが間違ったセッティングをしていた事を発見した。(中略)ここで彼の言った台詞 "If there is any way to do it wrong, he will." 「失敗する方法があれば、奴はその方法でする」がこの「法則」の土台となった。
          (マーフィーの法則 - Wikipedia日本語版 [wikipedia.org]より。枝葉末節を一部削除)

          #自己コメント訂正
          #>50年ほど前に通り過ぎているはずの道
          # 60年ほど前でした。

           仮に、何らかのミスが発生する可能性のある箇所が、1万箇所あるとします。
           で、各々にてミスが発生する可能性を1万分のとすると、ミスが1つ以上ある可能性は 63% あります。
           ミスの発生可能性を10万分の1としても、1万箇所あれば、同じく 10% です。
           そんなわけで、多数の要素からなるモノは、各々に失敗する可能性があれば、何処かで失敗して全体がダメになります。対策は、「失敗の可能性そのものを虱潰しにする」ことしかないでしょう。

          >自動車でも、ハーネスが設計よりも長めに取りつけられていて、設計上は接触しない他の部品と接触して問題が起きてリコールなんていう話を聞いたことがあります。

           自動車でやっちまうことなら、航空機でもやっちまうでしょうねぇ。

           失敗が即致命的な損害を生じるのでなければ、とりあえず動かしながらミスを発見していく、というやり方もよくありますね。
          #非常停止ボタンに手をかけながらそろりと試運転するとか
           もっとも、これはこれで色々楽な方法ですけど、まだ発覚していないミスが何処かに眠っているかもしれないという懸念がつきまといます。
          #なんだか、ソフトウェアの事を書いているような気がしてきました…。
          親コメント
    • by 335 (4199) on 2007年11月24日 16時12分 (#1254945) 日記
      >先日のF-2の事故は、センサーの配線間違いが原因とのことでしたが、それが大きな事故に
      >つながってしまったのは、Fly-By-Wire(FBW)機ならではのことだと思います。

      たしかにFBWならではなのですが、戦闘機ならではということもできます。戦闘機というのは航空機の中でもさらに特殊です。通常、旅客機のような普通の飛行機は、主翼に上反角というのがあります(翼が上に反りあがる)。重心が下側にあるので、これは飛行中に姿勢が安定になるように作用します。

      一方、最近の戦闘機は上反角がほとんどない、あるいは無いので、力学的には完全に不安定です。これは運動特性を向上させるためです。したがって、安定性はデジタルサーボに完全に依存しています。それを失えば墜落するしかないですし、そのセンサーの方向を間違えたとなれば自動的にひっくり返ります。

      航空機の設計者が、こともあろうにF-2やF-16のように実績のある機体にそんな分かりやすい悪質な欠陥を作るはずがないし、あったとしたら三菱重工はともかくロッキードがそんなにあっさり認めるはずがない、っていうか犯人みつけろよ、ぐらいの悪質な欠陥です。

      F-2の件はミスというよりも、故意に配線が変えられたと考える方がずっと自然です。

      親コメント
      • by Anonymous Coward on 2007年11月24日 17時03分 (#1254980)
        故意かどうかは知りませんが、配線の欠陥は製造時から [google.co.jp]だそうです。
        ピッチとヨーの並行する配線のコネクタを並べると誤接続の危険があるので、
        わざと前後にずらして配置し、間違えたらケーブルが届かない設計にしていたはずが、
        なぜかゆとりが大き過ぎて届いてしまったというオチ。

        思うに、離陸前の点検では、従来どおりスティックとペダルを操作して、
        各舵面が動くこと位は確認していたはずです、憶測ですが。
        ところが空中ではパイロットの操縦に加えてコンピュータによる補正がかかるのですが、
        コンピュータへの入力が見当違いだったために目茶苦茶な補正をされて墜落に至ったと。

        まあ憶測ではありますが、大もとのコメントのいうように、
        旧来の検査手順では新しい概念に基づく設計に対処できなかった例、
        といえる可能性の高い事故じゃないかと思います。
        親コメント
      • by Anonymous Coward on 2007年11月24日 16時43分 (#1254965)
        >こともあろうにF-2やF-16のように実績のある機体に

        F-16はともかく、F-2は開発時点でかなりの新規開発をしているんじゃないの? とくにFBWがかかわるところは。
        それとも、そのへんはF-16そのままなんだっけ?

        >F-2の件はミスというよりも、故意に配線が変えられたと考える方がずっと自然です。

        「自然」であっても実際そのとおりかどうかは分からない。
        ちょっと断定するには根拠がなさすぎるという気がしますけどね。

        # 中の人で、通常しられている以上の情報に基づいての発言でしたら別ですが
        親コメント
    • by Anonymous Coward on 2007年11月24日 15時51分 (#1254938)
      >コネクターの事情はわかりませんが、同じ部品を使っているとすると、なおさらそれを間違えないあるいは間違えても致命傷にはならないような仕組みや

      コネクターという奴は、ソフトウェア畑でいえば、設定ファイルのようなものだと思います。

      あるいは最近流行の「DI」なんかもコネクタのようなもんだと思います。

      工場で作る時点では何処に繋がるかは未定で、実働するときに初めて繋ぐべきところに繋いで、それで動作するようになる。

      ソフトウェアも設定(ファイル)を多くすればするほど、「差し違え」のリスクを抱えることになりますね。まあコネクタ(設定ファイル)を刺した状態で結合テストをしろってことでしょうけど、煩雑なのは確かです。

      それにしても設定ファイルってのは変なものです。もともと「ソフト」ウェアつまり変形が(ハードより)容易なのが売りだったはずなのに、気付けばアプリ本体を変更することを避けて設定ファイルを外出しにするようになってしまった。
      親コメント
typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

読み込み中...