【連載】自動車開発におけるシミュレーションの基本（第5回）

MBD（Model Based Development：モデルベース開発）の文脈で、MILS（Model In the Loop Simulation）やSILS（Software In the Loop Simulation）やHILS（Hardware In the Loop Simulation）といった単語がよく出てきます。

これらについて理解するには、前回までで解説したシミュレーション環境の構成に関する理解だけでなく、コントローラ内のソフトウェア構造やその開発プロセスについて理解する必要があります。

図1に、制御ソフトウェアおよびそれを搭載したECU（Electronic Control Unit）のソフトウェア構造と、MBDを適用した場合の開発プロセスの概要イメージを示します。

ECUのハードウェアやハードウェアに近い低レイヤ側のソフトウェアと、その上位レイヤに載るアプリケーション側のソフトウェア開発を分離し、アプリケーション側の開発にはMBDを適用する（モデルを作成してからコードを作成する）場合のイメージを示しています。それぞれのソフトウェアに関するもう少し詳細な内容は、第2回の記事を参照ください。ここでいうモデルはコンピュータ上で実行可能なモデルを指す事とし、モデリングツールとしてはMathWorks社のMatlab/Simulink製品群が特に有名です。なお、Simulinkモデルからコードの自動生成をする際は、先述のモデルをベースとしてコード生成用のモデルを構築した上でコード生成を行うワークフローが一般的です [1]。

ここまでの内容を基に、MILS/SILS/HILSについて解説します。位置付けとしては図1におけるアプリケーション部分を主な評価対象とする視点での解説となります。

MILSはModel In the Loop Simulationの略であり、モデルを評価対象としたシミュレーション環境です。

図2に、開発プロセスに対するMILSの位置付けを示します。評価対象（制御モデル）を、プラントモデルと接続してシミュレーションします。「プラントモデルとは何か」や「プラントモデルと評価対象（ここでは制御モデル）をどのような構成で接続するか」という考え方については、第3回や第4回の記事を参照してください。

MILSはECUのハードウェアや低レイヤ側のSWが存在しない段階で制御モデルの振る舞いを確認できるため、開発の初期段階から活用可能です。

SILSはSoftware In the Loop Simulationの略であり、ソフトウェアを評価対象とした シミュレーション環境です。

アプリケーション部のソフトウェアを評価対象として、プラントモデルと接続してシミュレーションする場合のイメージを図3に示します。

また、生成したコードをプロトタイピングユニットと呼ばれる機器向けにビルドして書き込むことで、HILS環境に接続したり車両に搭載したりすることが可能となります。このような方式はRCP（Rapid Control Prototyping）と呼ばれます。SILSはECUのハードウェアが存在しない段階から開発した制御アルゴリズムを実車やHILSシステムに接続して動作確認できるため、開発初期または中期から活用可能です。

ここではアプリケーション部のソフトウェアにフォーカスした説明をしていますが、低レイヤ側のソフトウェアも評価対象に含める場合、どこまで量産コードを用いるか（あるいはシミュレーション用コードで置き換えるか）によってECUの仮想化レベルが変わります。

HILSはHardware In the Loop Simulationの略であり、ECUを評価対象としたシミュレーション環境です。構成としてはECUをHILSシステムに接続した環境となります（図 4）。HILSではアプリケーション部のソフトウェアをECUのハードウェアや低レイヤ側のソフトと結合したECUとしての評価が可能となるため、ソフトウェア結合の観点での評価やハードウェア観点（電源電圧異常や断線などの故障モード）での評価も可能となります。

MILS/SILS/HILSの活用について、開発の序盤から終盤にかけてMILS→SILS→HILSの順で活用する、という説明がされることがあります。確かに、ECUのハードウェアが存在しない段階ではそのECUを評価するためのHILSは活用不可能であるというのは事実ですが、開発の終盤だからと言ってMILSやSILSが活用できないというわけではない、というのが筆者の意見です。

例えば、開発中に見つかった課題がアプリケーション層のアルゴリズムに起因するものであると分かった場合、開発の終盤であってもMILSやSILSも有効な選択肢になるでしょう。重要なのは、MILS/SILS/HILS環境で、システムのどの領域のどの側面をどうやって評価するのかを理解して整理する事であり、その観点や業務状況（例えばシミュレーション環境の構築状況や機材の占有状況など）を踏まえて環境を使い分けていくのが良いと筆者は考えています。

本連載では、シミュレーション技術について解説しました。

第1回で、シミュレーションとは端的に言うと模倣であり、故にシミュレーションの活用ではまずその対象をよく理解することが重要であると述べました。

第2回では、シミュレーションの対象となる自動車システムの例として、ACC（Adaptive Cruise Control）について解説しました。

第3回では、ハードウェアとソフトウェアのシミュレーションの考え方を解説し、その考え方を第2回のACCのシミュレーションに適用する例を示しました。

第4回では、シミュレーションを自動車システムの評価に用いる際の構成について解説し、その考え方を第2回のACCにおけるADAS（Advanced Driver-Assistance Systems）コントローラの評価に適用する例を示しました。

第5回では、制御ソフトウェアの開発プロセスを踏まえて、MILS/SILS/HILSの考え方について解説しました。

一部本文中でも言及しましたが、シミュレーションを業務に活用する上で特に重要なポイントは以下であると筆者は考えています。

• シミュレーション対象の構造とメカニズムを理解すること
• シミュレーション技術の仕組みを理解すること
• シミュレーションを活用する目的を明確にすること

シミュレーションは便利であると同時に、取り扱いに注意すべき技術です。仕組みがよく分かっていなくとも、もっともらしい結果は得られてしまいます。このため、適切に使いこなすためには幅広い知見が必要です。

私自身、まだまだ勉強中の身ではありますが、本連載がシミュレーションについて理解する一助となりましたら幸いです。皆さまがシミュレーションを適切に活用し、良いエンジニアリングライフを送る事を願います。

参考文献

[1] MathWorks社, “MBD(モデルベース開発)とは？　これだけは知っておきたい3つのこと,” [オンライン]. Available: https://jp.mathworks.com/discovery/mbd.html, Accessed Mar. 26, 2025.