無料ブログはココログ

Twitter

  • Twitter

トップページ | 2005年2月 »

2005年1月

2005年1月30日 (日)

なぜ使えない(3)

ここ何年か、企業の自己啓発プログラム等で「問題解決(力)」という言葉が目につくようになった。
その言葉を製品開発にあてはめると、現状の製品の問題点を洗い出し、その対策を実行することで、さらにより良い製品を開発する、ということになるのだが、設計という行為はまさにこの「問題解決」するための行為であり、「問題解決」という言葉がはやりだす前から行っていたことのはずである。
ただ、このごろ問題解決のための製品開発、設計になっているのか怪しいこともみうけられるのだが。。。

それはともかく、CAEはこの問題解決をするための道具である、と考えるとよい。

解決するための道具と考えてみると、「CAEは設計の問題点を見つけることには向かない」といえる。
マイクロソフトの「ワード」は文章を書く道具であるが、文章を考えてくれないのと同じである。
たとえば、ある構造物が原因不明で壊れる場合、負荷が大きすぎるのか、疲労破壊なのか、材料の欠陥なのかということをCAEは何も教えてくれないのである。
もちろん、考えられる原因を個別にシミュレーションすることは可能だが、その結果を分析して結局どれが支配的かを判断するには相当高度な技術力がいる。

次に負荷が大きいことが原因だと判っている場合を考えてみる。
そこでたとえば部材の形状を変更するということになるが、どのようにどれくらい変更すればよいかをCAEで知りたい、いった場合もCAEで解決できるかどうか微妙である。
少し技術的な話になるが、単一の材料の構造物の場合は、その材料の強度の値を参照して、シミュレーションの結果の応力などがそれより大きいか小さいかを判断すればよいはずである。
しかし壊れるのは切欠きなど応力集中部を起点にすることが多く、この応力集中部の応力を有限要素法のシミュレーションで正確に予測するのはメッシュサイズの依存性などの問題があり難しい。
また、いくつかの材料を組み合わせた構造物の場合、それらの接合部の強度(溶接強度、接着剤密着力など)は未知なことが多く、シミュレーションで応力が出てきても参照値がないため、壊れるか壊れないかの判断はできないことが多い。

それでは、どのような場合CAEが力を発揮するかというと、相対比較のとき、つまりA改良案とB改良案どちらが良いですか、これを判断する場合はAの結果とBの結果の応力を比較すればよいだけなのでそこそこ使える。(この場合でもいくつか考慮すべき点があるのでそこそこという表現を使わせてもらっている)

つまり、問題解決のアイデアが具体的になればなるほどCAEは力を発揮してくる。

そこまで考えないと使えないのか、という方がいるかもしれないが、CAEでいくつかのアイデアの中から問題解決のアイデアが絞り込めれば、絞り込んだ分の実験の費用や工数が削減できるはずである。
あとはその削減した(が予測される)費用がCAEに投資した(する)金額に見合うかどうかで使えるか使えないかを決めればよい。

それでも、相対評価のCAEの結果は正しいのか、相対評価ではなく絶対評価までできないと投資が回収できない、などと思われる方がいると思うしそれは当然でもある。

これらはCAEの精度についてということになるのだが、次回はその話の予定。

2005年1月23日 (日)

なぜ使えない?(2)

CAEの結果が現実と一致しない、
もしくは結果が怪しい、

ということは、よくある話である。

原因は、一言で言えば、
「解析モデルが間違っている」
ということなのだが、これを考えてみると、一言では片付けらないものである。

私は構造解析屋さんなので、有限要素法を使用した構造解析の場合について話を進める。

解析モデルが間違う原因として、
・ソフトの使い方が間違っている
・有限要素法の決まりに従ったモデル化を行っていない
・境界条件が現実と一致していない
・材料物性値が現実と一致していない
・モデル化で前提とした物理現象以上のことが現実で起こっている(物理現象の非線形をシミュレーションで考慮していないなど)
など、考えられる。

これらを一つ一つ解決する方法は、技術的なことが中心になり話が長くなるので、別の機会に行うとするが、ここでは、これらを解決する方法より重要なこと、
「何を持って現実とあったとするか」
「まっとうな(怪しくない)解析結果とは何か」
ということを考えてみる。

実は、シミュレーションの結果は現実と厳密に一致することはない、のである。
なぜかというと、「モデル化」をしている以上何らかの近似が入り、現実に起こりうることすべてを含むことはまず不可能だからである。
たとえば、有限要素法を使う場合、構造物を要素に分割するという時点で、すでにモデル化されているので、物理現象を100%再現することは不可能である。

よって、100点満点のモデル化というのは不可能であるので、100点に近い点数をとるか、つまり高精度のモデル化を行うか、ということになるが、高得点のモデル化を行うのもなかなか難しい場合が多い。

それより、まず最低合格ラインの精度を決めて、精度を上げていったほうが現実的だと思う。
つまり、どの程度の精度で「現実と一致した」とするかを決めてからかかる必要がある。

最低合格ラインの決め方、精度向上の方法については、また次回。



2005年1月16日 (日)

なぜ使えない?


今回はなぜ使えないかをもう少し考えてみる。

現在のメーカーのものづくりの目標は「はやく、やすく、いいものを作る」にあると思う。
それに対し、CAEが貢献できれば役に立つということになる。
で、よくある広告文句は、「CAEを使うと、開発のスピードアップとコスト削減が図れます」というものが多いので、広告を信じると「はやく」、「やすく」という部分で貢献できそうである。

もちろん、CAEが「いいものを作る」という面についても考えることが必要であるが、それは後回しにして、今回は「はやく」、「やすく」に対しての貢献について考えてみる。

さて、設計開発の担当者がCAEを使う場合、どのような状況が考えられるかというと、
1.自分で使う
2.他人に依頼する(社内専門部署や社外に頼む)
のどちらかである。

自分で使っている担当者が使えないと考える場合、
(1)ソフトが高い(やすくない)
(2)操作が覚えられない、覚えたとしてもモデルを作るのに時間がかかる(はやくない)
が主な理由だと思う。

他人に頼む場合で使えないと感じるのは
(3)費用が高い-社外受託解析に数百万かかる場合もある(やすくない)
(4)結構時間がかかる(はやくない)
が主な理由だと思う。

ところが、これら(1)-(4)の使えない理由は、少し乱暴だが、「やる気」とか「気合い」を入れると解決できる問題だと思う。つまり、予算取り、ソフト操作の習得、担当部署、業者へプレッシャーをかけるなどを気合を入れて行えば解決できるはずである。もちろん、具体的に考えていくと簡単に解決できない問題もあるのだが、これらに関しての「気合い」の入れ方などについてはまた後日考えてみたい。

上記のことより重要なのは、自分で使う場合、他人にやらせる場合共通の以下の問題点である。
(5)結果が怪しい、実験と一致しない
(6)結果の解釈が難しい
実はこちらの問題点を解決する方に「はやく」、「やすく」を実現する要素が多く含まれているように思う。また、これらの問題が解決されていないと、(1)から(4)までの解決のための気合も入れられまい。

2005年1月 9日 (日)

CAE 役立ってますか?


昔に比べ、コンピュータの低価格、高性能化が進み、電気屋さんで売っているパソコンでもシミュレーションができる時代になった。
CAEソフトも、ハードに比べると割高だが、それでも低価格のものが売られている。
解析屋さんの仕事も、人数も増えてきていて、このごろ解析技術者の資格までできたようだ。
実際、各会社の解析屋さんに話を聞くと、皆さん忙しいという。

ではその方々に、実際CAEが役に立っているかどうかを聞くと、役に立っているところとそうでないところに分かれるようだ。例えば、

-役に立っている。製品開発フローに完全に組み込まれているので、CAE結果がないと開発設計は進まない仕組みになっている。

-役に立っているかどうかわからない。結果を持って行っても、設計者の机の片隅に放置されたままで、解析結果が表に出てくることは多くはない。

な具合です。


では、うまくいっている場合とそうでない場合は何が違うのか、話を良く聞いてみると、使用ソフトやハード、部署の人数や組織など、見た目の体勢や投資額はあまり関係ないようだ。
開発フローを記述する標準書ではシミュレーションが組み込まれているのに事実上機能していないところもあると聞く。

私には結局のところ、「やる気」とか「気合い」とかそういうことが関係しているように見える。
しかも、この「やる気」とか「気合い」を現場の解析技術者だけではなく、トップやマネージメント層が持っているかどうか、大げさに言えば全社一丸となってやっているかどうかが鍵のような気がする。

長くなってきたので、この続きはまた後ほど。

2005年1月 3日 (月)

まず......

このブログは主が勝手にCAE(Computer Aided Engineering)について語るもの。
CAEへの不平不満から意見、提案などを書き込んで行きたいと思う。
間違って見に来てくださった方には、問題解決、ストレス解消等のお役に立てれば幸い。
週一回更新を目標にがんまります。

ちなみに、私はソフトベンダー屋さんやシステム販売屋さんではありません。
続けてるうちに職が変わるかもしれないが。


トップページ | 2005年2月 »

2015年6月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

最近のトラックバック

ウェブページ