ブログ

MBSEのツールチェーンについて紹介

MBSEのツールチェーンとシミュレーション連携への期待

昨今、MBSEのツールチェーン、特に要求・機能の検討結果やアーキテクチャ設計の結果と、シミュレーションの連携に関する期待が高くなってきていると感じます。

以前のブログで欧州におけるMBSE(Model Based Systems Engineering)およびSE(Systems Engineering)の標準言語であるSysMLの動向に関する調査結果を紹介しましたが、そこでもSysMLに今後期待する項目としてシミュレーション連携が挙げられていました(詳細は上記ブログのダウンロード記事をご覧ください)。

図1はMBSEでよく使われるV字開発のフロー図です。要求・機能検討からアーキテクチャ設計、構想設計、詳細設計と開発は進みますので、上流の要求・機能検討、アーキテクチャ設計の結果と、下流の構想設計・詳細設計で使われるシミュレーションを連携したい、というのは当然の要望かと思います。

図1:V字開発フロー

要求・機能検討やアーキテクチャ設計に使用するツールとシミュレーションに使用するツールを連携できれば、シミュレーションモデル構築の手間を省くことができるため開発効率は上がります。しかし一方でツールを連携するために必要な労力(Effort)がツール連携により得られる利益(Benefit)を上回っては意味がありません。

またSEやMBSEの目的はシステムを成功に導くことですので、シミュレーションとの連携が目的とならないように気を付ける必要もあります。

以上を踏まえた上で、本ブログではシミュレーションも含めたMBSE領域のツールチェーンについて簡単なユースケースを交えて紹介します。

要求・機能検討とアーキテクチャ設計、アーキテクチャ設計と日程・タスク・リソース管理の連携

まず図1中の①、②で示す、要求・機能検討とアーキテクチャ設計、さらにアーキテクチャ設計と日程・タスク・リソース管理の連携について紹介します。ここでは要求・機能検討と日程・タスク・リソース管理に電通総研製のiQUAVIS、アーキテクチャ設計にSysMLに準拠した情報整理・構造化のための標準ツールCATIA Magicを使うと想定し、この二つのツールを使用する理由とともに紹介します。

開発の初期段階、要求・機能検討の場面では各担当者から要求・機能を抽出し検討・集約する必要があります。iQUAVISのツリーでは要求・機能を記載するだけでなく、図2に示すような正展開・逆展開や関連ノードの表示といった機能を使うことで、要求・機能同士の背反や変更の影響範囲を確認できます。iQUAVISではこれらの機能をキーボードショートカットで簡単に使用できるため、手間なく要求・機能の抽出、検討・集約ができます。

図2:iQUAVISの正展開・逆展開機能

集約した要求・機能を基に、アーキテクチャ設計では対象システム全体の振る舞いや構造、状態遷移などを検討します。アーキテクチャ設計の結果は下流の構想設計領域だけでなく、OEMやサプライヤと共有されることもあります。

他社や他部門とのモデル共有も必要となるアーキテクチャ設計には、SysMLでモデルを構築できるCATIA Magicが適しています。SysMLではモデル表記のルールが厳密に決まっており国際標準の表記方法でもあるため、図3に示すように内部ブロック図やアクティビティ図といった様々なダイアグラムで対象の情報を表現できるだけでなく、他社や他部門との共有も行いやすく、検討の抜け漏れも発生しにくくなります。

図3:アーキテクチャ設計で使用されるSysMLモデル

次にアーキテクチャ設計を通じて部品構成や検証項目が決まった際には、各部品の設計・検証日程や担当者を決めて、各担当者へ展開します。図4に示すようにiQUAVISのリソース管理機能や日程表を活用することで、関係者への展開を簡単に行うことができます。

図4:SysMLモデルと日程管理の連携

このようにiQUAVISとCATIA Magicを連携して、場面に応じて使い分けることは難しそうに見えますが、iQUAVISのCSV Plug In機能を活用することで比較的簡単に実現できます(動画1、動画2を参照)。このCSV Plug In機能は開発中のプロトですが、お客様のご要望に応じたカスタム開発を御提案することも可能です。興味を持たれた方は、弊社担当までご連絡ください。

動画1:iQUAVISからCATIA Magicへの変換

動画2:CATIA MagicからiQUAVISへの変換

アーキテクチャ設計と1D CAEの連携

次に図1に③で示す、アーキテクチャ設計と構想設計の連携です。構想設計ではアーキテクチャ設計の結果をもとに1D CAEを使ってシステム全体の性能達成・未達の確認や、各部品の数値特性の評価などを行います。

アーキテクチャ設計で使用したCATIA Magicには様々なファイル形式へのExport機能が用意されており、制御設計の標準ツールSimulinkのファイル形式や、多くの1D CAEツールが準拠しているModelica言語形式にも対応しています。(CATIA MagicのファイルExport機能はOMGの仕様であるSysPhSに従っています。)

動画3:CATIA MagicからModelica形式へのExport

動画3ではCATIA Magicで作成した内部ブロック図をModelica言語形式にExportし、1D CAEツールで読み込む動きを紹介しています。アーキテクチャ設計では数式情報をモデルに含めていないためこの1D CAEモデルはそのままでは実行できませんが、各部品のインターフェースやパラメータの情報は含まれていますので、図5に示すように開発の後段で部品間や領域間の不整合に陥ることを防ぐことができます。(パラメトリック図に数式を記述することで、数式を1D CAEモデルに渡すこともできます。)

図5:アーキテクチャ設計によるメリット

またCATIA MagicはModelicaの標準ライブラリ(Modelica Standard Library:MSL)を読み込むこともできます。動画4で示すようにMSL内の要素を用いてブロック図を作成することで、そのままExportして1D CAEツールで解析を実行することもできます。

動画4:MSLを用いたCATIA MagicからModelica形式へのExport

1D CAEから3D CAEへ

最後に図1中の④で示す、1D CAEと3D CAEの連携です。1D CAEと3D CAEの連携は以前から取組が行われています。図6に示すように1D CAEでの評価結果をもとに3D CAEで諸元を設計する、3D CAEモデルをFMUや縮退モデルに変換して1D CAEに取り込むなど、相互に行き来しながら解析の精度向上、設計の詳細化を図っていきます。

図6:1D CAEと3D CAEの連携

情報確認のためのダッシュボード

さてここまで様々なツール連携について御紹介してきました。しかし実際にはこれらすべてのツールを一人の人が使いこなすことは難しく、またマネージャーは業務の進捗状況と課題の一覧、システムエンジニアは製品全体のアーキテクチャと製品全体の要件達成・未達を確認できる解析結果、といった具合に役割に応じて見たい情報は変わってきます。

情報確認のために各ツールを起動し目的のモデルやプロジェクトを探していると、それだけでも時間がかかってしまうため、図7に示すような各ツールから最新の情報を抽出して提供するダッシュボードが役割ごとに必要となります。

図7:各プロセスから情報を抽出するダッシュボード

このダッシュボードには要求機能やアーキテクチャの変更に容易に対応できる柔軟性が求められるため、Share PointやPower AppsといったPower Platformや、BIツール、Excelなどカスタマイズしやすいツールで作成するのが一般的です。

まとめ

MBSE領域のツールチェーンについて紹介しました。ここで紹介した要求・機能検討から1D CAE、3D CAE、ダッシュボード構築まで全ての領域で支援を提供できることが電通総研の強みでもあります。また今回の紹介には含めておりませんが、様々なデータ管理ツールとの連携についても別の機会に紹介したいと思います。


本記事は役に立ちましたか?コメント・問合せも承ります。

関連セミナー