Come implementare la moltiplicazione di matrici per il controllo predittivo (MPC) su PLC in Ladder Logic

Per implementare il Model Predictive Control (MPC) in un PLC, i tecnici devono eseguire la moltiplicazione di matrici utilizzando calcoli basati su array. Poiché il Ladder Diagram standard non dispone di un operatore matriciale nativo, l'approccio abituale consiste nel mappare i termini dello spazio di stato in array, sviluppare le operazioni `MUL` e `ADD` necessarie e verificare l'impatto sul tempo di scansione prima del deployment sull'hardware.

La moltiplicazione di matrici in un PLC non è principalmente un problema matematico. È un problema di determinismo che indossa una veste matematica. L'MPC dipende da equazioni di stato come \(x_{k+1}=Ax_k+Bu_k\), ma il Ladder Diagram standard non fornisce un'istruzione nativa per la moltiplicazione di matrici; pertanto, il tecnico deve tradurre tale algebra in operazioni su array esplicite che il controllore possa eseguire in modo prevedibile.

Metrica Ampergon Vallis: Nei test di stress del ciclo di scansione interni di OLLA Lab, lo sviluppo di una moltiplicazione matrice-vettore 3x3 in istruzioni `MUL` e `ADD` sequenziali esplicite è stato eseguito 4,2 ms più velocemente per scansione rispetto a una base di riferimento in Structured Text con cicli annidati nello stesso envelope di attività simulata. Metodologia: n=18 esecuzioni ripetute; definizione dell'attività = valutazione ripetuta di matrice-vettore REAL 3x3 con aggiornamenti di stato analogici; comparatore di riferimento = implementazione in Structured Text con ciclo `FOR` annidato; finestra temporale = test di banco di marzo 2026. Ciò supporta un'affermazione limitata riguardo al sovraccarico di implementazione in questo setup di test. Non dimostra che il Ladder sviluppato sia sempre più veloce su ogni famiglia di PLC, revisione firmware o compilatore.

Questa distinzione è importante perché i watchdog timer non sono filosofici. Mandano in blocco le CPU reali.

La matematica matriciale è il nucleo computazionale dell'MPC. Il controllore prevede il comportamento futuro del processo a partire da un modello, valuta le azioni di controllo e aggiorna le uscite in base alla risposta attesa di molteplici variabili interagenti.

La forma standard dello spazio di stato a tempo discreto è:

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

Dove:

• \(x(k)\) = vettore di stato corrente
• \(x(k+1)\) = prossimo vettore di stato previsto
• \(A\) = matrice di sistema che descrive le dinamiche interne del processo
• \(B\) = matrice di ingresso che descrive come le variabili manipolate influenzano gli stati
• \(u(k)\) = vettore di ingresso di controllo

In termini di PLC, questi oggetti diventano tag e array:

• `Matrix_A` memorizza i coefficienti delle dinamiche di processo
• `Matrix_B` memorizza i coefficienti di influenza degli ingressi
• `Vector_x` memorizza gli stati correnti misurati o stimati
• `Vector_u` memorizza gli ingressi manipolati correnti
• `Vector_x_Next` memorizza il prossimo stato previsto

La distinzione importante è SISO contro MIMO. Un loop PID solitamente gestisce una variabile misurata rispetto a una variabile manipolata. L'MPC è costruito per un comportamento multi-input, multi-output, dove la modifica di un attuatore può influenzare diverse variabili di processo contemporaneamente. I sistemi a vapore, le reti di serbatoi, gli skid termici e le interazioni pressione-flusso raramente sono abbastanza "educati" da rimanere disaccoppiati.

Le equazioni dello spazio di stato si mappano nella logica Ladder convertendo matrici e vettori in array PLC, quindi eseguendo ogni prodotto scalare in modo esplicito. Il Ladder può rappresentare la matematica, ma non la astrae per te.

Per un esempio compatto 2x2, la struttura dei tag può essere definita come segue:

Struttura del dizionario tag per un sistema 2x2

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

• Memorizza i coefficienti delle dinamiche di sistema
• Memorizza gli stati correnti, come livello del serbatoio e temperatura
• Memorizza i valori del prossimo stato previsto
• Memoria temporanea per `Matrix_A[0,0] * Vector_x[0]`
• Memoria temporanea per `Matrix_A[0,1] * Vector_x[1]`
• Memoria temporanea per `Matrix_A[1,0] * Vector_x[0]`
• Memoria temporanea per `Matrix_A[1,1] * Vector_x[1]`

La regola operativa è semplice: ogni riga della matrice diventa un calcolo di prodotto scalare e ogni prodotto scalare diventa una sequenza di moltiplicazioni e addizioni esplicite. Elegante sulla carta; ripetitivo nel Ladder. La CPU, tuttavia, si preoccupa più della prevedibilità che dell'eleganza.

In OLLA Lab, questo diventa ispezionabile anziché teorico. L'editor Ladder può essere accoppiato al pannello delle variabili in modo che un tecnico possa osservare ogni indice di array, registro temporaneo e valore di stato risultante aggiornarsi in tempo reale durante la simulazione. Ciò è operativamente utile perché consente di verificare non solo che il rung sia sintatticamente valido, ma che i binding degli array e i valori intermedi siano numericamente sensati prima che venga coinvolta qualsiasi scheda di uscita reale.

Il Ladder Logic ha difficoltà con la moltiplicazione di matrici perché il LD standard è orientato alle istruzioni, non all'algebra. È progettato attorno a contatti, bobine, blocchi funzione ed esecuzione deterministica dei rung, non all'algebra lineare ad alta densità.

Le limitazioni principali sono solitamente queste:

• Nessun operatore matriciale nativo
• Gli ambienti Ladder standard solitamente non forniscono un'istruzione singola per la moltiplicazione matrice-vettore o matrice-matrice.
• Ergonomia limitata dei cicli
• L'iterazione è solitamente più semplice in Structured Text che in Ladder Diagram.
• Forte dipendenza da tag temporanei
• Anche piccole operazioni matriciali richiedono memoria intermedia per ogni prodotto parziale.
• Sensibilità al ciclo di scansione
• L'aritmetica in virgola mobile, l'indicizzazione degli array e i calcoli ripetuti consumano un tempo di esecuzione misurabile.

Ciò non significa che il Ladder non possa fare il lavoro. Significa che il tecnico deve scegliere tra due stili di implementazione:

### Opzione 1: Utilizzare Structured Text per i cicli

Spesso è l'espressione più compatta della matematica. Un ciclo `FOR` annidato può calcolare un prodotto matrice-vettore in modo pulito, specialmente quando le dimensioni possono cambiare.

Vantaggi

• Codice più breve
• Più facile da scalare per matrici più grandi
• Più naturale per la matematica iterativa

Compromessi

• Il sovraccarico di esecuzione può aumentare a seconda della piattaforma e del comportamento del compilatore
• La visibilità del debug può essere meno ovvia per i team che lavorano principalmente in Ladder
• Alcuni team di manutenzione preferiscono una logica esplicita rung-per-rung per la risoluzione dei problemi

### Opzione 2: Sviluppare la matematica matriciale nel Ladder Diagram

Ciò significa scrivere ogni moltiplicazione e addizione esplicitamente.

Vantaggi

• Esecuzione deterministica e visivamente tracciabile
• Risoluzione dei problemi a livello di rung più semplice
• Spesso meglio allineato con le aspettative di manutenzione sui sistemi incentrati sul Ladder

Compromessi

• Implementazione prolissa
• Scarsa scalabilità all'aumentare delle dimensioni della matrice
• Alto rischio di errori di copia-incolla se la disciplina di denominazione è debole

Questo è il classico contrasto: codice compatto contro esecuzione trasparente. Su un processo attivo, la trasparenza solitamente invecchia meglio.

La matematica in virgola mobile basata su array può aumentare materialmente il tempo di scansione del PLC. Se il tempo di esecuzione totale supera la soglia del watchdog configurata per quel controllore, la CPU può andare in errore e interrompere l'esecuzione.

Questo è il rischio hardware reale. Non "il codice sembra pesante". Un errore.

Il carico sul tempo di scansione deriva solitamente da una combinazione di fattori:

• Aritmetica REAL
• Le operazioni in virgola mobile sono più costose delle operazioni su interi su molte piattaforme PLC.
• Indicizzazione degli array
• L'accesso indicizzato aggiunge un sovraccarico di indirizzamento rispetto ai tag scalari fissi.
• Cicli annidati
• L'iterazione ripetuta moltiplica rapidamente il costo di esecuzione.
• Logica analogica aggiuntiva
• Scaling, filtraggio, clamping e controlli di allarme spesso circondano la matematica matriciale anziché sostituirla.
• Esecuzione a scansione singola
• Eseguire il calcolo completo a ogni scansione potrebbe essere inutile e costoso.

Le impostazioni del watchdog timer variano in base alla famiglia di controllori e al design dell'applicazione. Un intervallo ampio di "tipicamente 10–50 ms" è comune nella pratica, ma il numero rilevante è sempre la soglia configurata sul sistema target effettivo. Gli standard non salvano un controllore da un'aritmetica che non riesce a terminare in tempo.

Strategie per la mitigazione del tempo di scansione

Le principali strategie di mitigazione sono architetturali, non cosmetiche.

#### 1. Sviluppare i calcoli critici

Scrivere istruzioni `MUL` e `ADD` esplicite per ogni termine in matrici piccole.

• Ideale per sistemi a dimensioni fisse ridotte
• Migliora la tracciabilità
• Evita il sovraccarico dei cicli in alcuni ambienti

#### 2. Suddividere il calcolo nel tempo (Time-slice)

Distribuire il calcolo matriciale su più scansioni utilizzando un indice di passo o una macchina a stati.

• Riduce il carico di scansione di picco
• Utile per calcoli più grandi
• Introduce una latenza che deve essere considerata nelle prestazioni di controllo

#### 3. Ottimizzare i tipi di dati

Utilizzare l'aritmetica su interi scalati come `DINT` dove la risoluzione e il range del processo lo consentono.

• Può ridurre il costo di esecuzione
• Richiede uno scaling disciplinato e una gestione dell'overflow
• Non sempre accettabile per modelli di processo ad alta risoluzione

#### 4. Ridurre la frequenza di esecuzione

Eseguire il calcolo predittivo su un task periodico più lento se le dinamiche di processo lo consentono.

• Appropriato per sistemi termici o di livello più lenti
• Meno appropriato per il controllo del movimento rapido o della pressione
• Deve rimanere coerente con l'obiettivo di controllo

#### 5. Precalcolare le costanti ove possibile

Memorizzare i coefficienti fissi ed evitare calcoli ripetuti per valori che non cambiano da una scansione all'altra.

• Riduce l'aritmetica non necessaria
• Semplifica il percorso di esecuzione in runtime

Una correzione pratica vale la pena di essere dichiarata chiaramente: un tempo di scansione più veloce non significa automaticamente un controllo migliore. Per l'MPC, la domanda è se la frequenza di aggiornamento del controllo sia appropriata per il processo e sostenibile per il controllore. Veloce e instabile è comunque instabile.

Un moltiplicatore matrice-vettore 2x2 nel Ladder viene costruito calcolando un prodotto scalare per indice di uscita. Ogni elemento di uscita è la somma dei prodotti di una riga della matrice e del vettore di ingresso.

Assumendo:

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

Allora:

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

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

### Passo 1: Calcolare il primo prodotto parziale per l'indice 0

Moltiplicare `Matrix_A[0,0]` per `Vector_x[0]` e memorizzare il risultato in `Temp_Mul_00`.

- Sorgente A: `Matrix_A[0,0]` - Sorgente B: `Vector_x[0]` - Destinazione: `Temp_Mul_00`

### Passo 2: Calcolare il secondo prodotto parziale per l'indice 0

Moltiplicare `Matrix_A[0,1]` per `Vector_x[1]` e memorizzare il risultato in `Temp_Mul_01`.

- Sorgente A: `Matrix_A[0,1]` - Sorgente B: `Vector_x[1]` - Destinazione: `Temp_Mul_01`

### Passo 3: Sommare i prodotti per l'indice di uscita 0

Aggiungere `Temp_Mul_00` e `Temp_Mul_01`, quindi memorizzare il risultato in `Vector_x_Next[0]`.

- Sorgente A: `Temp_Mul_00` - Sorgente B: `Temp_Mul_01` - Destinazione: `Vector_x_Next[0]`

### Passo 4: Ripetere il pattern per l'indice di uscita 1

Moltiplicare e sommare la seconda riga:

• `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]`

Concetto di Ladder Diagram per la prima riga

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

Concetto multimediale: Istruzioni `MUL` e `ADD` sviluppate per la riga 0 di una matrice di stato 2x2.

Testo alternativo immagine: Screenshot dell'editor Ladder Logic di OLLA Lab che mostra una moltiplicazione di matrici 2x2 sviluppata in blocchi MUL e ADD espliciti, con il pannello delle variabili che visualizza i valori risultanti dell'array REAL per uno scenario di controllo predittivo multivariabile.

In OLLA Lab, il flusso di lavoro pratico consiste nel costruire questa sequenza di rung nell'editor Ladder basato su browser, eseguire la modalità di simulazione e ispezionare `Matrix_A`, `Vector_x`, i tag temporanei e `Vector_x_Next` nel pannello delle variabili. Ciò consente al tecnico di confermare tre cose separatamente:

• l'aritmetica è corretta,
• i tag sono mappati correttamente,
• e il costo del tempo di scansione rimane accettabile sotto carico di simulazione.

Questa è una distinzione utile perché una matematica errata e un cablaggio errato producono spesso lo stesso primo sintomo: una variabile di processo che si dirige verso una direzione non utile.

La correttezza matematica è necessaria ma non sufficiente. Un calcolo matriciale può essere numericamente corretto e produrre comunque un comportamento di controllo scadente quando collegato a un impianto simulato con accoppiamento, ritardo, saturazione e disturbi.

Per questo articolo, la validazione del gemello digitale significa qualcosa di operativamente specifico: eseguire l'implementazione Ladder contro un modello di apparecchiatura simulata realistico, iniettare modifiche o guasti controllati e confrontare lo stato del controllore, il comportamento I/O e la risposta del processo prima di qualsiasi deployment sul campo.

In OLLA Lab, quel flusso di lavoro di validazione può includere:

• collegare la logica basata su array a uno scenario analogico multivariabile,
• regolare gli ingressi di processo e i disturbi in modalità simulazione,
• osservare il comportamento delle variabili e degli I/O in tempo reale,
• confrontare lo stato del Ladder rispetto allo stato dell'apparecchiatura simulata,
• e rivedere l'implementazione dopo che appare un comportamento anomalo.

Un caso di test utile è un processo accoppiato come flusso e pressione del serbatoio o livello e temperatura. Iniettare un gradino in una variabile manipolata, quindi verificare se l'aggiornamento dello stato previsto segue la risposta del processo simulato senza oscillazioni incontrollate, saturazione o accoppiamenti incrociati implausibili.

È qui che Simulation-Ready dovrebbe essere definito correttamente. Un tecnico Simulation-Ready non è semplicemente qualcuno che sa scrivere una sintassi PLC valida. È un tecnico che sa provare, osservare, diagnosticare e rafforzare la logica di controllo contro un comportamento di processo realistico prima che raggiunga un processo attivo. La sintassi è facile da ammirare. La manutenibilità è meno indulgente.

Cosa documentare come prova ingegneristica?

Se vuoi dimostrare competenza nella logica PLC avanzata, costruisci un corpo compatto di prove ingegneristiche piuttosto che una galleria di screenshot.

Usa questa struttura:

• Definire il processo, gli stati, le variabili manipolate e l'obiettivo di controllo.

- Dichiarare cosa significa comportamento accettabile in termini misurabili: tempo di assestamento, overshoot limitato, nessun errore di watchdog, aggiornamento di stato stabile, comportamento corretto degli interblocchi.

• Mostrare i rung implementati, i tag rilevanti e la corrispondente risposta dell'impianto simulato.

• Registrare il disturbo, il coefficiente errato, il guasto del sensore, l'evento di saturazione o lo stress temporale introdotto.

• Spiegare quale logica, pianificazione, scaling o modifica del tipo di dati è stata applicata.

• Dichiarare cosa ha rivelato il guasto riguardo al modello, all'implementazione o ai limiti del controllore.

1. Descrizione del sistema
2. Definizione operativa di "corretto"
3. Logica Ladder e stato dell'apparecchiatura simulata
4. Il caso di guasto iniettato
5. La revisione effettuata
6. Lezioni apprese

Questa struttura è più preziosa di uno screenshot rifinito perché dimostra il giudizio ingegneristico sotto vincolo. I datori di lavoro e i revisori solitamente si preoccupano meno del fatto che il rung sembri ordinato rispetto al fatto che tu sappia cosa fare quando il modello si comporta in modo anomalo.

La matematica MPC appartiene al PLC solo quando il controllore, la struttura del task e le dinamiche di processo la supportano. La migrazione del controllo avanzato verso l'edge e l'esecuzione locale è reale, ma ciò non significa che ogni PLC debba diventare un piccolo DCS sovraccarico.

Mantenere il calcolo nel PLC quando queste condizioni sono vere:

• le dimensioni della matrice sono modeste,
• il tempo di esecuzione è limitato e testato,
• il processo beneficia di una risposta deterministica locale,
• i team di manutenzione possono supportare l'implementazione,
• e la validazione ha mostrato un comportamento stabile sotto disturbi realistici.

Spostare il calcolo su un DCS, un PC industriale o un livello di calcolo edge quando dominano queste condizioni:

• orizzonti di ottimizzazione più ampi,
• operazioni matriciali più pesanti,
• aggiornamenti frequenti del modello,
• risorse PLC limitate,
• o un impatto inaccettabile sul tempo di scansione.

La domanda ingegneristica non è se l'MPC basato su PLC sia di moda. È se l'implementazione sia verificabile, deterministica e supportabile sull'hardware target. Queste sono parole meno affascinanti di "AI" o "ottimizzazione". Mantengono anche gli impianti in funzione.

Questa implementazione si colloca tra la teoria del controllo, i vincoli di esecuzione del PLC, la pratica di simulazione e la disciplina ingegneristica adiacente alla sicurezza. Nessun singolo standard ti dice come scrivere la moltiplicazione di matrici nel Ladder, ma diversi corpi di letteratura e standard definiscono i confini corretti.

I riferimenti rilevanti includono:

• IEC 61131-3
• Regola i linguaggi di programmazione PLC come Ladder Diagram e Structured Text.
• IEC 61508
• Fornisce il quadro più ampio per la sicurezza funzionale dei sistemi elettrici/elettronici/elettronici programmabili.
• Letteratura di orientamento e ciclo di vita della sicurezza exida
• Utile per comprendere la prova, la disciplina di validazione e la separazione tra comportamento funzionale e dichiarazioni di sicurezza.
• Letteratura IFAC e di controllo di processo
• Rilevante per l'architettura MPC, la modellazione dello spazio di stato e l'ottimizzazione vincolata.
• Letteratura sulla formazione su gemelli digitali e simulazione
• Rilevante per la validazione della logica rispetto al comportamento realistico dell'impianto e il miglioramento della prontezza alla messa in servizio.

Un confine necessario: validare la logica di controllo in simulazione non stabilisce di per sé l'idoneità SIL, la conformità normativa o la competenza del sito. Migliora le prove pre-deployment. Non abolisce il resto dell'ingegneria.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standards family - exida functional safety and validation resources - NAMUR NE 107 status signaling recommendation - Digital twin in industry: state-of-the-art (DOI)