Sistemi di controllo distribuito

Transcript

1 Sistemi di controllo distribuito Ing. Massimiliano Veronesi 1 INTRODUZIONE I CONTROLLORI I SUPERVISORI I PACCHETTI SUPERIORI Ing. Massimiliano VERONESI Sistemi di controllo distribuito Pagina 1 di 17

2 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. ERP/EDP MES/PIMS Supervisione Controllo di base SCADA PLC / PID DCS Misura e comando 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

3 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 (schede di I/O analogici o digitali) Acquisizione / comando (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

4 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

5 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

6 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

7 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

8 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

9 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. HIS1 Eng HIS2 HIS3 L2SW L2SW FCS-1 FCS-2 Vnet/IP bus1 Vnet/IP bus2 FCS 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

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

11 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

12 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

13 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 OPC- Client 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

14 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 Exaquantum/Explorer User PC User PC User PC User PC Intranet Local Area Network Role Based View OLE DB, ODBC, etc Administration Tools Long-term Archive External Data: ERP, LIMS, etc Real Time Database PCS Interface Historian Exaquantum/PIMS (Server) Exaquantum/PIMS (Server) OPC Servers Exaquantum/PIMS (Server) 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

15 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

16 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

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