Give your website a premium touchup with these free WordPress themes using responsive design, seo friendly designs www.bigtheme.net/wordpress
Interfaccia PLC-ERP: una soluzione sicura, semplice e gestibile - Project
16730
post-template-default,single,single-post,postid-16730,single-format-standard,ajax_fade,page_not_loaded,,columns-4,qode-theme-ver-7.6.2,wpb-js-composer js-comp-ver-4.6.2,vc_responsive

Interfaccia PLC-ERP: una soluzione sicura, semplice e gestibile

16 Dic Interfaccia PLC-ERP: una soluzione sicura, semplice e gestibile

Per l’interfacciamento tipico…

In un tipico progetto di interfacciamento, ci è normalmente richiesto di sviluppare un applicativo SCADA (Supervisory Control And Data Acquisition) da cui poter visualizzare lo stato degli impianti e dell’avanzamento della produzione. Da questo punto fermo è poi solitamente piuttosto semplice andare a scrivere le informazioni richieste dall’ERP su un database o sviluppare un set di script interni o un servizio che possano comunicare tramite le API del sistema gestionale di turno.

…e per quello atipico…

A volte capita però che l’applicativo SCADA sia realizzato da terzi, che sia stato rilasciato senza sorgenti, o che non abbia la possibilità di essere interfacciato direttamente, o che il cliente non ne avverta l’esigenza, dal momento che la macchina o l’impianto sono già controllati mediante semplici HMI. In questi casi, quando cioè l’esigenza è solamente quella di trasferire dati di produzione (codici, quantità, misure/rilievi, denunce di scarto/ rilavorazione/ conformità, etc.) dal PLC che controlla l’automazione dell’impianto al database dell’applicativo ERP e viceversa, possiamo intervenire con una soluzione estremamente poco rischiosa e implementabile in tempi certi. E possibilmente senza scrivere una sola riga di codice!

Qualcuno potrebbe obiettare che alcuni PLC (nello specifico parliamo di PAC – Programmable Automation Controller – solitamente dotati di funzionalità di livello superiore rispetto ai semplici PLC che gestiscono solo logiche e I/O fisici) hanno la capacità di comunicare direttamente oppure mediante librerie che implementano le API ODBC con dei database. Questo è vero, ma si tratta di una possibilità che ci sentiamo di sconsigliare: le comunicazioni, le eccezioni, il log degli errori vanno comunque gestiti in qualche modo e non possiamo correre il rischio di bloccare da una parte le tabelle (o le righe) del database oppure, che è ben peggiore, le celle di memoria del PLC a causa di un bug o di una eccezione non gestita.

…una soluzione efficace, sicura e manutenibile.

La nostra soluzione prevede l’utilizzo di un pacchetto software commerciale che realizza e gestisce in maniera robusta le comunicazioni e le interfacce di protocollo, opportunamente installato e configurato su una macchina host. L’applicativo in questione dispone dei driver di protocollo e comunicazione con una vasta gamma di macchine. Inoltre è dotato di un collaudato modulo ODBC che gestisce la connessione al database e gli eventuali errori. Per completare il tutto abbiamo bisogno di un meccanismo di flag e trigger (implementati sia sul server di comunicazione che sul PLC) che servono persincronizzare gli eventi di lettura e innescare i processi di scrittura in entrambe le direzioni.

In un progetto appena concluso abbiamo scelto di utilizzare il software KepServerEX (prodotto da Kepware – link a fine articolo) in una configurazione “ricca”, come descritta nello schema che riportiamo di seguito.

Per aggiungere un ulteriore strato di disaccoppiamento e per impedire perdite di informazioni abbiamo utilizzato come database di appoggio Microsoft SQL Server 2012 Express dove abbiamo implementato alcune tabelle e un meccanismo di bufferizzazione dei dati provenienti dal PLC: in caso di mancanza di comunicazione con il database del sistema gestionale, non fisicamente presente in produzione, il database di appoggio mantiene le “scritture” indefinitamente per poi sincronizzarle con i timestamp corretti al ripristino della connettività.

Schema di principio interfacciamento PLC produzione e ERP senza applicazioni ad-hoc

Ovviamente la soluzione ha dei pro e dei contro:

Pro

  • Gestione delle eccezioni “built-in” nel prodotto commerciale, che può essere aggiornato nel tempo e usufruire di eventuali bugfix o patch direttamente dal produttore;
  • Manutenzione senza interpretare codice o ricompilare;
  • Monitoraggio dei servizi (KEPServerEX e database) della soluzione con tipici strumenti di Asset Management;
  • Possibilità di aggiungere applicativi di interfaccia utente in un secondo tempo utilizzando qualsiasi ambiente di sviluppo (nel nostro caso abbiamo sviluppato un semplicissimo applicativo in Python per rappresentare lo stato dei buffer di produzione);
  • Tempi di implementazione e rischio di fermo impianto estremamente ridotti;
  • Costi limitati per le licenze.

Contro

  • Bassa frequenza di tracciamento (frequenza delle informazioni da registrare su database, tipicamente valida per processi lenti >2 secondi con tracciamento individuale, o processi veloci per lotti di produzione), da non confondere con i tempi ciclo;
  • Assenza di interfaccia operatore (sono presenti nativamente solo i log per consultazione da parte di “admin” ICT);
  • I programmi PLC devono prevedere in partenza almeno delle variabili flag per l’attivazione delle transazioni e gestire le eventuali eccezioni ritornate dal server (solo per l’aspetto legato all’automazione dell’impianto, e comunque sempre necessario anche in presenza di sistemi SCADA).

Link

KEPServerEX by Kepware: http://www.kepware.com/

No Comments

Sorry, the comment form is closed at this time.