MBD・MBSEを成功裏に導入するための秘訣 ～何のためにモデルを活用しますか？～（その1）

 

皆さま、こんにちは。

IDAJの玉手です。

自動車のみならずさまざまな分野において、モデルベース開発（Model Based Development：MBD）やモデルベース・システムズエンジニアリング（Model Based Systems Engineering：MBSE）を導入しようという取り組みがこの数年、加速度的に進んでいます。一方で、取り組みをはじめたものの設計開発の現場では上手く活用できていない、いつの間にか手段が目的化してしまい取り組みが形骸化してしまっているといった課題が顕在化しているのも事実です。本記事では、MBD・MBSEを活用したプロセスのありたき姿と現状を対比しながら、いかにして「現場に根付いた」枠組みを構築して行くのか、そのポイントと秘訣をご説明したいと思います。

MBD・MBSEに期待されていること

2021年版のものづくり白書によると2つのポイントが示されています。

• レジリエンス：サプライヤチェーンの強靭化

昨今の半導体不足のように、突然、材料や部品が入手できなくなるリスクに対して、どのような対応をとるのか考えておく必要があります。

• グリーン：カーボンニュートラルへの対応

例えば、アップル社では製造から廃棄、リサイクルにいたる製品のライフサイクル全体でのカーボンニュートラルを目指すために、各サプライヤーに対してもカーボンフットプリントの提供を求めています。また2030年、2035年に事実上内燃機関を持つ新車の販売は禁止されるというルールや規格の変更によるリスクにも備えなければなりません。

では、実際にどのように備えておけばよいのでしょうか。2020年版のものづくり白書に掲載されている2つの観点を元にご説明します。

• Ordinary Capability：技能的効率性（Do the Things Right）

これは、設計開発の効率性を求めることです。従来のモデルベース開発で期待されてきたコストの削減、業務効率と業務品質の改善、設計品質の向上、製品性能の向上があたります。

• Dynamic Capability：顧客ニーズとの一致（Do the Right Things）

変化する顧客の要求に対応するには、柔軟性を身に着けることが重要だということを示しています。このために必要な能力は3つあります。

• 脅威・機会の感知（Sensing）
• 機会を補足して資源を再構築・再結合し競争優位を獲得（Seizing）
• 競争優位性を持続可能なものにするために組織全体を変容（Transforming）

これらを実現するための一つの手段として、デジタルトランスフォーメーション（DX）を強化することが必要だと謳われています。つまりこの「Dynamic Capability」とは、事業の環境や顧客の要求の変化に対して「柔軟」かつ「迅速」に対応する力だと言い換えることができます。

 

従来の設計開発に照らし合わせて、この変化への柔軟かつ迅速な対応というのはどういうことなのか、イメージを簡単にまとめました。

例えば、法規制が厳格化し、より静粛性が求められるようになるという、ルールや規格が変わるリスクへの対応においては、元のシステムの構造や設計、要素をどのように変えればその要求を実現できるのかを考えます。また、半導体素子の供給が不足し代替品を検討しなければならない設計変更が行われたという、材料や部品が入手できなくなるリスクへの対応では、元のシステムに求められた要件や性能がどのように変わるのか、従来の性能を担保するための代替案は存在するのか、このようなことを考えます。

従って、設計開発プロセスのありたき姿としては、従来のシステムのコンポーネントの最適化といったモデルベース開発を通してデジタル技術を使い倒すことによってまずは、Ordinary Capability（技能的効率性“Do the Things Right”）を実行し、この過程で得られたナレッジを蓄積し、業務効率の改善によって獲得したリソースを活用することによって、将来の設計変更に対して柔軟かつ迅速に対応ができるようにデータを活用する、つまりDynamic Capability（顧客ニーズとの一致“Do the Right Things”）を磨いていくことがモデルベース開発（MBD）、MBSEに求められるありたき姿だと考えています。

 

MBD・MBSEを成功させるための秘訣

まずは、モデルベース開発について簡単にご説明します。

上流側で要求分析、アーキテクチャ設計を行い、前半では、システム設計やサブシステムの設計に1D CAEを使った機能設計を取り入れます。ここでは、システムの挙動の検証や最適諸元、目標達成度の予測などにモデルを活用します。その後徐々に設計を詳細化し、最後にCAEによる形状設計の領域に入り、寸法値を決めます。このプロセスを一つ上位の階層と一つ下位の階層で、小さなループを回しながら実施していくのが一般的なモデルベース開発のイメージになろうかと思います。

 

こういったプロセスの実現を阻む壁が、そこかしこに存在することもまた事実です。

私が普段、お客様とお話をする中で壁になっているなと思うことをいくつか具体的にご紹介します。

[壁1] 要求分析やアーキテクチャ設計を行うために、機能ばらしやSysMLツールを導入してみたが、どう設計に活用して良いかわからない

[壁2] 1D CAE（1次元CAE）を用いた機能設計やシステム設計を進めたいが、開発プロセスに浸透させることができない

[壁3] 機能設計と形状設計のプロセスが分断されている

[壁4] 設計業務でCAEや最適化技術を定着させることができない

これらの課題を克服するには、どうすれば良いのか？弊社からのご提案をご説明していきます。

プロセスを設計する

こちらは、現在、比較的多くの会社様で運用されているモデル活用の姿です。

企画から、性能、品質、コストといった製品に対する要求が下りてきます。機能設計のステップで非常に粒度の粗い1Dモデルで各コンポーネントへ目標を割り付けています。ここで使われるモデルは、原理原則に基づいた数式で成り立っている簡易的なモデルです。次に、コンポーネントの設計では、すでに割り付けられた目標値に対して、たいていは3D CAEを用いた詳細な設計に取り掛かります。この後、でき上ったものを組み上げて、実機評価によってその性能を検証します。

ただ、こういったプロセスでは、様々なところでひずみが生じることが多々あります。

詳細設計の段階で、「割り付けられた目標を達成することができなかった」、「システムを組み上げてはじめて目標未達がわかる」、この図に掲載しているヒートポンプのような流体回路の例では「自励振動を起こしてしまってうまく機能しない」など、それぞれのコンポーネントの相互作用による不具合の発生など枚挙にいとまがありません。

 

では、なぜうまくプロセスが機能しない、進行しないのでしょうか。

[要因1] 設計の階層やドメイン間での相互理解が進まない

システム側の目線からは、コンポーネント側で達成可能なスペックや設計制約がよくわからない状態で機能設計が進みますので、どうしてもシステムの性能ありきで目標値を定めてしまいます。一方で、コンポーネント側の目線では、そもそも実現性の低い目標が割り付けられる、目標の設定根拠があいまいなところから設計がスタートしたにもかかわらず、頑張ってその目標値を追ってしまいます。

[要因2] 設計のプロセスとモデルがひもづいていない

各シーンで活用しているモデルの粒度やモデル化の対象範囲が適切ではない。これは、モデルの粒度が粗すぎるために目標の割り付けの精度が下がっている、またはモデル化の範囲が広すぎる／詳細すぎるために実設計で使うことができないということです。さらに評価すべき性能のトレードオフや諸元の相互依存関係というものは、本来、システム設計の段階で見定めるべきであるにもかかわらず、それらを十分に検証できるモデルになっていなかったことも要因の一つです。

 

さて、ありたきモデル活用の姿とはどういったものか、概観をご紹介します。

左側の「L1」が先ほどご説明した「機能設計」、「L4」が「詳細設計」に該当します。モデル活用のポイントは、L1からL4を一足飛びにつなぐのではなく、L1からL4をつなぐモデル（よく使われるのは1次元モデル）を構築してプロセスをつないでいくことです。場合によってはコンポーネント設計の段階でも1次元の詳細なモデルを活用して、上流側の工程と連携させることがあります。つまり、適切な粒度のモデルを挟みながら、段階的に設計を詳細化することが、有効的なモデルの活用につながります。

モデル活用のポイントとは？（1）

必要なモデルの粒度、精度は何かといったモデル化の手段を検討する「How」にばかり目が行きがちではありますが、この「How」を考える前に「When・Why・What」に注目し、それらを明確にする必要があります。

When：モデルを企画設計、機能設計、詳細設計のどのプロセスで使うのか、その評価のタイミングを決める

Why：システムの成立性をラフに検討する、コンポーネントの目標性能を定めるなど評価の目的を決める

What：どのような特性値・諸元を振るか（Input）、どのような性能を評価するか（Output）といった評価対象となるシステムの範囲と評価内容を決める

When・Why・Whatを定めるには、対象システムがどのような前提において、何をどうやって実現するかという根本的な理解が欠かせません。

 

次回は、MBSE（Model Based Systems Engineering：モデルベースシステムズエンジニアリング）とは？ということからご説明します。

 

 

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

株式会社 IDAJ 営業部

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

E-mail：info@idaj.co.jp

TEL： 045-683-1990