Un dato OEE calcolato su un segnale letto con frequenza errata, un fermo macchina senza causa codificata o un contapezzi non allineato con l'ERP non sono semplici problemi di dashboard. Sono segnali di un'interconnessione incompleta. I protocolli industriali moderni determinano come i dati passano da PLC e macchinari...
Protocolli industriali moderni: cosa cambia davvero
Il protocollo non è un dettaglio riservato all'automazione. Definisce quali dati sono accessibili, con quale frequenza possono essere letti, come vengono identificati e con quali meccanismi sono protetti. In una fabbrica con linee di età, fornitori e tecnologie diverse, è il punto di contatto fra mondo OT e mondo IT.
Occorre però distinguere tre livelli che spesso vengono confusi. Il primo è il trasporto del dato: come un dispositivo comunica in rete. Il secondo è il modello informativo: cosa rappresenta un tag, un allarme, un ordine di produzione o lo stato di una macchina. Il terzo è l'integrazione applicativa: come il dato viene reso disponibile a MES, ERP, database o strumenti di analisi.
Un protocollo può risolvere molto bene il primo livello senza offrire una semantica ricca sul secondo. Modbus TCP/IP ne è un esempio: è diffuso, semplice da implementare e adatto a molti dispositivi, ma espone principalmente registri. Per trasformare quei registri in informazioni operative occorre conoscere gli indirizzi, le scale, le unità di misura e la logica della macchina.
La scelta, quindi, non dovrebbe partire dalla domanda "qual è il protocollo migliore?". La domanda corretta è: quali dati servono, da quali asset, per quale processo decisionale e con quale affidabilità?
I protocolli più usati e il loro ruolo in fabbrica
Siemens S7 e Modbus TCP/IP: accesso diretto ai dati di campo
Nelle aziende manifatturiere italiane, Siemens S7 è spesso il punto di partenza per l'acquisizione dei dati da PLC. La possibilità di leggere variabili di processo, contatori, stati, ricette e allarmi consente di costruire una visione reale della macchina, senza richiedere modifiche invasive al ciclo di automazione. La qualità del progetto dipende dalla mappatura dei tag: un bit di marcia non coincide necessariamente con lo stato produttivo, e un contatore può dover essere gestito in caso di reset o cambio formato.
Modbus TCP/IP rimane essenziale per connettere dispositivi eterogenei: inverter, strumenti di misura, sistemi di refrigerazione, periferiche e PLC di diversi costruttori. Il suo vantaggio è l'ampia compatibilità. Il limite è che la struttura a registri richiede una documentazione accurata e una normalizzazione a valle. Se due macchine espongono entrambe un registro 40001, non significa che descrivano lo stesso valore.
In entrambi i casi è utile definire una convenzione comune per nomi, unità, stati e causali. Questa attività evita che il MES riceva migliaia di tag tecnici senza poterli trasformare in KPI coerenti.
OPC UA: interoperabilità con contesto e sicurezza
OPC UA è adatto quando l'obiettivo non è solo leggere variabili, ma costruire un'integrazione più strutturata tra sistemi. Supporta meccanismi di autenticazione, cifratura, certificati e un modello informativo che può descrivere oggetti, proprietà, metodi ed eventi. Questo permette di esporre non solo un valore, ma anche il suo contesto: qualità del dato, timestamp, stato della risorsa e relazione con altri elementi dell'impianto.
Non tutte le implementazioni OPC UA, tuttavia, offrono lo stesso livello di dettaglio. Una macchina può pubblicare poche variabili essenziali, un'altra un albero informativo completo. Prima di definire l'architettura è necessario verificare il server disponibile, le licenze, il numero di connessioni supportate e la qualità della modellazione esposta dal costruttore.
OPC UA è particolarmente efficace nelle integrazioni fra macchine recenti, sistemi SCADA e piattaforme MES. Non sostituisce automaticamente i protocolli già presenti sul campo: spesso agisce come livello di interoperabilità sopra tecnologie diverse.
EtherNet/IP, MQTT e MTConnect: casi d'uso distinti
EtherNet/IP è comune in impianti con automazione basata su tecnologie Rockwell Automation e sull'ecosistema CIP. È una scelta naturale dove il parco macchine e le competenze interne sono già orientati a questo standard. Per il collegamento a sistemi informativi occorre valutare con attenzione quali dati siano esposti e tramite quale componente dell'architettura.
MQTT risponde a un'esigenza diversa. È leggero e basato sul modello publish/subscribe: una sorgente pubblica un messaggio su un topic e gli applicativi interessati lo ricevono tramite un broker. È utile per inviare eventi, telemetria e dati da siti distribuiti, soprattutto quando si vuole limitare l'esposizione diretta dei dispositivi di campo. Da solo, però, MQTT non definisce il significato del payload. Senza regole condivise su topic, struttura dei messaggi, versioning e gestione delle eccezioni, si rischia di spostare la complessità invece di ridurla.
MTConnect è orientato alle macchine utensili e rende disponibili informazioni standardizzate su condizioni, componenti ed eventi di lavorazione. Può accelerare la raccolta dati in contesti CNC, ma va verificato sul singolo impianto: la disponibilità effettiva dei dati dipende dal controllo numerico, dalla versione software e dall'implementazione del costruttore.
Dal segnale al KPI: il passaggio che determina il valore
La connettività non produce automaticamente controllo operativo. Per calcolare OEE, tempi di ciclo, disponibilità, prestazioni, scarti e cause di fermo, i segnali devono essere contestualizzati. Il MES deve sapere quale ordine è in produzione, quale articolo è associato alla linea, quando inizia e termina un turno, come classificare una microfermata e quale soglia definisce un'anomalia.
Un errore frequente consiste nel campionare tutto alla stessa frequenza. I dati di consumo energetico, gli stati macchina e gli eventi di scarto non hanno la stessa natura. Per gli stati e gli allarmi è spesso preferibile una gestione a evento, con timestamp preciso. Per grandezze analogiche può essere sufficiente un campionamento periodico ragionato. Un polling troppo aggressivo può caricare inutilmente PLC e rete; uno troppo lento può perdere transizioni decisive per il calcolo dei tempi improduttivi.
Anche la qualità del dato merita una regola esplicita. Un valore assente, non aggiornato o fuori scala non deve diventare silenziosamente uno zero. La piattaforma di raccolta dovrebbe conservarne provenienza, timestamp e stato di validità, così che una dashboard non trasformi un problema di comunicazione in un apparente calo di produzione.
Un'architettura adatta a OT, IT e sicurezza
In un progetto industriale efficace, la macchina non deve essere esposta direttamente a Internet. La segmentazione delle reti, la separazione fra domini OT e IT, il controllo degli accessi e la tracciabilità delle connessioni sono requisiti operativi, non accessori di cybersecurity.
Un agente leggero on-premise può raccogliere i dati all'interno della rete di stabilimento e trasmetterli verso servizi cloud tramite connessioni in uscita controllate. Questo approccio riduce la necessità di server locali dedicati e semplifica manutenzione, backup e aggiornamenti. Va comunque dimensionato in base a numero di macchine, volume dei tag, frequenza di acquisizione, politica di buffering e continuità richiesta in caso di indisponibilità temporanea della connettività.
Per scenari Transizione 4.0, il progetto deve inoltre dimostrare interconnessione e scambio dati coerenti con i processi aziendali. Non basta collegare fisicamente un PLC alla rete. Occorrono evidenze di comunicazione con sistemi gestionali o di produzione, tracciabilità dei flussi e documentazione tecnica ordinata. Una raccolta dati progettata correttamente rende questa documentazione più verificabile e riduce le attività manuali in fase di audit.
Come scegliere senza costruire un'infrastruttura inutile
La selezione dei protocolli dovrebbe partire da un censimento pratico: controllori installati, versioni firmware, porte disponibili, documentazione, reti esistenti e dati realmente necessari. Solo dopo è utile definire il connettore o il gateway richiesto. Standardizzare un'architettura non significa imporre un unico protocollo a ogni macchina, ma adottare un unico modello di raccolta, normalizzazione e governo del dato.
Conviene iniziare da una linea rappresentativa, non necessariamente dalla più semplice. Una linea con cambi formato, fermi ricorrenti, scarti e integrazione con ordini di produzione permette di verificare subito se la soluzione gestisce i casi reali. Il risultato atteso non è una lista di tag letti, ma una disponibilità affidabile di KPI, eventi e tracciabilità utilizzabili da chi lavora in stabilimento.
Piattaforme come PLCinCloud combinano connettori per S7, Modbus TCP/IP, OPC UA, EtherNet/IP, MQTT e MTConnect con un'architettura cloud-native e un agente locale. Il vantaggio è concentrare l'attenzione sui risultati produttivi e sull'integrazione con i sistemi aziendali, anziché sulla manutenzione di server e componenti custom.
Il protocollo più adatto è quello che rende il dato disponibile, comprensibile e governabile nel tempo. Prima di aggiungere una nuova interfaccia alla fabbrica, vale la pena verificare una cosa molto concreta: quel collegamento permetterà al responsabile di produzione di capire domani perché una linea ha perso efficienza e di intervenire con dati affidabili?