1. はじめに
この記事の目的
本記事では、モデルベース開発やシミュレーションの世界で広く利用されているFMI(Functional Mock-up Interface)のバージョン2.0と3.0の違いを中心に解説します。FMIは異なるツール間でモデルを交換したり、コシミュレーションを実行するためのオープンな標準インターフェースです。
特に、2022年にリリースされたFMI 3.0でどのような機能拡張や仕様変更が行われたのか、実際のユースケースや注意点を踏まえながらまとめます。
なぜFMI 3.0が重要か
- モデル交換やコシミュレーションの分野で「事実上の標準」として定着しており、今後の大規模シミュレーションやモデルベース開発(MBD)を推進する上でも中心的存在
- ツールチェーンの拡大や多様化(クラウドシミュレーション、リアルタイム環境、組み込み向け検証など)に伴い、新たな要求を満たすために拡張された仕様が多い
- 産業界(特に自動車や航空宇宙)だけでなく、アカデミックや研究機関でも、モデル連携のデファクトスタンダードとして利用が進んでいる
ターゲット読者と想定する前提知識
- モデルベース開発(MBD)やシミュレーションツールに興味がある方
- MATLAB/SimulinkやDymola、Modelica、あるいはPythonベースのシミュレーションツールを使った経験がある方
- シミュレーションにおけるイベント処理、離散ステップ、ソルバなどの基本概念を知っている方
本記事がFMIの入り口やバージョンアップ時の参考になれば幸いです。
2. FMIの概要
FMI(Functional Mock-up Interface)とは
FMIは、モデル交換 (Model Exchange) およびコシミュレーション (Co-Simulation) を可能にするための標準インターフェース仕様です。異なる開発ツール・プラットフォームで作成されたモデルを「FMU(Functional Mock-up Unit)」という形式にまとめることで、ツールの垣根を越えてシミュレーションを連携できます。
-
Model Exchange (ME):
ツール(ホストシミュレータ)がソルバーを持ち、FMUはモデル本体・方程式群を提供するだけの形態。- ホスト側がシミュレーションステップを進める。
- FMU内部にソルバーは含まれず、数値積分や離散ステップなどはホスト任せ。
-
Co-Simulation (CS):
FMUがソルバーを内蔵し、FMU自身が独立した形でステップを進める形態。- ホストシミュレータは「FMUを一歩進める」と呼ぶだけで、内部はFMUが管理。
- 異なるソルバーを複数FMU間で使いつつ、上位レベルで時間同期を行う。
バージョンごとの変遷
- FMI 1.0 (2010年頃): Model Exchangeを中心に登場。Co-Simulationは別仕様。
- FMI 2.0 (2014年): Model ExchangeとCo-Simulationを一本化し、状態遷移やAPIを整理。多くのツールが対応し、実利用が広く普及。
- FMI 3.0 (2022年): 新モードの追加(Scheduled Execution)、多インスタンス機能強化、APIやXMLの拡張などにより、一段と多様なユースケースに対応。
FMIはツールやプラットフォームの垣根を越えた相互運用性を実現する大きなメリットを持ち、今日では非常に重要な標準仕様の一つとなっています。
3. FMI 2.0のおさらい
2.0の特徴
-
Model ExchangeとCo-Simulationの統一
FMI 1.0ではMEとCSの仕様が分かれていたが、2.0では同じパッケージ(FMU)内で両方の機能をサポートできるようになり、産業での運用が加速。 -
APIや状態管理の刷新
例えばfmi2Instantiate
,fmi2SetupExperiment
,fmi2EnterInitializationMode
など、一連の呼び出し手順が定義され、ホストツールがモデルを扱いやすくなった。 -
明確な状態遷移図
「初期化 → ステップ実行 → 終了」の流れをシンプルに捉えられるため、多種多様なツール間での互換性が取りやすい。
2.0の制限や課題点
-
複数インスタンスの活用が制限的
同一FMUを複数箇所でインスタンス化する際、変数の取り扱いやイベントが煩雑になりやすい。 -
イベント処理が限定的
タイムイベント・状態イベントなど、より高度なイベント処理を行う場合には工夫が必要。 -
ファイル構造の拡張性
XMLスキーマやリソースファイルに関する仕様が単純な一方、大規模システムや特殊な用途にはやや柔軟性に欠ける。
とはいえ、FMI 2.0は現在(2025年時点)でも多くのツールで標準的にサポートされており、実績が最も豊富なバージョンです。
4. FMI 3.0の概要
3.0で追加された新機能とゴール
FMI 3.0では「より複雑なシステムを、より柔軟に扱う」ことが大きな狙いとされ、以下の点が強化されています。
-
Scheduled Executionモードの追加
後述しますが、周期的・イベント駆動的に動作するシステムを効率よく扱うための仕組み。 -
API・XMLスキーマの拡張
変数定義や依存関係、イベントフローがより細かく記述可能。 -
多インスタンス機能の強化
一つのFMUを並行して複数用いる大規模シミュレーションへの対応が進化。 -
セキュリティ・ライセンス面の再整理
ソースコードFMUやバイナリ配布に関する標準的なガイドラインが拡充。
仕様の大きな変更点
- 追加された関数群や拡張された状態遷移図によって、コシミュレーションやイベント駆動型システムを包括的にサポート。
- 変数やパラメータに対するより厳格な定義(データ型、物理単位、依存関係など)が可能に。
- 大規模並列実行(マルチコア・GPU環境)やリアルタイムシミュレーションとの親和性を意識した設計。
5. FMI 2.0からFMI 3.0への主な変更点
5.1 モデル交換 (Model Exchange) 周りの変更
-
APIの細分化と追加
3.0では、モデル初期化やステップ実行時により細やかな呼び出しが可能になっています。大規模モデルを部分的にステップ実行したり、ホストシミュレータの都合に合わせたパラメータ更新を行ったりする際の自由度が増しました。 -
入出力変数の依存関係がより明確に
XMLスキーマの拡張により、「ある出力がどの入力に依存するか」や「イベントがどの変数に影響を与えるか」が表現しやすくなり、モデル統合のミスを減らすことが期待されます。
5.2 コシミュレーション (Co-Simulation) 周りの変更
-
イベント処理が柔軟に
時刻イベント・状態イベントをより細やかに定義できるAPIが用意され、異なるソルバーを組み合わせているFMU同士でも、イベントの同期が取りやすくなりました。 -
タイミング制御の改善
FMI 2.0ではコシミュレーション時の時間管理が単純だった反面、高度なリアルタイム要件には対応しづらいケースもありました。3.0では時間刻みやイベントトリガをさらに詳細に制御でき、並列シミュレーションやリアルタイムシステムとの親和性が高まっています。
5.3 Scheduled Execution(新モード)について
FMI 3.0の中でも特に注目を集める機能が Scheduled Executionモード です。これは周期タスクやイベント駆動的な制御アルゴリズムを扱う際に強みを発揮します。
-
どんなユースケース?
- 制御系モデル(制御周期ごとに演算を行うPID制御、状態フィードバック制御など)
- 組み込みシステムやAUTOSARベースのソフトウェアなど、タスクスケジューリングが鍵となるアプリケーション
- イベント駆動アーキテクチャ(状態遷移や入力イベントによって動作タイミングが変わるシステム)
-
メリット
- イベント駆動システムの実行タイミングを、FMU内部と外部(ホストや他FMU)で一貫して管理できる
- 「複数周期」「異なる優先度・周期のタスク」が混在するようなシステムも、正確にスケジューリング可能
- 従来のModel ExchangeやCo-Simulationでは扱いにくかった離散イベント駆動ロジックを、より自然に実装できる
Scheduled Executionを活用することで、リアルタイムOSや組み込みターゲットなど、ハードウェアやソフトウェアのスケジュールを強く意識する開発にもフィットするようになりました。
5.4 構造・命名規則・ファイル形式の更新
-
XMLスキーマの拡張
modelDescription.xml
がよりリッチな情報を含むようになり、モデル内部構造の定義に自由度が増えました。たとえば物理単位の定義の細分化や、変数同士の依存関係を詳細に書けるなど。 -
命名規則やフォルダ構造の明確化
リソースファイルの取り扱い、ライブラリ参照方法(DLL / so / dylibなど)が整理され、大規模FMUや複数プラットフォーム対応FMUの開発・配布をしやすくする設計になっています。
5.5 バイナリ配布とソースコードFMU
-
バイナリ配布の強化
OS依存部やアーキテクチャ依存部(x86, ARMなど)をFMU内部でしっかり分けて管理し、複数プラットフォーム用バイナリを一括収録するケースにも柔軟に対応。 -
ソースコードFMUの取り扱い
FMUにソースコード(C/C++など)を同梱して配布する場合、セキュリティ・ライセンス・ビルド環境などの考慮点をFMI仕様書に明確化。産業機密を含むモデルの場合は注意が必要ですが、研究やOSSコミュニティではより積極的にソース付きFMUのやり取りが行われています。
6. FMI 3.0対応のツールとエコシステム
FMI 3.0は2022年の正式リリース以降、徐々に各種ツールチェーンで対応が進んでいます。2025年現在、以下のような対応状況がみられます。
- Dymola: Modelicaベースのモデリングツール。FMI対応の歴史が長く、3.0の機能を順次拡充中。
-
MATLAB/Simulink:
- MathWorks公式サポートの拡大が期待されており、一部のバージョンではβ的にFMI 3.0を取り扱う例も報告されています。
- サードパーティ製のFMI Toolboxも存在。
- OpenModelica: オープンソースのModelica実装。最新FMIバージョンを積極的に取り込んでおり、コミュニティの更新が活発。
- その他: JModelica.org、FMPy(Python)、FMUSDKなど。ツール間での互換性検証も進んでおり、FMI Communityで公開テストが行われています。
現状では、まだ2.0中心のツールが多いものの、3.0対応をアナウンスしているベンダーも増えており、今後さらに移行が進むと見込まれます。
7. 実践例・サンプルコード
ここではFMI 3.0でのFMU生成および利用の流れをイメージしやすいよう、Pythonツールでの例を簡単に紹介します。実際の手順はツールや言語により異なるため、あくまで参考としてください。
# Pythonスクリプト例: FMPyを利用したFMUのシミュレーション
from fmpy import simulate_fmu
import matplotlib.pyplot as plt
# 1. FMUをロードしてシミュレーション
result = simulate_fmu(
filename='MyModel.fmu',
start_time=0.0,
stop_time=2.0,
step_size=0.01
)
# 2. 結果の可視化
time = result['time']
output = result['y'] # 出力変数名が"y"の場合
plt.plot(time, output, label="y")
plt.xlabel("time [s]")
plt.ylabel("output")
plt.legend()
plt.show()
Scheduled Executionモードの例 (概念イメージ)
Scheduled ExecutionをサポートするFMUは、**「いつ、どのタスクを実行するのか」**という情報を持ちます。ホスト側(自作スクリプトや外部ツール)は、FMI 3.0 APIを通じてタスクの呼び出し順やイベントのトリガを問い合わせながら進めていきます。
/* 擬似コード: FMI 3.0 C APIの一部を用いたScheduled Execution */
fmi3EnterInitializationMode(fmuInstance);
/* ... 初期化処理 ... */
fmi3ExitInitializationMode(fmuInstance);
while (!simulationEnd) {
/* 次のタスク実行タイミングや優先度をFMUから問い合わせる */
fmi3GetNextTaskInfo(fmuInstance, &taskTime, &taskPriority, &taskID);
/* ホスト側の時間をtaskTimeまで進める、もしくは待機する */
hostAdvanceTimeTo(taskTime);
/* FMUの指定タスクを実行 */
fmi3ExecuteTask(fmuInstance, taskID);
/* イベント発生有無をチェック */
if (eventOccurred) {
fmi3HandleEvent(fmuInstance);
}
/* 終了条件を判定 */
simulationEnd = checkEndCondition();
}
上記はあくまで概念的な例ですが、FMI 2.0以前には無かった細やかなスケジューリングとイベント駆動を扱える点が、FMI 3.0の注目ポイントです。
8. 移行時のポイントと考慮事項
FMI 2.0から3.0へ移行する際に押さえておきたいポイントをまとめます。
-
既存FMUの再利用
- 多くのツールは2.0のFMUを依然として読み込み可能です。3.0の新機能を活かすには、モデルやツール側の対応が必要になるため、再エクスポートを検討。
-
APIの変更点への追従
- 2.0のAPIを直接呼び出していた自作ツールなどは、3.0で追加された関数や変更された引数に対応する必要があります。
-
modelDescription.xmlの修正
- XMLスキーマが拡張されたため、独自に生成・編集していた場合は書式変更やタグ追加に注意。
-
イベント・スケジューリングの差異
- イベント処理の強化に伴い、2.0で実装していたイベントハンドリングロジックが3.0で変更を必要とするケースがあります。
-
ツールチェーンアップデート
- 3.0対応をうたうツールでも、実装状況(Model Exchange対応のみ、Co-Simulation未対応など)が異なる可能性あり。自社環境のバージョンを事前にチェック。
-
ライセンス・セキュリティ面
- ソースコードFMUを扱う場合、産業機密のリーク防止やエクスポート禁止条項等、企業内ルールとFMI仕様を十分に確認する。
9. 今後の展望
FMI 3.0の拡張可能性
- さらなる並列実行最適化: マルチコアや分散環境(HPC、クラウド)でFMUを大規模に動かすニーズが高まり、FMIを活用した並列シミュレーションがさらに拡充される可能性。
- イベント駆動モデルの高度化: IoTやCyber-Physical Systems(CPS)のシミュレーションが進むにつれ、FMI上でより複雑なイベント処理を実装する要望が高まる。
- セキュリティとライセンス: 企業の機密が含まれるFMUを外部委託先やサプライチェーンとやり取りする機会が増え、暗号化やアクセス制御などFMIレベルでの仕組み強化が期待される。
モデルベース開発やシミュレーション領域全体におけるFMIの位置付け
- 産業界での普及度: 自動車業界(AUTOSARとの連携)や重工業、プラント制御、ロボティクスなど多岐にわたる。
- 学術研究やオープンソースコミュニティ: オープンソースツールとの相性が良く、学生・研究者レベルでの採用例も増えている。
- 標準化のさらなる進展: Modelica Associationによるサポートや、他の標準規格(SSP、DCPなど)との連携強化も議論されており、エコシステム全体が広がりつつある。
10. まとめ
本記事では、FMI 2.0とFMI 3.0の違いを中心に、FMIの概要や新機能、移行のポイントなどを解説しました。主な要点は以下の通りです。
-
FMI 3.0の大きな進化点
- Scheduled Executionモード の追加により、周期タスクやイベント駆動型システムをより自然に扱える
- API・XMLの拡張 で大規模化や多プラットフォーム対応がしやすくなった
- 多インスタンス機能強化 などにより、複雑なシステムを統合するハードルが低下
-
移行時のチェックポイント
- 使用中のツールチェーンが3.0にどの程度対応しているか
- 既存のFMUや独自ツール、スクリプトの差分吸収(API、XMLタグなど)
- イベント処理やスケジューリングロジックが変更になる場合のテスト
-
今後への期待
- MBD(モデルベース開発)のさらなる加速と、大規模シミュレーションやリアルタイムシステムへの適用拡大
- エコシステムの活性化と、国際標準としての定着・発展
もしFMI 3.0を使ってみて感じたことや、移行で苦労した点などがありましたら、ぜひコメント欄やQiita記事のフィードバックで共有いただければ幸いです。この記事が、FMIを活用したシミュレーションの一助となれば嬉しく思います。
参考リンク・資料
- FMI公式サイト (fmi-standard.org)
- FMI 3.0仕様書 (PDF)
- Modelica Association
- PyFMI / FMPy (Pythonツール)
- OpenModelica
- JModelica.org
以上