Sistemi di controllo distribuito - Ingegneria elettrica ed elettronica

Sistemi di controllo distribuito
Ing. Massimiliano Veronesi
1
INTRODUZIONE ................................................................................................................................ 2
2
I CONTROLLORI ............................................................................................................................... 4
3
I SUPERVISORI .................................................................................................................................. 9
4
I PACCHETTI SUPERIORI............................................................................................................. 13
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 1 di 17
1
Introduzione
Nell’ambito dell’automazione industriale, i sistemi di controllo distribuito (DCS)
rappresentano la soluzione più adottata per i grandi impianti continui (raffinerie, centrali di
produzione energia, cartiere, vetrerie, impianti chimici etc.). Essi svolgono in modo
integrato entrambe le funzioni normalmente implementate sui PLC (Programmable Logic
Computer) e sugli SCADA (Supervision Control And Data Acquisition); per questo motivo si
possono collocare come rappresentato in figura 1 nell’ambito della piramide CIM
(Computer Integrated Manifacturing).
Gest.
Aziend.
Pian. Prod.
Supervisione
ERP/EDP
MES/PIMS
SCADA
DCS
Controllo di base
Misura e comando
PLC / PID
Sensori e
attuatori
Fig. 1 – Collocazione dei DCS nell’ambito della piramide dell’automazione industriale
L’architettura tipica di un sistema di controllo distribuito è rappresentata in figura 2.
Partendo dal basso si possono trovare le interfacce verso il campo, costituite dalle
opportune schede elettroniche di acquisizione (ingressi) e comando (uscite). A questo
livello stanno anche le interfacce di comunicazione per i più comuni “bus di campo”,
attraverso i quali vengono scambiate informazioni con i trasmettitori e gli attuatori che
supportano lo stesso tipo di protocollo.
Attraverso il Bus I/O i valori di ingressi ed uscite vengono veicolati ai controllori, che si
fanno carico di processarli in base alle strategie di regolazione e alle logiche progettate per
la specifica applicazione. Il software viene sviluppato attraverso l’implementazione di
“blocchi funzione” che vanno così a costituire il cosiddetto “Database di sistema”. Ognuno
di essi viene etichettato con un nome univocamente definito, comunemente detto Tag: si
usa pertanto assimilare ciascun record del database al relativo tag ed i suoi campi alle
diverse variabili utilizzate nel blocco funzione, normalmente chiamate “item”. Ad esempio,
un regolatore PID rappresenta normalmente un tag del database ed i suoi item sono la
variabile di processo, il setpoint, la variabile di controllo, le soglie di allarme, i parametri
proporzionale, integrale e derivativo etc.
Al di sopra dei controllori stanno i supervisori, implementati oramai in normali
workstation gestite da sistemi operativi disponibili in commercio. È proprio accedendo ai
tag e agli item del database che essi svolgono la loro funzione di interfaccia per l’operatore
di sala controllo, costituita da numerose videate attraverso le quali viene sviluppata una
rappresentazione grafica dell’impianto e del processo. Ed è proprio qui che sta la chiave
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 2 di 17
della differenza tra un DCS e un sistema PLC-Scada: mentre infatti il PLC e lo Scada
rimangono due sistemi separati, ciascuno facente uso di proprie variabili e strutture dati,
che si scambiano dati attraverso un opportuno driver di comunicazione (facente uso di
protocollo proprietario o meno), nel caso del DCS il database, unico, è per l’appunto
condiviso e distribuito tra controllori e supervisori, ciascuno dei quali si fa carico dei propri
compiti di elaborazione.
Al di sopra dei supervisori trovano posto i numerosi pacchetti di ottimizzazione,
monitoraggio delle prestazioni e gestione della strumentazione e dei macchinari in campo,
che sempre più entrano a far parte dello scopo di fornitura di un sistema di controllo
distribuito. Queste funzionalità vengono effettuate da normali personal computers che
tipicamente possono anche essere connessi alla normale rete aziendale (o di
stabilimento).
Monitoraggio remoto
Integrazione
informazioni
Gestione
strumentazione
Rete aziendale
Supervisione
Ottimizzazione
Mondo
esterno
Database di sistema
Rete di sistema
Controllo
(schede a microprocessore)
Contr.avanzato
(MPC, FLC)
Bus I/O
Acquisizione / comando
Acquisizione / comando
(schede di I/O analogici o digitali)
(Schede di comunicazione)
Bus di campo
Fig. 2 – Architettura di un sistema di controllo distribuito
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 3 di 17
2
I controllori
Le stazioni di controllo sono costituite dai controllori e da tutto l’hardware necessario
per interfacciarsi con la strumentazione in campo (trasmettitori e attuatori). Le schede di
Input/Output si classificano normalmente in:
- ingressi analogici multiplexati (generalmente 8 o 16 per scheda), quali segnali in
corrente (0/4-20 mA), in tensione (in genere fino a 20 Vdc) o ingressi diretti da
termocoppie o termoresistenze
- uscite analogiche (generalmente 8 o 16 per scheda), tipicamente 4-20 mA
- ingressi digitali (generalmente 16 o 32 per scheda), costituiti ciascuno da un circuito
aperto attraverso il quale non passa corrente finché appunto non viene chiuso
attraverso i due morsetti di interfaccia con l’esterno
- uscite digitali (generalmente 16 o 32 per scheda), costituiti ciascuno da un circuito
aperto attraverso il quale non passa corrente finché appunto non viene chiuso
attraverso il comando che gli arriva dal controllore. Si possono usare anche uscite a
relè ma generalmente si preferisce appoggiare il contatto su relè esterni (accorpati su
ulteriori “Terminal Board” dalle quali risulta più agevole sostituirli in caso di guasto).
L’accuratezza sulla risoluzione dei segnali è dell’ordine dei μA (o mV nel caso di ingressi
in tensione) mentre i tempi di scansione dei multiplexer sono dell’ordine dei msec.
Generalmente le schede di I/O sono composte da un corpo di elettronica da installare
in uno slot libero del rack e da un frontalino intercambiabile cui collegare direttamente i
segnali oppure un cavo di interfacciamento con delle morsettiere esterne di appoggio (fig.
3); quest’ultima soluzione rende ovviamente meno laboriosa l’eventuale sostituzione della
scheda in caso di guasto.
Fig. 3 – Schede di I/O
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 4 di 17
Accanto alle schede di ingressi o uscite possono essere impiegate anche schede di
comunicazione compatibili con bus di campo più impiegati nell’automazione di processo;
tra i più diffusi si possono citare Modbus (RTU o TCP), Foundation Fieldbus, Profibus,
DeviceNet. Opportune restrizioni limitano il numero massimo di schede di comunicazione
che possono essere gestite da un singolo controllore.
Tutte le schede (di I/O o comunicazione) possono venire ridondate in modo
relativamente agevole, in modo da non perderne la funzionalità in caso di guasto.
Generalmente i DCS gestiscono automaticamente gli indirizzamenti, in modo da non
costringere chi fa l’ingegneria dell’applicazione a sviluppare codice addizionale.
La configurazione delle schede di I/O si limita in genere all’impostazione del range (per
gli ingressi analogici) e all’assegnazione (facoltativa) di un identificativo a ciascuno dei
segnali, che possa essere utilizzato come riferimento nella stesura del software applicativo.
Un po’ più complessa la configurazione delle schede di comunicazione, che richiede di
specificare i parametri relativi al protocollo utilizzato e a definire il significato (range,
etichetta, formato) di tutti i registri che vengono scambiati.
I racks di I/O, tipicamente dotati di doppio alimentatore, sono normalmente installati
nello stesso cabinet del controllore, con il quale comunicano attraverso schede e bus
generalmente ridondati a supporto di un protocollo proprietario. Tuttavia può essere
necessario o economicamente conveniente avvicinare uno o più rack a sensori ed
attuatori. Per questo motivo i DCS consentono anche di remotare l’I/O attraverso un bus
tipicamente più lento del precedente ma che consente di coprire distanze maggiori e di
essere veicolato anche attraverso cavi in fibra ottica (si veda la fig. 4).
Opportune restrizioni limitano il numero di rack di I/O gestibili da un singolo controllore
e quelli installabili sullo stesso ramo di bus I/O, nonché il numero stesso di rami utilizzabili
dal medesimo controllore.
Fig. 4 – Collegamenti tra controllori e rack I/O
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 5 di 17
I controllori dei DCS sono costituiti da schede sulle quali vengono montati
microprocessori molto potenti ed affidabili affiancati da una notevole quantità di memoria
(ad es. 32 MB) per supportare l’esecuzione del software applicativo in carico su quella
CPU. Il rack sul quale sono installate le CPU (normalmente due, per motivi di ridondanza)
sono dotati altresì di doppio alimentatore e su di essi possono già essere installate delle
schede di I/O.
Fig. 5 – Rack CPU e meccanismo di ridondanza
I DCS assicurano affidabili meccanismi di gestione della ridondanza tra le CPU in modo
da garantire la continuità nell’azione di controllo del processo anche in caso di guasto di
una delle due unità di elaborazione e della sua conseguente sostituzione a caldo. Tra le
tecniche utilizzate si distingue in particolare quella (in uso anche sui PLC certificati per
applicazioni di Emergency Shut-Down) che fa uso di due microchip per ciascuna scheda
CPU (si veda la figura 5): l’eventuale discrepanza tra i risultati da esse elaborati, rilevata
attraverso tecniche di watch-dog ed ECC (Error Correction Code), fa partire un ciclo di
diagnostica al termine del quale il sistema sceglie se mantenere il controllo o cederlo alla
scheda gemella; quest’ultima comunque sta sempre elaborando le stesse logiche di
regolazione e comando, in modo che la commutazione sia “bumpless” ovvero non
comporti attese né variazioni per il processo sotto controllo. Nel caso si renda necessario
sostituire una delle CPU, il sistema copia automaticamente il programma eseguibile su
quella nuova che viene inserita vergine.
L’ingegneria delle stazioni di controllo consiste nella sua configurazione e nello sviluppo
del software applicativo. Sono normalmente disponibili vari formalismi di tipo grafico che
rendono questo lavoro particolarmente rapido ed alla portata di personale non
necessariamente super-specializzato. Tipicamente si possono riscontrare le seguenti
modalità di programmazione:
Control Drawing. Si tratta di un ambiente di tipo CAD ove comporre le strategie di
controllo collegando tra loro opportuni blocchi funzione, attinti da una ricca libreria. È
questo il caso di tutte le architetture di regolazione per applicazioni di controllo PID
(singolo, di rapporto, in cascata etc..) e in generale di ogni elaborazione matematica dei
segnali analogici necessaria. Oltre a numerosi operatori aritmetici e relazionali
(comparatori, selettori) sono disponibili anche blocchi di tipo “funzione di trasferimento”
quali Lag, LeadLag, Delay; infine per le computazioni non riconducibili a funzioni standard,
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 6 di 17
sono disponibili blocchi di calcolo vuoti, nei quali poter scrivere il codice necessario per
svolgere la funzione desiderata. Un formalismo del genere (si veda la fig. 6 per un
semplice esempio) consente di sviluppare il software applicativo in un linguaggio molto
vicino a quello utilizzato dai “processisti” per progettare il funzionamento dell’impanto.
Fig. 6 – Esempio di Control Drawing
Logic Chart. Si tratta di un ambiente di tipo CAD nel quale sviluppare tutte le logiche
binarie, ovvero le reti di tipo combinatorio che elaborano informazioni di tipo vero/falso e
restituiscono risultati dello stesso tipo per il comando di motori ed in generale attuatori
pilotati da segnali On/Off. Oltre alle normali porte logiche (And, Or, Not, Xor) sono
disponibili altri operatori quali timer, counter, fronti di salita o di discesa, filp-flop, che
rendono particolarmente agevole realizzare le funzionalità richieste (si veda la figura 7 per
un esempio rappresentativo).
Fig. 7 – Esempio di Logic Chart
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 7 di 17
Per la programmazione di reti logiche sono disponibili anche altri formalismi quali il
ladder diagram (di provenienza dal mondo PLC) oppure la True/False Table.
Sia le logiche di regolazione che quelle di tipo combinatorio vengono normalmente
eseguite in modo iterativo dalle CPU, con un tempo di ciclo (comunque non inferiore a
quello minimo) che è bene configurare in modo tale da non far eccedere mai il carico di
lavoro rispetto a quello sostenibile dai microprocessori.
Tuttavia può essere necessario che il controllore esegua routine di tipo sequenziale
ovvero con un inizio, determinato da una condizione o da una azione dell’operatore, una
serie di operazioni consecutive da eseguire una sola volta fino ad una fine, corrispondente
alla conclusione della sequenza. Per progettare questo tipo di programmi vengono
normalmente usati formalismi di tipo SFC (Sequencial Functions Chart) del tipo riportato in
figura 8. In ciascun blocco, o fase, viene scritto il codice relativo alle operazioni da
compiere e la transizione tra un blocco e il successivo è espressa attraverso una
condizione logica da soddisfare. I linguaggi utilizzati si ispirano generalmente ai più
impiegati standard di programmazione (C, Pascal, …) ma prevedono sempre qualche
variante proprietaria per accedere ai record (e ai relativi items) del DataBase. Una nota
modalità è quella che fa uso della sintassi TagName.ItemName (come ad esempio
TIC100.PV) per riferirsi all’item ItemName del tag TagName. Ogni costruttore dispone poi
un suo personale set di istruzioni.
Fig. 8 – Esempio di SFC
È importante sottolineare come per un vero DCS ciascun blocco funzione, abbia esso
una funzionalità predefinita solo configurabile (es. PID) o invece una funzionalità realizzata
dal progettista attraverso un opportuno linguaggio (es. logic chart o SFC), rappresenti un
solo record (Tag) del database da distribuire sui vari controllori. Ciascuna stazione di
controllo può farsi carico di qualche migliaia di tag (che quindi non sono gli I/O) ed il
sistema nel suo complesso (decine o anche centinaia di controllori) può arrivare anche a
centinaia di migliaia di Tag.
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 8 di 17
3
I supervisori
Le stazioni di controllo, come accade anche per i PLC, sono cieche. È necessario
pertanto che si interfaccino con qualche tipo di visualizzatore che consenta di monitorare i
dati e impostare i parametri utilizzati nel software applicativo. Mentre però per i PLC sono
disponibili da semplici pannelli operatore (per applicazioni bordo-macchina) fino ai sistemi
SCADA, per il DCS le stazioni operatore sono parte integrante dell’architettura, essendo
esse stesse nodi della rete di sistema come lo sono le stazioni di controllo.
A secondo dei costruttori, le reti di sistema si presentano con modalità di
comunicazione differenti e protocolli più o meno proprietari. Sono ancora disponibili
affidabili reti gestite in Token-ring (IEEE 802.4) ma le soluzioni attualmente più avanzate
si basano su Ethernet Industriale (IEEE 802.3) e supportano almeno un traffico a 100
Mbps; in alcuni casi opportuni accorgimenti proprietari consentono di arrivare fino a 1
Gbps. In questi casi la topologia di rete diventa a stella e si avvale di Switch o Router
industriali in grado di risolvere i conflitti legati alle collisioni dei pacchetti.
Poiché l’affidabilità della comunicazione rappresenta un requisito fondamentale anche il
bus di sistema viene generalmente ridondato. Tenendo presente come entrambi i bus
debbano essere utilizzabili da entrambi i controllori, si capisce come la configurazione
necessaria per tre sole stazioni di controllo e tre stazioni operatore debba essere quella
illustrata in figura 9.
HIS2
HIS1
HIS3
Eng
L2SW
L2SW
FCSFCS-1
FCSFCS-2
Vnet/IP bus1
Vnet/IP bus2
FCSFCS-3 + I/O racks
Fig. 9 – Configurazione con 3 FCS + 3 HIS
Un ulteriore accorgimento rivolto a massimizzare la disponibilità del sistema è quello di
dedicare uno dei due bus (bus1) solamente alla comunicazione tra controllori e tra
controllori e supervisori usando l’altro (bus2) per lo scambio dati con gli altri sistemi e
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 9 di 17
dispositivi dotati di interfaccia Ethernet (PLC, altri supervisori, videocamere, RTU); una
parte della banda sul bus2 viene comunque lasciata libera come backup del bus1: in caso
di perdita di quest’ultimo il traffico di rete viene così dirottato sul secondo senza causare
perdite di dati.
Le stazioni operatore forniscono tutte le funzionalità necessarie per la conduzione
dell’impianto, attraverso l’interfaccia software sviluppata per la specifica applicazione. Dalla
fine degli anni novanta si tratta ormai di normali workstation disponibili in commercio,
gestite da sistemi operativi di uso comune; l’unico componente in più da installare è
tipicamente la scheda di comunicazione per la rete del DCS, fornita appunto insieme a
quest’ultimo. La ridondanza del sistema termina generalmente qui: non avendo molto
senso pretendere di utilizzare PC con hardware ridondato si preferisce non ridondare
nemmeno la scheda di comunicazione ed usare invece almeno due stazioni operatore.
Le funzionalità operative e di monitoraggio sono tipicamente le seguenti:
impostazione e comando dei tag attraverso l’interfaccia software (“Faceplate”) che
il sistema associa a ciascuno di essi sin dalla sua creazione nel database. Un
esempio rappresentativo è quello dei blocchi di tipo PID che sono provvisti di
numerosi parametri operativi, quali soglie di allarme, limitatori, coefficienti delle
azioni proporzionale, integrale e derivativa. Si veda la figura 10.
Monitoraggio e controllo delle varie aree di impianto, attraverso le interfacce
grafiche (sinottici) appositamente sviluppate per ciascuna. In questo ambito ci si
sforza di realizzare delle rappresentazioni il più possibile fedeli dell’impianto sotto
controllo cercando di perseguire l’ergonomia e l’usabilità del sistema interattivo.
Non mancano mai, dunque, serbatoi, valvole, pompe, tubature variamente
animate in funzione dello stato di funzionamento o delle condizioni di operative.
Monitoraggio e gestione degli allarmi, relativi al superamento di soglie preimpostate (tra i parametri operativi dei Tag) o a condizioni legate a logiche
combinatorie (ad esempio una pompa in moto con la valvola a valle chiusa)
Auto-Diagnostica del sistema stesso, attraverso una pagina allarmi dedicata alle
eventuali avarie hardware e alle pagine grafiche che consentono di visualizzare il
software applicativo in funzione, nello stesso formalismo utilizzato dagli
sviluppatori ma con opportune animazioni rivolte a facilitarne l’interpretazione (ad
esempio un logic chart si presenta con i rami veri in rosso e quelli falsi in verde;
una SFC con il blocco di istruzioni attualmente attivo colorato diversamente etc..)
Visualizzazione ed archiviazione degli andamenti delle variabili (generalmente
legate agli ingressi di tipo analogico) delle quali si vuole mantenere memoria. A
questo scopo vengono configurate apposite pagine di trend a ciascuna delle quali
è possibile assegnare un periodo di archiviazione dei dati sul disco fisso della
stazione operatore.
Produzione di Report di produzione di tipo periodico (ad esempio per le
totalizzazioni giornaliere) o ad evento (per esempio le totalizzazioni relative ai
batch di produzione); le informazioni, estratte come sempre dagli item dei tag e
confezionate in opportuni formati, possono essere stampate direttamente oppure
anche archiviate su file.
Gestione degli accessi al sistema e dei rispettivi privilegi operativi, attraverso
semplici funzionalità di Login/Logout con UserName e Password
Archiviazione delle azioni eseguite e degli eventi anche non legati a situazioni di
allarme, allo scopo di mantenere la traccia degli accadimenti.
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 10 di 17
Una barra di stato, generalmente superiore, mette a disposizione dell’operatore tutti i
comandi fondamentali, indipendentemente dalla finestra grafica in cui si trovi. Infine una
particolare tastiera operatore, fornita dal costruttore del DCS, rende particolarmente
agevole effettuare le tipiche manovre della conduzione, anche in assenza di mouse.
Una singola stazione operatore può gestire anche molte centinaia di pagine grafiche e
su ciascuna di esse possono trovarsi riferimenti anche a molte decine di variabili
(Tag.Item); il sistema deve essere in grado di garantire il richiamo delle interfacce e il
refresh dei dati entro un tempo limite massimo che in genere non può superare 1 sec.
Fig. 10 – Faceplate e pagina di tuning (PID)
La configurazione delle funzionalità operative viene fatta nello stesso ambiente di
progettazione che contiene anche i sorgenti delle funzioni di controllo. La disponibilità del
database condiviso consente di associare in modo immediato agli item dei tag oggetti
grafici quali barre verticali, campi numerici o stringhe, bottoni etc. con le relative
condizioni di animazione (cambio di dimensione, posizione o colore, azione sul “click” etc.).
Inoltre una nutrita libreria di oggetti grafici rende particolarmente rapido costruire
l’interfaccia più adatta alla specifica applicazione; tale libreria può anche crescere
popolandosi di nuovi oggetti creati dagli sviluppatori e ri-usabili attraverso nuove istanze.
Una efficace panoramica delle funzionalità di supervisione è rappresentata dalla figura
11. Sotto l’interfaccia di controllo per una colonna di distillazione sono riportate alcune
pagine tipiche come quella di soli strumenti, quella di trend, quella degli allarmi, quelle di
diagnostica del software applicativo (control drawing e logic chart).
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 11 di 17
Fig. 11 – Esempi di interfaccia operatore
La stazione di ingegneria può essere una qualunque delle stazioni operatore, pur di
istallare su di essa anche i pacchetti che consentono la creazione dei file sorgenti, la loro
compilazione ed infine il loro scaricamento sulle stazioni (di controllo e operatore) che
devono farsi carico delle funzionalità previste.
Tuttavia i softwaristi non devono necessariamente disporre di tutto l’hardware collegato
per “debugare” la loro applicazione. I migliori sistemi dispongono infatti di una modalità di
test che consente alla stazione di ingegneria di simulare la presenza di ciascuna stazione
di controllo facendosi carico delle sue funzionalità e simulando anche il comportamento del
processo sotto controllo attraverso semplici guadagni unitari (default) oppure inserendo
negli anelli altri opportuni blocchi funzione (Lag, Delay etc..). In questo modo gli
sviluppatori possono verificare la correttezza di tutto il software applicativo prima di
giungere al commissioning del sistema, rendendo così questa attività più agevole e rapida.
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 12 di 17
4
I pacchetti superiori
Pur non facendo parte del sistema di controllo in senso stretto, entrano generalmente a
far parte dello scopo di fornitura anche altri pacchetti a corredo, ai quali vengono
demandate alcune funzionalità specifiche.
L’interfacciamento tra questi pacchetti e il DCS avviene attraverso il formato OPC (Ole
for Process Control), oramai stadand de facto nell’ambito dell’automazione industriale da
quando le funzionalità di supervisione vengono implementate su workstations gestite da
noti sistemi operativi commerciali. Via OPC vengono scambiati dati di diversa natura tra
applicazioni diverse che possono accedere alla stessa rete ethernet. In particolare sono
disponibili diversi formati a secondo che il dato sia di tipo numerico (OPC DA utilizzato per
i dati di processo) o stringa (OPC A&E, utilizzato per allarmi ed eventi); infine esiste anche
la condivisione via OPC di dati non real-time ma già storicizzati, attraverso l’OPC HDA ed
HA&E. In ogni caso il flusso delle informazioni è sempre quello che prevede il
funzionamento di un OPC-Server (eventualmente ridondato) in grado di convertire in
formato OPC i dati disponibili sulle stazioni operatore (e quindi provvisto dal fornitore del
DCS); i pacchetti superiori non devono allora far altro che integrare la funzionalità di OPCClient in modo da poter attingere dal server (in lettura e/o scrittura) i dati di interesse per
l’espletamento della loro funzione. La figura 12 illustra il concetto.
Fig. 12 – Architettura Client-Server della comunicazione via OPC
Utilizzando i formati OPC è possibile dunque realizzare semplici applicazioni (ad
esempio in VisualBasic) per accedere ai dati del DCS; lo standard prevede che ad ognuno
venga associato il Time-Stamp e un Quality-Code indicativo della bontà del valore
conseguente al processo di comunicazione. Talvolta il fornitore del DCS provvede librerie
aggiuntive di funzioni utili per poter prelevare i dati dal proprio sistema in modo più
agevole (scrivendo meno codice) ed efficace.
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 13 di 17
Queste funzionalità di basso livello vengono normalmente integrate nei pacchetti
superiori esonerando così chi deve sviluppare l’applicazione dal preoccuparsi della
comunicazione OPC. Le funzionalità tipiche sono le seguenti.
Storicizzazione dati.
Pur essendo ciascuna stazione operatore in grado di archiviare sul proprio disco fisso
parte (o tutti, in base alla configurazione) degli andamenti (trend) delle variabili, non è
opportuno in genere caricare una workstation di sala controllo della memoria storica
dell’intero impianto; inoltre le funzionalità di interrogazione (data retrieval) dell’intefaccia
di supervisione sono in genere piuttosto limitate.
Per questo motivo si sceglie di sfruttare la comunicazione via OPC per popolare un
nuovo database (generalmente basato su tecnologie informatiche standard di mercato)
che poi può essere interrogato liberamente dai suoi client in rete, senza bisogno di essere
necessariamente in sala controllo, né tanto meno di utilizzare le rete di sistema. Questi
database diventano così dei veri e propri centri per la raccolta dei dati e la loro
conversione in informazioni utili da smistare nei veri uffici (si parla infatti di Plant
Informations Management Systems).
Accanto alle potenti funzionalità di storicizzazione e compressione dei dati, questi
pacchetti sono in grado di fornire informazioni aggregate (quali medie, varianze, massimi,
minimi) e anche elaborazioni in linea dei dati attraverso nuove variabili calcolate utilizzabili
per effettuare bilanci di massa e/o energia, valutazione del costo delle materie prime,
rendimento delle varie aree di impianto. L’architettura funzionale di un tipico Plant
Informations Management System è illustrata in figura 13.
Exaquantum/Explorer
User PC
Exaquantum/Explorer
User PC
User PC
User PC
Local Area Network
Intranet
Role Based View
OLE DB,
ODBC, etc
Long-term
Archive
Administration Tools
Real Time Database
Historian
External Data:
ERP,
LIMS, etc
PCS Interface
Exaquantum/PIMS
(Server)
Exaquantum/PIMS
(Server)
Exaquantum/PIMS
(Server)
OPC Servers
PCS, DCS, PLCs etc
TIC1-2
Fig. 13 – Architettura di un tipico Plant Informations Management System
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 14 di 17
Gestione allarmi.
Pur essendo ciascuna stazione operatore provvista delle sue pagine allarmi
(tipicamente suddivise tra allarmi di processo e di sistema), è in genere opportuno
disporre di funzionalità aggiuntive che consentano da un lato una migliore interazione da
parte dell’operatore con l’evento di allarme, dall’altro una elaborazione statistica
dell’archivio di eventi ed allarmi.
I requisiti da parte degli utenti sono che ciascun allarme sia:
rilevante: non relativo a condizioni ininfluenti e quindi ignorabili
unico: relativo ad informazioni non già riportate da un altro allarme
non fatale: tale da segnalare una condizione non già irrimediabile
comprensibile: il messaggio deve essere preciso e quanto più diagnostico possibile
prognostico: il messaggio deve indicare la contromisura
associato a una priorità, in modo da consentire un ordinamento non dipendente
solo dal TimeStamp dell’evento
I pacchetti di gestione allarmi devono pertanto consentire di organizzare gli allarmi in
interfacce che consentano agli operatori una chiara interpretazione dell’evento. A questo
scopo sono disponibili funzionalità per:
descrizione aggiuntiva da allegare all’evento in modo da dare una informazione
completa, associandovi indicazioni di tipo prognostico
ordinamento degli eventi secondo varie chiavi
pre-filtraggi atti a collocare il messaggio arrivato automaticamente nella “cartella”
più opportuna (inclusa quella degli allarmi poco urgenti)
mascheramento delle ripetizioni dello stesso allarme
Questi pacchetti consentono in genere anche l’acquisizione dei messaggi via OPC A&E,
costituendo così un utile strumento per la supervisione del DCS e degli altri (sotto)sistemi.
Un’altra funzionalità di questo tipo di Tools è quella di analizzare quantitativamente gli
allarmi e gli eventi registrati dal sistema di controllo. Lo scopo è quello di fornire a chi
esercisce gli impianti di produzione un quadro chiaro delle situazioni tipiche alle quali gli
operatori di sala controllo si trovano a dover far fronte. Un’analisi di questo tipo può
essere infatti di grande aiuto per individuare inefficienze, malfunzionamenti ripetuti o
errori di progettazione rimediando ai quali è possibile incrementare il rendimento
dell’impianto e la qualità dei prodotti.
Il pacchetto si basa in genere sull’analisi off-line degli Operation Log-files salvati dal
DCS sulle stazioni operatore. Questi files (di testo) vengono letti (su comando manuale
oppure periodicamente) ed il risultato viene presentato in forme grafiche facili da
interpretare. Si riporta a titolo esemplificativo quanto illustrato in figura 14.
Il grafico a barre rappresenta il diagramma eventi (sopra, in rosso) vs. azioni (sotto, in
blu) costituendo così un utile strumento per analizzare le contromosse effettuate a fronte
delle situazioni intervenute sull’impianto. Un’area rossa positiva dovrebbe essere infatti
sfasata in anticipo di poco rispetto ad una blu negativa; se quest’ultima è molto ampia
allora significa che le azioni da fare a fronte degli eventi sono state piuttosto complesse;
se invece l’area negativa è sfasata in anticipo rispetto a quella positiva allora significa che
sono state le azioni manuali degli operatori a generare allarmi ed anomalie successive.
Posizionandosi con il cursore in corrispondenza dell’ascissa desiderata, è possibile
individuare l’evento corrispondente visualizzando sia quando che quante volte si è
verificato nelle finestre inferiori. Sono riportati parecchi attributi, come data e ora,
tipologia, sorgente, etc.
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 15 di 17
Il diagramma a torta rappresenta invece la ripartizione tra le diverse tipologie di
evento. È possibile visualizzarla per categorie, per priorità, per sorgente (stazione di
controllo) etc., e “cliccando” su un particolare settore della torta si passa ad analizzare
solo i record (allarmi / eventi) di quel particolare sotto-gruppo. In questo modo è
immediato disporre di informazioni riassuntive in merito alle categorie di eventi (allarmi,
alarm recovery, messaggi, operazioni) alle tipologie (di allarmi intervenuti, di operazioni
effettuate, di stato dei tag, etc.). È possibile infine effettuare filtri in modo da
includere/escludere nell’analisi solo gli eventi desiderati. I risultati possono essere
facilmente esportati in Excel in formato CSV.
Fig. 14 – Funzionalità di un tipico pacchetto di gestione allarmi
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 16 di 17
Gestione della strumentazione in campo
Il pacchetti cosiddetti di “gestione degli Asset”, sempre più ritenuti una importante leva
per la competitività degli impianti di produzione, rappresentano i tool per estrarre e gestire
la notevole quantità di informazioni provenienti dalla strumentazione su bus di campo.
Essi sono tipicamente basati su un database commerciale che raccoglie i dati
provenienti dal DCS, veicolati attraverso il bus di sistema. Il loro scopo principale è quello
di costituire un database della strumentazione e dei dispositivi in campo mettendo a
disposizione numerose funzioni di esplorazione e diagnostica, quali:
• Visualizzazione on-line della strumentazione installata per tipologia di trasmettitore,
tipologia di bus di campo, nome del fornitore
• Verifica delle tipologie di guasto
• Configurazioni, tarature e calibrazioni degli strumenti
• Storicizzazione degli eventi e delle azioni (Audit Trail) per singolo strumento e per
area di impianto
• Comparazione della configurazione di più strumenti (funzionalità molto efficace in
caso di sostituzione di uno strumento con un altro presente a magazzino dalle
caratteristiche sconosciute)
• Programmazione del calendario delle attività di manutenzione periodica
• Manutenzione predittiva della strumentazione attraverso l’impostazione di soglie
sui contatori dei flags di allerta resi disponibili dallo strumento
Il Field Communication Server può interfacciarsi direttamente attraverso i protocolli
Hart (attraverso DCS o via seriale) e Foundation Fieldbus (attraverso DCS). Sono
supportate le modalità di interfacciamento FDT/DTM oppure EDDL. Ogni server può
interfacciarsi con un numero massimo di stazioni di controllo e può essere a sua volta
server (OPC A&E) verso i pacchetti di gestione allarmi, in modo da veicolare ivi i messaggi
provenienti dalla strumentazione in campo. I clients possono attingere informazioni da
server diversi, attraverso una commutazione manuale.
I pacchetti di Asset Management possono anche essere, limitatamente, impiegati per
archiviazione dati storici e routine di diagnostica avanzata, basate sul modelli dei
dispositivi (valvole, compressori, turbine) ricavati dalle leggi fisiche che governano il
processo incrociate con i dati rilevati. In tal caso, come concettualmente illustrato in fig.
15, è necessario implementare ulteriori routine di calcolo oppure importare (via OPC) i dati
elaborati dai pacchetti forniti dal costruttore del sotto-sistema.
Fig. 15 – Architettura di un pacchetto di Asset Management
Ing. Massimiliano VERONESI – Sistemi di controllo distribuito – Pagina 17 di 17