Comment corriger les échecs de dialectes API des LLM grâce à une validation adaptée aux fournisseurs

Pour combler le fossé entre les LLM et les API réels, les ingénieurs doivent valider le code généré par IA par rapport aux dialectes matériels spécifiques et au comportement d'exécution déterministe. Étant donné que les environnements API propriétaires sont mal représentés dans les données d'entraînement des modèles publics, OLLA Lab fournit un environnement de simulation délimité pour exposer les échecs d'adressage, de séquençage et d'interverrouillage avant le déploiement.

L'échec des LLM dans le travail sur API n'est pas principalement un problème de syntaxe. C'est un problème de déployabilité. Un modèle peut produire du Ladder ou du Structured Text qui semble plausible, cite correctement les noms de langage de la norme IEC 61131-3, et échouer tout de même dès qu'il rencontre un compilateur de fournisseur réel, un timing de balayage réel ou une chaîne de permissives réelle.

Lors d'une récente analyse comparative interne par l'équipe QA d'Ampergon Vallis Lab, 82 % des prompts « zero-shot » demandant du Structured Text Mitsubishi pour un séquenceur de pompe standard ont produit un adressage de périphérique invalide, une utilisation de temporisateurs non native ou des constructions de dialectes mixtes. Cela soutient une affirmation étroite : la sortie brute des LLM n'est pas fiable pour le travail sur API spécifique à un fournisseur sans validation. Cela ne prouve pas que tout développement d'API assisté par IA échoue, ni que chaque modèle fonctionne aussi mal.

Cette distinction est importante. Dans le domaine du contrôle, « presque correct » est souvent juste un chemin plus lent vers la liste des défauts.

La norme IEC 61131-3 définit des familles de langages, et non une réalité d'implémentation universelle. La norme vous donne des catégories telles que le Ladder Diagram et le Structured Text ; elle n'efface pas les modèles d'adressage spécifiques aux fournisseurs, la sémantique des temporisateurs, les attentes des compilateurs, les structures de projet ou les flux de travail d'ingénierie.

Une idée fausse courante est que « conforme à la norme IEC » signifie « suffisamment portable pour qu'un LLM puisse l'inférer correctement ». Ce n'est pas le cas. La conformité au niveau de la norme n'est pas la même chose que l'équivalence de dialecte au niveau du contrôleur. La classe de syntaxe et le code déployable sont deux choses différentes.

Le déficit de données propriétaires

Les LLM généralistes sont fortement entraînés sur des corpus de logiciels publics. Le code d'automatisation industrielle est différent pour une raison simple : une grande partie du matériel utile est verrouillée dans des environnements d'ingénierie propriétaires et des archives de projets privés.

En pratique, cela signifie que :

• Les dépôts publics contiennent des volumes énormes de Python, JavaScript, C et C++.
• Les structures de projet brutes Rockwell `.ACD`, Siemens TIA et les actifs de projet Mitsubishi GX Works sont rarement disponibles en tant que matériel d'entraînement ouvert.
• Une grande partie de la logique spécifique aux fournisseurs existe dans les sauvegardes des intégrateurs, les archives d'usine, les projets OEM et les ordinateurs portables de mise en service — rien de tout cela n'est du matériel de corpus public standard.
• En conséquence, le modèle interpole souvent à partir de manuels, de fragments de forums, d'exemples de formation et de modèles de code adjacents plutôt qu'à partir d'une large exposition à des projets API de qualité industrielle.

C'est pourquoi un LLM peut sembler confiant tout en étant mécaniquement faux. La confiance est bon marché ; l'acceptation par le compilateur ne l'est pas.

Comment les architectures mémoire des fournisseurs créent-elles des échecs de dialectes ?

L'échec du dialecte du fournisseur commence généralement au niveau du modèle de mémoire. Le modèle n'a pas seulement besoin du bon nom d'instruction. Il a besoin des bonnes hypothèses sur la façon dont le contrôleur nomme, stocke et évalue l'état.

• Siemens
• Peut utiliser des formes absolues telles que `%I0.0` et `%Q0.0`
• Peut également s'appuyer sur l'accès symbolique et le comportement des blocs optimisés
• La structure des blocs de données et les modèles d'accès sont importants pour la validité

- Utilise couramment des structures basées sur des tags telles que `Local:1:I.Data.0`

• Rockwell
• Les membres des temporisateurs et des compteurs suivent des conventions d'objets spécifiques au fournisseur
• La structure UDT, l'aliasing et le comportement des tâches façonnent la logique utilisable

• Mitsubishi
• Utilise un adressage orienté périphérique tel que `X`, `Y`, `M`, `D`, `T`, `C`
• L'interprétation des adresses peut impliquer des conventions octales ou hexadécimales selon la famille et le contexte
• Les LLM interprètent fréquemment cela à tort comme des tableaux booléens génériques ou inventent une notation hybride

Le résultat est prévisible : le modèle génère du code qui n'a sa place nulle part. Ce n'est pas du Siemens. Pas du Rockwell. Pas du Mitsubishi. C'est un compromis diplomatique entre des manuels qui n'ont jamais eu à compiler ensemble.

L'hallucination la plus courante est le mélange d'instructions entre fournisseurs. Le code semble familier parce que chaque fragment est familier. Le problème est que les fragments sont familiers à des écosystèmes différents.

Quelles familles d'instructions les LLM confondent-ils le plus souvent ?

Les LLM mélangent fréquemment les conventions de temporisateurs, de compteurs et de gestion d'état entre les fournisseurs. Cela produit ce que les ingénieurs en contrôle reconnaissent immédiatement comme une logique « Frankenstein » : visuellement plausible, opérationnellement invalide.

| Fournisseur | Forme de temporisateur native ou courante | Erreur LLM typique | |---|---|---| | Rockwell | `TON` avec des membres tels que `.EN`, `.TT`, `.DN` | Applique la sémantique des membres Rockwell à des structures de temporisateurs non-Rockwell | | Siemens | Blocs de temporisateurs spécifiques au fournisseur tels que `S_ODT` ou constructions de style IEC dans le contexte Siemens | Invente des bits de complétion de style `.DN` ou un accès aux membres de type Rockwell | | Mitsubishi | Formes de périphérique/temporisateur telles que `OUT T0` en utilisation orientée Ladder | Remplace les temporisateurs de périphérique par une syntaxe de temporisateur IEC générique ou des constructions ST hybrides non prises en charge dans le contexte |

D'autres hallucinations fréquentes incluent :

- Mélanger `%IX0.0`, `I:0/0` et `X0` dans une même routine

• Utiliser des bits de fin de type Rockwell sur des blocs de temporisateurs Siemens
• Traiter les périphériques Mitsubishi comme des tableaux booléens symboliques
• Inventer des signatures de fonction non prises en charge pour des comparateurs ou des blocs PID
• Écrire du ST générique qui est syntaxiquement propre mais non déployable par le fournisseur

Exemple halluciné vs exemple adapté au fournisseur

Ci-dessous une illustration simplifiée. Ce n'est pas un exemple de projet Mitsubishi complet, et cette limite est importante. Le but est de montrer le mode de défaillance.

Logique de temporisateur de style ST générique hallucinée

IF Start_Pump AND NOT Fault THEN TON_1(IN := TRUE, PT := T#5s); END_IF;

IF TON_1.Q THEN Pump_Output := TRUE; END_IF;

Concept Ladder/périphérique orienté Mitsubishi que l'ingénieur doit réellement valider

|----[ X0 ]----[/ M100 ]----------------[ OUT T0 K50 ]----| |----[ T0 ]-----------------------------------( Y0 )------|

Pourquoi cela est important :

• Le premier exemple reflète des attentes génériques de style IEC.
• Le second reflète une gestion de temporisateur orientée périphérique qui doit être construite et validée dans le contexte du fournisseur cible.
• Un LLM peut produire le premier avec une confiance totale même lorsque l'environnement cible attend le second.

C'est exactement là qu'un environnement de validation devient utile. Non pas parce qu'il rend le modèle intelligent, mais parce qu'il rend l'échec visible.

Les API ne s'exécutent pas comme des applications web ou des scripts. Ils s'exécutent dans un balayage déterministe : lecture des entrées, exécution de la logique, écriture des sorties. Si le modèle suppose une mutation d'état immédiate, il générera une logique qui semble correcte en séquence mais qui se comporte de manière incorrecte sur un contrôleur.

C'est le mode de défaillance le plus profond. Les erreurs de syntaxe sont miséricordieuses car elles s'arrêtent tôt.

Qu'est-ce que le sophisme du « semble correct » dans la logique API ?

La logique API générée par IA échoue souvent parce qu'elle est écrite comme si chaque ligne changeait le monde physique immédiatement. Dans un API, l'évaluation interne et la mise à jour de la sortie physique sont séparées par le cycle de balayage.

Un modèle de défaillance typique ressemble à ceci :

• Le modèle active une sortie sous une condition.
• Quelques lignes plus tard, il réinitialise la même sortie sous une autre condition.
• Dans un état d'esprit de programmation séquentielle, l'auteur imagine qu'un bref événement « on » s'est produit.
• Dans un balayage API, l'état logique final à la fin de l'évaluation l'emporte avant que les sorties physiques ne soient écrites.

La sortie ne s'active jamais réellement. Sur le papier, la séquence semblait correcte. Sur un processus en direct, rien ne se passe à part de la confusion et un temps de dépannage inutile.

C'est une voie vers le syndrome de la double bobine, les écritures d'état concurrentes et le séquençage fragile. La machine n'est pas impressionnée par une intention élégante.

Pourquoi les interverrouillages et les permissives exposent-ils rapidement une logique IA faible ?

Les interverrouillages forcent la logique à respecter l'état du processus, pas seulement l'état symbolique. C'est là que la sortie IA générique a tendance à se briser.

Les exemples incluent :

• Ouvrir une vanne de vidange alors qu'un moteur de mélangeur est encore en marche
• Démarrer une pompe de secours sans confirmer la défaillance de la pompe principale ou l'état d'arrêt
• Activer un chauffage sans preuve de flux d'air
• Réinitialiser une condition de déclenchement sans effacer le défaut initial
• Faire avancer une étape de séquence sans confirmation de retour

Ce ne sont pas des cas limites. Ce sont des responsabilités de contrôle ordinaires. Lors de la mise en service, la logique dangereuse n'est souvent pas le code qui plante. C'est le code qui se comporte presque correctement jusqu'à ce que le processus cesse d'être poli.

« Prêt pour la simulation » doit être défini opérationnellement, et non cosmétiquement. Cela ne signifie pas que quelqu'un peut dessiner une syntaxe Ladder ou produire une capture d'écran propre. Cela signifie que l'ingénieur peut prouver, observer, diagnostiquer et durcir la logique de contrôle par rapport à un comportement de processus réaliste avant que cette logique n'atteigne un système en direct.

Un ingénieur « prêt pour la simulation » peut :

• mapper l'état Ladder à l'état de l'équipement simulé,
• surveiller les E/S et les tags internes pendant l'exécution,
• tester les permissives, les déclenchements et les conditions anormales,
• injecter des défauts délibérément,
• réviser la logique après avoir observé une défaillance,
• et expliquer pourquoi la logique révisée est plus correcte.

C'est le véritable seuil : syntaxe versus déployabilité. L'un est facile à simuler pendant quelques minutes. L'autre survit au contact avec un processus.

L'utilisation sûre de l'IA dans les contrôles nécessite une couche de validation. OLLA Lab est mieux compris comme cette couche : un environnement basé sur le web où les ingénieurs construisent une logique Ladder, observent le comportement des variables, lient la logique à des scénarios réalistes et testent si l'intention de contrôle générée survit à une simulation déterministe.

C'est une affirmation délimitée. OLLA Lab n'est pas un substitut aux tests d'acceptation de l'IDE du fournisseur, au FAT/SAT sur site ou à l'évaluation de la sécurité fonctionnelle. C'est un endroit pratique pour répéter un comportement logique à haut risque avant que quiconque ne soit tenté de faire confiance à une réponse plausible.

À quoi ressemble le flux de travail Générer → Simuler → Réviser ?

Le flux de travail utile est simple :

• Utilisez un LLM généraliste ou GeniAI (d'Ampergon Vallis) pour esquisser des idées de logique, des structures de séquence, des conditions d'alarme ou des modèles de barreaux (rungs).
• Traitez la sortie comme un brouillon, pas comme une preuve.

• Recréez la logique dans l'éditeur Ladder basé sur navigateur d'OLLA Lab.
• Utilisez des contacts, des bobines, des temporisateurs, des compteurs, des comparateurs, des fonctions mathématiques et PID selon les besoins.
• Rendez l'intention du tag explicite. Une dénomination ambiguë cache un raisonnement faible.

• Connectez les variables et les E/S à un scénario réaliste dans OLLA Lab.
• Utilisez le panneau des variables pour inspecter les entrées, les sorties, les valeurs analogiques et les états de contrôle.
• Le cas échéant, alignez la logique avec les objectifs du scénario, les interverrouillages, les dangers et les notes de mise en service.

• Exécutez la logique en mode simulation.
• Basculez les entrées, observez les sorties, inspectez les transitions de variables et testez la progression de la séquence.
• Vérifiez la causalité, pas seulement l'apparence du barreau.

• Corrigez les conditions de course, les permissives manquantes, les hypothèses invalides et la mauvaise gestion des défauts.
• Réexécutez jusqu'à ce que la logique se comporte correctement dans des états normaux et anormaux.

1. Générer
2. Construire
3. Lier
4. Simuler
5. Réviser

C'est là qu'OLLA Lab devient opérationnellement utile. Il donne à l'ingénieur un endroit déterministe pour observer les hypothèses générées par l'IA échouer face au comportement d'un processus simulé.

Comment les scénarios OLLA Lab améliorent-ils la qualité de la validation ?

Le contexte du scénario améliore la validation car la logique de contrôle n'est significative que lorsqu'elle est liée au comportement de l'équipement. OLLA Lab inclut des préréglages industriels réalistes dans les domaines de la fabrication, de l'eau et des eaux usées, du CVC, de la chimie, de la pharmacie, de l'entreposage, de l'agroalimentaire, des services publics et des domaines connexes.

Cela compte pour trois raisons :

• La logique de séquence devient observable. Une pompe, un convoyeur, un mélangeur, une CTA ou un skid a un état, un retour d'information et des modes de défaillance.
• Les interverrouillages gagnent en contexte. Une permissive est plus facile à vérifier lorsqu'il existe une raison visible à son existence.
• La gestion des défauts devient testable. Les seuils d'alarme, les échecs de preuve, les déclenchements et les conditions de redémarrage peuvent être exercés délibérément.

Que devraient réellement documenter les ingénieurs comme preuve de compétence ?

Une galerie de captures d'écran n'est pas une preuve d'ingénierie. Un dossier de validation compact l'est.

Utilisez cette structure :

Indiquez ce que signifie le succès en termes observables : conditions de démarrage, conditions d'arrêt, interverrouillages, alarmes, timing, seuils analogiques et comportement de défaillance sécurisé.

Introduisez une condition anormale délibérée : preuve échouée, entrée bloquée, niveau haut, surcharge moteur, dérive de capteur ou dépassement de délai de séquence.

Expliquez la distinction d'ingénierie découverte : timing de balayage, propriété de l'état, conception de permissive, bande morte d'alarme, comportement de redémarrage ou logique de récupération de l'opérateur.

1. Description du système Définissez la machine ou le processus, l'objectif de contrôle et les E/S pertinentes.
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé Montrez la logique et le comportement de l'équipement correspondant en simulation.
4. Le cas de défaut injecté
5. La révision effectuée Documentez ce qui a changé dans la logique et pourquoi.
6. Leçons apprises

Les LLM n'échouent pas dans le travail sur API parce que l'automatisation est trop obscure pour l'IA. Ils échouent parce que les dialectes des fournisseurs, l'exécution déterministe et les interverrouillages de processus ne pardonnent pas l'approximation. La bonne réponse n'est pas d'interdire les brouillons d'IA ou de leur faire confiance aveuglément. C'est de les placer dans un flux de travail de validation discipliné.

Ce flux de travail est Générer → Simuler → Réviser. Dans le cadre d'Ampergon Vallis, c'est ce qui rend un ingénieur « prêt pour la simulation » : non pas la capacité de produire du code rapidement, mais la capacité de prouver si ce code se comporte correctement dans des conditions réalistes.

OLLA Lab s'intègre dans ce flux de travail de preuve en tant qu'environnement de simulation de logique Ladder et de jumeau numérique basé sur le web où les ingénieurs peuvent tester la causalité, inspecter les E/S, répéter les défauts et réviser la logique avant qu'elle ne s'approche d'un processus en direct.

Équipe technique d'Ampergon Vallis Lab, spécialisée dans l'intégration de l'IA et la validation des systèmes de contrôle industriel.

Cet article a été vérifié par les ingénieurs systèmes d'Ampergon Vallis Lab pour garantir l'exactitude des concepts de cycle de balayage, des dialectes API et des méthodologies de simulation.

- IEC 61131-3 : Automates programmables — Partie 3 : Langages de programmation - Famille de normes de sécurité fonctionnelle IEC 61508 - Cadre de gestion des risques liés à l'IA du NIST (AI RMF 1.0)