Molti impianti industriali sono controllati per mezzo di un sistema di controllo distribuito (Dcs, Distributed Control System). Come mostrato in Figura 1 esso è composto da un certo numero di unità di controllo connesse a differenti elementi: da un lato si deve interagire con il processo industriale attraverso dispositivi input/output collegati a sensori e attuatori, e dall’altro si devono connettere i sistemi di supervisione (Os, Operator Station) e altri sistemi di più alto livello quali ad esempio Mes (Manufacturing Execution System), Cmms (Computerized Maintenance Management System), e Erp (Enterprise Resource Planning). Durante la vita di un impianto è di solito necessario un rinnovamento dello stesso; quest’attività è comunemente chiamata revamping. Il revamping può coinvolgere il processo industriale, il sistema di controllo, l’interfaccia uomo-macchina ecc. In quest’articolo si è focalizzata l’attenzione sul revamping del sistema di controllo. Per portare a termine questo compito è necessario raccogliere più informazioni possibili dall’impianto e dal sistema di controllo in uso, e da questo costruire il nuovo Dcs con hardware e software che siano in grado di soddisfare i nuovi requisiti. L’idea di aiutare gli ingegneri di revamping con strumenti di traduzione, evitando lavoro manuale, non è nuova. Infatti, esistono casi di traduzione automatica o semiautomatica, come descritto nel paragrafo Soluzioni esistenti, ma purtroppo, questi strumenti sono stati progettati per casi specifici o considerano solo la traduzione del software di controllo. E inoltre, la migrazione della sola logica di controllo del Dcs non è sufficiente per ridurre effettivamente gli sforzi di revamping. Il principale obiettivo dell’approccio presentato in quest’articolo, invece, è di tradurre una configurazione completa (quindi hardware e software) usata nel vecchio Dcs verso una nuova configurazione completa (sempre hardware e software) per il nuovo Dcs, riducendo gli sforzi per il revamping, e il tempo di fermo-impianto o almeno il tempo totale di revamping.
Lo strumento di traduzione sviluppato garantisce la migrazione semiautomatica della configurazione hardware, del controllo analogico e digitale, dei tag, e degli allarmi, producendo l’applicazione di controllo per la nuova piattaforma. La traduzione garantisce la correttezza e la completezza (nessun segnale, connessione o funzione deve essere persa). Se, in una traduzione, uno di questi vincoli non è soddisfatto allora il tool segnala l’errore in modo da aiutare il successivo lavoro manuale degli esperti di revamping.
Motivi e scenari
In questo paragrafo sono analizzati tre possibili scenari e motivazioni per un revamping d’impianto. Il primo è il caso in cui il sistema di controllo è obsoleto, quindi non garantisce più i risultati attesi dall’impianto in termini di produzione e costi. Per esempio, questo può essere il caso di un sistema di controllo forzato a garantire all’azienda un crescente livello di servizi che possono essere distanti dalla missione originale, sia per quanto riguarda il controllo dell’impianto sia per il supporto agli operatori nel loro lavoro. I motivi possono essere i seguenti:
– prestazioni insufficienti dell’hardware del sistema di controllo (Cpu, memoria, periferiche ecc.);
– aumento dei costi di manutenzione;
– obsolescenza fisica del sistema e conseguente mancanza di pezzi di ricambio;
– difficoltà nel connettere il sistema con nuovi elementi. Per esempio, il sistema di controllo ora deve fornire informazioni di diagnostica, deve inoltre essere integrato con i sistemi Erp e deve, in generale, seguire il trend dell’It (Information Technology);
– difficoltà nell’adottare nuove tecnologie, come Internet, connessioni Tcp/Ip e così via.
Un secondo scenario riguarda il caso di cambiamenti nei requisiti esterni, i quali possono essere un’inaspettata ma importante ragione per modificare l’impianto. I riferimenti esterni possono venire, per esempio, dal mercato quando è richiesta maggiore o minore produzione; oppure, nuovi regolamenti ambientali che richiedono il rispetto di vincoli più stringenti. Di solito, le nuove caratteristiche possono essere rispettate ottimizzando il sistema. In questo caso, il revamping del sistema di controllo non è necessario, ma si tratta solo di aggiungere e modificare i programmi di controllo, oppure dei dispositivi di campo (sensori e attuatori). Il tool in questione non considera questi casi. Se, invece, i nuovi requisiti non possono essere risolti con semplici ottimizzazioni, allora i commenti del punto precedente rimangono validi, perché il sistema di controllo e/o il processo deve essere considerato obsoleto rispetto alle nuove specifiche. L’ultimo scenario considerato è il riutilizzo di soluzioni già implementate in precedenti impianti che sono un prezioso patrimonio dell’azienda. Di solito, questo know-how è sia patrimonio degli ingegneri sia dell’azienda la quale solitamente lo archivia in librerie contenenti soluzioni di controllo (proprie del sistema di controllo utilizzato). Un possibile scenario è, per esempio, quello d’impianti che raggiungono il loro limite di produzione, e si decide di costruire un impianto identico (o una parte aggiuntiva dello stesso) per incrementare la capacità produttiva. Anche se la struttura fisica e i componenti dell’impianto rimangono gli stessi, la strumentazione e il sistema di controllo potrebbe essere differente dall’originale. Ciò accade più spesso se l’impianto originale è abbastanza vecchio. Quindi, in questo caso la logica di controllo rimane la stessa, ma ovviamente l’implementazione su un differente sistema di controllo richiederà una, seppur lieve, migrazione. Un altro esempio è: quando una società d’ingegneria adotta un sistema di controllo per molti impianti, allora le cosiddette typical solution sono sviluppate per risolvere i soliti problemi. Per esempio una compagnia d’ingegneria che realizza applicazioni per power plant avrà delle librerie di soluzioni già pronte per il controllo di caldaie, turbine ecc. Queste soluzioni sono preziose perché sono testate e largamente accettate. Se la compagnia decide di adottare un differente sistema di controllo, allora tutte le librerie dovranno essere convertite al nuovo sistema. È evidente che anche queste attività possono fortemente beneficiare di uno strumento di conversione automatica di soluzioni preconfezionate in qualcosa d’equivalente (mantenendo le stesse funzionalità) in un nuovo sistema di controllo.