Era il 17 marzo 1861, giusto 150 anni fa, quando, vinti gli austriaci e conclusasi la spedizione di Garibaldi in Sicilia, veniva proclamata a Torino, prima capitale, l’Unità Nazionale. E oggi è il giorno giusto per risvegliare il nostro ‘orgoglio nazionale’, forse troppo spesso sopito… con questo spirito, dunque, ‘celebriamo’ il successo della norma IEC EN 62603 “Industrial Process Control Systems – Guideline for evaluating process control systems. Part 1: Specification”, il cui progetto è nato per iniziativa di nove società appartenenti a Clui (Club Utenti Italiani)-Exera, utilizzatrici di sistemi di controllo, e si è sviluppato in seno all’italiano CEI (Comitato Elettrico Italiano), all’interno del GdL (Gruppo di Lavoro) 6 di SC65B. CEI lo ha quindi proposto a IEC, ottenendo l’autorizzazione ufficiale a sviluppare il lavoro per conto della comunità internazionale.
“Proprio il respiro sovrannazionale dell’iniziativa ha richiesto il coinvolgimento sia dei costruttori/fornitori di tecnologia, sia degli utilizzatori finali” ha sottolineato Dario Fantoni, presidente di Clui e Convenor di IEC SC65B/WG6. Il sottocomitato WG6 del comitato SC65B di IEC, costituito nel 2008, aveva il compito di preparare un metodo standard di valutazione per stabilire le performance di un PCS. Il team dedicato al tema, interno a WG6, è oggi composto da rappresentanti di 11 Paesi (24 membri di cui 4 italiani). “L’idea era dare vita a un tool software che fosse in grado sia di produrre le specifiche di un PCS in modo automatico e guidato, sia di fornire una valutazione dei PCS implementati” prosegue Fantoni. “Al momento è stato compiuto un primo passo in avanti su questa strada, con la messa a punto del tool informatico, ma i lavori perseguiranno”.
Il gruppo di lavoro ha ‘compiuto l’impresa’ di promuovere l’immagine dell’Italia a livello internazionale, mostrando l’operatività dei rappresentanti italiani e la loro capacità di recepire nuove esigenze, nonché di proporre soluzioni concrete, valide a livello globale. “Nell’ambito della commissione sui PCS è stato dato incarico di realizzare il tool richiesto all’Università di Genova, in particolare al team coordinato da Paolo Pinceti, che ha poi sviluppato il testo della norma in accordo con CEI” prosegue Fantoni. “Nel luglio 2010 si è deciso di procedere presentando il progetto alla riunione di TC65 di IEC; in ottobre alla riunione di Seattle (USA) si è deciso di procedere con la norma 62603; il CDV (Commitee Draft for Vote) è stato presentato come richiesto entro la fine di dicembre 2010, in perfetta linea con i tempi previsti. Durante la riunione di Seoul, prevista per maggio di quest’anno, si procederà alla soluzione dei commenti, mentre la seconda parte del programma verrà sviluppata nel corso del 2011”. La norma dovrebbe andare in approvazione nella seconda metà del 2011, divenendo quindi operativa.
La prima parte della norma si focalizza sulla stesura delle specifiche base che vanno attribuite a un PCS, per consentire all’utente di comparare in modo obiettivo le soluzioni tecniche proposte da diversi costruttori. Si propone quindi una procedura che consente di verificare se un certo sistema di automazione soddisfa i requisiti tecnici specificati dal progettista, utente o società d’ingegneria. Per fare questo, la norma si articola in due parti: la prima definisce una modalità di stesura delle specifiche tecniche funzionali, identificando tutti i parametri necessari a focalizzare l’applicazione specifica; la seconda si focalizza sulle prove da effettuare (FAT-Factory Acceptance Test) per valutare la soluzione realizzata.
Venendo all’iter che la normativa ha seguito, spiega Paolo Pinceti, dell’Università di Genova: “Il progetto è nato con l’idea di sviluppare un tool che aiutasse l’utente a valutare un PCS e testarlo. Scopo ultimo era stabilire le prestazioni che un sistema di automazione dovesse avere non in sé, bensì in quanto inserito in un’applicazione, quindi per valutare quanto un dato sistema fosse adatto a fare ciò che era chiamato a fare”. Non si tratta dunque di valutare il prodotto in termini assoluti, per fare un ‘rating’ dei sistemi in commercio, bensi di valutarlo all’interno dell’applicazione.
Il testo finale della specifica consta di 11 capitoli, uno per ciascun aspetto ritenuto centrale in un PCS. Il software che implementa la norma è per sua natura un vero strumento di lavoro, che da una lato aiuta l’utente a elaborare le specifiche, dall’altro il costruttore nel rispondere alle richieste del cliente. “Per la prima volta abbiamo proposto una norma che si identifica con un tool software, infatti tutte le specifiche della norma sono state tradotte in menu e sottomenu da compilare via software” sottolinea Pinceti “Ogni voce della tabella richiama un capitolo della norma, dove tutto viene spiegato e giustificato. Altra novità del testo è che non occorre avere l’originale di tutte le norme per utilizzare il software, in quanto le parti di norma cui si fa riferimento nel documento sono richiamate all’interno del software stesso. Occorrerà solo controllarne via via gli aggiornamenti”.
La versione sviluppata utilizza come sistema di scambio dati fra utente e costruttore semplicemente Excel, completo di opportune password, per cui il foglio può essere modificato solo da chi lo ha creato. I fogli fanno ognuno riferimento ai diversi capitoli della norma e consente di costruire un modello del sistema proposto utilizzando un ambiente grafico completo di libreria a oggetti e comandi clic&drag. Ogni componente inserito è legato a una maschera da completare con i dati relativi al prodotto e le relative macro-informazioni. Vi sono anche degli ‘help’ cliccando sui quali compaiono gli estratti della norma, i capitoli con le indicazioni per la compilazione degli spazi. Il dettaglio progettuale deve essere invece elaborato in autonomia dai diversi costruttori, ognuno con i propri strumenti.
Gli 11 capitoli che compongono la norma richiamano i requisiti essenziali che un PCS deve avere, utilizzando una logica il più possibile vicina a quella del progettista.
Prima di tutto si guarda all’architettura del sistema: si usa un PLC, un DCS o un PC industriale? Quanti I/O dovranno essere supportati? Si passa poi alle condizioni ambientali: il sistema deve operare in campo o in una control room? E in condizioni ambientali estreme? Quindi vengono richiamate le caratteristiche che il sistema deve avere: si tratta di una soluzione chiusa o di un sottosistema entro un apparato più ampio? Deve essere facilmente espandibile? Deve presentare funzioni specifiche, per esempio funzionamento online, hot swap ecc.?
Un ulteriore capitolo è dedicato ai parametri di affidabilità richiesti: ridondanza, tolleranza ai guasti, problematiche di alimentazione, sicurezza. Segue una parte dedicata alla tipologia degli I/O da gestire (livelli d’isolamento, accuratezza); poi si considerano la tipologia del software (deve poter eseguire simulazioni in tempo reale? Contempla soluzioni di cyber security?), l’HMI (registrazione dello storico, gestione degli allarmi e delle interfacce ecc.), la comunicazione (separando i livelli fra fieldbus, control network ecc. e il tipo di protocollo, proprietario o interoperabile ecc.), le prestazioni (tempi di risposta ecc.).
Sono quindi i requisiti tecnico-commerciali (supporto da parte del fornitore, garanzie date ecc.), quindi le specifiche FAT (tipologia di test da effettuare, simulati, in campo ecc.; al 100% o a campione ). Occorre infatti che il costruttore sia fin dall’origine informato sulla tipologia di test che l’utente richiede, il che influisce sull’offerta finale (i costi cambiano).
Clui: www.clui.it
Università di Genova: www.unige.it