24 gennaio 2013

Le ultime novità da Copa-Data: Partner Program e Zenon 7.1x

Una partner community agile e multi-ruolo.

Il programma di partnership di Copa-Data è stato presentato oggi ai principali integratori e clienti italiani del marchio di Salisburgo, assieme ad una anteprima ristretta della piattaforma SCADA Zenon versione 7.1x che uscirà in primavera.
Le aspettative per il programma partner italiano sono quelle di creare una comunità di eccellenza in grado di rispondere alle richieste dei principali settori industriali che impiegano sistemi di automazione: Alimentare, Energia, Infrastrutture, Farmaceutico, Petrolchimico sono gli ambiti di primario, ma non esclusivo interesse.
La necessità di mettersi continuamente in gioco, di sapersi costantemente reinventare e di fare network sembra dunque essere la ricetta di Copa-Data e dei suoi partner italiani al calo della domanda a cui si assiste da ormai troppi mesi.

Il nuovo Zenon 7.1x in fase di beta testing.

Una attesa tutt'altro che infruttuosa: la nuova versione di Zenon 7.1x, in uscita a meno di un anno dalla seppur nuovissima 7.00, mostra interessanti miglioramenti nelle performance, nell'ergonomia, nell'esperienza utente, oltre all'aggiunta di alcuni nuovi moduli funzionali di engineering.
Dal multitouch nativo configurabile in maniere totalmente "code-less" che porta l'esperienza delle HMI su un nuovo piano qualitativo, al porting dell'editor e del runtime a 64 bit, fino alla piena compatibilità con Windows 8 Pro: sono le caratteristiche che promettono di saper sfruttare a pieno le potenzialità dei moderni hardware per offrire velocità, immersione e "awareness" dall'operatore bordo macchina fino al manager.
Restiamo in attesa di conoscere le date di rilascio e le release note ufficiali per le altre caratteristiche: non vogliamo svelare tutte le sorprese prima della festa!


Nota: questo blog non è legato alle aziende e ai prodotti che vengono presentati da alcun rapporto di natura commerciale, salvo diversa indicazione.

16 gennaio 2013

PLC e DCS: le radici storiche

Molti di noi lavorano nell'automazione di processo da decenni. E ci sono nuovi colleghi che quotidianamente rinfoltiscono i ranghi. Ed è proprio per i nuovi membri di questa comunità globale dell'automazione di processo che condivido una presentazione di Gordon Lawther di Emerson alla conferenza ChemInnovations dell'autunno scorso. La presentazione, "L'evoluzione dei PLC e dei DCS", tratta delle radici storiche, dei punti di forza e delle applicazioni storiche e dei progressi nel corso del tempo.

La genesi del PLC [Programmable Logic Controller] risale agli anni '60.

In quel periodo la General Motors impiegava enormi sforzi per modificare le linee automatizzate della fabbrica prima dell'introduzione di ogni nuovo Model Year (MY); automazione implementata mediante relè, temporizzatori e sequenziatori a camme, con il risultato che gli elettricisti impiegavano moltissimo tempo per il ricablaggio.

Per coloro che non hanno avuto il piacere di incontrare il famoso inventore del PLC, Dick Morley (NdT: Leggi a tal proposito la sua prima e unica intervista fatta da Armando Martin in Italia), è possibile avere l'occasione di incontrarlo durante alcuni eventi del settore, come la settimana dell'automazione di ISA, Il vertice marketing e vendite ISA, etc. Come scritto sulla sua voce Wikipedia:

Richard (Dick) Morley è noto come il "padre" del controllore logico programmabile (PLC), in quanto è stato coinvolto con la produzione del primo PLC per la General Motors, il Modicon, presso la  Bedford And Associates nel 1968.

Lo spostamento della logica dai dispositivi discreti al software, permetteva di ottenere una drastica riduzione dei tempi di ricablaggio dei processi produttivi discreti, alla General Motors come presso altri produttori.

Logica Ladder 
Gordon riassume così alcune caratteristiche generali dei primi PLC: erano economici, semplici da usare, di dimensioni ridotte, programmabili/gestibili dal personale interno, con interfacce operatore minimali e prevalentemente utilizzati nelle operazioni automatiche.
L'architettura era sovente costituita da una scheda rack con CPU e varie schede I/O connesse al livello di impianto; un terminale di programmazione veniva collegato al PLC per scaricare il software di controllo, scritto in logica Ladder.

Nel corso del tempo, questa architettura si è ampliata per includere collegamenti peer-to-peer tra i PLC, le workstation operatore, i moduli I/O remoti, etc; in seguito arrivarono anche la ridondanza, software aggiuntivi come gli archivi storici, le elaborazioni batch e il supporto per i bus e le reti.

Progettato per applicazioni discrete, il PLC ha avuto fin dall'inizio dei tempi ciclo di esecuzione al di sotto di 10msec in grado di supportare applicazioni per turbomacchine, contatori di impulsi, e applicazioni di arresto di sicurezza. Il sequencing è un'altra classe di applicazioni legata alla movimentazione dei materiali, per le linee di confezionamento e per la robotica, per citarne alcune. I PLC si sono anche dimostrati adatti ad equipaggiare sistemi montati su slitta, quali compressori d'aria, additivi chimici e mixer.

Sistemi distribuiti

I DCS [Distributed Control System] nascono dall'industria di processo.

Questo tipo di industria include processi continui che si trovano nella produzione di petrolio e gas, nella raffinazione, in chimica, e nell'estrazione mineraria. Inoltre, i DCS sono stati progettati per le elaborazioni a lotti tipicamente presenti in settori come quello farmaceutico, delle biotecnologie e dei prodotti chimici speciali. Le variabili di processo come portata, temperatura, pressione e livello avevano bisogno di essere strettamente e costantemente controllate, in special modo nei processi complessi come la distillazione, la fermentazione, le reazioni chimiche e le applicazioni legate al trasferimento di calore. Al posto dei relè i DCS sostituirono i controllori pneumatici, in cui il circuito di regolazione contiene aria compressa: invece del mal di testa causato dal cablaggio i DCS risolvevano quello causato dal portare le condotte pneumatiche dai collettori a ciascun regolatore.

I DCS avevano schede di I/O integrate, con controllo ad anello chiuso svolto dalla CPU del controller. I linguaggi di programmazione erano per lo più basati su Assembler, FORTRAN, e altri linguaggi logici ormai datati. Le variabili di processo, i setpoint, le uscite delle valvole e altri parametri erano rappresentati su display tabulari e mimici che assomigliavano ai cruscotti di controllo pneumatici che andavano a sostituire. I controller e le stazioni di lavoro degli operatori erano connesse mediante un bus di comunicazione.

Gordon ha evidenziato alcune delle caratteristiche comuni ai primi DCS: erano costosi, di grandi dimensioni, con complessi requisiti applicativi (a causa delle complessità dei processi da controllare), realizzati con tecnologie proprietarie per l'interfaccia operatore, per le comunicazioni, per gli strumenti di sviluppo e per le architetture ridondate in alta disponibilità, e infine con servizi / formazione forniti solo dal produttore del DCS o da terze parti. Inoltre, il tutto era pensato e progettato per una operatività "attended", in cui gli operatori partecipano al processo contribuendo a mantenere la qualità e la quantità del prodotto entro i limiti attesi.

I punti di forza intrinseci di architetture basate sui DCS sono l'ampia scalabilità, in grado di gestire interi impianti in cui gli I/O sono nell'ordine di grandezza delle decine-centinaia di migliaia di punti, forniscono agli operatori una stretta sorveglianza del processo, possiedono inoltre numerore librerie built-io per la gestione di controlli complessi, in continuo e per lotti, e mettono a disposizione una base di dati comune per semplificare la gestione delle funzioni di ingegneria. La ridondanza di questi sistemi si estende all'archietettura di alimentazione, di rete, di controller, di moduli I/O, etc.

Molte industrie come il "food & beverage" o le "Life Sciences" avevano stringenti requisiti sia per quanto riguarda le normative di controllo, sia per l'esigenza di alte velocità nel campo dell'automazione discreta. I DCS e i PLC, venivano così connessi per mezzo di interfacce seriali come RS232 / 422 e tramite OPC. Nel corso del tempo i PLC e DCS hanno acquisito ciascuno i punti di forza dell'altro: tecnologie e standard aperti si sono evoluti per aiutare queste migliorate capacità - reti ad alta velocità, protocolli aperti, linguaggi standard di programmazione industriali (IEC 1131), postazioni PC operatore, sistemi operativi Microsoft, bus I/O standard, ridondanza e altri servizi estesi.

Oggi la maggior parte dei sistemi, indipendentemente dalle proprie radici, hanno architetture hardware completamente ridondanti, bus I/O digitali, sistemi di sicurezza integrati, gestione e ottimizzazione degli asset, controllo di processo avanzato (APC), interfacce uomo-macchina (HMI) ad alte prestazioni, gestione avanzata dei lotti e connettività con la gestione della produzione, i sistemi MES e la pianificazione delle risorse aziendali (ERP). Innovazioni in grado di evolvere ulteriormente le capacità di questi sistemi continuano ad essere studiate e ricercate, come ad esempio l'Electronic Marshalling di Emerson.

L'attenzione delle industrie di processo, quando valutano possibili alternative, è solitamente rivolta verso la robustezza dell'architettura, la semplicità d'uso (operazioni, ingegneria, manutenzione e gestione degli impianti), la sicurezza, i servizi e il supporto locale, e l'esperienza e il curriculum aziendali sulle applicaizoni e sui settori industriali.



Questo post è la traduzione dell'articolo di Jim Cahill di Emerson dal titolo "Roots of PLCs and DCSs", che ringraziamo per il permesso alla traduzione e pubblicazione. Anche l'uso delle immagini originali ci è stato gentilmente concesso dallo stesso autore.

09 gennaio 2013

Automazione e sigle: facciamo chiarezza

Edit: abbiamo ricevuto diverse richieste di chiarimento in privato. L'argomento desta molto interesse e anche qualche polemica, quindi dedicheremo altri post per entrare un po' più nel dettaglio. Invitiamo comunque tutti i lettori a condividere le loro opinioni nell'area commenti, in modo da dare la possibilità a tutti di interagire.


Famiglia di prodotti per l'automazione SIMATIC
Abbiamo deciso di scrivere questo articolo dal momento che abbiamo notato che c'è molta confusione circa il senso di taluni termini piuttosto comuni per chi si occupa di automazione. Non è nelle nostre intenzioni dare delle definizioni esatte o universalmente accettabili: ci basta definire un lessico a cui fare per primi noi riferimento quando affrontiamo tematiche che potrebbero sollevare discussioni circa la correttezza o meno di certe considerazioni e opinioni. Neanche Wikipedia, da questo punto di vista, riesce ad essere sufficientemente chiara circa i limiti e risulta quasi sempre fumosa nelle definizioni: un indice di quanto sia difficile trovare consensi unanimi.
Molto spesso, nel colloquio si nota una certa tendenza ad usare questi termini in senso soggettivo o fisico, volendo in qualche modo identificarne le caratteristiche prestazionali o fisiche, mentre in questo articolo faremo riferimento al senso oggettivo o funzionale. Un possibile motivo per la diatriba di significati e sigle è l'affermazione sul mercato di nomi commerciali di prodotti: questo ha causato uno spostamento delle  definizioni verso le caratteristiche di prodotto distorcendo il significato generico originale.

SCADA

Supervisory Control And Data Acquisition - Controllo di supervisione e acquisizione dati.
Già in questa voce, ci troviamo di dissentire dalla definizione che troviamo su Wikipedia, che considera i sistemi SCADA come un tipo di sistemi di controllo industriali (ICS). Dal nostro punto di vista l'acronimo rappresenta due funzioni distinte e ben delineate:
  • il controllo supervisorio, ovvero il controllo che ricade nelle responsabilità di una persona che abbia il ruolo di "supervisore" di un impianto; un supervisore ha lo scopo di "guardare dall'alto" o "da sopra" l'oggetto del suo interesse. Ne valuta lo stato in termini generali o aggregati, senza scendere nel dettaglio (ovviamente dipende dall'estensione del sistema: se parliamo di un sistema di generazione elettrica con gruppo elettrogeno diesel magari anche il livello di carburante è un dato di "alto livello").
  • l'acquisizione dei dati, ovvero l'apertura e il mantenimento di uno o più canali di comunicazione verso i dispositivi del sistema da supervisionare allo scopo di acquisirne le informazioni diagnostiche e operative. Non c'è elaborazione, storage, retrieval e reporting in questa definizione. Sono funzioni da svolgersi a cura di altri moduli funzionali, in una generica architettura semplificata.

Riducendo all'osso le due definizioni, un sistema SCADA completo potrebbe già essere costituito da un modulo allarmi di alto livello e da uno o più moduli di comunicazione e di protocollo di interfaccia.
SCADA non è una famiglia di applicativi commerciali/proprietari (in senso soggettivo) ma una funzione che può essere svolta da un qualunque software che realizzi le funzioni indicate, con più o meno dovizia di particolari e di funzioni ausiliarie.

HMI

Human-Machine Interface - Interfaccia uomo-macchina.
Spesso indicata anche come MMI, Man-Machine Interface. E' un sistema mediante il quale l'uomo riesce a comunicare la sua volontà ad una macchina e attraverso cui la macchina fornisce informazioni circa il suo funzionamento. L'interfaccia è bidirezionale, non c'è motivo di pensare altrimenti.
Anche in questo caso la definizione identifica una funzione e non un tipo di strumento specifico. Un pulsante con indicatore luminoso è un chiaro esempio di HMI e funzionalmente l'HMI contiene anche la definizione di SCADA. La macchina verso cui l'uomo desidera interfacciarsi non è il pannello o il pulsante, ma l'impianto fisico, ergo nella definizione rientrano anche i protocolli di interfaccia e tutto quanto entra nel percorso tra la volontà umana e il sistema di controllo della macchina. L'attuazione finale è l'effetto desiderato, ma è svolto dal sistema di automazione o di controllo della macchina stessa.
In questo caso, a differenza dello SCADA, l'HMI non è limitato alla funzione supervisoria (che può ma anche può non implementare) ma realizza in pieno l'interfaccia completa con la macchina. Tutti i dettagli della macchina e tutti i comandi impartibili devono essere a disposizione dell'operatore. Ovviamente saranno mancanti i comandi e i controlli di alto livello, quelli che risultano dall'aggregazione logica o operativa di impianti e macchine diverse che realizzano il sistema nel suo complesso.
Un HMI in senso soggettivo spesso viene identificato con la sola rappresentazione grafica (ma in questo caso il termine più corretto sarebbe GUI - Graphical User Interface) o addirittura con i pannelli operatore videografici da bordo macchina.

M2M

Machine to Machine
Termine che sinceramente si sente molto poco, ma che mi piace utilizzare per classificare la funzione logica di interazione e scambio informazioni tra sistemi disaccoppiati (non fisica: quella è svolta dal mezzo trasmissivo e dall'infrastruttura di comunicazione come un Bus Seriale o una LAN). Un sistema di supervisione integrato può avere più punti dove viene usata una interfaccia M2M, quando è chiamato a dialogare con altri sistemi non di base quali SCADA o HMI. Ad esempio: pubblicare certe informazioni per tramite di servizi web lo consideriamo come impiegare un modulo M2M, oppure anche un modulo hardware/software che realizza la funzione di front-end di comunicazione è a tutti gli effetti un modulo M2M.

PLC

Programmable Logic Controller - Controllore a Logica Programmabile. Il termine si autodefinisce abbastanza genericamente. Un controllore a logica programmabile è un qualunque dispositivo programmabile in grado di risolvere una logica che implementa un algoritmo. Esistono poi delle norme tecniche internazionali che definiscono i requisiti che i PLC devono possedere in vari termini meccanici, elettrici, funzionali, di programmazione e di impiego. In questo caso si dovrebbe parlare di PLC conformi o non conformi alla norma IEC 61131.
Un PAC (Programmable Automation Controller), un DDC (Direct Digital Control), ad esempio, sono tutti dispositivi programmabili che risolvono determinati algoritmi e che quindi potrebbero rientrare a pieno titolo entro la definizione di PLC. Le sigle che li contraddistinguono tuttavia indicano una specializzazione (per ottimizzare le prestazioni o per dedicarli a funzioni specifiche) o una estensione di funzionalità ad ambiti per loro natura estranei alla risoluzione di logiche (come i PAC), ma utili (entro certi limiti di carico e al di fuori di certi canoni di disaccoppiamento funzionale) all'implementazione delle funzioni richieste ad un sistema di automazione e controllo.

RTU

Remote Terminal Unit - Unità Terminale Remota.
Una RTU non elabora né risolve alcuna logica. E' una unità terminale che ricevuti gli "ordini" da una unità di classe superiore non fa altro che eseguirli. Si tratta di un ripetitore con capacità di comunicazione, una morsettiera intelligente utile a ridurre i costi di cablaggio e a lasciare distribuiti sul campo gli I/O di un sistema di automazione e controllo.
Una RTU non è un PLC, anche se può possedere una interfaccia di configurazione.


Nota: l'immagine riprodotta in testa all'articolo è puramente decorativa.

08 gennaio 2013

Le novità della norma IEC 61131

La norma sui Controllori a Logica Programmabile (PLC)

Come già annunciato alcuni giorni fa, presentiamo oggi un altro post relativamente alle novità introdotte ed in corso di introduzione sulla norma IEC 61131, che disciplina la costruzione, la programmazione e l'utilizzo dei controllori programmabili (PLC per brevità d'ora innanzi).
Ma andiamo per ordine.


La prima edizione delle norme, che recava la sigla P-IEC, risale al 1992-1993. La norma era divisa in:
  • Parte 1: Informazioni Generali
  • Parte 2: Requisiti hardware e test
  • Parte 3: Linguaggi di programmazione
  • Parte 4: Linee guida per l'utente
Successivamente al 2000 vennero aggiunte le seguenti parti:
  • Parte 5: Comunicazioni
  • Parte 7: Programmazione controlli "fuzzy"
  • Parte 8: Linee guida per l'applicazione e l'implementazione dei linguaggi di programmazione

IEC 61131-6:2012 - Ed.1.0

La parte 6, a lungo rinviata dal Comitato Tecnico 65B (dispositivi di misura e controllo), ha visto finalmente l'uscita della sua prima edizione lo scorso anno. Lungamente attesa dai progettisti di sistemi di automazione (e forse un po' meno dai produttori) che prevedano l'implementazione di funzioni strumentate di sicurezza (SIF), questa parte chiude finalmente il cerchio della sicurezza funzionale, oggetto delle norme IEC 61508 e IEC 61511, e delle altre norme collegate alle quali occorre fare comunque e sempre riferimento.
Ciclo-vita del FS-PLC secondo la norma IEC 61131-6:2012

Questo nuovo capitolo si occupa dunque di definire i requisiti ingegneristici dei PLC e delle periferiche loro associate (moduli di input, output, interfaccia e comunicazione) qualora si voglia impiegarli come sottosistema di risoluzione della logica (Logic Solver) in sistemi di sicurezza elettrici, elettronici ed elettronici programmabili (E/E/PE), a partire dalla definizione del ciclo-vita del prodotto. I PLC che soddisfano i requisiti della norma acquisiscono una sorta di "qualifica" che li rende FS-PLC (Functional Safety PLC). Inoltre vengono definiti i criteri per il calcolo, la stima e la determinazione dei parametri di SIL, PFD, PFH, SFF, HFT e DC nonché per tutti i processi di documentazione, verifica e validazione.

Il target è dunque rappresentato dai manufactorers di PLC e dai progettisti di sistemi di sicurezza.

IEC 61131-3:2012 - Ed.3.0 (Final Draft)


Ma non è tutto! E' infatti uscita in bozza finale la revisione 3.0 della parte terza della norma, relativa ai linguaggi di programmazione. Se tutto procede senza intoppi, verrà approvata entro questo gennaio.
Si tratta di una norma di estensione, compatibile quindi con l'edizione 2.0, ma che introduce diverse interessanti novità:

  • Nuovi tipi di dato e relative funzioni di conversione;
  • Novità sulle modalità di riferimenti e sui namespaces;
  • Introduzione delle caratteristiche object-oriented nelle classi e nei blocchi funzione.

Considerazioni

E' superfluo osservare come l'introduzione di capacità di sviluppo object-oriented sui controllori programmabili possa rappresentare la manifestazione di uno sviluppo tecnico-culturale delle professionalità principali nel campo dell'automazione. La programmazione dei PLC, in precedenza vista come una capacità e una competenza specifiche del dominio dei tecnici di estrazione elettrica/elettronica, sta diventando materia per professionalità di estrazione informatica (grazie all'introduzione di superiori capacità di astrazione) e potrebbe quindi segnare l'inizio della fine di un'era.
Ovviamente il processo sarà lento, data la straordinaria longevità dei sistemi di automazione rispetto alle tencologie IT, ma per il prossimo futuro prevediamo il nascere di una dicotomia "Old school" Vs "New school": contatti contro oggetti.
Non riesco a nascondere una certa ansia della novità: da una parte ne accolgo il coraggio e l'innovazione che vorrei poter applicare da subito ai nuovi progetti (esistono già da qualche anno ambienti di sviluppo orientati agli oggetti nel senso della norma che, pur soffrendo degli immancabili mali di gioventù, mi rendono piuttosto entusiasta, ad esempio CoDeSys V3.x), dalla parte opposta della medaglia un senso di prudenza mi trattiene: credo che sia opportuno studiare bene il contenuto della norma e le peculiarità degli ambienti per lo sviluppo ad oggetti allo scopo di verificare quanta flessibilità e quale livello di astrazione venga realmente lasciato allo sviluppatore. Un eccesso da questo punto di vista, unito ad una scarsa esperienza nello sviluppo OO in questi ambienti, potrebbe portare a implementare soluzioni con un elevato livello di rischio per le prestazioni o la stabilità. Sicuramente, senza perdermi in ulteriori elucubrazioni, la carta vincente sarà la progettazione consapevole e bilanciata degli applicativi, in parte sviluppati secondo i canoni tradizionali (magari proprio per l'implementazione delle funzioni di sicurezza), e in parte secondo la nuova scuola (eventualmente per le funzionalità accessorie non critiche).