新しい材料には新しい検査が必要 77
壊さず調べるのはむずかしいね 部門より
Canada News Centreより。カナダ運輸安全委員会が11月22日、とある航空機事故について報告をまとめた中で、複合材料を使った部品の事故を防ぐにはこれまでとは異なる検査手法や指針が必要だとしている。
これは、2005年3月6日にエア・トランザット航空のエアバスA310-308機がラダーを損傷した事故への安全調査の最終報告である。問題のラダーはアラミド繊維のNomexからなるハニカム部分とそれを挟む炭素繊維強化プラスチック、外側に3枚のアルミ製の落雷防護用の板からなり、それらはガラス繊維強化プラスチックの部材によってまとめられていた。点検・補修は基準通りに正しく行われており、問題は見当たらなかったという。ただし、毎日の検査にはラダーが高所にあり検査者の視界が妨げられることなど、30ヶ月ごとの検査には視認可能な大きな傷以外は見落とすことなどの弱点があり、その有効性は限られたものだった。5年ごとのより綿密な検査もあるが、現行のtap testというコインのようなもので叩いて音を診る検査では、最終的に大きく成長して事故に繋がった内部の傷を、小さな段階で発見できずに見過ごしてしまったのだろうと運輸安全委員会では報告している。すなわち、今ある検査基準の想定では、複合材料・構造の部品を考慮に入れていないので、こうした部品でも事故が起きる前に確実に傷を検査できるような検査基準に改めるべきであると報告書は結論づけている。
超音波やX線やサーモグラフィーを例にあげ、そうした検査が他の部分では使われて有効性を発揮していたのに使われていなかったなどの記述もある。
新しい設計を取り入れたのに検査など他が古い基準のままであった事例に遭遇した話など、航空機に限らずスラッシュドット住民も自由に雑談して欲しい。
コスト (スコア:5, 参考になる)
航空機のコストの見積りは他の分野と違ってメンテナンスのコストを非常に重視します。
一般的に、航空機の故障は、「故障しても破壊に至るまでに捕捉できれば良い」という発想があります。
例えば、強度に関しては、単純な方法で(材料を増やして)強度をあげると直接燃費に影響するため、安全率を低く設定する、その変わりに保守の段階で検出できるように設計する。
というように、航空機はメンテナンスによって得られる信頼性も、航空機自体のコストとして設計されています。
コインタッピングとくらべて圧倒的にコストが高い非破壊検査方法が「実績があったのに使われなかった」というのは確かにそうかも知れませんが、おそらくそれを採用するとCFRPなどの複合材がそもそも採用できるかどうかのギリギリなのでしょう。(だから最近まで採用されてこなかった)。
だから「実績があったのに使われなかった」というのは少し不平等な言い方だと思います。
Re:コスト (スコア:1, 興味深い)
だとすると、今までの材料での経験は新しい材料では通用しないっていうのはないかな。
検査する側も、経験が少ないからよくわからないだろう。
で、見逃した、と。
まぁ、検出器が人でなくても、同じことがいえるとおもうけど。
もっと、こう、イメージングや数値化できるほうがわかりやすくて、安全かもしれない。
Re:コスト (スコア:5, 参考になる)
その通りです。超音波探傷の人間バージョンです
CFRPの場合、ミルフィーユみたいな積層構造になっているので、欠陥がは
いると、「カスっカスっ」という感じ、ちゃんとしてると「コツっコツっ」という感じ
に聞こえます。
金属の場合、本当は疲労を捕捉しなきゃいけないのですが、金属疲労での破壊はある程度
見積りが可能ですし、塑性変形を伴うので異常があってもある程度表面からセンシング可能です。
一方で、CFRPなどの積層複合材は表面が固まったまま、中で剥離してできた欠陥が急激に成長
することが問題になります。
>だとすると、今までの材料での経験は新しい材料では通用しないっていうのはないかな。
>検査する側も、経験が少ないからよくわからないだろう。
たとえば、トンネルなどのコンクリート検査ではハンマーで叩く方法が用いられてき
ました。CFRPの成形をしている人なら経験はありますが、飛行機の整備をやってるひ
とがそういう経験を持っているかは分かりませんね。ただ、練習すればできるように
なる技術だし、彼らはそれが仕事です。
いずれにしても、航空機の設計者は技術的な見積りをしたけれど、検査現場が対応しき
れていないからリスクが増えたのか、設計者の見積り自体が根本的に甘すぎて潜在的な
リスクが大きいのかというのを区別して検証したいところですね。
Re:コスト (スコア:1)
この表現はよくわからない。
「故障」というのは、フォールト・トレラントが確保されていることが前提の故障だろうか？
「破壊」と言うのは、割れたり欠けたりする程度でなく、完全に千切れたりしてラダーなどが機能を失うことを言っているのだろうか？
すると、何らかの機能不全が起きる前にちびちび壊れるようになっていて、その段階で修理、交換するとか、そういうことだろうか？
でもそんなうまい具合に壊れてくれるものだろうか？
新幹線の車軸などは蛍光探傷（全般検査時）、超音波探傷（交番検査時）、さらに定期的に交換と、かなりコストかけているように思える。1本折れても代替が効かないからかもしれないが。
ラダーは複数系統あれば代替が効くだろうけど、主翼支持など主要部分はそうもいかないだろうな。
Re:コスト (スコア:5, 興味深い)
>でもそんなうまい具合に壊れてくれるものだろうか？
基本的にはそういうことになっていて、うまい具合に壊れてくれないと現実に困ったことになります。大げさな言い方をすれば、検査工程が機能しないと航空機の場合いずれ墜落しうる設計となってるけど、自動車の場合そもそも多少壊れたからといって致命的な事故がおきるような設計にはしません。
だから、航空機の検査とその他の機械の検査は意味合いが少し違うのです。メンテナンスをさぼったら致命的な事故になる自動車だったらリコールの対象になりますが、航空機はそもそもそういう設計手法をとっているということもできます。
事故で航空機メーカーが責められるとき、整備検査工程に問題があったと航空機メーカーがしばしば主張できるのは、設計段階から整備検査工程に安全性を担保していることを皆が理解しているからです。自動車メーカーだったらそんな主張は許されないでしょう。
Re:コスト (スコア:1, 興味深い)
三島駅でふざけててドアにはさまれて引きずられて死んだ高校生1人以外に
これまでに「乗客の」死者出してませんから。
飛行機と比べると安全度の桁が違いますし。
まあ、新幹線ってのはテロにはものすごく脆弱ではありますね。
今まで荷物チェックなんか受けたことないし。
Re:コスト (スコア:1)
最近は意外とテロのような兆候は新幹線から出てこない。
日航機の事故以来、国内での事故による死者は出ていない。これも立派な実績。
もちろん、ヒヤリとするようなインシデントは結構多い。特に管制にまつわる部分で。油断できない。日本の空は過密だし、手合図口合図に頼る部分が多い管制はいささか心許ないと常々おもう。
Re:コスト (スコア:1)
・塾通いか何かで新幹線を定期的に利用しており、帰宅時は新幹線の駅まで親に迎えに来て貰っていた
・車内公衆電話は通話料金が高いので、いつも一駅前?の三島駅で停車時間の間にホームから家に電話をしていた
ってことだったと思います。
まあ、あまり誉められた行動じゃないのは確かですが、ふざけて [goo.ne.jp]たわけではないでしょう。
#昔は停車時間の間に駅弁を買いに走るなんてのをよく見かけたものですが…最近は見かけないですね…
Re:コスト (スコア:1)
人間の反射速度とか筋力とか骨強度とかまともに耐えられるのはそれぐらいの速度まででしょうから
全力疾走中にこけると下手すりゃ死ぬ訳で
でも、移動距離辺りの事故率は徒歩の方が飛行機よりも高そうだなあ、死亡率も
Re:コスト (スコア:2, 参考になる)
http://www.koito-ind.co.jp/flying/index.html [koito-ind.co.jp]
によると、１６G程度の加速度、時速48キロで衝突しほぼ瞬時に停止したときの加重に対応
とあります。
っていうかこの書き方も意味不明なんだけど、だいたい衝突が0.1秒くらいで完了すると
思うと、時速48キロからの衝突相当なんでしょう。
というわけで、航空機のシートベルトは、地上でタクシーしてるときの衝突への対応と
乱気流による上下運動への対応ができる、という性質のものです。
「地を這う飛行機」である新幹線がシートベルト無いのは、効果を発揮するケースが
想定しにくいというのがあります。
単に極低速での事故へ対応するシートを設けるなら、同じ理由で全ての鉄道にシート
ベルトをつけることになってしまう。
Re:コスト (スコア:4, 興味深い)
ラダーを動かす油圧系統はリダンダンシが確保されていますが、ラダーそのものは１つしかありません。構造上、複数つけるのは難しい（双尾翼？）。
破壊というのは文字通りで、そのパーツは担当していた機能を果たせなくなる状態のことでしょうね。
原則として旅客機は、あなたのおっしゃるように「うまい具合に」壊れるように設計されています。早い段階で破損を検出し、修理・交換するわけです。重厚長大産業の現場に普及している3次元CADのCATIAは、元々航空業界で開発されたものです。
旅客機のメンテナンスとは金属疲労に対する戦いでした。元祖ジェット旅客機のコメットは金属疲労が元で落ちました。結論としては、金属疲労をなくすことは不可能であるから、検査を徹底した上で不良パーツはどんどん交換することになっています。
一方で経年劣化の避けられない金属をやめ、新しい材質を使うことも広く試みられてきました。軽くて丈夫なそれら新材質を使用すれば、より多く積めるし、検査や交換の頻度も減らせて、旅客機の運航コストを下げられることを期待しています。
ですが、残念ながらそう上手くはいかなかったみたいです。設計段階では、このように内部破損することは予見できなかったのでしょう。
鉄道と比較するのは不適当です。鉄道ってのはコストに優れているし、そもそも新幹線なんて国が作ってくれたんですから。でも、鉄道じゃ海を渡れません。
旅客機は世界的な過当競争の中、ギリギリのコストでやっています。JALは国営企業でなかったら大昔に破綻していたでしょう。ANAだって国が保護していた国内線を主戦場にしていたから、なんとかなったわけです。こうした措置はもうありません。
燃料高騰やテロ対策も相まって、航空会社はコストに大変にシビアです。航空機製造業者もコストに優れた飛行機を開発しなきゃ買ってもらえません。その辺を度外視したら、航空券が高すぎて客が乗りません。
Re:コスト (スコア:3, 参考になる)
ただ重量制限が航空機ほどきつくないので、何でもとにかく壊れないように頑丈に作るという発想なんですね。
必要性があまりなかったから、製造時とメンテナンスでうまく分担してコストと重量を最小化するという航空機の設計の考え方には到達しなかったわけです。
また、たいていの場合鉄道のコスト構造は人件費が大部分を占めていて、航空機ほど機材の減価償却費は大きくないということと関係しているのかもしれません。
それと、とりあえずその場で列車を止めてしまえば絶対安全という鉄道と、止めては絶対にいけない航空機の発想の差もあるんでしょうね。
鉄道は、何かあったら必ず止まるようなフェールセーフ設計にするということだけ考えられていて、そこで思考停止しているという主張も聞いたことがあります。
でもって細かく突っ込みを入れると
> 新幹線なんて国が作ってくれた
国鉄時代の新幹線開業区間の建設費は国鉄の自己負担です。
それがために国鉄の債務が膨れ上がって破綻して、結局国民負担に付け回されたという意味なら、確かに国が作ったことになるのかもしれませんが、
JRが新幹線保有機構から新幹線設備を買い取った時の価格は当時の実勢価格以上だったので、新幹線分は鉄道が全額自己負担しているともいえます。
整備新幹線は国が建設して保有していますが、JRは運行にあたって線路使用料を払っています。
国が空港を建設して、着陸料を払って航空会社が利用しているのと同じです。
航空機は鉄道のように経路上の路線を造る必要がないので、鉄道側の視点からはインフラも全部国持ちで「航空機はコスト面で有利」に見えます。
Re:コスト (スコア:1)
ある程度の安全マージンを定量化して歯止めをかけないと危ない領域に突っ込みそうな気配さえ。
新幹線は、規制もあるだろうけど、ある意味「自制」しているかのような高値安定。
飛行機野郎のベンチャー気質と、安全確実を旨とする鉄道マンの違いだろうか？
Re:コスト (スコア:3, 参考になる)
ヒコーキは空気を運ぶよりは多少の金を取ってでも人を乗せた方がいいわけです。ここに航空業界の抱える、根本的なディスカウント合戦のインセンティブがあるのです。
とはいえ今時の料金でも黒字運行するために、航空会社はなかなか努力してますよ。目に見えるところでは、パイロットは3人から2人になったし、フライトアテンダントはずいぶん減らしたし、機内の飲食物もだいぶケチってます。目に見えないところでは、ヒコーキ自体が燃費が良くて故障の少ない、経済的な機体になりました。一つの便を複数の航空会社で集客することで（共同運航便）、搭乗率を向上させて不採算路線を整理することができました。先物市場に乗り込んで、燃料を確保することまでやってます。などなど。
旅客機の安全性の確保は、法律や各種規制で細かく定められています。旅客機ではつまらんコンデンサの一つを交換するときでも、製造メーカの指定部品しか使えません。
ま、それを遵守するかは航空会社の気質次第です。我が国の航空会社は高いレベルで遵守していますが、他ではそうでもないところもあります。
安全係数 (スコア:3, 興味深い)
ギリギリの安全係数で設計して、その代わりに検査で問題点を摘出するというアプローチしか取れません。
また、いったん飛び立ってしまえば着陸するまで修理は出来ないし、あちこち飛び回っているので、
どの時点で修理をするかを決め、必要機材を先回りして準備しておかなければいけないといった事情あり、
予測ということが重要でしょう。
これが地上の構築物であれば思いっきり安全係数を掛けて、検査を軽くするという
ライフサイクルコストを考えたアプローチも取れるのですが。
ソフトウェアのいいところはバグを潰しきれれば、その部分は安全であり、経年劣化や疲労などの心配をしないで済むということですね。
事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
Re:安全係数 (スコア:2, 興味深い)
ただ、インターネット世代だと、日々出てくるセキュリティホールや、時代の変化による陳腐化に晒されるといった類のソフトウェアもあるので、定期的な見直し、修理点検も必要といえば必要ですね。
>事前検査できる、個体差を考えなくてもいいというのも大きな特徴です。
これも、広くいろいろなハードウェア、条件でインストール、実行されると、思ってもみなかった不具合が出て来たり。
オープン化以前の、用途特化した汎用機の時代のほうがやりやすかったのかも。
Re:安全係数 (スコア:2, 興味深い)
裏を返せば恐ろしい事実が浮かび上がってきますね。
つまり、ソフトウェアでは、
上の人たちが話していたようなリアル物と違い、
「予測不可能な」壊れ方が大半を占める、ということになるので。
リアル物の疲労とかの壊れ方は、ある意味で予測可能なんですよね。
これくらいの力がかかってるから確率的にこれくらいの時期に駄目になるだろうとか。
ところがソフトはその発想が通用しない。
時間によって壊れるのではない。
実は最初から壊れてるだけで、それが発覚してないだけ。
それがバグ。
だから全く予想不可能なタイミングでとんでもない大バグで壊れたり…もとい実は最初から壊れてたのが発覚したり…する。
お仕事開発(つまり企業)においてしばしばイタイとされてるのは、
この「予測可能性」について勘違いしまくった人が開発工程を決める、
という状況だと思います。
＃某通信系大手に「バグ率」という言葉を散々振りかざされてウンザリしたのでAC
＃バグが多いならまだしも、少な「すぎ」てもペナルティを科されたんだよね…
＃もしウチの社員がテメーラより3倍優秀だったらバグも1/3になることは全然おかしくないだろうに…
Re:安全係数 (スコア:2, 興味深い)
じゃあとりあえず殺意を覚えさせてください(わら
少なくとも御社(だとすればの仮定の話ですが)の
あのドキュメントを書いたかたがたへ、ね。
殺意自体は冗談ですが、こっちがかなり非効率に忙殺されたのは間違いないと思いますので、(埋め合わせをして頂ける日が来るまでは)恨みは記憶から消えないでしょうね。
>客観的に
それをいうなら、あの方法論の適用の的確さもまた、客観的に示して欲しいものです。
つまり弊社社員たちが平均的だということを。
いつ測ったの？
(御社(だとすれば)がうちから持っていったデータは、履歴書の束だけのはずですよー)
というかそれ以前に、
●平均的人間ならばこれくらい、という相関がそもそも有るのかどうかを。
●平均かどうかをどうやって測るのかを。
客観的に示して欲しかったです。
要するに片手落ちなんです。こちらが出すものにはそうやって客観性だのなんだのといった真っ当なスジを期待なさる(実際そうでした)割には、そちらからくれるものはスジもへったくれもないものばかり。
それとも上流サマはそうやって下請けに無理難題言うのがお仕事なんでしょうか？
「文句があるなら換えは幾らでも居るぞ」ってか？
結局俺らの頬を札束で叩いてるだけじゃんかorz
というかぶっちゃけ、
そちらからのドキュメントが平均的(優秀でなくてもいい)日本人に判読可能であったことも、客観的に示して頂けると凄くありがたいですね。しゃれぬきに日本語としてすら判じ物で、それの意味を問いただすのだけで工数(与えられた期間)のうち半分以上を食ってしまったってのが実情なので。
(しかも「なかなか返事をもらえない」という待ち時間がその大半を占めた。たしかに質問と回答自体に時間がかかるわけではないが、待ち時間が凄かったわけね。電話を「3日後にまたかけて」とか言われて、かけてみたらまた待たされたりとかさ。)
こっちの品質を言うまえに、そちらの命令書(ドキュメントの文字通り山)の品質を、どうにか客観的に評価してもらえたら、助かったのですが。
その状況でバグ率とか言われてもねえ。
それともこれは引っ掛け問題で、判読できなくてそちらの意図と違うものを実装してしまったら、それをバグにカウントすることで帳尻が合う、ということだったのでしょうか？だとすれば優雅ですね。下請けに引っ掛け問題を出してコミュニケーションロス「で」遊ぶ暇が有るんですから。
＃ACはこういうために使うのか！と今更気付いたのでAC
日本語をクリアしたとしても、その次にはIT畑で典型的な問題が待ち構えています。
それは「ロジックの抜け」です。
ドキュメントを日本語でダラダラ書かれたドキュメントにありがちだし、そうでなくてもありがちなことなんですが、
「xxなときにyyしろ」
というような指示の羅列があったとき、
そのケースに抜けが有る、
ってのが典型的に良く見かける「ミス」です。
Waterfall(大量の「出来上がった」ドキュメントを一気に渡す方式)をやりたいなら、そういう抜けを絶滅させてから下請けに渡して頂きたいものです。
逆にいうと、上流サマが机上の空論こね回してるだけでは、そういう抜けは発見しきれないのが判っているからこそ、Waterfallは不味いって話に近年なってるのですね。
Re:安全係数 (スコア:1, おもしろおかしい)
とりあえず落ち着こうぜ
Re:安全係数 (スコア:1)
ああ、ソフトウェアの設計にも安全係数の考え方ができたら、 どんなに楽なことか。
常識的には、ソフトウェアの品質は、 欠陥を見つけて修正して、それが枯れたことでしか測れません。 そもそも欠陥が出ないと品質が測れないということは、 仮に超優秀なプログラマがいて、本当に無欠陥のコードを書いたとしても、 それは品質測定ができず、受け入れ不可能ってことになります。 だから、テストで欠陥がある程度出てくれないと困るのは確かです。
でもね、欠陥の検出率を測定して、 ある一定以上の欠陥が出ていないとしたら、 まず、テスト担当側の方法を疑うのが普通であって、 開発会社にペナルティを科すってのは、全くデタラメなやり方ですね。
できたばかりのコードそのものの品質の高さを「客観的に示せ」というのは、 これも無理な話ですが、 欠陥修正が速いとか(=昼間のテストで出た問題は、夜中に小人さんが修理してくれていて 翌日すぐに再テストできるとか?)、本当に平均して欠陥が少ないとか、 いつもテスト期間の短縮に貢献しているのだというデータは 取ろうと思えば取れるはずなのですけどね。(たいへんだけど)
私も発注側の人間。
Re:安全係数 (スコア:1, 参考になる)
まぁ、相手は大会社様ですからね、その大会社様の会社全体で見るとサンプル数も多いんですわ。
するってーと、案外、それなりに平均的な値とか傾向っつーのも出てくるんですよ、特に案件の規模が大きくなってくるとね。
傾向の出方も、バグ数だけの話じゃないんですよ、バグの種類とか、各工程での出方とかね。
この辺をきちんと見ていくと、これ数字捏造でしょ?とか、テスト本当にやったの?とか、テストの力入れる部分違うんじゃない?とか、そういうのも大体見えてくるんです。
SI工程なのに発見すべき工程がUTばかりだとテスト不十分だったのかなーとかね。
捏造なんかだとSIで発見されたバグがUTでなおってたりなんてのが大量にあったりしますね。
ま、こんな整合性を整えてまで捏造するならきちんとテストする方が楽ですし、本来捏造なんてやる気出ませんし、そもそも捏造が必要な事態に陥るほどの状況ですからね、こういう部分も雑になりますわな。
あと、大会社様の中でも、受け入れは別部門だったりすることがあって、そういう場合だと、担当部門の方も、その別部門の人を説得せにゃならんのですわ。
受け入れが別部門じゃなくとも、大会社様のお客様がITにそれなりに詳しかったりすると、やっぱり説得が必要ですし。
なので、その説得材料として、「まずは俺を納得させろ」なんつーことはよくあります。
そういうわけで、アドバイス。
テストをやる前に、テストのやり方については充分に大会社様と話をしておきましょう。
テストの目的とか、項目の抽出の仕方とか、目標のバグ件数とか、記録すべき事項とか。
で、記録すべき事項については、確実に周知・徹底して、きちんと残しましょう。
場合によっては、大会社様が残さなくていいといった内容についても記録に残すべきです、もちろんコストと相談してですが。
こういったことをしっかりやっておけば、話し合いで何とかなることが結構あります。
もちろん、プロジェクトの状況にもよりますよ、受け入れ側視点で見ても、もっと早く相談してよって言いたくなるケースもあります。
Re:安全係数 (スコア:1, 参考になる)
テスト目的やテスト観点、試験項目はきちんとレビューしてもらおう。→やるべき試験についての事前ネゴ
テスト期間や項目数にもよるが、最低でも週1、可能なら毎日、試験消化状況やバグの発生状況について話す場を設けてもらおう。→状況把握してもらおう&捏造してないことを知ってもらおう
政治的・コスト的に可能なら、担当部署の品質管理チームに数人混ぜてもらおう。→相手がどういう考えでいるのかを知ろう&手法を学び取ろう
同じく政治的・コスト的に可能なら、自社内部にも品質管理チームを持とう。担当部署の品質管理チーム分隊という感じでもOK。→大会社様と同じ意識を持とう&内部の記録ミスなんかは随時正そう
Re:安全係数 (スコア:1, 興味深い)
運用環境の違いや、それに合わせたコンフィギュレーションの差異なんかは個体差といって差し支えないし、そのような設定の変更を繰り返すうちに元に戻せなくなる場合も珍しくはない。交換＝再インストールで解決したりとかね。
これをオペレーションの問題でありソフトの不備では無いと言い張るならそれで構わないけれど、現実にはそんなに厳密なオペレーションが可能な設計でもなければマニュアル等が完備されてるわけでもない場合が珍しくないわけです。そのような不備をも含めて「バグ」と称するなら確かに元コメントの言うとおりではあるけれど、見方によっては「ソフトウェアも経年劣化や疲勞を起こすし、そうなったら交換すれば良い」という考えの元、コストダウンを図っているといえなくもないでしょう。
個人的にそれよりも気になるのは「ソフトウェアに製造工程はなく試作品がそのまま出荷される」ということをよく理解してない開発者が非常に多いということですね。敢えて飛行機ではなくガレージキットで例えさせてもらいますが、ガレキなら試作品、つまり原型が「切った貼った削った盛った」のツギハギだらけであろうと、型さえしっかり取れば量産品は継目なしの一体成形で出荷することもできるわけです。ところがソフトウェアの場合、出荷される製品はあくまで試作品のコピー、ツギハギまでも含めた良くも悪くも完全なコピーなのです。
酷い場合、バグを潰すのではなく、バグによって壊されたデータの修正ルーチンを別途組み込む、といった場当たり的なツギハギが、必然性もないまま放置され、出荷されてしまうことすらも。で試験に漏れた特定の条件で修正ルーチンが走らなかったり、２回以上走ったりとか。
そしてW2Kの記憶は忘れられた！ (スコア:1)
バグを潰しきったなんて、そんな夢物語！
最近なんてハッピーマンデー砲なんて軍事兵器が投入されたばっかりでありますよ！？
たとえ、バグがあろうが無かろうが、安全では無いし、経年劣化を防ぐためにメンテナンスは必要なのであります！
ソースコードのフリーズ＝メンテナンスの放棄なんて勘違いはしてないと思うけど！
Re:そしてW2Kの記憶は忘れられた！ (スコア:1)
旧い時代の汎用機だって休日には休日のスケジュールに従ってジョブを流すだけでありますよ？
問題点がそこだけだから大丈夫だろう。と思っている事が地獄の扉を開ける原因だと言っているのであります！
Re:安全係数 (スコア:0)
組み込み系、特にメカがかかわる奴とか、デバイスドライバ、あるいは通信系の低いレイヤーでは
個体差、というか条件によって発生する問題もありますからね。
Re:安全係数 (スコア:3, すばらしい洞察)
>一本一本テストしていくしか結局は意味ないですよね
ハードも設計者にとっては一本一本手作りです。
製造ライン作るのだって一本一本手作りです。
よろしく ^_^/
Re:安全係数 (スコア:1)
パッケージ販売してるところとかはまた別と思うけど。日本のSIerを早くパッケージ市場に乗り出せば良いのに。
そんなに斬新なシステムばかり要求されるわけじゃ無いでしょ。
Re:安全係数 (スコア:1, すばらしい洞察)
>枯れてしまえば問題ないということでしょう。
CPUの演算機能はたまにバグがあると結構騒がれますが、OSやコンパイラ、ライブラリレベルなら
今でもかなりバグがあります。
そもそも「枯れてるから問題がない」といっても、枯れた時点でバグ0ではありません。
結局のところどこかにバグがいるからバージョンアップをしている、という側面もあります。
ただ、ソフトとハードというのは、やはり比較すべきものではないでしょうね。
非常に誤解を招きやすい。
検査項目の策定 (スコア:3, 参考になる)
Re:検査項目の策定 (スコア:1)
ITでも (スコア:2, 興味深い)
新しい開発形態には新しいレビュー形態(視点)が必要
ってことだな。
例えばOOPコーディングを従来の手続きオンリーの視点で(だけ)レビューすると、的外れなレビュー結果が出かねない。
(だからOOPをやめる、ってのは適切とは限らないぞ)
Re:ITでも (スコア:1)
トピ名が「材料」に寄ってるから、ここはプロジェクトで採用するフレームワークやライブラリの話の方が広がるかも？
行数だけでプログラムの規模や品質測られるよーな笑い話も、減って来てる
と信じたい昨今ですしRe:ITでも (スコア:0)
何かある？
# ファンクションで測ろうったって「重み付け」で勘が入るし
# 機能の複雑さは普通行数に比例するべ？と言われちゃうし
Re:ITでも (スコア:3, おもしろおかしい)
逆に考えるんだ。
「言われちゃう」のが不味いと考えたらどうだろう？
つまり、その論拠の無い方法論に対して、
これまた論拠の無い別の方法論をぶつけてみるんだ。
「ためしに今日から関数の数でカウントすることにしまーす」
とかね。
そうするとあーら不思議、
みんなみんな、関数分割をやたらと積極的にやるようになるぞ！
もちろん昨日まで分割に消極的だったマネージャもだ！
そしてその方向性に難色を示していた老人たちは即効で首だ！
…なんか凄く幸せになるんじゃねーかこの方法論って？(ｗ
つまりさ。
品質(あるいは生産性でもいいよ)を測る基準として、
わざわざコードの質が実は下がることが経験的に判りきってる基準を
採用するのを止めればいいんだ。
実はコードの質を上げるかも知れない方法論に
こっそり摩り替えてしまえばいいんだ。
どーせ何で測ったらいいか判らないんだったら、
それを悪用というか口実にしてしまって
都合のよいやり方をやってしまえばいい。
もちろんお客だって何も損をしてない。
良いコードのほうが結果的にメンテしやすいという意味では
お客のためにもなっている。背信行為は全く無いぞ。
Re:ITでも (スコア:1)
MAXLENGTH = 256;
の代わりに、
int getMaxLength(){
return 256;
}
なんてのがはびこるならまだしも、
int syutoku256(){
return 256;
}
みたいのが大量に繁殖したコードが目に見えるようなんですが。
Re:ITでも (スコア:1)
少し前までは、 コードカバレッジというのがもてはやされていました。要はプログラムの全箇所テストしたらバグは無い、とするものです。
NTのおかけでマルチスレッドが普通に使われてくるとプログラムのある箇所と別のある箇所が同時に走行すると間違える、というケースが出てきました。こうなるとカバレッジ解析だけでは不足してしまいます。
こういったマルチスレッド観点での試験方法が必要なのですが、なかなかやり方を変えようとはしてくれません。困ったものです。
Re:ITでも (スコア:2, 興味深い)
そこだけ注視すればよいと理解されているからではないでしょうか？
あるいはスレッド同士のインタフェースを少くする(可能なら隠蔽する)よう
に設計せよということじゃないでしょうか？
Re:ITでも (スコア:0)
オブジェクト指向プログラミングコーディング？
フライ・バイ・ワイヤ機の点検 (スコア:1)
FBW機の場合は電気系統が命なので、空自のF-2以前の従来型機と比べて電気系統の信頼性の重要さが違うことでしょう。整備にミスがあったとしても、どうして実際に飛ぶ前にそれを検知できなかったのかが不思議です。コネクターの事情はわかりませんが、同じ部品を使っているとすると、なおさらそれを間違えないあるいは間違えても致命傷にはならないような仕組みや点検体制にするとか、点検用のプログラムがあるとすれば、それを検出できるようにしておく必要がある気がします。前提が変われば、当然何をどのレベルで点検しないといけないかは変わるんではないでしょうか。
ある系統にどんな問題が起こりうるか？またその時どんな事が起こりうるか？というのは、他のコメントにもあるように、例外処理を考える（バグつぶし）という話になると思いますが、それをどうやって知るかというのは、やはりその作動原理や特性、設計の意図、実装方法、どんな状況で操作されたり動作するかなどをどれだけ理解・把握できるかにかかってくるんでしょうか。今回のF-2の場合は、システムの設計としては飛行中、運用中のトラブルは考慮していても、社内整備中のトラブルは整備士を信頼して考慮していなかったのかな？
ある意味、あらゆる分野に共通する教訓を残してくれた事故だと思います。
Re:フライ・バイ・ワイヤ機の点検 (スコア:3, 興味深い)
一般の家電でさえ、内部の基板間のハーネス等のコネクタは、各々ピン数を変えておくとかして誤接続を防止するのが普通ですよねぇ。
＃/.erには、家電が故障したらとりあえず分解する（直せるかは別）人が多いと思いますので、本職じゃなくてもそういう種族なら納得して頂けるかと。
もっとも、大量生産しない産業機械では、コネクタに貼られたラベルやケーブルのマークチューブが唯一の手がか（省略されました
以下の点が問題、だと思います。
・誤配線「できてしまう」設計だったこと
・そして、そんな設計が通ってしまったこと
・さらに、欠陥がわかったのに、応急手当的な処置で済ませた [google.co.jp]こと
応急手当ではまずいことは設計者自身がよくわかるはずなので、何故根本的な対策が取れなかったか、が最大の問題ではないでしょうか。
＃コの業界からそんな話をよく聞くような…
＞ある意味、あらゆる分野に共通する教訓を残してくれた事故だと思います。
教訓ではありますが、50年ほど前に通り過ぎているはずの道でもあります。
（水城 徹 [biglobe.ne.jp], 2005, 宇宙の傑作機 No.10 アポロ誘導コンピュータ, 風虎通信, から引用）
Re:フライ・バイ・ワイヤ機の点検 (スコア:1)
にしても、ハーネスの長さにまつわる設計と艤装のズレの問題も今に始まったことではないでしょうし。自動車でも、ハーネスが設計よりも長めに取りつけられていて、設計上は接触しない他の部品と接触して問題が起きてリコールなんていう話を聞いたことがあります。
Re:フライ・バイ・ワイヤ機の点検 (スコア:1)
#1255160 [srad.jp]にて、「マーフィーの法則ですなあ。」とのコメントがあります。ホント、まさにマーフィーの法則です。
(マーフィーの法則 - Wikipedia日本語版 [wikipedia.org]より。枝葉末節を一部削除)
＃自己コメント訂正
＃＞50年ほど前に通り過ぎているはずの道
＃ 60年ほど前でした。
仮に、何らかのミスが発生する可能性のある箇所が、1万箇所あるとします。
で、各々にてミスが発生する可能性を1万分のとすると、ミスが1つ以上ある可能性は 63％ あります。
ミスの発生可能性を10万分の1としても、1万箇所あれば、同じく 10% です。
そんなわけで、多数の要素からなるモノは、各々に失敗する可能性があれば、何処かで失敗して全体がダメになります。対策は、「失敗の可能性そのものを虱潰しにする」ことしかないでしょう。
＞自動車でも、ハーネスが設計よりも長めに取りつけられていて、設計上は接触しない他の部品と接触して問題が起きてリコールなんていう話を聞いたことがあります。
自動車でやっちまうことなら、航空機でもやっちまうでしょうねぇ。
失敗が即致命的な損害を生じるのでなければ、とりあえず動かしながらミスを発見していく、というやり方もよくありますね。
＃非常停止ボタンに手をかけながらそろりと試運転するとか
もっとも、これはこれで色々楽な方法ですけど、まだ発覚していないミスが何処かに眠っているかもしれないという懸念がつきまといます。
＃なんだか、ソフトウェアの事を書いているような気がしてきました…。
Re:フライ・バイ・ワイヤ機の点検 (スコア:2, 参考になる)
>つながってしまったのは、Fly-By-Wire(FBW)機ならではのことだと思います。
たしかにFBWならではなのですが、戦闘機ならではということもできます。戦闘機というのは航空機の中でもさらに特殊です。通常、旅客機のような普通の飛行機は、主翼に上反角というのがあります(翼が上に反りあがる)。重心が下側にあるので、これは飛行中に姿勢が安定になるように作用します。
一方、最近の戦闘機は上反角がほとんどない、あるいは無いので、力学的には完全に不安定です。これは運動特性を向上させるためです。したがって、安定性はデジタルサーボに完全に依存しています。それを失えば墜落するしかないですし、そのセンサーの方向を間違えたとなれば自動的にひっくり返ります。
航空機の設計者が、こともあろうにF-2やF-16のように実績のある機体にそんな分かりやすい悪質な欠陥を作るはずがないし、あったとしたら三菱重工はともかくロッキードがそんなにあっさり認めるはずがない、っていうか犯人みつけろよ、ぐらいの悪質な欠陥です。
F-2の件はミスというよりも、故意に配線が変えられたと考える方がずっと自然です。
Re:フライ・バイ・ワイヤ機の点検 (スコア:4, 興味深い)
ピッチとヨーの並行する配線のコネクタを並べると誤接続の危険があるので、
わざと前後にずらして配置し、間違えたらケーブルが届かない設計にしていたはずが、
なぜかゆとりが大き過ぎて届いてしまったというオチ。
思うに、離陸前の点検では、従来どおりスティックとペダルを操作して、
各舵面が動くこと位は確認していたはずです、憶測ですが。
ところが空中ではパイロットの操縦に加えてコンピュータによる補正がかかるのですが、
コンピュータへの入力が見当違いだったために目茶苦茶な補正をされて墜落に至ったと。
まあ憶測ではありますが、大もとのコメントのいうように、
旧来の検査手順では新しい概念に基づく設計に対処できなかった例、
といえる可能性の高い事故じゃないかと思います。
Re:フライ・バイ・ワイヤ機の点検 (スコア:1)
Re:フライ・バイ・ワイヤ機の点検 (スコア:2, すばらしい洞察)
F-16はともかく、F-2は開発時点でかなりの新規開発をしているんじゃないの? とくにFBWがかかわるところは。
それとも、そのへんはF-16そのままなんだっけ？
>F-2の件はミスというよりも、故意に配線が変えられたと考える方がずっと自然です。
「自然」であっても実際そのとおりかどうかは分からない。
ちょっと断定するには根拠がなさすぎるという気がしますけどね。
# 中の人で、通常しられている以上の情報に基づいての発言でしたら別ですが
Re:フライ・バイ・ワイヤ機の点検 (スコア:1)
自然っていい日本語でしょう？
Re:フライ・バイ・ワイヤ機の点検 (スコア:1)
Re:フライ・バイ・ワイヤ機の点検 (スコア:1, 興味深い)
コネクターという奴は、ソフトウェア畑でいえば、設定ファイルのようなものだと思います。
あるいは最近流行の「DI」なんかもコネクタのようなもんだと思います。
工場で作る時点では何処に繋がるかは未定で、実働するときに初めて繋ぐべきところに繋いで、それで動作するようになる。
ソフトウェアも設定(ファイル)を多くすればするほど、「差し違え」のリスクを抱えることになりますね。まあコネクタ(設定ファイル)を刺した状態で結合テストをしろってことでしょうけど、煩雑なのは確かです。
それにしても設定ファイルってのは変なものです。もともと「ソフト」ウェアつまり変形が(ハードより)容易なのが売りだったはずなのに、気付けばアプリ本体を変更することを避けて設定ファイルを外出しにするようになってしまった。