モデルベース開発（MBD：Model Based Development）、今まさに様々な企業で取り組んでいらっしゃるのではないかと思います。
ソフトウェアを扱っているCAEベンダーとしては「それぞれのツールをどのように設計プロセスに融合して、モデルを使い分けながら、設計プロセスを円滑に進めるべきか」にフォーカスして、一つのアプローチとしてIDAJが考えるMBD像とあわせてご紹介します。

MBDの必要性

自動車業界における電動化（HEV・EV）や排ガス規制、自動運転（CASE）といった市場の新たなニーズへ対応するために、既存のパワートレイン領域における従来工数を大幅に削減しなければならないといった社会的要請があります。一方で、2030年でも90％の自動車に内燃機関が搭載されるという統計が示すように、内燃機関の開発を終了するわけにもいきません。

パワートレイン別長期見通し（出典：自動車新時代戦略会議（第１回）資料、平成30年4月18日 経済産業省 ）

新しい分野と既存分野の開発を、効率よく設計を進めていかなければならない状況に置かれるようになるつれ、CAEが一つのアプローチとして注目されるようになりました。

ここでは、ハイブリッドのドライブトレインを例に、CAEの使われ方を確認してみましょう。
まずは、プラント設計担当が各設計ドメインへ目標を下ろします。実際の設計では、これが一つの組織で発生しているとは限りません。サプライヤーへこういった設計目標を下しているケースも多々あります。
バッテリーの設計者は、電池の出力はどれくらい？、配置はどうする？、温度管理は？といったことを考えながら段階的に詳細な設計へと落とし込み、最後にはコンポーネント設計に入ります。
評価フェーズにおいて、試作で評価していたところを、CAEに置き換えてバーチャル評価を取り入れ、試作回数を低減することがCAE導入の当初のねらいでした。パックの設計段階で放熱が不十分であることがわかれば、設計に戻ってヒートシンクを大きくするといった設計変更を加えて最終的にシステムとして成立するものを作成します。これを、PCU担当、冷却系担当がそれぞれに設計を進め、各ドメインに与えられた目標を満足するものを作ります。

このような従来のボトムズアップのアプローチにおける問題点は、一つ一つのドメインは設計として成立しているが、これらをプラントとして組み合わせるときに初めて問題が発覚することです。そうなると、最初に立ち戻って設計を全部やり戻すかと言うと、そんな時間はありません。結果的には、“プラントの方は設計変更できないので制御で何とか頑張ってください”といった調整が発生し、システム性能未達による手戻りが減らないという状況に陥ってしまいます。

この従前のアプローチに対して、MBDによるアプローチの概要をご説明します。
まず、市場要求から性能目標へ、つまり要求分析やアーキテクチャ設計と呼ばれるアプローチをとります。「要求」からスタートし、それを実現するために必要な機能、その機能を具現化するための要素を検討することで、システムのアーキテクチャを設計します。その上で、実際のシステムの挙動やふるまいを1D-CAEを用いて検証し、システムの要求を満たすための各サブシステムの目標性能を決定します。先ほどの例では、ハイブリッドのドライブトレインとしての目標値を達成するために、バッテリーやモーター、DC-DCなど、それぞれにどの程度の目標値を割り付けていけば良いかを1D-CAEによって十分に検討します。

これを段階的に、システム、サブシステムの目標値へと下ろす機能設計のフェーズを経て、最終的に各コンポーネントに課せられた目標値を達成するための3次元の形状寸法を検討する、形状設計のフェーズへ移ります。このフェーズでは3D-CAEが活用されます。

先ほどのボトムアップのアプローチに対して、上位のモデルが下流工程の「動く仕様書」となるトップダウンのアプローチがMBDのコンセプトです。

MBDのねらい

エレキやメカなどの各ドメインを独立的に設計するのではなく、各ドメインをまたいで評価し、その結果として開発プロセスが改善されることで、開発を効率化していくことがMBDのねらいです。
先ほど、“性能が未達になれば制御という一つの分野でそれをカバーする”という例をあげましたが、これはMBDの反例で、必要なのは、本質を見定めて各ドメインを跨いでシステム全体を俯瞰しながら設計を突き詰めて行くことにあります。つまり、高いレベルでの協調設計を実現するための、あくまでも一つの手段であると考えます。

現実には“十人十色のMBD像”

MBDという言葉が一般化するなかで、様々な解釈や考え方が生まれています。

• 自動車のような複雑なシステムに適用できる手法であり、部品単体の開発には必要ない

• できる限り高精度のモデルを用いて全ての実測をシミュレーションに置き換える

• 粒度の低いモデルで高速に検討を行う手法である
• 開発工程の上流側では3D-CAEは使用しない

• 上流から下りてきた要件を満たすように設計すれば良い
• ボトムアップのフィードバックは不要である

これらに対してMBDの本来の目的に立ち返り、「高いレベルでの協調設計を実現するにはどうすれば良いのか」という視点で、MBDを定義したいと思います。

【システムを俯瞰した設計開発の重要性】
開発のターゲットとなるシステムやコンポーネント（SOI：System of Interest）だけでなく、その「外側」も意識しなければなりません。SOIは、システムズエンジニアリングで使用される用語の一つで、例えばエンジン設計であればエンジンが、ターボチャージャの設計であればターボチャージャがSOIとなります。このSOIだけではなく、それらを取り巻く外部環境（境界条件）や、1つ上位のシステムはどのような要求・要件を満たす必要があるのか、そこからどんな理由があって自分の設計しているSOIに、要求・要件が下りてきているのかを考えます。
自動車業界では、「モデル流通」という考え方が広まっていますが、これはまさに自分のシステムだけではなく、一つ上位のシステムに自分のシステムを組み入れた場合のふるまいを、設計開発段階で検討する必要性を表しているのです。

【段階的詳細化】
段階的詳細化とは、システムに対する要求やふるまい、アーキテクチャなどを、抽象度の粗いものから細かいものへと反復しながら段階的に設計するという考え方です。
システムズエンジニアリングや機能ばらしの取り組みで陥りがちなのは、下図の左側のように要求、ふるまい、アーキテクチャを上から下まで順番に深掘りするというアプローチです。この場合、SysMLに代表されるシステムモデリング言語を用いて構築するシステムダイアグラムは自ずと巨大化します。結果として、対応する解析モデルもあらゆる物理現象を反映させた複雑かつ大規模なモデルが必要となり、要件やアーキテクチャとのトレーサビリティがとれなくなります。つまり、設計の見える化にまで到達したは良いが、その活用方法の部分で次の手を考えあぐねてしまっている状況です。

これに対して「段階的な詳細化」は、下図の右側に示すように、要求・ふるまい・アーキテクチャを設計のフェーズに合わせて同じ抽象度で横並びに分析します。これに対応して、設計したシステムの検証・妥当性確認を行うためのシミュレーションモデルの抽象度が決まります。つまり、要求分析やアーキテクチャの設計を抽象度の粗いものから階層を分けて段階的に詳細化していくのに合わせ、必要なモデルの抽象度も段階的に細かくなるということです。

【Automotive SPICE】
ヨーロッパでは、MBDの考え方を標準プロセスとして構築しています。その一つがAutomotive SPICEです。 Automotive SPICEは、車載システムの開発プロジェクトにおいて、どのようなプロセスで設計を進め、どのような成果物を残すべきかという設計開発において実施すべき活動を、ベストプラクティスとしてまとめた「開発プロセスの評価と改善のための共通言語」です。
ヨーロッパではOEMメーカーが各サプライヤーに対してAutomotive SPICEへの準拠したプロセスで設計を行うことを要求しています。アセスメント評価によってAutomotive SPICEに対する各サプライヤーの対応レベルが分類されており、OEMメーカーはサプライヤーに対して、プロジェクトの参画条件として一定以上の対応レベルを要求することができます。これには、標準プロセスを導入することによってOEM側は、サプライヤーの開発プロセスをプロジェクトごとに個別に評価検証する必要がないというメリットがあります。また、サプライヤー側にとっても、取引先であるOEMごとに開発プロセスを変える必要がなく、製品開発に注力できるというメリットが生まれます。

Automotive SPICEはもともと、制御開発を対象としていましたが、その後、プラグインコンセプトという考え方を導入し、ソフトウェアだけでなく、ハードウェアやメカの開発プロセスにも拡張されました。それがメカニカルエンジニアリング向けのプロセスモデルであるMechanical SPICEです。

ここからは、ソフトウェア開発からメカ開発に視線を移して、Mechanical SPICEとMBDの関連についてご説明します。
Mechanical SPICEで最初に取り組むべきなのが要求の分析と機能の展開です。
先ほど、一つ上位のシステムの要件を俯瞰する必要があるというお話をしましたが、まさにそれが求められます。上位のシステムに対する要求からターゲットとするシステム（SOI）の要求を具体化して、機能（制御因子）へと展開します。

ここでは、バッテリーの冷却システム設計を例に、イメージを具体的に示します。
一つ上位のシステムである電動パワートレインシステムに要求されているのが、高出力化、耐用年数の向上、消費減力の削減、ダウンサイジングだと仮定します。これを今回のSOIである冷却システムに対する要求に下ろすと、例えばバッテリーの出力、耐劣化性能、ポンプの小型化といったものになります。これらを数値目標化し、さらに制御因子へと分解します。もちろん、ここには背反する目標が存在しますので、その分析も必須です。

2つ目のステップでは、各機能にサブシステムの構成要素を割り当てて、要求を実現するためのコンセプトを検討します。ここでは、各構成要素の間の伝熱経路に着目し、以下のような熱回路網で熱的なふるまいを評価することで、冷却方式やヒートシンクの要否、そのサイズ、必要な冷媒流量などを検討します。この段階で使用するモデルは、非常に粒度が粗いものであるということに留意してください。

3つ目のステップでは、自分が設計を担当する部品以外の構成要素の背反を考慮した上で、ステップ 2のコンセプトの成立性を検討し、サブシステムの特性値に対して目標を割り付け、成立性確認や目標値割付けを行います。
先ほどのステップでは熱的なふるまいにだけ着目しましたが、冷媒の流量やヒートシンクの伝熱面積は、冷媒を流す流体回路の圧損とトレードオフの関係にありますので、これを見定めて初期のコンセプトが成立するか否かを確認します。

ここでは熱回路と冷却回路だけをピックアップしましたが、実際のバッテリーの熱マネシステムは、さらに多くのサブシステムやコンポーネントが介在していますので、広範囲において背反性を考慮して設計し、結果的にその設計全体でのバッテリーの温度評価や冷却回路の出口温度、冷却回路の圧損といった項目を、全体システムを俯瞰しつつ決めてる必要があります。

4つ目のステップは、サブシステムに対する要求を段階的に下位のサブシステム、もしくはコンポーネント目標に落とし込むという設計の段階的詳細化へと進みます。
バッテリーの冷却回路に関しては、一つ上位のシステムで検討したバッテリーの温度や出口温度、圧損を満たすために、冷却回路をどのように取り回せば良いか、各流路への流量の配分をどうするか、このときの回路の圧損はどの程度になるのかを、もう少し粒度の細かいモデルを用いて検討します。

最終的には、4つ目のステップで検討した条件を満たす3次元形状を同定する必要があり、ここで3次元CAEを活用します。バッテリーの冷却回路を例にすると、まず、1D-CAEを用いて目的のバッテリー温度となるような冷却回路の流量配分を決定します。続いて、この流量配分を達成するような3次元形状を3次元CFDによって検討します。ここで重要なのは、3次元的な形状因子の情報を1D-CAEへ戻して、システムとしてこの設計の妥当性を検証するという、バリデーション（Validation）とベリフィケーション（Verification）のサイクルを回さなければならないという点です。例えば、設計したダクト形状によっては熱伝達係数が想定していたよりも下がってしまい、目標としていたバッテリー温度に達しないという可能性があります。したがって、3次元設計を行った後に、得られた熱伝達係数の値を1D-CAEへフィードバックし、設計の妥当性を確認する必要があります。 これは、1Dと3Dだけの話ではなく、それぞれの階層において、上流から下流へと下りていく段階で、より下流の設計を上流に戻したときに、その設計に果たして妥当性があるか否かをチェックしなければなりません。これは、“小さな「V」を回しながら下していく”と表現されることもあります。

ここからは、これまでにご説明したアプローチを踏まえた上で、いかにしてモデルを活用するかという、CAEのお話に移ります。 MBDのねらいは、高いレベルでの協調設計を実現するところにありますので、これを実践するために留意すべき点、モデルの活用ポイントを4つにまとめました。

1. Mixed-Fidelity：粒度の異なるモデルの活用
2. Multi-Disciplinary：ドメインを跨いだ協調設計
3. Multi-Dimensional：3D CAEの活用
4. Cross-Divisional：プロセスの標準化とデータ管理

1. Mixed-Fidelity：粒度の異なるモデルの活用

CAEやMBDに取り組む際、よく陥ってしまうのが、全ての物理現象を1D シミュレーションに取り込むのが究極の目的であると勘違いして、精度や詳細度ばかりを追及してしまうことです。しかし、高いレベルでの協調設計を実現するというMBDの本来の目的に立ち返ると、必ずしも、詳細なモデルが良いモデル、計算の早いモデルが良いモデルとは限りません。この先、コンピュータが非常に高速化して、全ての物理現象を一度に、そして瞬時にシミュレーションできるようになれば、それも可能かもしれませんが、現状はそうではありません。やはり設計開発のプロセスに応じて利用するモデルをよく検討し、適切なモデルを選択しながら使っていく必要があります。
例えば、エンジンを表現するモデルでも、マップでその効率を表現するような非常に粒度の粗いモデルもあれば、吸排気込みの複雑な計算ができるモデルもあります。それぞれ利用目的が異なりますので、ご自身が取り組まれる設計において、リアルタイム以上のスピードが要求されるのであれば詳細度の高いモデルを使うことは理にかなっていませんし、吸気脈動やインテークの形状まで詳細に見なければならない状況において、マップモデルを使うことは適当ではありません。

Audi社での実践例をあげてご紹介します。
エンジンの熱マネモデルをイメージしており、Aが最も簡易で粒度の粗いモデル、Dが最も詳細で粒度の高いモデルとして、4つの段階に分けました。
最初は、熱的な成立性を見るだけというフェーズですので、大きな熱マスとしてエンジンを配置し、そこからの放熱経路を熱伝導で表現するという非常に簡単なモデルを使用しています。次に使うのは、もう少し詳細度が上がったモデルで、エンジンを熱マス一つで表現するのではなく、ヘッドとブロック、オイル、熱交換器という形で熱マスを配置し、冷却回路だけはもう少し詳細に設計したいので、詳細なモデルを使って熱の伝達経路をモデル化しています。さらに、エンジンブロックの部位の温度を評価する段階では、熱と冷却回路と連携しながら計算するには、有限要素モデルを用いてより詳細に検討するという一段階詳細なモデルを用います。

このように、使い分けを考えながらモデルを準備します。

熱マネモデルだけでなく、それ以外のコンポーネントについても同様にモデルの粒度を分け、例えばHILSで使うなら全てのコンポーネントを粒度の粗いモデルで、あるいはエンジンの設計に使うなら、エンジンそのものは詳細なモデルを使って、それ以外は粒度の粗いモデルを使って評価します。

2. Multi-Disciplinary：ドメインを跨いだ協調設計

ここでよく登場するのが、コ・シミュレーションの活用です。
弊社製品のGT-SUITEは、車両・バッテリー・モーター・重電系・冷却回路・制御などといった異なるドメインのモデルを一つのモデルとしてつなぎあわせて、任意の走行条件下でのシステム全体の熱マネ評価を実施することができます。つまり、エレキ、メカ、制御といった異なるドメインのモデルをつむぎあわせた上で、設計の上流工程において、これらの背反する関係を見ながら設計することができるようになりつつあるのです。

ここまでできるようになると、すべての物理現象をつなぎ合わせて複雑なモデルを作りたいと考えがちですが、“協調設計を行うこと＝コ・シミュレーションを行うこと”ではないという点には注意が必要です。

例えば、設計フェーズが同じであっても、活用すべきモデルの次元が異なることが考えられます。ここではスイッチング回路のパッケージ構造を、熱設計とノイズ設計とに分けて考えてみましょう。
熱設計は、1Dの熱回路網法を使えば、熱問題をかなり追い込んで検討することができます。これに対してノイズ設計では、スイッチング回路のパッケージ形状そのものが、ノイズの原因となりうるため、寄生パラメータで縮退化させ、理想回路と組み合わせて計算しなければ評価することができません。同じ上流工程における検討であっても、熱なのかノイズなのか、検討する現象によって異なる次元のモデルを使う必要があります。

あるいは、現象をとらえるのに必要な時間分解能が異なるということも考えられます。電気自動車におけるモーターの制御回路を例にとると、車両のシステム評価に必要な時間スケールは1s、モーターのトルク評価は1μs、制御はモーターにあわせて同じく1μs、制御回路のノイズ評価は1nsのオーダーとなります。このようなケースでは、プラント、回路、モーター、制御のすべてをモデルに組み合わせてのコ・シミュレーションは非現実的であり、それぞれを分離して評価することが必要でしょう。

協調設計という観点からもう一つ大切なことは、Vプロセスにおける左バンクのモデルを使った設計と、右バンクの実機を使った適合をどうのようにしてつなぐかということです。
右バンクで実機で検証する場合は、それをプラントモデルとつなげますので、その時点で実機とモデルが混在させるシミュレーション技術が必要です。逆に、右バンク側でECU適合にキャリブレーションツールを使っている場合、このハードウェアを左バンクに適用してモデルの中でECUのモデル適合をするのに使うというアプローチも可能です。

3. Multi-Dimensional：3D-CAEの活用

モデルベース開発と聞くと、どうしても1D-CAEによる高速なシミュレーションを利用して、設計を進めることに目が向きがちですが、最終的には形状決めるところでは、必ず3次元の形状因子を検討しなければなりませんので、3D-CAEは必須です。ただしこれは、1次元から3次元へのOne-Way、または3次元から1次元へのOne-Wayではないということにはご注意ください。

先ほど、設計の下流工程では、3次元的な形状因子の情報を1D-CAEへフィードバックする必要があると述べました。これを実現する一つの方法として、3次元CAEと1D-CAEの直接連携があげられます。サージタンクを例にご説明しますと、サージタンク付近のEGRガスの3次元的な挙動を3D-CAEで計算しながら、1Dのエンジンモデルとカップリングさせてシステム全体のふるまいを解析することができます。しかしこの直接連携には欠点があります。それは、計算に非常に時間がかかることです。
この欠点を解消すべく、最近注目を集めている技術が縮退化（ROM：Reduced Order Model）です。例えばバッテリー冷却では、バッテリーの発熱量や冷却風の流量はバッテリーの使用状態や制御によって過渡的に変化します。これに応じて、バッテリーからの熱伝達量も過渡的に変化します。縮退化という手法は、このインプットとアウトプットの関係（ここでは発熱量と流量がインプット、熱伝達量がアウトプット）を、あらかじめ3次元モデルなどを用いて計算した教師データから、機械学習などの方法を使って高速に計算できる代理モデルに置き換える方法です。1Dシミュレーションの計算速度を犠牲にすることなく解析が可能となるため非常に有効な手法です。

4. Cross-Divisional：プロセスの標準化と管理

モデルの使い分けだけでなく、モデルを作成する環境も大切です。システム全体でみると、モデルの作成者は同じ部署の方だけでなく、異なる部署の方や海外拠点にいらっしゃる方、場合によっては協力会社様の担当者ということもあるでしょう。
Automotive SPICEは成果物が管理されている、そのプロセスが抜け漏れなく実行されていることをチェックする、前後関係や主従関係を持つ成果物の双方向のトレーサビリティが取れていることなど、データ管理とプロセス管理、トレーサビリティの確保を求めています。

ハイブリッドのパワートレイン設計を例にご説明します。このプロジェクトでは、パワートレイン設計と電動システム設計を、別の設計者が担当します。
パワートレイン担当者は、粒度の粗いモデルで構想設計し、詳細設計は詳細なモデルで検討しています。一方で、電動システム担当者は、電動システム用のモデルを作成し、それにエンジンモデルを組み込んでシミュレーションしたいので、パワートレイン設計担当者に対して、エンジンモデルの提供を依頼します。パワートレイン担当者は、とりあえずモデルは細かいに越したことはないだろうと詳細モデルを渡します。電動システム担当者は、その詳細なエンジンモデルを使って、シミュレーションを実施したのですが計算時間がかかり過ぎてしまいました。実際には、この時点でのシミュレーションでは、ここまで詳細なエンジンモデルは必要なかったのですが、オーバースペックなモデルを使ってしまい、結果的に目的としている現実的な時間では計算を終了させることができませんでした。

このような状況が続くと、電動システム担当者自身が、パワートレイン担当者から提供されたエンジンモデルをモディファイし始め、元のモデルの作成者があずかり知らないところで、派生モデルが量産されます。しかし、この派生モデルには、パワートレインの設計が変わってもその内容は反映されませんし、精度が十分に担保されておらず、結果として誤った設計が行われる危険性をはらんでいます。

さらに制御のモデルが関わると、状況はより複雑になります。パワートレインと電動システムで、単位や値の正負が異なる場合は修正することができますが、制御システムの場合は、値を取得できない、値の定義が異なる、必要なセンサ情報がメカ側のモデルに実装されていないなどが問題となり、I/Oの不一致によるすりあわせのための工数が増大することになります。その結果、モデルを用いた効率化にはほど遠い状況を招いてしまいます。

これを打破するために最近登場したアプローチが、Simulation Process and Data Management：SPDMで、「プロセスの標準化」と「モデルデータの管理」が必要だと考えています。

IDAJが考えるMBDとは？

複数のサブシステムで構成されている複雑な製品の開発に対するアプローチなのでしょうか？つまり、自動車のような複雑なシステムに適用できる手法であり、部品単体の開発には必要ないのでしょうか？

必ずしもそうではないと考えています。
MBDは、開発のターゲットとなるシステムやコンポーネント（SOI：System of Interest）を取り巻く環境、1つ上位のシステムに課せられた要求・要件やアーキテクチャを俯瞰して、設計開発を進めるアプローチです。また、開発ターゲットとなるシステムやコンポーネントは必ず何かしらのシステムの構成要素となっているため、同様の視点はシステムの複雑さに関わらず必須で、これがモデルベース開発のスタートポイントではないでしょうか。

できる限り高精度のモデルを用いて全ての実測をシミュレーションに置き換え、設計開発にシミュレーションを活用することでしょうか？開発工程の上流側では3D-CAEは使用せずに、粒度の低いモデルを用いた高速検討するために1D-CAEを活用することでしょうか？

こちらも間違いではありませんが、シミュレーション利用の目的が、単純に試験からシミュレーションへの置き換えだけになってはいけません。MBDは、より良い製品を効率的に設計するための1つの手段にすぎませんので、1D・3D問わず、設計の段階的詳細化に合わせて必要十分な粒度を持つモデルを使い分けることが重要です。

上流工程から下流工程までシームレスに繋がるトップダウンアプローチなのでしょうか？つまり、上流から下りてきた要件を満たすように設計すれば良く、ボトムアップのフィードバックは不要でしょうか？

考え方はトップダウンに違いないのですが、設計の過程では必ず、下流工程の結果を上流工程へフィードバックして、改めて検証するボトムアップのフェーズが存在します。常に上流工程からどのような過程で要求・要件が下りてきたのかを意識することが重要です。


どのようにモデルを活用するのか？
それにどのようなシミュレーション技術が必要なのか？
これらに対して、今後、IDAJから様々にご提案をさせていただきます。