FN_99

MAGGIO 2019 FIELDBUS & NETWORKS 67 dati relazionali. Da un certo punto di vista i database relazionali possono diventare una sorta di estensione della memoria dei PLC collocati sul campo e, grazie alla possibilità di condividere le informazioni con altri PLC e con il sistema informativo aziendale e di gestione di impresa, semplificano l’integrazione di macchine, processi e decision maker. Le informazioni che possono essere estratte interrogando i database inte- grati nel sistema permettono di individuare eventuali problemi, rallen- tamenti, inefficienze e di scegliere i rimedi ottimali per incrementare le prestazioni e i profitti di un impianto. Incrociando i dati provenienti dai PLC, dal software gestionale, dal controllo di qualità, per esempio, si possono identificare quali fornitori di materie prime o componenti siano associati alla maggiore soddisfazione da parte della clientela, oppure quali macchine abbiano processato prodotti risultati difettosi e a quali clienti siano stati spediti, così da isolare la fonte dei problemi, o attuare se necessario una tempestiva campagna di richiamo. Accesso ai dati Le due principali modalità di accesso a una base di dati sono del tipo a file condiviso e del tipo client-server. I Dbms a file condiviso sono applicazioni, come Access e SQLite, che girano su sistemi stand alone e trovano impiego tra le applicazioni di personal computing. La quasi totalità dell’offerta di Dbms per applicazioni industriali rientra invece nella categoria dei sistemi multi-utente in modalità client-server: qui una molteplicità di nodi client si connettono, tramite rete locale o via Internet, a un server separato, sul quale risiede la porzione server dell’applicazione Dbms (per esempio Oracle, MS SQL Server, MySQL). Il software presente sul lato client invia le richieste sotto forma di una lista di comandi SQL; l’applicazione Dbms sul server riceve, interpreta i comandi, interagisce con i file di dati (celando i dettagli implemen- tativi ai client) e invia il risultato delle operazioni a chi ne aveva fatto richiesta. Il software lato client può essere un’applicazione specifica connessa al particolare Dbms utilizzato, ma essendo i comandi SQL essenzialmente dei file di testo, anche un linguaggio di scripting, un linguaggio di svi- luppo web o un linguaggio di programmazione dotato delle opportune librerie. Un modo per garantire l’interoperabilità tra le varie implementazioni di Rdbms, ciascuna dotata di un proprio ‘dialetto’ SQL, consiste nell’uti- lizzare le API (Application Programming Interface) e le estensioni dello standard Odbc (Open DataBase Connectivity). In generale, le comunicazioni tra un’applicazione e il database av- vengono per mezzo di un driver che si divide in un front-end comune, aderente allo standard Odbc sul lato applicazione, e in un back-end spe- cializzato, che implementa i dettagli del particolare database. In un sistema client-server, queste due componenti del driver si trovano a cavallo del canale di comunicazione e si concretizzano in API stan- dard lato client e in API proprietarie o native lato server. Nel caso in cui le comunicazioni si svolgano su un rete intranet o Internet via http, si utilizzano estensioni sul lato server e sul lato client per effettuare la conversione tra codice Html, comandi aderenti allo standard Odbc e il particolare dialetto SQL necessario per interagire con il database specifico. In questo modo, con la giusta estensione diventa possibile ac- cedere al database attraverso il cloud utilizzando un semplice browser web. Connettività in pratica Sta allo sviluppatore del sistema di automazione scegliere la soluzione migliore per implementare la connettività tra i dispositivi sul campo e il database. Si può codificare una soluzione specifica sotto forma di driver o estensioni (utilizzando script o API nei linguaggi di programmazione disponibili), oppure ci si può appoggiare a pacchetti commerciali già pronti che, a fronte di costi fissi o di licenza, permettono di risparmiare sui tempi di sviluppo. Queste soluzioni ‘chiavi in mano’ si concretizzano tipicamente sotto forma di un PC industriale che gestisce le comuni- cazioni tra i PLC sul campo e il database e che espone delle interfacce grafiche per una più agevole configurazione. I PLC dialogano con il database per mezzo di questo ponte, rendendo possibile lo scambio bidirezionale di dati per applicazioni di data logging, sincronizzazione dei diversi controllori, personalizzazione delle ricette, tracciamento della produzione e molto altro ancora. Soluzioni commerciali di questo tipo sono solite integrare una moltepli- cità di driver, così da fornire all’utilizzatore libertà di scelta riguardo a quale base dati usare e se è il caso integrare più database nel proprio sistema di automazione. Le utilità di configurazione permettono di impo- stare le connessioni e le modalità per il trasferimento dei dati, settando condizioni, trigger, handshake. Alcuni PLC possono integrare moduli di interfaccia che permettono di comunicare direttamente con i server del database, eliminando così la necessità di un PC che faccia da ponte per le comunicazioni. In questo caso, lo scambio dei dati con il database è realizzato tramite blocchi funzione, mentre la configurazione si può effettuare tramite un pro- gramma nel PLC o direttamente da HMI. Il ruolo di OPC Lo sviluppo di soluzioni personalizzate (e ovviamente anche di soluzioni commerciali) può essere enormemente semplificato ricorrendo agli standard di interconnettività OPC (Open Platform Communications). Lo scopo originario di OPC era quello di introdurre un livello di astra- zione che permettesse di nascondere i dettagli dei protocolli specifici impiegati dai PLC dietro un’interfaccia standard comune da utilizzare nei sistemi HMI e Scada. Ai suoi albori, OPC era noto come acronimo di OLE (Object Linking and Embedding) for Process Control e la sua applica- zione era limitata ai sistemi operativi di casaMicrosoft e, in particolare, alle tecnologie Com/Dcom per le connessioni client-server. Lo standard è stato successivamente ampliato da OPC Foundation per includere le più moderne tecnologie di connessione del web in quella che è un’ar- chitettura agnostica e va sotto il nome di OPC UA (Unifed Architecture). Le vecchie specifiche OPC sono oggi note con il nome di OPC Classic e includono le varianti DA (Data Access), HDA (Historical Data Access) e A&E (Alarm and Events). Ancorché ampiamente diffuse nel mondo industriale, grazie al supporto di centinaia di produttori e all’offerta di decine di migliaia di prodotti compatibili, le specifiche OPC Classic sono destinate a essere soppiantate da OPC UA, che risulta retrocompatibile (è possibile convertire applicazioni OPC Classic in OPC UA), pur essendo indipendente dalla piattaforma. Oltre che su sistemi operativi di casa Microsoft, OPC UA può essere implementato su sistemi Unix e Linux, nonché su una molteplicità di sistemi embedded con sistemi operativi dotati di opportune specifiche di tempo reale. Questo significa che il parco prodotti che può avere accesso ai database del sistema di automazione si amplia considere- volmente. Ogni dispositivo in grado di ospitare un client OPC UA può comunicare con un server SQL sul quale sia presente una connessione dati Odbc SQL. OPC UA si integra in maniera nativa con i sistemi MES ed ERP ed è uti- lizzato in numerose soluzioni commerciali di connettività per basi di dati. Queste applicazioni agevolano la configurazione grazie a interfacce gra- fiche intuitive con cui impostare le condizioni di trasferimento dei dati. Le soluzione commerciali più evolute permettono in pratica di sviluppare applicazioni integrate con basi dati quasi senza dover scrivere codice. Gli strumenti di sviluppo OPC di ultima generazione semplificano inoltre la vita agli sviluppatori che vogliano realizzare soluzioni personalizzate che sostituiscano il middleware commerciale.