Caso di studio: Primi passi verso l'IIoT in un ambiente di PMI

IIoT e Industria 4.0 sono argomenti onnipresenti nelle fiere di settore e nei blog di oggi. Molti prodotti promettono di aiutarti a ottenere l'integrazione verticale del flusso di produzione e dei dati e del software aziendale come l'ERP. Ma di solito c'è anche un inconveniente: o si ottengono prodotti molto complessi con un prezzo altrettanto scioccante, oppure, nonostante la promessa dell'IIoT di una completa interoperabilità tra fornitori, si finisce per rimanere vincolati a un unico fornitore, soprattutto se si considerano le soluzioni software vendute dai fornitori di macchine di produzione insieme alle loro attrezzature.

Per le aziende più piccole con risorse limitate e dipartimenti IT di piccole dimensioni o di una sola persona, questo è un dilemma. Mentre tali aziende si affidano alla flessibilità per competere con le imprese più grandi e quindi devono adottare paradigmi come l'Industria 4.0, di solito si tratta di un investimento enorme e di un muro di complessità tecnica apparentemente insormontabile.

In questo caso di studio, in primo luogo, mostrerò come una piattaforma di integrazione software con connettori pre-costruiti per la comunicazione dei dati macchina può aiutare a superare queste limitazioni. E in secondo luogo, quali possono essere le prime applicazioni pratiche per i dati macchina in tempo reale in una piccola fabbrica che inizia il suo viaggio verso l'Industrial Internet of Things.

Il cliente e le sue esigenze

Il cliente è un fornitore della piccola industria che fornisce principalmente prodotti in lamiera d'acciaio inossidabile con lotti di piccole dimensioni e un portafoglio prodotti complesso.

Per essere in grado di competere con altri produttori in questo settore, la fabbrica ha bisogno di progresso tecnologico e di un'evoluzione costante del processo di produzione. Pertanto, il cliente ha iniziato a introdurre la saldatura laser robotizzata all'avanguardia nel processo produttivo.

A parte il processo in sé, l'integrazione di una tale soluzione di saldatura robotizzata nella pianificazione della produzione, l'ottenimento dei dati necessari per il calcolo dei costi, il controllo della qualità ecc. è un'altra sfida.

L'ambiente IT del cliente

Il panorama IT dei clienti è cresciuto in modo naturale e quindi è intrinsecamente complesso. Alla base utilizza un sistema ERP legacy che è stato ampliato con applicazioni web PHP personalizzate e interfacce con altri prodotti software (ad esempio CAD, CAM come software di nesting laser, ...) e sistemi dei clienti per lo scambio diretto di dati. Tutto questo all'interno di un ambiente server misto Windows/Linux e un pool di client quasi esclusivamente basato su Windows in un Active Directory. I servizi di file sharing si basano prevalentemente su condivisioni Windows e (in misura minore) su Dropbox.

In generale, la strategia dei clienti è quella di ridurre la complessità della propria infrastruttura IT cercando di ridurre la quantità di diverse tecnologie utilizzate (stack LAMP, AD, Windows, O365, sistemi legacy, ecc.), aumentando così la gestibilità e riducendo i costi di manutenzione dell'intero ecosistema.

L'ambiente di produzione

I macchinari di produzione hanno di solito un periodo di utilizzo intrinsecamente lungo. Pertanto, non tutte le macchine sono attrezzate per applicazioni Industry 4.0 o forniscono funzionalità molto limitate in questo settore. Pertanto, questo articolo si concentra esclusivamente sull'applicazione di saldatura robotizzata e sulle sue esigenze di integrazione.

Il sistema di saldatura è una soluzione chiavi in mano di un noto produttore che consiste in una sorgente laser a stato solido, un robot con tavola rotante-inclinabile, una testa di lavorazione con un sistema di telecamere, cella di protezione necessaria per applicazioni laser ad alta potenza, sistemi di controllo e sistemi ausiliari (aspirazione, raccolta della polvere, raffreddamento).

I componenti di questo sistema comunicano tramite una varietà di interconnessioni industriali standard (IO digitali, Profinet, EtherCat, Ethernet standard). Secondo le specifiche del fornitore, solo un'interfaccia Ethernet standard è esposta verso l'infrastruttura di rete del cliente. Questa interfaccia è collegata al sistema PLC complessivo del fornitore della macchina e offre un accesso molto limitato ai dati e al sistema di controllo della macchina. Offre un'interfaccia OPC UA con meno di 10 punti dati che vengono popolati solo se la fabbrica utilizza il software di pianificazione della produzione del fornitore della macchina in esecuzione sul PLC della macchina. Pertanto, questa interfaccia si è rivelata non troppo utile per il mio cliente al momento, ma la situazione potrebbe cambiare.

I primi passi

Come primo passo, l'obiettivo era quello di acquisire dati direttamente dai componenti della macchina.

Il cliente ha scelto il protocollo di comunicazione OPC UA, sempre più diffuso nei PLC e nelle macchine odierni. Sebbene questo standard possa essere utilizzato per stabilire una comunicazione in tempo reale e quindi sostituire le funzioni attualmente implementate dai sistemi bus di campo industriali, nel nostro scenario le funzionalità in tempo reale non sono necessarie. Sebbene siano disponibili SDK per l'integrazione diretta dello stack OPC UA nell'applicazione del mio cliente, questi sono solitamente complessi e quindi contraddicono l'obiettivo di ridurre la complessità.

Quindi, invece di ricorrere alla programmazione personalizzata, il cliente opta per una piattaforma di integrazione che dispone di un connettore OPC UA predefinito con un'interfaccia facile da usare e la possibilità di connettersi a sistemi di back-office come ERP, CRM, vari sistemi di gestione dei documenti o database, sia locali che basati su cloud, il tutto a un prezzo ragionevole.

Il controllo diretto di questi sistemi attraverso la piattaforma di integrazione non è un obiettivo, poiché potrebbe potenzialmente violare il principio del singolo punto di controllo necessario per la sicurezza della macchina.

Frequenza del sondaggio dei dati

In questo stabilimento, la nuova tecnologia è in fase di adattamento, quindi il sistema di saldatura robotizzata funziona solo su un unico turno e la macchina non è in funzione costantemente nemmeno durante l'orario di lavoro. Pertanto, i dati acquisiti in questa fase possono essere utili, ma potrebbero anche rivelarsi inaffidabili per un utilizzo futuro o a fini predittivi. Ciò si basa sull'esperienza del cliente con i dati raccolti da altre macchine di produzione, ad esempio le macchine per il taglio laser. Alcuni fattori, come la presenza dell'operatore della macchina al termine di un ciclo di produzione o al momento dell'acquisizione dei dati, hanno dimostrato che anche dati apparentemente molto accurati possono fornire un quadro errato e che non sempre è necessaria una granularità fine per valutare l'efficienza del processo di produzione.

Così, una frequenza di polling piuttosto bassa di 30 secondi è attualmente utilizzata per l'acquisizione dei dati.

In questo primo passo, il cliente vorrebbe sondare i dati di questi 3 componenti principali:

la sorgente laser,

il PLC del robot,

il sistema di telecamere.

Tuttavia, al momento è possibile collegare solo la sorgente laser. Non è possibile integrare altri componenti: il PLC del robot dispone solo dell'interfaccia OPC Classic e il passaggio all'architettura unificata è attualmente difficile; inoltre, il sistema di telecamere è collegato al PLC dell'intera macchina e non sembra accessibile da client esterni.

OPC UA per la sorgente laser

Rimane la sorgente laser. Fortunatamente, questo sistema è dotato di un controller all'avanguardia che incorpora una sofisticata interfaccia OPC UA con diversi livelli di accesso: accesso anonimo con capacità di lettura limitata, sola lettura, lettura e scrittura. Come detto prima, l'accesso in lettura e scrittura era fuori questione per ragioni di sicurezza della macchina. Pertanto, è stato scelto l'accesso in sola lettura.

Questa interfaccia offre una pletora di dati:

Stato generale del sistema laser

Periodi di funzionamento, potenza utilizzata, ...

Messaggi di errore e di manutenzione

Con la piattaforma di integrazione, il cliente ha sviluppato un servizio Windows in C# per eseguire periodicamente il polling dei dati e compilarli in diverse tabelle di database SQL per uso futuro. Le tabelle possono fornire informazioni come dati generali, uso delle attrezzature, tabelle per la manutenzione/messaggi di errore prodotti dalla sorgente laser.

Una grande domanda: come usare questi dati della macchina

La prima informazione preziosa è la raccolta dei messaggi di log delle macchine. L'esperienza passata dei miei clienti mi ha insegnato che non tutte le macchine conservano i propri file di log dopo il riavvio. Inoltre, gli operatori delle macchine non sempre segnalano accuratamente i malfunzionamenti e gli errori ai propri supervisori. Ciò può comportare tempi di inattività delle macchine più lunghi del necessario quando si verifica un malfunzionamento grave. Se la macchina fosse stata in funzione in quel giorno è una domanda importante.

Per facilitare l'accesso da parte della direzione tecnica dell'azienda, tali rapporti giornalieri vengono generati in formato PDF e archiviati in una cartella Dropbox condivisa, nel caso in cui fosse necessario contattare l'assistenza tecnica del fornitore della macchina.

Naturalmente, questa è attualmente solo un'applicazione molto limitata dell'immensa capacità del connettore OPC UA. I prossimi passi che il cliente sta sviluppando sono:

Collegamento al PLC del robot (tramite I/O digitali, se non diversamente possibile) per ottenere tempi di avvio/arresto accurati dei cicli di produzione.

In combinazione con il sistema di registrazione delle ore lavorative dell'azienda, ciò consentirà di comprendere meglio quanto tempo la macchina è effettivamente in produzione e quanto tempo viene utilizzato per l'insegnamento (programmazione del robot) e/o il carico/scarico/manutenzione;

Accesso al sistema di telecamere: poiché la saldatura laser è un processo di saldatura diverso, i clienti del mio cliente devono certificare questo metodo di produzione prima che qualsiasi prodotto reale venga consegnato. Tali processi saranno molto più facili da realizzare se sarà possibile fornire costantemente e automaticamente una documentazione completa del processo di saldatura.

Inoltre, con la prevista riduzione della complessità e dei servizi utilizzati, è imminente il passaggio da Dropbox-Shared a OneDrive, una volta che questo sarà esteso a tutti i clienti interessati. Il cliente è anche interessato ad una possibile analisi dei dati per la manutenzione predittiva.

Conclusione

Come scritto sopra, questo progetto è nella sua fase di stallo ed è ancora lontano dall'essere una soluzione IIoT completamente funzionale. Andare con una piattaforma di integrazione con connettori pre-costruiti invece di programmare l'intera integrazione mi ha aiutato evitando la necessità di entrare nei dettagli di un altro stack di connessione (come OPC UA o l'API Dropbox). E per il mio cliente ha fornito uno stack di comunicazione centralizzato per le applicazioni future.

Informazioni su Richard Majer

Richard Majer, fondatore di flupo Systemtechnik e.U., azienda specializzata in IT industriale e tecnologia di automazione per le PMI. Prima di avviare la propria azienda, Richard ha lavorato in un istituto di ricerca e sviluppo per applicazioni laser ad alta potenza (acquisendo esperienza nella tecnologia laser, simulazioni FEM, robotica industriale, programmazione PLC, sistemi bus di campo industriali) e ha più di 10 anni di esperienza nell'IT generale con particolare attenzione allo sviluppo di software in ambienti PMI (principalmente interfacce tra diversi prodotti software e applicazioni di pianificazione della produzione). Ha conseguito un master in Matematica presso l'Università di Vienna.