Comment séparer la perception IA de la sécurité API : L'architecture « Bulbe Rachidien »

L'architecture « Bulbe Rachidien » sépare la perception IA non déterministe du contrôle API déterministe. Dans ce modèle, l'IA peut proposer des points de consigne ou des classifications, mais l'API demeure la couche d'exécution et de validation temps réel rigoureuse qui impose des limites, des permissifs, des chiens de garde et un comportement en mode sécurisé avant que toute commande n'atteigne l'équipement.

L'IA n'est pas un contrôleur de sécurité, et la traiter comme tel est une erreur architecturale avant même de devenir une erreur de mise en service. La distinction utile est simple : l'IA excelle dans la perception, l'estimation et l'optimisation ; les API excellent dans l'exécution déterministe, les interverrouillages et le contrôle borné.

Cette distinction est cruciale car les systèmes de contrôle industriels ne tombent pas en panne dans l'abstrait. Ils tombent en panne sous forme de battements de cœur manqués, de valeurs obsolètes, de conditions de concurrence et de sorties qui s'activent alors qu'elles ne le devraient pas. La machine est rarement impressionnée par un modèle ingénieux.

Un récent test interne chez Ampergon Vallis confirme la valeur pratique de cette séparation. Au cours d'un exercice de simulation de 100 heures dans OLLA Lab, des mises à jour asynchrones de points de consigne externes injectées dans un scénario de contrôle en boucle fermée ont produit une augmentation de 14 % des événements de saturation intégrale (integral windup) par rapport à un chemin de validation API limité et bridé, tandis que le chemin régi par l'API a maintenu la variance de réponse dans une enveloppe d'exécution déterministe de 3 ms pour la séquence de validation. [Méthodologie : test simulé de 100 heures ; tâche = transfert de point de consigne externe dans un scénario de contrôle borné ; comparateur de référence = injection directe de point de consigne asynchrone sans validation par limiteur et chien de garde ; fenêtre temporelle = une seule exécution continue de 100 heures.] Cette métrique soutient la valeur de la validation API défensive en simulation. Elle ne soutient aucune affirmation générale concernant tous les systèmes d'IA, toutes les usines ou la certification de sécurité formelle.

Une exécution déterministe est requise car les décisions de sécurité et de contrôle primaire doivent se produire dans des limites temporelles connues. Les moteurs d'inférence IA, qu'ils soient locaux ou distants, ne garantissent pas cette propriété.

Un API exécute son programme dans un cycle de balayage (scan cycle) borné. Les entrées sont lues, la logique est résolue, les sorties sont écrites, et le cycle se répète à un intervalle défini. Cet intervalle peut varier légèrement selon la plateforme et la charge du programme, mais il est conçu pour rester prévisible et observable. La prévisibilité est l'objectif.

Les systèmes d'IA fonctionnent différemment. Leur temps de réponse peut varier en fonction de la charge du processeur, de la pression mémoire, du comportement du planificateur, de la taille du modèle, de l'étranglement thermique, des délais du middleware ou de la latence réseau. Même lorsque l'inférence moyenne est rapide, c'est le pire scénario temporel qui compte lorsque l'équipement peut bouger, entrer en collision, déborder, surchauffer ou ne pas se déclencher.

Les mathématiques du cycle de balayage versus l'inférence asynchrone

La distinction technique n'est pas philosophique. Elle est temporelle.

• Chemin de contrôle API
• S'exécute dans un cycle de balayage répété
• Prend en charge l'évaluation logique bornée
• Est conçu pour une gestion d'E/S déterministe
• Peut être audité par rapport au comportement temporel et aux pannes

• Chemin de calcul IA
• S'exécute de manière asynchrone
• Peut renvoyer des résultats à des intervalles irréguliers
• Peut stagner, expirer, présenter du jitter ou produire des sorties obsolètes
• Dépend souvent de piles logicielles non conçues comme logique de sécurité primaire

En termes pratiques, on peut faire confiance à un API pour évaluer un permissif à chaque balayage. Un service IA peut être utile, mais pas digne de confiance de la même manière. Utile et digne de confiance ne sont pas des synonymes. Les usines apprennent cette distinction à leurs dépens lorsqu'elles l'oublient.

Ce que disent les normes sur le contrôle déterministe

La norme IEC 61508 établit le cadre de sécurité fonctionnelle pour les systèmes électriques, électroniques et électroniques programmables liés à la sécurité. Une implication centrale pour cette discussion est directe : le comportement lié à la sécurité nécessite des caractéristiques d'exécution démontrables, bornées et validées.

Cela ne signifie pas que chaque programme API est automatiquement sûr. Cela signifie que les fonctions de sécurité nécessitent une conception déterministe, une vérification et une discipline de cycle de vie que les systèmes d'IA asynchrones ne fournissent pas intrinsèquement. exida et les conseils de sécurité fonctionnelle connexes soulignent le même point pratique dans l'industrie : si une fonction est critique pour la sécurité, l'incertitude temporelle et le comportement invérifiable ne sont pas des inconvénients mineurs.

Une correction concise est utile ici : l'IA peut assister un système lié à la sécurité, mais elle ne doit pas être traitée comme la couche de sécurité déterministe primaire. Vous ne pouvez pas câbler un rideau immatériel à un LLM et appeler cela une architecture.

L'architecture « Bulbe Rachidien » est un modèle de contrôle en couches dans lequel l'IA propose et l'API dispose. L'IA effectue la perception ou l'optimisation de haut niveau ; l'API reste l'autorité temps réel rigoureuse qui valide, bride, séquence ou rejette ces requêtes avant que le matériel n'agisse.

L'analogie biologique est mémorable car elle est structurellement assez précise pour être utile. Le cortex interprète et planifie. Le bulbe rachidien gère les fonctions de survie autonomes. En termes d'automatisation, l'IA peut estimer la qualité du produit, détecter des objets ou suggérer un ajustement de débit ; l'API conserve les interverrouillages, les chaînes d'arrêt, les permissifs et l'actionnement borné.

La hiérarchie du contrôle

• Interprète les images, les tendances ou le contexte de processus multivariables
• Génère une classification, un conseil ou un point de consigne demandé
• Fonctionne de manière asynchrone et peut être erronée, retardée ou obsolète

• Vérifie la requête par rapport à des limites strictes
• Vérifie l'état de la machine, les permissifs et les interverrouillages
• Confirme la fraîcheur via une logique de battement de cœur ou de chien de garde
• Applique des limites de taux de variation, des bridages et un comportement de repli

• Reçoit uniquement les commandes approuvées par l'API
• Inclut les variateurs, vannes, contacteurs, actionneurs et alarmes
• Passe à un état sûr ou borné si la validation échoue

1. Couche de perception (IA)
2. Couche de validation (API)
3. Couche d'exécution (Matériel)

Ce n'est pas une position anti-IA. C'est une position pro-limites. Une bonne architecture est principalement un refus discipliné.

Ce que l'API doit toujours conserver

L'API doit conserver une autorité absolue sur les fonctions qui nécessitent une réponse déterministe et un comportement de défaillance borné.

Cela inclut généralement :

• Le traitement de l'arrêt d'urgence
• L'évaluation des interverrouillages de sécurité
• Les permissifs de mouvement
• La logique d'évitement de collision
• Les limites strictes de course ou de vitesse
• Le repli en mode sécurisé en cas de perte de communication
• Le séquençage pour les transitions dangereuses
• L'arbitrage final des commandes vers les actionneurs

Si une IA demande une augmentation de vitesse, l'API peut l'autoriser, la réduire, la retarder ou la rejeter. La réponse finale appartient à la couche déterministe.

Vous programmez des limites de sécurité temps réel rigoureuses en traitant les sorties de l'IA comme des entrées externes non fiables. Cela signifie que chaque valeur issue de l'IA doit passer par une logique défensive explicite avant de pouvoir influencer une machine ou un processus.

C'est ici que la logique Ladder cesse d'être un exercice de syntaxe pour devenir un jugement de mise en service. Un barreau qui « fonctionne » simplement ne suffit pas. Le barreau doit également échouer de manière contrôlée.

Barreaux défensifs essentiels pour le dialogue IA-API

#### 1. Chien de garde pour la supervision du battement de cœur

Un chien de garde (watchdog) vérifie que l'IA ou le système de calcul amont communique toujours dans un intervalle acceptable.

- Si le temporisateur expire, l'API :

• L'IA envoie un bit de battement de cœur ou une valeur incrémentale
• L'API réinitialise un temporisateur TON ou équivalent lorsque le battement de cœur change
• invalide la requête IA,
• force un défaut sûr,
• déclenche une alarme,
• et empêche toute exécution ultérieure jusqu'à ce que les conditions de récupération soient remplies

Un service amont mort ne devrait pas laisser un chemin de sortie actif derrière lui. Ce n'est pas de l'intelligence ; c'est un résidu.

#### 2. Bloc de limite pour le bridage strict

Une instruction de limite contraint les valeurs demandées à une bande de fonctionnement physiquement sûre.

Exemples d'utilisation :

• Brider la vitesse moteur demandée entre la vitesse de refroidissement minimale et le RPM maximal sûr
• Brider la demande d'une vanne à une plage évitant le choc hydraulique
• Brider un point de consigne de température aux limites de conception de l'équipement

Exemple de structure de logique Ladder :

- Instruction : LIM (Test de limite) - Limite basse : 15,0 Hz - Test : `AI_Requested_Speed` - Limite haute : 45,0 Hz - Sortie : `Safe_Speed_Permissive`

L'objectif n'est pas l'élégance. L'objectif est qu'aucun optimisme amont ne puisse commander une survitesse.

#### 3. Limitation du taux de variation

Un limiteur de taux de variation empêche les changements de commande brusques qui sont techniquement valides en magnitude mais dangereux en transition.

Exemples :

• Empêcher une vanne de passer de 10 % à 100 % en une seule mise à jour
• Restreindre les augmentations de vitesse VFD à une rampe définie
• Limiter le mouvement du point de consigne par balayage ou par seconde

Ceci est important car de nombreuses défaillances se produisent lors de la transition, pas au point final. Le chiffre final peut être légal alors que le chemin pour y parvenir est imprudent.

#### 4. Détection d'obsolescence et validité de séquence

Une valeur peut être numériquement plausible et pourtant opérationnellement invalide.

L'API devrait vérifier :

• la fraîcheur de l'horodatage ou le compteur de séquence
• la compatibilité du mode machine
• la phase actuelle de l'opération
• l'état des permissifs avant d'appliquer la requête
• si la requête appartient à la recette active, à l'étape de lot ou à l'état de séquence

Un point de consigne obsolète pendant la mauvaise phase de séquence est juste une forme polie de mauvaise donnée.

Ce que signifie « correct » dans cette architecture

La correction doit être définie opérationnellement, pas cosmétiquement. Dans ce contexte, une intégration IA-API correcte signifie :

• l'API n'accepte que des requêtes fraîches et bornées,
• la machine ne bouge que lorsque les permissifs sont vrais,
• les transitions dangereuses sont bloquées,
• la perte de communication produit un état de repli défini,
• et chaque chemin de rejet est observable dans les tags, les alarmes ou la logique d'événement.

Cette définition est plus utile que « le barreau a compilé ». La compilation est une barre basse. Les dommages matériels la franchissent régulièrement.

Vous validez le dialogue IA-API en simulant délibérément un comportement anormal, puis en prouvant que la logique API le rejette ou le contient. La validation ne consiste pas à montrer que le chemin nominal fonctionne. La validation consiste à montrer que les mauvaises entrées échouent de manière sûre et observable.

C'est là que Simulation-Ready a besoin d'une définition stricte. Un ingénieur Simulation-Ready est celui qui 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 réel. C'est une norme plus élevée que de connaître la syntaxe Ladder. C'est la différence entre dessiner une logique et la mettre en service.

Ce qui devrait être testé avant l'exposition au matériel

Au minimum, les ingénieurs devraient tester :

• la perte de battement de cœur du service IA
• les mises à jour retardées et les valeurs obsolètes
• les points de consigne hors plage
• les valeurs implausibles mais dans la plage
• les requêtes oscillantes rapides
• l'inadéquation de mode entre la requête IA et l'état de la machine
• le mauvais timing de séquence de démarrage
• le comportement de repli après la restauration des communications

Si ces cas n'ont pas été exercés, l'architecture n'est pas validée. Elle est simplement pleine d'espoir.

OLLA Lab est utile ici comme environnement de validation borné pour répéter le côté API du risque d'intégration IA. Ce n'est pas un certificateur de sécurité IA, et ce n'est pas un substitut à l'acceptation formelle sur site, à l'examen des risques ou à l'évaluation de la sécurité fonctionnelle. C'est un endroit pour pratiquer les tâches exactes de durcissement du contrôle qui sont trop risquées ou trop coûteuses à improviser sur un équipement réel.

L'avantage pratique est simple : les ingénieurs peuvent injecter un mauvais comportement en toute sécurité et de manière répétée.

Ce qu'OLLA Lab permet aux ingénieurs de répéter

En utilisant l'éditeur de logique Ladder basé sur le web, le mode simulation et le panneau des variables, les ingénieurs peuvent :

• construire une logique Ladder qui supervise une valeur demandée externe,
• basculer les entrées et les tags internes en temps réel,
• observer les sorties et les permissifs intermédiaires,
• tester les temporisateurs, compteurs, comparateurs, mathématiques et comportement lié au PID,
• comparer l'état du Ladder par rapport à la réponse de l'équipement simulé,
• et réviser la logique après avoir observé un chemin de défaillance.

Ce flux de travail est important car les échecs d'intégration IA apparaissent souvent comme des problèmes de timing et d'état, pas seulement comme des chiffres erronés. OLLA Lab donne à ces problèmes un endroit où devenir visibles.

Un flux de travail de validation pratique dans OLLA Lab

Une séquence de répétition crédible ressemble à ceci :

• Construire une séquence de barreaux qui reçoit une valeur externe de vitesse, débit ou position demandée
• Ajouter des permissifs, des vérifications de mode et une condition d'exécution finale

• Insérer un chien de garde
• Ajouter un bridage utilisant une logique de limite
• Ajouter un limiteur de taux ou une rampe par étapes
• Définir un comportement de repli en cas de timeout ou de données invalides

• Utiliser le panneau des variables pour forcer des valeurs hors plage
• Mettre en pause ou arrêter le signal de battement de cœur
• Introduire des changements de commande brusques
• Changer l'état du processus en cours de commande

• Confirmer que les sorties restent bornées
• Vérifier que la logique de timeout se déclenche correctement
• Vérifier que les alarmes ou les bits de défaut deviennent visibles
• Comparer le comportement de la machine simulée à la philosophie de contrôle attendue

• Ajuster les valeurs de temporisation, les limites et les conditions de séquence
• Retester les mêmes défauts jusqu'à ce que le chemin de rejet soit déterministe et lisible

1. Créer le chemin de contrôle
2. Ajouter une logique défensive
3. Injecter des cas anormaux
4. Observer la cause et l'effet
5. Réviser et relancer

C'est là qu'OLLA Lab devient opérationnellement utile. Il permet aux ingénieurs de répéter la logique de veto, pas seulement de l'admirer.

Vous devriez produire un corpus compact de preuves d'ingénierie qui démontre le raisonnement de contrôle sous défaut, et non une galerie de captures d'écran de l'éditeur. Les captures d'écran prouvent qu'un écran a existé. Elles ne prouvent pas que la logique a tenu sous la contrainte.

Utilisez cette structure :

Indiquez les critères d'acceptation exacts : plage de fonctionnement permise, intervalle de timeout, conditions de permissif, état de repli et comportement d'alarme attendu.

Documentez la condition anormale introduite : battement de cœur obsolète, requête de survitesse, inadéquation de mode, commande oscillante ou timing de séquence invalide.

Expliquez ce qui a changé dans la logique : ajout d'un bridage, modification de l'intervalle du chien de garde, insertion d'un interverrouillage, ajout d'une limite de taux de variation ou révision du séquençage.

1. Description du système Décrivez la machine ou la cellule de processus, l'objectif de contrôle, l'entrée fournie par l'IA et le rôle de sécurité ou de validation détenu par l'API.
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé Montrez les barreaux, tags et l'état de la machine ou du processus simulé que ces barreaux régissent.
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é sur la philosophie de contrôle, les hypothèses de la machine ou le chemin de validité des données.

Cette structure de preuve est bien plus convaincante qu'un clip de démonstration poli. Le risque de mise en service répond à la preuve, pas à l'esthétique.

L'IA appartient en amont du contrôle déterministe, pas à sa place. Son rôle utile est de générer des valeurs consultatives ou candidates à partir de données complexes que la logique conventionnelle gère mal.

Les exemples incluent :

• la classification basée sur la vision
• la détection d'anomalies
• l'estimation de la qualité
• le score de maintenance prédictive
• les recommandations d'optimisation multivariables
• les suggestions de points de consigne adaptatifs

L'API décide ensuite si ces sorties sont admissibles dans le contexte actuel de la machine.

Une règle architecturale claire

Une règle pratique est celle-ci : l'IA peut recommander ; l'API doit autoriser.

Cette règle préserve les forces des deux couches :

• L'IA gère l'ambiguïté, la reconnaissance de formes et l'optimisation
• La logique API gère le timing, les permissifs, les limites et l'exécution déterministe

Le résultat n'est pas glamour, ce qui est souvent un bon signe dans les contrôles. Une bonne architecture d'usine semble généralement un peu ennuyeuse jusqu'au moment où elle empêche une erreur coûteuse.

L'erreur la plus courante est de permettre aux sorties de l'IA de contourner la logique de validation explicite. Une fois que cela se produit, l'architecture a déjà perdu sa discipline de frontière.

Les autres erreurs récurrentes incluent :

• traiter un horodatage réseau comme équivalent à une fraîcheur déterministe
• supposer que les valeurs dans la plage sont automatiquement sûres
• oublier la validation de l'état de séquence
• omettre le comportement de repli en cas de perte de battement de cœur
• permettre aux sorties consultatives de devenir des commandes directes au fil du temps
• tester uniquement le comportement nominal et non les transitions anormales
• confondre le succès du simulateur avec la préparation sur site

Ce dernier point mérite d'être souligné. La simulation est un environnement de validation, pas une déclaration de compétence sur le terrain. C'est là que les ingénieurs apprennent à observer, diagnostiquer et durcir la logique avant l'exposition réelle. Utile, nécessaire, et pourtant pas la même chose que de se tenir à côté d'une ligne en marche à 2h00 du matin avec la maintenance qui attend.

La manière sûre d'intégrer l'IA dans l'automatisation industrielle est de séparer la perception de l'autorité. L'IA peut classifier, estimer et recommander. L'API doit rester le cœur temps réel rigoureux qui valide, bride, séquence et oppose son veto.

C'est l'architecture « Bulbe Rachidien » en une ligne : l'IA pense, l'API maintient l'organisme en vie.

Pour les ingénieurs, la tâche pratique n'est pas de célébrer les sorties de l'IA mais de durcir le chemin de contrôle autour d'elles. Les chiens de garde, les limites, les permissifs, les vérifications de taux de variation, la détection de données obsolètes et les replis en mode sécurisé ne sont pas des détails optionnels. Ils sont l'architecture.

Et si cela semble moins futuriste que les présentations marketing, tant mieux. Les machines préfèrent généralement les adultes.

- IEC 61131-3: Automates programmables — Partie 3 - Famille de normes de sécurité fonctionnelle IEC 61508 - Ressources de sécurité fonctionnelle et de validation exida - Recommandation de signalisation d'état NAMUR NE 107 - Jumeau numérique dans l'industrie : état de l'art (DOI)