Симуляція та емуляція в автоматизації: у чому різниця?

By Mirko Peters · 2026-11-11

Симуляція та емуляція в автоматизації: симуляція моделює поведінку системи, а емуляція замінює реальну частину і працює в реальному часі. Дізнайтеся, коли використовувати кожну з них.

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

В автоматизації симуляція — це модель, яка відтворює поведінку системи, часто швидше за реальний час, щоб перебрати варіанти. Емуляція замінює частину реальної системи моделлю або імітує пристрій, тож реальний аналог працює з нею так, ніби він підключений до справжнього об'єкта, і вона працює в реальному часі. Цей посібник призначений для керівників з операційної досконалості, які читають комерційні пропозиції та плани проєктів, де ці два терміни змішані, наприклад у virtual commissioning. Ви дізнаєтеся визначення, для чого використовується кожен підхід, як у контур входять software і hardware in the loop, а також розглянете приклад із часом виконання.

Головне

• Симуляція моделює поведінку системи і може працювати швидше за реальний час; емуляція замінює частину реальної системи моделлю або імітує пристрій і працює в реальному часі.
• Використовуйте симуляцію, щоб досліджувати варіанти проєктування, компонування, потужності та стратегії керування; використовуйте емуляцію, щоб перевіряти логіку керування на моделі установки і навчати персонал.
• Емуляцію не можна прискорити, адже таймери керування й обмін даними залежать від реального часу, тому вона погано підходить для запуску багатьох сценаріїв.
• Software in the loop і hardware in the loop — це конфігурації емуляції: реальний код керування або реальний контролер працюють з симульованою установкою.
• Ці слова часто вживаються вільно, тож перш ніж погодити комерційну пропозицію чи специфікацію, з'ясуйте, що працює в реальному часі, що є реальним, а що змодельованим.

Симуляція та емуляція: коротка відповідь

Терміни перетинаються, і це визнає й наукова література. Емуляція і симуляція обидві створюють віртуальне середовище, в якому можна налагоджувати й тестувати до того, як торкнутися фізичного обладнання. У звіті про симуляцію промислових мереж Дуке Антона та його співавторів, доступному на arXiv, сказано, що симуляція прагне відтворити стани системи, а емуляція — її поведінку. Автори зазначають, що ці два слова часто використовують як взаємозамінні, і що вони говорять «симуляція» загалом, бо багато інструментів здатні робити обидва.

Практичніше визначення дає Ian McGregor у статті для 2002 Winter Simulation Conference. Він визначає модель емуляції як ту, в якій певну функціональну частину моделі виконує частина реальної системи, і навпаки: частина реальної системи замінюється моделлю. McGregor працював у компанії, що продає інструменти для емуляції, тож ставтеся до його тверджень із цим на увазі. Саме визначення легко перевірити на будь-якому проєкті.

Простими словами, практичне розрізнення в автоматизації таке:

• Симуляція — це модель усієї системи, яку ви запускаєте окремо. Ви змінюєте вхідні дані і дивитеся, що станеться, а запускати її можна швидко. Можна симулювати попит, зупинки та укомплектування персоналом, а також побудувати прототип компонування в моделі ще до того, як щось буде збудовано.
• Емуляція з'єднує щось реальне з моделлю. Реальним може бути програма керування, контролер або панель оператора, а модель відтворює навколишню машину чи установку. Оскільки в процесі бере участь щось реальне, запуск відбувається в реальному часі.

Та сама різниця видна й в інструментах: відмінність між емулятором і симулятором полягає в тому, що саме вони відтворюють. Симулятор може змоделювати установку або логіку програми контролера. Емулятор намагається відтворити функціональність реального контролера, аж до поведінки його процесора та комунікації, щоб на ньому можна було запустити реальний код і отримати те, що він зробив би на цільовому обладнанні. На практиці постачальники часто називають емулятор і симулятор ПЛК будь-яким із цих термінів, тож варто перевірити, що насправді приховано за назвою. Симулятори й емулятори для одного й того самого контролера можуть суттєво відрізнятися за точністю відтворення цільової системи.

Сценарії використання: для чого кожен із них застосовується в автоматизації

Макґрегор описує типові сценарії використання. Моделі симуляції застосовують для тестування й розробки різних рішень, щоб знайти найкраще. Вони дозволяють досліджувати варіанти конструкції, компонування, експлуатаційні межі та стратегію керування. Вони працюють швидко, часто швидше за реальний час, і дають відтворювані результати, якщо параметри не змінюються. Це робить їх придатними для багатьох експериментів і для автоматизованої оптимізації.

Моделі емуляції використовують для тестування логіки системи керування за різних навантажень, для перевірки поведінки керування перед введенням в експлуатацію та для навчання операторів і персоналу з технічного обслуговування. Вони працюють у реальному часі, а система керування підключена до них ззовні.

Макґрегор також перелічує обмеження. Моделі емуляції погано підходять для експериментів, бо часто працюють лише в реальному часі. Запуск швидше за реальний час спричиняє помилки, оскільки таймери системи керування не можуть адаптуватися. Результати також менш відтворювані, адже комунікація між моделлю та контролером є асинхронною і залежить від мережі та операційної системи.

Дуке Антон і співавтори висловлюють схожу думку з іншого боку. Симуляція ефективна за вартістю, ресурсами та часом, але кожну фізичну характеристику треба змоделювати, а це іноді вимагає багато зусиль. Емуляція за задумом така ж точна, як продуктивна система, коли середовище реальне, але вона потребує більше пристроїв і місця та коштує дорожче. Їхній висновок: універсального рішення, яке б відповідало всім вимогам, не існує.

Software in the loop, hardware in the loop і цифровий двійник

В проєктах автоматизації ці дві ідеї зустрічаються в тестах «in the loop». Сторінка постачальника realvirtual описує їх так:

• Software in the loop: програма керування працює як програмне забезпечення на ПК, наприклад в емуляторі ПЛК, і взаємодіє з моделлю машини. Апаратне забезпечення не потрібне.
• Hardware in the loop: реальний ПЛК підключається до моделі машини через мережу. Реальне обладнання керує віртуальною машиною.

Обидва варіанти є емуляціями в розумінні Макґрегора, адже реальна частина, код керування чи контролер, працює з моделлю решти системи. Вони становлять основу віртуального введення в експлуатацію. Сторінка є джерелом від постачальника, а її описи узгоджуються з академічними визначеннями вище.

Модель потоку виробництва — інший випадок. Факторна симуляція — це контрольована модель того, як робота рухається через частину фабрики, з урахуванням чинних правил експлуатації, ресурсів, замовлень і звичайних коливань. Це дозволяє перевірити зміну, наприклад додаткову зміну, нову машину чи менший буфер, ще до її впровадження. Контролер у контур не входить. Це симуляція в чистому вигляді, і вона працює значно швидше за реальний час.

Цифровий двійник, тобто підтримуване цифрове представлення фізичного ресурсу, яке оновлюється на основі спостережень, може слугувати моделлю в будь-якому з цих випадків. Важливо не те, якою є модель, а те, як її використовують: як окремий експеримент, що є симуляцією, або як з'єднану з реальним обладнанням у реальному часі, що є емуляцією.

Емулятор чи симулятор: що обрати

Скористайтеся цим як коротким орієнтиром. Це наш власний підсумок, а не стандарт.

• Яка потужність нам потрібна і де вузьке місце? Симуляція. Вам потрібно багато сценаріїв, швидко.
• Чи обробляє програма керування затори, відсутні деталі чи несправності датчиків? Спочатку емуляція в програмному забезпеченні.
• Чи відповідає реальний контролер вимогам щодо часу та інтерфейсів? Апаратура в контурі (hardware in the loop) або випробування на реальному обладнанні. Дуке Антон і співавтори стверджують, що реальне обладнання дає найреалістичніші результати, але його найважче налаштувати.
• Чи можна навчити операторів до запуску? Емуляція. Модель, підключена до реальної панелі керування, поводиться так, як поводилася б машина.
• Яка з двох компоновок краща? Симуляція.

Одному проєкту часто потрібні обидва підходи. Спочатку симуляція визначає розмір лінії. Потім емуляція перевіряє програму керування для цієї лінії.

Приклад: одна пакувальна лінія, два запитання

Це ілюстративний приклад, а не виміряний випадок. Пакувальна лінія випускає 3 000 коробок за годину. Завод ставить два запитання.

Запитання 1: чи підніме другий етикетувальник випуск до 3 600 коробок за годину? Це питання для симуляції. Виробнича модель проганяє одну 8-годинну зміну приблизно за 2 хвилини, що в 240 разів швидше за реальний час. Команда тестує 30 сценаріїв, наприклад різні розміри партій, розміри буферів і шаблони зупинок. Усі 30 прогонів займають близько 60 хвилин. Ті самі 30 сценаріїв у реальному часі тривали б 30 × 8 годин = 240 годин, або 30 робочих днів. Для цього запитання тести в реальному часі не є варіантом.

Запитання 2: чи обробляє програма керування затор коробок на етикетувальнику? Це питання для емуляції. Програма керування працює в емуляторі ПЛК, а модель відтворює лінію. Кожен випадок несправності триває близько 5 хвилин у реальному часі й не може бути прискореним, бо таймери програми залежать від реального часу. Дванадцять випадків несправностей займають близько 60 хвилин. Це недорого порівняно з тим, щоб виявити помилку обробки затору під час запуску на реальній лінії.

Обидва тести займають близько години, і відповідають вони на різні запитання. Швидка симуляція не покаже, чи працюють таймери керування, а емуляція в реальному часі не зможе перевірити 30 сценаріїв за день.

Типові помилки

• Використання слів як синонімів у специфікації. Постачальник, який пропонує «симуляцію», може поставити чисту модель, тоді як вам потрібні були тести керування.
• Оцінка часу керування за симуляцією. Модель, що працює швидше за реальний час, нічого не каже про таймери та комунікацію.
• Прискорення емуляції. Результати буде невірними, якщо таймери керування не встигають за процесом.
• Надто деталізовані моделі. Модель з кожним кабелем і болтом коштує зусиль, яких питання не потребує.
• Довіра до емулятора як до реального контролера. Емуляція контролера не є ПЛК. Заплануйте перевірку часу та інтерфейсів на реальному обладнанні.
• Відсутність приймального тестування на реальній лінії. Успішний віртуальний тест знижує ризик. Але він не усуває його повністю.

Як може допомогти програмне забезпечення

Інструменти для обох цілей існують. Моделі потоку виробництва працюють у програмах симуляції, а тести керування використовують емуляцію ПЛК і моделі машин. Запитайте постачальника, що працює в реальному часі, що є реальним, а що змодельованим. Для програмного тестування коду керування запитайте, як тести автоматизуються і фіксуються, щоб після кожної зміни програми можна було повторити прогін. Запитайте про інтерфейс до вашої платформи ПЛК і про обсяг роботи з побудови моделі. Програмне забезпечення не вирішує за вас, яке запитання ставити, і чітко сформульоване запитання — найкращий спосіб обрати між двома підходами.

Наступний крок

Для наступного проєкту автоматизації запишіть кожен потрібний тест у формі запитання і позначте кожен як «багато сценаріїв, швидко» або «реальне керування, реальний час». Потім використайте цей список, щоб вирішити питання симуляції чи емуляції до того, як запитувати комерційні пропозиції.