Comment déboguer la logique Ladder avec un assistant IA : Découvrez Yaga dans OLLA Lab

Un débogage efficace de la logique Ladder nécessite bien plus qu'une simple aide à la syntaxe. Yaga, le coach IA intégré à OLLA Lab, fonctionne comme un assistant délimité, lié à l'état du projet, au comportement de la simulation et au contexte des E/S. Il aide les ingénieurs à diagnostiquer les défauts de logique, à expliquer les structures IEC 61131-3 et à répéter les flux de travail de correction avant la mise en service réelle.

La logique Ladder échoue généralement pour des raisons plus physiques que grammaticales. Un barreau peut sembler correct tout en produisant un comportement machine erroné, car le problème réel réside dans l'ordre de balayage (scan), le mappage des tags, le séquencement, la temporisation ou une hypothèse erronée sur l'état de l'équipement.

C'est là que les ingénieurs juniors sont souvent bloqués. Ils savent placer des contacts et des bobines, mais ils ne peuvent pas encore expliquer pourquoi une séquence se bloque, pourquoi une sortie ne s'active jamais, ou pourquoi une condition de validation (permissive) s'efface un cycle de balayage trop tard. La syntaxe n'est pas le plus difficile ; c'est la déployabilité.

Lors des tests bêta d'OLLA Lab, les apprenants utilisant Yaga pour diagnostiquer les divergences d'état « verrouillage vs maintien » ont résolu les scénarios de défauts assignés 63 % plus rapidement que ceux utilisant uniquement la documentation statique [Méthodologie : n=38 apprenants ; tâche=débogage de défauts pré-configurés de contrôle moteur et de séquencement de pompes en simulation ; comparateur de référence=instructions PDF de type OEM et listes de tags sans assistance IA ; période=8 semaines de bêta, T1 2026]. Cette référence interne soutient une affirmation plus restreinte : le coaching par IA délimitée peut réduire le temps de diagnostic au sein d'un flux de travail de laboratoire simulé. Cela ne prouve pas la compétence sur site, la préparation à la mise en service sur équipement réel, ni des résultats plus larges sur le marché du travail.

Les ingénieurs juniors sont bloqués parce que la logique Ladder n'est pas seulement un système de notation. C'est un système comportemental exécuté en cycles de balayage par rapport à des états de processus réels ou simulés, avec des conséquences façonnées par la temporisation, les interverrouillages, les retours d'information et les modes de défaillance.

Une idée fausse courante est que le débogage d'un automate (PLC) consiste principalement à « trouver le mauvais barreau ». En pratique, la défaillance réside souvent dans la relation entre les barreaux, les tags et les hypothèses de séquence. Une commande de démarrage moteur peut s'activer correctement, mais la séquence échoue quand même parce que l'entrée de confirmation ne change jamais d'état, que le chemin d'arrêt est écrasé plus tard dans le balayage, ou que le modèle d'état n'était pas cohérent dès le départ. Le schéma est propre, mais la machine reste insensible.

Cet écart est mieux décrit comme une perte d'intuition en contrôle-commande. Les ingénieurs connaissent le jeu d'instructions, mais ils ne raisonnent pas encore couramment sur :

• l'ordre de balayage et les sorties écrasées,
• le comportement de maintien (seal-in) par rapport au verrouillage (latch),
• les conditions de validation (permissives) par rapport aux déclenchements (trips),
• le retour d'information de fonctionnement (proof-of-run),
• la gestion des états anormaux,
• les seuils analogiques et la temporisation anti-rebond,
• la progression de séquence dans des conditions de terrain incomplètes.

La recherche sur la formation industrielle et les systèmes cyber-physiques suggère que la qualité de l'apprentissage dépend d'un retour d'information riche en contexte plutôt que d'une exposition isolée au code. Dans les environnements OT, la charge cognitive provient du basculement entre la logique, le récit du processus, l'état des E/S, les alarmes et le comportement de l'équipement, plutôt que de la simple reconnaissance des symboles (Aivaliotis et al., 2019 ; Mourtzis et al., 2021).

C'est aussi pourquoi « Simulation-Ready » nécessite une définition stricte. Dans cet article, « Simulation-Ready » signifie qu'un ingénieur 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. C'est une exigence plus élevée que de savoir dessiner un barreau de mémoire, et plus utile.

Yaga fournit une correction contextuelle en opérant à l'intérieur de l'environnement délimité d'OLLA Lab, plutôt que comme un générateur de texte libre. Il est destiné à aider les utilisateurs à inspecter la logique qu'ils ont construite, les variables qu'ils ont mappées et le comportement simulé qu'ils ont déclenché.

Cette distinction est importante. Un chatbot général peut décrire des modèles de logique Ladder, mais il ne sait pas intrinsèquement ce que font vos tags, quel scénario est chargé, ou si l'état de l'équipement simulé diverge du récit de contrôle prévu. Dans le travail de contrôle-commande, le manque de contexte n'est pas un défaut mineur. C'est généralement le défaut lui-même.

Au sein d'OLLA Lab, Yaga fonctionne comme un coach de laboratoire IA qui prend en charge trois comportements d'ingénierie observables :

• le traçage de la causalité des E/S,
• l'identification des incohérences structurelles ou de mappage,
• la comparaison de la logique de séquence prévue par rapport à l'état réel de la simulation.

Flux de travail de diagnostic à trois niveaux de Yaga

Yaga peut aider les utilisateurs à identifier les E/S non mappées, l'utilisation incohérente des tags et les probables incompatibilités de types de données dans le contexte du projet visible via l'éditeur et le flux de travail des variables. C'est le premier niveau, car de nombreux défauts de « logique » sont en réalité des défauts de liaison déguisés.

• Validation de la syntaxe et des tags

Yaga peut orienter les utilisateurs vers des modèles structurels qui échouent couramment lors de l'exécution sur automate, tels que les conditions de double bobine, les écritures de sortie conflictuelles, les chemins de maintien rompus ou la logique de séquencement qui dépend de transitions d'état impossibles.

• Analyse du cycle de balayage et de la structure

Yaga peut aider à convertir un objectif de processus en langage clair en une ébauche de logique Ladder que l'utilisateur peut inspecter, affiner et tester. Le mot important est « ébauche ». C'est une aide au coaching, pas une autorité en matière de sécurité.

• Traduction de la philosophie de contrôle

C'est là qu'OLLA Lab devient opérationnellement utile. L'éditeur Ladder, le mode simulation, le panneau des variables et le cadre des scénarios donnent à Yaga un espace délimité à partir duquel coacher. Au lieu de répondre par abstraction, il peut soutenir un flux de travail où l'utilisateur écrit la logique, lance la simulation, bascule les entrées, observe les sorties et révise le programme par rapport au comportement visible de la machine.

Une IA délimitée signifie que l'assistant est contraint par l'environnement connu, les données de projet disponibles et le flux de travail de formation spécifique, plutôt que d'être invité à improviser dans un contexte industriel non vérifié.

Dans OLLA Lab, ce contexte délimité inclut le projet Ladder de l'utilisateur, l'état de la simulation, la visibilité des variables et des E/S, ainsi que la structure spécifique au scénario. L'article fait référence aux données de projet sérialisées en JSON ; cela compte car l'état du projet sérialisé crée une représentation lisible par machine du modèle de contrôle et du travail de l'utilisateur. En termes simples, l'assistant ne devine pas à partir d'une capture d'écran et d'une invite optimiste.

Opérationnellement, un coach d'automatisation délimité doit faire ce qui suit :

• raisonner à partir de l'état actuel du projet plutôt que d'exemples génériques,
• garder les recommandations liées aux tags, instructions et comportements de scénario observables,
• soutenir la validation en simulation plutôt que d'impliquer une autorité de déploiement sur le terrain,
• expliquer pourquoi un défaut se produit, et ne pas simplement proposer du code de remplacement.

Ce qu'il ne doit pas faire, c'est laisser entendre que la logique générée est sûre parce qu'elle est syntaxiquement plausible. L'IEC 61131-3 définit les langages de programmation et les structures pour le contrôle industriel, mais la conformité au langage n'est pas la même chose que la sécurité des procédés, la sécurité fonctionnelle ou l'approbation de mise en service (IEC, 2013).

La différence principale n'est pas la « qualité de l'IA » dans l'abstrait. C'est la capacité du modèle à raisonner à partir du contexte de contrôle réel, de l'état de la simulation et des contraintes d'ingénierie de la tâche en cours.

| Fonctionnalité | LLM général | Assistant Yaga d'OLLA Lab | |---|---|---| | Conscience du contexte | Repose sur des invites textuelles et des descriptions fournies par l'utilisateur. | Fonctionne dans le contexte du projet et de la simulation d'OLLA Lab. | | Ancrage des tags et E/S | Ne peut pas vérifier intrinsèquement les mappages de projet en direct. | Prend en charge le débogage par rapport aux variables, tags et comportements de scénario visibles. | | Pertinence du cycle de balayage | Peut décrire correctement les concepts d'automate mais peut manquer les implications de l'ordre d'exécution dans la logique spécifique de l'utilisateur. | Peut coacher les utilisateurs sur les problèmes d'ordre de balayage et de divergence d'état dans le flux de travail délimité du laboratoire. | | Réalisme matériel | Aucune connexion native à l'équipement de l'usine ou à l'état de simulation du laboratoire, sauf intégration explicite. | Utilisé avec la simulation d'OLLA Lab et les modèles de scénarios de type jumeau numérique. | | Résultat d'apprentissage | Tend souvent vers la génération de réponses. | Destiné à soutenir le diagnostic, l'explication et la révision. | | Posture de sécurité | Facile à sur-faire confiance car la sortie est fluide. | Délimité comme aide à la répétition et à la validation, pas comme autorité de mise en service. |

L'implication en matière de sécurité est directe. Les LLM généraux peuvent être utiles pour la révision de concepts, mais ils ne sont pas fiables lorsque les utilisateurs les traitent comme si un texte fluide équivalait à une révision de contrôle déterministe. Dans l'automatisation industrielle, l'éloquence ne coûte rien. Un comportement de séquence correct, si.

Yaga aide en transformant le débogage en un flux de travail observable plutôt qu'en un exercice de devinettes. L'utilisateur peut construire la logique dans l'éditeur Ladder basé sur navigateur, lancer la simulation, inspecter les variables et les E/S, et demander des conseils liés à ce que fait le système.

Un modèle de défaut typique est l'écrasement de sortie au sein du même balayage. Considérez cet exemple simplifié :

[Langage : Schéma à contacts (Ladder) - Exemple de défaut] // Yaga détecte le syndrome de la double bobine Barreau 1 : XIC(Start_PB) OTE(Motor_Run) Barreau 2 : XIC(Stop_PB) OTE(Motor_Run) // Défaut : État de sortie écrasé

Le problème n'est pas seulement que le code « semble étrange ». Le problème est que `Motor_Run` est écrit à plusieurs endroits, donc son état final dépend de la progression du balayage et de l'évaluation de la vérité du barreau. Un ingénieur junior peut voir deux déclarations raisonnables. Un ingénieur de mise en service y voit une invitation à perdre son après-midi.

La valeur de Yaga dans ce genre de cas n'est pas qu'il connaît magiquement la seule vraie réponse. Sa valeur est qu'il peut inciter l'utilisateur à se poser les bonnes questions de diagnostic :

• Où la sortie est-elle écrite ?
• La logique d'arrêt est-elle implémentée comme une coupure de validation ou comme une écriture conflictuelle ?
• Le chemin de maintien préserve-t-il correctement l'état ?
• Le retour d'information du moteur simulé confirme-t-il le fonctionnement ?
• Quel tag change en premier, et lequel devrait le faire ?

C'est la bonne boucle d'apprentissage. L'utilisateur ne reçoit pas simplement un barreau corrigé ; il est invité à raisonner à partir de la causalité, de l'état et de l'ordre d'exécution.

Yaga est le plus utile lorsque la révision de la logique est liée au comportement de l'équipement simulé. La logique Ladder n'est que la moitié de l'histoire ; l'autre moitié est de savoir si le modèle de machine ou de processus répond comme la philosophie de contrôle l'attend.

Dans OLLA Lab, les utilisateurs peuvent tester la logique en mode simulation, basculer les entrées, observer les sorties et les états des variables, et travailler sur des exercices industriels basés sur des scénarios. La plateforme inclut également des options de simulation 3D et WebXR/VR et les positionne comme des environnements de validation de jumeaux numériques. Cette expression nécessite de la rigueur.

Dans cet article, la validation par jumeau numérique signifie tester la logique de contrôle par rapport à un modèle d'équipement virtuel réaliste ou à une représentation de scénario pour voir si la séquence, les interverrouillages, les alarmes et les réponses analogiques se comportent comme prévu avant le déploiement réel. Cela ne signifie pas que la simulation est un substitut légalement suffisant pour les FAT, SAT, analyse des risques, vérifications de boucles ou réception sur site.

Cette définition délimitée s'aligne sur la littérature plus large sur les jumeaux numériques, qui traite généralement les jumeaux comme des environnements d'aide à la décision et de validation plutôt que comme des miroirs infaillibles de la réalité de l'usine (Tao et al., 2019 ; Jones et al., 2020). Un bon jumeau réduit l'incertitude. Il ne l'abolit pas.

La manière la plus sûre d'utiliser l'IA dans le contrôle-commande est de demander une structure, des hypothèses et des critères de validation plutôt qu'une génération de code aveugle. Demandez d'abord une ébauche de récit de contrôle. Ensuite, testez-la.

Un prompt faible ressemble à ceci :

• « Écris une logique Ladder pour une station de pompage. »

Un prompt plus fort ressemble à ceci :

- « Crée une ébauche de logique Ladder pour une séquence de pompes maître/esclave avec : Explique les hypothèses, les tags requis et ce qui doit être vérifié en simulation. »

• deux pompes,
• verrouillage sur niveau bas,
• démarrage sur niveau haut,
• anti-rebond de 5 secondes sur le commutateur de niveau bas,
• retour d'information de fonctionnement,
• alarme d'échec au démarrage,
• mode manuel/auto,
• alternance de la pompe maître après chaque cycle terminé.

Ce prompt est meilleur car il demande une structure d'ingénierie plutôt qu'un vidage de code. Il force l'assistant à exposer ses hypothèses et donne à l'utilisateur quelque chose de testable.

Un modèle de prompt pratique pour Yaga

Utilisez cette séquence :

Exemple : « Contrôler une station de pompage duplex avec alternance de la pompe maître. »

Exemple : « Verrouillage sur niveau très bas, alarme en cas d'échec au démarrage, déclenchement sur surcharge. »

Exemple : « Ajouter un anti-rebond de 3 secondes et un délai de confirmation de fonctionnement de 2 secondes. »

Exemple : « Lister les entrées, sorties, bits internes, temporisateurs et étapes de séquence requis. »

Exemple : « Que dois-je observer en simulation pour considérer cela comme correct ? »

1. Énoncez l'objectif du processus
2. Définissez les conditions anormales
3. Spécifiez les exigences de temporisation et de confirmation
4. Demandez les hypothèses de tags et les états de séquence
5. Demandez les critères de vérification

Cette dernière étape est importante. Les ingénieurs doivent demander à l'IA de définir des preuves, pas seulement de produire une sortie.

Les ingénieurs doivent valider le comportement, pas la qualité de la prose. Une explication plausible ou un modèle de barreau soigné ne suffit pas.

Avant de traiter la logique assistée par IA comme étant même digne d'une simulation, vérifiez :

Toutes les entrées, sorties, valeurs analogiques et tags internes requis sont-ils présents et correctement typés ?

• Intégrité du mappage des E/S

Chaque sortie critique est-elle contrôlée par une structure cohérente plutôt que par des écritures dispersées ?

• Contrôle de sortie à source unique

Les démarrages, arrêts, interverrouillages, défauts et réinitialisations sont-ils séparés proprement ?

• Logique de validation et de déclenchement

La séquence peut-elle entrer, maintenir et quitter chaque état attendu sans blocage ?

• Progression de l'état

Que se passe-t-il en cas de défaillance du capteur, d'échec de confirmation, de dépassement de délai, de surcharge ou de changement de mode opérateur ?

• Gestion des conditions anormales

Si des valeurs analogiques ou des instructions PID sont impliquées, les seuils, limites et bandes d'alarme se comportent-ils comme prévu ?

• Comportement analogique et PID

L'utilisateur peut-il démontrer la logique par rapport à un comportement de scénario réaliste, et pas seulement par une révision statique ?

• Preuve par simulation

C'est aussi là que le panneau des variables d'OLLA Lab est important. Un bon débogage dépend de la visualisation des états des tags, des valeurs analogiques et du comportement de la boucle de contrôle pendant que la logique s'exécute. Sans observabilité, le débogage devient du folklore.

Les ingénieurs doivent documenter un ensemble compact de preuves, pas une galerie de captures d'écran. Les responsables du recrutement, les instructeurs et les réviseurs seniors apprennent davantage d'un historique de défauts et de révisions que d'images finales polies.

Utilisez cette structure :

1. Description du système Décrivez le processus, l'équipement et l'objectif de contrôle en termes d'ingénierie simples.
2. Définition opérationnelle de « correct » Indiquez ce qui doit se produire pour que la logique soit considérée comme correcte en simulation. Incluez le comportement de la séquence, les interverrouillages, les alarmes et les conditions de confirmation.
3. Logique Ladder et état de l'équipement simulé Montrez les barreaux pertinents, les tags et l'état correspondant de la machine ou du processus en simulation.
4. Le cas de défaut injecté Documentez le défaut délibérément introduit ou découvert, tel qu'un chemin de maintien rompu, une mauvaise temporisation anti-rebond ou une sortie écrasée.
5. La révision effectuée Expliquez le changement de logique et pourquoi il résout le comportement observé.
6. Leçons apprises Résumez ce que le défaut a révélé sur l'ordre de balayage, la causalité, les hypothèses de processus ou le risque de mise en service.

Cette structure produit une preuve de raisonnement. C'est bien plus crédible que « voici mon fichier Ladder terminé ». Les fichiers terminés cachent les erreurs intéressantes, et les erreurs sont généralement là où l'ingénierie commence.

Non. Yaga est un coach de laboratoire délimité, pas un substitut à la révision d'ingénierie senior, aux méthodes de sécurité formelles ou à la validation sur site.

Cette limite n'est pas une formalité juridique ; c'est de l'honnêteté technique. La sécurité fonctionnelle, l'analyse des risques et l'approbation de mise en service nécessitent des méthodes et des responsabilités qui vont bien au-delà de la révision de code assistée par IA. L'IEC 61508 et les pratiques de sécurité connexes le soulignent clairement : la correction logicielle s'inscrit dans un cycle de vie plus large d'identification des dangers, de réduction des risques, de vérification, de validation et de contrôle de gestion (IEC, 2010 ; exida, 2024).

OLLA Lab et Yaga sont mieux compris comme des outils de répétition pour des tâches à haut risque que les ingénieurs débutants ont rarement l'occasion de pratiquer en toute sécurité sur des systèmes réels :

• valider la logique de contrôle,
• surveiller le comportement des E/S,
• tracer la cause et l'effet,
• gérer les conditions anormales,
• réviser la logique après un défaut,
• comparer l'état de l'équipement simulé par rapport à l'état Ladder.

C'est une valeur substantielle, et c'est suffisant.

Le rôle pratique de Yaga est de raccourcir le chemin entre « j'ai écrit quelque chose » et « je peux expliquer pourquoi cela fonctionne, pourquoi cela a échoué et ce qui a changé ». C'est la transition de la familiarité avec la syntaxe au jugement de mise en service.

Au sein d'OLLA Lab, ce rôle s'inscrit dans un environnement plus large qui comprend :

• un éditeur de logique Ladder basé sur le web avec des types d'instructions standard,
• des flux de travail guidés d'apprentissage du Ladder,
• un mode simulation pour une exécution et des tests en toute sécurité,
• une visibilité des variables et des E/S,
• des outils d'apprentissage analogiques et PID,
• des exercices industriels basés sur des scénarios,
• des flux de travail de validation de type jumeau numérique,
• des vues d'équipement 3D/WebXR/VR en option,
• des fonctionnalités de collaboration et de révision pour les contextes pédagogiques.

Yaga ne remplace pas ces composants. Il devient utile parce que ces composants existent déjà. Une bonne assistance dépend d'une bonne instrumentation ; c'est vrai dans les usines et dans les systèmes de formation.

- IEC 61508 Aperçu de la sécurité fonctionnelle - IEC 61131-3 Langages de programmation des automates programmables - NIST SP 800-207 Architecture Zero Trust - Tao et al. (2019) Jumeau numérique dans l'industrie (IEEE) - Kritzinger et al. (2018) Jumeau numérique dans la fabrication (IFAC) - Negri et al. (2017) Jumeau numérique dans les systèmes de production basés sur CPS - Ressources de sécurité fonctionnelle exida - U.S. Bureau of Labor Statistics