12 aprile 2013

PLC Vs PAC: ancora?!?!

Premesse:



  • Questo è un post in risposta all'articolo su AutomazioneNews.it "PLC e PAC, cosa scegliere?"
  • Non si tratta di un post di polemica, ma solo il punto di vista dell'autore sulla questione. Sarei felicissimo di intavolare una discussione per cercare di crescere e superare magari visioni che sono ingiustificate o troppo "reazionarie": nessuno ha il dono della Verità e il confronto aiuta ad arrivarci un po' più vicini...





Onestamente io mi posiziono tra coloro che in prima battuta non vedono grandissime differenze funzionali tra PAC e PLCAnche PLC a basso costo dispongono di innumerevoli "add-on" per svolgere molti ruoli diversi e la linea di demarcazione è così sottile che forse rappresentata solo dal sistema operativo e da un reale multitasking (prerogativa primaria dei PAC), a scapito di un determinismo e una rigidità (che dona in cambio sicurezza) che invece regna assoluto nel mondo dei PLC. E' giustissima la considerazione che si tratti solo di strumenti: chi lavora come integratore deve avere la capacità di discriminare quando e dove usare PAC o PLC o DCS o RTU...

Se invece affrontiamo il discorso da un punto di vista diverso, ovvero quello dell'architettura e delle "best practices", dobbiamo essere sempre all'erta.
Uno dei principi che, personalissimamente, ho sempre adottato è quello del disaccoppiamento funzionale: se ho da far svolgere a un sistema due funzioni diverse, dal mio punto di vista, è generalmente preferibile che siano due device diversi e specializzati a svolgerle: ognuno deve fare ciò che sa fare meglio, nell'impianto non regna la democrazia.

Faccio un esempio: desiderare che un controller si connetta al database aziendale è probabilmente una forzatura dovuta o alle circostanze obbligate ("non possiamo fare diversamente") o ad una scarsa progettazione architetturale di partenza. Il database per sua natura è uno strumento asincrono che deve restare il più possibile disaccoppiato da uno strumento che lavora nel dominio dei millisecondi. Un lock su una tabella o su un record potrebbe significare disastro dal lato IT come dal lato Campo.

Altro esempio: salvare dati su un controller può avere senso solamente se il controller è totalmente disconnesso da una rete, oppure se ha un funzionamento a "burst" di invio/ricezione (ad esempio invia i dati una volta al giorno con una connessione satellitare o cellulare) oppure se desideriamo un buffer in caso di assenza di connessione per guasto alla rete, ma in reti industriali cablate (ad anello, magari) questa caratteristica è superflua oppure è possibile implementarla sufficientemente bene anche su un PLC: una rete cablata e organizzata come si deve è davvero difficile che vada giù, e se va giù deve essere per pochi minuti... 

Ho fatto volutamente due esempi in cui un PAC potrebbe essere superfluo. Chi mi fa degli esempi in cui è indispensabile?

Confermo i complimenti alla redazione di AutomazioneNews per l'interessante spunto di riflessione rappresentato dal loro articolo!

Volete invece un paio di ottime risorse per scegliere e capire meglio di cosa stiamo parlando: 

01 aprile 2013

System Integrators: ostaggi delle “majors”?

Integratore legato come un salame
Il panorama internazionale dei tools di integrazione non è mai stato così vasto e ricco di offerte come al momento: negli ultimi anni si è assistito a importanti acquisizioni, fusioni e incorporazioni che hanno di fatto ridotto il numero dei marchi “storici”, consentendo alle cosiddette “majors” di dotarsi di numerosi strumenti, plug-in e verticalizzazioni tali da riuscire a coprire tutti i maggiori temi dell’integrazione. E’ singolare osservare come le parole chiave che descrivono i benefici di questi prodotti siano più o meno ovunque le stesse. Ho tentato di creare una sorta di tag cloud con principali parole chiave identificate sui svariati siti web:
Scalability Flexibility Real-time Intelligent Connectivity Integration Reliability Simple Easy Solution Product Open

Questo risultato (empirico), insieme ovviamente ad una lettura piuttosto approfondita dei vari contenuti, brochures e white-papers, al confronto con gli agenti che il mio lavoro mi porta costantemente a intrattenere, e alla tendenze di mercato che posso quotidianamente verificare sul campo, mi porta a voler condividere alcune considerazioni volutamente provocatorie...

+ Facile, +Semplice e + Flessibile
1. “Simple”, “Easy” e “Flexibility”: in base alla mia esperienza solitamente questi sono termini che sviluppano una forte frizione quando usati a breve distanza fra loro. La flessibilità comporta la disponibilità di una gamma di strumenti per poter affrontare diverse variabilità dei progetti, e più vasta è tale gamma maggiori sono le possibili criticità a cui si va incontro. Pretendere che uno strumento sia flessibile e semplice è in effetti la pietra filosofale dell’IT!

Scalabilita e affidabilità
2. Altro punto di riflessione è la minore importanza di termini quali “Scalability” o “Reliability”… quasi come se fossero ormai termini così tanto inflazionati da essere scontati, ovvi e superflui… del resto il cliente “deve” volere un sistema “chiavi in mano” e chi offre una soluzione deve anche avere la capacità di assumersi i rischi derivanti da una carenza di queste doti. Nell’immaginario collettivo il grande marchio è in grado di farlo, mentre la piccola azienda o il professionista non possono… in realtà è il contrario, ma l’arcano sarà, forse, un po’ più chiaro solo dopo aver letto l’ultimo punto di questo articolo… portate pazienza!

aperto?
3. La presenza del termine “open” porta a facili supposizioni di apertura delle soluzioni proposte. Di fatto questo termine è spesso associato non tanto al termine “strumento”, ma con il termine “architettura”, che di per sé aggiunge un ben magro valore: una architettura aperta è una caratteristica tutto sommato aleatoria: cosa significa di preciso? Non sono riuscito a capirlo esattamente, ma so che uno strumento aperto consente integrazioni spinte entro ambienti, applicazioni, sistemi con la stessa caratteristica di apertura. Spesso mi sono trovato ad approfondire questo argomento con i tecnici commerciali, ma le risposte vanno spesso in un unico senso: “Questa integrazione è semplicissima: basta acquistare il modulo X” oppure “Se vuoi pubblicare le pagine web occorre avere l’opzione Web-Server”, etc, etc...


4. Last but not least “Integration” e “Solution”: i grandi del mercato dei prodotti di integazione, ormai sempre di più, si vedono come providers di Soluzioni e di Integrazione, e dove volessimo vedere il termine “solution” in contrapposizione con “product” (ovvero l’offerta di un prodotto è meno pubblicizzata dell’offerta di soluzioni) le politiche di marketing parlano puttosto chiaro in merito: i produttori di software si stanno ponendo sul mercato come solution providers invece che come sviluppatori di strumenti, questione che mi lascia profondamente perplesso. Molti integratori si configurano ormai come partner indissolubilmente legati ad un prodotto e alle sue sorti, costretti ad accettare commesse per cui il fornitore di una volta è divenuto il cliente di oggi, trovandosi di colpo il coltello dalla parte del manico: non solo devono sviluppare, a volte sottocosto, le soluzioni così ampiamente pubblicizzate dal big di turno, ma, per poterlo fare, devono spesso anche qualificarsi con corsi molto costosi e rinunciare alla concorrenza in determinati settori. Paradossale, eh? E lo è ancora di più se ricordate il secondo punto di riflessione, dove dicevo che in realtà è il piccolo che è in grado di affrontare i rischi del successo del progetto…


Soluzioni a questa situazione verranno con il tempo, quando le piattaforme inizieranno a distaccarsi dalle esigenze, vuoi perché gli integratori “ammansiti” non stresseranno più i servizi di assistenza tecnica a valutare criticamente i loro prodotti, vuoi perché le tecnologie, già oggi estremamente stratificate dal tempo e solo in pochi casi (guarda il caso: sono le realtà più piccole!) costantemente aggiornate, non potranno più reggere l’impatto con esigenze di performance, analisi e integrazione sempre maggiori, vuoi perché le promesse di scalabilità e flessibilità pagate a peso d’oro dimostreranno i loro limiti. 

Chi avrà invece mantenuto la capacità di integrare veramente potrà, come sempre, continuare a progettare e a risolvere problemi.

20 febbraio 2013

Movicon 11.3 provato "al banco"

Movicon è un ambiente di sviluppo e runtime per applicativi HMI e SCADA leggero ed economico. E' sviluppato dalla italiana Progea di Modena.

La curva di apprendimento per le funzionalità accessibili da interfaccia grafica è praticamente piatta, mentre per padroneggiare la DOM è necessario qualche sforzo in più. Progea organizza periodicamente dei corsi gratuiti di avvicinamento al prodotto, che ci sentiamo di consigliare a chi ha già provato l'ambiente e desidera intraprendere lo sviluppo di progetti effettivi. Ulteriori corsi a pagamento sono invece indispensabili per chi desiderasse sviluppare progetti complessi e con funzionalità che trascendono le più semplici applicazioni di visualizzazione dei dati di processo.
Non abbiamo ovviamente effettuato alcun benchmarking degno di questo nome, ma abbiamo voluto valutare l'aspetto prestazionale di questo ambiente che apprezziamo per la "leggerezza", l'organizzazione pulita e funzionale dell'interfaccia di sviluppo e la grande produttività.

Installazione

Abbiamo scaricato Movicon 11.3 dal sito di Progea in poco più di 15 minuti (828 Mb). Il server è dunque reattivo e niente affatto "addormentato". Lavoriamo su un notebook dignitoso con Windows 8. L'installazione è come da manuale. Pochi clic per impostare i parametri principali e 3-4 minuti per l'installazione completa (da cui abbiamo eliminato i manuali multilingua e i progetti demo).
Dopo l'installazione (siamo su Windows 8) l'icona di avvio non viene aggiunta al desktop, quindi dobbiamo andare a cercarla per creare un link veloce, oppure WIN + R e digitare "Movicon".

Primo avvio

Viene richiesto il codice di licenza, che non abbiamo e di cui non avremo bisogno fino alla messa in produzione del runtime finale: annulliamo. Viene mostrato un dialogo dove poter scegliere un template di progetto. Scegliamo "Piattaforma Win 32/64". Inseriamo poi la cartella di destinazione e il nome del progetto, le impostazioni di sicurezza e i driver di comunicazione e di protocollo di cui vogliamo servirci nel nostro progetto, che sono molti e ben organizzati. Scorrendo l'elenco possiamo da subito verificare per quali driver sarà necessaria una licenza aggiuntiva e quali sono invece forniti gratuitamente. Non è presente il driver "OPC Client" in quanto fa parte di default della struttura di progetto che vedremo al termine del wizard di creazione del nostro progetto. Proseguiamo senza selezionare alcun driver. Ancora avanti viene chiesto quante pagine creare e se desideriamo aggiungere un titolo alle pagine e un menu di navigazione. Diciamo di no e proseguiamo con le opzioni di default fino al termine della procedura.

IDE

Dobbiamo rilevare un piccolo fastidio ottico che non compromette la funzionalità: quando il cursore si sposta su una posizione dove il puntatore assume l'aspetto di una freccia di ridimensionamento c'è uno sfarfallio rapidissimo e continuo che lascia intravedere il cerchietto "occupato" (la ex-clessidra).
Riportiamo una screenshot commentata che sintetizza l'organizzazione intuitiva dell'ambiente di sviluppo.

Prestazioni

Dopo l'apertura di un progetto vuoto:

Dopo l'apertura del progetto demo (>350 variabili, 28 sinottici aperti in editing):


Editor aperto e Runtime demo avviato:
Dobbiamo indicare che il progetto demo di Movicon è piuttosto pesante, in quanto contiene numerosi datalogger in funzione, ha delle pagine grafiche molto "dimostrative" e che quindi fa un uso abbastanza intenso di processore e scritture su disco. In condizioni normali un progetto con queste caratteristiche di complessità dovrebbe girare su un server di impianto dedicato.

Processo di compilazione e avvio Runtime:

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).