Un fermo macchina registrato solo a fine turno, un contapezzi letto manualmente e un ordine ERP aggiornato il giorno dopo sono segnali dello stesso problema: i dati esistono, ma non circolano dove servono. Questa guida integrazione PLC e database chiarisce come progettare un flusso dati affidabile tra macchine,...
Perché collegare PLC e database
Il PLC governa la macchina nel tempo reale: legge sensori, gestisce logiche, esegue sequenze e reagisce agli eventi con tempi nell’ordine dei millisecondi. Il database ha un altro compito: conservare, organizzare e mettere a disposizione informazioni per analisi, tracciabilità e integrazione con MES, ERP o BI.
Tenere separati questi ruoli è essenziale. Usare il database come estensione della logica macchina introduce dipendenze indesiderate e rischi operativi. Usare invece il PLC come unico archivio rende difficile ricostruire lotti, analizzare scarti, calcolare OEE e verificare cosa sia accaduto su una linea durante un intervallo preciso.
Un’integrazione ben progettata consente di acquisire stati macchina, pezzi prodotti, tempi ciclo, ricette, parametri di processo, allarmi, consumi e dati di qualità. Questi segnali diventano informazioni utili solo quando sono associati a contesto: macchina, commessa, prodotto, operatore, lotto, turno e timestamp affidabile.
Guida all’integrazione PLC e database: partire dai casi d’uso
La scelta tecnica deve seguire il risultato operativo, non il contrario. Prima di definire tag, protocolli o schema dati, conviene stabilire quali decisioni il sistema dovrà supportare.
Per esempio, il monitoraggio OEE richiede la distinzione tra produzione, microfermate, guasti, cambio formato e attese, oltre a un contatore pezzi affidabile. La tracciabilità di lotto richiede invece eventi di ingresso e uscita, associazioni con materie prime e avanzamenti di fase. L’invio di dati verso ERP richiede regole chiare su quando un avanzamento è consolidato e su come gestire eventuali rettifiche.
In questa fase è utile definire un dizionario dati condiviso tra produzione, automazione e IT. Per ogni informazione vanno indicati significato, unità di misura, sorgente, frequenza di aggiornamento, qualità attesa e responsabile. Un tag chiamato `status` senza semantica documentata crea ambiguità; uno stato macchina classificato secondo una causale concordata diventa immediatamente utilizzabile.
Non tutti i dati devono essere campionati allo stesso modo
La frequenza di acquisizione dipende dal fenomeno da osservare. Un contapezzi può essere letto su variazione o a intervalli brevi. Un allarme va acquisito come evento, con apertura, chiusura e codice. Una temperatura di processo può richiedere un campionamento periodico, mentre una ricetta va registrata al cambio o all’avvio della produzione.
Trasferire ogni variabile a intervalli molto ravvicinati aumenta traffico, volume storico e costi di gestione, senza migliorare necessariamente la lettura del processo. Al contrario, una frequenza troppo bassa può nascondere microfermate o rendere impossibile ricostruire un’anomalia. Il criterio corretto è acquisire il dato con la granularità necessaria al caso d’uso.
L’architettura: separare campo, raccolta e applicazioni
Un’architettura industriale efficace distingue almeno tre livelli. Al livello di campo operano PLC, CNC, sensori, strumenti e macchine. Al livello di raccolta un connettore o agente industriale legge i dati, applica le regole necessarie e li inoltra in sicurezza. Al livello applicativo risiedono database, MES, ERP, dashboard e sistemi BI.
Questo modello evita di esporre direttamente i PLC alla rete aziendale o a servizi esterni. La macchina continua a lavorare anche se una dashboard non è disponibile, mentre la piattaforma di raccolta può gestire ritenti, accodamenti e normalizzazione senza modificare la logica di automazione.
In contesti con più stabilimenti, l’agente on-premise leggero riduce la necessità di server locali dedicati. I dati vengono raccolti vicino alle macchine e resi disponibili in una piattaforma centralizzata accessibile via browser. È un approccio particolarmente adatto quando l’azienda vuole standardizzare la raccolta dati senza replicare infrastrutture e attività di manutenzione in ogni reparto.
PLCinCloud adotta questa logica: l’interconnessione tra asset di campo e servizi cloud passa da un componente locale essenziale, mentre le funzioni MES, dashboard, storicizzazione e integrazione applicativa restano centralizzate. Il vantaggio non è solo tecnologico: riduce i tempi di attivazione e semplifica la governance di macchine anche molto diverse tra loro.
Protocolli e connettività: scegliere in base al parco macchine
Non esiste un protocollo migliore in assoluto. La scelta dipende da PLC installati, firmware, topologia di rete, requisiti di sicurezza e disponibilità delle interfacce della macchina. In uno stabilimento reale è frequente trovare più standard contemporaneamente.
Siemens S7 è spesso il canale diretto per PLC Siemens. Modbus TCP/IP è diffuso su dispositivi, strumenti e macchine di generazioni diverse. OPC UA offre un modello più strutturato, con metadati e sicurezza integrata, ed è indicato quando il costruttore lo espone correttamente. EtherNet/IP è comune in ecosistemi basati su Rockwell Automation. MQTT è utile per trasportare messaggi in architetture publish/subscribe, soprattutto quando occorre distribuire dati a più applicazioni. MTConnect trova spazio nella raccolta dati da macchine utensili compatibili.
La compatibilità di protocollo, da sola, non garantisce un progetto riuscito. Occorre verificare quali variabili siano effettivamente accessibili, se i contatori sono persistenti, come vengono gestiti reset e riavvii e se esiste una mappa dati aggiornata. Su macchine datate può essere necessario leggere registri disponibili, aggiungere un gateway o intervenire con il costruttore per esporre segnali significativi. Ogni scelta va valutata rispetto al costo, al fermo necessario e al valore operativo atteso.
Modellare il database per eventi, non solo per tag
Un errore ricorrente consiste nel creare una tabella generica che salva timestamp, nome tag e valore per ogni lettura. Questo modello può essere utile per diagnostica o storicizzazione tecnica, ma non basta per alimentare i processi di fabbrica.
Per produrre informazioni utilizzabili servono entità orientate al dominio: ordini di produzione, cicli, lotti, turni, eventi di stato, dichiarazioni di quantità, scarti, allarmi e parametri di processo. Il dato grezzo resta disponibile quando necessario, ma viene affiancato da dati elaborati e coerenti con il linguaggio del reparto.
Un evento di fermo, per esempio, dovrebbe contenere almeno inizio, fine, durata, macchina, causale e, quando possibile, ordine in lavorazione. Se la causale arriva dal PLC, va verificata la sua codifica. Se è inserita dall’operatore, è utile proporre un elenco controllato e prevedere una gestione delle cause non ancora classificate. Senza questa disciplina, il dato esiste ma non è confrontabile.
Gestire duplicati, perdita di connessione e qualità del dato
Le reti industriali non sono sempre continue e i PLC possono riavviarsi. L’integrazione deve quindi prevedere identificativi evento, controlli di sequenza e scritture idempotenti: se lo stesso messaggio viene ricevuto due volte, il database non deve duplicare la produzione dichiarata.
È altrettanto importante distinguere tra dato mancante, zero reale e valore non valido. Un contatore fermo può significare macchina in attesa, comunicazione interrotta o sensore guasto. Registrare la qualità del dato e lo stato della connessione permette di evitare KPI apparentemente precisi ma costruiti su informazioni incomplete.
La sincronizzazione oraria merita la stessa attenzione. PLC, gateway, database e applicazioni devono riferirsi a una fonte oraria coerente. Quando gli orologi non sono allineati, la sequenza di un allarme e la relativa fermata può risultare invertita, rendendo complessa qualsiasi analisi delle cause.
Sicurezza OT e continuità produttiva
L’integrazione non deve ampliare la superficie di attacco dell’impianto. La rete OT va segmentata dalla rete IT, gli accessi devono essere limitati al minimo necessario e le credenziali gestite con criteri coerenti. Le comunicazioni verso servizi esterni richiedono cifratura, autenticazione e tracciabilità degli accessi.
Sul piano operativo, la regola più importante è semplice: nessun sistema di raccolta dati deve diventare un punto di blocco per la produzione. Il PLC deve mantenere autonomia sulle funzioni di controllo e sicurezza. L’agente di integrazione deve poter gestire temporaneamente l’assenza di connettività, memorizzare i dati localmente entro limiti definiti e inviarli quando il collegamento torna disponibile.
Per aziende soggette a requisiti di Transizione 4.0, la progettazione deve anche rendere dimostrabile l’interconnessione. Non basta dichiarare che la macchina invia dati: servono evidenze su scambio bidirezionale, identificazione univoca dell’asset, integrazione con i sistemi aziendali e tracciabilità delle informazioni. Progettare questi aspetti dall’inizio evita documentazione ricostruita a posteriori.
Dalla prova pilota alla standardizzazione
Un progetto efficace parte spesso da una linea rappresentativa: una macchina con dati disponibili, un caso d’uso misurabile e interlocutori operativi coinvolti. Il pilota serve a validare mappa tag, qualità dei segnali, classificazione degli stati e integrazione con i sistemi esistenti.
Dopo la validazione, la priorità diventa standardizzare. Convenzioni per nomi macchina, causali, ordini, unità di misura e modelli di dashboard rendono più veloce l’estensione ad altre linee. Non significa imporre artificialmente la stessa configurazione a ogni impianto, ma riutilizzare ciò che è comune e gestire in modo esplicito le eccezioni.
Il database diventa davvero un patrimonio industriale quando il dato raccolto restituisce un’azione concreta: intervenire su una causa di scarto, ridurre un’attesa, verificare un lotto, migliorare una pianificazione o documentare un requisito di conformità. Per arrivarci, conviene iniziare da un flusso utile al reparto, misurarne l’affidabilità e ampliarlo solo quando le persone possono usarlo con fiducia.