Symulacja a emulacja w automatyce: jaka jest różnica?

By Mirko Peters · 2026-11-11

Symulacja a emulacja w automatyce: symulacja modeluje zachowanie systemu, a emulacja zastępuje rzeczywistą część i działa w czasie rzeczywistym. Sprawdź, kiedy stosować każde z nich.

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

W automatyce symulacja to model odwzorowujący zachowanie systemu, często szybciej niż w czasie rzeczywistym, aby badać warianty. Emulacja zastępuje część rzeczywistego systemu modelem albo imituje urządzenie, tak aby rzeczywisty element współpracował z nim tak, jakby był podłączony do prawdziwego obiektu, i działa w czasie rzeczywistym. Ten przewodnik jest przeznaczony dla kierowników ds. doskonałości operacyjnej, którzy czytają oferty i plany projektów mieszające oba terminy, na przykład w virtual commissioning. Dowiesz się, jakie są definicje, do czego służy każde z nich, jak do tego pasują software in the loop i hardware in the loop, oraz zobaczysz przykład z czasami wykonania.

Najważniejsze wnioski

• Symulacja modeluje zachowanie systemu i może działać szybciej niż w czasie rzeczywistym; emulacja zastępuje część rzeczywistego systemu modelem albo imituje urządzenie i działa w czasie rzeczywistym.
• Symulacji używaj do badania wariantów projektowych, układów, wydajności i strategii sterowania; emulacji używaj do testowania logiki sterowania na modelu instalacji oraz do szkolenia personelu.
• Emulacji nie da się przyspieszyć, ponieważ timery sterowania i komunikacja zależą od czasu rzeczywistego, dlatego słabo nadaje się do uruchamiania wielu scenariuszy.
• Software in the loop i hardware in the loop to konfiguracje emulacyjne: rzeczywisty kod sterowania lub rzeczywisty sterownik współpracuje z symulowaną instalacją.
• Określenia te są często używane swobodnie, dlatego zanim zaakceptujesz ofertę lub specyfikację, zapytaj, co działa w czasie rzeczywistym, co jest rzeczywiste, a co zamodelowane.

Symulacja a emulacja: krótka odpowiedź

Te pojęcia się pokrywają, a literatura to przyznaje. Zarówno emulacja, jak i symulacja tworzą środowisko wirtualne, w którym można debugować i testować przed dotknięciem fizycznego sprzętu. Raport z badań nad symulacją sieci przemysłowych autorstwa Duque Antona i współautorów, dostępny w serwisie arXiv, stwierdza, że symulacja ma na celu odwzorowanie stanów systemu, a emulacja – odtworzenie jego zachowania. Autorzy zauważają, że oba słowa są często używane zamiennie, a sami posługują się ogólnie terminem „symulacja”, ponieważ wiele narzędzi potrafi robić obie rzeczy.

Bardziej praktyczną definicję podaje Ian McGregor w artykule na konferencję 2002 Winter Simulation Conference. Definiuje on model emulacyjny jako taki, w którym pewna funkcjonalna część modelu realizowana jest przez fragment rzeczywistego systemu, a zachodzi też zależność odwrotna: część rzeczywistego systemu zastępowana jest modelem. McGregor pracował dla firmy sprzedającej narzędzia do emulacji, dlatego jego tezy warto czytać z tym na uwadze. Sama definicja jest jednak łatwa do sprawdzenia w każdym projekcie.

Mówiąc prosto, praktyczne rozróżnienie w automatyce wygląda następująco:

• Symulacja to model całego systemu, który uruchamiasz samodzielnie. Zmieniasz dane wejściowe i obserwujesz, co się dzieje, a model możesz uruchomić szybko. Możesz symulować popyt, postoje i obsadę, a także zbudować w modelu prototyp układu, zanim cokolwiek zostanie zbudowane.
• Emulacja łączy coś rzeczywistego z modelem. Tą rzeczywistą częścią może być program sterujący, sterownik lub panel operatora, a model odgrywa maszynę lub instalację wokół niego. Ponieważ uczestniczy coś rzeczywistego, przebieg symulacji trwa tyle, ile trwałby w rzeczywistości.

Ta sama różnica widoczna jest w narzędziach, gdzie rozróżnienie między emulatorem a symulatorem sprowadza się do tego, co dokładnie odwzorowują. Symulator może odwzorowywać instalację lub logikę programu sterownika w postaci modelu. Emulator stara się odtworzyć działanie rzeczywistego sterownika aż do zachowania procesora i komunikacji, tak aby na nim mógł działać prawdziwy kod i odtwarzać to, co zrobiłby na docelowym sprzęcie. W praktyce producenci często nazywają emulator i symulator sterowników PLC jedną z tych nazw, dlatego warto sprawdzić, co kryje się za etykietą. Symulatory i emulatory tego samego sterownika mogą się bardzo różnić pod względem tego, jak wiernie odwzorowują system docelowy.

Zastosowania: do czego każde z nich służy w automatyce

McGregor opisuje typowe zastosowania. Modele symulacyjne służą do testowania i opracowywania różnych rozwiązań w celu znalezienia najlepszego. Pozwalają badać warianty projektu, układ, granice pracy i strategię sterowania. Działają szybko, często szybciej niż w czasie rzeczywistym, a wyniki są powtarzalne, o ile parametry się nie zmieniają. Dzięki temu nadają się do wielu eksperymentów i zautomatyzowanej optymalizacji.

Modele emulacyjne służą do testowania logiki systemu sterowania przy różnych obciążeniach, do weryfikacji działania sterowania przed uruchomieniem oraz do szkolenia operatorów i personelu utrzymania ruchu. Działają w czasie rzeczywistym, a system sterowania jest podłączony z zewnątrz.

McGregor wymienia także ograniczenia. Modele emulacyjne słabo nadają się do eksperymentów, ponieważ często działają wyłącznie w czasie rzeczywistym. Uruchomienie ich szybciej niż w czasie rzeczywistym powoduje błędy, gdyż timery systemu sterowania nie mogą się do tego dostosować. Wyniki są też mniej powtarzalne, ponieważ komunikacja między modelem a sterownikiem jest asynchroniczna i zależy od sieci oraz systemu operacyjnego.

Duque Anton i współautorzy przedstawiają podobny wniosek z drugiej strony. Symulacja jest efektywna pod względem kosztów, zasobów i czasu, ale każda cecha fizyczna musi zostać odwzorowana w modelu, co bywa bardzo pracochłonne. Emulacja z założenia jest tak dokładna jak system produkcyjny, gdy środowisko jest rzeczywiste, jednak wymaga większej liczby urządzeń i przestrzeni oraz kosztuje więcej. Ich wniosek jest taki, że nie istnieje uniwersalne rozwiązanie spełniające wszystkie wymagania.

Software in the loop, hardware in the loop i cyfrowy bliźniak

W projektach automatyki oba pojęcia spotykają się w testach typu „in the loop”. Strona producenta realvirtual opisuje je następująco:

• Software in the loop: program sterujący działa jako oprogramowanie na komputerze PC, na przykład w emulatorze PLC, i współpracuje z modelem maszyny. Sprzęt nie jest potrzebny.
• Hardware in the loop: rzeczywisty sterownik PLC łączy się z modelem maszyny przez sieć. Prawdziwy sprzęt steruje wirtualną maszyną.

Oba przypadki są emulacjami w rozumieniu McGregora, ponieważ rzeczywista część, czyli kod sterujący lub sterownik, współpracuje z modelem reszty układu. Stanowią one rdzeń wirtualnego uruchamiania. Strona jest źródłem producenta, a jej opisy są spójne z definicjami akademickimi przedstawionymi powyżej.

Model przepływu produkcji to osobny przypadek. Symulacja fabryki to kontrolowany model tego, jak praca przemieszcza się przez część zakładu, z uwzględnieniem obowiązujących zasad pracy, zasobów, zleceń i normalnej zmienności. Dzięki temu można przetestować zmianę, na przykład dodatkową zmianę, nową maszynę lub mniejszy bufor, zanim zostanie ona wprowadzona. Sterownik nie jest tu częścią pętli. To symulacja w czystym znaczeniu, która działa znacznie szybciej niż w czasie rzeczywistym.

Cyfrowy bliźniak, czyli utrzymywana cyfrowa reprezentacja fizycznego zasobu, aktualizowana na podstawie obserwacji, może służyć jako model w obu przypadkach. Istotny jest nie sam model, lecz sposób jego wykorzystania: jako samodzielny eksperyment, czyli symulacja, albo połączony z czymś rzeczywistym w czasie rzeczywistym, czyli emulacja.

Emulator czy symulator: którego użyć

Traktuj to jako szybką wskazówkę. To nasze własne podsumowanie, a nie norma.

• Ile zdolności produkcyjnych potrzebujemy i gdzie jest wąskie gardło? Symulacja. Chcesz szybko przebadać wiele scenariuszy.
• Czy program sterujący poradzi sobie z zacięciem, brakującą częścią lub awarią czujnika? Najpierw emulacja programowa.
• Czy rzeczywisty sterownik spełnia wymagania dotyczące czasów i interfejsów? Hardware in the loop albo test na rzeczywistym urządzeniu. Duque Anton i współautorzy twierdzą, że prawdziwy sprzęt daje najbardziej realistyczne wyniki, ale jest najtrudniejszy do przygotowania.
• Czy można przeszkolić operatorów przed uruchomieniem? Emulacja. Model podłączony do rzeczywistego panelu sterowania zachowuje się tak, jak zrobiłaby to maszyna.
• Który z dwóch układów jest lepszy? Symulacja.

Pojedynczy projekt często wymaga obu. Najpierw symulacja określa wydajność linii. Potem emulacja testuje program sterujący dla tej linii.

Przykład: jedna linia pakująca, dwa pytania

To przykład poglądowy, nie zmierzony przypadek. Linia pakująca produkuje 3000 kartonów na godzinę. Zakład zadaje dwa pytania.

Pytanie 1: czy druga etykieciarka podniesie wydajność do 3600 kartonów na godzinę? To pytanie do symulacji. Model produkcyjny przechodzi jedną 8-godzinną zmianę w około 2 minuty, czyli 240 razy szybciej niż w czasie rzeczywistym. Zespół testuje 30 scenariuszy, na przykład różne wielkości partii, rozmiary buforów i wzorce przestojów. Wszystkie 30 przebiegów zajmuje około 60 minut. Te same 30 scenariuszy w czasie rzeczywistym zajęłoby 30 × 8 godzin = 240 godzin, czyli 30 dni roboczych. Testy w czasie rzeczywistym nie wchodzą w grę dla tego pytania.

Pytanie 2: czy program sterujący poradzi sobie z zacięciem kartonu na etykieciarce? To pytanie do emulacji. Program sterujący działa w emulatorze sterownika PLC, a model odgrywa linię. Każdy przypadek awarii trwa w czasie rzeczywistym około 5 minut i nie można go przyspieszyć, ponieważ timery programu zależą od rzeczywistego czasu. Dwanaście przypadków awarii zajmuje około 60 minut. To niewiele w porównaniu z wykryciem błędu obsługi zacięcia podczas uruchomienia na prawdziwej linii.

Oba testy zajmują około godziny i odpowiadają na różne pytania. Szybka symulacja nie pokaże, czy timery sterowania działają poprawnie, a emulacja w czasie rzeczywistym nie pozwoli przetestować 30 scenariuszy w ciągu jednego dnia.

Częste błędy

• Traktowanie tych słów jako synonimów w specyfikacji. Dostawca, który oferuje „symulację”, może dostarczyć czysty model, a Państwu były potrzebne testy sterowania.
• Ocena czasu sterowania na podstawie symulacji. Model działający szybciej niż w czasie rzeczywistym nic nie mówi o timerach i komunikacji.
• Przyspieszanie emulacji. Wyniki są błędne, gdy timery sterowania nie nadążają.
• Zbyt szczegółowe modele. Model z każdym kablem i śrubą pochłania wysiłek, którego pytanie nie wymaga.
• Traktowanie emulatora jak rzeczywistego sterownika. Emulacja sterownika nie jest sterownikiem PLC. Zaplanuj sprawdzenie czasów i interfejsów na rzeczywistym sprzęcie.
• Brak testu odbiorczego na rzeczywistej linii. Zaliczony test wirtualny obniża ryzyko, ale go nie eliminuje.

Jak oprogramowanie może pomóc

Narzędzia do obu zastosowań istnieją. Modele przepływu produkcji działają w oprogramowaniu do symulacji, a testy sterowania wykorzystują emulację PLC i modele maszyn. Zapytaj dostawcę, co działa w czasie rzeczywistym, co jest rzeczywiste, a co zamodelowane. W przypadku testów oprogramowania kodu sterującego zapytaj, jak testy są automatyzowane i rejestrowane, aby przebieg testu można było powtórzyć po każdej zmianie programu. Zapytaj o interfejs do Państwa platformy PLC oraz o nakład pracy potrzebny na zbudowanie modelu. Oprogramowanie nie rozstrzygnie za Państwa, o jakie pytanie warto zapytać, a jasno sformułowane pytanie to najlepszy sposób, by wybrać między tymi dwoma podejściami.

Kolejny krok

W następnym projekcie automatyzacji zapisz każdy test, który chcesz wykonać, w formie pytania, i oznacz każdy jako „wiele scenariuszy, szybko” albo „rzeczywiste sterowanie, czas rzeczywisty”. Następnie użyj tej listy, aby zdecydować między symulacją a emulacją, zanim poprosisz o wyceny.