Comment programmer un veto déterministe dans un automate de sécurité pour contrer les hallucinations de l'IA

Pour contrer les hallucinations de l'IA dans l'automatisation industrielle, les ingénieurs doivent placer l'IA derrière un veto d'automate (PLC) déterministe. L'automate doit vérifier les commandes demandées par l'IA par rapport à des limites fixes, des permissifs d'état et des fonctions de sécurité câblées avant toute actionnement. Cette défense multicouche sépare l'optimisation probabiliste de l'exécution déterministe.

L'IA ne devient pas sûre simplement parce qu'elle semble convaincante. Dans le contrôle industriel, la confiance n'est pas une variable de contrôle.

Le conflit d'ingénierie est simple : les LLM et les systèmes d'IA agentiques sont probabilistes et non déterministes, tandis que les automates exécutent une logique sur des cycles de balayage répétables avec un comportement borné. Cette différence n'est pas philosophique. Elle est architecturale, et dans les contextes liés à la sécurité, elle est décisive.

Dans un lot interne récent de 500 anomalies de points de consigne générées par IA et simulées via les flux de travail de validation par jumeau numérique d'OLLA Lab, un bridage du taux de variation côté automate associé à des permissifs d'état explicites a bloqué 100 % des commandes hors limites catastrophiques avant qu'elles n'actionnent les modèles virtuels de vannes et de moteurs. Méthodologie : n=500 cas d'anomalies injectés sur des tâches de vitesse, de pression et de position de vanne bornées ; comparateur de référence = passage direct de la commande demandée par l'IA vers l'étiquette d'actionneur simulé ; fenêtre temporelle = tests internes au laboratoire d'Ampergon Vallis réalisés au T1 2026. Cela confirme la valeur de la vérification déterministe en simulation. Cela ne constitue pas une certification IEC 61508, une preuve SIL, ni une affirmation concernant toutes les architectures d'usine.

La réponse pratique n'est pas d'interdire l'IA. C'est de lui refuser l'autorité d'exécution directe et d'exiger que l'automate maintienne un veto déterministe permanent.

Les hallucinations de l'IA nécessitent un veto déterministe car les sorties de l'IA ne sont pas garanties d'être bornées, répétables ou synchrones avec le cycle de balayage, contrairement à ce que doit être l'exécution d'un automate.

Dans un système de contrôle, une commande dangereuse est dangereuse même si elle a été générée par un modèle statistiquement impressionnant. Une vanne ne se soucie pas du fait que la probabilité du jeton semble persuasive.

Les normes IEC 61508 et ISO 13849 sont construites autour d'un comportement prévisible, d'une gestion des défaillances définie et d'états sûrs connus. Les fonctions de contrôle liées à la sécurité doivent échouer de manière analysable, bornée et validable. Les systèmes actuels de type LLM ne répondent pas à cette exigence car leurs modes de défaillance ne sont pas caractérisables de manière exhaustive comme l'exige la logique de sécurité déterministe. C'est là le vrai problème : non pas que l'IA soit nouvelle, mais que l'IA n'est pas suffisamment bornée systématiquement pour posséder le chemin d'actionnement final.

Le cycle de balayage vs le moteur d'inférence

Un automate exécute une logique de manière cyclique. Il scanne les entrées, résout la logique, met à jour les sorties et répète l'opération à un intervalle connu, souvent de l'ordre de la milliseconde selon la plateforme, la structure de la tâche et la charge.

Un moteur d'inférence IA ne se comporte pas ainsi. Son temps de réponse varie en fonction de la taille du modèle, de la disponibilité des ressources de calcul, des conditions réseau, de la surcharge d'orchestration et de la complexité de l'invite. Même lorsque la latence moyenne semble acceptable, le pire scénario de synchronisation et de comportement de sortie reste le problème.

Cela crée deux classes de risques :

- Risque de synchronisation : la réponse de l'IA peut arriver en retard, hors séquence ou pendant un état machine invalide. - Risque de contenu : la réponse de l'IA peut demander une action impossible, dangereuse ou aveugle au contexte.

Un automate peut tolérer des demandes retardées ou rejetées. Un train de pompes ne peut pas tolérer la fantaisie.

Qu'exigent réellement les normes ?

Les normes exigent un comportement de sécurité prévisible, pas un logiciel à la mode.

À un haut niveau :

• IEC 61508 traite de la sécurité fonctionnelle des systèmes électriques, électroniques et électroniques programmables liés à la sécurité.
• ISO 13849 traite des parties des systèmes de contrôle liées à la sécurité, en particulier dans les contextes de machines.
• Les deux cadres dépendent d'architectures définies, d'un comportement validé et de réponses connues aux conditions de défaillance.

Cela ne signifie pas que tout composant logiciel non déterministe est interdit partout dans une pile industrielle. Cela signifie que les composants non déterministes ne doivent pas être traités comme l'autorité de sécurité finale. La distinction est importante. La perception et l'optimisation peuvent être probabilistes ; le veto et le chemin d'arrêt ne peuvent pas l'être.

Un veto déterministe est une structure logique codée en dur, liée au cycle de balayage, qui évalue une commande demandée et la bloque, la bride ou l'outrepasse lorsqu'elle viole des limites physiques, des contraintes de processus ou des permissifs d'état machine.

Il s'agit d'une définition opérationnelle, pas d'un slogan. Un veto déterministe doit être observable dans la logique et testable par rapport à des cas de défaillance.

En pratique, un veto déterministe inclut souvent :

- Contrôle des limites : rejet ou bridage des valeurs au-dessus ou en dessous des limites autorisées. - Limitation du taux de variation : prévention des changements brusques au-delà des rampes de sécurité. - Permissifs d'état : autorisation des commandes uniquement dans des états de fonctionnement valides. - Gestion des alarmes et des déclenchements : forçage d'une réponse sûre en cas de conditions anormales. - Isolation de mode : prévention des actions distantes ou demandées par l'IA dans les modes local, maintenance ou défaillant.

Si l'IA demande 150 % de vitesse d'entraînement et que l'automate la bride au maximum configuré tout en déclenchant une alarme, le veto a fonctionné. Si l'IA peut écrire directement dans l'image de sortie, l'architecture est mauvaise.

Définitions opérationnelles importantes

Ces termes sont souvent utilisés de manière vague. Ils ne devraient pas l'être.

- Veto déterministe : logique d'automate qui évalue une demande externe ou générée par IA à chaque cycle et bloque l'exécution dangereuse par des limites, permissifs et règles de défaillance explicites. - Défense multicouche : séparation architecturale entre les fonctions IA/IT qui suggèrent ou optimisent et les fonctions automate/OT qui vérifient, exécutent et imposent les limites de sécurité. - Simulation-Ready : capacité à tracer la causalité des E/S, observer un comportement anormal, injecter des cas de défaillance, diagnostiquer la réponse de contrôle et réviser la logique dans un environnement virtuel avant de toucher au matériel physique.

« Simulation-Ready » n'est pas un raccourci pour « capable d'écrire de la syntaxe ladder ». Cela signifie que l'ingénieur peut prouver le comportement sous contrainte. La syntaxe est bon marché ; la déployabilité ne l'est pas.

L'architecture de défense multicouche correcte donne à l'IA une influence sans lui donner une autorité incontrôlée.

La séparation doit être explicite :

### Couche 1 : Agent IA pour la perception ou l'optimisation

Cette couche peut :

• estimer la demande,
• suggérer des points de consigne,
• recommander le routage,
• classifier les conditions de fonctionnement,
• générer une ébauche de logique ou des conseils pour l'opérateur.

Cette couche ne doit écrire que dans des étiquettes de mémoire intermédiaires, des structures de message ou des variables de demande de supervision. Elle ne doit pas écrire directement dans les sorties physiques ou la mémoire de sécurité.

### Couche 2 : Veto déterministe dans l'automate

Cette couche évalue la demande de l'IA par rapport à des règles d'ingénierie fixes telles que :

• valeurs max/min autorisées,
• états machine valides,
• verrouillages,
• permissifs,
• exigences d'étape de séquence,
• conditions d'alarme et de déclenchement,
• limites de taux de variation.

C'est ici que la commande devient acceptable, modifiée ou rejetée.

### Couche 3 : Chemin d'exécution de sécurité câblé ou certifié

Cette couche inclut, le cas échéant :

• chaînes d'arrêt d'urgence (E-stop),
• relais de sécurité,
• tâches d'automate de sécurité,
• contacteurs,
• circuits STO,
• verrouillages de protection,
• fonctions d'arrêt indépendantes.

Cette couche doit rester en dehors de la carte mémoire de l'IA et en dehors de toute optimisation de supervision logicielle. La sécurité câblée existe parce que les logiciels développent parfois des opinions.

Vous programmez le veto en forçant chaque commande demandée par l'IA à passer par une logique de vérification explicite avant qu'elle ne puisse influencer la variable de contrôle finale.

Le principe de conception clé est simple : les demandes de l'IA sont des propositions, pas des sorties.

Mise en œuvre du bridage du point de consigne

Un bridage de limites empêche les valeurs impossibles ou dangereuses d'atteindre la commande de l'actionneur.

Utilisez une structure comme celle-ci :

Exemple de traduction en texte structuré / logique Ladder :

SI AI_Requested_Speed > Max_Allowable_Speed ALORS Actual_Drive_Speed := Max_Allowable_Speed; Déclencher Alarm_AI_Hallucination_Over_Speed; SINON SI AI_Requested_Speed < Min_Allowable_Speed ALORS Actual_Drive_Speed := Min_Allowable_Speed; Déclencher Alarm_AI_Hallucination_Under_Speed; SINON Actual_Drive_Speed := AI_Requested_Speed; FIN_SI;

C'est le modèle minimal, pas l'architecture finale.

Une mise en œuvre orientée production ajoute généralement :

- permissif d'état : n'accepter les demandes que lorsque la machine est dans un état de séquence valide - bridage ROC (taux de variation) : limiter le changement par cycle ou par seconde - bit de qualité : rejeter les données amont obsolètes, invalides ou non fiables - gestion du délai d'attente (timeout) : revenir à une valeur de repli si le flux de demande est interrompu - verrouillage des alarmes et visibilité opérateur : rendre le rejet visible et révisable

Un chemin de contrôle plus complet ressemble souvent à ceci :

1. Recevoir `AI_Requested_Speed`
2. Valider la qualité et la fraîcheur de la source
3. Confirmer `System_Auto = TRUE`
4. Confirmer que tous les permissifs sont vrais
5. Brider aux min/max d'ingénierie
6. Appliquer la limite ROC
7. Écrire dans `Actual_Drive_Speed_Command`
8. Déclencher ou inhiber si la chaîne de sécurité est ouverte

Que doit imposer la logique Ladder avant de transmettre une commande IA ?

L'automate doit imposer les mêmes choses qu'un ingénieur de mise en service prudent demanderait avant de mettre l'équipement sous tension :

• La machine est-elle dans le bon mode ?
• La séquence est-elle à la bonne étape ?
• Tous les permissifs sont-ils satisfaits ?
• Les rétroactions sont-elles saines ?
• La valeur demandée est-elle dans les limites physiques ?
• Le changement demandé est-il plausible pour ce processus ?
• Y a-t-il une condition de déclenchement ou de sécurité active ?

Cette dernière question a tendance à compter plus que le schéma d'architecture.

La chaîne d'arrêt d'urgence maître

La chaîne d'arrêt d'urgence maître doit se situer en dehors de la limite d'autorité de l'IA car le comportement d'arrêt d'urgence ne peut pas dépendre de la qualité de l'inférence, de la synchronisation réseau ou de l'état du logiciel de supervision.

En pratique :

• Le chemin d'arrêt d'urgence doit être câblé ou géré dans une fonction de sécurité certifiée comme l'exige l'application.
• Le système IA ne doit ni écrire ni supprimer l'état d'arrêt d'urgence.
• La tâche de contrôle standard peut observer l'état d'arrêt d'urgence, mais elle ne doit pas en être le seul gardien.
• Toute commande demandée par l'IA doit s'effondrer sans danger lorsque la chaîne d'arrêt d'urgence s'ouvre.

Une règle utile est la suivante : si un hoquet réseau, une erreur de modèle ou une défaillance de l'analyseur peut maintenir le mouvement activé, la conception n'est pas terminée.

Vous le testez en injectant des commandes anormales et en prouvant que la réponse de l'automate reste bornée, observable et correcte dans ces conditions.

C'est là que beaucoup d'équipes s'arrêtent trop tôt. Un test nominal propre ne prouve presque rien.

Au minimum, testez ces cas :

• demandes IA au-dessus de la valeur maximale autorisée
• demandes IA en dessous de la valeur minimale autorisée
• changements de pas brusques au-delà de la rampe de sécurité
• commandes émises dans le mauvais état machine
• commandes émises alors qu'un permissif est faux
• valeurs amont obsolètes ou gelées
• signaux de demande oscillants ou bruyants
• activation de l'arrêt d'urgence ou du déclenchement pendant une demande IA active

Pour chaque cas, vérifiez :

• la commande finale de l'actionneur,
• le comportement de l'alarme,
• le comportement de la séquence,
• la visibilité de l'opérateur,
• le comportement de récupération après la disparition de la défaillance.

Un veto qui bride correctement mais laisse la séquence bloquée dans un état incohérent n'est qu'une demi-solution.

OLLA Lab est utile ici en tant qu'environnement de validation borné où les ingénieurs peuvent injecter de mauvaises commandes, observer la réponse de l'équipement et réviser la logique Ladder avant toute implication de matériel réel.

Ce positionnement est important. OLLA Lab n'est pas un certificateur de sécurité et ne remplace pas une validation formelle sur la plateforme cible. C'est un environnement pratique pour répéter une logique de mise en service à haut risque de manière contenue.

Au sein d'OLLA Lab, les ingénieurs peuvent :

• construire une logique Ladder dans un éditeur basé sur le web,
• exécuter une simulation sans matériel physique,
• surveiller les étiquettes, les E/S, les valeurs analogiques et les variables liées au PID,
• utiliser des modèles d'équipement basés sur des scénarios,
• comparer l'état du Ladder avec le comportement simulé de la machine,
• réviser la logique après avoir observé un cas de défaillance.

Pour le cas d'utilisation de cet article, le flux de travail pertinent est simple :

1. Créer une étiquette intermédiaire telle que `AI_Requested_Speed`
2. Acheminer cette étiquette à travers une logique de bridage et de permissif
3. Observer le `Actual_Drive_Speed_Command` résultant
4. Injecter des valeurs anormales ou des modèles instables
5. Confirmer que le modèle simulé de moteur, de pompe ou de vanne ne dépasse jamais les limites de sécurité
6. Examiner les alarmes et réviser la logique

C'est là qu'OLLA Lab devient opérationnellement utile. Vous ne pouvez pas tester de manière responsable une commande de vanne ouverte à 200 % hallucinée sur un skid de processus réel juste pour voir ce qui se passe. La curiosité est précieuse ; le matériel plié est coûteux.

À quoi ressemble « Simulation-Ready » en pratique

Un ingénieur est Simulation-Ready lorsqu'il peut faire tout ce qui suit dans un environnement virtuel :

• tracer la cause et l'effet de l'entrée à la sortie,
• observer si un permissif ou un verrouillage a bloqué l'exécution,
• identifier l'échelon ou la condition exacte qui a produit la réponse,
• comparer l'état de la logique de contrôle à l'état de l'équipement simulé,
• injecter une défaillance et expliquer le comportement résultant,
• réviser la logique et retester jusqu'à ce que la réponse soit bornée et répétable.

C'est le seuil qui compte pour la préparation à la mise en service. Pas « savoir placer une instruction de temporisation », mais « pouvoir prouver pourquoi la machine a bougé ou n'a pas bougé ».

L'artefact approprié est un ensemble compact de preuves d'ingénierie, pas une galerie de captures d'écran.

Utilisez cette structure :

Indiquez ce que signifie un comportement acceptable en termes observables : plage autorisée, états valides, réponse attendue aux alarmes, comportement de déclenchement et comportement de récupération.

Documentez l'entrée anormale exacte : demande de survitesse, commande d'état invalide, étiquette obsolète, signal bruyant ou arrêt d'urgence pendant le mouvement.

Enregistrez ce qui a changé dans la logique : bridage ajouté, permissif resserré, délai d'attente introduit, alarme verrouillée, limite ROC ajustée.

1. Description du système Définissez la machine ou la cellule de processus, la variable contrôlée, les modes de fonctionnement et la limite de sécurité pertinente.
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé Montrez la logique de contrôle parallèlement à la réponse simulée de l'actionneur ou du processus afin que la chaîne causale soit visible.
4. Le cas de défaillance injecté
5. La révision effectuée
6. Leçons apprises Indiquez ce que la défaillance a exposé et quelle règle de conception en découle désormais.

Cela produit des preuves qu'un autre ingénieur peut examiner, contester et reproduire. C'est la norme à viser.

L'erreur la plus courante est de permettre à l'IA de contourner la couche de vérification.

Parmi les autres erreurs récurrentes, citons :

• écrire la sortie de l'IA directement dans les étiquettes de commande de l'actionneur,
• traiter la performance moyenne de l'IA comme un argument de sécurité,
• oublier la détection des données obsolètes,
• omettre les permissifs basés sur l'état,
• compter sur les alarmes IHM au lieu de blocs d'exécution matériels,
• accorder trop de confiance à la simulation sans validation finale spécifique à la plateforme,
• confondre le Ladder généré avec le Ladder validé.

Un échelon généré n'est pas un échelon prouvé. Le contrôle industriel est toujours régi par ce que la machine fait réellement.

Le modèle correct n'est pas « l'IA contrôle l'usine ». Le modèle correct est « l'IA peut suggérer, mais l'automate décide, et la couche de sécurité peut toujours dire non ».

Un veto déterministe est le mécanisme d'ingénierie qui rend cette limite réelle. Il convertit les demandes non bornées en un comportement de contrôle borné grâce à des bridages, des permissifs, des verrouillages et des fonctions de sécurité indépendantes. C'est ainsi que vous empêchez un logiciel probabiliste de devenir un incident physique.

OLLA Lab s'intègre dans ce flux de travail en tant qu'environnement de répétition et de validation. Il permet aux ingénieurs de pratiquer les cas inconfortables — mauvais points de consigne, états invalides, signaux bruyants, permissifs défaillants, arrêts d'urgence — sans utiliser l'équipement réel comme banc d'essai. C'est un chemin plus crédible vers le jugement de mise en service que de mémoriser la syntaxe en espérant que la première vraie défaillance sera douce.

- IEC 61131-3 : Automates programmables — Partie 3 : Langages de programmation - Vue d'ensemble de l'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 une classification (IFAC, DOI) - Jumeau numérique dans l'industrie : état de l'art (IEEE, DOI)

Expert en automatisation industrielle et systèmes de sécurité fonctionnelle, spécialisé dans l'intégration de l'IA dans les environnements OT critiques.

Cet article a été vérifié par les ingénieurs systèmes d'Ampergon Vallis Lab pour garantir la conformité avec les principes de sécurité déterministe et les meilleures pratiques de simulation.