モデルベース開発（MBD）入門

モデルベース開発（MBD）とは何か - 定義と従来型開発との違い

モデルベース開発（MBD、Model-Based Development）とは、装置やソフトウェアの動作、あるいは構造を数式やブロック図で表したモデルを中心に、設計と検証を進める開発手法です。制御アルゴリズムや、制御対象であるプラントの特性をモデル化し、実機が完成する前からシミュレーションで動作を確認します。モデルを共有することで、設計者間での仕様の解釈のずれも減らせます。

従来の組み込み開発では、まず仕様書や設計書といったドキュメントで動作を規定していました。実際の動作確認は、試作品が完成してからおこなうのが一般的でした。この進め方は、手戻りのリスクと表裏一体の関係にあります（「開発の全体像と手戻りを防ぐ設計」参照）。試作後に不具合が見つかると、設計のやり直しが発生し、開発期間とコストが膨らみます。手戻りの規模が大きいほど、開発全体に与える影響も大きくなります。

MBDでは、設計の初期段階からモデルを作成します。パラメータを変えながら、繰り返しシミュレーションを実行できる点が特徴です。試作前に制御ロジックの妥当性を確認できるため、手戻りの発生源を早期につぶせます。ただしこの効果は、モデル化のしやすさに強く依存します。この点については、後の見出しで詳しく整理します。

MILS・SILS・HILSとは - 検証の段階を整理する

MBDの検証プロセスは、大きくMILS、SILS、HILSという3つの段階に整理されます。それぞれの略称は、検証対象が何であるかの違いを表しています。

• MILS（Model-In-the-Loop Simulation）は、制御アルゴリズムと制御対象を、どちらも簡易的なモデルとして表現し、シミュレーション上で動作を検証する段階です。実装に入る前の設計段階で、制御ロジックの妥当性を確認する目的で使います。
• SILS（Software-In-the-Loop Simulation）は、制御アルゴリズムをモデルから生成した実際のソフトウェアに置き換え、制御対象のモデルと組み合わせて検証する段階です。コードレベルでの動作を、実機を使わずに確認できます。
• HILS（Hardware-In-the-Loop Simulation）は、ソフトウェアを実際の制御基板やマイコンに搭載し、制御対象は模擬信号に置き換えて検証する段階です。リアルタイムで動作させるため、試作機が完成する前に、実機に近い条件でテストできます。

この3段階は、V字モデルでいう右側、つまり実装から実機検証に向かう工程と重なります（「V字モデルで学ぶテスト工程と品質保証」参照）。モデルの抽象度を段階的に下げながら、検証対象を実機へ近づけていく考え方です。検証の抽象度を意識せずに進めると、どの段階で何を確認したのかがあいまいになります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

なぜ自動車業界でMBDが先行して普及したのか

自動車は、数十から百を超える電子制御ユニット（ECU、Electronic Control Unit）が連携して動作する、大規模な制御システムです。全体の挙動を試作機だけで把握するのは難しく、モデルによる事前検証の必要性が早くから高まっていました。制御対象どうしの干渉も多く、部分ごとの試作だけでは全体の妥当性を確かめきれません。

自動車は、一つの車種で数万台から数十万台という規模で量産されます。モデル作成やツール導入にかかる初期投資を、量産台数で割ることで、1台あたりの負担を抑えられます。この採算構造は、小ロット生産が多い産業機器や医療機器とは大きく異なります。量産規模の違いは、開発手法の選択にも影響します（「組み込みソフトと汎用ソフトの違い」参照）。少量生産の現場では、モデル化にかけた工数を回収しにくい構造があります。

自動車の機能安全規格であるISO 26262や、開発プロセスの成熟度を評価するAutomotive SPICE（A-SPICE）は、モデルによる仕様の明確化と、検証記録の整備を重視しています。規格への対応が、MBD導入を後押しする一因になりました。リアルタイム性や資源制約という組み込み共通の事情に加え（「組み込み開発における制約事項」参照）、自動車特有の規格対応が、普及をさらに加速させました。

非自動車の組み込みでMBDが向く領域

家電や産業機器、医療機器の組み込み開発でも、制御アルゴリズムを数式で表現できる領域では、MBDの効果を発揮しやすいといえます。

• 温度制御：エアコンや調理機器などで、センサが検出した温度を入力に、ヒーターやモータへの出力を計算する制御です。伝達関数や微分方程式で挙動を記述しやすい領域です。
• モータ制御：ファンやポンプ、搬送装置、輸液ポンプなどのモータを、目標回転数やトルクに追従させる制御です。フィードバック制御の理論を、そのままモデルに落とし込めます。
• 電源制御：電圧や電流を目標値に保つ制御です。連続的な物理量を扱うため、モデル化との親和性が高い領域です。
• フィルタ処理：センサ信号からノイズを取り除く信号処理です。数式で明確に定義できるため、モデルとコードの対応を取りやすい領域です。

これらに共通するのは、制御対象の振る舞いを、微分方程式や伝達関数といった数式で近似できる点です。数式化しやすい領域ほど、モデルとシミュレーションの恩恵を受けやすくなります。逆に言えば、数式化が難しい領域では、同じ効果を期待しにくいということでもあります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

非自動車の組み込みでMBDが向かない領域

一方で、モデル化の旨みが薄い領域も存在します。こうした領域に無理にMBDを適用すると、かえって開発効率を下げる場合があります。

• シーケンス制御：動作の状態を切り換えながら進める制御です。状態遷移が中心となるため、数式よりも状態遷移図やステートマシンで表現するほうが適しています。ステートマシンによる設計手法との相性のほうが良い領域です（「状態爆発を防ぐステートマシン設計」参照）。
• UI（ユーザインターフェース）処理：画面表示やボタン操作への応答は、数式によるモデル化になじみにくい処理です。
• 通信プロトコル処理：パケットの解釈や手順の制御は、論理的な条件分岐の集まりであり、連続的な物理量を扱うモデルとは性質が異なります。
• 割り込み処理：発生タイミングが不定な事象への対応は、モデルとして表現しにくい領域です。

これらの領域を無理にモデル化すると、モデルの複雑さがかえって増します。レビューやデバッグの負担が増える場合もあります。MBDを適用する範囲は、制御対象の性質を見極めたうえで選ぶ姿勢が欠かせません。モデル化ありきで進めるのではなく、対象ごとに向き不向きを判断する姿勢が求められます。

導入のハードルと、モデル検証で終わらせないための実機検証

MBDの導入には、いくつかの現実的なハードルがあります。モデルの作成やシミュレーションをおこなうツールのライセンス費用は、小規模なプロジェクトには負担になりやすいものです。モデルを設計する技術者には、制御理論とモデリングの両方のスキルが求められ、育成にも時間がかかります。少量生産が多い非自動車分野では、この初期投資を回収しにくい点も見逃せません。

既存の手書きコード資産との共存も、見過ごせない課題です。長年の運用実績がある手書きコードを、モデルから生成したコードに置き換える際には、両者の書き方の違いを吸収する工夫が必要です。言語仕様やコーディング規約とも関わる論点です（「組み込みソフトの開発言語」参照）。モデルから生成したコードは、モデルの記述次第で意図しない構造になる場合があります。生成後のレビューやデバッグに手間がかかる点も、見過ごせません。

さらに重要なのは、MBDによる検証がモデルの中だけで完結しない点です。MILSやSILSでの検証結果が良好でも、最終的には実機での検証を欠かせません。実機には、部品の個体差や配線から拾うノイズ、処理のタイミングのずれなど、モデルには表れない要素が存在するためです。モデルの中でどれほど精緻に検証しても、この差を完全にはなくせません。

モデル検証と実機検証の間を埋める手段として、実機に接続する周辺機器の入出力を模擬的に再現し、実機相当の条件で動作を確かめる装置を使う方法があります。センサやアクチュエータの信号を模擬しながら、実機のマイコンやソフトウェアと組み合わせて検証する考え方です。検証手段の使い分けの整理とあわせて、検証段階に応じた手段を選ぶ姿勢が求められます（「エミュレータ/シミュレータ/実機の使い分け」参照）。実機だけに頼らず、段階を踏んで検証範囲を広げていく進め方が現実的です。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

まとめ

モデルベース開発は、制御アルゴリズムを数式で表現できる領域では、非自動車の組み込み開発でも効果を発揮します。一方でシーケンス制御やUI、通信処理には向きません。ツールのライセンス費用やスキル、既存資産との共存という導入のハードルもあります。導入の際は対象領域を見極め、モデル検証と実機検証を組み合わせる姿勢が重要です。