Un fermo macchina di tre minuti, un contapezzi che si azzera a cambio turno o un allarme non associato alla commessa possono alterare KPI, consuntivi e decisioni di reparto. Questa guida all'integrazione MQTT in fabbrica parte da qui: non dalla scelta di un protocollo, ma dalla necessità di rendere il dato di...
Perché usare MQTT per collegare la fabbrica
MQTT adotta un modello publish/subscribe. Una sorgente pubblica un messaggio su un topic, mentre uno o più sistemi ricevono i messaggi sottoscrivendo quel topic. Il broker è l'elemento centrale che riceve, instrada e controlla le comunicazioni. Rispetto a integrazioni punto-punto, questo modello riduce le dipendenze tra macchina, raccolta dati, MES, BI ed eventuali applicazioni di manutenzione.
In uno stabilimento con linee eterogenee, il vantaggio è concreto. Un PLC Siemens S7, un controllo esposto via Modbus TCP/IP, una macchina OPC UA e un dispositivo EtherNet/IP possono continuare a usare i rispettivi protocolli nativi sul campo. Un agente industriale raccoglie i valori, li normalizza e li pubblica tramite MQTT. I sistemi a valle non devono conoscere il dettaglio del singolo PLC né accedere direttamente alla rete di automazione.
MQTT è particolarmente adatto quando servono telemetria frequente, aggiornamenti di stato, eventi di allarme e comunicazioni affidabili su connessioni con banda limitata o soggette a interruzioni. Non è però sempre la scelta migliore per ogni flusso. Per trasferire ricette complesse, file o grandi volumi storici possono essere più appropriati database, API o integrazioni dedicate. Il criterio corretto non è usare MQTT ovunque, ma assegnargli il ruolo di bus eventi industriale.
Architettura per l'integrazione MQTT in fabbrica
Una configurazione efficace separa chiaramente il livello macchina dal livello applicativo. Questa separazione limita l'esposizione della rete OT e rende più semplice aggiungere macchine, linee o nuovi consumatori di dati senza modificare gli impianti esistenti.
Dal PLC al messaggio contestualizzato
Il primo passaggio è definire come leggere i dati. L'agente on-premise comunica con PLC, CNC, gateway o sistemi SCADA attraverso il protocollo disponibile: S7, OPC UA, Modbus TCP/IP, MTConnect o altri standard supportati dalla macchina. La lettura deve essere pianificata per frequenza e priorità, evitando polling inutilmente aggressivi che possano gravare sui dispositivi di campo.
A questo punto serve una trasformazione semantica. Un bit denominato `M100.2` non è utile al reparto direzionale e non è sufficiente neppure per un MES. Deve diventare, ad esempio, lo stato `marcia`, associato alla linea, alla macchina, al timestamp, alla commessa attiva e, se disponibile, all'operatore o al lotto. Lo stesso vale per contatori, scarti, velocità, temperature e causali di fermo.
Il messaggio dovrebbe mantenere una struttura coerente, tipicamente JSON, con campi standardizzati. Un evento di produzione può contenere identificativo macchina, tipo evento, valore, unità di misura, qualità del dato e data-ora in formato univoco. La qualità è spesso trascurata: indicare se il valore è valido, stimato, assente o proveniente da una riconnessione evita che dati incompleti finiscano nei calcoli di OEE.
Topic progettati per crescere
I topic MQTT sono un elemento architetturale, non una semplice convenzione estetica. Una gerarchia leggibile permette di assegnare permessi, filtrare i messaggi e aggiungere nuovi sistemi senza creare ambiguità. Un formato possibile è `stabilimento/reparto/linea/macchina/evento`.
Per esempio, una linea di confezionamento potrebbe pubblicare su `impianto1/packaging/linea03/macchina07/stato`. I dati di consumo, gli allarmi e i contatori possono essere distinti in topic dedicati. È preferibile evitare topic troppo generici, come `dati/macchine`, perché costringono tutti i consumer a ricevere e filtrare messaggi che non servono.
Anche il versionamento merita attenzione. Se il formato del payload cambia, introdurre una versione nel messaggio o nel percorso del topic protegge MES e applicazioni già in esercizio. Questa disciplina è utile soprattutto quando il progetto parte da una linea pilota e viene esteso progressivamente allo stabilimento.
Broker, edge e continuità operativa
Il broker può essere ospitato in cloud, in un'infrastruttura aziendale o, in alcuni contesti, localmente. La scelta dipende da requisiti di latenza, politiche IT, continuità di connessione e necessità di accesso multi-sito. Per molte aziende manifatturiere, un'architettura cloud con agente leggero in stabilimento riduce server locali, attività di manutenzione e complessità di aggiornamento.
La connettività non deve però diventare un punto debole. L'agente deve gestire il buffering locale e la ritrasmissione ordinata quando la connessione esterna viene meno. Senza questa funzione, una perdita di rete può trasformarsi in buchi nei dati di produzione, con effetti su tracciabilità, consuntivazione e analisi delle fermate.
Affidabilità del dato: QoS, retained message e timestamp
MQTT mette a disposizione diversi livelli di Quality of Service. QoS 0 privilegia velocità e semplicità: un messaggio viene inviato senza garanzia di consegna. Può essere adatto a valori molto frequenti e non critici, come una temperatura aggiornata ogni secondo. QoS 1 assicura la consegna almeno una volta, ma richiede che i consumer gestiscano eventuali duplicati. QoS 2 aumenta ulteriormente le garanzie, con un costo maggiore in termini di scambi e complessità.
Per eventi produttivi che non devono andare persi, come chiusura di un ciclo, scarto validato o cambio stato, QoS 1 è spesso un compromesso efficace. Serve però un identificativo evento univoco, in modo che il sistema MES possa riconoscere una ritrasmissione senza contare due volte lo stesso pezzo.
I retained message sono utili per distribuire l'ultimo stato noto di una macchina a chi si collega successivamente. Non sostituiscono lo storico degli eventi. Un topic di stato può essere retained, mentre un evento di scarto o un allarme richiede una gestione temporale e persistente a valle.
Il timestamp deve essere coerente. Quando possibile, va registrata sia l'ora dell'evento in macchina sia l'ora di ricezione della piattaforma. La sincronizzazione NTP dei dispositivi e dei sistemi di raccolta è essenziale per ricostruire correttamente sequenze, durate dei fermi e correlazioni con ordini ERP.
Sicurezza OT e controllo degli accessi
Esporre un broker MQTT senza progettare la sicurezza è un errore evitabile. La comunicazione deve usare TLS, con certificati gestiti e rinnovati secondo una procedura definita. L'autenticazione può basarsi su credenziali dedicate o certificati client, ma in entrambi i casi ogni agente e ogni applicazione devono avere identità distinte.
Le autorizzazioni devono essere granulari. Un dispositivo che pubblica i dati della linea 3 non dovrebbe poter leggere i topic di tutte le altre linee, né inviare comandi a macchinari per i quali non è autorizzato. Le ACL per topic riducono l'impatto di credenziali compromesse e rendono più chiari i confini tra reparti, siti e applicazioni.
Sul piano di rete, la pratica consigliata è mantenere le connessioni in uscita dall'agente verso il broker, evitando aperture inbound dirette verso PLC e macchine. Segmentazione IT/OT, firewall configurati per il minimo privilegio, monitoraggio degli accessi e registri di audit completano il perimetro. MQTT non elimina i requisiti di cybersecurity industriale: li rende più governabili se l'architettura è progettata fin dall'inizio.
Dal messaggio MQTT al valore MES ed ERP
Pubblicare dati non equivale a digitalizzare la produzione. Il valore arriva quando gli eventi vengono correlati al calendario, alla commessa, all'articolo, agli standard di ciclo e alle causali. Solo allora un contapezzi diventa avanzamento ordine, uno stato macchina diventa tempo produttivo o fermo classificato, e uno scarto diventa un indicatore utile per qualità e costo.
Un MES deve applicare regole di business esplicite. Per calcolare correttamente l'OEE, per esempio, occorre stabilire quali segnali rappresentano disponibilità, prestazione e qualità, come trattare microfermi, cambi formato, inattività pianificata e dati mancanti. Queste regole variano tra reparti e tecnologie: non esiste una mappatura universale valida per tutte le macchine.
L'ERP, invece, non deve ricevere ogni variazione di tag. È più efficace scambiare eventi consolidati: avvio e chiusura ordine, quantità buona, quantità scartata, tempi, materiali consumati e dichiarazioni di avanzamento. Questo evita integrazioni rumorose e mantiene il sistema gestionale allineato con dati già verificati.
Piattaforme MES cloud-native come PLCinCloud permettono di acquisire dati da protocolli industriali, normalizzarli e renderli disponibili in dashboard operative, flussi MES e integrazioni gestionali, senza introdurre server da mantenere in stabilimento. Il punto decisivo resta la configurazione iniziale dei segnali e delle logiche produttive: la tecnologia accelera il progetto quando il modello dati è chiaro.
Un percorso di implementazione che riduce i rischi
Conviene iniziare con una linea rappresentativa, non necessariamente la più semplice. Una linea con stati, contatori, scarti e almeno un'integrazione gestionale consente di validare l'intero flusso prima dell'estensione.
- Mappare segnali, protocolli, indirizzi di rete e responsabilità OT/IT, distinguendo dati essenziali da dati opzionali.
- Definire il modello eventi: stati macchina, contatori, causali, commesse, lotti, unità di misura e regole di qualità.
- Configurare agente, broker, topic, cifratura e permessi con un principio di minimo privilegio.
- Testare riconnessione, duplicati, perdita temporanea della rete, cambio turno e riavvio della macchina.
- Confrontare per alcuni giorni i dati raccolti con registri di produzione e consuntivi reali, correggendo soglie e logiche.
- Estendere il modello alle altre linee riutilizzando convenzioni e componenti già validate.
Per gli investimenti che richiedono requisiti di interconnessione e documentazione ai fini Transizione 4.0, MQTT può essere parte dell'architettura, ma non costituisce da solo prova di conformità. Servono evidenze sulle modalità di scambio dati, identificazione univoca, integrazione con sistemi aziendali e conservazione delle informazioni richieste. Progettare questi elementi durante il progetto evita ricostruzioni documentali tardive.
Il test più utile non è verificare se un valore compare su un topic, ma se il responsabile di produzione può spiegare con quel dato perché una linea ha perso efficienza e quale azione intraprendere nel turno successivo. Quando la risposta è chiara, l'integrazione MQTT sta già producendo valore operativo.