Comment prouver que la logique Ladder générée par IA respecte la rigueur de la norme IEC 61508-3

Pour évaluer la logique Ladder générée par IA par rapport à la norme IEC 61508-3, les ingénieurs doivent tester le comportement déterministe, la réponse aux fautes et la traçabilité par la simulation plutôt que par de simples invites (prompts). OLLA Lab fournit un environnement de validation borné où la logique peut être exercée face à un comportement machine réaliste, observée dans des conditions de défaillance et documentée sous forme de preuves d'exécution prêtes pour l'audit.

La logique Ladder générée par IA ne fait pas échouer un audit parce qu'elle est « IA ». Elle échoue parce que la sécurité fonctionnelle exige un comportement déterministe, traçable et vérifiable, alors que la sortie d'un LLM est probabiliste tant qu'un ingénieur ne la contraint pas et ne la prouve pas.

Une analyse interne récente d'Ampergon Vallis a révélé que 68 % des 500 routines de contrôle moteur générées par IA échouaient à un test de prévisibilité bornée dans des conditions simulées de perte de capteur, jusqu'à ce qu'elles soient manuellement contraintes par un ingénieur [Méthodologie : n=500 routines de démarrage moteur et de permissifs/interverrouillages testées dans la simulation OLLA Lab, comparateur de référence = critères d'acceptation déterministes dérivés de séquences prédéfinies et d'attentes de réponse aux fautes, fenêtre temporelle = janvier-mars 2026]. Cette métrique soutient un point précis : la sortie d'une IA non contrainte viole souvent le comportement prévisible en cas de faute lors de la simulation. Elle ne permet pas d'affirmer quoi que ce soit sur l'ensemble du code PLC, tous les fournisseurs ou les résultats de certification formelle.

Cette distinction est importante. Vous ne pouvez pas auditer une invite. Vous ne pouvez auditer que l'exécution déterministe de la logique résultante sous des contraintes physiques simulées. La syntaxe est peu coûteuse ; la déployabilité ne l'est pas.

La logique générée par IA échoue aux audits IEC 61508-3 parce que la norme se préoccupe de l'intégrité systématique du comportement logiciel, et non de la rapidité avec laquelle le code a été produit. La norme IEC 61508-3 exige que le logiciel soit spécifié, structuré, vérifié et justifié de manière à garantir un fonctionnement prévisible dans des conditions définies et en cas de défaillances définies.

Le conflit fondamental est simple. Les LLM génèrent les jetons (tokens) les plus probables à partir de modèles présents dans les données d'entraînement. Le logiciel de sécurité doit produire des transitions d'état bornées et explicables dans des conditions de processus connues. L'un est une génération probabiliste ; l'autre est une responsabilité déterministe.

C'est pourquoi l'historique des invites n'est pas une preuve de conformité. Une invite peut expliquer une intention, mais elle ne prouve pas le comportement du cycle de balayage (scan cycle), la gestion des fautes, la transition vers un état sûr ou la conformité temporelle.

Les modes de défaillance pratiques sont familiers aux ingénieurs en contrôle-commande :

• des permissifs qui s'activent correctement mais ne se désactivent pas de manière déterministe
• des bits verrouillés (latched) qui persistent après des conditions de redémarrage anormales sans logique de réinitialisation explicite
• une gestion des alarmes qui détecte une valeur erronée mais ne force pas une réponse sûre
• des comparaisons analogiques sans gestion des dépassements de plage
• une logique séquentielle qui fonctionne dans le cas nominal mais se fragmente sous des entrées asynchrones
• des structures de barreaux (rungs) trop complexes qui obscurcissent la vérification

La norme IEC 61508 utilise une terminologie différente selon les activités du cycle de vie, mais l'exigence d'ingénierie est constante : le comportement du logiciel doit être justifié, testable et traçable par rapport à l'intention de sécurité. L'IA peut rédiger une logique. Elle ne peut pas hériter d'une capacité systématique par simple enthousiasme.

C'est là qu'OLLA Lab devient opérationnellement utile. Son rôle n'est pas de certifier le code IA. Son rôle est de fournir un environnement à risque maîtrisé où les ingénieurs peuvent exécuter la boucle génération-validation, observer le comportement du cycle, induire des fautes, comparer l'état du Ladder à l'état de l'équipement simulé et documenter ce que la logique fait réellement.

« Simulation-Ready » signifie qu'un ingénieur peut prouver, observer, diagnostiquer et durcir la logique de contrôle face à un comportement de processus réaliste avant qu'elle n'atteigne un processus réel.

Cette définition est opérationnelle, pas aspirationnelle. Un ingénieur « Simulation-Ready » peut :

• définir à quoi ressemble un comportement correct avant le début des tests
• exécuter la logique face à un modèle de machine ou de processus plutôt que face à des hypothèses
• surveiller les E/S, les bits internes, les valeurs analogiques et l'état de la séquence pendant l'exécution
• injecter des conditions anormales telles que la perte de capteur, un retour d'information obsolète, des cycles d'alimentation et la perte de permissifs
• identifier où l'état du Ladder diverge du comportement attendu de l'équipement
• réviser la logique et retester jusqu'à ce que le comportement soit borné et explicable

C'est la véritable distinction entre la syntaxe Ladder et le jugement de mise en service. Beaucoup de gens peuvent dessiner un barreau. Peu peuvent expliquer pourquoi une pompe devrait refuser de redémarrer après une preuve défaillante, ou pourquoi un permissif doit opposer un veto inconditionnel à une commande de marche après une faute.

Les « 16 piliers » ci-dessous sont une synthèse d'ingénierie pratique dérivée des attentes du cycle de vie de la sécurité logicielle de la norme IEC 61508-3, en particulier l'accent mis par la norme sur la correction, la vérifiabilité, l'évitement des fautes et la conception disciplinée. Il ne s'agit pas d'une liste nommée textuellement dans la norme. Il s'agit d'une structure de travail pour évaluer si la logique Ladder générée par IA évolue vers une rigueur auditable.

### Groupe 1 : Architecture et déterminisme

Tous les modes de fonctionnement définis, états de démarrage, états d'arrêt et états anormaux sont traités.

• 1. Exhaustivité

La logique correspond à la philosophie de contrôle et aux exigences de sécurité prévues.

• 2. Correction

Le comportement d'exécution est borné et répétable dans les mêmes conditions.

• 3. Prévisibilité

La conception évite les contradictions internes, les verrouillages involontaires, les blocages de séquence de type interblocage (deadlock) et les interactions d'état instables.

• 4. Absence de fautes intrinsèques

La complexité est minimisée afin que la logique reste révisable et testable. L'IA échoue souvent ici en produisant une logique ornée qui compile mais est difficile à justifier.

• 5. Simplicité

### Groupe 2 : Tolérance aux fautes et réponse

La logique gère les entrées invalides, bruitées, manquantes ou hors plage sans comportement indéfini.

• 6. Robustesse

Le programme reconnaît activement les capteurs défaillants, les signaux de preuve manquants, les valeurs analogiques erronées ou la perte de communication, le cas échéant.

• 7. Détection des fautes

Les sorties dangereuses sont supprimées par une logique de veto déterministe lorsque les conditions de sécurité sont violées.

• 8. Transition vers l'état sûr

Les fonctions non critiques échouent de manière contrôlée tout en préservant le comportement sûr essentiel.

• 9. Dégradation gracieuse

Les variables, les états conservés et les valeurs critiques sont protégés contre toute corruption ou utilisation involontaire.

• 10. Intégrité des données

La logique répond dans le temps de sécurité du processus requis et ne repose pas sur des hypothèses d'exécution non bornées.

• 11. Contraintes temporelles

### Groupe 3 : Vérification et traçabilité

Chaque barreau, interverrouillage, alarme ou étape de séquence lié à la sécurité est associé à une exigence définie ou à un contrôle des risques.

• 12. Traçabilité

Les fonctions sont partitionnées afin de pouvoir être révisées et testées indépendamment.

• 13. Modularité

La logique peut être exercée selon des scénarios définis et démontrer qu'elle répond aux résultats attendus.

• 14. Vérifiabilité

Les futurs ingénieurs peuvent comprendre, dépanner et modifier le code en toute sécurité.

• 15. Maintenabilité

La protection contre le forçage non autorisé ou la modification dangereuse est prise en compte là où l'intégrité logicielle chevauche les pratiques de cybersécurité, y compris les préoccupations de la norme IEC 62443.

• 16. Intégrité du contrôle sensible à la sécurité

Ces piliers sont importants car la norme IEC 61508 n'est pas impressionnée par un code qui fonctionne « généralement ». Le logiciel de sécurité est jugé sur son comportement défini sous un stress défini.

Un artefact prêt pour l'audit n'est pas une capture d'écran, un journal d'invites ou une note de test vague. Dans ce contexte, il doit être défini comme un rapport de simulation horodaté qui compare le comportement de la séquence de contrôle prévue avec les changements d'état observés lors de conditions de faute induites.

Cette définition maintient la preuve liée à l'exécution. Elle maintient également les revendications de produit dans des limites raisonnables. OLLA Lab peut soutenir la production de cette preuve en fournissant la simulation, la visibilité des variables, la structure des scénarios et des modèles de machines réalistes. Il ne s'agit pas en soi d'une autorité de conformité.

Un artefact utile prêt pour l'audit devrait inclure :

1. Description du système Quel équipement ou processus est contrôlé, y compris les principales E/S, l'intention de la séquence et les modes de fonctionnement.
2. Définition opérationnelle du comportement correct Le comportement attendu en fonctionnement normal et dans des conditions anormales.
3. Logique Ladder et état de l'équipement simulé La logique du barreau testé et la réponse correspondante de la machine ou du processus en simulation.
4. Le cas de faute injecté La condition anormale exacte introduite, telle qu'une rupture de fil, une preuve défaillante, une valeur analogique hors plage ou une récupération après cycle d'alimentation.
5. La révision effectuée Ce qui a changé dans la logique après l'observation de la faute.
6. Leçons apprises Ce que la défaillance a révélé sur les hypothèses, la conception de la séquence, les interverrouillages ou la maintenabilité.

Cette structure en six parties produit des preuves d'ingénierie plutôt qu'une galerie de captures d'écran. Les auditeurs et les réviseurs seniors ont besoin d'une piste de décision. Tout comme les personnes qui hériteront du code plus tard.

La documentation doit être un sous-produit de la validation, et non un exercice de nettoyage après coup. Si le processus de test est structuré correctement, le dossier de preuves peut être assemblé à partir du flux de travail lui-même.

Un flux de travail pratique ressemble à ceci :

1. Définir la séquence prévue et la réponse de sécurité Indiquer ce que l'équipement doit faire en marche, arrêt, démarrage, arrêt et conditions de faute.
2. Construire ou importer la logique Ladder Cela peut inclure une ébauche de logique générée par IA, mais l'ébauche n'est que le point de départ.
3. Exécuter la logique en mode simulation Exécuter le programme tout en surveillant les entrées, les sorties, les tags internes, les valeurs analogiques et les bits de séquence.
4. Injecter des fautes délibérément Utiliser les contrôles de variables pour simuler des ruptures de fil, des limites défaillantes, des preuves obsolètes, la perte de permissifs, des excursions analogiques ou des conditions de redémarrage.
5. Comparer le comportement attendu par rapport au comportement observé Enregistrer si l'équipement simulé entre dans l'état sûr correct et si la logique interne correspond à la philosophie de contrôle.
6. Réviser la logique et retester Ajouter des vetos déterministes, une gestion de réinitialisation, un verrouillage de faute ou des gardes de séquence si nécessaire.
7. Exporter le rapport de test Préserver l'objectif du scénario, le cas de faute, les changements d'état observés et le comportement final de la logique acceptée.

Dans OLLA Lab, ce flux de travail est pris en charge par l'éditeur Ladder, le mode simulation, le panneau des variables, la structure des scénarios et le contexte de jumeau numérique. Le point clé n'est pas que la plateforme assure la conformité. Le point clé est qu'elle fournit un environnement d'observation déterministe où le comportement logiciel peut être testé face à des conditions de processus réalistes.

Un exemple compact de logique de veto déterministe est présenté ci-dessous :

[Langage : Ladder Diagram] // Exemple : veto déterministe remplaçant la logique de marche générée // Si AI_Run_Cmd est vrai, mais que Safety_Permissive chute, // Motor_Out doit inconditionnellement se déverrouiller.

|---[ AI_Run_Cmd ]----[ Safety_Permissive ]-----------( Motor_Out )---| | | |---[/Safety_Permissive ]--------------------------------(U Motor_Out)-|

La caractéristique importante ici n'est pas l'élégance stylistique. C'est que la perte du permissif a une conséquence explicite, testable et inconditionnelle.

OLLA Lab valide le comportement, pas le statut de certification. C'est la limite correcte.

La capacité systématique selon la norme IEC 61508 dépend de pratiques de développement et de vérification disciplinées qui réduisent les fautes systématiques. Un simulateur basé sur le Web ne peut pas conférer de capacité systématique par lui-même, mais il peut fournir l'environnement nécessaire pour observer si la logique implémentée se comporte de manière cohérente avec ces pratiques disciplinées.

En termes pratiques, OLLA Lab soutient cela en permettant aux ingénieurs de :

• construire une logique Ladder avec des éléments de contrôle standard, y compris des contacts, des bobines, des temporisateurs, des compteurs, des comparateurs, des fonctions mathématiques et des instructions PID
• exécuter la logique en simulation sans matériel physique
• surveiller et manipuler des variables, des E/S, des valeurs analogiques et des paramètres liés au PID
• tester la logique face à des scénarios industriels réalistes plutôt que des problèmes abstraits
• comparer l'état du Ladder avec le comportement de l'équipement en 3D ou WebXR lorsque disponible
• répéter des conditions anormales qui seraient dangereuses ou coûteuses à induire sur une installation réelle

Cela est important car la correction mathématique unitaire ne suffit pas pour le contrôle industriel. Un barreau peut être syntaxiquement valide et échouer tout de même au niveau du processus. La validation par jumeau numérique est utile précisément parce qu'elle expose l'interaction entre l'état logiciel et l'état physique simulé.

Opérationnellement, la validation par jumeau numérique signifie ici exécuter la logique Ladder face à un modèle de machine ou de processus réaliste et observer si le comportement attendu de l'équipement, la progression de la séquence, les interverrouillages, les alarmes et les transitions vers l'état sûr se produisent dans des conditions normales et défaillantes.

Les scénarios réalistes exposent les hypothèses de contrôle que les exercices génériques cachent. Un tutoriel de démarrage moteur peut enseigner la logique de maintien. Il n'enseigne généralement pas la preuve défaillante, l'inhibition de redémarrage, l'arbitrage maître-esclave, la bande morte d'alarme analogique, ou ce qui se passe lorsqu'une commande opérateur entre en collision avec une condition de déclenchement.

C'est pourquoi le contexte du scénario est important. Les préréglages documentés d'OLLA Lab dans les domaines de l'eau, des eaux usées, du CVC, de la fabrication, de l'entreposage, de l'agroalimentaire, des services publics, de la chimie et de la pharmacie sont utiles non pas parce qu'ils sont nombreux, mais parce qu'ils forcent la logique dans un contexte opérationnel.

Différents scénarios enseignent différents modèles de sécurité et de mise en service :

• Les systèmes de pompage enseignent la rotation maître-esclave, la protection contre les bas niveaux, la détection de démarrage défaillant et le risque de débordement.
• Les convoyeurs et lignes de conditionnement enseignent la détection de bourrage, les permissifs de séquence et le comportement d'arrêt coordonné.
• Les systèmes CVC et de traitement d'air enseignent les interverrouillages, la preuve de ventilateur, la logique de position de registre et la gestion des alarmes.
• Les skids de processus enseignent les seuils analogiques, l'interaction PID, la logique de déclenchement et l'arrêt contrôlé.
• Les systèmes d'eau et d'eaux usées enseignent le contrôle de niveau, le cyclage de service, la priorisation des alarmes et la continuité du processus en cas de défaillance de l'équipement.

C'est aussi là que les instructions de construction guidées aident. Les démarrages rapides, les cartes d'E/S, les notes de philosophie de contrôle, les interverrouillages, les dictionnaires de tags et les étapes de vérification donnent à l'ingénieur une base structurée pour prouver le comportement. C'est plus utile que de laisser quelqu'un dans un éditeur vide et d'appeler cela du réalisme.

Les tests de faute doivent être conçus autour du risque de processus observable, et non autour de ce que l'IA a généré par hasard. La bonne question n'est pas « le code fonctionne-t-il ? », mais « que se passe-t-il lorsque le processus ment, cale ou disparaît ? ».

Un ensemble de tests de faute discipliné devrait inclure, au minimum :

• la perte de permissif pendant la marche active
• un retour d'information ou un signal de preuve défaillant
• un signal analogique haut, bas, gelé ou hors plage
• un cycle d'alimentation ou un redémarrage avec des bits conservés présents
• une commande opérateur asynchrone pendant une transition de séquence
• une perte de communication ou des données obsolètes, le cas échéant
• un désaccord de capteur lorsque des signaux redondants ou de confirmation existent

Pour chaque cas, l'ingénieur doit définir :

• la réponse sûre attendue
• le temps de réponse acceptable maximum
• les tags et sorties à observer
• les critères de réussite, d'échec et de révision

Le panneau des variables dans OLLA Lab est utile ici car il permet la manipulation directe des entrées et la visibilité de l'état pendant l'exécution. Cela prend en charge l'injection de fautes, l'observation des tags et le retest répétable. Encore une fois, la valeur est bornée : il s'agit d'un environnement de validation contrôlé pour les tâches de mise en service à haut risque, et non un substitut à l'acceptation formelle sur site, à la vérification matérielle ou à la compétence sur un processus réel.

Un dossier de décision est la preuve assemblée qui explique pourquoi la logique finale est acceptable. Dans cet article, l'orchestration agentique doit être comprise étroitement comme l'acte de l'ingénieur supervisant la logique générée, la testant face à des scénarios définis, rejetant les comportements dangereux et préservant le raisonnement derrière les révisions acceptées.

Un dossier de décision défendable devrait contenir :

• l'objectif de contrôle
• les exigences liées à la sécurité ou les atténuations des risques
• l'historique des révisions de la logique Ladder
• le scénario de simulation utilisé
• les cas de faute injectés
• les résultats observés
• le comportement final accepté
• les hypothèses ou limites non résolues
• la base de signature pour passer à l'étape de révision suivante

OLLA Lab contribue à ce dossier en donnant une structure à la boucle de construction et de vérification grâce à des scénarios guidés, la visibilité des variables, l'exécution de la simulation et le contexte de jumeau numérique. Il aide les ingénieurs à produire des preuves qui peuvent être révisées. C'est le seuil utile.

L'IA peut accélérer la génération d'ébauches, mais elle ne réduit pas la charge de la preuve. Dans les logiciels liés à la sécurité, la vitesse sans preuve est juste un chemin plus rapide vers une logique non vérifiée.

Les règles pratiques sont simples :

• traiter la logique Ladder générée comme une ébauche, jamais comme une vérité acceptée
• définir le comportement correct avant de tester
• valider face au comportement du processus, pas seulement l'apparence des barreaux
• injecter des fautes exprès
• préserver les preuves horodatées de la réponse attendue par rapport à la réponse observée
• réviser pour le déterminisme, la lisibilité et la traçabilité
• garder l'ingénieur humain responsable de l'acceptation

C'est la véritable boucle génération-validation. C'est moins glamour que les affirmations selon lesquelles l'IA écrit le code PLC, et plus utile dans le travail de sécurité.

- Lisez « The Deterministic Veto: Programming Safety PLCs » pour un traitement plus approfondi des interverrouillages matériels et de la logique d'état sûr inconditionnelle.

• Retournez au hub « Future of Automation » pour en savoir plus sur les flux de travail d'ingénierie résilients et la validation dirigée par la simulation.
• Consultez « EU AI Act High-Risk Compliance » si votre flux de travail d'automatisation doit également satisfaire aux exigences émergentes de gouvernance de l'IA.
• Prêt à tester le comportement en cas de faute directement ? Ouvrez le scénario « Safety Interlock » dans OLLA Lab et validez la logique face à un modèle de machine simulé.

- UP : Explorez le hub du Pilier 1. - ACROSS : Article connexe 1. - ACROSS : Article connexe 2. - ACROSS : Article connexe 3. - DOWN : Réservez une visite guidée de l'implémentation d'OLLA Lab.

- IEC 61131-3: Automates programmables — Partie 3 : Langages de programmation - Présentation de la norme IEC 61508 (sécurité fonctionnelle) - Cadre de gestion des risques liés à l'IA du NIST (AI RMF 1.0) - Jumeau numérique dans la fabrication : Une revue de littérature catégorique et classification (IFAC, DOI) - Jumeau numérique dans l'industrie : État de l'art (IEEE, DOI)

[Nom de l'auteur/Expert en automatisation]

[Nom du vérificateur/Ingénieur sécurité]