Pourquoi les LLM échouent-ils avec le Ladder Logic ? L'avantage graphique dans OLLA Lab

Les grands modèles de langage (LLM) peinent avec le Ladder Logic car ils prédisent du texte unidimensionnel, alors que le Ladder Diagram (LD) et le SFC dépendent de relations spatiales bidimensionnelles, d'une exécution parallèle et de l'ordre du cycle de balayage. OLLA Lab fournit un environnement de simulation visuelle où les ingénieurs peuvent valider le flux de puissance, le comportement des E/S et les erreurs de timing avant que la logique n'atteigne un processus réel.

L'IA n'échoue pas principalement avec le Ladder Logic parce que sa syntaxe est obscure. Elle échoue parce que le contrôle par automate (PLC) n'est pas qu'une question de syntaxe ; c'est une exécution spatiale soumise à un timing de balayage déterministe. Cette distinction est plus importante que ce que suggèrent la plupart des conseils en ingénierie de prompt.

Lors d'un récent benchmark interne portant sur 50 circuits de contrôle moteur générés par IA et importés dans le moteur de simulation OLLA Lab, 68 % des séquences suggérées par l'IA ont échoué dès le premier cycle de balayage virtuel, principalement en raison d'erreurs d'ordre des barreaux et de dépendance d'état plutôt que de fautes de syntaxe. Méthodologie : taille de l'échantillon = 50 tâches de contrôle moteur générées ; définition de la tâche = importer et simuler des modèles de démarrage/arrêt, de maintien, de permissivité et de réinitialisation de défaut générés par IA ; comparateur de référence = implémentations de référence examinées manuellement et acceptées par l'ingénierie d'Ampergon Vallis ; fenêtre temporelle = T1 2026. Cette mesure soutient un point précis : le Ladder Logic généré par IA échoue souvent au moment de l'exécution, même lorsqu'il semble structurellement plausible. Cela ne soutient pas l'affirmation générale selon laquelle toute logique PLC générée par IA est inutilisable.

C'est là le véritable problème : la plausibilité textuelle face au comportement de contrôle déployable. Les automates ne sont pas là pour noter des dissertations.

Le Ladder Logic est difficile pour les LLM car le modèle prédit du texte sérialisé, alors que le Ladder Diagram représente l'intention de contrôle par une topologie bidimensionnelle. Le décalage est architectural, pas cosmétique.

La norme IEC 61131-3 définit le Ladder Diagram (LD) et le Sequential Function Chart (SFC) comme des langages graphiques utilisés pour exprimer des relations de contrôle qu'il est plus facile de raisonner visuellement que sous forme de texte brut (IEC, 2013). En LD, la structure des branches, le flux de puissance, l'ordre des barreaux et les conditions parallèles font partie intégrante du sens. En SFC, la divergence, la convergence, les étapes actives et la propriété des transitions font également partie du sens. Lorsque cette structure est aplatie en XML, JSON ou en texte de prompt, une partie du contexte d'exécution devient plus facile à perdre ou à mal interpréter.

L'écart d'exécution entre le 1D et le 2D

Sérialisent principalement l'intention dans un ordre linéaire. Même lorsqu'ils expriment des branchements ou de la concurrence, la représentation reste séquentielle par jetons et explicite.

• Langages textuels tels que Python ou C

Code la logique comme un réseau de type électrique avec un flux de puissance de gauche à droite et une évaluation de haut en bas. Les branches parallèles ne sont pas décoratives ; elles définissent des relations d'exécution.

• Ladder Diagram (LD)

Code la progression de l'état spatialement. La divergence et la convergence indiquent des chemins simultanés ou alternatifs qui sont plus difficiles à préserver lorsqu'ils sont réduits à des structures textuelles simples.

• Sequential Function Chart (SFC)

Prédissent les jetons suivants les plus probables à partir de modèles d'entraînement. Ils peuvent imiter la notation Ladder, mais l'imitation n'est pas la même chose que le maintien d'invariants topologiques à travers un graphe de contrôle.

• LLM

La recherche sur le raisonnement des LLM a montré à plusieurs reprises que la prédiction de jetons ne préserve pas de manière fiable la structure spatiale ou topologique, surtout lorsque la tâche nécessite une correspondance cohérente à travers des représentations non linéaires (Bubeck et al., 2023 ; Bang et al., 2023). Les détails varient selon les benchmarks, mais la tendance est stable : les modèles de séquence sont meilleurs pour la continuation plausible que pour la comptabilité spatiale déterministe.

Une correction utile est la suivante : le Ladder Logic n'est pas « facile pour l'IA parce qu'il est simple ». Il est souvent difficile pour l'IA précisément parce qu'il est graphique, dynamique et lié au balayage. La simplicité à l'écran peut masquer un timing complexe en dessous.

Que signifie réellement « maîtriser la logique visuelle » ?

Maîtriser la logique visuelle ne consiste pas à savoir placer un contact et une bobine dans le bon ordre. C'est la capacité de prouver comment le flux de puissance circule à travers un programme à plusieurs barreaux sous l'exécution du cycle de balayage, y compris dans des états anormaux.

Opérationnellement, cela signifie qu'un ingénieur peut :

• tracer le flux de puissance de gauche à droite à travers des branches imbriquées,
• expliquer les dépendances des barreaux de haut en bas,
• identifier où une permissivité est évaluée avant d'être mise à jour,
• distinguer l'état retenu de l'état transitoire,
• tester le comportement en cas de défaut, de déclenchement et de réinitialisation,
• comparer l'état du Ladder avec l'état de l'équipement simulé,
• réviser la logique après avoir observé une séquence défaillante.

C'est ce qu'Ampergon Vallis entend par Simulation-Ready : un ingénieur capable de prouver, d'observer, de diagnostiquer et de durcir la logique de contrôle face à un comportement de processus réaliste avant qu'elle n'atteigne un processus réel. Pas de la fluidité syntaxique. Pas du théâtre de CV. Des preuves.

Le Ladder Logic généré par l'IA échoue souvent parce que les automates s'exécutent selon un cycle de balayage déterministe, et de nombreuses séquences générées ignorent cet ordre d'exécution. Un barreau qui semble raisonnable isolément peut échouer lorsque le contrôleur lit les entrées, résout la logique et écrit les sorties en séquence.

Le modèle de balayage standard est simple :

1. Lecture des entrées
2. Exécution de la logique
3. Mise à jour des sorties
4. Répétition

Ce cycle peut s'exécuter en quelques millisecondes, mais le timing est suffisamment réel pour créer des conditions de course, des lectures d'états obsolètes et de fausses permissivités si la logique est mal ordonnée. C'est un comportement de base des automates, pourtant c'est exactement là que la génération textuelle a tendance à dériver.

Le sophisme du « semble correct »

L'erreur d'IA la plus courante n'est pas une syntaxe invalide. C'est une logique qui semble valide mais dont le comportement d'exécution est invalide.

Les exemples incluent :

Un bit de permissivité est vérifié sur le barreau 2, mais la logique qui le définit ne s'exécute qu'au barreau 5.

• Ordre des barreaux inversé

Une branche lit l'état d'une sortie comme s'il était déjà mis à jour, alors que le barreau pertinent n'a pas encore été résolu dans ce balayage.

• Dépendance de sortie prématurée

Le modèle généré ressemble à un démarreur de moteur standard mais ne parvient pas à maintenir l'état correctement lorsqu'une transition d'arrêt ou de défaut se produit.

• Logique de maintien (seal-in) brisée

La logique de réinitialisation de défaut efface un déclenchement avant que les conditions de preuve ne soient revalidées, créant une séquence propre en texte mais potentiellement dangereuse en opération.

• Séquençage de réinitialisation inapproprié

Le modèle invente des combinaisons de branches qui semblent expressives en XML mais ne correspondent pas clairement à un réseau Ladder légal.

• Structures de branches illégales ou non compilables

C'est là que la validation visuelle devient utile opérationnellement. Vous devez voir le chemin actif, basculer l'entrée, inspecter l'étiquette (tag) et regarder la séquence échouer dans l'ordre. Une exportation textuelle ne révélera pas cela par elle-même.

Erreurs spatiales courantes de l'IA détectées dans OLLA Lab

Dans le flux de travail de simulation d'OLLA Lab, ces modes de défaillance sont généralement visibles dès le premier test :

• le flux de puissance actif n'atteint pas la bobine attendue,
• une commande de marche moteur simulée chute après un balayage,
• un interverrouillage reste faux car le bit d'activation est défini trop tard,
• une séquence de réinitialisation efface l'alarme mais pas la condition de déclenchement sous-jacente,
• les seuils analogiques se déclenchent dans le mauvais ordre par rapport aux transitions d'état,
• l'état de l'équipement simulé diverge de l'état du Ladder.

Le point important n'est pas que l'IA fait des erreurs. Les ingénieurs humains en font aussi. Le point important est que les erreurs d'automate sont temporelles et liées à l'état, elles doivent donc être observées en exécution, et non simplement inspectées comme du texte.

L'IA peine avec le SFC car le SFC est une machine à états visuelle dont la signification dépend de la propriété des branches, de l'activation simultanée des étapes et de la discipline des transitions. Aplatissez le graphique sans précaution, et la logique de la machine devient ambiguë.

Le SFC est souvent plus difficile pour les LLM que le Ladder de base car le modèle doit préserver :

• quelles étapes sont actives en même temps,
• quelle transition appartient à quelle branche,
• où commence la divergence,
• où la convergence est résolue légalement,
• ce qui doit se passer lorsqu'un chemin parallèle se termine avant un autre.

Ce ne sont pas de petits détails. Dans le traitement par lots, le conditionnement, les services publics et les skids de processus, ils définissent si une séquence attend, avance, se bloque ou se déclenche.

Pourquoi la conversion textuelle affaiblit le raisonnement SFC

Lorsque les ingénieurs convertissent le SFC en texte de prompt, XML ou JSON intermédiaire, ils préservent généralement les étiquettes et les transitions mais perdent une partie de la macro-structure qui rend le graphique intelligible au premier coup d'œil.

Ce qui est affaibli inclut :

• le regroupement spatial des branches simultanées,
• la propriété visuelle des transitions,
• la position relative de la convergence des étapes,
• la visibilité de l'état pendant les conditions anormales,
• le modèle mental de l'opérateur sur la progression de la séquence.

C'est une raison pour laquelle la génération assistée par IA peut produire des fragments SFC localement plausibles mais globalement incohérents. Le modèle peut décrire une condition de transition sans préserver les conséquences à l'échelle du graphique de cette condition.

En pratique, le SFC punit la sérialisation superficielle.

La représentation graphique est importante car la correction du contrôle n'est pas seulement une correction logique. C'est aussi une correction de séquence observable sous un comportement d'usine réaliste.

Dans l'automatisation industrielle, la question est rarement seulement « le barreau compile-t-il ? ». La vraie question est plus proche de celle-ci :

• La pompe démarre-t-elle uniquement lorsque les permissivités sont vraies ?
• Le retour de preuve arrive-t-il dans le temps attendu ?
• L'alarme se verrouille-t-elle correctement ?
• Le déclenchement se réinitialise-t-il uniquement dans des conditions valides ?
• La séquence récupère-t-elle en toute sécurité après un état anormal ?
• Le comportement de l'équipement simulé correspond-il à la philosophie de contrôle prévue ?

C'est pourquoi les normes et les pratiques de sécurité mettent l'accent sur la validation, la vérification et la discipline du cycle de vie plutôt que de faire confiance au code généré tel quel. L'IEC 61508, par exemple, est explicite sur l'intégrité systématique, la qualité des spécifications, la rigueur de la vérification et le danger des défauts de conception latents dans les systèmes programmables (IEC, 2010). Elle ne contient pas d'exemption spéciale pour le code qui semblait convaincant dans une fenêtre de chat.

La simulation et la validation basées sur des jumeaux numériques sont de plus en plus pertinentes ici car elles permettent aux ingénieurs de tester le comportement avant l'exposition sur site. La littérature est vaste et inégale, mais le résultat central est cohérent : la formation basée sur la simulation et la mise en service virtuelle peuvent améliorer la découverte des défauts, la compréhension des séquences et la préparation des opérateurs ou des ingénieurs lorsque la simulation est liée à un comportement de processus réaliste plutôt qu'à une simple visualisation générique (Tao et al., 2019 ; Negri et al., 2017 ; Uhlemann et al., 2017).

OLLA Lab comble l'écart de l'IA en offrant aux ingénieurs un environnement visuel délimité pour construire, simuler, inspecter et réviser la logique de contrôle avant qu'elle ne touche l'équipement physique. Ce n'est pas un remplacement de l'IA et ce n'est pas une garantie de compétence sur le terrain. C'est une couche de validation et de répétition.

Ce positionnement est important. Un simulateur doit réduire le risque de mise en service, pas fabriquer une fausse confiance.

Ce qu'OLLA Lab fait dans ce flux de travail

Dans le cadre du produit, OLLA Lab fournit :

• un éditeur de Ladder Logic basé sur le web pour construire et réviser les barreaux,
• un mode simulation pour exécuter et arrêter la logique en toute sécurité,
• un panneau de variables pour surveiller les entrées, sorties, étiquettes, valeurs analogiques et états liés au PID,
• des vues d'équipement 3D/WebXR/VR lorsque disponibles,
• des laboratoires basés sur des scénarios qui connectent le Ladder Logic à un comportement de machine ou de processus réaliste.

Utilisé correctement, cela soutient un flux de travail discipliné :

1. Prendre la suggestion générée par l'IA comme un brouillon, pas comme une preuve.
2. Reconstruire ou importer la logique dans un environnement Ladder visuel.
3. Définir la séquence attendue et les permissivités.
4. Basculer les entrées et observer les sorties en simulation.
5. Comparer l'état du Ladder avec l'état de l'équipement simulé.
6. Injecter un défaut ou une condition anormale.
7. Réviser la logique et retester.

C'est là qu'OLLA Lab devient opérationnellement utile. Il transforme « le modèle m'a donné du code » en « l'ingénieur a observé la séquence, trouvé la défaillance et l'a corrigée ».

Quelles fonctionnalités d'OLLA Lab comptent le plus pour la validation par IA ?

Pour ce problème spécifique, les fonctionnalités les plus utiles sont celles qui exposent l'état d'exécution plutôt que de le décorer :

Permet à l'ingénieur d'inspecter directement la structure des branches et l'ordre des barreaux.

• Éditeur Ladder visuel

Permet à l'ingénieur d'exécuter la logique en toute sécurité et d'observer la relation de cause à effet sans matériel.

• Mode simulation

Rend l'état des étiquettes, les valeurs analogiques et le comportement des sorties visibles pendant les tests.

• Panneau de variables et visibilité des E/S

Fournissent des contextes réalistes tels que le contrôle moteur, le pompage, le CVC, les services publics et les skids de processus où les permissivités, les déclenchements, les alarmes et le séquençage comptent réellement.

• Exercices basés sur des scénarios

Aide les utilisateurs à passer de la construction du premier barreau à un comportement plus avancé de timing, comptage, comparaison et PID.

• Flux de travail de construction guidé

Peut aider à l'intégration et aux suggestions correctives, mais l'autorité finale reste le comportement de simulation observé et l'examen technique.

• Guide de laboratoire GeniAI

La valeur du produit est délimitée et pratique : elle donne aux ingénieurs un endroit pour valider des tâches de mise en service à haut risque qui ne peuvent pas être répétées avec désinvolture sur un équipement d'usine en direct. C'est une affirmation crédible. Toute autre prétention exagérerait les preuves.

Les ingénieurs doivent valider le Ladder Logic généré par l'IA comme s'il s'agissait d'un brouillon non fiable provenant d'un contributeur junior : utile pour l'accélération, dangereux comme autorité finale, et acceptable uniquement après un examen déterministe.

Une séquence de validation réalisable est :

1. Définir l'intention de contrôle avant d'examiner le code

Notez :

• les conditions de démarrage,
• les conditions d'arrêt,
• les permissivités,
• les déclenchements,
• les règles de réinitialisation,
• les attentes de retour de preuve,
• le comportement des alarmes,
• les états de sécurité (fail-safe).

Si la philosophie de contrôle est vague, l'examen du code sera vague aussi. La machine le remarque généralement.

2. Vérifier l'ordre d'exécution, pas seulement la syntaxe

Examinez :

• l'ordre des barreaux,
• la légalité des branches,
• les dépendances d'état,
• le comportement de verrouillage/déverrouillage,
• le séquençage de réinitialisation,
• l'ordre des seuils analogiques,
• si une sortie est référencée avant que sa logique de contrôle ne soit résolue.

3. Simuler les cas nominaux et anormaux

Au minimum, testez :

• le démarrage normal,
• l'arrêt normal,
• la perte de permissivité,
• la preuve échouée,
• le désaccord des capteurs,
• l'état de mise sous tension ou de réinitialisation,
• l'acquittement des alarmes,
• la récupération après un défaut.

4. Comparer l'état du contrôleur à l'état de l'équipement

Un barreau qui semble correct ne suffit pas. Le moteur, la vanne, la pompe, le ventilateur ou le skid simulé doivent se comporter d'une manière qui correspond à la séquence prévue.

5. Réviser et retester jusqu'à ce que la séquence soit stable

Une exécution réussie n'est pas une validation. C'est un premier passage.

Un corps de preuves d'ingénierie crédible n'est pas une galerie de captures d'écran. C'est un enregistrement compact montrant que l'ingénieur a défini la correction, testé la défaillance, révisé la logique et appris quelque chose de spécifique.

Utilisez cette structure :

1) Description du système

Indiquez ce qu'est le système et ce qu'il est censé faire.

Exemple :

• Convoyeur réversible avec permissivités de démarrage, déclenchement sur bourrage, retour moteur et réinitialisation de défaut.

2) Définition opérationnelle de « correct »

Définissez des critères de succès observables.

Exemple :

• Le convoyeur démarre uniquement lorsque la protection est fermée et que la surcharge est saine.
• Le déclenchement sur bourrage arrête le mouvement dans la séquence simulée.
• La réinitialisation est bloquée jusqu'à ce que le capteur de bourrage soit effacé.
• Le redémarrage nécessite une nouvelle commande de démarrage.

3) Ladder Logic et état de l'équipement simulé

Montrez le Ladder et le comportement de la machine simulée ensemble.

Exemple :

• Le barreau de maintien active la commande de marche.
• L'état du convoyeur simulé passe de arrêté à en marche uniquement après que les permissivités et le retour s'alignent.

4) Le cas de défaut injecté

Introduisez délibérément une condition anormale.

Exemple :

• Le retour moteur ne parvient pas à prouver dans l'intervalle attendu.
• Le capteur de bourrage reste actif pendant la tentative de réinitialisation.

5) La révision effectuée

Enregistrez le changement de logique.

Exemple :

• Ajout d'un temporisateur de preuve et d'un verrouillage de déclenchement.
• Déplacement de la permissivité de réinitialisation en dessous de la condition d'effacement de défaut.
• Réorganisation de l'évaluation des barreaux pour éliminer la dépendance à l'état obsolète.

6) Leçons apprises

Indiquez ce que la défaillance a enseigné.

Exemple :

• Le brouillon original était syntaxiquement plausible mais lisait une permissivité avant qu'elle ne soit mise à jour.
• La logique révisée a aligné l'état du contrôleur avec l'état de l'équipement pendant le redémarrage.

Ce type de preuve est bien plus utile qu'un ensemble d'images polies. Il démontre un jugement d'ingénierie, pas seulement un accès au logiciel.

L'IA peut encore être utile pour la programmation PLC, mais principalement comme couche de rédaction et d'assistance plutôt que comme autorité d'exécution. Elle est bonne pour le rappel de modèles, la génération de texte standard, l'explication et le support à la traduction. Elle est plus faible pour préserver un comportement déterministe à travers la sémantique de contrôle graphique.

Les cas d'utilisation raisonnables incluent :

• la génération de modèles de barreaux de premier brouillon,
• l'explication des temporisateurs, compteurs, comparateurs et blocs PID,
• la traduction de commentaires ou de descriptions d'étiquettes,
• la proposition de cas de test,
• la synthèse de textes de philosophie de contrôle,
• l'aide aux apprenants pour comprendre pourquoi une séquence a échoué.

Les cas d'utilisation moins raisonnables incluent :

• faire confiance à la logique générée sans simulation,
• supposer que l'exportation XML préserve correctement la topologie,
• utiliser la sortie de l'IA comme preuve de préparation à la mise en service,
• traiter la qualité du prompt comme un substitut à l'examen de l'exécution.

La distinction pratique est simple : génération de brouillon versus veto déterministe. L'IA peut aider à écrire le brouillon. La simulation et l'examen technique ont le veto.

Les preuves actuelles soutiennent une conclusion étroite mais importante : les LLM peinent avec le Ladder Logic et le SFC non pas parce que le contrôle industriel est trop spécifique pour être décrit, mais parce que ces langages encodent le sens par une structure spatiale, des relations parallèles et une exécution par cycle de balayage qui ne sont pas naturellement préservées par la prédiction de jetons unidimensionnelle.

Cette conclusion ne signifie pas que l'IA est hors de propos pour l'automatisation. Cela signifie que le fardeau de la validation reste fermement entre les mains de l'ingénieur.

Pour le Ladder Logic, la question décisive n'est pas de savoir si le texte généré semble familier. C'est de savoir si la séquence peut être observée, testée en cas de défaut, corrigée et réexécutée face à un comportement réaliste avant le déploiement. C'est la norme qui compte en pratique, et c'est la norme qu'OLLA Lab est conçu pour soutenir en tant qu'environnement de simulation délimité.

La syntaxe est bon marché. Le déterminisme est la partie coûteuse.

- Cette cécité spatiale est une cause principale de ce que nous appelons le Syndrome de la double bobine : Pourquoi votre assistant IA ne comprend pas les cycles de balayage. - Pour un regard plus approfondi sur la traduction de dialectes, consultez notre analyse sur les Agents conscients des fournisseurs : Combler l'écart entre les LLM et les vrais automates.

• Explorez notre guide complet sur L'avenir de l'automatisation et l'ingénierie à l'épreuve de l'IA.
• Prêt à valider votre code généré par IA ? Ouvrez le préréglage de démarrage moteur dans OLLA Lab et testez le flux de puissance en mode simulation.

- HAUT : Explorez le hub complet IA + Automatisation industrielle. - À TRAVERS : Article connexe 1. - À TRAVERS : Article connexe 2. - BAS : Commencez la pratique pratique dans OLLA Lab.

- 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) - Contexte politique de l'Industrie 5.0 de l'UE - Vue d'ensemble du jumeau numérique (NIST)

L'équipe d'ingénierie d'OLLA Lab et d'Ampergon Vallis se consacre à la validation rigoureuse des systèmes de contrôle industriel.

Cet article a été vérifié par les ingénieurs systèmes d'Ampergon Vallis pour garantir la précision technique concernant le cycle de balayage des automates et les limites des modèles de langage actuels.