Simulation ou émulation en automatisation : quelle est la différence ?

Par Mirko Peters · 2026-11-11

Simulation ou émulation en automatisation : la simulation modélise le comportement d’un système, l’émulation se substitue à un élément réel et s’exécute en temps réel. Voyez quand utiliser chacune.

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

En automatisation, une simulation est un modèle qui reproduit le comportement d’un système, souvent plus vite que le temps réel, afin d’explorer des options. Une émulation remplace une partie du système réel par un modèle, ou imite un équipement, de sorte que l’élément réel fonctionne avec elle comme s’il était connecté au système réel, et elle s’exécute en temps réel. Ce guide s’adresse aux responsables de l’excellence opérationnelle qui lisent des devis et des plans de projet où les deux termes sont mélangés, par exemple dans la mise en service virtuelle. Vous y découvrirez les définitions, les usages de chacune, la place du software in the loop et du hardware in the loop, ainsi qu’un exemple détaillé avec les durées d’exécution.

Points clés

• Une simulation modélise le comportement d’un système et peut s’exécuter plus vite que le temps réel ; une émulation remplace une partie du système réel par un modèle, ou imite un équipement, et s’exécute en temps réel.
• Utilisez la simulation pour explorer des options de conception, des implantations, la capacité et les stratégies de commande ; utilisez l’émulation pour tester la logique de commande face à un modèle d’installation et pour former les équipes.
• L’émulation ne peut pas être accélérée, car les temporisations et les communications du contrôleur dépendent du temps réel : elle se prête mal à l’exécution de nombreux scénarios.
• Le software in the loop et le hardware in the loop sont des configurations d’émulation : le code de commande réel ou un contrôleur réel fonctionne avec une installation simulée.
• Ces termes sont souvent employés sans rigueur : avant d’accepter un devis ou une spécification, demandez ce qui s’exécute en temps réel, ce qui est réel et ce qui est modélisé.

Simulation ou émulation : la réponse courte

Les termes se chevauchent, et la littérature le reconnaît. L’émulation comme la simulation créent un environnement virtuel dans lequel vous pouvez déboguer et tester avant de toucher au matériel physique. Un rapport de terrain sur la simulation de réseaux industriels, signé par Duque Anton et ses coauteurs et disponible sur arXiv, indique que la simulation vise à imiter les états d’un système et que l’émulation vise à reproduire son comportement. Les auteurs remarquent que les deux mots sont souvent utilisés indifféremment, et qu’ils emploient « simulation » de façon générale parce que de nombreux outils savent faire les deux.

Une définition plus pratique vient d’Ian McGregor, dans un article pour la 2002 Winter Simulation Conference. Il définit un modèle d’émulation comme un modèle dont une partie fonctionnelle est assurée par une partie du système réel ; et la réciproque est vraie aussi : une partie du système réel est remplacée par un modèle. McGregor travaillait pour une entreprise qui commercialise des outils d’émulation, il faut donc lire ses affirmations en en tenant compte. La définition elle-même se vérifie facilement sur n’importe quel projet.

En termes simples, la distinction utile en automatisation est la suivante :

• La simulation est un modèle de l’ensemble du système, que vous exécutez seul. Vous modifiez les entrées et observez ce qui se passe, et vous pouvez l’exécuter rapidement. Vous pouvez simuler la demande, les arrêts et les effectifs, et construire un prototype d’implantation dans le modèle avant que quoi que ce soit ne soit construit.
• L’émulation relie un élément réel à un modèle. L’élément réel peut être un programme de commande, un automate ou un panneau opérateur, et le modèle joue le rôle de la machine ou de l’installation qui l’entoure. Comme un élément réel est impliqué, l’exécution prend un temps réel.

La même différence apparaît dans les outils : la distinction entre émulateur et simulateur tient à ce qu’ils reproduisent. Un simulateur peut simuler l’installation ou la logique du programme de l’automate dans un modèle. Un émulateur cherche à reproduire le fonctionnement de l’automate réel, jusqu’au comportement de son processeur et à ses communications, de sorte que le code réel puisse s’y exécuter et reproduire ce qu’il ferait sur le matériel cible. En pratique, les éditeurs désignent souvent un émulateur ou un simulateur d’automate PLC par l’un ou l’autre terme ; vérifiez donc ce que recouvre réellement l’étiquette. Les simulateurs et émulateurs d’un même automate peuvent différer fortement quant à la fidélité avec laquelle ils reproduisent le système cible.

Cas d’usage : à quoi servent chacun dans l’automatisation

McGregor décrit les cas d’usage typiques. Les modèles de simulation servent à tester et à développer différentes solutions afin de trouver la meilleure. Ils permettent d’explorer des options de conception, l’agencement, les limites de fonctionnement et la stratégie de commande. Ils s’exécutent rapidement, souvent plus vite que le temps réel, et sont reproductibles tant que les paramètres ne changent pas. Ils conviennent donc à de nombreuses expérimentations et à l’optimisation automatisée.

Les modèles d’émulation servent à tester la logique du système de commande dans différentes conditions de charge, à vérifier le comportement de la commande avant la mise en service, et à former les opérateurs et le personnel de maintenance. Ils fonctionnent en temps réel, le système de commande étant connecté de l’extérieur.

McGregor énumère aussi les limites. Les modèles d’émulation se prêtent mal aux expérimentations, car ils ne fonctionnent souvent qu’en temps réel. Les exécuter plus vite que le temps réel génère des erreurs, car les temporisateurs du système de commande ne peuvent pas s’adapter. Les résultats sont par ailleurs moins reproductibles, la communication entre le modèle et l’automate étant asynchrone et dépendant du réseau et du système d’exploitation.

Duque Anton et ses coauteurs formulent un constat similaire, vu de l’autre côté. La simulation est efficace en coût, en ressources et en temps, mais chaque caractéristique physique doit être modélisée, ce qui demande parfois beaucoup d’efforts. L’émulation est, par conception, aussi précise que le système de production lorsque l’environnement est réel, mais elle nécessite davantage d’équipements et d’espace, et coûte plus cher. Leur conclusion est qu’il n’existe pas de solution générale répondant à toutes les exigences.

Software in the loop, hardware in the loop et le jumeau numérique

Dans les projets d’automatisation, les deux notions se rejoignent dans les tests « in the loop ». La page de l’éditeur realvirtual les décrit :

• Software in the loop : le programme de commande s’exécute comme un logiciel sur un PC, par exemple dans un émulateur d’automate PLC, et fonctionne avec le modèle de la machine. Aucun matériel n’est nécessaire.
• Hardware in the loop : un automate PLC réel se connecte au modèle de la machine via un réseau. Le matériel réel pilote une machine virtuelle.

Ces deux approches sont des émulations au sens de McGregor, puisqu’un élément réel, le code de commande ou l’automate, fonctionne avec un modèle du reste. Elles sont au cœur de la mise en service virtuelle. La page est une source éditeur, et ses descriptions sont cohérentes avec les définitions académiques ci-dessus.

Un modèle de flux de production est un cas différent. La simulation d’usine est un modèle contrôlé de la façon dont le travail circule dans une partie de l’usine, à partir des règles de fonctionnement actuelles, des ressources, des commandes et des variations normales. Elle permet ainsi de tester un changement, comme une équipe supplémentaire, une nouvelle machine ou un stock tampon réduit, avant de le mettre en œuvre. Aucun automate n’est dans la boucle. Il s’agit d’une simulation au sens strict, qui s’exécute bien plus vite que le temps réel.

Un jumeau numérique, c’est-à-dire une représentation numérique maintenue d’une ressource physique, mise à jour à partir des observations, peut servir de modèle dans les deux cas. Ce qui compte n’est pas le modèle, mais la manière de l’utiliser : en expérimentation autonome, il s’agit d’une simulation ; connecté à un élément réel en temps réel, il s’agit d’une émulation.

Émulateur ou simulateur : lequel choisir

Utilisez ceci comme guide rapide. Il s’agit de notre propre synthèse, et non d’une norme.

• De quelle capacité avons-nous besoin, et où se trouve le goulot d’étranglement ? Simulation. Vous voulez de nombreux scénarios, rapidement.
• Le programme de commande gère-t-il un bourrage, une pièce manquante ou un défaut de capteur ? D’abord une émulation, logicielle.
• Le contrôleur réel respecte-t-il ses exigences de temporisation et d’interface ? Hardware in the loop, ou un test sur l’équipement réel. Duque Anton et ses coauteurs estiment que le matériel réel donne les résultats les plus réalistes, mais qu’il est le plus difficile à mettre en place.
• Peut-on former les opérateurs avant la mise en service ? Émulation. Un modèle connecté au vrai pupitre de commande se comporte comme la machine le ferait.
• Laquelle de deux implantations est la meilleure ? Simulation.

Un même projet a souvent besoin des deux. D’abord une simulation dimensionne la ligne. Ensuite une émulation teste le programme de commande de cette ligne.

Exemple : une ligne de conditionnement, deux questions

Il s’agit d’un exemple illustratif, et non d’un cas mesuré. Une ligne de conditionnement produit 3 000 cartons par heure. L’usine pose deux questions.

Question 1 : un second étiqueteur fera-t-il passer la production à 3 600 cartons par heure ? C’est une question de simulation. Un modèle de production simule une équipe de 8 heures en environ 2 minutes, soit 240 fois plus vite que le temps réel. L’équipe teste 30 scénarios, par exemple différentes tailles de lots, différentes capacités de tampons et différents profils d’arrêt. Les 30 simulations prennent environ 60 minutes. Les mêmes 30 scénarios en temps réel demanderaient 30 × 8 heures = 240 heures, soit 30 jours ouvrés. Des essais en temps réel ne sont pas envisageables pour cette question.

Question 2 : le programme de commande gère-t-il un bourrage de cartons au niveau de l’étiqueteur ? C’est une question d’émulation. Le programme de commande tourne sur un émulateur d’automate programmable, et le modèle joue le rôle de la ligne. Chaque cas de défaut dure environ 5 minutes en temps réel et ne peut pas être accéléré, car les temporisateurs du programme dépendent du temps réel. Douze cas de défaut prennent environ 60 minutes. C’est peu coûteux, comparé à la découverte d’une erreur de gestion de bourrage lors de la mise en service sur la ligne réelle.

Les deux essais prennent environ une heure chacun et répondent à des questions différentes. Une simulation rapide ne peut pas montrer si les temporisateurs de commande fonctionnent, et une émulation en temps réel ne permet pas de tester 30 scénarios en une journée.

Erreurs courantes

• Utiliser les termes comme synonymes dans un cahier des charges. Un fournisseur qui propose une « simulation » peut livrer un modèle pur, alors que vous aviez besoin de tests de commande.
• Juger la temporisation de commande à partir d’une simulation. Un modèle qui tourne plus vite que le temps réel ne dit rien des temporisateurs ni de la communication.
• Accélérer une émulation. Les résultats sont faux lorsque les temporisateurs de commande ne peuvent pas suivre.
• Des modèles trop détaillés. Un modèle qui intègre chaque câble et chaque boulon coûte un effort que la question ne justifie pas.
• Considérer l’émulateur comme le contrôleur réel. L’émulation du contrôleur n’est pas l’automate. Prévoyez une vérification sur le matériel réel pour la temporisation et les interfaces.
• Pas de test de réception sur la ligne réelle. Un test virtuel réussi réduit le risque. Il ne le supprime pas.

Comment le logiciel peut aider

Des outils existent pour les deux usages. Les modèles de flux de production tournent dans des logiciels de simulation, et les tests de commande s’appuient sur l’émulation d’automates et sur des modèles de machines. Demandez à votre fournisseur ce qui tourne en temps réel, ce qui est réel et ce qui est modélisé. Pour les tests logiciels du code de commande, demandez comment les tests sont automatisés et enregistrés, afin qu’un essai puisse être rejoué après chaque modification du programme. Demandez l’interface avec votre plateforme d’automates ainsi que l’effort nécessaire pour construire le modèle. Le logiciel ne choisit pas à votre place la question à poser, et une question bien formulée reste le meilleur moyen de choisir entre les deux.

Étape suivante

Pour votre prochain projet d’automatisation, rédigez chaque test souhaité sous forme de question, et classez chacune comme « nombreux scénarios, rapide » ou « commande réelle, temps réel ». Utilisez ensuite cette liste pour trancher entre simulation et émulation avant de demander des devis.