Revamping di sistemi di controllo Un nuovo approccio.

• 
• Tweet
• Pin It
• Condividi per email

Possibili problemi

Nel seguito sono elencati dei possibili problemi a cui va incontro chi si appresta a cambiare parte o tutto il sistema di controllo.
• Il primo problema è la complessità dell’impianto e del sistema di controllo. Infatti, la quantità di informazioni riguardanti tutti i differenti aspetti è enorme. In più, ci sono molti collegamenti/relazioni, visibili e non, e il numero di questi collegamenti/relazioni cresce proporzionalmente al numero d’elementi e al numero di aspetti considerati. Specialmente, ci sono collegamenti tra elementi che appartengono a differenti aspetti del sistema di controllo. Questi cosiddetti collegamenti possono essere stabiliti attraverso un nome, un indirizzo o utilizzando riferimenti dipendenti dal particolare sistema di controllo. Per esempio, un collegamento può essere quello fra la definizione hardware di un canale di I/O e il corrispondente suo utilizzo nella logica di controllo. Un altro esempio può essere quello dei tag, che in molti sistemi vengono usati per stabilire comunicazioni inter e intra-controllore oppure fra controllore e stazione operatore.
• Altri problemi vengono dal fatto che il sistema è vecchio e “proprietario” (nel caso di Dcs, in pratica, tutti). Più il sistema è vecchio, meno sarà compatibile con gli attuali standard sia per quanto riguarda l’hardware sia il software. Questa situazione aumenta gli sforzi perché richiede una più profonda fase di reingegnerizzazione considerando gli elementi non standard. Questo è il caso, per esempio, di: software non riutilizzabile, linguaggi non standard, protocolli di comunicazioni proprietari (sia per i fieldbus sia per le reti di comunicazione a livello superiore).
• Un altro caso difficile è quando una nuova tecnologia obbliga a reingegnerizzare la parte considerata. Per esempio la stazione operatore fatta con quadri sinottici, pulsanti, luci deve essere sostituita con workstation o personal computer.
• Documentazione non disponibile o vecchia e non aggiornata (sull’impianto, sul sistema di controllo e sui programmi) è anch’essa un problema. Nel caso di un tool software per il revamping, il non avere la configurazione in formato elettronico potrebbe rappresentare un ostacolo insormontabile.
Concludendo, il processo di revamping, sfortunatamente, non è mai un’attività semplice; richiede invece uno sforzo agli ingegneri per comprendere il comportamento della vecchia configurazione (hardware e/o software) per poi riprodurre lo stesso comportamento o il nuovo atteso sulla nuova piattaforma.

Soluzioni esistenti

Tralasciando il caso di traduttori solo di linguaggi, che si è visto non essere sufficienti per ridurre effettivamente il tempo e gli sforzi di revamping, nel passato ci sono stati esempi di traduzione automatica per singoli Plc (Programmable Logic Controller) con programmi scritti con logica Ladder [1]. Ma questi studi si sono dimostrati parzialmente applicabili al mondo dei Dcs, infatti, la qualità e l’utilità di una traduzione automatica sono strettamente correlate all’obiettivo dello stesso traduttore. In altre parole, è impossibile non considerare aspetti quali la configurazione input/output (locale e remota), la configurazione hardware (multi-controllore) e la comunicazione. Questi aspetti non sono fini solo a loro stessi, ma coinvolgono il software di controllo; quindi, ogni sforzo prodotto per tradurre i programmi deve necessariamente tenere conto di questi aspetti. Ritornando al caso del Dcs, fino ad ora, due principali approcci sono stati utilizzati: uno completamente manuale e un altro parzialmente automatico. Nel caso manuale, gli ingegneri usano tabelle che collegano elementi nella prima (vecchia) configurazione Dcs con elementi della seconda (nuova) configurazione Dcs. Queste tabelle possono esistere per qualche o tutti gli aspetti menzionati sopra. Gli ingegneri usano queste tabelle come una guida per creare gli elementi della seconda configurazione. Comunque, la traduzione è realizzata in modo manuale, allora, la completezza, la consistenza e la correttezza della traduzione soffrono degli stessi problemi di accuratezza di ogni lavoro manuale. Inoltre, per tradurre a mano una configurazione completa è necessario molto tempo e questo come già detto impatta sui costi di aggiornamento del sistema di controllo. Nel secondo caso, invece, gli ingegneri usano tool software progettati per la traduzione di un singolo controllore con un singolo programma in esecuzione, e per gli aspetti riguardanti la configurazione degli input/output. Questi tool software hanno bisogno dell’aiuto di un operatore, per tradurre le informazioni di configurazione dal primo al secondo sistema di controllo. In pratica questo strumento utilizza l’approccio con le tabelle (si veda il caso precedente), sollevando gli ingegneri dal tedioso lavoro di traduzione. Quindi, con l’aiuto di questo tool, non è necessario introdurre manualmente la completa configurazione nel nuovo sistema di controllo [1]. Come detto, questa soluzione è limitata ai sistemi dove solo un controllore è coinvolto, e dove questo esegue un singolo programma. In aggiunta, questa soluzione tiene conto del software e degli I/O ma non tiene conto di tutti gli altri aspetti quali cycle-time, esecuzione e comunicazione fra unità hardware.

La traduzione: scopo

Al fine di permettere la traduzione automatica dell’informazione, la stessa deve essere disponibile e accessibile in formato elettronico. Questi dati elettronicamente memorizzati, sono solitamente disponibili in quanto la progettazione e la realizzazione del sistema di controllo avviene con l’uso di un’applicazione specifica. Quest’applicazione è lo strumento di ingegneria usato per configurare l’hardware del sistema e per implementare le logiche di controllo. La migrazione si basa sulle informazioni relative alla configurazione del sistema di partenza (Source engineering Db), per produrre la configurazione del sistema finale (Target engineering Db). La traduzione tratta i seguenti dati:
– numero e tipo delle schede di ingresso uscita, connesse ai diversi controllori, unitamente a tutti i parametri di configurazione delle schede stesse;
– numero, tipo e configurazione dei controllori che costituiscono il sistema di controllo distribuito;
– informazioni sul comportamento atteso da ogni controllore. Queste informazioni consistono solitamente nell’insieme dei programmi assegnati ai controllori, in aggiunta alle informazioni sui tempi di esecuzione e sulle priorità dei programmi stessi;
– informazioni sul numero, tipo e caratteristiche dei sistemi per la comunicazione tra i controllori;
– informazioni sui requisiti e necessità di comunicazione tra i vari controllori e con eventuali sistemi di supervisione e controllo;
– tag usati per identificare vari elementi del sistema.

Scarica l'allegato

• 
• Tweet
• Pin It
• Condividi per email