HOME

特集

マルチドメインが踊りだす!
クラウド対応 FMI コシミュレーション

MDS推進センター 長澤 幹夫

現在、サイバネットシステムでは、複合領域モデルが協調するFMIコシミュレーション環境を開発中です。クラウド対応で、マルチプレイヤー、みんなで楽しめるCAE解析の新世界誕生にご期待ください。

はじめに:インターフェイスの共通化

システムを使う場合、ユーザは制御データを入力し、出力データを理解することで、システムを制御します。 例えば、自動車を運転する際、運転手はハンドルを操作して進行方向を制御し、アクセルとブレーキで速度を制御します。 運転手は窓を通して外界を見ることで自動車の位置を把握し、速度計で正確な速度を知ることができます。 機械や自動車などのユーザインターフェイスはヒューマンマシンインターフェイス(HMI)と呼ばれます。 コンピュータの場合には、グラフィカルユーザインターフェイス(GUI)と呼ばれるような、 カーナビやダッシュボードでの画面操作系も含めて、 HMIは、操作する人間と操作させる機械が接する境界面となります。 HMIで、自動車メーカー各社は、 スマートフォンとの連携を強化したり、車載専用OSを使ったりして、 操作性の向上を進めながら、HMIのデザインでブランド化や差別化を図ろうとしています。 自動車メーカーとしては、個人情報の管理や自動車の安全運行の観点から、 閉じたネットワークを優先させたいところですが、 スマートフォンに慣れたユーザは、クラウドを介して、 クルマのオープンな連携を求めるでしょう。 「ヒトもクルマもみんな友達」になる時代が来ているかも知れません。

システムは、複数の構成部品から成り立ちます。 仮想的なシステム評価実験、つまりシミュレーションもまた、多くの部品モデルから成り立つことになります。 システムを設計構築する際には、結合したシステム全体の機能評価や性能評価を行います。 ここにもまた、自動車メーカーと部品メーカーの協力関係に似た連携方式があります。 多種多様なモデルを組み合わせて、同時にシミュレーションする、いわゆるコシミュレーションです。 ひとつの大きなプログラムを、独占的に大規模シミュレーション実行するのでなく、 中小の部品プログラムが、同調しながら、協力しあって、全体システムの評価をするのです。

マルチドメインソリューションに立ちはだかる三つの壁

協調シミュレーション、コシミュレーションを用いて、複合領域の問題にチャレンジするには、 克服すべき課題、三つの壁があります。

  • まず、購買担当者の悩みとなる「ライセンスの壁」です。

    マルチプロダクトのライセンス調達のコストだけでなく、 多種多様なOS環境へのインストールの手間は、複合領域問題に取り組む意欲をそこないかねません。 解決策として考えられるものは、オンラインシミュレーションです。 クラウド環境に用意されたシミュレーションソフトを、そのまますぐ、従量制で使用できれば、 ユーザの負担は、大きく軽減されるでしょう。

  • 次に、開発担当者の悩みとなる「インターフェイスの壁」があります。

    インターフェイスの実装に際しては、 複合領域の異なる種類のプログラミング知識やコンパイラ知識が必要とされます。 さらに、N種類のツールやモデルをつなぐ組み合わせの数は、N(N-1)/2 です。 Nが小さいうちはよいですが、Nが大きくなると、多大な工数と、注意力が要求されることになります。 組み合わせの増大を抑制する解決策は、共通レイヤーを定義して、 各モデルがその共通レイヤーに対して、インターフェイスを実装することです。 この標準インターフェイスの発想のひとつが、 ファンクショナル モックアップ インターフェイス(FMI)と名付けられた標準仕様です。 FMIは、 サプライヤの壁、ツールの壁を取り払い、 CAEモデルを流通促進する仮想OEM実現のため、 欧州のMODELISARプロジェクトでオープンな標準仕様として規格化され、 2010年にバージョン1.0が公開されました。 2011年からは、Modelica協会が引き継いで仕様改訂しており、 最新版は2013年10月公開のバージョン2.0RC1です。 現在、シミュレーションツールベンダを巻き込んで、FMI支持や対応表明の輪が広がっています。 MapleSimなど市販シミュレーションツールの多くが、 FMIモデルを出力するエクスポート機能と、FMIモデルを読み込むインポート機能を提供し始めています。

  • そして、解析担当者の悩みとなる「バリデーションの壁」も忘れてはなりません。

    いくら、たくさんのモデルをつないでコシミュレーションできたとしても、 結果の解析、妥当性の検証ができなれば、すべては水泡に帰します。 解析、検証には、異分野専門家のコミュニケーション支援が有効です。 モデルとモデルが協調するコシミュレーションには、 ヒトとモデル、さらには、ヒトとヒトの協調が必要となります。
    そのための解決策としては、複数のユーザが同時にシミュレーションに参加できる、 オンラインゲームのような環境が役立つでしょう。 我々は、クラウドでも利用できる マルチプレイヤープロトコル(UPC)をコシミュレーション環境に持ち込むことにしました。

次のセクションからは、 上述の三つの壁に挑戦する、FMIコシミュレーション環境の全体的なアーキテクチャについて説明します。 クラウド対応FMIコシミュレーションに関するいくつかの疑問に答えながら、 コシミュレーション・クラウドのアーキテクチャについて コシミュレーション・クラウドがどのように実装されるのか説明し、 コシミュレーション・クラウドFMIモデルを実装する方法を示します。

ファンクショナル モックアップ インターフェイス

FMIコシミュレーションでは、FMIモデル間で物理量をやり取りするため、 例えば、モータとギヤのモデル間でトルクや回転数の情報を受け渡し、 両者を組み合わせたシステムを表現できます。 小さなモデル同士を組み合わせ、 大きなシステムのモデルを容易に構成できます。 部品メーカーが設計で用いたシミュレーション・モデルを、 製品メーカーが製品全体のシミュレーション・モデルに組み込むといった使い方が実現できます。

FMIが規定するのは、 ファンクショナル モックアップ ユニット(FMU)と呼ばれる パッケージファイルの形式、実行ライブラリ引数の記述方法、 共通する物理データ型や、関数名称規約などモデル間のインターフェイスです。 そして、FMUには、インターフェイスを記述するXMLファイル、 モデル時間積分を実行するバイナリライブラリ、 付属データ (アイコン、ドキュメント)などが、ZIP圧縮されて格納されます。

FMIを用いる場面は、

  • ツール間での「モデル交換」
  • 同時に計算を進めているモデル同士の「コシミュレーション」

の2つです。 また、モデル交換とコシミュレーションでは、FMI規定が区別されています。 モデル交換規定では、モデルとソルバの間のインターフェイスと、 同じソルバで計算される他のモデルとのインターフェイスを規定します。 全体システムモデルが動いているシミュレーション・ツールに、 追加あるいは、交換モデルを外部から読み込むことを想定しています。 コシミュレーション規定では、 モデルとソルバーの組みをセットとして捉え、 これらと、システム全体を制御するFMIマスターとの間のインターフェイスを規定します。 コシミュレーション規定では、独立して動作する複数のシミュレーション・モデルを想定しており、 FMI実行ライブラリは、時間積分計算をするソルバーを含みます。 FMIモデル同士は対等であり、シミュレーション全体を制御するFMIマスターの下で動作します。 自動車のシミュレーションであれば、ECU制御モデルと、 物理モデル(トランスミッション、エンジン、車体)が、 FMIにしたがって接続されます。

図1 ゲームレベルのコシミュレーション

ゲームレベルのシミュレーションと 物理モデルによるシミュレーションの距離は、年々近づいています。 クイックルックが可能な簡易モデルと位置づけて、 適材適所に、ゲームレベルのモデルを機構解析ツールの車体モデルに連携させる コシミュレーションも、真剣に考慮されるようになっています。 FMIモデルの仕様は、ゲームモデルでも、物理モデルでも、平等に適用可能です。

連成シミュレーションと協調コシミュレーションの違いは?

コシミュレーションとよく比較される 大規模並列連成シミュレーションのプログラミングスタイルがあります。 複合問題の変数を、ひとつの大きなマトリクスとしてモデル化した上で、 均一のプラットフォーム用にコンパイルするものです。 データやモデルは分割されますが、処理の内容は均一なものです。

一方、FMIコシミュレーションのスタイルは、 独立したモデルを、独立した実行ライブラリとして作成し、 リンク結合する方法です。 実行環境が32ビット環境と64ビット環境で異なるとすると、何が起こるでしょう? 簡単に読み込み結合することはできません。 すでに多くの解析モデルが、異なるプログラム言語形式で存在する状況に対して、 コシミュレーションを実行するには、 変数のインターフェイスを共通化してアクセスしなければなりません。 多様な実行環境での、多様なモデル連携は、 マルチドメインソリューションを実装するために必須の技術なのです。

モデルインターフェイスの解釈は?

FMIには、インターフェイス定義と、インターフェイスの実行ライブラリがあります。 インターフェイス定義は実行環境に独立であり、中立的な定義なので、 FMIマスターも、他のFMIモデルも共通に理解解釈できます。 一方、実行ライブラリは実行環境固有なものであってかまいません。 コシミュレーションマスターがFMIモデルを呼び出すとき、 XMLに格納されたFMI変数の定義属性は、 異機種上でコンパイルされたライブラリの引数と対応づけられます。 関数の入出力引数が、モデルの物理量とひもづけられます。 このFMIの基本的な構成が、クロス実行環境での連携動作を可能にしているのです。

FMIモデル実装例には、任意の実行環境のクライアントが含まれます。 クライアントは、ネットワーク経由で動作するFMIを通して、 サーバーに対してコールバックを行います。 コールバックを行えば、イベントに対する応答は自動的に処理されます。 FMIコシミュレーションでは、FMIモデルがどこに存在しているかは関係ありません。 FMIの仕様に則っていれば、それでいいのです。

モデルデータの共通化は?

オンライン通信によるシミュレーションデータの交換は、 XMLといったネットワーク透過なメッセージ形式の利用で解決されています。 FMI環境でコンパイルされるデータ型変換ライブラリを使えば、 モデルの物理量インターフェイスも、 FMI 変数を用いて連携させることができます。 オンラインゲーム環境 UPCはメッセージ通信が基本です。 ネットワーク透過な、XMLやJSON形式にデータを変換することで、 バイナリデータの違いを吸収処理します。

オンラインでのセキュリティは?

図2 コシミュレーションクラウドの構成 UPCプロトコルを用いたFMI Communication Layer 実装。

図2にコシミュレーションクラウドの構成を示します。 すべてのFMIモデルは、ローカルサーバーには自動的に公開されます。 FMIモデルをオンラインに公開するときには、 オンラインゲームサーバーがアクセス管理や参照解決を支援します。

Application Serverは複数のプロトコルを使用することができます。 よく使われるのは、TCP/IPソケット通信です。 同じコンパイラ、同じ通信ライブラリにより生成されたモデル間通信は、 問題が少ないですが、専用の通信ポートを開放するリスクが生じます。 一方、クラウドでは http 利用が前提となります。 問題は、クラウド マシンが Application Serverと通信するときに起こります。 複数のプロトコルが使用されているときには、クラウド の FMI コールバックができるようにしなければなりません。 Application Server実行環境から Application Server以外の実行環境に対して 関数コールバックが行われるときには、 セキュリティの処理は複雑になります。 FMIコシミュレーションでは、FMIモデルのセキュリティや課金管理の方法は、 統一的な規定はまだありません。 現段階では、FMIモデルをパブリックに公開するような使い方はせず、 Application Server の背後に隠すようなアーキテクチャを採用すべきと 考えられています。

我々は、FMIモデル関数リンクをApplication Sserverの ソケット通信に変更する実装評価をしました。 Modelica言語のMapleSimの外部関数DLL呼び出しと、 ANSYSのバイナリデータ入出力用FortranDLLをC言語でラッピングして連携させる プログラム試験です。 ANSYS/MaxwellのプラントモデルをMapleSimやSimulinkでの制御モデルと連携させる実験試作もしました。 FMIの知識だけでなく、個別のソルバーと各言語コンパイラ知識が必要不可欠であることを 実感しています(図3,図4)。

Flash APIとは、ダイナミックなWebページ表示言語です。 FMIマスターからは、FMIを使ってモデルを呼び出すことができます。 モデル間は オンラインゲームサーバーのコンテキストの中で動作するので、 FMIモデル解析モデルが実行するアクションは、 すべて FMIマスターからの制御として通信されます。

図3 オンライン同期通信デモ(MapleSim制御) タイムステップ同期と時間積分法の検証。
通信遅延の確認と、コシミュレーション遅延補償アルゴリズムの検証ができます。

図4 オンライン同期通信デモ(Simulink制御) コシミュレーション一時停止中の三次元マウス操作を含むデモ画面。

コシミュレーション・クラウドの構成

コシミュレーションクラウドの動作原理を示す基本的なアーキテクチャについて説明します。 FMIマスターは、複数のFMIモデル間での、タイムステップ同期と最小限のデータ交換により、 個別のFMIモデルの言語独立性を保全したまま、 全体システムのコシミュレーション(時間発展)させます。 このFMIコシミュレーション環境の実装方法として、以下の三つの方式設計ができます

実行方式 ソフトウェア種類 利用環境
(1)  マルチスレッドのシングルプロセスとして実行 コネクタ スタンドアロン型
(2)  ソケット通信を介したマルチプロセスとして並列実行 プロキシ クライアントサーバー型
(3)  インターネットを介したマルチユーザ分散実行 オンライン クラウド型

図2の 多層通信構造は、FMI通信の実行ライブラリの仕組みを示しています。 三つの実装方式も包含されています。 クラウドをソケット通信に見せかけるローカルな使用法と、 クラウドにマルチユーザFMIの機能を与える実装が可能です。 FMI規定では、自由な実装が許されている Communication Layer は、 FMI Wrapper でもある Application Server を使用して、FMIモデルを実行することができます。 クラウドサーバーには、最小限の機能を実装し、 シミュレーションのロジックは、FMIモデル側に実装する方法が、 拡張性が高くなります。 ローカルな実行環境性をクラウドに再現するのではなく、 コシミュレーションクラウドに参加する全参加者のFMIモデル資源を 活用することを目標とします。

オンラインゲームサーバーは、 Session ClientとなるFMIマスターも、 Session ServerとなるFMIモデルも、 平等なゲームルーム参加者として扱います。 シミュレーションの時間同期判定も、 必要な物理変数の交換も、ゲーム参加者の自発的なメッセージ交換のかたちで、 処理されます。 オンラインゲームサーバーは 参加モデルに、ドメイン認証を行い、参加を許可していいかどうかを確認します。 通信は暗号化され、他のゲームルーム参加者、つまり別のコシミュレーションクラウドとは 隔離されます。 FMIでの当面の弱点である、セキュリティやアクセス管理は、 このUPCによって担保されることになります。 そのため、オンラインゲームサーバーは、 FMIマスターやFMIモデルが呼ばれる前にサービス起動しておく必要があります。

オンラインゲームサーバーのもう1つの機能は、 pingサービスの提供です。 たとえば、次のようなシナリオを考えてみましょう。 異なる実行環境にいるFMIモデルが、 コシミュレーションの途中で、何かの原因で、消滅したとします。 FMIマスターや他のFMIモデルは、消滅FMIモデルに気づかず、 コールバックを待ち続けることになります。 pingサービスにより、ルームに参加しているFMIモデルの安否確認ができるのです。 ただし、FMIモデルが消滅した時に、どのような対応をするかは、 オンラインゲームサーバーではなく、FMIマスターのロジックにより実装されます。 コシミュレーションを中止するのか、最初からやり直すのか、消滅したFMIモデルを無視するのか、 再度、呼び出すのか、さまざまなオプションがありえます。 pingサービスにより、計算が収束しなくなって、コールバックが遅くなっているのか、 なんらかの理由で、ルームを退室したのかを区別できることは、 FMIとUPCを組み合わせて参照することで、はじめて確認できます。

コシミュレーション・クラウドのプログラミング

図5 コシミュレーションマルチ時間積分法
機構シミュレーションは1次精度Euler法、 弾性体振動は、4次Runge-Kutta法による時間積分で、固定点速度を共有した例。

次のステップでは、実際にコシミュレーションアプリを作成します。 アプリの作成は、それほど難しくなく、 問題はどのような手順を踏むかということです。 コシミュレーション・クラウド の FMI仕様の定義には、FMI規定に従うヘッダー定義が含まれています。 FMI1.0とFMI2.0では、ヘッダーが異なりますので、注意が必要です。

実行環境では、機種OS依存する実行ライブラリが、かなり異なることに気づきます。 真のクロス実行環境機能を実現することは不可能であり、 場合わけして、コンパイルされたライブラリを用意することになります。 FMIモデル選択の際に、モデルのソースプログラムを見る必要はありません。 FMIの付属XMLメタデータに必要な情報が記載されているからです。 図5に、コシミュレーションアプリを実行した様子を示します。

ステップ 1: どのような種類の連携を実現するのか?

FMIマスターとFMIモデル同期プロトコルは、 オーケストラの指揮者と、演奏家の関係に相当します。 指揮者が指揮棒を上げ、演奏家が構えたところで、 初期条件のセットアップが完了。 指揮者が指揮棒を動かすと、曲全体が開始します。 演奏家は、各小節ごとに指揮棒を確認し、曲のテンポに追随します。 指揮者は、曲の進みを耳で確認しながら、終了に入るのか、 次の小節に進むかの判断をします。 指揮者も演奏家も、そして、演奏家同士も、必要な音とテンポを 共有し、細かく判断しながら、協調していくのです。 楽器の演奏方法は、演奏家に任されています。 ソルバーは自由であり、奏でる音、交換される物理量のみが、 共有されるのです。

まず、どのような種類の連携シミュレーションが必要なのかを考えることが重要です。 連携シミュレーションには次の 3 つのタイプがあります。

  • 同期。モデルが呼び出されるとき、情報を要求したクライアントは、答えが返されるまで待機します。
  • 非同期。 モデルが呼び出されるとき、クライアントは要求をサブミットした後に、以前のタスクに戻ります。 求めている応答の種類に応じて、クライアントは答えをポーリングするか、何らかの非同期的なコールバックを起動します。
  • 一括データ転送。 クライアントが情報を要求するとき、情報の要求は一括フォーマットで行われます。 クライアントには一括データが返され、クライアントからの要求は、変数メモリではなく一括データに対して行われます。

時間発展を追う、コシミュレーション開発では、 オンラインを使用するので、選択肢としては 同期方式と一括データ転送方式の2つあります。 どちらが適しているかを決めることになります。 一般に、データが頻繁に変更される場合、 アプリの拡張性が求められる場合、 また、コストが重要であるときに、同期方式が採用されます。 FMIコシミュレーション規約も、同期方式を規定しています。 コシミュレーションクラウドでは、 クラウド上にFMIマスターの同期ロジックが存在しており、 FMIモデルは、FMIインターフェイスを通じて使用します。 FMIコシミュレーションは、データそのものが、クラウド上に置かれている場合にも対応できます。

ステップ 2: FMIインターフェイスの決定

インターフェイスの定義は、システム設計のうちでも最も複雑なものです。 しかし、インターフェイスの設計に十分な時間が当てられないことも多く、 迅速な開発と、永く使用できるインターフェイス設計のトレードオフが行われます。 長期的なサポートが期待されるFMIインターフェース標準化は、 個々の開発者のプログラム設計効率化にも寄与しているのです。

  • モデル・リダクション

    FMIは、モデル・リダクションを行う上でも優れた表現です。 モデル・リダクションの発想で、インターフェイスと実行ライブラリを別々に定義します。 モデルを使用するときには、実行ライブラリではなくインターフェイスを見ます。 モデル・リダクションの利点は、実行ライブラリの種類を動的に決定・変更できるという点にあります。 FMIに従うインターフェイスである限り、 たとえば、現在はローカルマシン上で実行されているライブラリを、 別のコンパクトな実行ライブラリに置き換えて、クラウド上に置くことも可能です。

  • ソルバー独立モデル

    FMIコシミュレーションモデルは、ソルバーを含みます。 ソルバー単位の修正を加えて、一方のFMIモデルを再コンパイルしても、 協調する他のFMIモデルを再コンパイルする必要はありません。

  • モデル ラッパ

    FMIモデルラッパはレガシーアプリが関与する状況で有効です。 モデルラッパの目的は、レガシーアプリやロジックを、ひとつのFMIモデルとして、 FMIコシミュレーションに組み込む層を作成することです。 インターフェイスは、モデルラッパの概念に基づいて設計されることになります。 例えば、データモデルにアクセスする階層として、 既存のデータアクセス階層が古くなってしまったアプリでは、 データインターフェイスとして、 XML/JSON用のデータ階層の組み込む設計方法は周知であり、 必要な関数を追加実装することになるでしょう。 モデルとデータを分離することで、FMIモデルラッパとしての インターフェイスを守ったままの変更も可能になるわけです。

次のステップでは 通信基盤をインターネット対応させます。 クラウド環境として、UnionPlatform が提供するオンラインゲームサーバーを利用します。 UPCプロトコルをサポートし、 同時 1000ユーザまでフリーで利用できるサーバーソフトです。 ただし、提供されているプログラムインターフェイス(API)は、Java, Flash, HTML5に限定されるため、 FMIモデルとの通信は、C言語で新たに作成する必要があります。 以下に、UPCプロトコルの一部の定義を示します。 オンラインゲームのチャットルームを管理することを想像していただければ、 どのようなプロトコルが用意されているか、容易に察しがつくと思います。

UPC protocol functions
SEND_MESSAGE_TO_ROOMS
SEND_MESSAGE_TO_CLIENTS
SEND_MESSAGE_TO_SERVER
SET_CLIENT_ATTR
JOIN_ROOM
SET_ROOM_ATTR
CREATE_ACCOUNT
LOGIN
SYNC_TIME
... 150 more

新たに作成したFMI関数コールUPCプロトコルの変換ライブラリは、 解析モデルの状態変数に、クラウドからアクセスするインターフェイスです。 コシミュレーションクラウドでは、 オンラインゲームサーバーが提供している機能を利用できるように、 メッセージベースのインターフェイスを FMI関数コールにラッピングします。 FMIモデルは、オンラインメッセージのコレクションを処理しますが、 あくまで、FMIモデルは、FMI関数コールインターフェイスを使用しているので、 UPCプロトコルの詳細や変更には依存していません。 つまり、制御と通信を分離することに成功しています。 また、オンラインゲームサーバーから見ると、 人工知能のチューリングテストのように、 ゲームに参加してメッセージ交換している実体が、 ヒトなのかモデルなのかの区別は付かないことになります。

ステップ 3: FMIマスターの実装

FMI関数コールUPCプロトコルの変換ライブラリは、 開発ドメインの違いをネットワーク通信で吸収する重要なライブラリです。 前のステップでは、時間積分を計算するFMIモデルのラッパとしての役割を持たせましたが、 同様に、FMIマスターのラッパとしても機能します。

時間同期を制御するFMIマスターのロジックは、 C言語でも、Pythonスクリプトでも記述できます。 FMIマスター用としては、 コンパイルの手間がない、Pythonスクリプトが広く採用されています。 スレッド管理と FMI外部関数インターフェイスを定義するラッパー、 または、FMI結合からソケット通信、HTTP通信するUPCプロトコルの実装は、 汎用的なPythonライブラリと組み合わせることで、 比較的容易に実装することができます。

コシミュレーション・クラウドでのデバッグ診断

Alternative content

Get Adobe Flash player

図6  コシミュレーション同期制御デモ画面。
マウス操作により、玉入れシミュレーションを修正したり、右上の緑ボタンで、同期をとったりできます。 機構弾性体コシミュレーションでは、物体をマウスで移動され、トルクの変化を観察できます。

FMIモデル互換性の検証には、 まだ、FMI 1.0ですが、モデル検証ツールとして、 Jmodelicaコミュニティ提供のオープンソフトであるPyFMIが活用できます。 しかし、 FMI標準に準拠したモデルを用意できたといっても、 多くのコンパイラは、異なる実行環境の複雑さに対応できていません。 FMI開発の方法論に合わせてカスタマイズしなければならないでしょう。 FMUに格納されるFMI実行ライブラリは、 実行環境ごとに適したコンパイラで用意されることを前提としています。 特定の実行環境に依存する特殊な処理手順を使用しているFMIモデル間の連携は、 問題を起こすことがあります。 実行環境での対話的なデバッグは必須といえます。

我々は、 オンラインFMIコシミュレーション環境を開発しています。 FMI通信レイヤーとオンラインゲームプロトコルの変換ライブラリを用意する必要がありますが、 クラウド環境は非常に有用です。 セキュリティを気にしないFMIのみの試験実装であれば、用意する変換ライブラリも、 UPCのフルセット150種類ではなく、 20種類程度で済みます。 Multi-Method-In-the-Loop の発想で、モデルとソルバーを切り替えたり、計算環境や実測環境ハードを動的に切り替えることが可能になります。 対話的な可視化制御をしながら、解析評価のアセスメントが進みます。

ただし、クラウドを使用するときには、いくつかの注意点があります。 多くのFMI実行ライブラリの中で、 クラウドに移植できるプログラムは一部に過ぎません。 大部分の開発をクラウド上で行なう開発手法も存在しますが、 多様な実行環境に分散しなければならないアプリや 既存のモデルをFMIモデル化したい場合には、 パソコンで開発されたアプリをラッピングして、 クラウド環境に接続する方法が適しています。 開発環境も、使い慣れたツールのほうが快適でしょう。 ただし、簡単にコンパイルが行える市販ツールでも、 エクスポートしたFMIモデルが、どのような実行環境に置かれることを 常に意識して、デバッグ解析するようにしてください。

まとめ:永続的なコシミュレーション環境に向けて

レガシーアプリのためのFMI コシミュレーション連携

既存のレガシーアプリをFMI準拠される方法として、 ソルバーが分解できないプログラムは、ひとつのFMIモデルとする方法があります。 既存コシミュレーション実装例でも、 複数のモデルを連携動作させるには、各モデルの時間軸を揃える同期機構が必要となります。 クロックサーバーから送出されるクロックにて、各モデルは同期動作させます。 基本的に、マルチスレッドの処理を制御する必要があり、 クロックイベントを共有して、同期待ちのためのコールバック関数を定義して対応します。 状態変数を定義して、独自のイベントリスナーを設けた非同期モードも選択できます。

オンラインマルチユーザFMI化による付加価値

コシミュレーションクラウドが普及すると、マルチドメインのCAEにとって、多くのメリットがあります。

  • 標準化:モデル流通促進とメタ情報管理
  • 省力化:専門家による分担保守
  • 低コスト化: 対応ツール選択肢の増加
  • 長寿命化:システムとモデルの拡張性
  • 広域化:インターネット、クラウド対応
  • 安全強化:セキュリティ、ユーザ認証
  • 可視化: リアルタイム解析、インターフェイスモニタリング
  • 多目的化: コラボレーション、ゲーム、CG、教育、モバイル利用

連携解析、協調コシミュレーションは、一定の範囲内で行っているうちは単純です。 しかし、モデルの数が増えたり、ドメイン境界を越えたとたんに、物事は複雑になり、 問題が発生する可能性があります。 しかし、FMI構築支援サービスが普及し、多くの専門家が同時にアクセスできる環境が整備されていくにつれ、 専門家と解析モデルが協調するコシミュレーションは、より簡単に実現できるようになるでしょう。 我々も、マルチドメインソリューションを推進するキー技術として、今後も技術開発を続けていきます。

期待されるFMI支援サービス

コシミュレーションには、FMI標準に則った環境構築が普及していくと考えられます。 FMIは、以下に示すように、 モデル作成、可視化と制御を独立させて、シミュレーションの効率的な修正変更ができる開発パラダイムです。 ヒトとヒトとの協調が、今後さらに有益になると期待されます。

  • モデル作成: 物理エンジンのDLL化、FMIモデル生成は、市販ツールベンダが対応していくでしょう。 しかし、ユーザプログラムのFMIモデル化には、レガシーアプリの分類や、同期スレッドの実装など、 複合領域の専門知識を必要とする作業も入ります。
  • 可視化: シミュレーションツールに依存したグラフ表示でなく、 マルチドメインのコシミュレーションにふさわしい、汎用的な可視化サービスが、解析、デバッグともに 役立つでしょう。我々が採用したWeb ブラウザでのFlashによる可視化は、汎用性と拡張性、 さらにゲームクリエータとCAEエンジニアの協調も促進できると考えています。
  • 制御:XML定義される物理変数や状態変数の設定や、時間同期アルゴリズムの実装などは、 コシミュレーション特有のツールや技術が役立つ分野です。 コシミュレーションの研究や適用例が増えていくことで、知識共有が進む分野と期待されています。

関連情報

1/1

(5/6)