CONTROLLO
tecnica
Settembre 2014
■
Automazione e Strumentazione
70
necessario specificare le modalità operative
di ogni blocco di calcolo e di controllo, defi-
nire le logiche di setpoint ed output tracking
di ogni blocco funzionale, l’origine dei
valori di tracking, e le logiche di controllo
che servono a garantire una attivazione e
disattivazione bumpless di ogni blocco della
strategia, e della strategia nel suo insieme.
La variazione di stato operativo di un ele-
mento di controllo (ad esempio il passaggio
di un controllore feedback da manuale ad
automatico) si definisce
bumpless
quando
viene eseguita senza causare variazioni
istantanee del setpoint o della variabile
manipolata, ovvero senza indurre brusche
variazioni sul processo.
Allo stesso modo, sebbene si tratti di un
evento relativamente raro, l’insorgere di
una condizione di bad value di una qualsiasi
variabile misurata, controllata o manipolata,
deve essere opportunamente gestito al fine
di evitare comportamenti anomali o indesi-
derati della strategia di controllo non solo al
manifestarsi della condizione di bad value, o
mentre questa sussiste, ma anche quando il
segnale o il valore della variabile interessata
dal bad value torna ad essere normale.
Anche in questo caso, la gestione di una
condizione di bad value per un loop di
regolazione semplice non presenta partico-
lari difficoltà e spesso ci si può affidare alla
configurazione standard dei moderni sistemi
DCS, senza richiedere ulteriori funzionalità
o accorgimenti.
Al contrario, la gestione di una condizione
di bad value di una strategia di controllo
complesso o di tipo ARC, necessita di logi-
che di controllo dedicate.
In aggiunta a quanto sopra, quando la stra-
tegia di controllo include dei blocchi di cal-
colo, si deve porre attenzione all’insorgere
di condizioni di bad value indotte dai bloc-
chi di calcolo stessi, ad esempio a causa di
errori quali radice quadrata o logaritmo di
numeri negativi, o a risultati dei calcoli non
compatibili con vincoli numerici predefiniti.
In questi casi sarebbe opportuno definire
per ogni blocco di calcolo, o parte di esso,
valori numerici entro cui limitare non solo le
variabili di ingresso al blocco di calcolo, ma
anche i risultati intermedi e finali.
Stessa attenzione deve essere dedicata alla
definizione delle interfacce del DCS con
altri sistemi di controllo. In particolare,
oltre ad identificare quali segnali debbano
essere di tipo analogico e quali, invece, pos-
sono essere scambiati utilizzando interfacce
seriali, si deve anche stabilire come gestire
la perdita di comunicazione tra i sistemi di
controllo e l’inizializzazione delle interfacce
seriali.
Alla luce di tutti questi esempi si può dedurre
facilmente che la definizione e progetta-
zione di strategie di controllo complesso
o di tipo ARC deve rispondere non solo
alle esigenze di quelle condizioni opera-
tive cosiddette normali, che corrispondono,
cioè, al normale funzionamento dell’im-
pianto, ma anche, e soprattutto, a condizioni
di funzionamento anomalo delle strategie
di controllo stesse, così come a situazioni
operative atipiche dell’impianto (ad esem-
pio la fase di startup, quando le strategie di
controllo complesso sono operate in modo
parziale).
Infatti, sebbene alcune di queste condizioni
anomale possano sembrare alquanto impro-
babili e la loro frequenza di accadimento
rara, il loro numero, il numero di combina-
zioni possibili, e la loro complessità sono
indubbiamente non trascurabili.
Implementazione e manutenzione
strategie ARC
La definizione e progettazione di qualsiasi
strategia di controllo, a prescindere dalla
complessità di questa, dovrebbe prendere
in considerazione anche l’implementa-
zione e manutenzione della strategia stessa.
In aggiunta, l’uso dei blocchi funzionali
della libreria standard del DCS selezionato
dovrebbe essere massimizzato.
Infatti, sebbene l’uso dei blocchi funzionali
standard possa dare minor flessibilità nella
progettazione delle strategie di controllo,
allo stesso tempo ne riduce notevolmente i
tempi di implementazione e collaudo e ne
facilita la manutenzione.
Al contrario, utilizzare blocchi funzionali
non standard e sviluppati ad-hoc, pur faci-
litando la progettazione di strategie com-
plesse, ne allunga i tempi di implementa-
zione e collaudo, e rende la manutenzione
delle strategie stesse un’operazione delicata.
A riguardo, è opportuno tener presente che
le librerie standard dei sistemi DCS non
sempre contengono gli stessi blocchi fun-
zionali. E nonostante la denominazione di
alcuni di questi sia simile, se non la stessa,
possono essere riscontrate differenze non
trascurabili non solo tra DCS di diversi for-
nitori, ma anche tra modelli diversi dello
stesso fornitore.
A titolo di esempio, attenzione deve essere
posta al modo in cui viene implementato
l’algoritmo di controllo PID e quale valore
utilizza l’equazione di default del sistema
DCS per l’azione proporzionale e quella
derivativa. Alcuni sistemi utilizzano di
default il valore della variabile misurata,
altri il valore dello scostamento tra setpoint
e variabile misurata.
Sarebbe opportuno, in oltre, verificare se
l’abilitazione dell’azione derivativa possa
essere fatta con il loop in esercizio, o se si
debba essere entrare in configurazione, met-
tendo, quindi, il loop fuori servizio (situa-
zione che dovrebbe essere evitata con l’im-
pianto in marcia).
Analogamente, è consigliabile verificare,
possibilmente prima di iniziare progetta-
zione delle strategie di controllo avanzato,
se e come si possa implementare un con-
trollo feedforward-feedback con la libreria
standard del DCS selezionato (se di tipo
additivo, moltiplicativo, o se c’è la possibi-
lità di utilizzare entrambe le configurazioni).
Alcune di queste problematiche possono
sembrare trascurabili, ma doverle prendere
in esame e risolvere in una fase troppo avan-
zata del progetto, ad esempio durante i col-
laudi del sistema DCS, potrebbe comportare
rifacimenti con impatti considerevoli, in ter-
mini di tempi e di costi.
Sistemi ed applicazioni MPC
Lo sviluppo di strategie di controllo avan-
zato di tipo model predictive control (MPC)
è condizionato in modo significativo da
condizioni e vincoli operativi, molti dei
quali possono essere identificati, valutati ed
eventualmente inclusi nel modello di con-
trollo solo dopo aver analizzato dati di pro-
cesso rilevati con gli impianti in esercizio.
Ciononostante, ci sono alcuni aspetti che se
gestiti in modo e con tempistiche adeguate
possono accelerare i tempi di esecuzione di
un progetto MPC, rendendone più proficua
La comunicazione e l’integrazione tra controllo
MCP e sistema di regolazione di base (DCS)
sono fondamentali
