オートメーションにおけるシミュレーションとエミュレーション：違いは何か？

By Mirko Peters · 2026-11-11

オートメーションにおけるシミュレーションとエミュレーション：シミュレーションはシステムの振る舞いをモデル化し、エミュレーションは実機の一部の代わりとなってリアルタイムで動作させます。それぞれをいつ使うべきかを解説します。

Automatically translated with AI from the original post. Read the English original

オートメーションにおいて、シミュレーションはシステムの振る舞いを模倣するモデルであり、選択肢を検討するためにリアルタイムより速く実行されることがよくあります。エミュレーションは、実システムの一部をモデルで置き換えるか、機器を模倣するもので、実機の相手側がそれを実際の機器に接続されているかのように動作し、リアルタイムで実行されます。このガイドは、見積書や프로젝트計画で両者の用語が混在しているのを読む業務改善（オペレーショナルエクセレンス）マネージャーを対象としています。たとえばバーチャルコミッショニングの場面です。定義、それぞれの用途、ソフトウェアインザループとハードウェアインザループの位置づけ、そして実行時間を含む具体例を学べます。

重要なポイント

• シミュレーションはシステムの振る舞いをモデル化し、リアルタイムより速く実行できます。エミュレーションは実システムの一部をモデルで置き換えるか、機器を模倣し、リアルタイムで実行されます。
• 設計案、レイアウト、生産能力、制御戦略の検討にはシミュレーションを使用します。制御ロジックをプラントモデルに対してテストする場合や、人材の訓練にはエミュレーションを使用します。
• エミュレーションは高速化できません。制御タイマーや通信が実時間に依存しているためです。そのため、多数のシナリオを実行するツールとしては不向きです。
• ソフトウェアインザループとハードウェアインザループは、どちらもエミュレーションの構成です。実際の制御コードや実機のコントローラーが、模擬されたプラントと連携して動作します。
• これらの用語は曖昧に使われることが多いため、見積書や仕様書を受け入れる前に、何がリアルタイムで動作し、何が実物で、何がモデルなのかを確認してください。

シミュレーションとエミュレーション：結論

両者の用語は重なり合っており、文献もそれを認めています。エミュレーションもシミュレーションも、物理的なハードウェアに触れる前にデバッグやテストができる仮想環境を作り出します。Duque Anton氏らの共著者による産業用ネットワークシミュレーションに関する報告（arXivで公開）は、シミュレーションはシステムの状態を模倣することを目的とし、エミュレーションはその振る舞いを再現することを目的とすると述べています。著者らは、両者の語はしばしば互換的に使われること、また多くのツールが両方を行えるため、一般的に「シミュレーション」という語を用いていることも指摘しています。

より実用的な定義は、Ian McGregor氏が2002 Winter Simulation Conference向けの論文で示したものです。同氏は、エミュレーションモデルを、モデルの機能の一部を実システムの一部が担うものと定義しており、その逆も成り立つとしています。つまり、実システムの一部がモデルに置き換えられるということです。McGregor氏はエミュレーションツールを販売する企業に勤めていたため、その主張は割り引いて読む必要があります。ただし定義そのものは、どのプロジェクトに対しても容易に検証できます。

平たく言えば、オートメーションの実務上の区別は次のとおりです。

• シミュレーションは、単独で実行するシステム全体のモデルです。入力を変更して結果を観察でき、高速に実行できます。需要、停止、人員配置をシミュレーションでき、何かを構築する前にモデル上でレイアウトの試作を行うこともできます。
• エミュレーションは、実物を何らかの形でモデルに接続します。実物とは制御プログラム、コントローラー、オペレーターパネルなどを指し、モデルはその周囲の機械やプラントを模擬します。実物が関わるため、実行には実時間がかかります。

ツールにも同じ違いが表れます。エミュレーターとシミュレーターの違いは、何を再現するかにあります。シミュレーターは、プラントやコントローラーのプログラムロジックをモデルで模擬できます。エミュレーターは、実際のコントローラーの機能を、CPUの動作や通信に至るまで再現しようとします。そのため、実際のコードをそのうえで動かし、対象のハードウェアで行われる動作を再現できます。実際には、ベンダーが PLC のエミュレーターとシミュレーターを、どちらの名称でも呼ぶことがよくあります。そのため、ラベルの裏にある中身を確認してください。同じコントローラー向けでも、シミュレーターとエミュレーターでは、対象システムをどれだけ忠実に再現するかが大きく異なる場合があります。

ユースケース：オートメーションにおける用途の違い

McGregor は典型的なユースケースを説明しています。シミュレーションモデルは、さまざまなソリューションをテストおよび開発し、最適なものを見つけるために使われます。設計案、レイアウト、稼働限界、制御戦略を検討します。実行速度は速く、実時間よりも速く動くことも多く、パラメーターが変わらなければ結果を再現できます。そのため、多くの実験や自動最適化に適しています。

エミュレーションモデルは、さまざまな負荷条件下で制御システムのロジックをテストし、本番稼働前に制御の動作を検証し、オペレーターや保守担当者を教育するために使われます。外部から制御システムを接続した状態で、実時間で動作します。

McGregor は制約についても挙げています。エミュレーションモデルは、多くの場合で実時間でしか動作しないため、実験には不向きです。実時間より速く動かすと、制御システムのタイマーが適応できないためエラーが発生します。また、モデルとコントローラー間の通信は非同期で、ネットワークやオペレーティングシステムに依存するため、結果の再現性も低くなります。

Duque Anton と共著者たちは、反対側の視点から似た指摘をしています。シミュレーションはコスト、リソース、時間の面で効率的です。ただし、物理的な特性はすべてモデル化する必要があり、それには多大な労力がかかる場合があります。エミュレーションは、環境が実物である場合、設計上は本番システムと同等の精度を持ちます。一方で、より多くの機器と設置スペースが必要になり、コストも高くなります。彼らの結論は、すべての要件を満たす汎用的な解決策は存在しない、というものです。

ソフトウェアインザループ、ハードウェアインザループとデジタルツイン

オートメーションプロジェクトでは、この2つの考え方が「インザループ」テストで交わります。realvirtual のベンダーページでは、これらを次のように説明しています。

• ソフトウェアインザループ：制御プログラムが PC 上でソフトウェアとして動作し、たとえば PLC エミュレーターを使って機械モデルと連携します。ハードウェアは不要です。
• ハードウェアインザループ：実際の PLC がネットワーク経由で機械モデルに接続します。実機のハードウェアが仮想の機械を動かします。

どちらも McGregor の定義でいうエミュレーションです。実物の一部、つまり制御コードまたはコントローラーが、残りの部分のモデルと連携して動作するためです。これらはバーチャルコミッショニングの中核をなします。このページはベンダーの情報源ですが、その説明は上記の学術的な定義と一致しています。

生産フローのモデルは別のケースです。工場シミュレーションは、現在の運用ルール、リソース、受注、通常のばらつきを用いて、工場の一部で作業がどのように流れるかを管理されたモデルで再現するものです。残業シフトの追加、新しい機械の導入、バッファーの縮小といった変更を、実施前にテストできます。制御機器はループに含まれません。純粋な意味でのシミュレーションであり、実時間よりはるかに速く動作します。

デジタルツインとは、物理的なリソースの保守された デジタル表現で、観測データにより最新の状態に保たれるものです。どちらの場合にもモデルとして使用できます。重要なのはモデルそのものではなく、その使い方です。単独で行う実験であればシミュレーションになります。実時間で実物と接続すればエミュレーションになります。

エミュレーターかシミュレーターか：どちらを使うべきか

以下は簡易的な指針です。これは当社独自の要約であり、標準ではありません。

• 必要な生産能力はどれくらいか、ボトルネックはどこか？シミュレーション。多くのシナリオを素早く検証したい場合に適しています。
• 制御プログラムは、ジャム、部品の欠品、センサーの故障に対応できるか。 まずはソフトウェア上のエミュレーションで確認します。
• 実機のコントローラーは、タイミングとインターフェースの要件を満たすか。 ハードウェアインザループ、または実際の設備でのテストです。Duque Anton らの共著者は、実機が最も現実的な結果をもたらす一方で、構築が最も難しいと述べています。
• 稼働開始前にオペレーターを訓練できるか。 エミュレーションです。実際の制御盤に接続したモデルは、機械と同じように動作します。
• 2つのレイアウト案のどちらが優れているか。 シミュレーションです。

1つのプロジェクトでは、両方が必要になることが多くあります。まずシミュレーションでラインの規模を決め、その後にエミュレーションで、そのラインの制御プログラムを検証します。

例：1つの梱包ライン、2つの問い

これは説明のための例であり、実測データに基づくケースではありません。ある梱包ラインは1時間あたり3,000ケースを生産しています。工場側は2つの問いを立てました。

問い1：2台目のラベラーを追加すれば、生産量は1時間あたり3,600ケースに増えるか。 これはシミュレーションで答えるべき問いです。生産モデルは、8時間の1シフトを約2分で実行します。これは実時間の240倍の速さです。チームは、バッチサイズ、バッファサイズ、停止パターンの違いなど、30通りのシナリオを検証します。30回の実行にかかる時間は約60分です。同じ30シナリオを実時間で行うと、30 × 8時間 = 240時間、つまり30稼働日かかります。この問いに対して、実時間のテストは現実的な選択肢ではありません。

問い2：ラベラーでケースが詰まった場合、制御プログラムは正しく対応するか。 これはエミュレーションで答えるべき問いです。制御プログラムはPLCエミュレーター上で動作し、ラインの動きはモデルが再現します。故障ケース1件あたり実時間で約5分かかり、タイマーがプログラムの実時間に依存しているため、早送りはできません。12件の故障ケースに約60分かかります。実際のラインで立ち上げ中にジャム対応の誤りを発見するのに比べれば、これは低コストです。

両方のテストはどちらも約1時間で完了しますが、答えるべき問いが異なります。高速なシミュレーションでは、制御タイマーが正しく動作するかどうかはわかりません。一方、実時間のエミュレーションでは、1日で30シナリオを検証することはできません。

よくある間違い

• 仕様書で両者を同義語として扱うこと。 「シミュレーション」を提供するサプライヤーが、純粋なモデルだけを納品する可能性があります。制御のテストが必要だった場合、それでは不十分です。
• シミュレーションだけで制御のタイミングを判断すること。 実時間より速く動作するモデルは、タイマーや通信について何も示しません。
• エミュレーションを早送りすること。 制御タイマーが追従できない場合、結果は誤ったものになります。
• 過度に詳細なモデルを作ること。 すべてのケーブルやボルトまで再現したモデルは、その問いには不要な労力とコストがかかります。
• エミュレーターを実際のコントローラーと同一視すること。 コントローラーのエミュレーションは実際のPLCそのものではありません。タイミングとインターフェースについては、実機での確認を計画してください。
• 実際のラインでの受け入れテストを行わないこと。 仮想環境でのテストに合格することでリスクは下がりますが、リスクがなくなるわけではありません。

ソフトウェアはどのように役立つか

両方の目的に使えるツールがあります。生産フローのモデルはシミュレーションソフトウェアで実行され、制御のテストはPLCエミュレーションとマシンモデルを使って行われます。サプライヤーには、どの部分が実時間で動作するのか、どの部分が実物なのか、どの部分がモデル化されたものなのかを確認してください。制御コードのソフトウェアテストについては、テストがどのように自動化され記録されるのかを尋ねてください。プログラムを変更するたびにテストを再実行できるようにするためです。また、使用しているPLCプラットフォームへの接続方法と、モデル構築に必要な工数も確認してください。どの問いを立てるべきかは、ソフトウェアが決めてくれるわけではありません。明確な問いを立てることこそが、2つの手法のどちらを選ぶかを判断する最善の方法です。

次のステップ

次回の自動化プロジェクトでは、実施したいテストをそれぞれ問いの形で書き出し、各テストに「多くのシナリオを高速に」または「実際の制御を実時間で」のいずれかの印を付けてください。そのうえで、見積もりを依頼する前に、そのリストをもとにシミュレーションとエミュレーションのどちらを使うかを決めてください。