Comment générer de la logique Ladder IEC 61131-3 avec l'IA dans OLLA Lab

Pour générer une logique Ladder prête pour la production à l'aide de l'IA, les ingénieurs doivent traduire une intention en langage naturel en structures IEC 61131-3, puis valider le résultat par rapport à un comportement machine réaliste. Dans OLLA Lab, GeniAI est utile au sein d'un flux de travail de génération-validation : générer des modèles Ladder standard, lier les E/S, simuler des pannes et vérifier le comportement des états de sécurité avant toute décision de déploiement en conditions réelles.

L'IA n'échoue pas avec la logique Ladder parce qu'elle est « mauvaise en code ». Elle échoue parce que la logique API n'est pas un logiciel ordinaire, contrairement à ce que la plupart des modèles généralistes ont appris à attendre. Le Ladder s'exécute selon un cycle de balayage déterministe, interagit avec des E/S physiques et doit survivre à des états anormaux sans improvisation. Une confiance apparente ne coûte rien ; les erreurs de mise en service, si.

Un benchmark interne délimité illustre ce point. Lors d'un test bêta interne d'Ampergon Vallis en 2026 sur 500 circuits de commande moteur demandés par les utilisateurs dans OLLA Lab, les sorties brutes non guidées des LLM omettaient un arrêt d'urgence physique normalement fermé ou un permissif d'arrêt équivalent dans 68 % des cas, tandis que les invites acheminées via les garde-fous de GeniAI produisaient des modèles alignés sur la sécurité dans 99,4 % des cas avant la simulation par l'utilisateur. Méthodologie : n=500 tâches de commande moteur par invite, comparateur de référence = sortie LLM généraliste brute versus flux de travail GeniAI protégé, fenêtre temporelle = période bêta interne 2026. Cela confirme que les garde-fous spécifiques au domaine améliorent sensiblement la structure dès la première itération. Cela ne signifie pas que la logique générée par l'IA est prête pour le déploiement sans examen humain ni simulation.

Cette distinction est importante. La syntaxe n'est pas la déployabilité.

Les LLM standard échouent avec la logique Ladder industrielle car ils traitent le code principalement comme une génération de texte séquentiel, alors que le contrôle API est cyclique, étatique et physiquement contraint. Un modèle fortement entraîné sur des exemples Python, JavaScript ou de type C produira souvent quelque chose qui semble raisonnable à l'écran mais qui se comporte mal dans un contrôleur basé sur le balayage. L'échelon peut être propre et pourtant erroné.

Les trois lacunes fondamentales de l'IA open-source dans les API

Les modèles généralistes impliquent souvent un comportement asynchrone ou piloté par les événements qui ne correspond pas clairement à l'exécution du balayage API. Dans un contrôleur réel, les entrées sont lues, la logique est résolue, les sorties sont écrites, et ce cycle se répète de manière déterministe. Une logique qui suppose des changements d'état instantanés sur des conditions non liées peut produire un comportement de type « course » ou des transitions manquées.

• Ignorance du cycle de balayage

L'IA non guidée écrit fréquemment sur la même sortie à plusieurs endroits sans stratégie de mémoire disciplinée. En termes Ladder, cela peut signifier plusieurs écritures destructrices sur le même bit ou la même bobine de sortie, le dernier échelon gagnant. C'est une erreur courante chez les débutants, et l'IA peut la reproduire rapidement.

• Syndrome de la double bobine

Les modèles standard traitent souvent les tags comme des variables abstraites plutôt que comme des signaux de terrain ayant une signification électrique. Ils peuvent ignorer le câblage de terrain normalement fermé, les chaînes d'arrêt de sécurité, les retours de preuve ou le comportement des signaux analogiques, comme l'interprétation du « live-zero » 4–20 mA. Une valeur analogique faible n'est pas toujours une demande de processus nulle ; elle indique parfois un problème de câblage ou d'instrumentation.

• Perte du contexte des E/S

Ces lacunes sont prévisibles car les données d'entraînement du modèle ne sont pas natives OT (technologies opérationnelles). Ce n'est pas un échec moral. C'est un problème de jeu de données avec des conséquences d'ingénierie pratiques.

GeniAI est plus utile lorsqu'il agit comme une couche de traduction de l'intention technique vers des structures Ladder standard, et non comme un générateur de code libre. Dans OLLA Lab, l'objectif est de générer une logique utilisant des modèles d'instructions de style IEC 61131-3 reconnaissables dans un environnement Ladder basé sur navigateur, puis d'inspecter et de tester cette logique en simulation.

Pour cet article, « prêt pour la production » est défini de manière opérationnelle et étroite : une logique qui est conforme à la structure Ladder IEC 61131-3, utilise des types d'instructions et une gestion des données standard de manière appropriée, évite les erreurs de gestion d'état évidentes telles que les écritures conflictuelles, et est adaptée à une validation basée sur la simulation. Cela ne signifie pas certifié par le fournisseur, approuvé sur site, qualifié SIL ou sûr à déployer sans examen.

Garde-fous structurels dans l'éditeur basé sur navigateur

GeniAI améliore la génération Ladder de première intention en contraignant la sortie vers des éléments de contrôle standard déjà présents dans l'éditeur d'OLLA Lab, notamment :

• contacts et bobines
• temporisateurs tels que TON
• compteurs tels que CTU
• comparateurs
• opérations mathématiques et logiques
• instructions et variables liées au PID

C'est important car les demandes en langage naturel sont généralement sous-spécifiées. « Démarrer une pompe après cinq secondes » n'est pas une philosophie de contrôle. C'est un fragment. Les garde-fous aident à convertir les fragments en structures plus complètes qui incluent des permissifs, un comportement temporel et des transitions d'état sensibles aux pannes.

Un exemple délimité est un circuit de maintien (seal-in) de moteur avec une logique de chaîne d'arrêt explicite :

|----[/] E_STOP_OK ----[/] OL_TRIP ----[ ] START_PB ---------(L) MOTOR_RUN_CMD----| |----[ ] MOTOR_RUN_CMD ----[ ] AUX_FEEDBACK ------------------( ) MOTOR_CONTACTOR--| |----[ ] STOP_PB ------------------------------------------------(U) MOTOR_RUN_CMD--| |----[/] E_STOP_OK ---------------------------------------------(U) MOTOR_RUN_CMD--| |----[/] OL_TRIP -----------------------------------------------(U) MOTOR_RUN_CMD--|

Dans ce modèle :

• `E_STOP_OK` et `OL_TRIP` sont traités comme des conditions permissives ou de déclenchement
• la commande de marche du moteur est verrouillée délibérément
• les conditions d'arrêt et de défaut déverrouillent explicitement la commande
• l'actionnement de la sortie est séparé de la mémoire de commande

Les noms de tags exacts et la sémantique des instructions du fournisseur varieront selon les projets réels, mais le modèle d'ingénierie est ce qui compte.

La boucle de génération-validation est le flux de travail d'ingénierie central : l'IA échafaude la logique, et la simulation détermine si la logique mérite de survivre. La génération de code est la partie rapide. Prouver le comportement est le travail.

Dans OLLA Lab, cette boucle est opérationnellement utile car la plateforme combine un éditeur Ladder, un mode simulation, une visibilité des variables et des E/S, et des scénarios d'équipement en 3D ou basés sur WebXR dans un seul environnement. Cela permet aux utilisateurs de passer de « l'échelon existe » à « la séquence se comporte correctement dans des conditions normales et anormales ». Ce sont des accomplissements différents.

Pour Ampergon Vallis, « prêt pour la simulation » signifie quelque chose de spécifique : un ingénieur peut prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste avant que cette logique n'atteigne un processus réel. Cela ne signifie pas qu'il peut simplement dessiner une syntaxe Ladder de mémoire. La syntaxe est le ticket d'entrée ; la validation sensible aux pannes est la profession.

Tester la logique de l'IA contre les préréglages OLLA

Une boucle de génération-validation pratique dans OLLA Lab suit trois étapes :

1. Génération par invite : échafauder le premier brouillon Utilisez GeniAI pour générer une séquence de première intention à partir d'une demande de contrôle délimitée. L'objectif n'est pas un code parfait. L'objectif est un point de départ structuré avec des instructions standard et des hypothèses visibles.

2. Liaison d'E/S : connecter les tags à la signification du processus Utilisez le panneau des variables pour inspecter et ajuster les entrées, sorties, valeurs analogiques, états des tags et paramètres de scénario. C'est ici que la logique abstraite rencontre le comportement de l'équipement. Si un permissif n'a pas de source de processus significative, ce n'est pas vraiment un permissif.

3. Forçage d'état : déclencher des pannes et vérifier la réponse de l'état de sécurité Exécutez la simulation, basculez les entrées, injectez des conditions anormales et observez si la logique passe à l'état de sécurité prévu. Forcez une surcharge, rompez un permissif, faites chuter un signal de niveau ou dépassez un seuil de pression. Si l'échelon généré par l'IA ne fonctionne que lorsque le monde est poli, il n'est même pas prêt pour une répétition.

C'est là qu'OLLA Lab devient opérationnellement utile. Il offre aux utilisateurs un espace contenu pour tester la cause à effet, tracer les E/S, réviser la logique après des pannes et comparer l'état du Ladder à l'état de l'équipement simulé. Ce sont exactement les tâches qui sont coûteuses, risquées ou simplement indisponibles à pratiquer sur des systèmes réels.

Une demande efficace pour la logique Ladder signifie décrire la philosophie de contrôle, et non simplement demander du code. L'IA fonctionne mieux lorsque l'invite inclut l'intention de la séquence, les permissifs, les déclenchements, la temporisation, les seuils analogiques et le comportement de réinitialisation. Dans le travail de contrôle, les hypothèses omises deviennent des problèmes de site avec du câblage attaché.

Invites faibles vs Invites d'ingénierie

| Invite faible | Invite d'ingénierie | |---|---| | « Écris un programme pour démarrer une pompe après 5 secondes. » | « Génère une séquence Ladder pour la Pompe 101. Inclus un délai de démarrage TON de 5 secondes. Les permissifs exigent Niveau de réservoir > 20 % et Arrêt d'urgence OK. Si Pression de refoulement > 80 PSI, déclenche un défaut, déverrouille la commande de pompe et exige une réinitialisation par l'opérateur avant le redémarrage. » |

La différence n'est pas stylistique. Elle est architecturale.

Une invite d'ingénierie plus forte devrait généralement spécifier :

Exemple : Pompe 101, section de convoyeur A, agitateur de mélangeur, ventilateur d'alimentation CTA Exemple : démarrer après un TON de 5 secondes, puis prouver le retour de marche dans les 3 secondes Exemple : Arrêt d'urgence sain, protection fermée, niveau de réservoir au-dessus du minimum, VFD sain Exemple : surcharge, haute pression, basse aspiration, haute température, perte de communication Exemple : verrouiller la commande, déverrouiller sur défaut, réinitialisation manuelle requise après défaut Exemple : commande de marche, bit de défaut, sortie d'alarme, indicateur d'état Exemple : niveau bas à 20 %, haute pression à 80 PSI, bande morte d'alarme si nécessaire Exemple : moteur hors tension, commande déverrouillée, alarme active, redémarrage inhibé

• l'actif contrôlé
• la condition de démarrage et la temporisation de la séquence
• les permissifs
• les conditions de déclenchement (trips)
• le comportement de l'état
• les sorties observables
• les seuils analogiques le cas échéant
• l'état de sécurité attendu

C'est aussi pourquoi l'IA ne devrait pas être jugée uniquement sur sa capacité à écrire du code. Une invite de contrôle utile ressemble plus à une description fonctionnelle compacte qu'à une demande de programmation.

La programmation d'état de sécurité signifie que la logique conduit le processus vers une condition non dangereuse définie lorsqu'un permissif est perdu, qu'une panne survient ou qu'un signal requis devient invalide. Dans la logique Ladder, cela apparaît généralement sous forme de chaînes d'arrêt explicites, de logique de permissif normalement fermée le cas échéant, de verrouillage de défaut ou de déverrouillage de commande, et d'un comportement de réinitialisation déterministe.

Cet article utilise les modèles d'état de sécurité dans un sens délimité. Il fait référence à des motifs de contrôle de sécurité standard tels que :

• des chemins d'arrêt ou de permissif normalement fermés où la perte de signal supprime la condition de marche
• une gestion explicite des déclenchements pour les surcharges ou les conditions de processus anormales
• une mémoire de commande qui est intentionnellement réinitialisée en cas de défaut
• des vérifications de preuve ou de retour où l'actionnement doit être confirmé
• un comportement d'alarme et de réinitialisation observable en simulation

Ceci est aligné avec le principe d'ingénierie plus large trouvé dans la pratique de la sécurité fonctionnelle : les systèmes doivent par défaut tendre vers une condition plus sûre en cas de défaillances prévisibles, avec une réduction des risques conçue consciemment plutôt qu'impliquée par la seule syntaxe (IEC, 2010 ; exida, 2024).

L'IA ne comprend pas le risque au sens technique. Elle peut reproduire des modèles associés à une conception plus sûre lorsque ces modèles sont contraints, sollicités et testés. C'est utile, mais ce n'est pas la même chose que le jugement.

Les ingénieurs doivent valider la logique Ladder de l'IA en testant le comportement observable par rapport à une philosophie de contrôle définie, dans des conditions normales et défaillantes. La cible de la validation n'est pas « est-ce que ça compile ? » mais « est-ce que ça se comporte correctement quand le processus cesse de coopérer ? »

Une liste de contrôle de validation pratique dans OLLA Lab comprend :

• vérifier que tous les tags ont une signification de processus claire
• confirmer que les permissifs et les déclenchements sont câblés dans la séquence intentionnellement
• vérifier les écritures conflictuelles ou l'appartenance d'état ambiguë
• forcer les transitions de démarrage, d'arrêt et de défaut en simulation
• observer le comportement de sortie et la mémoire de commande pendant les pannes
• inspecter les seuils analogiques, le comportement des comparateurs et les variables liées au PID le cas échéant
• confirmer le comportement de réinitialisation et de redémarrage après l'effacement du défaut

Pour les lecteurs qui construisent des preuves de compétence, une galerie de captures d'écran n'est généralement pas suffisante. Un ensemble plus crédible de preuves d'ingénierie comprend :

1. Description du système : Décrire l'actif, l'objectif du processus, les principales E/S et la séquence de fonctionnement. 2. Définition opérationnelle du comportement correct : Énoncer ce que signifie un comportement correct en termes observables : conditions de démarrage, permissifs, temporisation, déclenchements, alarmes et état de sécurité. 3. Logique Ladder et état de l'équipement simulé : Montrer la structure de l'échelon avec la réponse de la machine ou du processus simulé. 4. Le cas de panne injecté : Définir la condition anormale introduite : surcharge, niveau bas, preuve échouée, haute pression, perte de capteur. 5. La révision effectuée : Expliquer ce qui a changé dans la logique après les tests et pourquoi. 6. Leçons apprises : Enregistrer les conclusions techniques, en particulier là où la sortie initiale de l'IA était incomplète ou trompeuse.

Cette structure est plus convaincante que des captures d'écran polies car elle montre le raisonnement, pas seulement la familiarité avec l'interface.

Les jumeaux numériques améliorent la formation à la logique Ladder assistée par l'IA en donnant à la logique générée un contexte de test physique. Un échelon Ladder isolé peut sembler cohérent tout en échouant à respecter les dépendances de séquence, l'inertie de l'équipement, la temporisation du retour d'information ou le comportement anormal du processus. Le jumeau numérique est là pour défier les hypothèses.

Dans OLLA Lab, la validation par jumeau numérique signifie tester la logique Ladder contre des modèles de machines réalistes et des préréglages de scénarios avant que toute prétention de correction ne soit envisagée. Les scénarios documentés de la plateforme couvrent la fabrication, l'eau et les eaux usées, le CVC, la chimie, la pharmacie, l'entreposage, l'agroalimentaire, les services publics et les contextes de processus connexes. C'est important car une station de pompage, une CTA et un convoyeur d'emballage ne tombent pas en panne de la même manière, et ils ne devraient pas être formés comme s'ils le faisaient.

La littérature récente soutient largement la simulation et la formation basée sur les jumeaux numériques comme utiles pour réduire les risques de formation, améliorer la compréhension des processus et permettre une validation plus précoce des stratégies de contrôle, bien que les résultats dépendent fortement de la fidélité, de la conception des tâches et de la méthode d'évaluation plutôt que de la simple présence d'un modèle virtuel (Tao et al., 2019 ; Fuller et al., 2020 ; Boschert & Rosen, 2016). L'interprétation la plus prudente est généralement la bonne : le jumeau est précieux lorsqu'il expose un comportement que vous auriez autrement manqué.

OLLA Lab s'inscrit comme un environnement de répétition et de validation délimité pour les tâches de contrôle à haut risque difficiles à pratiquer sur des équipements réels. Ce n'est pas un substitut à l'examen spécifique au site, à l'expertise de la plateforme du fournisseur, au travail sur le cycle de vie de la sécurité fonctionnelle ou à la mise en service supervisée. C'est un endroit pour pratiquer la boucle de génération-validation avec des scénarios réalistes, des E/S visibles et un support guidé.

Ce positionnement délimité est important. OLLA Lab peut aider les utilisateurs à :

• construire une logique Ladder dans un éditeur basé sur le web
• générer des structures de première intention avec l'assistance de l'IA
• inspecter les variables, les tags, les valeurs analogiques et le comportement lié au PID
• tester la logique en mode simulation
• comparer l'état du Ladder au comportement de l'équipement en 3D ou WebXR
• répéter le dépannage et les révisions de style mise en service

Il ne doit pas être présenté comme un raccourci vers la certification, la compétence sur site ou la conformité formelle.

L'équipe d'ingénierie d'Ampergon Vallis Lab se spécialise dans l'intégration des technologies d'IA dans les flux de travail de contrôle industriel, en se concentrant sur la sécurité fonctionnelle, la simulation de jumeaux numériques et la validation rigoureuse des systèmes automatisés.

Cet article a été examiné par des ingénieurs en automatisation et des experts en sécurité fonctionnelle pour garantir l'alignement avec les principes de la norme IEC 61131-3 et les meilleures pratiques de l'industrie OT.

- IEC 61131-3: Automates programmables — Partie 3 - Aperçu de la norme de sécurité fonctionnelle IEC 61508 - Profil de fabrication intelligente du NIST - IEEE Access: Technologies habilitantes du jumeau numérique (DOI)