Création d'un jumeau numérique d'une micro-usine

Comment prévoir l'imprévisible et empêcher l'impossible ?

C'est la question ouverte sur laquelle j'ai tenté d'apporter des points de réponse pendant un an passé au sein du laboratoire TH-Brandenburg en Allemagne, au sein du département de cybersécurité et de stéganographie.

Les systèmes industriels sont revenus au centre de nos préoccupations au cours des dernières années face au contexte géopolitique tendu que nous subissons, et les récentes cyberattaques sur des sites sensibles n'ont fait qu'accentuer la nécessité de prévoir, anticiper et évaluer les risques et conséquences sur la vulnérabilité et l'exposition des systèmes de contrôle-commande industriels.

Pour prévenir tout risque lié au domaine industriel, nombreuses sont les solutions actuelles qui visent à organiser des exercices de réponse face aux attaques. Mais toutes ces mises en pratique reposent sur un modèle établi qui doit être fidèle à la réalité, ne pouvant se permettre d'être un simulacre approchant de manière approximative le comportement d'un système réel. Quand il s'agit de centrales nucléaires, d'installations électriques, voire même militaires, le droit à l'erreur ne peut exister, et c'est ainsi qu'interviennent les Cyber Ranges (laboratoires virtuels dédiés à la cybersécurité) munis de jumeaux numériques, véritables répliques d'une installation reflétant son état et son comportement en temps réel.

Ayant étudié pendant près de six mois, dans le cadre d'une précédente collaboration avec l'ESAIP, les forces et les faiblesses d'une solution propriétaire de Cyber Range^[1], il m'est paru intéressant de pousser la démarche jusqu'à son terme sur une installation physique réelle en la reproduisant intégralement de manière virtuelle. Au sein du laboratoire IoT de l'université TH-Brandenburg en Allemagne, où s'est déroulé ce projet de fin d'études d'avril à septembre 2026, une maquette industrielle grandeur nature développée par l'entreprise Fischer Technik m'a été mise à disposition. Je bénéficiais ainsi d'un véritable terrain de jeu pour réaliser la réplique d'un système physique en son jumeau informatisé. Au travers de ce projet de recherche, je vous invite à suivre les méandres qui accompagnent la création d'un « jumeau numérique » d'un système industriel physique.

En 2010, l'attaque Stuxnet a levé l'alerte sur le risque de cyberattaques visant les infrastructures industrielles, et depuis cette date la menace n'a cessé de se déplacer des systèmes d'information vers les automates, les capteurs et les actionneurs qui font tourner les usines, les réseaux électriques et les stations de traitement des eaux. En 2024, selon le rapport Dragos^[2], 1693 attaques de ransomwares contre des installations industrielles furent enregistrées, représentant une hausse de 87 % en une année, et c'est ainsi que la compréhension fine des chaînes de contrôle-commande, de leurs protocoles et de leurs faiblesses est devenue une composante impérative de toute démarche de cybersécurité industrielle.

Le projet fut intégré au sein du pôle de recherche en cybersécurité du département "informatique et médias" dirigé par le professeur Claus Vielhauer dont les travaux portent sur la sécurité des systèmes d'information, la forensique et plus spécifiquement la stéganographie et la stéganalyse, en d'autres termes la dissimulation d'informations via des supports numériques ainsi que sa détection. Ces travaux s'inscrivent dans un programme de recherche conjoint d'universités nommé ATTRIBUT qui est dédié à l'attribution des communications stéganographiques. Le laboratoire y développe des méthodes de détection et d'analyse de canaux cachés. La question de la fidélité des flux réseau d'un système industriel répliqué, objet du présent projet de recherche y a parfaitement trouvé place et sens car les jumeaux numériques sont de véritables terrains de jeu pour l'observation de communications dissimulées suivant des protocoles industriels.

Ce projet de fin d'études a emboité le pas d'un projet de recherche que j'avais entamé en septembre 2025 sur les Cyber Ranges et leur utilisation dans le domaine industriel.

Au sein du laboratoire de l'université TH-Brandenburg en Allemagne, j'eus la possibilité d'allier physique et virtuel en ayant à disposition une maquette grandeur nature d'un système industriel piloté par le biais d'un automate programmable PLC. Il nous est venu l'idée avec le groupe de recherche cyber de réaliser un jumeau numérique de l'usine Fischer Technik permettant l'analyse des flux de communication d'un modèle virtuel afin de les comparer aux données d'un modèle physique présent sur site.

L'intérêt de réaliser une telle réplique virtuelle réside dans la diversité des protocoles de communication présents sur la solution physique. L'usine faisant appel aux protocoles de communication industriels tels qu'OPC-UA et MQTT.

En second plan, la multiplicité des solutions physiques présentes telles que des actionneurs liés à un automate programmable Siemens S7-1500, la présence d'une passerelle de communication utilisant des interfaces de communication Low-Code telles que Node-Red et MQTT, ainsi qu'une passerelle OT propriétaire (Fischer Technik TXT) agrégeant MQTT, I2C et des entrées PWM à courant faible, ont renforcé les motivations du projet en y ajoutant une réelle valeur pédagogique sur le caractère universel de la solution, couvrant un grand nombre de technologies utilisées dans les industries existantes.

Au sein du laboratoire IOT de l'université de Brandenburg, mon projet de fin d'études est venu s'inscrire dans la continuité de mes précédents projets de recherches entamés à l'Esaip sur la virtualisation des périphériques en milieux industriels. Ce projet mobilisa les multiples capacités que j'ai pu développer au sein de mon école d'ingénieur, l'ESAIP, au cours des trois dernières années avec notamment :

• L'utilisation de mes compétences en codage sur les systèmes embarqués qui, dans notre cas d'études, s'est majoritairement axée sur le langage automate SCL Siemens puisque la solution avait comme pièce maîtresse un automate Siemens S7-1500.
• L'utilisation de mes compétences en codage Node-Red pour la passerelle de communication réseau.
• L'utilisation de mes compétences en codage sur des systèmes embarqués Raspberry Pi où les codes furent majoritairement écrits en langage Python.
• L'utilisation de mes compétences en rétro-ingénierie pour élaborer une solution de remplacement face au contrôleur propriétaire Fischer Technik TXT.
• L'utilisation de mes compétences en systèmes d'exploitation Linux et de temps réel distribués pour coder les passerelles de capteurs à destination du jumeau numérique créé ainsi que les capteurs d'environnement mesurant température, gaz et humidité dont le comportement fut simulé.
• L'utilisation de mes compétences de codage en C# pour élaborer une passerelle qui simulait le modèle physique de l'usine en collaborant via les points d'entrés de programmes de l'automate Siemens.

Toutes ces compétences ont ainsi permis de construire le jumeau numérique, réplica virtuel de l'usine physique. Cet objectif convenu avec le groupe de recherche permettait ainsi d'élaborer un référentiel pour analyser les communications issues d'un milieu synthétique/virtuel et les comparer à celles provenant du milieu réel physique. Cela demandait ainsi d'obtenir les mêmes protocoles de communication tels qu'OPC UA et MQTT sur le modèle virtuel ainsi que le même comportement de celui-ci face aux perturbations et modes de fonctionnements nominaux.

Les enjeux principaux ont ainsi résidé dans la compréhension exacte de l'usine et son contrôle-commande que Fischer Technik avait peu documenté afin d'en révéler les aspects clefs pour effectuer des choix attenant au modèle de réplication (virtualisation) qui allait être utilisé et celui attenant à la réplication des périphériques physiques et réseau pour obtenir une chaîne de transmission des données aussi fidèle que celle présente dans le monde réel.

Les principaux points bloquants rencontrés furent ainsi liés à la mise en service initiale de la maquette livrée en défaut, la rétro-ingénierie des modules propriétaires et le choix pertinent du protocole de capture des évènements réseau produisant des jeux de données consistants et exploitables. Venait s'ajouter le choix de remplacement d'une solution propriétaire par une solution Open Source où le choix de son architecture de remplacement allait influer directement sur la qualité des données obtenues.

C'est ainsi que le cahier des charges rédigé en avril qui mettait en avant une interface affichant en trois dimensions l'usine répliquée fut réduit à une version plus condensée mais très efficace utilisant un synoptique logique de l'usine en deux dimensions.

La problématique s'inscrivant dans les enjeux et objectifs énoncés précédemment fut la suivante :

Le planning prévisionnel, établi lors de la semaine du 13 au 17 avril, a organisé le projet en neuf groupes de tâches associés à autant de jalons : la prise en main fonctionnelle et technique de l'usine, sa mise en service et sa calibration, l'étude comparative des possibilités de capture des trames, la capture et l'analyse des trames de terrain, la modification du programme automate pour un fonctionnement continu, la conception d'une architecture de virtualisation, la virtualisation elle-même, et enfin la capture et l'exploitation des données issues du modèle virtuel, cette dernière partie étant réalisée par mon collègue Hirama Wohler dans le cadre de son stage. Chaque jalon prévoyait un livrable, documentation, compte rendu ou rapport dont le détail complet des étapes figure en annexe 8.

Le cœur de ce projet de recherche se situe dans la période présentée sur le schéma ci-dessous où les travaux effectués furent les plus intenses en raison de la géométrie variable de leur réussite qui oscillait entre succès et échec.

Selon les recherches d'Ukwandu et al.^[3], augmentées des formalisations du NIST^[4], quatre approches principales peuvent être entreprises afin de concevoir un Cyber Range.
Parmi ces approches, on retrouve :

• La simulation, qui consiste à modéliser le comportement des systèmes de manière mathématique, représentant 50 % des solutions principalement étudiées. Cette approche représente la plus sûre et la moins coûteuse, mais elle se confronte à la difficulté de reproduire de manière fidèle les infrastructures du monde réel.
• L’émulation, qui correspond à la réplication d’opérations d’un système cible au travers d’un système miroir, représentant 38 % des solutions principalement étudiées. Cette approche offre un meilleur niveau de fidélité et de réalisme en simulant à la fois l’infrastructure réelle mais aussi ses comportements nominaux associés comme un trafic et un adressage réseau issus du monde réel.
• L’overlay ou superposition, qui consiste à utiliser tout un réseau et une infrastructure existante où l’on vient superposer des outils de test et d’attaques, représentant 8 % des solutions principalement étudiées. Cette solution s’apparente à celle possédant des niveaux de fidélité des plus optimaux, mais avec une contrepartie financière importante, car elle implique d’avoir de vrais équipements physiques comme des serveurs, systèmes OT, de réseau et de stockage.
• L’approche physique, qui ne représente que 4 % des solutions principalement étudiées, en majeure partie due à ses coûts extrêmement élevés.

Pour une définition formelle, le jumeau numérique (Digital Twin) est une réplique virtuelle d'un système physique reflétant son état et son comportement en temps réel.

À son origine, le jumeau numérique fut développé pour la maintenance prédictive et les optimisations de processus. Son application dans le domaine de la sécurité industrielle est en plein essor, car elle permet la création de copies virtuelles d’infrastructures OT dans l’optique de conduite de tests d’infiltration, de simulations d’attaque et d’analyse de vulnérabilités (pentest) sans en impacter les systèmes de production réels.
Ce concept permet ainsi une réduction de coûts dans les étapes de recherche et développement, mais aussi une facilité d’amélioration de la qualité et de la sécurité des systèmes sur un espace temporel très court.

Si nous devons définir son utilité en cybersécurité en une phrase, le jumeau numérique doit répondre à la règle suivante :

Les travaux de Tao et al. datant de 2019 ont eux recensé les applications industrielles du concept en relevant que la fidélité d'un jumeau numérique se caractérise en mesurant la qualité de la synchronisation entre le jumeau et son modèle réel. Ce qui va beaucoup plus loin qu'un modèle jugé sur des apparences comme un réalisme graphique d'une réplique^[5].

C'est précisément cette caractéristique sur laquelle je me suis mis un point d'honneur à élaborer un jumeau qui ne se contente pas de satisfaire des comportements attendus comme des cases que l'on coche mais bien un jumeau qui simule ses organes physiques et interagit avec suite à une commande de l'automate. Ce qui a permis de mettre en exergue les défauts dont la machine réelle faisait preuve mais aussi d'autres insoupçonnés qui étaient cachés dans le bruit du monde réel.

Sur le plan de la cybersécurité, les travaux d'Eckhart et Ekelhart datant de 2018 ont retenu mon attention car ils faisaient référence à une approche précise, facilement quantifiable et fondée sur la réplication d'état basée sur de la spécification. Les travaux invitaient à faire tourner le programme de contrôle réel sur une réplique dont l'état est aligné sur son étalon physique afin de détecter les déviations et perturbations induites par une attaque en comparant les effets du monde réel à ceux du monde virtuel^[6]. Cette approche fut verbalisée sous forme de typologie d'usage : de la détection d'une intrusion à la validation de correctifs avant leur déploiement en production. Leur insistance sur la valeur d'un jumeau est fondamentale puisqu'elle devint le fer de lance de la simulation développée : le coût d'un jumeau réside dans son maintien en cohérence avec l'installation qu'il représente^[7].

En appliquant cette méthodologie cela a permis de révéler de nombreuses erreurs du programme conçu par FischerTechnik car c'est en comparant la vue de l'automate réel et celle fictive en parcourant chaque caractéristique que j'ai pu déceler de nombreuses fautes de programmation qui étaient muettes dans le monde réel.

En explorant plus en détail la méthodologie proposée, les principaux critères fréquemment utilisés furent la comparaison entre l'état réel et l'état répliqué (ce qui va de soi), la validation de toute modification du programme de contrôle avant tout chargement dans le monde réel et virtuel ainsi que la formation des opérateurs en utilisant des systèmes destructibles à souhait dont l'état peut être remis à zéro à tout instant.

Répliquer une chaîne OT/IT ne se limite pas à simuler un automate : après avoir répliqué le cœur, il faut répliquer les poumons du système, tels que la passerelle Node-RED qui interface les communications de chaque élément de l'usine ainsi que la station de capteurs qui envoie les données d'environnement et d'identification des pièces traitées. Ces deux stations ont une architecture bien précise, celle d'un Raspberry Pi 4 tournant sous un système d'exploitation Linux et utilisant un jeu d'instructions différent de celui des ordinateurs classiques. L'objectif étant de faire tourner leurs logiciels d'origine sans en modifier une ligne : la mise en virtuel de ces éléments nécessitait de reproduire leurs architectures physiques ainsi que leurs programmes.
Une solution s'est imposée : l'émulation de processeur. Celle-ci permet de « répliquer » le comportement d'une architecture précise et de son jeu d'instructions associé. Ainsi les instructions à destination d'une carte Raspberry Pi sous architecture ARM sont traduites en temps réel en celles de l'hôte hébergeant l'émulateur. L'outil utilisé qui est une référence dans son domaine fut QEMU, présenté depuis 2005 et étant open-source^[8]. Cependant toute traduction entraîne un coût qui en l'occurrence rend le Raspberry Pi émulé environ dix fois plus lent que son homologue physique. Cela entraîne des lancements de programmes plus longs et des décalages d'horloge interne, ce qui fut une bataille secondaire menée dans le chapitre dédié à la gestion du temps de ce projet de recherche.

En complément de l'émulation il me fallait répliquer un dialogue inter-composants et plus précisément celui du capteur d'environnement, le Bosch BME680 et celui du lecteur NFC qui utilisaient dans le modèle réel le bus I²C. Au lieu de créer un composant virtuel de A à Z ce qui aurait pris un temps considérable, j'ai préféré utiliser la paravirtualisation permettant de faire dialoguer une machine émulée et un hôte par le biais d'une file de messages partagée. Par ce canal, toute trame est transmise de manière brute et cela permet à un programme présent sur l'hôte de répondre à des requêtes comme le ferait un capteur dans le monde réel. Cette approche utilisée est nommée virtio^[9] et grâce à sa documentation fournie, il fut très facile de concevoir l'émulation des capteurs sur une réplique de bus I²C^[10] puisque cette approche prévoyait dans ses cas d'utilisation une telle communication. La réplication des capteurs fut ainsi basée sur le projet vhost-device de la communauté rust-vmm^[11].
Chaque capteur écrit dans notre cas en Python peut ainsi communiquer sur un bus I²C virtuel ce qui permet de répliquer de manière fidèle son comportement réel. Au fur et à mesure de la conception du jumeau, une constante est venue s'immiscer dans les sources de problèmes. Bien qu'elle nous paraisse évidente, sans référence commune, elle devient un véritable enfer car de nombreux points de contrôle ainsi que d'ordonnancement en dépendent. Cette constante, c'est le Temps ! La solution physique comme virtuelle était répartie en plusieurs organes, celle-ci nécessitait la présence d'une référence temporelle précise et commune à chaque élément. Lamport montrait en 1978 qu'il n'existait pas d'horloge commune dans des systèmes dits « répartis » et que sans précieuse référence temporelle, il fallait reconstruire chaque ordre d'évènements^[12].
Ainsi il nous fallait une référence précise conditionnant toute coordination d'évènements comme le précise Kopetz^[13].
Sur nos machines modernes connectées entre elles et séparées de parfois plusieurs milliers de kilomètres, la question ne se pose presque pas car un serveur central d'horloge atomique utilisant le protocole NTP (Network Time Protocol) donne la cadence. La maquette Fischer Technik elle en dépendait^[14] ce qui souleva le problème d'un passage en environnement clos virtualisé où l'accessibilité de ces serveurs centraux devenait impossible. L'étendue de l'importance du temps fut mesurée lorsque l'automate s'est mis à refuser les commandes issues d'une réponse du lecteur NFC possédant un horodatage antérieur à celui de sa commande. Est venu se rajouter le fonctionnement simulé de l'automate via la solution propriétaire Siemens qui n'avance que suivant le cycle propre de cosimulation modélisant le comportement physique, dans notre cas le pont IoBridge écrit en C#. Il fallait ajouter désormais à la liste des tâches une synchronisation de chaque horloge interne des éléments de l'usine de la passerelle au PLC en passant par la station de capteurs, ce qui ne fut pas une mince affaire.

Cet état de l'art a ainsi pu dresser quelques hypothèses :

• Une correspondant à la fidélité fonctionnelle suivant laquelle un modèle physique des organes d'un système non issu d'un séquençage « brut » est suffisant pour qu'un programme d'automate réel y effectue son cycle complet sans aucune modification de sa logique.
• Une correspondant à la fidélité de protocole suivant laquelle l'émulation des deux cartes Raspberry Pi couplées avec leurs logiciels d'origine produit sur le réseau virtuel les mêmes flux OPC UA et MQTT observés sur le réseau réel.
• Une correspondant à la cohérence temporelle suivant laquelle une chaîne de synchronisation temporelle peut maintenir l'alignement à la seconde des horloges internes des composants virtuels, condition que le programme du monde réel exige.

Le modèle d'usine sur lequel le projet s'est articulé est un démonstrateur développé par la marque allemande Fischer Technik.
Ses avantages sont en lien direct avec les protocoles et méthodes de communications que l'on retrouve en entreprise tels que l'OPC UA largement utilisé à destination des systèmes industriels. L'intérêt d'utiliser une maquette à échelle réduite est son lien direct entre la physique et l'automation permettant à diverses équipes de développement spécialisées dans un domaine de travailler sur un prototype physique concret.
Dans notre cas d'étude le modèle choisi par le pôle de recherche de l'usine de développement fut le modèle Training Factory Industry 4.0 24V équipé du PLC S7-1500.
Ce modèle nous a offert un large panel de solutions industrielles et protocoles de communications associés.

Concernant son principe de fonctionnement voici un résumé du cycle nominal d'usinage d'une pièce :

1. Une pièce de couleur rouge, bleue ou blanche portant un identifiant RFID unique est avancée sur une zone de dépôt (En comparaison avec le monde réel nous parlerions de matière première)
2. Un bras robotique pneumatique vient déplacer cette pièce de la zone de réception à la zone de stockage
3. Un deuxième bras robotique vient ranger cette pièce – matière première dans un emplacement de stockage.
4. Un client / responsable de production effectue une commande d'usinage d'une pièce de couleur précise depuis l'interface de contrôle commande de l'usine.
5. Un robot présent dans la baie de stockage amène la matière première à la zone d'usinage
6. Un bras robotique pneumatique vient prendre la matière première pour l'amener dans la station d'usinage composée d'un four multifonction et d'une fraiseuse
7. Les différentes composantes du produit fini sont transportées à l'aide de convoyeurs et de bras robotiques pneumatiques
8. Le produit fini est ensuite analysé puis trié vers sa zone de transport à l'aide de convoyeurs
9. Le produit fini est déplacé en zone de transport à l'aide du bras pneumatique

La solution technique se compose de cinq modules principaux :

• Le premier correspond au cerveau du système qui est représenté par le contrôleur logique programmable Siemens S7-1500 utilisant des IO physiques couplées au protocole OPC UA pour la chaîne d'acquisition de données et de contrôle commande.
• Le second correspond à une passerelle de communication OPC UA – Node Red – MQTT qui est assurée par une carte Raspberry Pi 4 tournant sous Linux, cette passerelle de communication fait aussi office de serveur Node Red Web affichant une interface graphique permettant de contrôler le procédé industriel en lui-même tel que l’enregistrement de nouvelles pièces au sein de l’usine, le stockage des pièces, la calibration de chaque module respectif et la requête de fabrication d’une pièce particulière. Elle est en communication directe avec le PLC et le contrôleur TXT.
• Le troisième correspond à la solution d'actionneurs et de capteurs Fischer Technik comprenant 4 modules principaux :
• VGR – Vacuum Gripper Robot – Le bras robotique principal acheminant les pièces à usiner sur chaque chaîne d'assemblage et traitement
• HBW – High Bay Warehouse – L'automate de stockage des pièces
• MPS / MPO – Multi Processing Station – Multi Processing Oven - Correspond à une station d’usinage combinée à un four multifonctions
• SL / SLD (Sorting Line – Sorting Line / Sorting Line with color Detection ) – Correspond au triage final des pièces après usinage.

Concernant la chaîne de communication, les éléments communiquent entre eux via un réseau LAN physique et sont interfacés via les protocoles MQTT – OPC/UA et NTP. On notera la présence du protocole NTP car il octroie un horodatage précis des évènements de la chaine capteurs-actionneurs ainsi qu'un référentiel temporel commun pour l'orchestration des tâches concernant la manufacture des pièces. Ce fut tout au long du projet un véritable point clef car dans l'optique d'une virtualisation hors internet, la rupture d'une connexion NTP entraînait le dysfonctionnement total du système, notamment avec l'horodatage des étiquettes NFC attribuées par pièce.

Cette analyse préliminaire a pointé du doigt une particularité propre à la solution développée par Fischer Technik : l'utilisation de plusieurs contrôleurs liées à la chaine directe de contrôle commande. Alors que nos hypothèses préliminaires mettaient uniquement le PLC en relation avec les éléments de commande, sa liaison dépendante du contrôleur TXT pour notamment la lecture des Tags RFID a nécessité le rajout d'une étape de rétro-ingénierie sur son principe de fonctionnement afin de concevoir un protocole de réplication virtuel.

Le présent chapitre rend compte de la réalisation centrale du projet, la réplication virtuelle de l'usine dans laquelle le programme réel de l'automate s'exécute, sans jamais modifier sa logique.

Trois principes ont gouverné l'ensemble des choix :

Le premier visait à obtenir un modèle physique et non un séquenceur : le pont logiciel reliant l'automate virtuel à la mécanique simulée ne reproduit pas une séquence attendue par le programme, bien au contraire, il reproduit fidèlement le comportement de terrain, de sorte qu'un contacteur relâché trop tôt ou une pièce perdue en route produisent exactement le résultat constaté sur la machine réelle.

Le deuxième visait à obtenir une précision accrue sur le code source mis en jeu : tout désaccord entre le modèle conçu et l'automate fut tranché par la lecture du code source, jamais par une adaptation du programme de simulation, ce qui aurait comblé un défaut virtuel sans jamais en connaître la véritable source.

Le troisième mettait en place le principe de consistance et de cohérence avant tout perfectionnement. Chaque modification rapportée dans ce chapitre fut basée sur un élément tangible : une capture réseau, un journal de bord ou une simulation hors ligne de la logique exacte du programme afin que les comportements physiques observés aient leur équivalent dans le monde du jumeau numérique.

Tous ces principes ont imposé la reproduction du fonctionnement physique du système en intégrant ses retards, ses pertes d'impulsions et ses aléas d'horloge. Il a ainsi fallu descendre jusqu'aux données émises par les capteurs en étudiant leurs valeurs brutes puis en « rétro-calculant » leurs formules de conversion internes. Ainsi les trames du lecteur NFC sont reproduites jusqu'à leurs temps de transmission et les Raspberry Pi ne sont pas remplacés par des programmes équivalents mais émulés à partir des images réelles de leurs cartes SD hébergées sur des architectures matérielles simulées afin que leurs logiciels d'origine s'exécutent sans la moindre modification.

La valeur d'un jumeau se traduit par son faible écart de comportement évalué par rapport à son modèle physique. Cela a exigé d'avoir en référence un modèle physique presque parfait. Un modèle physique instable aurait provoqué une amplification des défauts compte tenu de la couche d'abstraction immuable qu'entraîne la virtualisation. Un soin particulier fut donc porté aux caractéristiques de la solution physique avant toute réplication. Les capteurs de positions présents sur chaque axe furent étudiés de fond en comble, de leur modèle proprement physique et mécanique à leur contrôle-commande déclaré dans le code source du PLC. Avoir une donnée erronée traduisant un mouvement physique aurait été catastrophique à répliquer car cela aurait entraîné la production de données analytiques purement inutilisables.

Cette exigence de compréhension et de vérification de la cohérence du code de l'automate face à ses actions physiques au sein de l'usine fut poussée jusqu'aux méthodes de transmission des informations sur une pièce quelconque que l'on retrouve stockées dans des "tags NFC". Le programme d'origine n'exposait leur contenu que sous une forme interprétée ce qui ne permettait pas de capturer des données brutes. En me connectant directement via l'interface I2C de la station de capteurs, décrite au chapitre précédent, j'ai pu relever douze tags réels dont huit à l'état brut et quatre à l'état usiné ce qui a permis de constituer la seule source fiable de tags présentés par le lecteur émulé, de sorte que chaque pièce du jumeau porte l'identifiant et l'historique d'une pièce ayant réellement existé. Il en est allé de même pour les images de la caméra de l'usine qui furent capturées à leur source pour être rejouées au sein du modèle virtuel.

Même le système réel a dû être étendu pour se prêter à la comparaison. Le programme fischertechnik d'origine exécute une commande à la fois et s'arrête sur le bac de sortie jusqu'au retrait de la pièce par un opérateur. La constitution d'un jeu de données de référence exigeant des heures de trafic sans intervention humaine et sans interruption, j'étendis donc le programme du PLC afin d'obtenir un mode de fonctionnement continu.

Cette simple modification a nécessité la refonte de l'ensemble de la chaîne de contrôle-commande de la solution. Il a fallu modifier le comportement de la passerelle Node-Red en accord avec ce nouveau mode de fonctionnement.

La passerelle reçut en regard un onglet de commande automatique qui, sur action d'un opérateur, activait le mode de fonctionnement continu de l'usine avec la gestion aléatoire de pièces de caractéristiques différentes. Ainsi modifiée, la maquette réelle a pu produire pendant plusieurs cycles de 10 minutes (choix effectué pour des raisons d'espace de stockage) le trafic OPC UA et MQTT nécessaire à la constitution d'une banque de données de référence.

L'automate est virtualisé par le biais du logiciel de SIEMENS PLCSIM Advanced V5, en mode dit synchronisé, ce qui octroie au modèle physique sous la forme d'un pont entre le logiciel PLCSIM et la passerelle NodeRed un contrôle parfait du temps de simulation ainsi que des actions qui s'effectuent en ce temps de cycle. Le pont IoBridge, modèle physique de l'usine fut écrit en C# en s'adaptant à l'API publiée par Siemens. À chaque temps de cycle, il effectue dans l'ordre :

• la lecture des sorties de l'automate permettant au modèle physique de connaître l'état actuel de l'automate par le biais de ses commandes.
• l'avancement du modèle physique. Soit les mouvements de chaque automate, leurs états ainsi que ceux attenants aux pièces.
• l'écriture des entrées telles que celles correspondant à des barrières infrarouges permettant de localiser la position absolue des pièces en des endroits précis
• l'écriture des sorties (en parallèle de celle des entrées) telles que celles correspondant aux commandes moteur des axes robotiques

Le plan d'adressage des entrées sorties du pont reproduit avec une fidélité parfaite (bit à bit) le plan d'occupation du projet défini par FischerTechnik, chaque signal est adressé à une entrée ou une sortie portant le nom exact de la variable du programme.

Le modèle physique que le pont anime comprend :

• sept axes à codeur incrémental (dont la position peut être connue en temps réel)
• trois axes à fins de course (dont la position est uniquement connue quand l'axe physique vient presser une fin de course ce qui octroie un nombre limité de positions par le nombre de fin de courses présentes sur son chemin)
• des axes pneumatiques (de préhension et déplacement )
• des barrières lumineuses permettant de notifier la présence de pièces à un endroit précis de l'usine
• deux capteurs de couleur analogiques : un en entrée de ligne de manufacture et un autre en sortie de manufacture
• des convoyeurs de pièces qui transportent les pièces d'un point à un autre par l'intermédiaire de tapis roulants.
• La corrélation du comportement de certains capteurs comme celui des informations de pièces NFC lorsque celles-ci sont présentes dans une zone précise de l'usine

La présence d'une pièce dans une zone précise est ainsi déterminée à l'aide de la conjonction des états de ces différents éléments couplés au capteur NFC.

Les deux Raspberry Pi sont émulés à partir des images disque relevées sur leurs modèles physiques. Sur la station de capteurs réelle, le service NFC et le service de capture des données environnementales lisent les données de leurs composants via le bus de communication I²C. Ce bus fut répliqué au sein de la machine virtuelle 3 afin de simuler la présence des capteurs ainsi que leurs données produites sur le canal I²C. Cette simulation est complétée d'une liaison avec le modèle physique, le pont IoBridge, afin de simuler en temps et en heure le comportement des capteurs suivant la présence d'une pièce dans une zone précise. Le comportement est simulé à partir du code source de leur modèle physique mais aussi à l'aide de banques de données de référence, ce qui est le cas pour les informations d'identification de pièces véhiculées par le service NFC.

Le lecteur émulé reproduit le protocole de la puce fidèlement pour que la machine virtuelle qui héberge la station de capteurs puisse dialoguer avec lui. Trois comportements issus du monde physique y sont simulés :

• l'attente d'une pièce lorsque le champ de communication est vide
• le défaut de lecture lorsqu'aucune carte ou plusieurs cartes sont posées sur le lecteur
• La lecture / écriture d'un tag. Dans notre simulation, le pont détermine quel tag se trouve dans le champ et demande au programme de gestion du capteur de simuler la présence du tag correspondant. La passerelle de capteurs dialogue ensuite avec le capteur simulé pour y effectuer une des actions susmentionnées.

Une page du dashboard, représentée ci-après, fut créée pour que l'opérateur ait la main sur le capteur afin d'y insérer un tag précis, d'en lire et d'en écrire son contenu avec la possibilité d'injecter à volonté des défauts comme la présence de deux tags dans le champ ou d'un tag inconnu ou effacé.

À la question : comment superviser de manière rapide, efficace et simple le modèle virtuel, la solution fut d'implémenter un synoptique en deux dimensions qui reprend l'agencement de l'usine réelle avec toutes ses unités. On retrouve ainsi :

• Le bras robotique
• le hangar de stockage de pièces automatisé
• l'unité de traitement multifonction des pièces
• l'unité de conditionnement

Ces unités sont animées via le pont de simulation qui reprend chaque instruction en cours et les envoie à la passerelle via UDP pour qu'elle mette à jour l'interface du synoptique. En complément de cette vue logique d'usine, on retrouve des organes de commande pour insérer, retirer des pièces dans le modèle et commander une manufacture comme dans le monde réel. Par ailleurs, par souci de réalisme, des sources de failles ont été ajoutées comme la perte d'une pièce ou le dysfonctionnement d'un capteur de position d'un axe précis.

La mise en service du jumeau fut retardée de deux mois en raison des nombreux problèmes qui se sont accumulés lors de la préparation du modèle physique de l'usine, qui se heurtait à l'impérativité d'obtenir un modèle de référence exempt de défauts majeurs.

Le premier problème, qui m'aura demandé tant d'efforts, concernait les encodeurs de position présents sur les moteurs des axes robotisés VGR, SSC et HBW. Dès la mise en service, nous avions remarqué que les positions calculées par l'automate étaient en dehors de la réalité à chaque déplacement, et ce, avec des écarts allant de quelques unités à des centaines d'unités. Cela rendait impossible toute mesure ou création de jeu de données étalon.
En approfondissant le code source de l'automate, je suis tombé sur une ligne qui m'aura laissé stupéfait, car elle effectuait un « OU » logique exclusif (XOR) sur les entrées de signaux provenant de ces encodeurs, ce qui divisait la précision de position par deux, puisque cela signifiait qu'au lieu de lire les valeurs provenant des deux encodeurs rotatifs, la mesure se basait uniquement sur un signal d'encodeur… Cela entraînait par ailleurs une perte d'impulsions entre deux cycles de programme, engendrant une perte de l'ordre de 400 incréments en moyenne sur chaque course d'axe.

Cette faiblesse grave explique le silence de Fischer Technik, qui n'a jamais documenté de manière publique la mesure de position des axes de l'usine. Bien au contraire, la marque s'est contentée de brider volontairement la vitesse maximale atteignable sur chaque axe de l'usine à 500 incréments par seconde, valeur jusqu'à laquelle le programme de mesure imparfait restait dans sa zone de confort, alors que les moteurs et les encodeurs, eux, pouvaient atteindre une vitesse de 1000 incréments par seconde.
Afin de régler ce problème, un nouveau bloc de comptage des impulsions provenant des deux codeurs incrémentaux de chaque axe fut rédigé. Nommé FBINCDECv2, il ne manque plus aucune impulsion et reconnaît même le sens de rotation du moteur.

L'usine virtuelle FischerTechnik Industry 4.0 est un vrai vivier de périphériques multiples où leur diversité de fonctionnement et d'architecture a vite rattrapé un critère que le modèle physique industriel imposait avec la notion de « temps réel critique ». Cette notion fait référence à des systèmes qui ne tolèrent aucun dépassement de contraintes temporelles au risque d'entraîner de lourdes conséquences induites par des dérives de comportement nominales. On parle de « systèmes temps critique » pour des systèmes de contrôle commande de centrales nucléaires ou bien issus du domaine aéronautique. Dans notre cas les mouvements des axes nécessitant une précision accrue caractérisaient ce temps critique sur lequel venaient s'additionner les conditions d'envoi et de réponse aux messages circulant entre les différents composants où l'horodatage strict était vérifié. La solution initiale de Fischer Technik fut de synchroniser tous les périphériques à une source d'horloge fiable telle que celle des horloges atomiques distribuant leur référence de temps via le protocole NTP (Network Time Protocol). Cependant ce choix « critique » pour l'occasion s'est avéré être inapproprié car il empêchait tout mode de fonctionnement local mis en avant sur le papier. En rendant dépendants les périphériques d'une ressource présente sur l'internet, cela contredisait de fait la possibilité d'un fonctionnement en boucle fermée sans aucun accès sur l'extérieur. De plus, aucun mécanisme de synchronisation manuel n'avait été implémenté pour rattraper ces erreurs temporelles en transformant une machine comme la passerelle Node-RED en source de temps temporaire en cas d'avarie sur la disponibilité et l'accessibilité des serveurs NTP.

Les blocages sont caractérisés dans la manière dont l'automate dialogue avec le lecteur de tags NFC. Lorsqu'une pièce est à proximité du champ de lecture du capteur NFC, le PLC envoie une requête de lecture à la station de capteurs en y ajoutant l'heure à laquelle il a émis sa requête. La station vérifie ensuite si la différence entre le temps où la commande est reçue et celui où elle est émise correspond à l'intervalle prédéfini en mémoire. Si cet intervalle est dépassé, la commande est rejetée. Dans notre cas le temps d'expiration est défini par défaut à 10 s. Dans le cas où la commande est temporellement valide, la station renvoie la réponse en l'horodatant et le PLC lui de son côté vérifie si la réponse fut émise après sa commande, si c'est le cas la réponse est acceptée, dans le cas contraire, il envoie la pièce au rebut. Ces règles sont tout à fait correctes lorsque la source de temps est « pure » sans imperfection ni fluctuation. Mais voilà que dans le monde du jumeau numérique, à cause des raisons précédemment mentionnées sur les imperfections d'horloge qu'entraîne l'émulation d'une architecture de processeur, le temps fluctue et les horloges se dérèglent. Le principal maillon faible de la chaîne est l'automate virtuel qui n'avance que lorsque le modèle physique l'y autorise, dans notre cas le pont C# avançant ainsi milliseconde par milliseconde ce qui entraîne un retard cumulé dès que son processus démarre sur l'ordinateur de simulation. Combiné avec les Raspberry émulés qui deviennent plus lents que leurs homologues physiques, le temps devient un véritable cauchemar.

La solution trouvée pour pallier ce problème fut de partir d'une source de temps précise et de venir synchroniser le temps des autres périphériques suivant celle-ci, comme illustré ci-dessous avec pour préférence celle qui engendre le plus de fluctuations. Dans notre cas il fallait impérativement remettre à l'heure l'automate qui perdait sa référence à chaque cycle. Il fut donc décidé de mettre à l'heure l'automate via l'horloge de l'ordinateur qui l'héberge à raison de 50 fois par seconde. La passerelle Node-RED se calque ainsi sur ce temps de référence pour corriger son horloge dès que l'écart avec le temps du PLC est supérieur à 1 s. Enfin la passerelle capteurs se cale sur le temps que lui donne la passerelle Node-RED via un message et auto-corrige son horloge lorsque l'écart dépasse la demi-seconde.

Afin d'évaluer les performances du jumeau, les critères établis lors de la partie de recherche scientifique furent réutilisés et à savoir s'ils respectaient le principe fondamental de consistance et de légitimité d'un jumeau :

Ces critères furent prouvés sur les deux plans : fonctionnel et réseau.

• Sur le plan fonctionnel, le programme de l'automate physique inchangé a réussi à fonctionner sous tous les modes physiques émulés sur le jumeau virtuel. Ainsi le cycle complet attenant à la manufacture d'une pièce fut observé : des étapes de réception, stockage et de mise en magasin à celles de cuisson, fraisage, triage et d'expédition. Le mode continu a aussi été vérifié : le comportement attendu était une reprise d'une pièce par le VGR dans le bac de pièces terminées DSO pour la recycler en matière première dans un cycle infini (défini par les bornes temporelles du mode continu). Enfin, les modes de lecture, écriture, effacement de tags NFC se sont déroulés comme sur la maquette physique avec y compris le rejet de pièces dont l'horodatage de commande était supérieur à la tolérance prédéfinie. Grâce au miroir PLC servi par le biais de la passerelle Node-RED, les positions notées en modèle et calculées suivant le PLC n'ont différé que de incréments en moyenne ce qui n'est rien par rapport au programme initial de Fischer Technik qui avoisinait les 400 incréments d'erreur.
• Sur le plan réseau, les machines du jumeau correspondent à leur plan d'adressage réel, utilisent les mêmes ports, mêmes sujets MQTT. Les 429 variables exposées par l'automate sont les mêmes que sur le modèle physique et les messages de la passerelle de capteurs sont les mêmes. Le trafic de caméra simulé est exactement le même et les images sont bien servies et encodées suivant le bon format en base 64. Les horloges, elles, restent alignées à moins d'un quart de seconde sans aucune connexion Internet.

Ce que le jumeau reproduit de l'usine réelle, et ce qu'il ne reproduit pas

• Programme de l'automate – Programme final de la maquette – Le même programme, sans modification – Identique
• Cycle complet d'une pièce – Réception, stockage, four, fraisage, tri, expédition – Identique, retour au stockage compris – Reproduit
• Position des axes – Encodeurs réels, comptage corrigé – Écart inférieur à 5 impulsions sur les 7 axes – Reproduit
• Tags NFC – Tags réels des pièces – 12 tags réels relevés sur la maquette – Reproduit
• Adresses, ports, sujets MQTT – Ceux de la maquette – Identiques – Répliqué
• Variables de l'automate – 429 variables, lues par interrogation – 429 variables, lues par abonnement – Répliqué, mode de lecture différent
• Écart entre les horloges – Mise à l'heure par Internet – Moins d'un quart de seconde, sans Internet – Répliqué
• Flux de la caméra – 15 images par seconde – Environ 2 images par seconde – Non reproduit
• Usure et aléas mécaniques – Présents – Absents – Non reproduit

Une limites subsiste: La caméra virtuelle ne fournit qu'environ deux images par seconde au lieu de quinze, ce qui réduit le volume du trafic sans en changer la nature. Sous cette réserve, le critère est atteint : le jumeau reproduit le fonctionnement de l'usine et en réplique les caractéristiques réseau.

Une fois le nouveau service d'encodeurs installé et testé, les captures ont pu s'étendre sur plusieurs jours afin de réaliser une base de données étalon pour la conception du jumeau numérique. Les captures s'étendaient par pas de 10 minutes en fonctionnement d'usine continu et enregistraient divers évènements comme la mise en stock d'une pièce en état de matière première jusqu'à la manufacture complète de celle-ci.

Après avoir évalué 10 captures réseau en fonctionnement nominal, 10 autres furent effectuées avec tout type de pannes possibles : désynchronisation de l'horloge gateway, PLC, TXT, perte de connexion réseau d'un des éléments en plein fonctionnement d'usine, perte de pièce lors de la manufacture…. Ces échantillons ont constitué une base de données d'altérations de référence qu'il aurait fallu pouvoir comparer avec celle altérée provenant du jumeau numérique, mais faute de temps, la comparaison des captures nominales a uniquement pu être faite entre le modèle physique et son jumeau numérique.

En début de projet de recherche nous nous interrogions sur la faisabilité d'un jumeau numérique, nous sommes désormais convaincus du résultat ! Avec à l'appui des mesures, un protocole de mise en œuvre et surtout tant d'expertise sur la solution FischerTechnik où chaque problème rencontré ne faisait qu'augmenter un peu plus les connaissances de l'usine. On est partis de loin avec une usine qui dysfonctionnait et nous avons réussi suite à des diagnostics approfondis à la remettre sur pied. Elle tourne aujourd'hui de manière continue et sa plateforme de capteurs n'est plus limitée à un seul contrôleur dont seul Fischer Technik a le secret. Aujourd'hui le jumeau numérique est fonctionnel, utilisant le même programme que son homologue physique et simulant le même comportement réseau qu'un modèle réel. Les trois hypothèses ont ainsi été mises à l'épreuve et nous pouvons désormais statuer sur chacune d'elles : La première affirmant qu'un modèle physique des organes de la maquette suffit à faire fonctionner le programme est désormais vérifiée par la preuve d'un cycle complet du programme PLC sans qu'aucun artéfact vienne remplacer une de ses fonctions. La seconde selon laquelle les Raspberry Pi émulés reproduisent les mêmes contenus de trames réseau suivant les flux OPC UA et MQTT est également vérifiée, leurs logiciels et architectures virtuels sont intacts. Enfin la troisième portant sur la stabilité des horloges fut la plus difficile à établir. Elle ne fut vérifiée qu'à la suite d'une correction en profondeur de la chaîne de mises à l'heure des périphériques.

Ce projet a cependant quelques limites qui devront être levées voire retravaillées notamment sur les images synthétiques produites à partir de la caméra virtuelle, la comparaison de trafics issus d'altération pour le modèle physique et virtuel qui reste à faire ainsi que l'amélioration du modèle physique du jumeau pour simuler des usures et aléas mécaniques plus poussés. Qu'en est-il d'une possible évaluation de vecteurs d'attaques ou d'attaques à proprement parler sur les systèmes pour étudier son comportement ? Telles sont les perspectives que nous pouvons dresser en cette fin de projet.

1. BAGLIONE Pierre-Sacha (2025). Rapport de stage ESAIP : forces et faiblesses de l'Airbus CyberRange. ESAIP, Angers.
2. DRAGOS (2025). 2025 OT Cybersecurity Year in Review. Dragos Inc.
3. UKWANDU Elochukwu, et al. (2020). A Review of Cyber-Ranges and Test-Beds: Current and Future Trends. Sensors, vol. 20, n° 24, 7148.
4. NIST, The Cyber Range Project Team and the NICE Community (2023). The Cyber Range: A Guide. National Institute of Standards and Technology.
5. TAO Fei, ZHANG He, LIU Ang, NEE Andrew Y. C. (2019). Digital Twin in Industry: State-of-the-Art. IEEE Transactions on Industrial Informatics, vol. 15, n° 4, pp. 2405-2415.
6. ECKHART Matthias, EKELHART Andreas (2018). Towards a Specification-Based State Replication Approach for Digital Twins. Proceedings of the 2018 Workshop on Cyber-Physical Systems Security and PrivaCy (CPS-SPC '18), ACM, Toronto, pp. 36-47.
7. ECKHART Matthias, EKELHART Andreas (2019). Digital Twins for Cyber-Physical Systems Security: State of the Art and Outlook. In : Security and Quality in Cyber-Physical Systems Engineering, Springer, Cham, pp. 383-412.
8. BELLARD Fabrice (2005). QEMU, a Fast and Portable Dynamic Translator. Proceedings of the USENIX Annual Technical Conference, FREENIX Track, Anaheim, pp. 41-46.
9. RUSSELL Rusty (2008). virtio: Towards a De-Facto Standard for Virtual I/O Devices. ACM SIGOPS Operating Systems Review, vol. 42, n° 5, pp. 95-103.
10. OASIS (2022). Virtual I/O Device (VIRTIO) Version 1.2. OASIS Standard, Organization for the Advancement of Structured Information Standards.
11. RUST-VMM PROJECT (2024). vhost-device: vhost-user backend devices, dont vhost-device-i2c. Dépôt GitHub [en ligne], disponible sur le Web <https://github.com/rust-vmm/vhost-device> [consulté le 21 septembre 2026].
12. LAMPORT Leslie (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, vol. 21, n° 7, pp. 558-565.
13. KOPETZ Hermann (2011). Real-Time Systems: Design Principles for Distributed Embedded Applications. 2e édition, Springer, New York.
14. MILLS David, MARTIN Jim, BURBANK Jack, KASCH William (2010). Network Time Protocol Version 4: Protocol and Algorithms Specification. RFC 5905, Internet Engineering Task Force.