解析主導型設計が提唱されて10年以上が経過し、フロントローディングを実現する手段としての設計CAEの導入も一般的なものになりました。特に近年では解析ソフトウエアの堅牢性が向上し、また、クラウドなど計算環境の充実もあり設計テーマによっては100回を超える解析評価を伴う事例も増えてきています。一方で、事前検討で最適化をしても設計変更が入りやり直しになる、設計変更が入るタイミングが予想できないため解析リソースの計画が立てられないといった問題も増えてきました。

本テーマでは、真に設計開発に活かすための設計CAE評価の在り方を考えます。

現状の解析プロセスの分析

設計CAEによる事前検証が組み込まれた開発プロセスは図1のようになります。

1. 要求の収集：製品の価値を生み出すために実現するべき要求を収集
2. 設計課題設定：要求が実現されたといえる設計目標値の設定、目標値達成のためのリソース（設計空間）の割り当て
3. モデル検証：CAEによる設計目標値を達成するための設計パラメータの検討、最適化
4. 設計すりあわせ：他の設計課題との設計パラメータのすり合わせ
5. 試作試験：設計案の実効性確認、設計課題の妥当性検証
6. 出図：設計案の決定

このフローでの「モデル検証」の価値（達成度）は「設計パラメータにより獲得できる性能/目標性能」と定義できますが、「設計すり合わせ」で他の設計課題を解決するため、あるいは「試作試験」で発生した新しい課題に対応するための仕様変更によりリセットされるリスクがあります。

図2は上記の「モデル検証」プロセスの進捗管理を可視化した例です。「モデル検証」プロセスを「要件定義ツリー構築」などの小プロセスに分解し、獲得価値を「設計パラメータにより獲得できる性能/目標性能」と置いて計画、管理をしています。赤・青・黄色の点は解析による最適化の試行を表現しており、それぞれ試行とともに獲得性能が向上しているものの、設計空間の変更により振り出しに戻っている状況がわかります。現状（EarnedValue）は設計目標を達成する設計パラメータが見つかっており計画（PlannedValue）に比べて先行していますが、仕様変更のリスクがありリソース解放が難しい状態です。

この試行の様子を設計空間上で表現すると図3のようになります。右図では、初期の設計空間（選択可能なパラメータの範囲）が仕様変更により次第に狭まっている様子を示しています。この図から、与えられた初期案を中心に最適化検討をすすめているものの、仕様変更により設計空間が制限されて検討結果が使えなくなり、未検討の空間に移動している様子がわかります。

あるべき解析評価の価値定義

このような仕様変更に強い解析検討の手法として、設計空間探査が挙げられます。設計空間探査では、初期案ベースの局所的な最適化ではなく、図4赤色の点のように設計空間全体の傾向評価を行ったうえで、設計検討の進捗に合わせて最適化検討（青色の点）、ロバスト性検討（黄色の点）とステップを進めていきます。この手法での解析評価の価値は「設計空間の傾向の把握」ですので、進捗評価指標は「検証範囲/設計可能範囲」が適当です。

この設計空間探査による評価を進めることにより、従来の解析結果一つずつを追いかけていた「点でとらえる開発」から、設計空間と性能空間の全体をとらえる「面でとらえる開発」にシフトできます。「面でとらえる開発」では、図5に示すように採用可能な設計空間範囲が可視化されるため、「設計擦り合わせ」プロセスでは重ね合わせによる複数課題に対する実現可能性を考慮したすり合わせが行えます。

まとめ

これまで設計CAEのプロセスにおいては、仕様変更によりリセットされることで解析評価の価値が下がってしまい、また進捗管理が困難になる問題がありました。そこで、今回のテーマでは仕様変更に強い「面でとらえる開発」に移行するために、解析評価プロセスを設計空間探査に切り替え、解析評価の価値定義を「設計パラメータにより獲得できる性能/目標性能」から「検証範囲/設計可能範囲」へ置き換えることを提案しています。

本内容が皆様の設計検証業務の一助となり、解析評価の価値向上に貢献できれば幸いです。

サイト内関連リンク