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

 

皆さま、こんにちは。

IDAJの玉手です。

前回は、モデル活用におけるWhen・Why・Whatを定めるために、対象システムがどのような前提において、何をどうやって実現するかという根本的な理解が必要だというお話をさせていただきました。

MBSE（Model Based Systems Engineering：モデルベースシステムズエンジニアリング）とは？

When・Why・Whatを理解するための手段として最近注目されているのがMBSE（Model Based Systems Engineering：モデルベースシステムズエンジニアリング）という方法です。

MBSEについて詳しくご説明する前に、SE（Systems Engineering：システムズエンジニアリング）という手段について簡単にご説明します。

これは、システムを成功させるための複数の専門分野にまたがるアプローチと手段と定義されています。システムの要求分析やアーキテクチャの設計、システムの解析評価（検証と妥当性確認）、システムの統合を含む、システム開発全体にかかるアプローチです。

これに対して、MBSEは、モデルを駆使してSEを実験することということになるのですが、ここでいうモデルは、要求やふるまい、アーキテクチャをダイアグラムで記述した“記述型モデル”と、システム自体のふるまいを検証・妥当性確認をするための“分析型モデル（シミュレーションモデル）”を指します。

SEの本来の定義に則るならば、MBSEは分析型モデルを用いたシステムの解析評価、つまり従来のMBDと呼ばれていた領域を包含することになります。

一方、言葉の用法として“MBSE＝記述型モデルを用いた要求分析、あるいはアーキテクチャの設計”を指すと解釈されているケースも多く、実はここに、落とし穴がひそんでいます。この落とし穴とは何か？という点については、後述します。

モデルベースシステムズエンジニアリング MBSE：Model Based Systems Engineering

モデルを駆使してSEを実践すること

改めて、記述型のシステムモデルの役割を確認しておきましょう。

記述型のシステムモデルの役割は、様々なダイアグラムを使って、当該システムをあらゆる角度から表現するというものです。これらを介して、システムの要求やふるまい、アーキテクチャを異なる担当者間で共通認識として共有することになります。

 

記述型モデルで実現できること、できないこととは何か？

できることの一つに「マネージメントの効率化」があります。

様々なダイアグラムを用いて、開発対象となるシステムの要求、ステークホルダー、必要な機能などを抽出し、整理することで、経験者のナレッジを共通言語化し、ドメインや経験値の異なるメンバーと共有することができます。または、これらの情報を元に、チーム体制、開発期間・工数・予算といったリソース、レビュー項目などを決定することができるようになります。

一方で、記述型のシステムモデルは非常に抽象度が高く、これら抽象的な要求を定量的な設計パラメータにすることは、事実上不可能です。したがって、各ダイアグラムによって要求や機能、要素のバラシといった繋がりの見える化は可能ですが、要求に対する各要素の充足度判断や定量的な性能目標に落とし込むことは、記述型モデルを使ってもできません。つまり、定量的な性能目標に落とし込むフェーズにおいては記述型のモデルではなく分析型モデルを使わなければならないのです。

これらを踏まえると、記述型モデルを使った要求分析・アーキテクチャ設計と分析型モデルを使ったMBDは、本来、プロセスとして切り離すことができないはずなのですが、先述の通り、“MBSE＝記述型モデルを用いた要求分析・アーキテクチャの設計”であるという解釈も相まって記述型モデルという手段ばかりが先行してしまい、冒頭にご説明した“課題＝壁”につながっていると考えています。

 

プロセスを左から、要求、機能、要素、特性、仕様、設計とすると、前半の要求分析とアーキテクチャの設計では、システムの要求やふるまい、アーキテクチャを、記述型モデルを使って可視化し、階層やドメインが異なる担当者間で情報を共有する中で、背反や相互依存関係を整理し、結果的にモデルで何を評価すべきなのか、その内容と仕様（When・Why・What）を明確にします。

プロセスの後半部分では、これらを書き下したものの結果として、モデルを用いて目標設定の妥当性確認やトレードオフの定量評価を実施する、または上位階層の要求を下位階層の目標値へと定量的に割り付けますが、ここは従来の分析型モデル（＝シミュレーションモデル）を用いたMBDの役割となります。

もう一つ付け加えるならば、記述型モデルによってつくられたダイアグラム、特に機能ブロック図と呼ばれるものは、分析型モデルと対比させることで、このモデルが何を評価するためのモデルなのかということを明示的に残しておくことができる、つまり可読性を向上させることができます。これも、記述型モデルの副次的な効果と言えるのではないでしょうか。

MBSE・MBDに期待される効果

1．開発初期から早期にシステム成立性を検証

記述型モデルを使うことによって設計に関する思考を見る化し、早期にシステムの仕様を決めます。またそれらを担当者に間で合意することができます。主に1D CAEを使うことになるかとは思いますが、分析型モデルでアーキティチャの検証を行うことによって、早期にシステム要求の妥当性や成立性を評価することができます。

2. 作成したモデルを別プロジェクトで再利用

副次的な効果となるかもしれませんが、要求⇒機能⇒論理⇒解析モデルをひもづけ、トレーサビリティを明らかにすることで、上位の要求が変更された場合に、解析モデルに対してどうやってその変更を反映させるかを、別プロジェクトの担当者であっても容易に理解することができます。また解析モデルに含まれている要素、あるいは要素間でやり取りする物理量や情報を直感的にわかりやすく記述型モデルに残すことによって、解析モデル自体がどのようなものかという可読性を向上させ、モデル作成者以外でも内容を理解することができます。

 

ここまでプロセスを設計する上での課題やポイントをご説明してきましたが、続いてはプロセスを運用する上での課題やポイントを解説します。

MBDに期待される効果を、図示してみました。

従来の試験を3次元のCAE（3D CAE）に置き換えることによって、試験にかかる工数を圧縮します。そこからさらに、コストの削減要求やリソースの減少といった昨今の状況に対応するために、自動化や1D CAE（システムシミュレーション）、最適化、さらにはAIといった技術を活用することによって、工数を圧縮することが可能になります。結果として将来的なリソースの減少に対応し、さらに空いたリソースをDynamic Capability（事業の環境や顧客の要求の変化に対して「柔軟」かつ「迅速」に対応する力）に投入できるという効果が期待できます。

 

一方で、現状よくあるモデル活用における代表的な課題には、以下のようなものがあります。

・担当者によって3D CAEの解析結果にばらつきがあり設計にうまく活用できていない

・思いのほか解析に時間がかかり実設計に使えない：最適化計算技術を導入しても、単発計算に比べると計算時間がかかるため、時間をかけてでもベストな設計を追うのではなく、深追いせずに及第点の設計でとどめておくという従来の手法から抜け出せない

・担当者によってモデルの活用度合いに濃淡がある：ある人は多目的最適化を設計に活用しているが、別の担当者は単発計算で設計を比較している、または設計ではCAEを活用せずに、不具合が発生した際の原因解明にだけ使用しているなど

・解析専任者は、普段の業務が忙しいため新規技術の導入や利用者支援にまで手が回らない

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

メッシュ、物理モデル、その他の解析条件、結果処理方法など、モデルの作成方法と仕様手順をルール化する、つまり標準化するとともに、設計プロセスを整流化することが重要です。

How：Source（どこから情報を得て） ⇒ Input（どういうインプットとして準備をして） ⇒ Process（どういうプロセスにかけて） ⇒ Output（どういう成果物を得て） ⇒ Consumer（それをどこに保存するのか） という評価の流れ（SIPOC）を決める

Who：各評価プロセスの担当者（ロール）を決める

Where：各評価プロセスで必要なデータや、成果物の保存先と実行場所（インフラ）を整備する

課題を克服して、モデルを活用したプロセスを設計開発に定着させるためには、業務の標準化とプロセスの整流化が不可欠ということになります。

 

CAE業務の定型化例

課題	人や製品によって条件や結果処理方法等が異なり、CAE結果にバラツキが生じている：人によってメッシュの作成の仕方（切り方）が異なるため、結果がばらつきが発生します。またこれは意外に見落としがちなポイントなのですが、ある人はある点における温度で評価し、またある人は平均値を見ているなど、結果の評価の仕方のバラツキによっても結果が変わります。
改善策	CAEの条件や結果処理方法などを標準化し、その他CADモデルの準備の仕方などの影響因子も含めてルール化する必要がある
効果	誰でも社内外へ品質を担保した結果を提示できるようになる、CAEの結果がおかしいので計算をやりなおすといったCAE計算の手戻りを削減できる、一番大きな効果はCAE作業の自動化が可能になる、最適化ツールやAIの活用が可能になる

 

CAEプロセスの適正化例

課題	計算負荷が高く、複数ケースの計算をするには時間が足りないため、計算点数が少なくなる、最適化の導入などの多点での検証が難しい
改善策	詳細なCAEを簡易CAEに一旦置き換えて、パラメータスタディを行った上で、最終的に出てきたベストな答えを詳細CAEを用いて確認計算するようなプロセスそのものの組み換えというものが非常に効果的。ここで言う簡易CAEの置き換えというのは、従来は3Dモデルですべて検証していたものを2Dモデルでパラスタをやってみる、あるいは定性的な傾向は捉えられるという前提において細かいメッシュで確認していたものを粗いメッシュでの定性評価に置き換える、またはCADモデルを簡易化したラフなモデルで検討を行った上で詳細モデルでの確認計算を行うといったプロセスの置き換えが有効
効果	短時間で複数案の検証が可能になり、改善案の早期提案につながること、計算の高速化によって最適化やAI技術が活用しやすくなる

プロセスの見える化と整流化例

課題	標準化や適正化を行い、ルールを定めただけではなかなか指示が伝わらない、理解できない、あるいは技術継承ができず結果的に元の属人化、スキル依存の状態に戻ってしまう、担当者が変わるとこれまでの取り組みが途切れる、また何か困ったことが起こると作り直すというように開発フローそのものが形骸化する
改善策	プロセスに関わるインプット、プロセス、アウトプット（成果物）を定義して書き下す、各プロセスの担当者を決める、各プロセスに必要なデータや結果として出てくる成果物の保存先と実行場所を決めて見える化することが重要
効果	SIPOCを明確に決め、その結果として対象となるプロセスが整流化できると、これをそのままSPDM(Simulation Process and Data Management)またはPLMプラットフォームの中で運用できるようになる、データのトレーサビリティが取れる形で管理できる

 

まとめ

モデルを作成する上で、どういった評価のタイミングで（When）、どういった目的で（Why）、何をインプットとアウトプットとしてモデルを使って評価をするのか（What）、これを考えたうえで、モデル化の手段を検討する（How）、これによってプロセスそのものを設計することになります。

そして、作成したモデルをどのように運用するのか、モデルの作成方法と仕様手順をルール化（How）、プロセスの評価の流れ（SIPOC）を整流し（How）、各評価プロセスの担当者（ロール）を決めて（Who）、各評価プロセスで必要なデータや成果物の保存先や実行場所といったインフラを整備（Where）します。

 

プロセス構築の全体像を示します。

まずは現状プロセスと要求分析・アーキテクチャを可視化し、これらを対比させることによって現状のプロセスにおける問題点を洗い出します。そこからプロセス（When・Why・What）に落とし込み、モデルを作成し、モデルの使いかたやルールを決めます。これによってプロセスを構築し整流化することができます。

 

ここまでご紹介したプロセス構築に対して、IDAJでは、1D/3D CAEのモデリング（下図青色枠）、最適化・データ分析コンサルティング（紫色）、プロセスの整流化や業務の標準化を終えられたものに対してSPDMのプラットフォームに実装するというシステム構築の領域（緑色）、また上流側のMBSEコンサルティング（黄色）も対応します。さらに、このようなプロセス全体を包括してご提案するMBDプロセス構築コンサルティング（オレンジ色）もご提供しています。

 

お客様の課題などをお聞かせいただき、その解決に向けて一緒に取り組ませていただければと存じます。

 

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

株式会社 IDAJ 営業部

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

E-mail：info@idaj.co.jp

TEL： 045-683-1990