Comment valider la logique API à l'aide du Software-in-the-Loop (SITL) et des jumeaux numériques OLLA Lab

Le test Software-in-the-Loop (SITL) en automatisation industrielle consiste à exécuter la logique de contrôle d'un API sur un modèle logiciel du comportement de l'équipement plutôt que sur du matériel physique. Dans OLLA Lab, la logique à contacts (ladder) peut être testée sur des jumeaux numériques 3D pour vérifier le séquençage, les temporisations, les interverrouillages, le comportement en état anormal et la reprise après défaut avant la mise en service réelle.

Une logique à contacts syntaxiquement correcte n'est pas la même chose qu'une logique de contrôle déployable. Un compilateur peut confirmer la validité des instructions, la cohérence des tags et l'ordre d'exécution de base ; il ne peut pas vous dire si un convoyeur s'indexe dans un vérin déployé, si une séquence de redémarrage remet sous tension un mouvement dangereux, ou si un capteur arrive trop tard pour protéger le mécanisme. La syntaxe est peu coûteuse. Les erreurs de mise en service ne le sont pas.

Une définition utile de la « simulation-ready » est opérationnelle et non aspirationnelle : un ingénieur est prêt pour la simulation lorsqu'il peut prouver, observer, diagnostiquer et renforcer la logique de contrôle face à un comportement de processus réaliste avant qu'elle n'atteigne un processus réel.

Dans une analyse interne d'Ampergon Vallis portant sur 1 200 scénarios de mise en service simulés dans OLLA Lab, les utilisateurs ayant validé leur logique sur un jumeau numérique 3D ont identifié 84 % des conditions de concurrence (race conditions) mécaniques modélisées avant la première exécution physique. Méthodologie : taille de l'échantillon = 1 200 exécutions de scénarios dans des laboratoires prédéfinis et personnalisés ; définition de la tâche = détection des conditions de concurrence modélisées telles que les chevauchements d'actionnement et les conflits d'indexation ; comparateur de référence = revue de logique et état de compilation valide sans exécution sur jumeau numérique ; fenêtre temporelle = janvier 2025 à février 2026. Cela confirme que la simulation peut exposer des classes de défauts que les vérifications syntaxiques ordinaires manquent. Cela ne prouve pas la fiabilité sur le terrain, la compétence de l'opérateur ou la certification de sécurité.

Le SITL, le HIL et la mise en service physique répondent à des questions de validation différentes. Les traiter comme interchangeables est un moyen sûr de passer à côté des risques.

Selon le cadre de mise en service virtuelle décrit dans la norme VDI 3693, le Software-in-the-Loop (SITL) signifie que la logique du contrôleur et le comportement de l'installation sont tous deux représentés par logiciel, sans nécessiter la présence de l'API physique, du câblage de terrain ou du matériel machine. L'objectif est de valider le comportement de contrôle par rapport à la réponse simulée du processus dans un environnement à risques maîtrisés.

Le Hardware-in-the-Loop (HIL) se rapproche d'un niveau de la réalité. L'installation reste simulée, mais le matériel de contrôle réel est introduit. Cela permet de tester la temporisation du matériel, la gestion des E/S et certains comportements spécifiques à la plateforme que le SITL ne peut pas reproduire entièrement.

La mise en service physique est la pile complète : logique de contrôle, API physique, câblage, instrumentation, actionneurs, dynamique de la machine et les surprises qui apparaissent lorsque tout cela se rencontre lors du démarrage.

### Comparaison : SITL vs HIL vs mise en service physique

| Mode de validation | Ce qui est réel | Ce qui est simulé | Objectif principal | Niveau de risque | |---|---|---|---|---| | SITL | Environnement d'exécution de la logique de contrôle | Comportement de l'installation/équipement | Valider la logique de séquence, les interverrouillages, les hypothèses de temporisation, les transitions d'état, la gestion des défauts | Faible | | HIL | Matériel API/contrôleur physique | Comportement de l'installation/équipement | Valider l'exécution spécifique au contrôleur, le comportement des E/S, la temporisation matérielle, les hypothèses d'intégration | Moyen | | Mise en service physique | API, câblage, capteurs, actionneurs, machine/processus | Peu ou aucun | Valider le système déployé dans les conditions réelles d'exploitation | Élevé |

Ce pour quoi le SITL est efficace

• Test du comportement des alarmes et des déclenchements (trips)
• Exercice de la logique de redémarrage et de récupération
• Exposition des conditions de concurrence entre les commandes et les retours d'information
• Répétition des états anormaux sans risquer l'équipement

Ce que le SITL ne remplace pas

• Les tests de réception sur site (SAT)
• Les tests de boucles et la vérification du câblage
• La validation de la sécurité fonctionnelle
• La détermination du SIL ou la démonstration de conformité
• La formation des opérateurs sur l'actif installé exact, à moins que la portée du modèle ne le permette

Cette limite est importante. Un jumeau numérique est utile parce qu'il réduit l'incertitude, pas parce qu'il l'élimine.

La logique à contacts échoue sur le terrain parce que les systèmes physiques ne sont pas des diagrammes booléens. Ils présentent des délais, de l'inertie, de la friction, des dérives et des modes de défaillance qu'un compilateur ne modélise pas.

Un barreau (rung) valide à la compilation peut toujours commander une séquence impossible. Il peut également commander une séquence possible au mauvais moment, ce qui est souvent pire car la défaillance est intermittente.

Les trois réalités physiques ignorées par les compilateurs

1. Inertie mécanique Une commande d'arrêt ne produit pas un arrêt instantané. Les moteurs continuent de tourner, les convoyeurs dépassent leur cible et les charges suspendues continuent de se déplacer. La logique peut être correcte au niveau du cycle de balayage (scan) et pourtant fausse au niveau de la machine.
2. Latence des capteurs Les capteurs réels ont un temps de réponse, une tolérance de montage, des rebonds et un filtrage. Une cellule photoélectrique ou un fin de course qui change d'état quelques millisecondes plus tard que prévu peut invalider une séquence par ailleurs élégante.
3. Stiction des actionneurs et délai de processus Les vérins pneumatiques nécessitent une montée en pression. Les vannes peuvent gripper avant de bouger. Les pompes ne créent pas un débit stable à l'instant où le bit du moteur est activé. Le schéma à contacts ne s'en soucie pas ; le processus, si.

Le sophisme du « ça a l'air correct »

« Ça a l'air correct » signifie généralement « passe une revue visuelle sous des hypothèses idéales ». Ce n'est pas la même chose que de prouver que la séquence survit à des conditions de temporisation et de défaillance réalistes.

Considérez un convoyeur de tri avec un vérin pousseur :

• La logique commande l'arrêt du convoyeur.
• La logique commande l'extension du vérin.
• La logique attend la confirmation d'extension.
• La logique redémarre le convoyeur après la déviation du produit.

Sur le papier, c'est propre. Dans une machine simulée, le convoyeur peut encore être en roue libre lorsque le vérin entre dans la voie. Si la séquence dépend d'un arrêt instantané, le mécanisme entre en collision même si chaque barreau est légal et chaque nom de tag est correct. Le compilateur ne s'y opposera pas. La physique, généralement, si.

Dans cet article, un jumeau numérique n'est pas un synonyme marketing pour des graphismes 3D. C'est un modèle logiciel qui échange des états avec la logique de contrôle dans une boucle de validation déterministe.

Opérationnellement, un jumeau numérique de validation API est :

> Un modèle logiciel cinématique et à événements discrets qui consomme les sorties de l'API, applique des contraintes physiques simulées telles que le délai de mouvement, la gravité, la friction et la temporisation dépendante de l'état, et renvoie des entrées de capteurs et de processus déterministes à la logique de contrôle.

Cette définition est intentionnellement étroite. Elle exclut la visualisation décorative qui ne participe pas à l'échange d'état de contrôle.

Un jumeau numérique utile pour le travail de contrôle doit faire quatre choses

Exemple : commandes de marche moteur, commandes d'ouverture de vanne, bits d'extension de vérin, points de consigne analogiques.

• Consommer les sorties du contrôleur

Exemple : accélération, décélération, temps de maintien, temps de trajet, délai de pression, changement de niveau ou retard de processus.

• Appliquer le comportement modélisé de l'équipement

Exemple : détecteurs de proximité, cellules photoélectriques, fins de course, valeurs analogiques (PV), états d'alarme, retours de preuve.

• Renvoyer des entrées simulées à la logique

Le même cas de test doit être suffisamment reproductible pour diagnostiquer les changements de logique et comparer les révisions.

• Préserver des conditions de test déterministes

C'est la différence entre une vidéo et un environnement de validation. L'un est illustratif. L'autre peut opposer son veto à une mauvaise logique de contrôle.

OLLA Lab devient opérationnellement utile lorsque le programme à contacts et l'équipement simulé partagent un état observable. La plateforme n'est pas seulement un éditeur de logique avec une scène à côté ; la valeur réside dans l'association des variables logiques au comportement de la machine, puis dans l'observation de la boucle qui se ferme.

Dans OLLA Lab, les utilisateurs construisent une logique à contacts dans un éditeur basé sur le web, l'exécutent en mode simulation et inspectent ou manipulent les variables via le panneau des variables. La plateforme prend en charge les flux de travail d'apprentissage orientés booléens, analogiques, temporisateurs, comparateurs, mathématiques et PID, ainsi que des scénarios de simulation 3D/WebXR. Au sein de ce flux de travail, les tags peuvent être associés aux états de l'équipement simulé afin que les bits de commande pilotent le modèle et que les événements du modèle renvoient des retours d'information dans la logique.

Flux de travail pratique d'association de tags dans OLLA Lab

Une configuration de validation typique ressemble à ceci :

• Définir les tags de commande dans la logique à contacts
• `Conveyor_Run_CMD`
• `Cylinder_Extend_CMD`
• `Reset_Fault_CMD`

• Définir les tags de retour et de capteur
• `Conveyor_At_Speed`
• `Cylinder_Extended_LS`
• `Photoeye_PE1`
• `Jam_Fault`

• Associer les tags de commande aux comportements du jumeau numérique
• `Conveyor_Run_CMD` pilote l'état de mouvement du convoyeur
• `Cylinder_Extend_CMD` pilote la séquence d'extension de l'actionneur

• Associer les réponses de l'équipement simulé aux tags
• Le mouvement du convoyeur met à jour `Conveyor_At_Speed`
• Le fin de course virtuel met à jour `Cylinder_Extended_LS`
• Le raycast virtuel ou la détection d'objet met à jour `Photoeye_PE1`

• Exécuter la séquence et inspecter les transitions d'état
• Basculer les entrées
• Mettre en pause, exécuter ou arrêter la simulation
• Observer les changements de tags, les temporisateurs, les valeurs analogiques et les états de défaut

Ce que cela apporte à l'ingénieur

• Une chaîne de cause à effet visible entre la logique des barreaux et la réponse de la machine
• Un endroit pour tester si les interverrouillages sont réellement suffisants
• Un moyen d'inspecter les décalages de temporisation entre la commande et la preuve
• Un environnement sûr pour injecter des défauts qui seraient coûteux ou dangereux sur un équipement réel

C'est là qu'OLLA Lab s'intègre de manière crédible : en tant qu'environnement de répétition à risques maîtrisés pour la validation et la pratique du dépannage. Il ne remplace pas la mise en service sur le terrain, mais il permet aux ingénieurs de répéter des parties de la mise en service qui sont trop destructrices, trop coûteuses ou trop perturbatrices pour être apprises sur une ligne en production.

Les tests SITL les plus précieux ne sont pas les séquences nominales. Ce sont les tests d'états anormaux. Presque toute stratégie de contrôle semble compétente lorsque chaque capteur se comporte normalement et que chaque actionneur arrive à l'heure.

Cas de test SITL obligatoires

Déclencher un arrêt d'urgence pendant qu'un mouvement est actif et que le mécanisme transporte ou pousse du matériel. Vérifier :

• que le mouvement dangereux est mis hors tension comme prévu,
• que la mémoire d'état se comporte de manière prévisible,
• que le redémarrage nécessite une action délibérée de l'opérateur,
• qu'aucun chemin de reprise automatique caché n'existe.

Forcer un dispositif de fin de course normalement fermé ou normalement ouvert dans l'état de défaillance pendant le mouvement. Vérifier :

• que la détection de défaut se produit dans la fenêtre attendue,
• que le mouvement est inhibé ou arrêté en toute sécurité,
• que le texte de l'alarme et les bits de défaut sont sans ambiguïté,
• que les conditions de réinitialisation sont délibérées et limitées.

Simuler une perte de puissance de contrôle ou une interruption d'exécution. Vérifier :

• que les sorties reviennent à des valeurs par défaut sûres,
• que la logique de démarrage ne redémarre pas automatiquement un mouvement dangereux,
• que les états conservés ne créent pas d'hypothèses de séquence impossibles,
• que l'acquittement de l'opérateur est requis le cas échéant.

Commander un mouvement et ne pas recevoir le retour attendu. Vérifier :

• que la logique de temporisation se déclenche,
• que le défaut est mémorisé correctement,
• que le mouvement en aval est bloqué,
• que le chemin de récupération est explicite.

Introduire un chevauchement de temporisation entre des états machine adjacents. Vérifier :

• que les actions mutuellement exclusives restent exclusives,
• qu'un état ne peut pas en supplanter un autre sans la preuve requise,
• que les hypothèses sur l'ordre de balayage ne masquent pas un défaut de séquençage.

Injecter des perturbations de processus ou des valeurs de capteur irréalistes. Vérifier :

• que les alarmes s'activent aux seuils définis,
• que la sortie de contrôle se comporte dans les limites attendues,
• que le transfert sans à-coup (bumpless) ou les changements de mode sont gérés proprement,
• que les déclenchements et les permissifs restent cohérents en cas de perturbation analogique.

1. Arrêt d'urgence asynchrone en charge
2. Défaillance de capteur et vérification de sécurité (failsafe)
3. Récupération après coupure de courant
4. Temporisation mécanique et conditions d'absence de preuve
5. Conditions de concurrence de séquence
6. Excursion analogique et perturbation PID

Une idée fausse pratique qui mérite d'être corrigée

Tester uniquement le chemin nominal n'est pas de la validation. C'est de la démonstration. Le risque réel de mise en service réside dans les transitions, les délais et les défaillances.

Un modèle de temporisation est l'une des structures défensives les plus simples qui gagne une réelle valeur en SITL. Il convertit « l'actionneur aurait dû bouger maintenant » en une condition de défaut observable.

Voici un exemple compact pour une temporisation d'extension de vérin. La syntaxe exacte varie selon la plateforme, mais l'intention de contrôle est standard.

Langage : Schéma à contacts (Ladder)

// Logique de défaut de temporisation d'actionnement de vérin |---[ ]-----------[/]-----------[/]-----------------(TON)---| CMD_Extend Limit_Retract Limit_Extend Fault_Delay

|---[ ]---------------------------------------------( )-----| Fault_Delay.DN Fault_Cyl_Ext_Timeout

Ce que fait ce barreau

• `CMD_Extend` démarre la condition de temporisation lorsque l'extension est commandée.
• `Limit_Retract` non activé indique que le vérin n'est plus en position de repos sécurisée, selon la philosophie de l'appareil.
• `Limit_Extend` non activé signifie que la preuve d'extension n'est pas encore arrivée.
• `Fault_Delay` chronomètre la fenêtre de déplacement autorisée.
• Lorsque le temporisateur se termine sans preuve d'extension, `Fault_Cyl_Ext_Timeout` est activé.

Pourquoi le SITL est important ici

Dans une revue de logique statique, ce barreau semble simple. Dans un jumeau numérique, vous pouvez tester si la temporisation est :

• trop courte pour un déplacement réaliste de l'actionneur,
• trop longue pour protéger le mécanisme,
• réinitialisée incorrectement par les transitions de séquence,
• aveugle à un mouvement partiel ou à des conditions de blocage.

C'est la différence entre écrire une temporisation et en valider une.

Les preuves d'ingénierie doivent montrer un raisonnement, pas seulement une familiarité avec l'interface. Une galerie de captures d'écran prouve que le logiciel a été ouvert. Elle ne prouve pas grand-chose d'autre.

Si l'objectif est de démontrer un travail de contrôle sérieux, documentez chaque exercice simulé en utilisant cette structure :

Structure de preuve requise

Exemple : « Le convoyeur ne doit pas redémarrer tant que le vérin de déviation n'est pas complètement rétracté et que la présence de produit est effacée. »

Exemple : « Commande d'extension de vérin émise alors que le temps de roue libre du convoyeur était encore de 1,8 s. »

Exemple : « Ajout d'un permissif de vitesse nulle du convoyeur et d'un défaut de temporisation d'extension. »

1. Description du système Définir la machine ou la cellule de processus, les principaux actionneurs, les capteurs et l'objectif opérationnel.
2. Définition opérationnelle du « correct » Indiquer ce qui doit être vrai pour que la séquence soit considérée comme correcte.
3. Logique à contacts et état de l'équipement simulé Montrer les barreaux pertinents, les définitions de tags et les états ou retours correspondants du jumeau numérique.
4. Le cas de défaut injecté Indiquer exactement ce qui a été forcé ou perturbé.
5. La révision effectuée Documenter le changement de logique.
6. Leçons apprises Expliquer quelle hypothèse a échoué et comment la logique révisée renforce la séquence.

Cette structure est utile car elle capture l'intention de contrôle, le modèle de défaillance et le raisonnement correctif. C'est le matériel que les employeurs et les réviseurs peuvent réellement interroger. Les captures d'écran seules sont principalement décoratives.

OLLA Lab prend en charge un flux de travail « simulation-ready » en combinant la création de logique à contacts, la simulation, l'inspection des variables, le contexte de scénario et l'interaction avec le jumeau numérique dans un environnement basé sur le web. L'avantage n'est pas la commodité pour elle-même ; c'est la réduction du changement de contexte pendant la validation.

Dans le cadre des faits produits limités, OLLA Lab offre :

• Un éditeur de logique à contacts basé sur le web avec contacts, bobines, temporisateurs, compteurs, comparateurs, fonctions mathématiques, opérations logiques et instructions PID
• Un mode simulation pour exécuter la logique, basculer les entrées et observer les sorties sans matériel physique
• Un panneau de variables pour surveiller les tags, les E/S, les valeurs analogiques, les variables liées au PID et l'état du scénario
• Des simulations 3D/WebXR/VR qui connectent la logique de contrôle au comportement de l'équipement
• Des flux de travail de validation par jumeau numérique pour tester la logique par rapport à des modèles de machines réalistes
• Des laboratoires basés sur des scénarios dans les domaines de la fabrication, de l'eau/eaux usées, du CVC, de la chimie, de la pharmacie, de l'entreposage, de l'agroalimentaire et des services publics
• Des instructions de construction guidées avec objectifs, mappage des E/S, philosophie de contrôle, interverrouillages et étapes de vérification
• Des conseils d'IA via GeniAI, positionnés comme un coaching de laboratoire et un support correctif à l'intérieur du flux de travail d'apprentissage

La revendication limitée

OLLA Lab peut aider les ingénieurs à répéter des tâches de validation difficiles à mettre en scène en toute sécurité sur des systèmes réels :

• tracer la cause à effet des E/S,
• tester les interverrouillages,
• observer le comportement en cas de défaut,
• réviser la logique après une défaillance d'état anormal,
• comparer l'état de la logique à contacts par rapport à l'état de l'équipement simulé.

Il ne doit pas être présenté comme un substitut à l'expérience sur le terrain, au travail formel de sécurité fonctionnelle ou à l'autorité de mise en service spécifique au site. Un simulateur peut exposer de mauvaises hypothèses tôt. Il ne peut pas signer la réception d'une installation.

Le SITL peut améliorer la qualité de la mise en service en déplaçant la découverte des défauts plus tôt, mais il n'établit pas en soi la conformité de sécurité. Cette distinction est centrale.

Ce que le SITL peut soutenir

• Découverte plus précoce des défauts de séquençage
• Meilleure couverture des tests des états anormaux
• Répétition plus sûre de la gestion des défauts
• Préparation à la mise en service plus disciplinée
• Amélioration de la communication entre les équipes de contrôle, mécaniques et de processus

Ce qui nécessite toujours un traitement séparé

• Activités du cycle de vie de la sécurité fonctionnelle selon la norme IEC 61508
• Conception et vérification des fonctions instrumentées de sécurité
• Évaluation des risques spécifique au site
• Analyse de la tolérance aux pannes matérielles
• Tests de preuve et validation du système installé

La littérature industrielle sur la mise en service virtuelle et la simulation cyber-physique soutient généralement la valeur d'une validation comportementale plus précoce, en particulier pour les systèmes mécatroniques et à forte intensité de séquençage. Le résultat récurrent n'est pas que la simulation élimine le risque de mise en service. C'est que la simulation déplace une partie significative de la découverte des défauts vers une phase moins coûteuse et plus sûre du projet. C'est une revendication plus modeste, et aussi la plus crédible.

Commencez par une séquence compacte qui contient du mouvement, un retour d'information et une branche d'état anormal. Si le premier exercice est trop simple, il enseigne la syntaxe mais pas le jugement.

Un bon cas de démarrage dans OLLA Lab est un scénario de convoyeur et déviateur ou de pompe en mode maître/esclave avec :

• un chemin de commande,
• un retour de preuve,
• une temporisation,
• une alarme,
• une condition de redémarrage,
• un défaut injecté.

Cela donne suffisamment de structure pour tester la causalité sans disparaître dans l'architecture. L'objectif est d'apprendre si la logique survit au contact avec un processus modélisé, et non de construire un grand système dès le premier jour.

Ampergon Vallis Lab

Ampergon Vallis

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)