| TOP > CAE総論 > CAEとCAD > CAEとPDM |
＜解析DB＞
#1999年2月17日#Gz
私は、某部品メーカーでシステム関連の仕事をしています。
当社ではCosmos/Mという構造解析ソフトを使っています。
運用面でいろいろと悩みがあるので、相談にのってください。
このソフトを入れて、1年程度になります。現行では特に専任者をおかないで、
設計者が意思決定のために使っています。そのため、解析ソフトは計算機のように
なっており、解析結果を次の解析のために貯えるというような行為は行っていません。
私としては、解析技術向上のためにも、解析結果をレポートとしてまとめて、
知識データベースを構築したいと考えています。
ここで悩んでいるのですが、このようなレポートを作成する場合、どのような情報
を残せば有効なのでしょうか。
解析結果だけでなく、解析に対する解析者の意図のようなものを盛り込まないと
有益な情報にならない気がします。
解析の目的を明確にする事もその一つですが、解析モデルに付加した条件（荷重、
拘束条件等）に対する解析者の意図を明確にすることが、解析結果を評価する上でも
解析のDBを作成するにも重要であると考えています。
そこで、相談なのですが、皆さんは、解析結果のレポート等はどのように作られ、
どのように貯えられているのでしょうか。教えていただければ幸いです。
#1999年2月22日#小林 篤央#
了解しました。ただし、当社も、限られた貴社（貴殿）からの情報で、100％納得できる
お返事（回答）は現在のところ困難です。また、当社にも不得意な分野があるので
そこはご容赦ください。
さて、当社では、Cosmosの基本機能を全面的に機能改良した（大幅な改善；特にパソコンに特化）
ソルバー（ＣＡＥＦＥＭ）を扱っていますので、かばり具体的なお話はできると思います。
> このソフトを入れて、1年程度になります。現行では特に専任者をおかないで、
> 設計者が意思決定のために使っています。そのため、解析ソフトは計算機のように
> なっており、解析結果を次の解析のために貯えるというような行為は行っていません。
> 私としては、解析技術向上のためにも、解析結果をレポートとしてまとめて、
> 知識データベースを構築したいと考えています。
>
ここで、問題なのは、2つありまして、
1つは解析担当者（解析専任者）を置いていないということです。
もう一つは「知識データベース」の定義です。
1．貴社の会社規模、ＣＡＥに取り組む会社の姿勢、上司の意向など、間接的に、しかし
重要なポイントが肝心だと思っています。
当然、解析担当者（解析専任者）を置くのがベストだと思います。
（かなり進んでいるあるメーカーでは逆に解析担当者などは置かずに設計者全員が
解析できるような体制を取っているところも実際あります。（ＣＡＤのような扱い）
しかし、こういったユーザーは残念ながら、日本では、ごくわずかです。
解析をサポートしたり、システムをメンテナンスしたり、次期システムを企画検討する部隊
はおいているようですが・・・）
2．「知識データベース」の定義（意味）を教えて下さい。
> ここで悩んでいるのですが、このようなレポートを作成する場合、どのような情報
> を残せば有効なのでしょうか。
> 解析結果だけでなく、解析に対する解析者の意図のようなものを盛り込まないと
> 有益な情報にならない気がします。
そのとおりですね。
> 解析の目的を明確にする事もその一つですが、解析モデルに付加した条件（荷重、
> 拘束条件等）に対する解析者の意図を明確にすることが、解析結果を評価する上でも
> 解析のDBを作成するにも重要であると考えています。
これもそのとおりだと思います。
ただ「解析のDB」の定義が大切だと考えています。
これは、紙ベースのものでいいのか、市販の廉価なＤ／Ｂソフトを使った簡易なＤ／Ｂでいいのか
それとも市販の高価な本格的なＤ／Ｂなのか？
それによって対応（システムの仕様、構築）はまったく変わってきます。
当然、コスト、マンパワーはまったく変わってきます。
> そこで、相談なのですが、皆さんは、解析結果のレポート等はどのように作られ、
> どのように貯えられているのでしょうか。教えていただければ幸いです。
#1999年2月23日#Gz#
さっそくの回答ありがとうございました。
1． 解析担当者の件について
私も解析担当者は必要だと思っています。特にCOSMOS／Mは、設計者（普段から使って
いない人）には操作が難しく、やろうとしてもなかなか出来ないのが現状です。
私のほうでマニュアルなどは作っているのですが、それ以上の事はなかなか出来
ないようです。
会社としては、CAEに関心はあります。しかし、CAEのエンジニアリングに対する
理解は難しいと思います。
2． 知識データベースの定義について
＞ ただ「解析のDB」の定義が大切だと考えています。これは、紙ベースのもので
＞いいのか、市販の廉価なＤ／Ｂソフトを使った簡易なＤ／Ｂでいいのか。
＞それとも市販の高価な本格的なＤ／Ｂなのか？それによって対応（システムの仕様、
＞構築）はまったく変わってきます。当然、コスト、マンパワーはまったく変わって
＞きます。
今、当社ではPDMの導入を考えています。すべての設計データをDB化して整理し、設計
効率をあげようとしています。この中に、CAEも入っているわけです。
解析結果ファイルのみをDBにためていっても、容量的にも内容的にも問題があるし、
DBなので、検索用の属性が必要になってきます。
そこで、解析内容レポートの雛形を決めて、この中から属性を抽出するような形に
していきたいと考えています。
まだPDMを何にするかは決まっていませんが、将来的にこの問題は確実に浮上してくる
ので、今からある程度手を打っていきたいのです。
ただ、DBを構築するとなると、今度は内容の品質の問題が・・・
いやはや、頭の痛い所です。
(編集担当：burning 2001/12/21)
＜PDMについて＞
#1999年2月25日#小林 篤央#
個人的な経験からＰＤＭについてコメントさせていただきます。
依然いた会社でＰＤＭ販売（営業部門）の責任者だったもので、私の体験をお話します。
私を個人的にご存知の方には、偏見と独断で書いているのだなー
とおっしゃると思います。じつはそのとおりで、反論の余地はありません。
ただ、3年から4年前に経験したことは私にとって大変貴重な体験でした。
ＣＡＥを担当していた関係で以前からＰＤＭ，ＣＡＬＳには非常に興味をもって
いました。でも、当時は「何のこっちゃ？」程度の知識しかなかったのでほとんど興味
を持たずにすごしていました。ところが、ある日、ＰＤＭ開発・販売部隊ができ、
なんと私はその部隊の営業責任者となってしまったのです。
それから、私の悪戦苦闘は
始まりました。（昔、ＡＩの部隊ができ、しばらくして消滅していったことを思い出しながら
・・・）
何といっても当時、ＣＡＬＳの意味も良く分からなかった人間が、お客様に、
システムの概要を説明し、個別の会社にあった、ＰＤＭの企画、立案、提案書の作成の
お手伝いまでさせられるのです。当時は「何ちゅう会社やと思いました・・・」
（前いた会社を批判するつもりは毛頭ありません。むしろ、現在はこれを決定した役員の
方々に敬意を
表したい気持ちです。先見の明があったのでしょうね。）
さっそく、関連の学会やカンファレンスに参加させてもらいました。
関連の学会は立ち見席がでるほどの賑わいで当時はブームといったかんじでした。
それでも、頭の悪い私は、概略しか理解できず、「なぜ、いまＰＤＭやねん」、
「なんで当時、日本でＰＤＭが必要なのか」理解できませんでした。
まず、メーカー（お客様）にとって、ＰＤＭ導入の前提として、
1．社内でいろいろな意味での標準化が徹底され、システム化されている。
2．ＣＡＤの導入がいきわたっており、かつサポート部隊も充実している。
3．各人の仕事の役割分担が明確で、組織のミッションも明確に定義されている。
4．ドキュメントを残すことが徹底されており、システム化もすすんでいる。
以上他にもあると思いますが、私は上記の条件を満たすメーカーを絞り込み、
お付き合いのあった会社を回りました。当時は営業というより、各社のＰＤＭについての
取り組み方、方向性（目指しているもの）をお互いにディスカッションしていただきました。
その結果、私は当時の国内のほとんどのメーカーでは導入時期が尚早だと思いました。
それでも、会社は売上を期待するものですから、本当に大変だったのを記憶しています。
現在は、ＰＤＭ，ＣＡＬＳという響きをきくと本当に懐かしく思い出す日々を過ごしています。
現在、ＰＤＭ、ＣＡＬＳにたづさわっているかたのコメントを期待しています。
米国では相当成功している会社が多いと聞いていますが、どんなもんなんでしょう？
#1999年2月25日#谷口#
久しぶりにCAE掲示板を覗いてみて、PDMやDBについての投稿が幾つかありましたので、
私の知る範囲で特にCAE分野でのPDMやDBの利用についてコメントさせて頂きたいと思います。
まず、CAE分野におけるPDMやDBの利用状況ですが、欧米では非常に導入が進んでいます。
(例えばボーイング社などがそうで、777は開発システムを全てデジタル化し、統合化したこと
により、試作を行わずに開発した製品として非常に有名です)
日本でも図面管理に関しては、非常にPDMやDBの利用が進んでいます。また、最近はCAE分野
でもPDMやDBによる統合化が進みつつあります。
(CAE分野はデータや結果が全てデジタル化されており、取り扱う情報も非常に多いので、PDM
やDBを利用した統合化による効果が他の分野(プロセス)よりも顕著に現れると考えられています)
PDMやDBを利用した統合化は、単にCAEの結果のDB化というのではなく、CAEプロセス
(プリ処理、解析、ポスト処理)をシームレスに接続するインターフェースを開発・構築し、
CADとCAEの相互インターフェース(CAD to CAE、CAE to CAD)を開発・構築し、
技術情報だけでなく、仕様書や図面情報や価格情報も含めた全情報を統合化し、設計・開発
プロセスの効率化を計ることが重要だと思います。
これまでも色々な企業でこの手のPDMやDB技術を利用した統合化の話はありましたが、
そのほとんどがうまく行っていません。
その理由は、PDMやDBを利用したシステムの導入を全社的に考えてしまい、非常に大規模
なシステムになってしまい、システム構築に時間がかかり、いざシステムが完成した時点では、
その企業自体の業務フローが変わって使えなくなっているというのが大半でした。
この原因としては、統合化システムに柔軟性と拡張性が悪いというのが挙げられますが、
統合化システムを構築して行く上では、非常に大きな問題で、改善しにくい点だとも言えます。
しかし、現在ではPDMにもオブジェクト指向を採用したものも出きており、柔軟性と拡張性の
優れたものも出てきています。
PDMやDBによる統合化システムを構築して行く上で重要になるのは、
1. 業務分析を行い業務フローを良く理解し、その中でどのプロセスにどれだけの時間とコスト
が掛っているかを知る。
2. システムを利用していく上での操作性の容易さ(情報のDBへの自動登録や運用管理の容易性)
と、言葉(呼び方や記述の方法)の共通化
3. 短期間でのシステムの構築(理由は先に述べた通りで、3ヶ月から6ヶ月での構築が現実的)
4. システムの柔軟性と拡張性(DBに登録する項目の追加や削除が容易にでき、複数のDBに分割
管理できる)
5. 資源(各種情報)の共有化を計り、情報の無駄をなくす。
6. アプリケーションとファイルと結果と履歴を一元管理する。
(いわゆるエンジニアリングデータベース)
だと考えられます。
特にCAE分野において統合化システムを導入して行く上では、6番目の項目が非常に重要です。
これは、CADのデータを中心にそのデータがどういうソフトを利用してどのような結果が得ら
れたかをソフトとデータと結果を関連づけて管理すると言うことで、この中で、設計変更等の
情報をこれらの情報と一緒に管理すれば、次の解析や後で再評価するような時に非常に役にたつ
と考えられます。
また、CAEだけでなく実験とのリンクにより、総合的な評価が可能になると考えられます。
CAEの場合は、取り扱うデータが非常に大きいため、結果をどのように管理するかが問題とな
る場合がありますが、解析結果のファイルを残すか残さないかの違いであり、実際はそれほど
大きな問題にはなりません。
ファイルの管理方法としては、ファイルサーバを用意して実ファイルを管理するかあるいは
ファイルの在処だけを管理するかのいずれかで対応することになります。
しかし実際のところ、最終的に総合評価されれば、解析の結果ファイルはほとんど必要ないと
思います。(少し乱暴な言い方ですが、数値計算の場合は、実験と違い再現性があり、何度計算
しても結果が同じなので、将来その結果に問題があれば、その時点で再計算すればよいので結果
ファイルを消してもほとんど問題はないと思います。必要なのは、評価結果とその評価基準だと
思います)
実際CAE分野でPDMやDBを利用してある種の統合化システムを構築するのは、上記の点を
考慮すれば、それほど難しくはありません。(ただし、直接オラクル等のDBをカスタマイズする
には若干時間を要する場合もあります)
また、CAEから統合化システムを拡張して行くことで、全社システムへと移行させることも可能です。
このようなCAE分野におけるPDMによる統合化システムの構築については、もっと具体的な
内容をお話しすることも可能なのですが、話せば長くなりますので、ご興味のある方は、別途ご
連絡頂き、対応させて頂く形にしたいと思います。
#1999年3月5日#Gz#
いろいろとご意見をいただきましてありがとうございました。
PDMと一言書いただけで、こんなにレスが帰ってくるとは思いませんでした。
皆さん苦労されているんですね。
正直、PDMについては規模が大きすぎて自分の力の無さを痛感する毎日です。
ソフトウェアについても、どれがいいのか落とし所がむずかしいです。
ここで、愚痴ってもしょうがないですが・・・
谷口さんのご意見大変参考になりました。
私も解析結果は、他の製品データや実験結果といっしょに保管して、同列で扱うべきだと思います。
解析データだけでデータベースを構築した場合、これだけで運用するのは、非常に危険
だからです。
理由は、多くの人にとってDBの内容は、絶対のものになってしまうからです。
DBからデータを参照しようとするときに、このデータが本当に正しいかどうか疑う人間は、
まずいないでしょう。こういった意味で、製品にまつわる実験結果や解析結果は、なるべく
総合的に評価できるような形でDB化する必要があると思います。
また、解析結果についてきちんと評価できる人間の承認のもとでデータを構築する必要が
があるでしょう。
PDMにしても、DBにしてもコンピュータシステムより、人間が絡む会社システムをどうするか
のほうが何十倍も難しそうです。
#1999年3月5日#David#
谷口さんの理路整然とされたレスには感心しました。
さて、私も相談をいくつか受けたことがありますが、経験上の最大のポイントでいいますと
図面管理（3DCADはモデル、構成情報）、採番、履歴が現在整理されていない会社がまだまだ
多いということです。ほとんどの製品設計が過去の製品データを再利用する流用設計で、且つ
各パートに何人かが関わるコラボレーション設計であるならば、データ検索、共有、排他制御ときて
ワークフローがついてくるのではと思います。つまり、図面（設計に関連する情報と置き換えても
いいですが）管理の体系化が最大の問題であり、これが解決されないと次（PDM)にいけません。
意外と、図面管理システムなるものから、考えていくと悩みが早く解決するかも知れません。
Gzさん、がんばってください。
(編集担当：burning 2001/12/20)