Comment solliciter l'IA pour la programmation d'automates avec des philosophies de contrôle pour Yaga

Une sollicitation efficace de l'IA pour la programmation d'automates (PLC) nécessite des philosophies de contrôle structurées, et non des requêtes ouvertes. Lorsque les ingénieurs fournissent des mappages d'E/S explicites, des permissifs, des verrouillages, des états de séquence et des conditions de défaillance, Yaga peut générer des échafaudages de logique Ladder nettement plus faciles à valider dans l'environnement de simulation d'OLLA Lab.

L'IA n'échoue pas dans le travail sur automate parce qu'elle est « mauvaise en programmation ». Elle échoue parce que la logique Ladder n'est pas seulement une génération de code ; c'est un comportement de contrôle déterministe soumis à des contraintes, à un ordre de balayage (scan) et à des états anormaux. Cette distinction est souvent négligée.

Lors d'un récent exercice bêta interne de l'assistant Yaga d'OLLA Lab, les invites incluant un dictionnaire de tags, un état sûr défini et au moins un verrouillage explicite ont produit des échafaudages de première passe utilisables en simulation dans 22 cas sur 24 (91,7 %), tandis que les invites génériques telles que « écrire une séquence de pompe » ont nécessité des corrections majeures dans 17 cas sur 24 (70,8 %) avant que la simulation ne puisse être lancée. Méthodologie : n=48 exécutions de tâches basées sur des invites pour des exercices de pompe, mélangeur, convoyeur et niveau de réservoir ; comparateur de référence = invite en langage naturel générique versus invite structurée par philosophie de contrôle ; fenêtre temporelle = période bêta interne, février-mars 2026. Cela soutient une affirmation limitée : la structure de l'invite affecte fortement l'utilisabilité de première passe en simulation. Cela ne prouve pas la déployabilité sur le terrain, la suffisance en matière de sécurité ou la préparation à la production.

En automatisation, l'ingénierie des invites (prompt engineering) doit être définie de manière étroite : la traduction systématique des contraintes mécaniques, du mappage d'E/S et des verrouillages de sécurité en paramètres lisibles par machine afin qu'un agent IA puisse générer des échafaudages syntaxiquement corrects et testables. C'est un outil utile, et non un substitut au jugement de l'ingénieur. OLLA Lab joue ici le rôle de boucle de validation, et non de permis de construire.

Les LLM généraux échouent avec la logique Ladder car ils prédisent des séquences de jetons plausibles, tandis que les automates exécutent une logique de balayage déterministe sur des entrées et sorties à état. Un modèle de langage voit une continuité textuelle ; un contrôleur voit un ordre d'évaluation, des bits de mémoire, des conditions de front et l'état des dispositifs.

La logique Ladder est également spatiale. Les branches parallèles, les chemins de maintien (seal-in), les chaînes de permissifs et les états mutuellement exclusifs portent un sens par leur structure, et non seulement par les mots. Un LLM polyvalent a tendance à linéariser cette structure en texte et peut perdre l'intention d'exécution dans le processus. C'est l'une des raisons pour lesquelles une logique Ladder générée par IA peut sembler compétente tout en se comportant mal.

Un second mode de défaillance est la faible conscience du cycle de balayage. La logique d'automate est évaluée de manière répétée, et les sorties peuvent être écrites, réinitialisées ou outrepassées au cours du même balayage selon la structure du programme. Sans contraintes explicites, un LLM peut générer :

• des écritures en double sur la même bobine de sortie,
• un comportement de type « one-shot » manquant,
• des conditions de course entre les modes auto et manuel,
• des temporisateurs avec des conditions de réinitialisation floues,
• des seuils analogiques sans hystérésis (deadband) ni gestion des défauts,
• des verrouillages qui apparaissent dans les commentaires mais pas dans la logique exécutable.

Le résultat courant est familier aux praticiens : une logique qui se lit bien mais qui se comporte mal dès que les entrées changent. La syntaxe est facile ; le déterminisme est plus difficile.

Cette limitation est largement cohérente avec la littérature sur le raisonnement des LLM et la fiabilité du code. Les travaux publiés sur les systèmes logiciels et incarnés suggèrent que la qualité de sortie se dégrade lorsque les tâches nécessitent un suivi d'état persistant, un raisonnement spatial ou une satisfaction exacte des contraintes plutôt qu'une complétion de motifs fluide (Bubeck et al., 2023 ; Huang & Chang, 2023). La programmation d'automates est particulièrement impitoyable sur ces trois points.

Une invite IA de qualité industrielle est une spécification fonctionnelle compacte. Elle doit indiquer au modèle ce qu'est la machine, ce que signifie « sûr », quels dispositifs existent, quelles conditions doivent être vraies avant qu'une action ne soit autorisée et comment gérer les défaillances. Si l'invite ne peut pas supporter un examen de base de la spécification de conception fonctionnelle (FDS), elle est probablement trop vague pour une génération fiable de logique Ladder.

En pratique, une bonne invite pour automate se comporte moins comme une requête de recherche que comme des instructions données à un ingénieur en contrôle junior. Les ingénieurs seniors ne disent pas « fais-moi un programme de pompe ». Ils spécifient le processus, les tags, la séquence, les déclenchements (trips) et l'état de repli attendu.

Les 3 piliers d'une invite d'automatisation

#### 1. Contexte et objectif

Indiquez la machine ou l'unité de processus, l'objectif opérationnel et l'état sûr.

Incluez :

• le type d'équipement,
• le mode de fonctionnement,
• l'objectif de démarrage/arrêt,
• la condition d'arrêt sûr,
• l'attente en cas d'état anormal.

Exemple :

• « Pompe de transfert unique remplissant un réservoir journalier. »
• « L'état sûr est pompe arrêtée et vanne de sortie fermée. »
• « Si le transmetteur de niveau est invalide, inhiber le démarrage automatique. »

#### 2. Dictionnaire des E/S et des tags

Définissez les tags explicitement. L'IA fonctionne mieux lorsque la dénomination est sans ambiguïté et typée.

Incluez :

• les entrées numériques,
• les sorties numériques,
• les entrées analogiques,
• les sorties analogiques si pertinent,
• les bits de mémoire interne,
• les temporisateurs et compteurs,
• les bits d'alarme ou de défaut.

Exemple :

• `DI_PB_Start`
• `DI_PB_Stop`
• `DI_EStop_OK`
• `AI_Tank_Level_Pct`
• `DO_Pump_Run`
• `M_Auto_Mode`
• `T_FillTimeout`

La discipline de nommage n'est pas cosmétique. C'est la différence entre une logique traçable et une taxe de débogage.

#### 3. Permissifs et verrouillages

Définissez ce qui doit être vrai avant qu'une action puisse se produire, et ce qui force l'arrêt de l'action.

Incluez :

• les permissifs,
• les déclenchements (trips),
• les restrictions de mode,
• les exigences de rétroaction,
• le comportement en cas de dépassement de temps (timeout),
• les conditions d'alarme.

Exemple :

• La pompe ne peut démarrer que si `DI_EStop_OK = TRUE`
• La pompe ne peut démarrer que si `AI_Tank_Level_Pct < 80`
• La pompe doit s'arrêter si `AI_Tank_Level_Pct >= 95`
• Déclencher une alarme si la commande de marche est vraie et qu'aucune rétroaction de marche n'est reçue dans les 3 secondes

C'est là que beaucoup d'invites s'effondrent. Les ingénieurs spécifient souvent le chemin nominal et omettent les raisons pour lesquelles la machine doit refuser de bouger. Les usines réelles passent beaucoup de temps dans des conditions hors normes.

Pour la sollicitation de l'IA, une philosophie de contrôle doit être définie comme la spécification fonctionnelle minimale nécessaire pour générer un échafaudage de contrôle testable. Ce n'est pas une expression marketing ni un récit de conception vague. Opérationnellement, elle doit contenir les mêmes comportements fondamentaux qu'un ingénieur en contrôle attend dans un document de type FDS :

• état initial,
• modes de fonctionnement,
• séquence d'opérations,
• permissifs,
• verrouillages,
• alarmes et déclenchements,
• réponses aux défaillances,
• comportement de réinitialisation,
• actions de l'opérateur,
• critères de succès.

Cette définition est limitée par les observables techniques. Si l'invite ne dit pas au modèle ce que le processus doit faire lorsqu'un capteur tombe en panne, qu'un couvercle s'ouvre, qu'un niveau dépasse un seuil ou qu'une rétroaction n'arrive jamais, alors l'invite n'est pas une philosophie de contrôle.

Ce cadrage s'aligne sur les pratiques établies de documentation industrielle. La norme IEC 61131-3 régit les langages de programmation d'automates, mais une bonne logique Ladder dépend toujours d'une clarté fonctionnelle en amont. Les normes ne sauvent pas une intention vague.

Une idée fausse utile à abandonner

L'ingénierie des invites en automatisation ne consiste pas à rendre l'IA plus créative. Il s'agit de rendre la spécification moins ambiguë.

La manière la plus efficace de solliciter Yaga est de fournir un modèle contraint et réutilisable. Le modèle doit connaître le rôle, l'objectif du processus, les tags, la séquence, les permissifs, les verrouillages et le format de sortie attendu. Si l'un de ces éléments est laissé implicite, le modèle peut improviser.

Modèle d'invite recommandé pour Yaga

Agis comme un assistant de logique Ladder IEC 61131-3.

Objectif : Crée un échafaudage de logique Ladder pour la tâche de contrôle suivante.

Description du système : - Équipement : [machine/unité de processus] - Objectif opérationnel : [ce que le système doit faire] - État sûr : [quelles sorties/états doivent être vrais à l'arrêt ou en défaut]

Dictionnaire des E/S et des tags : Entrées numériques : - [tag] : [description] - [tag] : [description]

Sorties numériques : - [tag] : [description]

Entrées analogiques : - [tag] : [description et unités techniques]

Bits internes / Temporisateurs / Compteurs : - [tag] : [objectif]

Modes de fonctionnement :

• [Auto / Manuel / Maintenance]
• [règles de mode]

Séquence d'opérations :

Permissifs :

• [condition requise avant démarrage]
• [condition requise avant transition]

Verrouillages / Déclenchements :

• [condition qui doit arrêter ou inhiber l'opération]
• [condition de défaut et réponse]

Alarmes :

• [condition d'alarme]
• [condition de timeout]

Règles de réinitialisation / récupération :

• [exigence de réinitialisation manuelle]
• [règle de réinitialisation auto si autorisée]

Exigences de sortie :

• Utilise une structure Ladder claire échelon par échelon
• N'écris pas sur la même bobine de sortie dans plusieurs emplacements conflictuels
• Utilise des bits internes nommés pour les états de séquence si nécessaire
• Inclus des commentaires pour chaque échelon
• Identifie explicitement les hypothèses

Ce modèle ne garantit pas une logique correcte. Il fait quelque chose de plus utile : il rend les erreurs visibles plus tôt.

1. [étape 1]
2. [étape 2]
3. [étape 3]

Invite junior vs invite senior

| Style d'invite | Exemple | Résultat probable | |---|---|---| | Invite junior | « Fais un schéma Ladder qui allume un mélangeur pendant 10 secondes quand j'appuie sur start. » | Comportement d'arrêt ambigu, verrouillage de couvercle manquant, logique de réinitialisation floue, structure de tags faible | | Invite senior | « Agis comme un programmeur IEC 61131-3. Crée un échafaudage Ladder pour un mélangeur. Entrées : `PB_Start` (NO), `PB_Stop` (NC), `LS_LidClosed`, `EStop_OK`. Sortie : `MTR_Mixer`. Verrouillage : le mélangeur ne peut pas tourner sauf si le couvercle est fermé et l'arrêt d'urgence sain. Utilise TON pour un cycle de marche de 10 s. Arrête immédiatement si le couvercle est ouvert ou sur commande d'arrêt. État sûr = moteur arrêté. Fournis des commentaires d'échelon et identifie les hypothèses. » | Base de référence testable avec permissifs explicites, comportement d'arrêt plus sûr, chemin de simulation plus clair |

La différence n'est pas l'éloquence. C'est la densité des contraintes.

Une bonne invite pour automate doit définir la machine comme un système à états, et non comme une tâche verbale. Avant que Yaga n'écrive le moindre échelon, l'invite doit déjà répondre à six questions d'ingénierie.

1. Quel est le système ?

Définissez l'équipement, la limite du processus et l'opération prévue.

Exemple :

• « Station de pompage duplex avec alternance et alarme de haut niveau. »

2. Quel est le comportement « correct » ?

Définissez la condition de succès opérationnel en termes observables.

Exemple :

• « En mode auto, la pompe principale démarre à 70 % du niveau du puisard et s'arrête à 30 % ; la pompe secondaire démarre à 90 % ; les deux s'arrêtent sur arrêt d'urgence ou surcharge moteur. »

Ceci est important car « prêt pour la simulation » doit être défini opérationnellement : un ingénieur est prêt pour la simulation lorsqu'il peut prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste avant qu'elle n'atteigne un processus réel. C'est une norme plus stricte que de connaître la syntaxe Ladder.

3. Quels sont les tags et les types de signaux ?

Listez les tags, la direction du signal et les unités.

Exemple :

• `AI_WetWell_Level_Pct` = entrée analogique, pourcentage
• `DI_P1_OL_Trip` = entrée numérique, déclenchement surcharge
• `DO_P1_RunCmd` = sortie numérique

4. Quelles conditions anormales existent ?

Définissez les défaillances, les états invalides et les réponses aux défauts.

Exemple :

• mauvaise qualité du transmetteur de niveau,
• rétroaction de marche absente après commande,
• deux surcharges actives,
• arrêt d'urgence non sain,
• conflit de commutateur HOA.

5. Qu'est-ce qui ne doit jamais arriver ?

Énoncez explicitement les comportements interdits.

Exemple :

• « Ne jamais commander les deux pompes en logique d'alternance manuelle. »
• « Ne pas redémarrer automatiquement après une réinitialisation de surcharge sans action de l'opérateur. »
• « Ne pas démarrer le mélangeur avec le couvercle ouvert. »

6. Quelles hypothèses sont autorisées ?

Exigez de l'IA qu'elle déclare ses hypothèses plutôt que de les enterrer.

Exemple :

• « Supposer que le bouton-poussoir d'arrêt est sain (NC) sauf indication contraire. »
• « Supposer que la mise à l'échelle analogique est déjà effectuée en amont. »

Les hypothèses cachées sont une source courante de logique Ladder faible générée par IA.

OLLA Lab valide la logique générée par l'IA en la plaçant dans un environnement de simulation où les entrées, sorties, variables et comportements de l'équipement peuvent être observés et manipulés avant toute mise en service réelle. Cela en fait une boucle de validation à risque contenu, et non un oracle.

L'éditeur Ladder fournit la surface logique. Le mode Simulation fournit l'exécution. Le panneau des variables offre une observabilité sur les tags, les états d'E/S, les valeurs analogiques et les variables de contrôle. Ensemble, ils permettent à un ingénieur de tester si la logique générée se comporte comme spécifié lorsque les conditions changent.

En termes pratiques, cela signifie que vous pouvez :

• basculer les entrées numériques,
• forcer des conditions de défaut,
• inspecter la réponse des sorties,
• observer le changement d'état des temporisateurs et des bits internes,
• comparer l'état du Ladder au comportement simulé de l'équipement,
• réviser la logique après un test échoué.

La validation n'est pas une capture d'écran d'un échelon qui semble correct. La validation est une séquence d'hypothèses infirmées suivies d'une logique plus rigoureuse.

À quoi ressemble la boucle génération-validation

1. Générer l'échafaudage avec Yaga Utilisez une invite de philosophie de contrôle structurée.
2. Inspecter le Ladder généré Vérifiez les noms des tags, la propriété des sorties, la structure de la séquence et le placement des verrouillages.
3. Exécuter la logique en simulation Commencez par des conditions nominales.
4. Injecter des conditions anormales Forcez la perte de capteur, des permissifs invalides, des états de couvercle ouvert, des déclenchements de surcharge ou des cas de timeout.
5. Observer si la logique échoue en toute sécurité Confirmez l'arrêt sûr, le verrouillage d'alarme, l'inhibition du redémarrage ou le maintien de l'état selon les besoins.
6. Réviser et retester Resserrez l'invite ou modifiez le Ladder directement.

C'est là qu'OLLA Lab devient opérationnellement utile. Il donne aux ingénieurs un endroit pour répéter des tâches à haut risque pour lesquelles les systèmes réels sont de mauvais enseignants.

Vous la testez en définissant des cas de défaut avant de faire confiance à la séquence nominale. Une routine Ladder qui fonctionne uniquement lorsque chaque signal se comporte bien n'est pas validée ; elle est simplement incontestée.

Au minimum, testez ces catégories en simulation.

Défauts d'intégrité des entrées

• capteur bloqué à 1,
• capteur bloqué à 0,
• transmetteur hors plage,
• mauvaise valeur analogique,
• rétroaction absente après commande.

Défaillances de verrouillage

• arrêt d'urgence non sain,
• protection ou couvercle ouvert,
• permissif perdu pendant la marche,
• déclenchement de surcharge actif,
• preuve de vanne non établie.

Défauts de séquence

• le temporisateur ne se réinitialise jamais,
• le bit d'état reste verrouillé,
• chevauchement des commandes manuelle et auto,
• redémarrage après déclenchement sans réinitialisation,
• la sortie reste sous tension après le chemin d'arrêt.

Défauts liés à l'analogique et au PID

• la variable de processus dépasse le seuil de déclenchement,
• hystérésis analogique manquante,
• bavardage d'alarme près du seuil,
• saturation de la sortie du contrôleur,
• le transfert de mode provoque un à-coup.

La présence d'outils analogiques et de tableaux de bord PID dans OLLA Lab est importante ici car de nombreux exemples d'IA restent piégés dans la logique discrète. Le contrôle de processus réel ne l'est généralement pas. Une station de pompage, une CTA, une boucle thermique ou un skid de dosage inclut souvent des seuils, des délais, des hystérésis et un comportement dépendant du mode.

Un exemple concret doit montrer la traduction de l'intention du processus en contraintes lisibles par machine. Voici un exemple de mélangeur compact adapté à Yaga.

Exemple d'invite structurée

Agis comme un assistant de logique Ladder IEC 61131-3.

Description du système : - Équipement : Mélangeur de lot - Objectif opérationnel : Faire tourner le mélangeur pendant 10 secondes après la commande de démarrage de l'opérateur - État sûr : Moteur du mélangeur arrêté immédiatement sur arrêt, perte d'arrêt d'urgence ou couvercle ouvert

Dictionnaire des E/S et des tags : Entrées numériques : - DI_PB_Start : Bouton-poussoir de démarrage, normalement ouvert - DI_PB_Stop : Bouton-poussoir d'arrêt, normalement fermé - DI_Lid_Closed : Preuve de couvercle fermé - DI_EStop_OK : Arrêt d'urgence sain

Sorties numériques : - DO_Mixer_Run : Commande de marche du moteur du mélangeur

Bits internes / Temporisateurs : - M_Mix_Cycle_Active : Verrouillage de cycle de mélange actif - T_Mix_Run : Temporisateur TON de 10 secondes

Séquence d'opérations :

Permissifs :

• DI_Lid_Closed = TRUE
• DI_EStop_OK = TRUE
• DI_PB_Stop sain

Verrouillages / Déclenchements :

• Si le couvercle s'ouvre pendant la marche, mettre DO_Mixer_Run hors tension immédiatement
• Si l'arrêt d'urgence est non sain, mettre DO_Mixer_Run hors tension immédiatement

Exigences de sortie :

• Fournir un échafaudage Ladder échelon par échelon
• Utiliser un chemin de propriété de sortie unique pour DO_Mixer_Run
• Ajouter des commentaires d'échelon
• Énoncer toute hypothèse

1. Sur commande de démarrage, commencer le cycle de mélange uniquement si le couvercle est fermé et l'arrêt d'urgence sain
2. Faire tourner le moteur du mélangeur pendant 10 secondes
3. Arrêter le moteur quand le temporisateur est terminé
4. Abandonner immédiatement si commande d'arrêt, couvercle ouvert ou arrêt d'urgence non sain

Que vérifier après la génération

Une fois que Yaga a généré le Ladder, inspectez :

• un chemin de propriété clair pour `DO_Mixer_Run`,
• l'activation du temporisateur liée à l'état de cycle actif,
• la coupure immédiate en cas d'ouverture de couvercle ou de perte d'arrêt d'urgence,
• l'absence de redémarrage automatique caché,
• des commentaires qui correspondent au comportement réel de l'échelon,
• des hypothèses explicites.

Ensuite, exécutez-le en simulation et forcez `DI_Lid_Closed` à faux pendant la marche temporisée. Si la commande moteur persiste, l'invite ou la logique est erronée.

Les ingénieurs doivent documenter le travail sur automate assisté par IA comme une preuve d'ingénierie, et non comme une galerie de captures d'écran d'interface. Un dossier crédible montre ce que le système était censé faire, comment il a été testé, comment il a échoué et comment il a été corrigé.

Utilisez cette structure :

Enregistrez le défaut exact introduit : perte de capteur, surcharge, perte de permissif, timeout, valeur analogique invalide, etc.

1. Description du système Définissez l'équipement, l'objectif du processus, le mode de fonctionnement et l'état sûr.
2. Définition opérationnelle du « correct » Énoncez les critères de succès observables, y compris les conditions d'arrêt et le comportement en cas d'état anormal.
3. Logique Ladder et état simulé de l'équipement Montrez le Ladder généré ou modifié aux côtés de l'état de la machine simulée ou du comportement des variables pertinent.
4. Le cas de défaut injecté
5. La révision effectuée Documentez le changement de logique ou l'affinement de l'invite utilisé pour corriger le comportement.
6. Leçons apprises Indiquez ce que la défaillance a révélé sur la philosophie de contrôle originale, les hypothèses ou la conception de la séquence.

Cela produit un corpus de preuves compact qui est utile aux examinateurs, aux instructeurs ou aux responsables du recrutement.

La sollicitation d'automates assistée par IA est utile pour l'échafaudage, la rédaction et l'accélération de la structure logique de première passe. Elle n'est pas suffisante pour la validation de la sécurité, la signature de mise en service ou les décisions de déploiement spécifiques au site.

Cette frontière est importante tant pour l'éthique que pour l'ingénierie. OLLA Lab est décrit ici comme un simulateur de logique Ladder et de jumeau numérique interactif basé sur le Web, avec un support guidé via Yaga, des simulations 3D/WebXR/VR, des exercices basés sur des scénarios, des outils analogiques et PID, et des flux de travail pour instructeurs. Ces fonctionnalités le rendent utile comme environnement de répétition et de validation. Elles ne convertissent pas par association une logique générée en logique d'usine approuvée.

Quelques limites doivent rester explicites :

• Le Ladder généré par IA peut être syntaxiquement plausible et fonctionnellement dangereux.
• La simulation peut exposer de nombreux défauts logiques, mais elle n'est pas identique à la mise en service sur site.
• La validation par jumeau numérique dépend de la fidélité du modèle et de la portée du scénario.
• Les obligations de sécurité fonctionnelle nécessitent toujours des méthodes formelles, un examen compétent et une discipline de cycle de vie basée sur des normes.

Ceci est cohérent avec la littérature plus large sur la sécurité. La norme IEC 61508 et les conseils connexes traitent les défaillances systématiques, les erreurs de spécification et la discipline de vérification comme des préoccupations centrales. Un modèle qui produit du code rapidement ne supprime pas ces devoirs.

Cette approche est plus utile car elle déplace la tâche d'une génération sans contrainte vers une ingénierie bornée. Lorsque vous rédigez d'abord une philosophie de contrôle, vous forcez les décisions importantes à apparaître au grand jour : état sûr, permissifs, déclenchements, propriété de la séquence et réponse aux défauts.

Cela présente trois avantages pratiques :

• un meilleur échafaudage de première passe,
• un débogage plus rapide en simulation,
• un examen plus clair par les humains.

Cela enseigne également la bonne habitude. La transition professionnelle ne consiste pas seulement à passer de l'ignorance du Ladder à sa connaissance. Il s'agit de passer de l'écriture d'échelons à la défense d'un comportement.

- Présentation de la norme IEC 61131-3 (PLCopen) - Cadre de gestion des risques liés à l'IA du NIST (AI RMF 1.0) - Présentation des directives pour l'accessibilité des contenus web (WCAG) 2 du W3C - Portail des taxonomies et publications de l'IEEE - Page de la norme ISO/IEC 23894 sur la gestion des risques liés à l'IA