日経テクノロジーオンライン

<キーワード解説>ModelicaとFMI─構想設計段階で役立つCAE規格

2013/11/11 00:00
木崎 健太郎=日経ものづくり

 「Modelica」は、電気、ソフトといった要素を含む機械システムなどのシミュレーション・モデルを記述するのに用いる言語。機械製品の設計においてCADデータを作成する前の構想設計段階で、システム全体の挙動の把握に用いる「1Dシミュレーション」などで多く使われている。(図1。欧州の非営利団体Modelica協会が仕様を決めており、最新バージョンは2012年5月公開のバージョン3.3である。

図1●Modelicaで記述したシミュレーション・モデル
システムの挙動を方程式で記述する。単純な部分システムのモデル同士を組み合わせることで、複雑なシステムを表現できる。
[画像のクリックで拡大表示]
* Modelica対応のツールやライブラリは、「CyModelica」「Vertex」「Converge」(米CyDesign Labs社)、「Dymola」(仏Dassault Systemes社)、「MOSILAB」(独Fraunhofer FOKUS社)、「SimulationX」(独ITI社)、「LMS Imagine.Lab AMESim」(ベルギーLMS International社)、「MapleSim」(カナダMaplesoft社)、「OPTIMICA Studio」(スウェーデンModelon社)、「MWorks」(中国Suzhou Tongyuan社)、「Wolfram SystemModeler」(米Wolfram Research社)の他、フリーまたはオープンソースの「JModelica.org」「Modelicac」「OpenModelica」など(2013年10月現在、Modelica協会のWebページによる)。

方程式で物理現象を記述しシミュレーションする

 Modelicaでは通常のプログラミング言語と違い、物理現象を表す「オームの法則」「運動方程式」「運動量保存」といった方程式でシミュレーション・モデルを記述することを目指した。Modelicaを考案したHilding Elmqvist氏によれば、「1970 年代前半にボイラーとタービンのシミュレーションを試みた際に、当時あったプログラミング言語だけでは十分なモデルを記述できなかった。そこでプログラミング言語ではなく、方程式(連立方程式)でモデルを記述したいと考えた」という。

 プログラミング言語はコンピュータの動作を指示するものであり、物理現象そのものを記述するには制限がある。例えば方程式では、左辺から右辺が決まる場合も、右辺から左辺が決まる場合も表現できる。ところがプログラミング言語では、数式の形での記述は、右辺を計算した結果を左辺の変数へ格納するという1方向の動作を示す(代入文と呼ばれる)。入力と出力の関係(因果関係)が入れ替わるような双方向のモデル、例えば動力用のモータをブレーキ時に発電機としても使うような場合を表すには、代入文よりも方程式を使う方が望ましい。

 ただし、方程式をコンピュータに計算させるには、通常のプログラミング言語とは別の仕組みが必要になる。Elmqvist氏は1976年に連立方程式を単純化して計算する方法を思い付き、連立方程式の処理ソフトを試作した。そこから発展したのがModelica言語である。

 当初は、コンピュータ向けに方程式をどう表現するかと、どう計算処理するかは一緒に考える必要があったため、Modelicaは言語仕様と処理ソフトの両方を指していた。その後これらを切り離し、処理ソフトは「Dymola」の名称で、1992年設立のスウェーデンDynasim社が開発するようになった(現在はDynasim社を買収した仏DassaultSystemesが引き継いでいる)。Modelica言語は、2000年設立のModelica協会が仕様決定を担うようになった。

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

モデル間のインタフェースを規定

 このような、複数のシミュレーション・モデルを組み合わせるメリットを得やすくする目的で、モデル間のインタフェースFMI(Functional Mockup Interface)を標準化しようという動きが始まった。当初は、独Daimler社が独自に開発を始め、その後欧州の公的プロジェクトが規格化し、2010年にバージョン1.0が公開された。FMIはModelicaの仕様と直接の関係はないが、目的が似ているなどの理由で2011年にModelica協会が引き継いだ。

 FMIを用いる場面は、[1]ツール間での「モデル交換」(Model Exchange)、[2]同時に計算を進めているモデル同士の「連成シミュレーション」(Co-Simulation)、の2つである。FMIの対象となるモデルはFMU(Function Mockup Unit)と呼ぶ。FMIが決めるのは、このFMUが物理量をやり取りする際の枠組みである(図2)。

図2●FMIにおける2つの規定
「モデル交換(Model Exchange)」では、モデル(FMU、Functional Mockup Unit)とソルバの間のインタフェースと、同じソルバで計算される他のモデルとのインタフェースを規定する。「連成シミュレーション(Co-Simulation)」では、モデルとソルバの組みをFMUと捉え、これとマスタ(連成シミュレーションの計算全体を制御するソフト)との間のインタフェースを規定する。
[画像のクリックで拡大表示]

 モデル交換と連成シミュレーションでは、それぞれ規定が分かれている。モデル交換の規定では、システムのシミュレーション・モデル(システムモデル)が動いているシミュレーション・ツールに、外部からFMUを読み込むことを想定している。そのFMUとシステムモデルの間と、FMUとソルバ(積分器)との間の物理量のやり取りを規定する〔図2(a)〕。

 連成シミュレーションの規定では、独立して動作する複数のシミュレーション・モデルを想定しており、FMUはソルバを含む。FMU同士は対等であり、シミュレーション全体を制御するマスタの下で動作する。従ってFMIではFMUとマスタとのインタフェースを規定する〔図2(b)〕。

 FMIの開発を始めたDaimler社では、商用車のギヤのシミュレーション・システムを複数のシミュレータとFMIで構成するプロジェクトを実行した(図3)。制御モデルと、物理モデル(トランスミッション、エンジン、車体)がそれぞれ別のシミュレータ上のモデルやDaimler社が作成したプログラムとして存在しており、これらをFMIで接続した。

 FMIの次期バージョン2.0(2013年12月公開予定)では、モデル交換と連成シミュレーションの規定の親和性を高める。さらに、2014年中ごろに小さな改訂を加えたFMI2.1を確定し、「これで主要な規定がほぼ出そろうため、普及を拡大できる時期になる」〔Modelica協会FMIプロジェクト議長のTorsten Blochwitz氏(独ITI社R&Dマネジャ)〕という。

図3●独Daimler社におけるFMI応用プロジェクト
商用車のギヤのシミュレーションを、複数のツールを用いて実行した。図の右から、トランスミッションの制御モデル(独自プログラム)とエンジン制御モデル(「Simulink」上に作成)を1Dシミュレーション・ツール(SimulationX)の物理モデルに組み込む。さらに、これを機構解析ツール(SIMPACK)の車体の物理モデルに組み込む。
[画像のクリックで拡大表示]