Comment implémenter la multiplication matricielle pour le contrôle prédictif (MPC) par automate en Ladder

Pour implémenter le contrôle prédictif (MPC) dans un automate (PLC), les ingénieurs doivent effectuer des multiplications matricielles en utilisant des calculs basés sur des tableaux. Le langage Ladder standard ne possédant pas d'opérateur matriciel natif, l'approche habituelle consiste à mapper les termes de l'espace d'état dans des tableaux, à dérouler les opérations `MUL` et `ADD` nécessaires, et à vérifier l'impact sur le temps de cycle avant le déploiement sur le matériel.

La multiplication matricielle dans un automate n'est pas principalement un problème mathématique. C'est un problème de déterminisme déguisé en mathématiques. Le MPC dépend d'équations d'état telles que \(x_{k+1}=Ax_k+Bu_k\), mais le schéma à contacts (Ladder) standard ne fournit pas d'instruction native de multiplication matricielle ; l'ingénieur doit donc traduire cette algèbre en opérations sur tableaux explicites que le contrôleur peut exécuter de manière prévisible.

Métrique Ampergon Vallis : Lors de tests de contrainte internes du cycle de balayage dans OLLA Lab, le déroulement d'une multiplication matrice-vecteur 3x3 en instructions `MUL` et `ADD` séquentielles explicites s'est exécuté 4,2 ms plus rapidement par cycle qu'une référence en texte structuré (Structured Text) avec boucles imbriquées dans la même enveloppe de tâche simulée. Méthodologie : n=18 exécutions répétées ; définition de la tâche = évaluation répétée de matrice-vecteur 3x3 REAL avec mises à jour d'état analogiques ; comparateur de référence = implémentation en texte structuré avec boucles `FOR` imbriquées ; fenêtre temporelle = tests de banc de mars 2026. Cela soutient une affirmation limitée sur la surcharge d'implémentation dans cette configuration de test. Cela ne prouve pas que le Ladder déroulé est toujours plus rapide sur toutes les familles d'automates, révisions de firmware ou compilateurs.

Cette distinction est importante car les chiens de garde (watchdogs) ne sont pas philosophiques. Ils provoquent des défauts sur les processeurs réels.

Le calcul matriciel est le cœur computationnel du MPC. Le contrôleur prédit le comportement futur du processus à partir d'un modèle, évalue les actions de contrôle et met à jour les sorties en fonction de la réponse attendue de multiples variables en interaction.

La forme standard de l'espace d'état à temps discret est :

\[ x(k+1)=Ax(k)+Bu(k) \]

Où :

• \(x(k)\) = vecteur d'état actuel
• \(x(k+1)\) = prochain vecteur d'état prédit
• \(A\) = matrice système décrivant la dynamique interne du processus
• \(B\) = matrice d'entrée décrivant comment les variables manipulées affectent les états
• \(u(k)\) = vecteur d'entrée de contrôle

En termes d'automate, ces objets deviennent des tags et des tableaux :

• `Matrix_A` stocke les coefficients de dynamique du processus
• `Matrix_B` stocke les coefficients d'influence des entrées
• `Vector_x` stocke les états actuels mesurés ou estimés
• `Vector_u` stocke les entrées manipulées actuelles
• `Vector_x_Next` stocke le prochain état prédit

La distinction importante est SISO versus MIMO. Une boucle PID gère généralement une variable mesurée par rapport à une variable manipulée. Le MPC est conçu pour un comportement multi-entrées, multi-sorties (MIMO), où la modification d'un actionneur peut influencer plusieurs variables de processus à la fois. Les systèmes de vapeur, les réseaux de réservoirs, les skids thermiques et les interactions pression-débit sont rarement assez polis pour rester découplés.

Les équations d'état se mappent à la logique Ladder en convertissant les matrices et les vecteurs en tableaux d'automate, puis en exécutant chaque produit scalaire explicitement. Le Ladder peut représenter les mathématiques, mais il ne les abstrait pas pour vous.

Pour un exemple compact 2x2, la structure des tags peut être définie comme suit :

Structure du dictionnaire de tags pour un système 2x2

- `Matrix_A` : tableau `REAL` 2D `[0..1, 0..1]` - `Vector_x` : tableau `REAL` 1D `[0..1]` - `Vector_x_Next` : tableau `REAL` 1D `[0..1]` - `Temp_Mul_00` : `REAL` - `Temp_Mul_01` : `REAL` - `Temp_Mul_10` : `REAL` - `Temp_Mul_11` : `REAL`

• Stocke les coefficients de dynamique du système
• Stocke les états actuels, tels que le niveau du réservoir et la température
• Stocke les prochaines valeurs d'état prédites
• Stockage temporaire pour `Matrix_A[0,0] * Vector_x[0]`
• Stockage temporaire pour `Matrix_A[0,1] * Vector_x[1]`
• Stockage temporaire pour `Matrix_A[1,0] * Vector_x[0]`
• Stockage temporaire pour `Matrix_A[1,1] * Vector_x[1]`

La règle opérationnelle est simple : chaque ligne de la matrice devient un calcul de produit scalaire, et chaque produit scalaire devient une séquence de multiplications et d'additions explicites. Élégant sur papier ; répétitif en Ladder. Le processeur, cependant, se soucie plus de la prévisibilité que de l'élégance.

Dans OLLA Lab, cela devient inspectable plutôt que théorique. L'éditeur Ladder peut être couplé au panneau des variables afin qu'un ingénieur puisse observer chaque index de tableau, registre temporaire et valeur d'état résultante en temps réel pendant la simulation. C'est utile opérationnellement car cela vous permet de vérifier non seulement que le barreau est syntaxiquement valide, mais que les liaisons de tableaux et les valeurs intermédiaires sont numériquement cohérentes avant toute implication d'une carte de sortie réelle.

Le langage Ladder peine avec la multiplication matricielle car le LD standard est orienté instruction, et non orienté algèbre. Il est conçu autour de contacts, bobines, blocs fonctionnels et exécution déterministe des barreaux, et non autour de l'algèbre linéaire haute densité.

Les limitations principales sont généralement celles-ci :

• Pas d'opérateur matriciel natif
• Les environnements Ladder standard ne fournissent généralement pas d'instruction unique pour la multiplication matrice-vecteur ou matrice-matrice.
• Ergonomie limitée des boucles
• L'itération est généralement plus facile en texte structuré qu'en schéma à contacts.
• Forte dépendance aux tags temporaires
• Même les petites opérations matricielles nécessitent un stockage intermédiaire pour chaque produit partiel.
• Sensibilité au temps de cycle
• L'arithmétique à virgule flottante, l'indexation des tableaux et les calculs répétés consomment un temps d'exécution mesurable.

Cela ne signifie pas que le Ladder ne peut pas faire le travail. Cela signifie que l'ingénieur doit choisir entre deux styles d'implémentation :

### Option 1 : Utiliser le texte structuré pour les boucles

C'est souvent l'expression la plus compacte des mathématiques. Une boucle `FOR` imbriquée peut calculer un produit matrice-vecteur proprement, surtout lorsque les dimensions peuvent changer.

Avantages

• Code plus court
• Plus facile à mettre à l'échelle pour des matrices plus grandes
• Plus naturel pour les mathématiques itératives

Compromis

• La surcharge d'exécution peut augmenter selon la plateforme et le comportement du compilateur
• La visibilité du débogage peut être moins évidente pour les équipes qui travaillent principalement en Ladder
• Certaines équipes de maintenance préfèrent une logique explicite barreau par barreau pour le dépannage

### Option 2 : Dérouler le calcul matriciel en schéma à contacts (Ladder)

Cela signifie écrire chaque multiplication et addition explicitement.

Avantages

• Exécution déterministe et visuellement traçable
• Dépannage au niveau du barreau plus facile
• Souvent mieux aligné avec les attentes de maintenance sur les systèmes centrés sur le Ladder

Compromis

• Implémentation verbeuse
• Faible évolutivité à mesure que la taille de la matrice augmente
• Risque élevé d'erreurs de copier-coller si la discipline de nommage est faible

C'est le contraste classique : code compact versus exécution transparente. Sur un processus en direct, la transparence vieillit généralement mieux.

Les calculs en virgule flottante basés sur des tableaux peuvent augmenter sensiblement le temps de cycle de l'automate. Si le temps d'exécution total dépasse le seuil du chien de garde configuré pour ce contrôleur, le processeur peut se mettre en défaut et arrêter l'exécution.

C'est le risque matériel réel. Pas « le code semble lourd ». Un défaut.

La charge sur le temps de cycle provient généralement d'une combinaison de facteurs :

• Arithmétique REAL
• Les opérations en virgule flottante sont plus coûteuses que les opérations sur entiers sur de nombreuses plateformes d'automates.
• Indexation des tableaux
• L'accès indexé ajoute une surcharge d'adressage par rapport aux tags scalaires fixes.
• Boucles imbriquées
• L'itération répétée multiplie rapidement le coût d'exécution.
• Logique analogique supplémentaire
• La mise à l'échelle, le filtrage, le bridage et les vérifications d'alarme entourent souvent le calcul matriciel plutôt que de le remplacer.
• Exécution à chaque cycle
• Exécuter le calcul complet à chaque cycle peut être inutile et coûteux.

Les paramètres du chien de garde varient selon la famille de contrôleurs et la conception de l'application. Une plage large de « 10–50 ms typiquement » est courante dans la pratique, mais le chiffre pertinent est toujours le seuil configuré sur le système cible réel. Les normes ne sauvent pas un contrôleur d'une arithmétique qu'il ne peut pas terminer à temps.

Stratégies d'atténuation du temps de cycle

Les principales stratégies d'atténuation sont architecturales, pas cosmétiques.

#### 1. Dérouler les calculs critiques

Écrivez des instructions `MUL` et `ADD` explicites pour chaque terme dans les petites matrices.

• Idéal pour les systèmes à petites dimensions fixes
• Améliore la traçabilité
• Évite la surcharge des boucles dans certains environnements

#### 2. Découper le calcul dans le temps (Time-slicing)

Répartissez le calcul matriciel sur plusieurs cycles en utilisant un index d'étape ou une machine à états.

• Réduit la charge de pointe du cycle
• Utile pour les calculs plus importants
• Introduit une latence qui doit être prise en compte dans la performance du contrôle

#### 3. Optimiser les types de données

Utilisez l'arithmétique entière mise à l'échelle telle que `DINT` lorsque la résolution et la plage du processus le permettent.

• Peut réduire le coût d'exécution
• Nécessite une mise à l'échelle disciplinée et une gestion des dépassements
• Pas toujours acceptable pour les modèles de processus à haute résolution

#### 4. Réduire la fréquence d'exécution

Exécutez le calcul prédictif sur une tâche périodique plus lente si la dynamique du processus le permet.

• Approprié pour les systèmes thermiques ou de niveau plus lents
• Moins approprié pour le contrôle de mouvement rapide ou le contrôle de pression serré
• Doit rester cohérent avec l'objectif de contrôle

#### 5. Précalculer les constantes si possible

Stockez les coefficients fixes et évitez les calculs répétés pour les valeurs qui ne changent pas d'un cycle à l'autre.

• Réduit l'arithmétique inutile
• Simplifie le chemin d'exécution au moment de l'exécution

Une correction pratique mérite d'être énoncée clairement : un temps de cycle plus rapide n'est pas automatiquement un meilleur contrôle. Pour le MPC, la question est de savoir si la vitesse de mise à jour du contrôle est appropriée pour le processus et durable pour le contrôleur. Rapide et instable reste instable.

Un multiplicateur matrice-vecteur 2x2 en Ladder est construit en calculant un produit scalaire par index de sortie. Chaque élément de sortie est la somme des produits d'une ligne de matrice et du vecteur d'entrée.

Supposons :

\[ A = \begin{bmatrix} a_{00} & a_{01}\\ a_{10} & a_{11} \end{bmatrix} ,\quad x = \begin{bmatrix} x_0\\ x_1 \end{bmatrix} \]

Alors :

\[ x_{next,0} = a_{00}x_0 + a_{01}x_1 \]

\[ x_{next,1} = a_{10}x_0 + a_{11}x_1 \]

### Étape 1 : Calculer le premier produit partiel pour l'index 0

Multipliez `Matrix_A[0,0]` par `Vector_x[0]` et stockez le résultat dans `Temp_Mul_00`.

- Source A : `Matrix_A[0,0]` - Source B : `Vector_x[0]` - Destination : `Temp_Mul_00`

### Étape 2 : Calculer le deuxième produit partiel pour l'index 0

Multipliez `Matrix_A[0,1]` par `Vector_x[1]` et stockez le résultat dans `Temp_Mul_01`.

- Source A : `Matrix_A[0,1]` - Source B : `Vector_x[1]` - Destination : `Temp_Mul_01`

### Étape 3 : Sommer les produits pour l'index de sortie 0

Ajoutez `Temp_Mul_00` et `Temp_Mul_01`, puis stockez le résultat dans `Vector_x_Next[0]`.

- Source A : `Temp_Mul_00` - Source B : `Temp_Mul_01` - Destination : `Vector_x_Next[0]`

### Étape 4 : Répéter le modèle pour l'index de sortie 1

Multipliez et additionnez la deuxième ligne :

• `Matrix_A[1,0] * Vector_x[0] -> Temp_Mul_10`
• `Matrix_A[1,1] * Vector_x[1] -> Temp_Mul_11`
• `Temp_Mul_10 + Temp_Mul_11 -> Vector_x_Next[1]`

Concept de schéma à contacts pour la première ligne

|----[MUL Matrix_A[0,0] Vector_x[0] ]----------------(Temp_Mul_00)----| |----[MUL Matrix_A[0,1] Vector_x[1] ]----------------(Temp_Mul_01)----| |----[ADD Temp_Mul_00 Temp_Mul_01 ]--------------(Vector_x_Next[0])--|

Concept média : Instructions `MUL` et `ADD` déroulées pour la ligne 0 d'une matrice d'état 2x2.

Texte alternatif de l'image : Capture d'écran de l'éditeur de logique Ladder d'OLLA Lab montrant une multiplication matricielle 2x2 déroulée en blocs MUL et ADD explicites, avec le panneau des variables affichant les valeurs du tableau REAL résultant pour un scénario de contrôle prédictif multi-variables.

Dans OLLA Lab, le flux de travail pratique consiste à construire cette séquence de barreaux dans l'éditeur Ladder basé sur navigateur, à exécuter le mode simulation et à inspecter `Matrix_A`, `Vector_x`, les tags temporaires et `Vector_x_Next` dans le panneau des variables. Cela permet à l'ingénieur de confirmer trois choses séparément :

• l'arithmétique est correcte,
• les tags sont mappés correctement,
• et le coût en temps de cycle reste acceptable sous la charge de simulation.

C'est une distinction utile car des mathématiques erronées et un câblage erroné produisent souvent le même premier symptôme : une variable de processus se dirigeant vers un endroit inutile.

La correction mathématique est nécessaire mais pas suffisante. Un calcul matriciel peut être numériquement correct et produire tout de même un comportement de contrôle médiocre lorsqu'il est attaché à une installation simulée avec couplage, retard, saturation et perturbations.

Pour cet article, la validation par jumeau numérique signifie quelque chose d'opérationnellement spécifique : exécuter l'implémentation Ladder contre un modèle d'équipement simulé réaliste, injecter des changements ou des défauts contrôlés, et comparer l'état du contrôleur, le comportement des E/S et la réponse du processus avant tout déploiement sur le terrain.

Dans OLLA Lab, ce flux de travail de validation peut inclure :

• la liaison d'une logique basée sur des tableaux à un scénario analogique multi-variables,
• l'ajustement des entrées et perturbations du processus en mode simulation,
• l'observation du comportement des variables et des E/S en temps réel,
• la comparaison de l'état du Ladder par rapport à l'état de l'équipement simulé,
• et la révision de l'implémentation après l'apparition d'un comportement anormal.

Un cas de test utile est un processus couplé tel que le débit et la pression du réservoir ou le niveau et la température. Injectez un changement d'échelon dans une variable manipulée, puis vérifiez si la mise à jour de l'état prédit suit la réponse du processus simulé sans oscillation incontrôlée, saturation ou couplage croisé invraisemblable.

C'est ici que Simulation-Ready doit être défini correctement. Un ingénieur Simulation-Ready n'est pas simplement quelqu'un qui peut écrire une syntaxe d'automate valide. C'est un ingénieur qui peut prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste avant qu'elle n'atteigne un processus réel. La syntaxe est facile à admirer. Le déploiement est moins indulgent.

Que faut-il documenter comme preuve d'ingénierie ?

Si vous voulez démontrer votre compétence en logique d'automate avancée, construisez un corpus compact de preuves d'ingénierie plutôt qu'une galerie de captures d'écran.

Utilisez cette structure :

• Définissez le processus, les états, les variables manipulées et l'objectif de contrôle.

- Indiquez ce que signifie un comportement acceptable en termes mesurables : temps de stabilisation, dépassement borné, pas de défaut de chien de garde, mise à jour d'état stable, comportement correct des interverrouillages.

• Montrez les barreaux implémentés, les tags pertinents et la réponse correspondante de l'installation simulée.

• Enregistrez la perturbation, le coefficient erroné, la défaillance du capteur, l'événement de saturation ou la contrainte temporelle introduite.

• Expliquez quel changement de logique, de planification, de mise à l'échelle ou de type de données a été appliqué.

• Indiquez ce que la défaillance a révélé sur le modèle, l'implémentation ou les limites du contrôleur.

1. Description du système
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé
4. Le cas de défaut injecté
5. La révision effectuée
6. Leçons apprises

Cette structure est plus précieuse qu'une capture d'écran polie car elle démontre le jugement d'ingénierie sous contrainte. Les employeurs et les réviseurs se soucient généralement moins de savoir si le barreau semblait propre que de savoir si vous saviez quoi faire lorsque le modèle se comportait mal.

Les mathématiques MPC appartiennent à l'automate uniquement lorsque le contrôleur, la structure de la tâche et la dynamique du processus le permettent. La migration du contrôle avancé vers l'exécution en périphérie (edge) et locale est réelle, mais cela ne signifie pas que chaque automate devrait devenir un petit DCS surchargé.

Gardez le calcul dans l'automate lorsque ces conditions sont vraies :

• les dimensions de la matrice sont modestes,
• le temps d'exécution est borné et testé,
• le processus bénéficie d'une réponse déterministe locale,
• les équipes de maintenance peuvent supporter l'implémentation,
• et la validation a montré un comportement stable sous des perturbations réalistes.

Déplacez le calcul vers un DCS, un PC industriel ou une couche de calcul en périphérie lorsque ces conditions dominent :

• horizons d'optimisation plus larges,
• opérations matricielles plus lourdes,
• mises à jour fréquentes du modèle,
• ressources d'automate contraintes,
• ou impact inacceptable sur le temps de cycle.

La question d'ingénierie n'est pas de savoir si le MPC basé sur automate est à la mode. C'est de savoir si l'implémentation est auditable, déterministe et supportable sur le matériel cible. Ce sont des mots moins glamour que « IA » ou « optimisation ». Ils permettent aussi aux usines de fonctionner.

Cette implémentation se situe à la croisée de la théorie du contrôle, des contraintes d'exécution des automates, de la pratique de la simulation et de la discipline d'ingénierie adjacente à la sécurité. Aucune norme unique ne vous dit comment écrire une multiplication matricielle en Ladder, mais plusieurs corpus de littérature et normes façonnent les limites correctes.

Les références pertinentes incluent :

• IEC 61131-3
• Régit les langages de programmation des automates tels que le schéma à contacts (Ladder) et le texte structuré.
• IEC 61508
• Fournit le cadre plus large pour la sécurité fonctionnelle des systèmes électriques/électroniques/électroniques programmables.
• Conseils d'exida et littérature sur le cycle de vie de la sécurité
• Utile pour comprendre la preuve, la discipline de validation et la séparation entre le comportement fonctionnel et les revendications de sécurité.
• Littérature IFAC et contrôle de processus
• Pertinent pour l'architecture MPC, la modélisation de l'espace d'état et l'optimisation sous contraintes.
• Littérature sur le jumeau numérique et la formation à la simulation
• Pertinent pour valider la logique par rapport au comportement réaliste de l'installation et améliorer la préparation à la mise en service.

Une limite nécessaire : valider la logique de contrôle en simulation n'établit pas en soi la conformité SIL, la conformité réglementaire ou la compétence du site. Cela améliore les preuves avant déploiement. Cela n'abolit pas le reste de l'ingénierie.

- 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)