CAEからMBD、そしてDXへ向けて ～new NORMを切り拓く武器としてのMBD～（2）

 

皆さま、こんにちは。

IDAJの玉手です。

前回は、DXへ向けて、武器としてのMBDの実現に向けて、現状を解説させていただきました。今回は、モデル活用のあり方について具体的にご説明したいと思います。

DXに向けたモデル活用のあり方：キーワード①設計プロセス

本題に入る前に「段階的詳細化」という考え方について、簡単にご紹介しておきます。

段階的詳細化は、システムに対する要求やふるまい、アーキテクチャ（システムの構造）などを抽象度の粗いものから細かいものへ反復しながら段階的に設計するシステムズエンジニアリングのアプローチのことです。

要求分析、アーキテクチャの設計を個別に深堀りするのではなく、抽象度の粗いものから階層を分けて段階的に詳細化していきますので、これに合わせて必要なモデルの抽象度も段階的に細かくなります。

 

この段階的詳細化について、具体的なイメージをお持ちいただくために、車両のNV特性を例にご説明します。

ここでは、ばね下振動とボデー振動という2つの要件を取り上げていますが、実際には背反する他の特性に対しても同様に分解する必要があるということにはご留意ください。

下図右端に、マウント構造（Mt構造）やマウント材料（Mt材料）といった図面に落とし込むことができる設計情報が並んでいます。段階的詳細化では、要件と設計因子の間を結ぶ中間特性値に着目し、要件と設計因子がどのような関係性を持つのかをひも解いていくところからスタートします。ボデー振動は、サス減衰レート、サスばねレート、エンジンロール振動、エンジン並進振動などの複数の中間特性値によって決まります。その中間特性値の一つであるエンジンロール振動は、ロール剛性とロール慣性から決まっており、ロール剛性は、エンジンマウントの配置、アクティブコントールマウント（ACM）剛性、コンベンショナルなマウント剛性で決まり、ACM剛性が図面に落とし込めるマウントの構造（寸法）情報や材料で決まっています。

 

 

モデルの役割は、各階層でのInとOutを紡いでいくことにあります。L2階層ではエンジンのロール振動をロール剛性とロール慣性という2つのインプット（In）から評価するためのモデルを作成します。従って、最終的な評価指標と設計因子とをつなぐ中間特性値に着目し、そのInとOutを結ぶモデルを作成していくことがモデルベース開発の根幹です。

 

 

では、これまでお話した内容を、設計プロセスに落とし込むとどうなるでしょうか？

L1のモデルでは、バネ下振動とボデー振動という2つのモデルを使って、サス減衰レート、サスばねレート、エンジンロール振動、エンジン並進振動などの複数の中間特性値を用いて評価します。ここでは自動化・最適化の技術を使って、広範に様々なパラメータを探索することができます。パラメータを振った中から今回の設計要件を満たすには、バネ下振動とボデー振動が特定の範囲内に収まらなくてはならないため、結果として入力の範囲がどこに収まるかを評価することができます。

続いてL2のモデルで、エンジンロール振動に着目すると、ロール剛性とロール慣性という2つのインプットから評価するモデルを使って検証します。ポイントは、L1モデルでエンジンロール振動の範囲が決った、つまり設計の制約条件が決まりましたので、上流のプロセスで入力として振ったものが、一つ下流では制約条件、つまりアウトプットに変わることです。L3やL4のモデルも同様に、上位モデルの入力変数が下位モデルの制約範囲になるという数珠つなぎで評価し、最終的には図面に落とすことができる情報である“設計因子”がどの範囲に存在すれば良いかということをひも解くことができます。

ここでのポイントは、広域に解空間を探索し、設計の成立範囲を適切に把握すること、つまり設計を一意に決めずに“幅を持たせた設計”を行うことにあります。

 

ボデー振動に対する要件を濃いブルーの範囲に変更した場合、それが設計にどう影響するのか？をモデルをたどることで評価することができます。

 

つまり、あらかじめ設計の成立範囲を把握しておくことで要件や設計の変更に柔軟な対応が可能になります。

DXに向けたモデル活用のあり方：キーワード②デジタルスレッド

続いてデジタルスレッドについてご説明します。

要件と設計因子の間の中間特性値を把握し、モデルを使って評価することが理想的な姿ですが、ここにたどり着くには、乗り越えなければならない壁が存在します。それは“各設計フェーズで担当者や組織が異なる”という現実です。

各担当者や組織でアーキテクチャの認識が異なる、使用するシミュレーションモデルの粒度や精度がバラバラ、解析結果に対する解釈が違う、設計プロセスそのものが統一されていないといった状況に適切な対応をしていかなければなりません。つまり、各担当者・組織が、アーキテクチャやシミュレーションモデル、結果、プロセスに関して“同じ絵”を共有する手立てが必要なのです。

アーキテクチャの認識が異なるという課題に対しては、SysML言語などを使用した記述型のシステムモデルを使い、様々なダイアグラムでシステムを可視化することで、システムの要求・ふるまい・アーキテクチャを共通認識として共有することができます。この具体的な手段や効果についてのご説明は別の機会に譲り、ここでは効果的なシミュレーションモデルの活用に向けた3つのステップについて詳細に解説します。

• ステップ1：ルールを決める

モデルの使用目的と粒度を決めます。各モデルを開発プロセスの「どこ」で、「何の目的」で使用するのかを明確にし、必要な精度とスピードに応じてモデルの粒度を決定することが大切です。モデルの精度や粒度、目的が決まれば、モデルのインプット・アウトプットがおのずと決まります。場合によってはモデルを連携させることも考慮しておかねばなりません。

また、一人の設計者が作成したモデルが共有されると、それを入手した人が情報を追加して“味付け”し、多くの派生モデルが生成されてしまうことはありませんか？

こうなると、実際に設計に使用したモデルがどれなのか、トレースできなくなってしまいます。これを避けるには、モデル作成に必要な情報や取得方法（過去設計、3次元CAE、実測）を決めておく、キャリブレーションが必要な場合はその手順と合否の判断基準を明確にして、誰が作成しても同じ精度・粒度となるようにしておくことが肝要です。

 

• ステップ2：プロセスを決める

ルールが定まれば、次はプロセスを決めます。これは、各担当者のロールを分けることにもつながりますが、システム設計者、コンポーネント設計者、CAE担当者がいらっしゃる場合、それぞれの役割とその間でシステムアーキテクチャモデル、シミュレーションモデルをどのように共有するかというプロセス全体を定めます。

 

• ステップ3：データとプロセスを共有する

シミュレーションデータやプロセスの共有という観点では、CAE担当者がルールに則って作成した1Dモデルや数式モデル、3Dモデルなどをプラットフォーム上で共有します。

データには、実測データを使って作成したサロゲートモデル（代理モデル）を準備することもあるでしょうし、3Dモデルで計算時間がかかる場合には、パラメータを振って、近似関数で高速に計算できるモデルへ置き換えることも考えられます。

一方でモデルを使う側であるシステム設計者、コンポーネント設計者は、プラットフォーム上にあげられたモデルを用いて、RPA（Robotic Process Automation）技術によって自動探索します。そしてここで探索された解は、各設計者間で共有することができます。

 

より設計上流で業務フローそのものを管理する、あるいは要件管理、文書、帳票、CAD、測定データなど、シミュレーションに関わるデータ以外のもの管理するのがPLMプラットフォームの役割です。これらはデータベースとしてストックするだけでなく、各プロセス間のトレーサビリティを取った上でシミュレーションプラットフォームとPLMプラットフォームが連携されていること、各プロセスで導出された成果物や検証に使用したデータやモデルがトレースできること、データそのもののトレーサビリティがとれていることが、データとプロセスを共有するというステップにおける大きな役割です。そしてこれが、要件や設計変更に迅速に対応が可能なデジタルスレッドを実現することにつながります。

 

●効果的なシミュレーションモデルの活用に向けたステップ（まとめ）

●	START
● ｜	STEP1 ルールを決める	・モデル作成方法のルール策定による脱属人化 ・キャリブレーション手順の体系化による解析精度の担保
● ｜	STEP2 プロセスを決める	・モデルを使った評価手順および意思決定基準の策定による設計プロセスの標準化
● ｜	STEP3 データとプロセスを共有する	・プラットフォーム上での管理による担当者間でのモデルや結果の共有化と再利用の促進
●	GOAL

おわりに

ものづくり白書の中に書かれている“Dynamic Capability”に着目してここまでご説明してきました。

Dynamic Capabilityを実現するためのアイテムの一つめが、要求や設計変更への柔軟かつ迅速な対応が可能な設計プロセス。ここでは、中間特性値に着目して、システムの構造を抽象度の粗いものから細かいものへ段階的に分解し、抽象度レベルに応じてInとOutをつなぐモデルを適切な手段を選択して構築する「システムアーキテクチャの階層化とモデルの構築」、各設計フェーズにおいて広域に解探索を行うことで設計の成立範囲を把握するための「RPAの活用」がポイントです。

アイテムの二つ目は、担当者・部門間で認識を共有するデジタルスレッド。モデル作成方法のルール策定によって属人化を廃し、キャリブレーション手順の体系化によって解析精度を担保する「モデル粒度の標準化と精度向上」、モデルを使った評価手順と意思決定基準の策定による「設計プロセスの標準化」、モデルや結果の共有化と再利用を促進し、データとプロセスのトレーサビリティを確保する「プロセスと成果物の管理するためのプラットフォームの構築」がポイントとなります。

Dynamic Capabilityを実現するためのアイテム（まとめ）

設計プロセス：要求や設計変更への柔軟かつ迅速な対応

システムアーキテクチャの階層化とモデルの構築 ・中間特性値に着目しシステムの構造を抽象度の粗いもの→細かいものへ段階的に分解 ・抽象度レベルに応じてInとOutをつなぐモデルを適切な手段を選択して構築

RPA; Robotics Process Automationの活用 ・各設計フェーズにおいて広域に解探索を行うことで設計の成立範囲を把握

デジタルスレッド：担当者・部門間での認識の共有化

モデル粒度の標準化と精度向上 ・モデル作成方法のルール策定による脱属人化 ・キャリブレーション手順の体系化による解析精度の担保

設計プロセスの標準化 ・モデルを使った評価手順および意思決定基準の策定による設計プロセスの標準化

プロセスと成果物の管理 ・モデルや結果の共有化と再利用の促進 ・データとプロセスのトレーサビリティの確保

 

今回ご紹介したのは、あくまでもデジタルトランスフォーメーション実現のための一つの切り口に過ぎませんが、今後、お客様がデジタルトランスフォーメーションを推進される上でのアイディアとなれば幸いです。

 

■オンラインでの技術相談、お打合せ、技術サポートなどを承っています。下記までお気軽にお問い合わせください。ご連絡をお待ちしています。

株式会社 IDAJ 営業部

Webからのお問い合わせはこちら

E-mail：info@idaj.co.jp

TEL： 045-683-1990