Commissioning virtuel : fonctionnement et conditions de rentabilité

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

Par Mirko Peters · 2026-11-11

Le commissioning virtuel teste le logiciel de commande sur un modèle virtuel avant la mise en service. Découvrez son fonctionnement, ce que disent les données disponibles et quand il devient rentable pour une usine.

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

Le commissioning virtuel consiste à tester le logiciel de commande réel d’une machine ou d’une installation sur un modèle virtuel, avant que l’équipement ne soit construit ou mis en service. Il est rentable lorsqu’un jour de retard à la mise en service coûte cher ou que la logique de commande est complexe, mais il ne l’est pas pour chaque projet. Ce guide s’adresse aux responsables d’usine qui doivent décider s’il faut le demander. Vous y découvrirez son fonctionnement, les trois niveaux de test, ce que disent les données disponibles sur les gains de temps, un exemple de seuil de rentabilité chiffré et les erreurs à éviter.

Points clés

• Le commissioning virtuel relie le logiciel de commande réel, comme un programme d’automate programmable (API), à un modèle simulé de la machine. La logique, les signaux et les séquences sont ainsi testés avant la mise en service de l’équipement.
• Le modèle doit intégrer à la fois la géométrie, la cinématique et l’interface électrique avec le contrôleur. Sa valeur dépend de la fidélité de sa reproduction du comportement réel.
• Les gains de temps annoncés sont importants, mais ils proviennent de petites expérimentations et de pages de fournisseurs. Prévoyez donc une hypothèse prudente et ne considérez pas ce gain comme garanti.
• Il est rentable lorsqu’un jour de retard au démarrage coûte cher, que la logique de commande est complexe, ou que le modèle peut être réutilisé pour la formation et les évolutions ultérieures.
• Il répond à une question différente de celle d’une simulation de production : il vérifie que la commande fonctionne, et non ce que le système peut produire.

Commissioning virtuel : définition et fonctionnement

Dans un commissioning traditionnel, le logiciel de commande rencontre la machine pour la première fois sur site. Les erreurs de logique, de signaux et de séquences coûtent alors du temps en atelier, où chaque heure de retard est onéreuse. Le commissioning virtuel déplace cette première rencontre au bureau, dans un environnement virtuel où le modèle peut simuler capteurs, variateurs et pièces. Pour un projet d’automatisation, cela signifie résoudre les problèmes à un stade précoce, quand une correction reste peu coûteuse. Un article de Matthias Schamp et de ses collègues de l’université de Gand et de Flanders Make, publié dans Procedia Manufacturing en 2019, le décrit comme la reproduction du comportement du matériel dans un environnement logiciel, afin de valider la logique de commande avant la mise en œuvre réelle. Les composants virtuels nécessitent un modèle mécanique, avec géométrie et cinématique, ainsi qu’un modèle électrique qui couvre l’interaction avec l’automate programmable.

Concrètement, la démarche se déroule ainsi :

1. Construire le modèle de la machine ou de l’installation : les pièces mobiles, les capteurs et les actionneurs.
2. Nommer les signaux du modèle de la même manière que dans le programme de commande, afin que le contrôleur perçoive le modèle comme il percevrait l’équipement réel.
3. Relier le logiciel de commande au modèle. Le programme d’automate réel s’exécute, et le modèle réagit.
4. Tester les séquences et les défaillances. Exécutez des cycles normaux, puis déclenchez des incidents tels qu’une pièce manquante, une panne de capteur ou un blocage, dont le test sur un équipement réel est risqué ou long.
5. Corriger les erreurs au bureau, puis transférer le programme corrigé sur site.

La qualité du résultat dépend de la proximité entre le modèle et le comportement réel. L’article de Schamp indique que le modèle numérique doit se comporter comme le système de production réel, et il cite l’effort de modélisation et la dépendance à l’expertise comme des défis non résolus.

Trois niveaux de test : model-in-the-loop, software-in-the-loop et hardware-in-the-loop

Le test peut être réalisé à différents niveaux, selon l’étape du projet. La page du fournisseur realvirtual, qui commercialise un logiciel de mise en service virtuelle, décrit trois boucles :

• Model-in-the-loop couple des modèles de comportement, par exemple issus d’un outil de simulation, au modèle de la machine. Il convient aux entraînements et aux procédés avant l’existence de tout code d’automate.
• Software-in-the-loop exécute le contrôleur sous forme de logiciel sur un PC, de sorte que le test complet ne nécessite ni câblage ni matériel. Il convient aux tests précoces et se déploie facilement.
• Hardware-in-the-loop relie un automate réel au modèle via le réseau. Il est plus proche du système final et permet de vérifier le comportement et la synchronisation du matériel réel.

Un billet de blog de Siemens, fournisseur, décrit les mêmes deux modes, software-in-the-loop et hardware-in-the-loop, pour son outil de simulation d’usine. La différence entre simulation et émulation, qui compte ici, mérite un traitement à part. Pour un responsable de site de production, l’essentiel est le suivant : commencer par le logiciel, puis ajouter du matériel réel lorsque le projet atteint l’étape où la synchronisation et les interfaces deviennent déterminantes.

Ce que disent les données sur les gains de temps

Les gains annoncés sont importants, mais la qualité des preuves varie ; il faut donc lire les chiffres avec prudence.

• L’article de Schamp cite une expérience antérieure à petite échelle qui faisait état d’une réduction de 73 % du temps de mise en service réelle et d’une amélioration de 31 % des exigences satisfaites avant la mise en service réelle, grâce à une approche par modèle numérique. Les auteurs soulignent qu’il est difficile de comparer les approches, car une mise en service ne peut avoir lieu qu’une seule fois.
• La page de realvirtual indique que le temps de mise en service sur site peut être réduit jusqu’à 75 %, et que la part des fonctions de commande qui fonctionnent dès la première tentative est passée de 37 % à 84 %. Elle s’appuie sur une étude de terrain de l’Université technique de Munich. Elle précise également que ces 75 % ne constituent pas un résultat garanti pour chaque projet. Il s’agit donc d’une source émanant d’un fournisseur, qui cite un tiers.
• Le billet de blog de Siemens avance lui aussi des gains importants, mais il fournit peu de chiffres vérifiables.

La tendance est donc cohérente, mais l’ampleur reste incertaine. Pour la planification, retenez une hypothèse prudente, par exemple un quart du temps sur site, et vérifiez-la lors de votre premier projet.

Un terme apparenté est le jumeau numérique : une représentation numérique maintenue à jour d’une ressource physique, alimentée par des observations. Dans les projets Industrie 4.0, le jumeau et le modèle de mise en service sont souvent évoqués ensemble, mais ce ne sont pas la même chose. Un modèle construit pour la mise en service virtuelle est souvent un modèle de test ponctuel, par exemple pour une seule ligne d’assemblage. S’il est tenu à jour, il peut devenir un jumeau, puis servir à la formation et à tester les modifications ultérieures. Cette réutilisation est l’un des principaux leviers de rentabilisation de l’investissement.

Exemple : à partir de quand cela devient-il rentable ?

Il s’agit d’un calcul illustratif, et non d’un cas mesuré. Une nouvelle ligne nécessite 30 jours de mise en service sur site. La construction du modèle virtuel coûte 25 jours d’ingénierie à 800, soit 20 000, auxquels s’ajoutent 15 000 pour les logiciels et licences, soit 35 000 au total. Un jour de retard au démarrage coûte 8 000, correspondant aux équipes sur site et à la marge perdue.

Supposons que l’équipe planifie de façon prudente et table sur une économie de 25 % du temps sur site, soit 7,5 jours.

• Gain : 7,5 × 8 000 = 60 000.
• Coût : 35 000.
• Gain net : environ 25 000.

Le seuil de rentabilité est de 35 000 ÷ 8 000 = 4,4 jours, soit environ 15 % des 30 jours. Si le temps gagné est inférieur à ce seuil, le modèle ne se rentabilise pas sur cette seule ligne.

Modifions maintenant une hypothèse. Si un jour de retard ne coûte que 3 000, les mêmes 7,5 jours représentent 22 500, soit moins que les 35 000. Le projet ne se rentabilise pas dès la première ligne, sauf si le modèle est réutilisé. Si ce même modèle sert aussi à la formation des opérateurs et à deux modifications ultérieures qui auraient chacune coûté deux jours de tests à 3 000, la réutilisation ajoute 12 000. Le bénéfice total s'élève alors à environ 34 500, ce qui est proche du seuil de rentabilité.

L'idée est que la décision repose sur trois chiffres : le coût d'un jour de retard, la part de jours que vous espérez économiser et la réutilisation du modèle. Comparez-les avant le démarrage du projet.

Tests de commande et tests de production : deux types de simulation

La mise en service virtuelle est parfois confondue avec la simulation de production, car les deux utilisent un modèle. Elles répondent toutefois à des questions différentes. La distinction habituelle est la suivante : la simulation étudie le comportement d'un système et ce qu'il peut produire, alors qu'ici l'objectif est de vérifier que la commande fonctionne correctement.

La simulation d'un système de production permet de savoir si l'installation atteindra le rendement visé. iFAKT's Polaris Simulator, par exemple, est un module d'iFAKT Polaris qui teste virtuellement le système de production, notamment à travers des scénarios de capacité, de dotation en personnel et de stocks tampons, et qui révèle les goulots d'étranglement avant toute modification. Il s'agit d'une question de flux et de capacité, et non d'un test du code de l'automate programmable (API). Les deux approches ne se remplacent pas : une ligne peut disposer d'un programme de commande très bien testé tout en étant mal conçue, et inversement. Les deux tests répondent à des questions différentes ; ils doivent donc intervenir à des moments différents du projet.

Comment lancer un projet d'automatisation en cinq étapes

Cette séquence est un outil de planification que nous avons conçu nous-mêmes ; il ne s'agit pas d'une norme.

1. Choisissez un projet à fort coût de retard ou dont la logique de commande est complexe et nouvelle. Une machine simple que vous avez déjà construite de nombreuses fois constitue un mauvais premier cas.
2. Définissez les questions. Quelles séquences, quels verrouillages et quels cas de défaillance doivent être testés ? Le périmètre détermine l'effort de modélisation.
3. Convenez du niveau de détail. Le modèle doit être aussi simple que les questions le permettent. Un modèle trop fin coûte du temps ; un modèle trop grossier laisse passer des erreurs.
4. Choisissez le niveau de test. Commencez par le software in the loop. Ajoutez le matériel lorsque la synchronisation ou les interfaces sont déterminantes.
5. Testez, documentez et conservez le modèle. Consignez les erreurs détectées, transférez le programme corrigé sur site et désignez ensuite un responsable du modèle.

Erreurs courantes

• Démarrer trop tard. Si le code de commande est terminé et livré, il reste peu de choses à tester.
• Mauvais niveau de détail. Un modèle trop grossier laisse passer des erreurs, et un modèle trop fin retarde le projet.
• Signaux qui ne correspondent pas. Si les noms des signaux du modèle diffèrent de ceux de l'installation réelle, vous testez un autre programme.
• Considérer un test réussi comme une preuve. Le modèle n'est pas la machine. Prévoyez du temps pour la vérification sur site.
• Compter sur le pourcentage annoncé. Même le fournisseur reconnaît que son chiffre n'est pas garanti pour chaque projet.
• Aucun responsable après le projet. Un modèle que personne ne maintient est obsolète dès la première modification.

Comment les logiciels peuvent aider

Les logiciels de simulation destinés à ce type de travail vont des suites de simulation de processus industriels aux extensions de moteurs de jeu vidéo, et nombre d'entre eux se connectent aux plateformes d'automates courantes. Vérifiez les interfaces avec votre contrôleur, l'effort nécessaire pour construire et nommer les signaux, et la possibilité de réutiliser le modèle par la suite. Un outil ne vaut que par le modèle que vous construisez avec lui, et c'est la construction de ce modèle qui représente la plus grande partie du coût.

Étape suivante

Listez vos trois prochains projets d'investissement, estimez le coût d'un jour de retard de mise en service pour chacun, et comparez-le au coût d'un modèle. Retenez comme projet pilote celui pour lequel la mise en service virtuelle a le plus de chances d'être rentable.