Un PLC Siemens su una linea di confezionamento, un CNC con Modbus TCP/IP, una macchina americana con EtherNet/IP e un ERP che richiede avanzamenti ordine: è in questo scenario che decidere quali protocolli usare in fabbrica smette di essere una scelta teorica. Il protocollo definisce come il dato viene letto,...
Come scegliere quali protocolli usare in fabbrica
Il primo criterio è semplice: partire da ciò che la macchina espone realmente. Manuale del costruttore, modello di PLC, firmware, porte disponibili e licenze installate contano più della preferenza interna per un determinato standard. Un protocollo moderno non migliora una connessione se il controllore non lo supporta nativamente o se richiede interventi invasivi sulla macchina.
Il secondo criterio è il tipo di dato. Leggere un contatore pezzi ogni pochi secondi non richiede le stesse prestazioni della supervisione di allarmi, della sincronizzazione di ricette o della tracciabilità di lotto. Occorre stabilire quali tag servono, con quale frequenza, chi ne è proprietario e quale sistema li utilizzerà a valle. Un dato raccolto senza unità di misura, stato macchina o riferimento ordine resta un numero difficile da trasformare in decisione.
Va poi valutato il ciclo di vita dell’impianto. In una fabbrica con macchine di età diverse, la coesistenza di protocolli è normale. La strategia efficace non consiste nel sostituire PLC funzionanti per inseguire uno standard unico, ma nell’adottare un livello di interconnessione capace di dialogare con protocolli diversi e presentare dati coerenti a MES, ERP, BI e database.
I protocolli più usati per l’interconnessione industriale
Siemens S7 per impianti con PLC Siemens
Nei reparti italiani, Siemens S7 è spesso la scelta diretta quando la linea utilizza PLC della famiglia S7. Consente di leggere variabili, stati, contatori e dati di produzione dal controllore, rispettando la struttura del programma esistente. È particolarmente adatto quando serve un collegamento rapido con macchine Siemens senza introdurre gateway aggiuntivi.
La qualità dell’integrazione dipende però dalla mappatura dei tag. Indirizzi poco documentati, merker usati per logiche temporanee o variabili non normalizzate possono generare dati ambigui. Prima della connessione è utile definire un elenco condiviso di segnali: stato automatico, fermo, causa fermo, contapezzi, scarti, codice articolo, ordine e parametri rilevanti.
Modbus TCP/IP per semplicità e diffusione
Modbus TCP/IP è molto presente su macchine ausiliarie, impianti di processo, strumenti di misura, inverter, sistemi frigoriferi e dispositivi di campo. È apprezzato perché semplice, diffuso e supportato da molti costruttori. Per la raccolta di registri, bit di stato e valori analogici, rappresenta spesso il percorso più rapido per portare dati OT verso un MES.
Il compromesso è una semantica limitata. Modbus indica dove leggere un valore, non cosa quel valore significhi nel processo. Il registro 40125 può rappresentare temperatura, velocità, pressione o un setpoint: il significato deve essere gestito dall’integrazione e documentato con precisione. Anche la corretta gestione di endianess, scaling, registri a 16 o 32 bit e tempi di polling è decisiva per evitare valori errati.
OPC UA quando servono standardizzazione e contesto
OPC UA è indicato quando l’obiettivo non è soltanto leggere tag, ma disporre di un modello dati più strutturato, interoperabile e sicuro. Offre meccanismi di autenticazione, cifratura, certificati e una rappresentazione più ricca degli oggetti macchina. È una scelta solida per linee nuove, macchinari predisposti all’Industria 4.0 e architetture che devono crescere nel tempo.
Non è automaticamente la risposta a ogni esigenza. Un server OPC UA configurato male, con certificati non gestiti o un namespace non documentato, può rallentare il progetto più di una connessione diretta. Prima di adottarlo conviene verificare quali nodi espone realmente la macchina, la qualità dell’implementazione del costruttore e la possibilità di sottoscrivere eventi invece di effettuare letture ripetitive.
EtherNet/IP negli ecosistemi Rockwell e nordamericani
EtherNet/IP è comune in impianti con controllori Rockwell Automation e in macchine di origine nordamericana. Oltre alla comunicazione con PLC, può essere presente nella rete di azionamenti, I/O distribuiti e dispositivi intelligenti. Per chi gestisce linee importate o reparti misti, supportarlo evita di creare conversioni proprietarie o dipendere da un PC di supervisione dedicato.
Il punto operativo è separare il traffico di raccolta dati dal controllo della macchina. La rete che governa I/O e motion richiede priorità e stabilità. L’accesso ai dati per dashboard o MES deve essere progettato con frequenze e segmentazione coerenti, senza appesantire il ciclo produttivo.
MQTT per inviare dati al cloud in modo efficiente
MQTT è un protocollo publish/subscribe particolarmente utile per trasferire dati dalla fabbrica a servizi cloud. Un agente locale può pubblicare eventi, valori e stati verso un broker, mentre applicazioni autorizzate si iscrivono ai topic necessari. È efficace quando occorre scalare su più stabilimenti, ridurre il traffico rispetto al polling continuo e gestire connessioni in uscita controllate.
MQTT non sostituisce sempre il protocollo nativo del PLC. Nella pratica, lavora bene come livello di trasporto verso il cloud dopo la lettura di S7, Modbus TCP/IP, OPC UA o EtherNet/IP. La progettazione deve includere naming dei topic, qualità del servizio, gestione delle disconnessioni, buffer locale e certificati. Pubblicare migliaia di tag senza una gerarchia leggibile crea soltanto una nuova forma di frammentazione.
MTConnect per macchine utensili e dati di lavorazione
MTConnect è rilevante soprattutto per CNC e macchine utensili. Consente di esporre in modo standardizzato informazioni come stato operativo, programma, avanzamento, allarmi e condizioni di lavorazione. Quando il parco macchine lo supporta, facilita il confronto tra CNC di costruttori diversi e la costruzione di indicatori specifici per il reparto.
Anche qui serve verificare il perimetro dei dati disponibili. Non tutte le implementazioni espongono le stesse informazioni e, per esigenze di tracciabilità o calcolo OEE, possono essere necessari segnali aggiuntivi dal PLC di linea o da sistemi di identificazione pezzo.
L’architettura conta quanto il protocollo
Un errore frequente è trattare il protocollo come l’unica decisione tecnica. In realtà, anche il miglior standard fallisce se l’architettura impone aperture di rete inutili, server locali da mantenere o accessi remoti non governati. La soluzione deve distinguere la rete OT, dove operano macchinari e PLC, dai servizi IT e cloud che elaborano i dati.
Un agente leggero on-premise può leggere i protocolli industriali nella rete autorizzata e inviare verso l’esterno solo le informazioni necessarie attraverso connessioni cifrate in uscita. Questo approccio limita la superficie di attacco, evita l’esposizione diretta dei PLC a Internet e riduce l’infrastruttura da amministrare nello stabilimento. Per aziende che cercano un MES cloud-native, è un criterio pratico quanto la compatibilità protocollare.
Sicurezza, continuità e qualità del dato
La sicurezza non coincide con il semplice uso di OPC UA o MQTT con TLS. Occorrono segmentazione di rete, account dedicati, privilegi minimi, gestione dei certificati, logging degli accessi e una chiara politica su chi può leggere o scrivere dati. Nella maggior parte dei progetti MES, la raccolta deve essere in sola lettura: intervenire sui comandi macchina richiede valutazioni di sicurezza funzionale e responsabilità molto diverse.
La continuità operativa richiede inoltre di gestire ciò che accade quando la connettività esterna cade. I dati critici devono poter essere temporaneamente memorizzati e trasmessi al ripristino, con timestamp affidabili e regole contro i duplicati. Senza questo presidio, un dashboard può apparire aggiornato mentre i totali di produzione risultano incompleti.
Infine, nessun protocollo corregge un segnale di origine sbagliato. Se lo stato “macchina in marcia” resta attivo durante un fermo, l’OEE sarà falsato. Il progetto deve prevedere un collaudo sul campo con produzione, manutenzione e automazione: confronto tra contapezzi PLC e pezzi reali, verifica degli scarti, classificazione degli allarmi e validazione delle causali di fermo.
Una scelta pragmatica per un parco macchine misto
Per molte aziende manifatturiere la combinazione più efficace è usare il protocollo nativo più affidabile per ogni macchina e un’unica piattaforma per normalizzare i dati. Siemens S7 per i PLC Siemens, Modbus TCP/IP per dispositivi e macchine compatibili, OPC UA dove serve un modello interoperabile, EtherNet/IP per ecosistemi Rockwell, MTConnect per CNC e MQTT per il trasporto controllato al cloud.
PLCinCloud adotta proprio questa logica: connettività industriale estesa, agente leggero in stabilimento e servizi accessibili via browser, senza richiedere una nuova infrastruttura server locale. Il risultato atteso non è una collezione di connessioni tecnicamente corrette, ma dati di produzione utilizzabili per avanzamenti ERP, KPI real-time, tracciabilità e documentazione Transizione 4.0.
La domanda da porre al prossimo progetto non è “qual è il protocollo migliore in assoluto?”, ma “quale collegamento porta il dato giusto, con il minor impatto sulla macchina e con una gestione sostenibile negli anni?”. È da questa risposta che un impianto connesso comincia a generare controllo operativo reale.