Man mano che i processi di trattamento delle acque sono diventati più esigenti — evaporazione e cristallizzazione a scarico liquido zero, acqua ultrapura per grado semiconduttore, separazione profonda dei sali e detossificazione dei metalli pesanti per effluenti industriali difficili — anche il livello di automazione sottostante ha dovuto crescere di pari passo. Due architetture hanno dominato questo livello per decenni: il sistema di controllo distribuito (DCS) e il controllore a logica programmabile (PLC). Hardware e software sono in parte convergiti negli anni, dando vita a piattaforme DCS ibride e a controllori di automazione programmabili (PAC) che sfumano il confine sulla carta. Ma sotto questa convergenza, i due approcci restano fondati su presupposti diversi in fatto di architettura del database, pianificazione dei task, ridondanza e profondità degli anelli di controllo — differenze che contano molto più di quanto suggerisca il vecchio adagio “il PLC gestisce i segnali discreti, il DCS quelli analogici”.
Due filosofie a confronto: la macchina e il processo
L’eredità del PLC, incentrata sulla macchina. Le origini del PLC risalgono alla sostituzione della logica a relè nelle linee di montaggio automobilistiche. È stato concepito per gestire logica discreta veloce e deterministica, con l’attenzione fissata su singole apparecchiature — una pompa, una valvola, un raschiatore — e sulle loro transizioni di stato, sequenze e interblocchi di sicurezza. Il suo modello mentale è ingresso, logica, uscita, e privilegia la velocità di risposta e l’autonomia autosufficiente in un unico controllore.
L’eredità del DCS, incentrata sul processo. Il DCS nasce nell’industria petrolchimica e nei processi a flusso continuo, concepito per gestire grandi processi fisici e chimici estesi a tutto l’impianto — evaporazione termica, estrazione, reazione continua — come un unico sistema fluido indivisibile. Il suo modello mentale è il bilancio di processo, la regolazione multi-anello e il monitoraggio dell’intero impianto, e privilegia l’accoppiamento dinamico tra variabili, la precisione in regime stazionario del controllo analogico e la coerenza assoluta dei dati su tutta la struttura.
Architettura del database: un unico modello unificato contro due database assemblati
Un DCS è costruito dall’alto verso il basso attorno a un unico database globale. All’interno dell’ambiente di ingegnerizzazione, un tag, il suo tipo di variabile, il suo indirizzo hardware di I/O, i suoi limiti di allarme, le sue unità ingegneristiche, le impostazioni dello storico e la grafica HMI sono tutti vincolati allo stesso database unificato. Quando un ingegnere definisce un blocco PID o un blocco di controllo valvola a livello di controllore, il sistema genera automaticamente la corrispondente faceplate operatore, la voce di trend e la voce del log allarmi. Qualsiasi modifica online alla logica o alle proprietà di una variabile si propaga a tutti i nodi correlati senza una fase di sincronizzazione separata, il che riduce drasticamente il rischio di disallineamento dei tag che affligge i progetti di ingegnerizzazione di lunga durata.
Un PLC, al contrario, ha tradizionalmente utilizzato un database incentrato sull’hardware, costruito dal basso verso l’alto. Il suo nucleo è un controllore autonomo che esegue logica ad alta velocità, e il suo database è fondamentalmente una mappa di memoria hardware — indirizzi di memoria o tag indipendenti. Il PLC e il sistema di supervisione (SCADA/HMI) sono di norma prodotti software del tutto separati. Gli ingegneri definiscono gli I/O e le variabili intermedie all’interno dell’ambiente PLC, per poi mappare queste variabili nel database separato del sistema SCADA tramite OPC (Open Platform Communications) o un driver di comunicazione dedicato. Questa struttura a doppio database implica che le conversioni di tipo di dato delle variabili, le modifiche ai limiti di allarme e le impostazioni di archiviazione dei trend vadano configurate e mantenute due volte — una nel PLC, una nello SCADA. Se l’indirizzo di memoria di una variabile cambia sul lato PLC, il lato SCADA deve essere ricollegato manualmente, pena un’interruzione della comunicazione o un valore disallineato in modo silenzioso.
Pianificazione dei task: cicli di scansione fissi contro multitasking a slice temporali
Un PLC funziona con un’esecuzione ciclica basata sulla scansione: campionamento degli ingressi, scansione della logica di programma, aggiornamento delle uscite e gestione della comunicazione, in un ciclo fisso a quattro fasi. I tempi di scansione ricadono tipicamente nell’intervallo - (circa 1-10 ms), determinati per lo più dal numero di righe di codice che la scansione deve eseguire. Questo conferisce al PLC un eccellente determinismo temporale e un throughput molto rapido per la logica discreta — esattamente ciò di cui hanno bisogno gli interblocchi ad alta velocità e il controllo sequenziale.
Un DCS, invece, adotta una pianificazione multitasking, a slice temporali, guidata da interrupt. La logica di controllo è suddivisa in task periodici con priorità di esecuzione diverse: gli interblocchi di sicurezza e la logica ad alta velocità ricevono la priorità più alta (un ciclo di 50 ms, ad esempio), mentre la regolazione PID continua complessa, il controllo di disaccoppiamento e gli algoritmi di controllo di processo avanzato (APC/MPC) girano su task periodici a priorità inferiore (cicli di 200-500 ms). Questo modello di pianificazione è ciò che impedisce a una CPU di incepparsi o di far scattare un timeout del watchdog quando deve gestire simultaneamente diverse centinaia, o migliaia, di anelli PID in un grande processo continuo.
Ridondanza: architettura di sistema nativa contro modulo aggiuntivo
L’alta disponibilità è l’obiettivo stesso del controllo di processo, e DCS e PLC differiscono radicalmente nel modo — e nella trasparenza — con cui la ottengono.
Un DCS è stato progettato fin dall’origine per una produzione ininterrotta, 24 ore su 24, 365 giorni l’anno, per cui la sua ridondanza è nativa a livello di sistema. Controllori, moduli di alimentazione, bus di controllo di processo, bus di I/O e singoli canali di I/O sono di norma realizzati con hot standby continuo. Il controllore primario e quello di riserva restano sincronizzati fino al millisecondo tramite un collegamento hardware dedicato di mirroring della memoria — stato di esecuzione, variabili intermedie, immagine di memoria, tutto quanto. Se il controllore primario subisce un guasto hardware o perde alimentazione, quello di riserva subentra senza scosse: nessuna discontinuità in alcuna uscita analogica, nessuno scatto sulla valvola di controllo, e nessun codice aggiuntivo di sincronizzazione della ridondanza che l’ingegnere debba scrivere. Il voto tollerante ai guasti a livello di scheda e di canale (schemi 1oo2, 2oo3) è di norma integrato direttamente nell’hardware e nel software di configurazione.
La ridondanza di un PLC è invece solitamente assemblata a partire da moduli hardware di ridondanza esterni, rack a doppia CPU e moduli di comunicazione per ridondanza dedicati. I PLC moderni di fascia medio-alta possono senz’altro raggiungere l’hot standby del controllore, ma quanto sia effettivamente esente da urti il passaggio, e quanta parte di esso sia gestita in modo trasparente dalla piattaforma, dipende molto dall’implementazione specifica. In una configurazione tipica di ridondanza PLC, gli ingegneri devono spesso configurare esplicitamente i blocchi di sincronizzazione dati, mappare i flag di stato e, in alcuni casi, gestire in prima persona il comportamento di mantenimento di moduli specifici — una scheda di uscita analogica, ad esempio — durante il transitorio di commutazione.
Ovunque quella commutazione finisca per manifestarsi, essa è a valle dell’elemento finale di controllo vero e proprio. Qualunque sia l’architettura che impartisce il comando, la valvola di controllo o la pompa dosatrice che lo riceve ha una propria e distinta questione di dimensionamento — il selettore di attuatori pneumatici di questo sito copre proprio quella parte del quadro.
Profondità degli algoritmi di controllo
La libreria di controllo di processo del DCS. Un DCS viene fornito con un’ampia libreria di blocchi di controllo di processo di ordine elevato e collaudati a livello industriale. Il suo blocco PID integra nativamente anti-windup, transizione manuale/automatico esente da urti, compensazione feedforward, controllo di rapporto, guadagno adattivo, predittori di Smith per ritardi temporali fissi e algoritmi di disaccoppiamento multivariabile. Configurare un PID a cascata o un PID feedforward-feedback è in gran parte questione di collegare tra loro due pin di blocchi funzione; è l’algoritmo stesso a gestire internamente il tracciamento dello stato master/slave e la logica di commutazione manuale/automatico.
Come il PLC implementa la stessa matematica. Anche il PLC offre un blocco funzione PID di base, ma per tutto ciò che va oltre, di norma calcola soltanto la formula PID standard a tempo discreto:
Non appena il processo richiede disaccoppiamento multivariabile, sovrapposizione feedforward o commutazione di stato manuale/automatico, l’ingegnere deve scrivere codice aggiuntivo in structured text (ST) per gestire manualmente il blocco dello stato integrale, il clamping dell’uscita e la gestione delle variabili di tracking. Qualsiasi lacuna in questa logica tende a manifestarsi come un urto sull’uscita di controllo proprio nel passaggio manuale/automatico, che la valvola in campo percepisce come uno scatto improvviso.
Tre dimensioni del ciclo di vita ingegneristico che decidono il vero vincitore
Al di là delle differenze architetturali a livello di elaborazione, è “l’ergonomia” e l’esperienza operativa quotidiana di un sistema di controllo lungo l’intero ciclo di vita del progetto a stabilire davvero se una scelta è stata quella giusta.
Usabilità di ingegnerizzazione e implementazione
L’usabilità riguarda la velocità di sviluppo — dalla progettazione ingegneristica e dalla scrittura della logica, passando per la configurazione delle schermate, fino alla messa in servizio in campo.
Per la configurazione degli anelli di controllo, la ricca libreria di blocchi funzione di un DCS — anti-windup, transizione esente da urti, feedforward, controllo di rapporto, disaccoppiamento multivariabile, tutto integrato — permette a un ingegnere di configurare un anello complesso per lo più trascinando collegamenti tra blocchi predefiniti e compilando i parametri. Un PLC, disponendo solo di un blocco PID di base, richiede agli ingegneri di scrivere codice aggiuntivo in ladder diagram (LD) o structured text (ST) per la logica a cascata, feedforward o di disaccoppiamento, gestendo a mano il windup integrale, la transizione esente da urti e l’affidabilità dei valori anomali — una barriera di sviluppo più alta e risultati meno standardizzati.
Per lo sviluppo dell’HMI, un DCS è estremamente efficiente a livello di configurazione di sistema: aggiungendo un nuovo blocco funzione pompa o valvola sul controllore, l’interfaccia operatore eredita e genera automaticamente una faceplate standard — stato di marcia, commutazione manuale/automatico, testo di allarme guasto, trend in tempo reale, tutto quanto. Un PLC richiede invece un “doppio lavoro”: dopo aver scritto la logica di controllo nell’ambiente PLC, l’ingegnere deve aprire separatamente il software SCADA, disegnare manualmente la grafica delle valvole, costruire manualmente la mappatura di comunicazione dei tag e scrivere manualmente gli script dei popup e la logica di innesco degli allarmi per il pannello operatore.
Per l’integrazione di skid OEM, il quadro si ribalta. Poiché un DCS si basa su un database unificato e su una particolare architettura hardware, integrare un quadro di controllo indipendente proveniente da un fornitore terzo di skid — uno skid di pompaggio ad alta pressione, uno skid di generazione di ozono — tende a essere macchinoso; i dati del terzo devono di norma essere mappati attraverso un gateway generico Modbus o Profinet, il che spezza la coerenza del database nativo. Un PLC, al contrario, è intrinsecamente aperto e modulare: la stragrande maggioranza dei pacchetti skid OEM è costruita nativamente attorno a un PLC come controllore locale, per cui, a livello di integrazione dell’intero impianto, i sistemi PLC possono collegare tra loro skid di vendor diversi su un bus industriale comune con relativamente poco attrito.
Praticità operativa e di manutenzione
La manutenibilità determina direttamente il tempo medio di ripristino (MTTR) di un impianto dopo un guasto imprevisto, e quanta parte dell’operatività quotidiana avviene senza alcuna interruzione.
Per la programmazione e il download online, l’intera ragion d’essere di un DCS è non fermarsi mai. Supporta una vera compilazione online incrementale globale e download esente da urti: quando un ingegnere modifica la logica di controllo, ritara un PID o aggiunge una nuova variabile, il download non ha alcun effetto sullo stato di esecuzione runtime della CPU del controllore — le uscite delle valvole in campo restano lisce, gli anelli PID non saltano, e la schermata SCADA non fa nemmeno un tremolio nel proprio collegamento di comunicazione. Un moderno PLC di fascia medio-alta supporta la modifica online di alcuni segmenti di codice, ma qualunque cambiamento alla struttura di un blocco dati, alla configurazione hardware o una ricostruzione logica su larga scala forza tipicamente un download completo, che può portare il PLC in modalità di arresto per un intervallo da millisecondi a secondi, o interrompere brevemente la comunicazione con lo SCADA — un rischio concreto in una fase di processo chimico o termico altamente pericolosa e a funzionamento continuo, come un evaporatore MVR, dove un’interruzione di questo tipo può innescare uno scatto di sicurezza.
Per la diagnostica e la sostituzione a caldo, un DCS mantiene rigorose zone di contenimento dei guasti dal livello di canale, su fino al livello di scheda e al livello di bus, insieme a una capacità nativa di hot-swap (RIOP). Se un canale di ingresso analogico viene distrutto da un corto circuito in uno strumento di campo, la protezione di limitazione di corrente interna alla scheda e l’isolamento ottico impediscono che il guasto si propaghi mai a un canale vicino o al bus di backplane, e la scheda può essere sostituita senza un reset software. Le piattaforme DCS forniscono in genere anche una registrazione della sequenza degli eventi (SOE) a livello di sistema, conforme allo standard di gestione allarmi ISA-18.2, con risoluzioni fino a 1 ms, il che rende molto più semplice risalire alla vera causa primaria di un incidente. Anche le schede di I/O distribuito di un PLC supportano comunemente l’hot-swap, ma le informazioni diagnostiche devono di norma essere estratte dall’ingegnere richiamando un apposito blocco funzione di sistema per la diagnostica (SFC/SFB) nel programma PLC e passando esplicitamente il risultato interpretato allo SCADA. Se questa routine diagnostica non è mai stata scritta, un guasto a livello di scheda in campo può comparire nello SCADA come nient’altro di più specifico di un’astratta “perdita di comunicazione”.
Scalabilità e proiezione verso il futuro
L’aggiornabilità determina quanto bene un asset di automazione mantenga il proprio valore, e quanto costi un rinnovo tecnologico, lungo un ciclo di vita dell’impianto di 10-20 anni.
Per la retrocompatibilità e il ciclo di vita, i vendor DCS come categoria si impegnano su uno standard di compatibilità futura insolitamente rigoroso — i cicli di vita tipici del sistema si estendono per 15-20 anni o più. Un controllore DCS di nuova generazione può spesso montare una scheda di I/O installata vent’anni prima, e un progetto ingegneristico più datato può migrare in avanti con poche interruzioni. Questa evoluzione fluida abbassa in modo significativo il costo di capitale e il rischio tecnico dei futuri aggiornamenti di automazione dell’impianto. Il ciclo di iterazione di un PLC è più breve — i cicli di vita hardware tipici sono di 8-12 anni — e i componenti elettronici di livello consumer al suo interno vengono dismessi più rapidamente. Un salto generazionale da una famiglia di piattaforme PLC alla sua successora comporta comunemente un cambio integrale del protocollo di bus, del software di programmazione e del backplane hardware, per cui migrare un programma richiede di norma strumenti di conversione dedicati, o la riscrittura diretta della logica.
Per l’espansione hardware e la topologia di rete, l’espansione di un DCS è di norma costruita attorno a un’architettura di rete di processo fissa e ridondante: aggiungere una nuova stazione di I/O remota permette al sistema di assegnare automaticamente un indirizzo di nodo e completare la configurazione di instradamento, il che è standardizzato ma comporta vincoli topologici piuttosto rigidi. Un PLC ha una flessibilità di rete industriale considerevolmente maggiore, supportando Profinet, EtherNet/IP, Modbus TCP, EtherCAT e altri protocolli fianco a fianco. Quando un sistema di piccole-medie dimensioni viene ampliato, o quando un dispositivo eterogeneo di terze parti — un azionamento a frequenza variabile, un analizzatore intelligente della qualità dell’acqua, un robot — deve essere aggiunto, l’adattabilità di rete di un PLC è l’opzione più agile.
Sedici dimensioni a confronto
| Dimensione | DCS | PLC |
|---|---|---|
| Filosofia di progettazione | Incentrata sul processo, controllo di processo continuo | Incentrata sulla macchina, controllo a logica discreta |
| Architettura del database | Unico database globale unificato | Database del controllore indipendente, mappato allo SCADA via OPC/driver |
| Tipo di controllo dominante | Analogico, anelli PID complessi, disaccoppiamento multivariabile | Discreto/digitale, logica ad alta velocità, controllo sequenziale |
| Esecuzione della logica | Pianificazione multitasking a slice temporali, task periodici | Esecuzione ciclica a ciclo di scansione fisso |
| Tempo di scansione/risposta | Ciclo tipico: 50 ms – 500 ms | Molto rapido: 1 ms – 10 ms |
| Usabilità ingegneristica | Ricca libreria di algoritmi nativa; faceplate HMI e allarmi generati automaticamente | Libreria di algoritmi di base, richiede codifica ladder/ST; HMI configurata separatamente |
| Praticità operativa/di manutenzione | Download online incrementale globale esente da urti; isolamento nativo dei guasti a livello di canale | I download profondi possono forzare un arresto; la diagnostica richiede blocchi funzione scritti a mano |
| Ridondanza | Ridondanza completa nativa a livello di sistema (alimentazione, controllore, rete, I/O), esente da urti | Ridondanza opzionale modulare, richiede moduli dedicati e sincronizzazione a livello di codice |
| Capacità PID analogico | Libreria ricca (feedforward, cascata, predittore di Smith, MPC), forte disaccoppiamento | Blocco PID di base, disaccoppiamento multivariabile relativamente difficile |
| HMI | Integrazione nativa profonda; faceplate di valvole/pompe/PID generate automaticamente | Software SCADA indipendente, schermate e comunicazione dei tag costruite separatamente |
| Ciclo di vita e compatibilità | 15-20+ anni, forte retrocompatibilità hardware, aggiornamenti fluidi | 8-12 anni, iterazione più rapida, migrazione generazionale richiede conversione/riconfigurazione |
| Efficienza di sviluppo ingegneristico | Molto rapida per grandi processi continui, alta riutilizzabilità, modifiche online esenti da urti | Efficiente per la logica di dispositivi discreti; i grandi processi richiedono ampia mappatura manuale dei tag |
| Topologia di rete e bus | Ethernet industriale ibrida chiusa-e-aperta, reti ad anello/doppie ad alta ridondanza | Molto aperta, supporta Profinet, EtherNet/IP, Modbus TCP e altri |
| Isolamento dei guasti | Rigorose zone di contenimento dei guasti a livello di controllore e bus di I/O | Un guasto su una singola scheda può propagarsi ad altri moduli tramite il bus interno di backplane |
| Scala tipica | Conteggio I/O oltre ~2.000 punti, quota analogica elevata (>30%), sistemi a livello di intero impianto | Da poche decine a diverse migliaia di punti, distribuzione flessibile, prevalentemente discreto |
| CAPEX iniziale | Più elevato (costi di controllore e licenze software) | Più basso (ottimo rapporto prezzo/prestazioni hardware, vantaggio netto per sistemi piccoli) |
Abbinare l’architettura al segmento di trattamento delle acque
Processi di trattamento delle acque diversi hanno una natura fisica e chimica fondamentalmente diversa, ed è proprio questo a determinare l’architettura di controllo corretta.
Il trattamento di acqua potabile e reflui municipali è geograficamente disperso e dominato dai segnali discreti, per cui funziona su PLC in rete con un livello SCADA centrale. Un impianto municipale di trattamento reflui si estende su stazioni di sollevamento, grigliature, dissabbiatori, reattori biologici — A²/O, MBR, o altro — sedimentatori secondari e disidratazione fanghi. L’impianto è geograficamente disperso, con un elevato grado di autonomia delle sottostazioni; le apparecchiature (pompe, raschiatori, valvole) sono dominate dal controllo a stati discreti, e la logica di controllo è per lo più commutazione sequenziale basata su livello o tempo. Gli anelli PID (controllo dell’ossigeno disciolto nella vasca di aerazione, controllo della portata di dosaggio) sono relativamente pochi e in gran parte indipendenti tra loro. L’architettura pressoché universale è un sistema di monitoraggio SCADA centrale su sottostazioni PLC di campo regionali: ogni area di processo riceve il proprio quadro PLC che gestisce gli interblocchi locali delle apparecchiature, mentre lo SCADA aggrega i dati su una rete Ethernet industriale — una struttura con un chiaro vantaggio sia in termini di costo di capitale sia di flessibilità di disposizione della rete.
Le acque reflue industriali ad alta difficoltà e lo scarico liquido zero costituiscono un processo termodinamico-chimico fortemente accoppiato, ed è territorio del DCS. Nei sistemi ZLD costruiti attorno a reflui della chimica del carbone, petrolchimici o di desolforazione dei fumi, la filiera di processo attraversa pretrattamento, concentrazione a membrana ed evaporazione-cristallizzazione termica (MVR o evaporazione a effetto multiplo). Il livello dell’evaporatore, la pressione del vapore secondario, la portata della pompa di circolazione e la sovrasaturazione del liquido madre interagiscono tra loro in modo fortemente dinamico. L’I/O analogico rappresenta di norma il 30-50% dell’I/O totale, con un gran numero di anelli di controllo a cascata, feedforward e di disaccoppiamento. Se un controllore va offline o un anello PID inizia a oscillare, l’evaporatore può incrostarsi o la pompa di circolazione forzata può cavitare e intasarsi — e il costo di un fermo, di una pulizia e di un riavvio è severo. Un DCS nativo è qui quasi obbligato: la sua libreria di algoritmi di disaccoppiamento, la pianificazione multitasking deterministica, il database globale unificato e la modifica online esente da urti sono ciò che mantiene un sistema ZLD in funzionamento continuo a regime stazionario.
L’acqua ultrapura (UPW) per semiconduttori richiede il controllo delle impurità al livello di parti per trilione e una resistività prossima al limite teorico di . Un sistema UPW è costruito da un gran numero di skid OEM prefabbricati e densamente impacchettati — filtrazione a sabbia, RO, EDI, letto misto di affinamento — e necessita di un monitoraggio della qualità dell’acqua ad altissima frequenza; nel momento in cui la qualità dell’acqua esce dalle specifiche, una valvola deve chiudersi in millisecondi per proteggere la linea dei wafer a valle. L’architettura pressoché universale è ibrida: skid PLC distribuiti ad alta velocità più un DCS o SCADA di monitoraggio centrale. Ogni skid viene sviluppato e messo in servizio in modo indipendente dal proprio vendor OEM attorno a un PLC, il che garantisce efficienza di consegna modulare e risposta di protezione a scala millisecondica; il livello di monitoraggio centrale viene poi unificato nel DCS dell’impianto o in un grande sistema SCADA, offrendo pianificazione del bilancio idrico e tracciabilità della qualità a livello di intero impianto. L’articolo di questo sito sulla contaminazione in tracce nell’acqua ultrapura per semiconduttori approfondisce il lato della purezza di questo quadro.
Il trattamento delle acque reflue con metalli pesanti e speciali — reflui minerari, metallurgici e di galvanica che veicolano arsenico, antimonio, piombo, cadmio o cianuro — richiede due cose contemporaneamente: un dosaggio chimico estremamente preciso (regolato in continuo rispetto a ORP, pH e concentrazione di metalli pesanti in ingresso, un anello di controllo che il Calcolatore di dosaggio chimico di questo sito può aiutare a dimensionare) e interblocchi di sicurezza estremamente affidabili, poiché uno scarico fuori specifica deve essere intercettato e instradato verso una vasca di contenimento di emergenza entro pochi secondi. L’architettura tipica è un grande PLC a doppio hot standby, o un micro-DCS, scelto specificamente per una forte capacità di elaborazione analogica unita a ridondanza a livello hardware.
Tre casi di campo
Caso 1: ZLD ad alto contenuto salino e cristallizzazione per separazione dei sali nella chimica del carbone
Il progetto di scarico liquido zero di un grande polo della chimica del carbone, dimensionato per 12.000 m³/d, tratta un influente con circa 42.000 mg/L di TDS (di cui solfato intorno a 17.000 mg/L e cloruro intorno a 11.000 mg/L) attraverso un treno composto da separazione salina in nanofiltrazione a due stadi, cristallizzazione evaporativa del solfato di sodio, concentrazione a osmosi inversa e cristallizzazione evaporativa del cloruro di sodio — recuperando infine solfato di sodio con purezza e cloruro di sodio con purezza , con una frazione di sale misto pari solo a circa il 10%.
All’inizio del progetto, un’opzione PLC+SCADA è stata testata a confronto diretto con un DCS. Nella fase di evaporazione-cristallizzazione a circolazione forzata MVR, il DCS ha mostrato tre vantaggi decisivi:
Disaccoppiamento termodinamico complesso. Il livello del cristallizzatore, la pressione del vapore e la portata della pompa di circolazione interagiscono fortemente tra loro. Il DCS ha eseguito un algoritmo feedforward-cascata tramite il suo modulo integrato di controllo di processo avanzato (APC):
funzionante a regime su un ciclo di controllo di 200 ms, mantenendo la sovrasaturazione di cristallizzazione con precisione all’interno della zona metastabile. Il sistema PLC testato in parallelo, privo di un algoritmo di disaccoppiamento nativo, ha mostrato una severa oscillazione (hunting) tra gli anelli PID, innescando frequenti sovrapressioni dell’evaporatore.
Modifiche online esenti da urti. Durante la fase di scale-up/messa a punto, la logica del rapporto di dosaggio richiedeva aggiustamenti frequenti. La compilazione online incrementale globale del DCS ha avuto effetto senza soluzione di continuità, senza alcun disturbo su alcuna uscita PID. Nel test PLC, il tentativo di scaricare un blocco dati modificato ha innescato una breve disconnessione dallo SCADA, e la valvola di dosaggio è momentaneamente scesa a zero.
Isolamento hardware a livello di canale. Durante il funzionamento, un corto circuito nel densimetro del liquido madre ha causato un riflusso ad alta pressione. L’isolamento di canale della scheda DCS ha bloccato con successo la propagazione del guasto; il controllore ha mantenuto automaticamente l’uscita precedente, sollevato un allarme e consentito la sostituzione a caldo della scheda guasta, senza alcun fermo impianto (RIOP nativo).
Caso 2: sistema di acqua ultrapura in una fab per semiconduttori
Il sistema UPW di una fab per wafer da 12 pollici, dimensionato per 15.000 m³/d, opera secondo un’architettura “pacchetti skid PLC più SCADA/DCS centrale”.
Protezione a scala millisecondica. Quando un analizzatore TOC in linea al punto d’uso rileva una violazione della qualità dell’acqua (oltre circa 2 ppb), il PLC locale dello skid esegue una routine di interruzione terminale ciclica fissa a 5 ms, completando l’azione di una valvola di intercettazione a tre vie entro 40 ms — bloccando con successo l’acqua fuori specifica prima che raggiunga la linea di produzione.
Consegna modulare OEM. Diciotto skid indipendenti (filtrazione a sabbia, RO, EDI, letto misto) sono stati scritti e messi in servizio internamente da fornitori diversi utilizzando un PLC, e poi collegati al sistema centrale in loco tramite i protocolli standard Profinet e OPC UA — comprimendo nettamente il calendario di costruzione dell’impianto.
Caso 3: impianto municipale di trattamento reflui da 100.000 m³/d, retrofit intelligente
Un impianto municipale di trattamento reflui da 100.000 m³/d ha ricostruito il proprio assetto originario “sette sottostazioni PLC indipendenti più SCADA” in un sistema di controllo ibrido unificato.
Distribuzione dei controllori. Prima del retrofit: sette sottostazioni PLC indipendenti senza comunicazione diretta tra controllori. Dopo: un’architettura di controllo distribuita e integrata su una piattaforma unificata.
Gestione del database. Prima: sette database PLC separati più un database SCADA, ciascuno configurato in modo indipendente. Dopo: un unico database ingegneristico centralizzato e unificato.
Controllo dell’ossigeno disciolto in aerazione. Prima del retrofit, il DO era mantenuto con un semplice controllo on/off temporizzato, oscillando entro circa . Dopo il retrofit, il DO è stato gestito con un PID feedforward-cascata, secondo:
mantenendo il DO stabile entro circa dal set point.
Manutenzione ed espansione. Prima del retrofit, modificare una variabile richiedeva la configurazione su entrambi i lati e un breve fermo per il download; dopo, l’impianto supporta il download online globale esente da urti, e la manutenzione è considerevolmente più semplice.
Energia. Dopo il retrofit, il consumo energetico complessivo delle soffianti è calato del 12%, e il consumo di reagenti di dosaggio è calato dell’8%.
Un modello decisionale quantitativo
La scelta tra DCS e PLC non dovrebbe ridursi a una preferenza soggettiva: può essere valutata direttamente sui parametri di progetto. Si definisca un indice di selezione :
dove ciascun parametro è definito come segue:
- : quota di I/O analogico (assegnare 1 se superiore al 30%, altrimenti 0).
- : numero di anelli PID complessi/a cascata/disaccoppiati (assegnare 1 se superiore a 30 anelli, altrimenti 0).
- : necessità di coerenza globale dei dati e di modifica online esente da urti (assegnare 1 per un requisito forte, 0 per nessuno).
- : costo di un’interruzione della produzione continua (assegnare 1 se le perdite da fermo impianto sono molto elevate, 0 se il fermo è tollerabile).
- : proporzione di apparecchiature skid OEM indipendenti di terze parti (assegnare 1 se la quota di skid supera il 50%, altrimenti 0).
- : coefficienti di ponderazione (valori consigliati: ).
Regola decisionale:
- Se : si raccomanda con forza un sistema DCS.
- Se : si raccomanda con forza un’architettura PLC in rete + SCADA.
- Se : si raccomanda un sistema di controllo ibrido (Hybrid DCS/PAC).
Costo totale di possesso
Il costo totale di possesso (TCO) combina la spesa in conto capitale (CAPEX) e la spesa operativa (OPEX):
Come evolve l’equilibrio dei costi. All’acquisto iniziale, una soluzione PLC+SCADA presenta costi di hardware e licenze software tipicamente inferiori del 30-50% rispetto a un DCS, e questo vantaggio in termini di CAPEX è particolarmente marcato per i progetti di piccole-medie dimensioni. Durante l’ingegnerizzazione e la messa in servizio, per processi complessi a forte intensità analogica come lo ZLD, il database globale e la libreria di algoritmi nativa di un DCS possono ridurre il tempo di messa in servizio in campo di circa il 40%, abbattendo il costo del lavoro ingegneristico. Nell’arco di una vita operativa di 10-15 anni, il download online esente da urti del DCS, l’isolamento dei guasti a livello di canale, la retrocompatibilità fluida e la capacità di ottimizzazione di processo (risparmio energetico, riduzione dei consumi) tagliano nettamente le perdite da fermo impianto e i costi di O&M — e nella pratica, il costo totale di possesso di un DCS scende tipicamente al di sotto di quello di un sistema PLC che richiede riconfigurazioni frequenti attorno ai 5-7 anni.
Conclusione
Nell’ampio panorama dell’automazione del trattamento delle acque, DCS e PLC non sono tanto concorrenti quanto due architetture radicate in patrimoni tecnici diversi, ciascuna capace di un lavoro che l’altra non può sostituire:
Il punto di forza centrale del PLC è l’efficienza della logica discreta, il determinismo temporale e l’agilità modulare. Nell’approvvigionamento idrico municipale e nella fognatura, nelle sottostazioni di impianti di trattamento reflui e negli skid ultrapuri autonomi, un’architettura PLC-più-SCADA è la scelta più conveniente e più flessibile da implementare.
Il punto di forza centrale del DCS è la continuità del controllo di processo, la coerenza globale dei dati e la tolleranza ai guasti ad alta disponibilità. Nelle acque reflue industriali a scarico liquido zero, nell’evaporazione-cristallizzazione e in altri processi termici e chimici complessi, il DCS è lo strumento che mantiene un intero impianto in funzione in modo sicuro, stabile e continuo.
Per i futuri progetti di automazione del trattamento delle acque, la scelta del sistema dovrebbe mettere da parte qualsiasi pregiudizio verso un’etichetta hardware particolare, guardare invece alla natura fisica e chimica del processo stesso, e trovare il miglior equilibrio tra usabilità ingegneristica, manutenibilità, aggiornabilità futura e costo totale di possesso.
Ulteriori letture
- International Society of Automation, ISA-18.2 — Management of Alarm Systems for the Process Industries — il riferimento normativo per la registrazione della sequenza degli eventi e le pratiche di gestione degli allarmi discusse sopra.
- International Electrotechnical Commission, IEC 61131-3 — Programmable Controllers, Part 3: Programming Languages — lo standard di riferimento per la programmazione PLC in ladder diagram e structured text.
- International Electrotechnical Commission, IEC 61508 — Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems — il riferimento fondamentale per le considerazioni sugli interblocchi di sicurezza e sul SIL nelle applicazioni di dosaggio e interblocco ad alto rischio.
- International Society of Automation, ISA-95 — Enterprise-Control System Integration — il quadro normativo di riferimento per l’architettura dei dati tra i sistemi di controllo di impianto e i sistemi aziendali.