Simulazione vs emulazione nell'automazione: qual è la differenza?

By Mirko Peters · 2026-11-11

Simulazione vs emulazione nell'automazione: la simulazione modella il comportamento di un sistema, l'emulazione sostituisce una parte reale e gira in tempo reale. Scopri quando usare l'una o l'altra.

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

Nell'automazione, una simulazione è un modello che riproduce il comportamento di un sistema, spesso più veloce del tempo reale, per esplorare alternative. Un'emulazione sostituisce una parte del sistema reale con un modello, o imita un dispositivo, così che la controparte reale lavori con esso come se fosse collegata alla realtà, e gira in tempo reale. Questa guida è pensata per i responsabili dell'eccellenza operativa che leggono preventivi e piani di progetto in cui i due termini si mescolano, ad esempio nel virtual commissioning. Imparerai le definizioni, a cosa serve ciascuna, come si inseriscono il software e l'hardware in the loop, e un esempio svolto con i tempi di esecuzione.

Punti chiave

• Una simulazione modella il comportamento di un sistema e può girare più veloce del tempo reale; un'emulazione sostituisce una parte del sistema reale con un modello, o imita un dispositivo, e gira in tempo reale.
• Usa la simulazione per esplorare opzioni di progetto, layout, capacità e strategie di controllo; usa l'emulazione per testare la logica di controllo su un modello di impianto e per formare il personale.
• L'emulazione non può essere accelerata, perché timer di controllo e comunicazioni dipendono dal tempo reale, quindi è uno strumento poco adatto a eseguire molti scenari.
• Il software in the loop e l'hardware in the loop sono configurazioni di emulazione: il codice di controllo reale o un controllore reale lavorano con un impianto simulato.
• I termini sono spesso usati in modo approssimativo, quindi chiedi che cosa gira in tempo reale, che cosa è reale e che cosa è modellato prima di accettare un preventivo o una specifica.

Simulazione vs emulazione: la risposta breve

I termini si sovrappongono, e la letteratura lo ammette. Emulazione e simulazione creano entrambe un ambiente virtuale in cui fare debug e test prima di toccare l'hardware fisico. Un report sulla simulazione delle reti industriali di Duque Anton e coautori, disponibile su arXiv, afferma che la simulazione mira a imitare gli stati di un sistema e l'emulazione a riprodurne il comportamento. Gli autori osservano che i due termini sono spesso usati come sinonimi, e che usano "simulazione" in senso generale perché molti strumenti possono fare entrambe le cose.

Una definizione più pratica viene da Ian McGregor, in un articolo per la Winter Simulation Conference del 2002. Egli definisce un modello di emulazione come un modello in cui una parte funzionale è svolta da una parte del sistema reale, e vale anche il contrario: una parte del sistema reale è sostituita da un modello. McGregor lavorava per un'azienda che vende strumenti di emulazione, quindi valuta le sue affermazioni tenendolo presente. La definizione in sé, però, è facile da verificare su qualsiasi progetto.

In parole semplici, la distinzione pratica nell'automazione è questa:

• La simulazione è un modello dell'intero sistema che si esegue da solo. Si modificano gli input e si osserva che cosa succede, e può girare velocemente. Puoi simulare domanda, fermi e personale, e puoi costruire un prototipo di un layout nel modello prima che qualcosa venga realizzato.
• L'emulazione collega qualcosa di reale a un modello. La parte reale può essere un programma di controllo, un controller o un pannello operatore, e il modello simula la macchina o l'impianto che gli sta intorno. Poiché è coinvolto qualcosa di reale, l'esecuzione richiede tempo reale.

La stessa differenza emerge negli strumenti, dove la distinzione tra emulatore e simulatore dipende da ciò che replicano. Un simulatore può simulare l'impianto o la logica del programma del controller in un modello. Un emulatore cerca di emulare le funzionalità del controller reale, fino al comportamento della CPU e alla comunicazione, in modo che il codice reale possa girarvi sopra e riprodurre ciò che farebbe sull'hardware di destinazione. In pratica, i fornitori spesso chiamano un emulatore o un simulatore di PLC con l'uno o l'altro nome, quindi verifica cosa c'è dietro l'etichetta. Simulatori ed emulatori per lo stesso controller possono differire molto nel modo in cui riproducono il sistema di destinazione.

Casi d'uso: a cosa serve ciascuno nell'automazione

McGregor descrive i casi d'uso tipici. I modelli di simulazione servono a testare e sviluppare diverse soluzioni per trovare la migliore. Esplorano opzioni di progetto, layout, limiti operativi e strategia di controllo. Girano velocemente, spesso più veloci del tempo reale, e sono ripetibili quando i parametri non cambiano. Questo li rende adatti a molti esperimenti e all'ottimizzazione automatica.

I modelli di emulazione servono a testare la logica del sistema di controllo in diverse condizioni di carico, a verificare il comportamento del controllo prima della messa in servizio e a formare operatori e personale di manutenzione. Girano in tempo reale con il sistema di controllo collegato dall'esterno.

McGregor elenca anche i limiti. I modelli di emulazione sono poco adatti agli esperimenti perché spesso girano solo in tempo reale. Eseguirli più veloci del tempo reale provoca errori, perché i timer del sistema di controllo non riescono ad adattarsi. Anche i risultati sono meno ripetibili, poiché la comunicazione tra modello e controller è asincrona e dipende dalla rete e dal sistema operativo.

Duque Anton e coautori arrivano a un punto simile da un'altra prospettiva. La simulazione è efficiente in termini di costi, risorse e tempi, ma ogni caratteristica fisica deve essere modellata, operazione che a volte richiede molto impegno. L'emulazione è per sua natura accurata quanto il sistema produttivo, dove l'ambiente è reale, ma richiede più dispositivi e più spazio, e costa di più. La loro conclusione è che non esiste una soluzione generale che soddisfi tutti i requisiti.

Software in the loop, hardware in the loop e il gemello digitale

Nei progetti di automazione, le due idee si incontrano nei test "in the loop". La pagina del fornitore di realvirtual li descrive così:

• Software in the loop: il programma di controllo gira come software su un PC, ad esempio in un emulatore di PLC, e lavora con il modello della macchina. Non serve alcun hardware.
• Hardware in the loop: un PLC reale si collega al modello della macchina tramite rete. L'hardware reale pilota una macchina virtuale.

Entrambi sono emulazioni nel senso di McGregor, perché una parte reale, il codice di controllo o il controller, lavora con un modello del resto. Sono il cuore della messa in servizio virtuale. La pagina è una fonte del fornitore, e le sue descrizioni sono coerenti con le definizioni accademiche riportate sopra.

Un modello di flusso di produzione è un caso diverso. La simulazione di fabbrica è un modello controllato di come il lavoro si muove in una parte dello stabilimento, usando le regole operative attuali, risorse, ordini e la variabilità normale. Così una modifica, come un turno in più, una nuova macchina o un buffer più piccolo, può essere testata prima di essere attuata. Nessun controller è coinvolto nel ciclo. È una simulazione in senso puro e gira molto più veloce del tempo reale.

Un gemello digitale, cioè una rappresentazione digitale mantenuta di una risorsa fisica e aggiornata con le osservazioni, può fungere da modello in entrambi i casi. Ciò che conta non è il modello in sé, ma come lo si usa: come esperimento autonomo, che è una simulazione, oppure collegato a qualcosa di reale in tempo reale, che è un'emulazione.

Emulatore o simulatore: quale usare

Usa questa come guida rapida. È una sintesi nostra, non uno standard.

• Quanta capacità ci serve e dove si trova il collo di bottiglia? Simulazione. Vuoi molti scenari, velocemente.
• Il programma di controllo gestisce un inceppamento, un pezzo mancante o un guasto di un sensore? Prima con un'emulazione via software.
• Il controllore reale rispetta i suoi requisiti di tempistica e di interfaccia? Hardware in the loop, oppure un test sull'impianto reale. Duque Anton e coautori sostengono che l'hardware reale offra i risultati più realistici, ma sia il più difficile da configurare.
• Possiamo formare gli operatori prima dell'avvio? Emulazione. Un modello collegato al pannello di controllo reale si comporta come si comporterebbe la macchina.
• Quale delle due disposizioni è migliore? Simulazione.

Un singolo progetto spesso richiede entrambe. Prima una simulazione dimensiona la linea. Poi un'emulazione verifica il programma di controllo di quella linea.

Esempio: una linea di confezionamento, due domande

Si tratta di un esempio illustrativo, non di un caso misurato. Una linea di confezionamento produce 3.000 cartoni all'ora. Lo stabilimento si pone due domande.

Domanda 1: una seconda etichettatrice porterà la produzione a 3.600 cartoni all'ora? Questa è una domanda da simulazione. Un modello di produzione esegue un turno di 8 ore in circa 2 minuti, cioè 240 volte più velocemente del tempo reale. Il team testa 30 scenari, ad esempio dimensioni diverse dei lotti, dei buffer e schemi di arresto. Le 30 esecuzioni richiedono circa 60 minuti. Gli stessi 30 scenari in tempo reale richiederebbero 30 × 8 ore = 240 ore, ovvero 30 giornate lavorative. Per questa domanda i test in tempo reale non sono un'opzione.

Domanda 2: il programma di controllo gestisce un inceppamento dei cartoni all'etichettatrice? Questa è una domanda da emulazione. Il programma di controllo gira su un emulatore PLC e il modello simula la linea. Ogni caso di guasto richiede circa 5 minuti in tempo reale e non può essere accelerato, perché i timer del programma dipendono dal tempo reale. Dodici casi di guasto richiedono circa 60 minuti. È un costo contenuto rispetto a scoprire un errore nella gestione dell'inceppamento durante l'avvio sulla linea reale.

Entrambi i test richiedono circa un'ora e rispondono a domande diverse. Una simulazione veloce non può mostrare se i timer di controllo funzionano, e un'emulazione in tempo reale non può testare 30 scenari in una giornata.

Errori comuni

• Usare i termini come sinonimi in una specifica. Un fornitore che offre una « simulazione » potrebbe consegnare un modello puro, mentre tu avevi bisogno di test di controllo.
• Giudicare la tempistica di controllo da una simulazione. Un modello che gira più veloce del tempo reale non dice nulla su timer e comunicazione.
• Accelerare un'emulazione. I risultati sono errati quando i timer di controllo non riescono a stare al passo.
• Modelli troppo dettagliati. Un modello con ogni cavo e ogni bullone comporta uno sforzo che la domanda non richiede.
• Considerare l'emulatore come il controllore reale. L'emulazione del controllore non è il PLC. Pianifica una verifica sull'hardware reale per tempistiche e interfacce.
• Nessun test di accettazione sulla linea reale. Un test virtuale superato riduce il rischio. Non lo elimina.

Come può aiutare il software

Esistono strumenti per entrambi gli scopi. I modelli di flusso della produzione girano in software di simulazione, mentre i test di controllo usano emulazione PLC e modelli di macchina. Chiedi al fornitore cosa gira in tempo reale, cosa è reale e cosa è modellato. Per il test software del codice di controllo, chiedi come i test vengono automatizzati e registrati, in modo che un'esecuzione possa essere ripetuta dopo ogni modifica al programma. Chiedi l'interfaccia verso la tua piattaforma PLC e lo sforzo necessario per costruire il modello. Il software non decide al posto tuo quale domanda porre, e una domanda chiara è il modo migliore per scegliere tra le due opzioni.

Prossimo passo

Per il tuo prossimo progetto di automazione, annota ogni test che vuoi come domanda e contrassegna ciascuna come « molti scenari, velocemente » oppure « controllo reale, tempo reale ». Poi usa questo elenco per decidere tra simulazione ed emulazione prima di richiedere le offerte.