Comment convertir les poids d'un réseau de neurones en texte structuré (ST) pour la détection d'anomalies sur automate

Convertir les poids d'un réseau de neurones en texte structuré (ST) pour automate consiste à exporter les poids et biais d'un modèle entraîné, à les réécrire sous forme de tableaux IEC 61131-3 et à exécuter les calculs de propagation (feedforward) de manière déterministe au sein du cycle de l'automate. L'objectif technique n'est pas de faire de « l'IA dans les contrôles » comme simple slogan, mais d'obtenir une inférence bornée et testable, sans dépendance vis-à-vis d'un réseau périphérique.

Les réseaux de neurones ne deviennent utiles industriellement que lorsqu'ils sont capables de fonctionner de manière prévisible pour un système de contrôle dont la survie dépend du temps de cycle, des limites du chien de garde (watchdog) et du comportement en cas de défaillance.

Pour la détection d'anomalies à haute vitesse, l'envoi de données de processus vers un PC périphérique externe peut introduire de la latence, de la gigue et un point de défaillance supplémentaire entre le signal et l'action. Cette architecture peut être acceptable pour de l'analytique consultative, mais elle est moins adaptée lorsque la sortie du modèle est liée à une autorisation, un arrêt ou un verrouillage. L'OT (technologie opérationnelle) tolère mal les architectures élégantes qui échouent de manière inélégante.

Une alternative bornée consiste à exporter un modèle entraîné léger — généralement un perceptron multicouche (MLP) peu profond — en texte structuré IEC 61131-3 et à exécuter l'inférence directement dans le contrôleur.

Métrique Ampergon Vallis : Dans une simulation interne OLLA Lab, un MLP à 3 couches utilisant une matrice de couche cachée 16x16 en virgule flottante a ajouté 1,2 ms au temps de cycle simulé lors de tests d'inférence répétés. Méthodologie : n=25 exécutions de simulation de la même tâche feedforward, comparateur de référence = logique identique sans exécution matricielle, fenêtre temporelle = une session de validation de mars 2026. Cela confirme que de petits blocs d'inférence neuronale peuvent être testés pour leur faisabilité déterministe dans un environnement de type automate. Cela ne prouve pas leur adéquation pour chaque contrôleur, chaque budget de temps de cycle ou chaque fonction de sécurité.

Exécuter l'inférence à l'intérieur de l'automate supprime le transport réseau du chemin d'exécution critique. C'est la raison technique centrale.

Un PC périphérique peut être adéquat pour une surveillance non critique, des analyses d'historisation ou des tableaux de bord de maintenance. Il en va tout autrement lorsque la sortie du modèle doit participer à une décision de contrôle déterministe. Si la liaison réseau tombe, le chemin d'inférence tombe avec elle. Le problème n'est pas que l'informatique périphérique est mauvaise ; le problème est que la logique de contrôle est moins tolérante que l'architecture analytique.

La distinction est simple :

• L'inférence périphérique est généralement asynchrone, dépendante du réseau et planifiée en dehors du cycle de l'automate.
• L'inférence résidente dans l'automate n'est déterministe que si le temps d'exécution, l'utilisation de la mémoire et le comportement en cas de défaut sont bornés à l'intérieur de la tâche du contrôleur.

Pour la détection d'anomalies liée à une autorisation de moteur, une inhibition de vanne ou un maintien de séquence, la localité déterministe est primordiale. Un résultat qui arrive en retard est souvent fonctionnellement équivalent à une absence de résultat.

Quel contexte normatif est important ici ?

Les normes de sécurité fonctionnelle ne cautionnent pas les hypothèses de timing approximatives. La norme IEC 61508 se préoccupe du comportement prévisible, de l'exécution validée et de la réponse connue aux défaillances, et non de savoir si un modèle était impressionnant dans un notebook.

Cela nécessite une limite prudente :

• Intégrer un réseau de neurones en texte structuré ne le transforme pas par défaut en fonction de sécurité.
• Il peut supporter une logique de surveillance de processus déterministe si son exécution est validée, bornée et isolée de manière appropriée.
• Si la sortie influence une action liée à la sécurité, la charge de la preuve augmente considérablement. « Ça a fonctionné en simulation » ne constitue pas un dossier de sécurité.

Une idée fausse répandue est que mettre de l'IA dans l'automate le rend automatiquement plus industriel. Cela le rapproche simplement du cycle de balayage. La partie difficile reste la preuve.

Seuls les petits modèles feedforward sont pratiques dans la plupart des contextes d'automates. C'est la limite utile.

Le candidat le plus courant est un perceptron multicouche (MLP) peu profond, entraîné hors ligne dans MATLAB, Python ou un environnement similaire, puis exporté sous forme de poids et biais statiques. Cela fonctionne car l'inférence pour un MLP fixe n'est que de l'arithmétique :

• multiplication matricielle
• addition de biais
• évaluation de fonction d'activation
• logique de seuillage ou de classification

Cette arithmétique est fastidieuse mais déterministe.

Les modèles les plus susceptibles de convenir sont :

• Les MLP à couche cachée unique ou peu profonds
• Les petits vecteurs d'entrée
• Les nombres de nœuds cachés limités
• Les fonctions d'activation simples, telles que ReLU ou des approximations linéaires bornées

Les modèles les moins susceptibles de s'adapter proprement sont :

• les réseaux récurrents
• les grands modèles convolutionnels
• les architectures de type transformer
• tout ce qui nécessite une gestion dynamique de la mémoire, des bibliothèques non prises en charge ou un débit important en virgule flottante

Ce n'est pas une déclaration sur la capacité de l'IA en général, mais sur l'économie des contrôleurs et la discipline du temps de cycle.

Le processus de conversion est simple dans son concept mais impitoyable dans les détails. La plupart des échecs ne sont pas mathématiques, mais liés à l'indexation, au dimensionnement, au type de données ou au temps de tâche.

### Étape 1 : Entraîner un modèle léger hors ligne

Entraînez le modèle dans MATLAB, Python ou un autre environnement ML en utilisant des données de processus historiques ou des données d'événements étiquetées.

Les bons candidats pour un déploiement sur automate ont généralement :

• des entrées numériques normalisées
• un nombre de caractéristiques limité
• des enveloppes de fonctionnement stables
• des étiquettes d'anomalie ou une logique de seuil claires
• un chemin d'inférence explicable et borné

Si le modèle a besoin d'un GPU de bureau pour fonctionner confortablement, il n'a généralement pas sa place dans une tâche de contrôleur standard.

### Étape 2 : Exporter les poids et les biais

Extrayez les paramètres entraînés du modèle :

• matrice de poids entrée-vers-cachée
• vecteur de biais de la couche cachée
• matrice de poids cachée-vers-sortie
• vecteur de biais de la couche de sortie

Les formats d'exportation typiques incluent :

• CSV
• JSON
• Tableaux MATLAB
• Tableaux NumPy Python écrits en texte

À ce stade, préservez :

• les dimensions des tableaux
• l'ordre des lignes/colonnes
• la précision numérique
• les constantes de normalisation des entrées
• les valeurs de seuil de sortie

Un nombre surprenant de problèmes de déploiement ne sont en réalité que des matrices transposées.

### Étape 3 : Convertir les paramètres en tableaux conformes à l'IEC 61131-3

Réécrivez les paramètres du modèle sous forme de tableaux en texte structuré en utilisant les types de données pris en charge par le contrôleur, généralement `REAL` ou `LREAL` selon la capacité de la plateforme et le budget de temps de cycle.

Exemple de mappage de forme :

• `W1[HiddenNodes, InputNodes]`
• `B1[HiddenNodes]`
• `W2[OutputNodes, HiddenNodes]`
• `B2[OutputNodes]`

Définissez également :

• les tableaux de vecteurs d'entrée
• les tableaux de sommes de nœuds intermédiaires
• les tableaux de sortie d'activation
• les tableaux de sortie d'inférence finale

Le choix du type de données est important. `LREAL` peut améliorer la fidélité numérique, mais peut aussi augmenter le coût d'exécution selon l'architecture du contrôleur.

### Étape 4 : Recréer la passe feedforward en texte structuré

Implémentez le modèle sous forme d'arithmétique explicite :

1. initialiser chaque somme de nœud avec son biais
2. accumuler les produits des entrées pondérées
3. appliquer la fonction d'activation
4. passer les sorties activées à la couche suivante
5. comparer la sortie finale à un seuil ou une règle de classification

C'est ici que le modèle devient un bloc arithmétique déterministe.

### Étape 5 : Recréer la logique de prétraitement et de sortie

Un modèle entraîné sur des entrées normalisées doit recevoir des entrées normalisées dans l'automate. Sinon, l'inférence est mathématiquement correcte mais opérationnellement fausse.

Vous devez implémenter :

• la mise à l'échelle
• la correction d'offset
• le bridage (clamping) si nécessaire
• la gestion des signaux manquants
• le seuillage de sortie
• le comportement en cas de défaut si le bloc d'inférence reçoit des données invalides

Un modèle sans son chemin de prétraitement n'est pas déployé, il est simplement copié.

La multiplication matricielle en texte structuré est généralement implémentée avec des boucles `FOR` imbriquées et une accumulation explicite dans des tableaux de sommes de nœuds. L'objectif est la correction, le déterminisme et la visibilité du temps de cycle.

Exemple : somme pondérée de la couche cachée

Langage : Texte structuré

// Somme pondérée de la couche cachée FOR i := 0 TO HiddenNodes - 1 DO NodeSum[i] := Bias1[i]; FOR j := 0 TO InputNodes - 1 DO NodeSum[i] := NodeSum[i] + (InputArray[j] * Weight1[i, j]); END_FOR; END_FOR;

Ce code effectue le produit scalaire entre le vecteur d'entrée et chaque ligne de poids des neurones de la couche cachée, puis ajoute le biais correspondant.

• confirmez si votre automate utilise des conventions de tableau basées sur zéro ou sur un
• gardez les dimensions des tableaux explicites
• initialisez les sommes avant l'accumulation
• évitez la conversion de type implicite
• testez le temps d'exécution dans le pire des cas, pas seulement le temps nominal

Une boucle qui fonctionne une fois est une démonstration. Une boucle qui fonctionne au rythme de la tâche avec des entrées bruitées est de l'ingénierie.

Comment calculer la couche de sortie ?

La couche de sortie suit le même modèle appliqué aux activations de la couche cachée.

Langage : Texte structuré

// Somme pondérée de la couche de sortie FOR i := 0 TO OutputNodes - 1 DO OutputSum[i] := Bias2[i]; FOR j := 0 TO HiddenNodes - 1 DO OutputSum[i] := OutputSum[i] + (HiddenOutput[j] * Weight2[i, j]); END_FOR; END_FOR;

Pour un score d'anomalie unique, `OutputNodes` peut être `1`, avec le score final comparé à un seuil.

ReLU est l'une des fonctions d'activation les plus faciles à traduire car elle est linéaire par morceaux. En texte structuré, elle devient une simple conditionnelle.

Langage : Texte structuré

// Activation ReLU FOR i := 0 TO HiddenNodes - 1 DO IF NodeSum[i] < 0.0 THEN HiddenOutput[i] := 0.0; ELSE HiddenOutput[i] := NodeSum[i]; END_IF; END_FOR;

Cela préserve la règle de base de ReLU :

• si entrée < 0, sortie = 0
• sinon sortie = entrée

Cette simplicité est utile dans les automates car elle évite des fonctions non linéaires plus coûteuses.

Quelles autres approches d'activation sont pratiques ?

Les options pratiques dépendent des capacités du contrôleur, mais les approches courantes incluent :

- ReLU : la plus simple pour une implémentation directe - Activation linéaire : utile pour les sorties de type régression - Approximation par morceaux : parfois utilisée lorsqu'une fonction non linéaire lisse est nécessaire mais que le support mathématique natif est limité

Les options moins pratiques dans de nombreux automates incluent :

• les calculs exacts de sigmoïde ou tanh utilisant des exponentielles coûteuses
• les schémas d'activation dynamiques nécessitant des bibliothèques non prises en charge
• les architectures qui dépendent du comportement du graphe à l'exécution

Dans le travail de contrôle, un comportement borné l'emporte souvent sur un comportement élégant mais invérifiable.

La détection d'anomalies ne devient opérationnellement significative que lorsque la sortie est liée à une action de contrôle définie. « Le modèle a produit 0,83 » n'est pas encore un résultat d'ingénierie.

Une implémentation utilisable nécessite :

• un score d'anomalie défini
• une règle de seuil ou de classification
• une règle de débruitage ou de persistance si du bruit est attendu
• une réponse de contrôle claire

Par exemple :

- mettre `AnomalyDetected := TRUE` - mettre `MotorRunPermissive := FALSE`

• si score d'anomalie > seuil pendant 500 ms
• verrouiller une alarme
• exiger une réinitialisation par l'opérateur ou le superviseur selon la philosophie

Cette logique doit être documentée en termes de contrôle, et non en termes de ML.

Définition opérationnelle de la détection d'anomalies

Dans cet article, la détection d'anomalies signifie :

> lire un ensemble borné d'entrées de processus, exécuter un bloc d'inférence feedforward déterministe à l'intérieur de la tâche de l'automate, comparer le score résultant à un seuil défini et modifier une variable d'état de contrôle telle qu'une autorisation, une alarme ou un maintien de séquence lorsque la condition de seuil est atteinte.

Cette définition est intentionnellement étroite. Elle est observable, testable et adaptée à la validation.

Les principaux risques sont le dépassement du temps de cycle, l'inadéquation numérique et la fausse confiance.

1. Risque de temps de cycle et de chien de garde (watchdog)

L'arithmétique matricielle consomme du temps de tâche. Si le bloc d'inférence est trop grand ou mal structuré, il peut déclencher des défauts de chien de garde ou dégrader la réactivité du contrôle.

Les facteurs de risque incluent :

• les grandes matrices
• l'exécution fréquente dans des tâches rapides
• l'utilisation intensive de la virgule flottante
• la normalisation et la mise à l'échelle répétées dans le même cycle
• la recomputation inutile

Les mesures d'atténuation incluent :

• la réduction de la taille du modèle
• le déplacement de l'inférence vers une tâche périodique plus lente si approprié
• la pré-computation des constantes
• l'utilisation de tests d'exécution bornés
• la validation de l'impact sur le temps de cycle dans le pire des cas avant le déploiement

2. Inadéquation du type de données et de la précision

Un modèle entraîné en `float64` et déployé en `REAL` peut se comporter différemment aux seuils. Cette différence peut être numériquement faible mais opérationnellement grande.

Vérifiez :

• la plage numérique
• la cohérence de la mise à l'échelle
• la sensibilité au seuil
• le comportement en virgule flottante spécifique au contrôleur

3. Erreurs d'indexation et d'orientation matricielle

Une matrice transposée, un index décalé ou un mauvais mappage de biais peuvent produire des sorties qui semblent plausibles tout en étant totalement fausses.

C'est pourquoi la validation déterministe est importante. Les erreurs arithmétiques sont souvent assez polies pour compiler.

4. Comportement face aux entrées invalides

Un capteur manquant, une valeur obsolète, un transmetteur saturé ou une mauvaise mise à l'échelle analogique peuvent corrompre l'inférence.

Définissez :

• ce qui se passe en cas de mauvaise qualité
• si le bloc s'inhibe lui-même
• si la sortie échoue en sécurité, échoue en neutre ou déclenche seulement une alarme
• si le résultat est ignoré pendant les états de maintenance ou de démarrage

5. Utilisation abusive dans les contextes de sécurité

Un bloc d'inférence neuronale ne doit pas être décrit comme certifié pour la sécurité simplement parce qu'il se trouve dans un automate. S'il influence une fonction liée à la sécurité, les obligations de conception, de vérification et de cycle de vie deviennent nettement plus exigeantes.

OLLA Lab est utile ici comme environnement de validation borné pour les tâches de mise en service à haut risque. Ce n'est pas un raccourci pour éviter les tests sur contrôleur, et ce n'est pas un substitut à la réception sur site. C'est là que vous répétez les modes de défaillance avant que le matériel et le temps de processus ne deviennent coûteux.

Dans ce cas d'utilisation, OLLA Lab peut aider les ingénieurs en fournissant :

• un environnement logique basé sur navigateur pour construire et examiner la logique de contrôle
• un mode simulation pour exécuter, arrêter et observer le comportement sans matériel physique
• une visibilité des variables et des E/S pour tracer les valeurs intermédiaires
• des tests basés sur des scénarios réalistes contre un comportement d'équipement simulé
• des flux de travail de validation de type jumeau numérique où la logique peut être comparée à la réponse attendue de la machine

Pour le flux de travail de cet article, la valeur pratique est claire :

• écrire la logique d'inférence
• lier les entrées aux variables de processus simulées
• injecter des perturbations ou des conditions anormales
• observer les changements d'état de sortie
• vérifier si la réponse de contrôle correspond à la philosophie prévue

C'est ce que Simulation-Ready devrait signifier en termes opérationnels : un ingénieur capable de prouver, d'observer, de diagnostiquer et de durcir la logique de contrôle contre un comportement de processus réaliste avant qu'il n'atteigne un processus réel.

Que signifie la validation par jumeau numérique ici ?

Dans ce contexte borné, la validation par jumeau numérique signifie tester la logique de contrôle contre un modèle d'équipement simulé réaliste afin que l'ingénieur puisse comparer :

• l'état du ladder ou du texte structuré
• l'état des E/S
• la réponse du processus
• la gestion des conditions anormales
• l'action de contrôle résultante

Cela ne signifie pas que le modèle simulé est automatiquement une réplique parfaite du comportement sur site. Cela signifie que la logique peut être répétée contre une dynamique de machine ou de processus représentative avant le déploiement sur le terrain.

Un flux de travail pratique consiste à traiter le réseau de neurones comme un bloc à l'intérieur d'un récit de contrôle plus large plutôt que comme un objet de nouveauté.

Une séquence de validation représentative serait :

1. Construire le bloc d'inférence Implémentez les poids, biais, normalisation et logique de seuil exportés en texte structuré ou dans un flux de travail de logique de contrôle pris en charge équivalent.
2. Lier les entrées aux signaux de processus simulés Mappez les entrées du modèle à des variables telles que les vibrations, le courant moteur, l'élévation de température, la fluctuation de pression ou l'instabilité de débit.
3. Définir l'état normal attendu Confirmez que la sortie du modèle reste en dessous du seuil pendant un fonctionnement sain.
4. Injecter une condition anormale Introduisez une perturbation telle qu'une vibration oscillatoire, un pic de capteur, une dérive ou un comportement de charge instable.
5. Observer la sortie de l'inférence et la réponse de contrôle Vérifiez que le score d'anomalie dépasse le seuil uniquement lorsque prévu, et que l'autorisation, l'alarme ou l'état de séquence changent correctement.
6. Mesurer la charge logique Vérifiez si l'arithmétique ajoutée crée un coût d'exécution inacceptable ou un comportement instable.

Cette séquence est importante car la détection d'anomalies n'est utile que lorsqu'elle est liée à une conséquence de processus. Un score sans chemin d'action n'est qu'un nombre.

Une galerie de captures d'écran est une preuve faible. Un dossier de validation compact est plus utile pour les examinateurs, les instructeurs et les employeurs car il montre le raisonnement, pas seulement la familiarité avec l'interface.

Utilisez cette structure :

1. Description du système Décrivez l'équipement, l'objectif du processus, les entrées pertinentes et l'endroit où le bloc de détection d'anomalies se situe dans la philosophie de contrôle.
2. Définition opérationnelle du comportement correct Indiquez exactement ce que la logique doit faire dans des conditions normales et anormales, y compris les seuils, le timing et les états de sortie attendus.
3. État de la logique et de l'équipement simulé Montrez la logique implémentée et le comportement correspondant de la machine ou du processus simulé pendant le test.
4. Le cas de défaut injecté Documentez la perturbation introduite, telle que le bruit du capteur, la dérive, l'oscillation ou une charge anormale.
5. La révision effectuée Enregistrez ce qui a changé après le premier test — ajustement du seuil, logique de débruitage, correction de mise à l'échelle, placement de la tâche ou optimisation matricielle.
6. Leçons apprises Résumez ce que le test a révélé sur la déployabilité, les faux positifs, la charge de cycle ou la philosophie de contrôle.

Ce corpus de preuves est beaucoup plus proche du jugement de mise en service qu'une capture d'écran polie.

Le déploiement doit être conditionné par une vérification bornée, et non par l'enthousiasme.

Utilisez une liste de contrôle pré-déploiement :

• La taille du modèle est appropriée pour le contrôleur et le taux de tâche
• La mise à l'échelle des entrées correspond aux conditions d'entraînement
• Les poids et biais sont mappés correctement
• La logique d'activation est implémentée exactement comme prévu
• Le comportement du seuil est documenté
• La gestion des mauvaises entrées est définie
• Le temps d'exécution dans le pire des cas est testé
• La réponse de contrôle à l'anomalie est vérifiée
• Le comportement de repli est défini si le bloc d'inférence est invalide
• Les tests de mise en service spécifiques au site sont planifiés

Si le modèle ne peut pas survivre à cette liste de contrôle, il n'est pas prêt pour l'automate. Il peut encore être utile ailleurs.

Cette approche résout un problème OT spécifique : comment exécuter un petit modèle entraîné de manière déterministe à l'intérieur d'un environnement de contrôle de type automate sans dépendre d'une infrastructure d'inférence externe.

Elle peut aider avec :

• le score d'anomalie à faible latence
• l'inférence locale bornée
• la réduction de la dépendance au réseau dans les décisions de contrôle
• la validation de l'arithmétique du modèle contre un comportement de processus réaliste

Elle ne résout pas :

• la certification de sécurité par implication
• la gouvernance du modèle par elle-même
• la mise en service spécifique à l'usine par la seule simulation
• l'adéquation des architectures neuronales grandes ou complexes pour le matériel d'automate standard

Cette limite mérite d'être maintenue propre.

La conversion des poids d'un réseau de neurones en texte structuré pour automate est techniquement viable lorsque le modèle est petit, que le chemin arithmétique est explicite et que la charge d'exécution est validée par rapport aux contraintes du contrôleur. Le but n'est pas de faire imiter les environnements Python par les automates. Le but est de placer une fonction d'inférence bornée là où la réponse déterministe compte le plus.

La séquence d'ingénierie est claire :

• entraîner hors ligne
• exporter les poids et les biais
• les réécrire sous forme de tableaux IEC 61131-3
• implémenter les mathématiques feedforward et la logique d'activation
• valider l'impact sur le cycle et le comportement en cas de défaut
• tester la conséquence de contrôle contre des conditions de processus simulées réalistes

C'est là qu'OLLA Lab devient opérationnellement utile. Il fournit un endroit pour répéter la logique lourde en matrices, observer le comportement des E/S et des variables, injecter des conditions anormales et durcir la conception avant la mise en service réelle. C'est une utilisation crédible de la simulation : ne pas remplacer la preuve sur le terrain, mais rendre la preuve sur le terrain moins imprudente.

- IEC 61131-3: Automates programmables — Partie 3 : Langages de programmation - IEC 61508 Aperçu de la sécurité fonctionnelle - NIST AI Risk Management Framework (AI RMF 1.0) - Revue du jumeau numérique (IFAC-PapersOnLine) - IA industrielle dans l'Industrie 4.0 (Manufacturing Letters)