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 post dei blog di oggi. Un sacco di prodotti promettono di aiutare a raggiungere l'integrazione verticale del flusso di produzione e dei dati e del software aziendale come l'ERP. Ma di solito, c'è anche una fregatura: o si ottengono prodotti molto complessi con un cartellino del prezzo altrettanto scioccante - o nonostante la promessa di IIoT di piena interoperabilità cross-vendor si diventa vendor-locked, soprattutto se si considerano le soluzioni software che sono 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 paesaggio informatico dei clienti è un paesaggio cresciuto in modo naturale e quindi intrinsecamente complesso. Alla sua fondazione, utilizza un sistema ERP legacy che viene esteso da applicazioni web-based PHP personalizzate e interfacce con altri prodotti software (ad esempio CAD, CAM come il software di nesting laser, ...) e sistemi del cliente per lo scambio diretto di dati. Tutto questo in un ambiente server misto Windows/Linux e un pool di clienti quasi esclusivamente basato su Windows in un Active Directory. I servizi di file si basano prevalentemente sulle condivisioni di 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 attraverso 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 generale del fornitore della macchina e offre solo un accesso molto limitato ai dati della macchina e al sistema di controllo. Offre un'interfaccia OPC UA con meno di 10 punti dati che sono popolati solo se la fabbrica usa il software di pianificazione della produzione del fornitore della macchina che gira sul PLC della macchina. Pertanto, questa interfaccia si è dimostrata non troppo utile per il mio cliente ora, tuttavia la situazione potrebbe cambiare.

I primi passi

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

Il cliente ha scelto il protocollo di comunicazione OPC UA che è sempre più comune nei PLC e nelle macchine di oggi. Mentre questo standard può essere usato per stabilire una comunicazione in tempo reale e quindi sostituire le funzioni attualmente implementate dai sistemi industriali di bus di campo, nel nostro scenario, le capacità in tempo reale non sono necessarie. Mentre gli SDK sono disponibili per l'integrazione diretta dello stack OPC UA nell'applicazione del mio cliente, sono di solito complicati e quindi contraddicono l'obiettivo di ridurre la complessità.

Così, invece della codifica personalizzata, il cliente opta per una piattaforma di integrazione che ha un connettore OPC UA pre-costruito 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 - locali e basati su cloud, e 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 questa fabbrica, la nuova tecnologia sta attraversando il processo di adattamento, quindi il sistema di saldatura robotizzato funziona solo in un singolo turno e la macchina non è in funzione costantemente anche durante le ore di lavoro. Pertanto, i dati acquisiti in questo momento possono essere utili, ma potrebbero anche rivelarsi inaffidabili per un uso futuro o per scopi predittivi. Questo 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 - se l'operatore della macchina era presente quando un ciclo di produzione è finito, quando l'acquisizione dei dati è stata attivata - hanno dimostrato che anche i dati apparentemente molto accurati potrebbero dipingere un quadro sbagliato, e che la granularità fine non è sempre necessaria per giudicare 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, in questo momento solo la sorgente laser può essere collegata. Altri componenti non sono possibili da integrare: il PLC del robot ha solo l'interfaccia OPC Classic, e il passaggio all'Architettura Unificata è impegnativo al momento; e il sistema di telecamere è legato al PLC dell'intera macchina e sembra non essere 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 preziosa intuizione è la compilazione dei messaggi di log della macchina. L'esperienza del mio cliente in passato era che non tutte le macchine mantengono i loro file di log attraverso i riavvii. Inoltre, gli operatori delle macchine non sempre riportano accuratamente i malfunzionamenti e gli errori ai loro supervisori. Questo può portare a tempi di fermo macchina più lunghi del necessario quando si verifica un grave malfunzionamento. Se la macchina era in funzione quel giorno - è una domanda importante.

Per un facile accesso da parte della direzione tecnica dell'azienda, tali report giornalieri vengono generati come file PDF e archiviati in una Dropbox condivisa, nel caso in cui sia necessario aprire una chiamata di supporto al 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 IO digitali se non altrimenti possibile) per ottenere una precisa tempistica di avvio/arresto dei cicli di produzione.

Insieme al sistema di timesheet dell'azienda, questo permetterà di capire meglio quanto tempo la macchina è effettivamente in produzione e quanto tempo è usato 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 di consegnare qualsiasi prodotto reale. Tali processi saranno molto più facilmente realizzabili se la documentazione completa del processo di saldatura può essere consegnata in modo costante e automatico.

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. specializzato in tecnologia informatica industriale e 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 di 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 (soprattutto interfacce tra diversi prodotti software e applicazioni di pianificazione della produzione). Ha conseguito un master in matematica presso l'Università di Vienna.