Comment les automates programmables (API) supervisent l'IA agentique avec une logique de sécurité déterministe

L'IA agentique peut proposer des actions, mais elle ne doit pas être autorisée à les exécuter directement sur des équipements industriels. Dans une architecture Industrie 5.0 plus sûre, l'API reste le superviseur de sécurité déterministe : il évalue les commandes générées par l'IA par rapport à des permissives, des verrouillages et une logique de sécurité intégrée (fail-safe) codés en dur avant que tout mouvement physique ne soit autorisé.

L'IA agentique ne remplace pas l'API. Elle modifie ce contre quoi l'API doit se défendre.

Le problème architectural est simple : les systèmes d'IA génèrent des sorties probabilistes, tandis que les systèmes de contrôle industriel doivent imposer un comportement déterministe à la limite de l'équipement. Cette distinction n'est pas philosophique. C'est la différence entre une suggestion de débit et une course de vanne sur une ligne sous pression.

Lors des tests de résistance par jumeau numérique dans OLLA Lab, des injections de points de consigne non contraintes de type IA ont produit des défauts de dépassement de course d'actionneur simulés dans 25 des 30 tests, tandis que l'ajout d'une logique de limitation (clamp) et de chien de garde déterministe a réduit ces violations à zéro dans les mêmes scénarios. Méthodologie : taille de l'échantillon = 30 simulations sur des scénarios de vannes et de convoyeurs ; définition de la tâche = injecter des changements de consigne erratiques et des pertes de communication dans des équipements contrôlés par langage Ladder ; comparateur de référence = aucune logique de limitation/chien de garde versus logique Ladder avec permissives bornées et gestion de temporisation ; fenêtre temporelle = T1 2026. Cela confirme la valeur de la logique de veto déterministe en simulation. Cela n'établit pas, en soi, la fiabilité sur le terrain, les performances SIL ou les taux de réduction des défauts universels.

La norme IEC 61508 et les pratiques de sécurité fonctionnelle associées clarifient la limite : une action critique pour la sécurité nécessite du déterminisme, une traçabilité et un comportement validé. Les multiplications matricielles sont utiles. Elles ne constituent pas une analyse de sécurité.

L'IA agentique fonctionne de manière probabiliste, tandis que la logique API s'exécute de manière déterministe.

Une définition opérationnelle est utile ici. Dans cet article, l'IA agentique désigne un système logiciel capable de générer des actions, des points de consigne ou des décisions de trajectoire en dehors d'un script séquentiel fixe, en fonction de l'évolution des entrées et des objectifs d'optimisation. En termes d'automatisation, cela signifie généralement des éléments tels que :

• la génération dynamique de points de consigne,
• des recommandations de séquençage adaptatif,
• la sélection autonome d'itinéraires ou de trajectoires,
• des suggestions de commandes basées sur des anomalies,
• l'optimisation de la supervision sur plusieurs actifs.

À l'inverse, la logique API déterministe désigne un contrôle basé sur le cycle de balayage (scan) où les mêmes entrées validées, le même état logique et les mêmes conditions de temporisation produisent le même comportement de sortie au sein d'un modèle d'exécution défini.

Cette distinction est importante car l'équipement industriel ne se soucie pas de savoir si une commande dangereuse provient d'un opérateur humain, d'un script d'historisation ou d'un agent IA. Une mauvaise commande reste une mauvaise commande.

Contrôle déterministe versus probabiliste à la limite de l'équipement

L'API existe au point où l'intention logicielle devient un mouvement physique.

Un service d'IA moderne peut s'exécuter de manière asynchrone sur un nœud de périphérie (edge), un service cloud ou un PC industriel local. Son temps de réponse peut varier en fonction de la latence du réseau, de la complexité du modèle, de la profondeur de la file d'attente ou de la qualité des données en amont. Un cycle de balayage d'API, par conception, est borné et répétitif. C'est pourquoi l'API reste l'endroit approprié pour appliquer les verrouillages, les permissives, les conditions de déclenchement et les vetos de sortie.

Le contraste pratique est simple :

| Attribut de contrôle | IA agentique | API / API de sécurité | |---|---|---| | Modèle d'exécution | Probabiliste ou heuristique | Exécution déterministe basée sur le balayage | | Comportement temporel | Variable, asynchrone | Borné, cyclique, temps réel strict ou quasi-temps réel selon la plateforme | | Force principale | Optimisation, adaptation, inférence de modèles | Exécution fiable, verrouillages, séquençage, réponse de sécurité | | Rôle de certification de sécurité | Non adapté comme exécuteur direct de fonction de sécurité IEC 61508 | Peut être mis en œuvre dans des architectures de sécurité certifiées si conçu correctement | | Préoccupation liée au mode de défaillance | Sortie non bornée, contexte obsolète, recommandation hallucinatoire, perte de communication | Défaut logique, erreur d'intégration, erreur de configuration, mais le comportement reste testable et traçable |

Pourquoi l'IA ne peut pas simplement « être le contrôleur »

L'IA peut assister le contrôle. On ne doit pas supposer qu'elle puisse remplir le rôle d'un contrôleur de sécurité.

La norme IEC 61508 n'interdit pas l'intelligence logicielle au sens large, mais la sécurité fonctionnelle exige des preuves de capacité systématique, un comportement prévisible, des contrôles de cycle de vie et des fonctions de sécurité validées. Les modèles d'IA actuels ne sont pas conçus comme des solveurs de sécurité déterministes. Leurs sorties sont sensibles au contexte et non reproductibles dans de nombreuses conditions pratiques. Cela en fait de mauvais candidats pour l'actionnement direct de sécurité.

Un contraste utile est celui entre optimisation et autorité de veto. L'IA peut recommander. L'API doit décider si la recommandation est physiquement et procéduralement admissible.

Un API oppose son veto aux commandes IA en forçant chaque commande externe à passer par une logique permissive déterministe avant d'atteindre les sorties physiques.

C'est l'architecture centrale. L'IA n'écrit pas directement sur la carte de sortie. Elle écrit, au mieux, dans un registre de commande supervisé, un point de consigne demandé ou un bloc de données non sécurisé. L'API évalue ensuite cette demande par rapport à des conditions codées en dur telles que :

• chaîne d'arrêt d'urgence saine,
• sélection de mode valide,
• verrouillage de maintenance inactif,
• fins de course non violés,
• variable de processus dans la plage de sécurité,
• présence d'un signal de vie (heartbeat) de communication,
• état de séquence valide,
• aucun déclenchement actif ou défaut verrouillé.

Si une condition requise échoue, l'API bloque, limite, substitue ou rejette la commande.

C'est l'architecture de veto. Elle est moins glamour que le contrôle autonome, ce qui explique précisément pourquoi elle a tendance à survivre à la mise en service.

L'API comme superviseur de sécurité

Un superviseur de sécurité API est une couche logique déterministe qui évalue les demandes provenant de l'IA par rapport à des contraintes opérationnelles et de sécurité explicites avant d'autoriser toute transition d'état de la machine ou changement de sortie analogique.

Cette définition est intentionnellement étroite. Elle décrit un comportement d'ingénierie observable :

• l'IA émet une demande,
• l'API vérifie les permissives,
• l'API rejette, borne ou transmet la demande,
• le comportement final de l'actionneur reste régi par une logique déterministe.

Dans une architecture mixte IA/OT, l'API doit traiter l'IA comme une source en amont non fiable mais potentiellement utile. C'est une conception de contrôle normale.

Un chemin de veto pratique

Un chemin supervisé typique ressemble à ceci :

3. L'API valide : 4. L'API soit :

• la fraîcheur de la source,
• la plage de commande,
• les permissives de mode,
• la légalité de la séquence,
• la disponibilité de l'équipement,
• les contraintes de sécurité.
• rejette la commande,
• la limite à une plage de sécurité,
• limite le taux de changement,
• substitue une valeur de repli,
• l'autorise.

1. L'IA génère une commande demandée ou un point de consigne analogique.
2. La demande est écrite dans une étiquette (tag) API non sécurisée ou échangée via une couche d'interface.
3. La sortie finale vers l'actionneur est toujours produite par la logique API, et non directement par l'IA.

C'est aussi là que la discipline de mise en service est importante. L'architecture non sécurisée n'est généralement pas spectaculaire. Il s'agit généralement d'un chemin d'écriture non vérifié et d'une temporisation manquante.

La supervision de l'IA nécessite des modèles Ladder qui détectent les demandes hors limites, les communications obsolètes, les transitions de séquence invalides et les taux de commande physiquement abusifs.

L'implémentation exacte varie selon la plateforme, mais les modèles de contrôle sont stables.

1. Logique de limitation (Clamp) pour des fenêtres de fonctionnement sûres

La logique de limitation restreint les valeurs analogiques générées par l'IA à une plage physiquement sûre et opérationnellement valide.

C'est la première ligne de défense pour les vitesses demandées, les positions de vannes, les cibles de pression, les points de consigne de température ou les taux de dosage. L'API compare la valeur demandée aux limites d'ingénierie et remplace toute valeur hors plage par une alternative bornée.

L'implémentation typique utilise :

• des comparaisons `LES` (inférieur à),
• des comparaisons `GRT` (supérieur à),
• des instructions de transfert (move) pour substituer les valeurs min/max,
• des limites dépendantes du mode,
• des bits d'alarme pour la visibilité de l'opérateur.

Exemples d'utilisation :

• limiter une commande de vanne à 20–80 % pendant le démarrage,
• empêcher les commandes de vitesse de pompe en dessous du débit de refroidissement minimum,
• borner un point de consigne de température en dessous des seuils de déclenchement,
• restreindre les changements de vitesse du convoyeur pendant le transfert de produit.

La logique de limitation répond à une question fondamentale : même si la demande est syntaxiquement valide, est-elle physiquement acceptable ?

2. Filtres de taux de variation pour éviter le fouettement mécanique

Le filtrage du taux de variation limite la vitesse à laquelle une valeur commandée peut changer entre les intervalles de balayage.

Un optimiseur IA peut passer d'une valeur optimale à une autre sans tenir compte de l'usure de l'actionneur, du coup de bélier, du glissement de courroie ou du retard thermique. L'équipement a tendance à protester après le deuxième ou troisième cycle.

Un API peut imposer :

• un delta maximum par balayage,
• un delta maximum par seconde,
• des profils de rampe de montée et de descente,
• la gestion de la zone morte (deadband),
• des limites distinctes pour le démarrage par rapport au fonctionnement en régime permanent.

Cela est particulièrement important dans :

• le contrôle de vitesse par variateur (VFD),
• le positionnement des vannes,
• les boucles de pression et de débit,
• les demandes de mouvement robotiques ou adjacentes aux servomoteurs,
• les processus avec inertie ou jeu mécanique.

3. Chiens de garde (Watchdog) pour la supervision du signal de vie

Un chien de garde vérifie que la source IA est active, actuelle et se met à jour dans un intervalle attendu.

Une implémentation courante utilise un bit de signal de vie ou une valeur incrémentielle provenant de la couche IA. Si le signal ne change pas dans un délai défini, l'API définit un défaut de communication et force le processus dans un état connu. Cet état peut être le maintien de la dernière valeur, une rampe de descente contrôlée, un transfert en manuel ou un arrêt complet, selon l'analyse des risques.

Les éléments Ladder typiques incluent :

• des temporisateurs `TON`,
• une logique de comparaison de signal de vie,
• des verrous de défaut,
• des conditions de réinitialisation,
• une logique de transfert de mode.

Un chien de garde n'est pas juste une commodité de communication. C'est une déclaration qu'une intelligence obsolète n'est pas une intelligence.

4. Vérifications de la légalité des séquences

La logique de légalité des séquences empêche l'IA de sauter les états de processus requis.

Cela est important dans les systèmes de lots (batch), les trains de pompes, les transitions CVC, les séquences NEP (nettoyage en place) et les unités utilitaires où l'ordre fait partie de la sécurité et de la protection de l'équipement. Une IA peut déduire qu'un état ultérieur est souhaitable. L'usine peut encore exiger des conditions de purge, de preuve, de permissive ou de temps de maintien au préalable.

Les vérifications typiques incluent :

• la validation de l'étape actuelle,
• le retour de preuve d'ouverture ou de fonctionnement,
• les temps de maintien minimum,
• les permissives de pré-démarrage,
• une logique de transition uniquement si confirmée.

5. Verrouillage des défauts et récupération déterministe

Le verrouillage des défauts garantit que les demandes IA dangereuses ou invalides ne peuvent pas être effacées implicitement par le cycle suivant.

Si l'IA demande une transition d'état illégale ou perd son signal de vie pendant une opération critique, l'API ne doit pas simplement effacer le problème lorsque la communication reprend. De nombreux systèmes nécessitent un défaut verrouillé, une reconnaissance par l'opérateur et un chemin de redémarrage défini.

Ce n'est pas un excès bureaucratique. C'est ainsi que l'on empêche les défauts intermittents de devenir des mystères récurrents.

Un échelon de supervision IA pratique combine la surveillance du signal de vie, le verrouillage des défauts, les vérifications de permissives et le déclenchement des sorties.

Voici un exemple simplifié de style Ladder pour illustration. La syntaxe variera selon la famille d'API.

[Langage : Schéma à contacts (Ladder)]

// Temporisation du signal de vie IA |---[ AI_Heartbeat_Changed ]-------------------------(RES T4:0)---| |---[/AI_Heartbeat_Changed ]-------------------------(TON T4:0)---| | PRE 500ms |

// Verrouiller le défaut de communication IA sur temporisation |---[ T4:0/DN ]--------------------------------------(L AI_Fault)--|

// Effacer le défaut uniquement avec réinitialisation opérateur et signal de vie valide restauré |---[ Reset_PB ]---[ AI_Healthy ]--------------------(U AI_Fault)--|

// Permissive de limitation pour la commande de vanne |---[ AI_Request_GT_Max ]----------------------------(OTE Clamp_Hi)-| |---[ AI_Request_LT_Min ]----------------------------(OTE Clamp_Lo)-|

// Sortie finale autorisée uniquement si aucun défaut IA et toutes les permissives de sécurité sont vraies |---[ AI_Command_Enable ]---[/AI_Fault]---[ Safe_Permissive ]---[ No_Trip ]---(OTE Valve_Open)--|

Le point technique n'est pas le choix exact du mnémonique. C'est la structure de contrôle :

• vérifier la fraîcheur de la source,
• verrouiller les défauts de manière déterministe,
• exiger des conditions de récupération explicites,
• déclencher chaque sortie finale par des permissives strictes.

La norme IEC 61508 reste importante car l'ajout de l'IA ne supprime pas le besoin d'une sécurité fonctionnelle démontrable ; elle augmente généralement le besoin de séparation architecturale et de discipline de validation.

La norme IEC 61508 est la norme fondamentale de sécurité fonctionnelle pour les systèmes liés à la sécurité électriques, électroniques et électroniques programmables. En termes pratiques, elle définit la manière dont les fonctions de sécurité sont spécifiées, conçues, validées et maintenues tout au long du cycle de vie. Elle sous-tend également de nombreuses normes sectorielles.

Pour cet article, le point pertinent est plus étroit : une fonction de sécurité doit être mise en œuvre d'une manière analysable, testable et justifiée par des preuves. Les sorties générées par l'IA ne sont pas intrinsèquement disqualifiées de l'existence quelque part dans le système plus large, mais elles ne remplacent pas la logique de sécurité déterministe.

Ce que cela signifie dans une architecture de contrôle réelle

Dans une architecture crédible :

• L'IA peut recommander un point de consigne.
• Le système de contrôle (BPCS) ou l'API peut évaluer et mettre en œuvre une version bornée de celui-ci.
• La fonction de sécurité reste séparée et déterministe.
• Les déclenchements, les arrêts et les actions de protection ne dépendent pas de l'inférence de l'IA.

Lorsqu'un API de sécurité est utilisé, la séparation doit être encore plus nette. La logique de sécurité n'est pas l'endroit pour l'improvisation probabiliste.

Ce que cela ne signifie pas

Cela ne signifie pas que l'IA n'a aucune utilité dans l'automatisation industrielle.

L'IA peut être précieuse pour :

• la maintenance prédictive,
• l'optimisation énergétique,
• la détection logicielle (soft sensing),
• la détection d'anomalies,
• la planification de la production,
• les suggestions de réglage adaptatif,
• l'aide à la décision de l'opérateur.

Le modèle de conception correct est une intelligence consultative ou de supervision probabiliste au-dessus d'une application de contrôle déterministe. C'est la réponse pratique de l'Industrie 5.0.

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

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

• définir ce que le système de contrôle doit faire dans des conditions normales et anormales,
• observer le comportement des E/S et des étiquettes internes pendant l'exécution,
• injecter des défauts réalistes et des demandes anormales,
• comparer l'état Ladder avec l'état de l'équipement simulé,
• réviser la logique après une défaillance,
• documenter pourquoi la révision est plus sûre ou plus robuste.

C'est la distinction entre syntaxe et déployabilité.

Une personne qui sait dessiner un échelon n'est pas nécessairement prête à superviser un équipement influencé par l'IA. Une personne qui sait tester les chiens de garde, la logique de limitation, la légalité des séquences et la récupération des défauts par rapport à un modèle réaliste est beaucoup plus proche.

La validation de la logique de supervision de l'IA nécessite un environnement à risque contenu où des commandes erratiques peuvent être injectées sans risquer le matériel, la production ou les personnes.

C'est là qu'OLLA Lab devient opérationnellement utile.

OLLA Lab est un environnement de simulation de logique Ladder et de jumeau numérique basé sur le Web où les utilisateurs peuvent construire des programmes Ladder, les exécuter en simulation, inspecter les variables et les E/S, et valider le comportement par rapport à des scénarios industriels réalistes. Dans ce contexte, sa valeur est bornée et claire : il donne aux ingénieurs un endroit pour répéter une logique de mise en service à haut risque avant de l'appliquer sur des systèmes réels.

Comment OLLA Lab soutient la pratique de la supervision IA

Les capacités pertinentes de la plateforme incluent :

• un éditeur de logique Ladder basé sur navigateur pour construire la logique de supervision,
• un mode de simulation pour exécuter et arrêter la logique en toute sécurité,
• un panneau de variables pour surveiller et forcer les étiquettes,
• des outils analogiques et PID pour des exercices de points de consigne bornés,
• des simulations 3D / WebXR pour observer le comportement de l'équipement,
• des laboratoires basés sur des scénarios avec verrouillages, dangers et notes de mise en service,
• GeniAI, le guide de laboratoire IA, pour un support guidé lors de la construction ou du débogage de la logique.

La revendication du produit doit rester modeste : OLLA Lab ne certifie pas les fonctions de sécurité, n'accorde pas de compétence sur site et ne remplace pas les FAT/SAT sur un projet réel. Il permet aux ingénieurs de répéter le type exact de validation logique que les usines réelles ne peuvent pas se permettre de traiter comme de l'improvisation.

Un flux de travail OLLA Lab pratique pour la validation de la liaison IA

Un exercice de laboratoire utile consiste à simuler l'IA comme une source de commande externe, puis à tester la réponse de supervision de l'API.

Construisez et testez ce qui suit :

- Exemple : `AI_Valve_SP_Request`

• Traitez-la comme une entrée non fiable.

• limitation min/max,
• limiteur de taux de variation,
• temporisation chien de garde,
• permissives de séquence,
• verrouillage de défaut.

• position de vanne,
• état de fonctionnement du moteur,
• réponse du niveau de réservoir,
• mouvement du convoyeur,
• vitesse du ventilateur.

• sauts soudains de 0 % à 100 %,
• valeurs négatives impossibles,
• signal de vie obsolète,
• commande pendant une condition de déclenchement,
• commande pendant une étape de séquence invalide.

• L'API a-t-il rejeté la demande ?
• Le défaut s'est-il verrouillé ?
• L'équipement est-il resté dans un comportement sûr ?
• Le processus est-il passé à l'état de repli prévu ?

• ajuster les valeurs de temporisation,
• resserrer les permissives,
• ajouter une visibilité d'alarme,
• affiner les conditions de redémarrage.

C'est la validation par jumeau numérique en termes pratiques : non pas « le modèle semble impressionnant », mais « la logique survit aux mauvaises entrées sans produire de mauvais mouvement ».

1. Créer une étiquette de commande supervisée
2. Ajouter une logique de validation déterministe
3. Mapper les sorties vers l'équipement simulé
4. Injecter des cas d'erreur via le panneau de variables
5. Observer à la fois l'état Ladder et l'état de l'équipement simulé
6. Réviser et retester

Les ingénieurs doivent documenter un ensemble compact de preuves, pas une galerie de captures d'écran.

Si l'objectif est de démontrer la compétence en supervision IA-API, utilisez cette structure :

Indiquez ce que signifie un comportement correct en termes observables : plage de consigne autorisée, réponse à la temporisation, transitions de séquence valides, comportement d'alarme et état de repli sûr.

Documentez l'entrée anormale exacte : signal de vie obsolète, point de consigne impossible, transition invalide ou changement de taux excessif.

Expliquez quelle logique a été modifiée : seuils de limitation, temporisation du chien de garde, verrouillage des défauts, conditions de verrouillage ou gestion des modes.

1. Description du système Définissez la machine ou le processus, la variable demandée par l'IA, les sorties contrôlées par l'API et les modes de fonctionnement.
2. Définition opérationnelle du « correct »
3. Logique Ladder et état de l'équipement simulé Montrez les échelons pertinents, les étiquettes et la réponse de l'équipement correspondante en simulation.
4. Le cas de défaut injecté
5. La révision effectuée
6. Leçons apprises Indiquez ce que la défaillance a révélé et ce que la logique révisée empêche désormais.

Ce format est utile car il rend le jugement d'ingénierie visible. N'importe qui peut prétendre avoir travaillé avec l'IA et les API. La preuve commence lorsque le cas de défaut est explicite.

Les erreurs d'intégration les plus courantes sont architecturales, pas algorithmiques.

Traiter la sortie de l'IA comme une autorité de contrôle fiable

C'est l'erreur principale. Si l'IA écrit directement sur un chemin de commande en direct sans validation déterministe, l'architecture est déjà faible.

Confondre optimisation et sécurité

Une IA peut améliorer le débit ou l'utilisation de l'énergie. Cela ne la rend pas adaptée à l'action de protection, à la logique de déclenchement ou aux décisions de contournement de verrouillage.

Omettre la gestion de la temporisation et des données obsolètes

Un service IA déconnecté qui laisse la dernière valeur en place peut être plus dangereux qu'un service bruyant. Le silence est toujours un état.

Ignorer la légalité des séquences

De nombreuses défaillances surviennent non pas parce que la valeur demandée est numériquement fausse, mais parce qu'elle arrive à la mauvaise étape du processus.

Tester uniquement les cas nominaux

Si le laboratoire prouve seulement que le système se comporte bien quand tout est sain, il n'a pas encore prouvé grand-chose. La mise en service est l'endroit où les hypothèses sont auditées.

Les API agissent comme des superviseurs de sécurité pour l'IA agentique en imposant une logique de veto déterministe entre les recommandations probabilistes et l'équipement physique.

C'est la règle de conception centrale. L'IA peut optimiser, suggérer et s'adapter. L'API doit toujours valider, contraindre et, si nécessaire, refuser. Dans l'Industrie 5.0, le problème de contrôle n'est pas l'IA ou l'API. C'est comment placer chacun dans le rôle qu'il peut réellement remplir avec des preuves.

OLLA Lab s'intègre dans ce flux de travail en tant qu'environnement de validation borné. Il permet aux ingénieurs de construire une logique Ladder, de simuler des entrées anormales de type IA, d'observer la réponse de l'équipement et de durcir la logique de supervision avant que des modèles similaires ne soient exposés au risque de mise en service en direct. C'est une utilisation crédible de la simulation : prouver le comportement avant que le métal ne bouge.

- NIST AI Risk Management Framework (AI RMF 1.0) - IEC 61508 Functional safety overview - IEC 62443 industrial cybersecurity standards overview - Digital twin enabling technologies (IEEE Access) - Industrial AI for Industry 4.0 (Manufacturing Letters)