Un gateway IoT industriale è un dispositivo, oppure un software su un piccolo computer industriale, che si colloca tra le macchine in reparto e i sistemi che hanno bisogno dei loro dati. Legge i valori da PLC, azionamenti e contatori nei protocolli che questi parlano, li traduce in un formato comprensibile per i sistemi IT e cloud e li inoltra in modo sicuro, di solito senza che nessuno debba modificare le macchine.

Se i dati dei PLC e delle macchine devono finire in una dashboard, in un historian o in un sistema di manutenzione, la maggior parte delle decisioni pratiche riguarda il gateway. Quali protocolli deve leggere? Quanta elaborazione conviene fare vicino alla macchina? E in quale punto della rete di stabilimento va collocato perché non diventi l’anello debole? Questo articolo le affronta una per una, in quest’ordine.

In breve

  • Un gateway legge da un lato protocolli industriali come Modbus, OPC UA o EtherNet/IP e dall’altro pubblica i dati, spesso tramite MQTT.
  • Inoltre memorizza i dati in un buffer quando la connessione cade e mantiene la rete di controllo chiusa verso l’esterno.
  • L’edge computing sul gateway riduce i dati grezzi ad alta frequenza ai soli valori rilevanti prima che escano dallo stabilimento.
  • L’hardware dei gateway per la fabbrica è pensato per i quadri elettrici: guida DIN, 24 V DC, ampio intervallo di temperatura, porte seriali e più porte Ethernet.

Come funziona un gateway IoT industriale?

Basta seguire un singolo valore attraverso un gateway per capire quali compiti svolge. Supponiamo di voler leggere la corrente del motore di un estrusore, che il suo PLC misura già.

Il lato southbound del gateway si collega alla macchina. Dispone di driver per i protocolli industriali: Modbus RTU su linea seriale RS-485, Modbus TCP, OPC UA, EtherNet/IP, PROFINET o protocolli proprietari come Siemens S7. Lo si configura per leggere il registro del PLC o il nodo OPC UA che contiene la corrente del motore, e con quale frequenza, per esempio una volta al secondo.

Poi il gateway dà un significato al numero grezzo. Un registro Modbus potrebbe contenere 1.523, che il programmatore del PLC intendeva come 152,3 ampere. Il gateway applica la scalatura, aggiunge un nome, un’unità di misura e un timestamp, e può scartare o combinare valori secondo le regole impostate.

In questa fase il polling richiede una certa attenzione. La capacità di comunicazione di un PLC è condivisa con tutto ciò che dialoga con il PLC, compresi HMI e SCADA. Leggere duecento registri sparsi una volta al secondo, una richiesta alla volta, può rallentare quelle altre connessioni. Un gateway ben configurato raggruppa i registri vicini in un’unica richiesta, legge i valori che cambiano lentamente, come le temperature, ogni qualche secondo anziché a ogni ciclo e pubblica un valore solo quando varia oltre una certa soglia, detta banda morta (deadband).

Segue il lato northbound, da cui i dati escono. La maggior parte dei gateway moderni pubblica tramite MQTT, un protocollo publish/subscribe leggero in cui i dispositivi inviano messaggi a un broker su topic denominati e qualsiasi sistema autorizzato può sottoscriverli. Alcuni offrono anche HTTPS, OPC UA verso altri sistemi dello stabilimento oppure Sparkplug B, una specifica che standardizza topic e payload MQTT per l’uso industriale.

Altri due compiti si svolgono silenziosamente in background. Il buffering store-and-forward conserva i messaggi quando la connessione di rete cade e li invia, con i timestamp originali, quando torna disponibile. E poi c’è la sicurezza: è il gateway ad aprire connessioni cifrate in uscita, quindi nulla all’esterno dello stabilimento ha bisogno di una via d’ingresso.

I gateway si presentano in molte forme, dai flussi Node-RED su un PC industriale a Modbus2MQTT, all’hardware Moxa e Advantech, fino a software edge commerciali come Ignition Edge. Ognuno di questi si collega a Kilo indirizzando la propria uscita MQTT verso un broker: Cloud MQTT, che Kilo predispone per l’utente e che accetta solo connessioni cifrate con TLS, oppure un broker proprio tramite External MQTT. Si decide poi come ogni messaggio trova il proprio dispositivo in Kilo, in base al topic o a un ID dispositivo all’interno del payload JSON. Se le macchine espongono un server OPC UA, un bridge che si sottoscrive ai suoi nodi e pubblica JSON tramite MQTT è la strada abituale per collegare apparecchiature OPC UA in questo modo.

Come progettare una rete IoT industriale

Una rete IoT industriale deve fare due cose che tirano in direzioni opposte: far uscire facilmente i dati dallo stabilimento e mantenere protetto il sistema di controllo. Un’architettura IoT industriale a livelli risolve il conflitto stabilendo dove si trova ogni dispositivo e in quale direzione il traffico può scorrere.

Lo schema a cui arriva la maggior parte degli stabilimenti è questo, partendo dalla macchina verso l’esterno:

  • Reti di macchina e di cella. PLC, azionamenti, I/O remoti e HMI comunicano sul proprio bus di campo o Ethernet industriale. È qui che avviene il controllo in tempo reale, e nulla a questo livello dovrebbe dipendere dal cloud.
  • Rete di controllo dello stabilimento. Server SCADA, postazioni di engineering e sistemi a livello di linea collegano le celle. I firewall la separano dalla rete degli uffici.
  • DMZ industriale. Una zona cuscinetto tra la rete di controllo e la rete aziendale. Il gateway si trova spesso qui, oppure a cavallo del confine con una porta di rete su ciascun lato, così può leggere dai controllori e pubblicare verso l’esterno senza instradare traffico tra le due reti.
  • Rete aziendale e cloud. ERP, sistemi di manutenzione, dashboard e piattaforme cloud ricevono i dati.

Le regole del traffico discendono dallo schema. Il gateway apre le connessioni verso i controllori all’interno e verso il broker all’esterno; nulla all’esterno apre una connessione verso l’interno. Se un sistema cloud deve inviare un comando a un’apparecchiatura, quel comando dovrebbe comunque arrivare attraverso la connessione in uscita del gateway, ed è il controllore locale della macchina a decidere se accettarlo.

I sensori wireless aggiungono un percorso parallelo. I sensori a batteria che monitorano vibrazioni o temperatura su macchine più vecchie trasmettono di solito a un gateway LoRaWAN o a una stazione base mioty, che inoltra i loro messaggi a un network server. Questo percorso non tocca mai la rete di controllo, ed è uno dei motivi per cui i retrofit su impianti esistenti lo usano spesso.

Una verifica pratica del progetto consiste nel disegnare ogni freccia su un’unica pagina: ogni dispositivo, la rete in cui si trova e la direzione in cui viene aperta ogni connessione. Se una freccia punta da internet verso la rete di controllo, il progetto va rivisto.

Edge computing vs cloud nell’IoT industriale

Edge computing nell’IoT industriale significa elaborare i dati sul gateway o vicino a esso, prima che escano dallo stabilimento. Il cloud, o un data center centrale, si occupa di ciò che richiede dati da molte macchine o siti. La maggior parte dei progetti usa entrambi, quindi la domanda utile è quale compito vada dove.

I dati di vibrazione mostrano bene i vantaggi dell’elaborazione edge. Un sensore di vibrazione campionato 10.000 volte al secondo produce 864 milioni di campioni al giorno. A due byte per campione, sono circa 1,7 GB al giorno per un solo asse di misura su una sola macchina. Inviarli al cloud per uno stabilimento con cento cuscinetti monitorati non è né economico né utile. Un dispositivo edge che calcola una volta al minuto la velocità di vibrazione RMS e qualche valore spettrale invia invece 1.440 serie di numeri al giorno e conserva la forma d’onda grezza in locale per l’analista che ne abbia bisogno.

Lo stesso ragionamento vale per i normali valori di processo. Il livello di un serbatoio letto ogni secondo ma pubblicato solo quando varia di oltre lo 0,5% potrebbe generare qualche centinaio di messaggi al giorno anziché 86.400, senza perdere nulla su cui una persona interverrebbe. Scegliere quelle bande morte segnale per segnale è una delle impostazioni edge più utili, e una di quelle più spesso lasciate al valore predefinito.

Compito Meglio nell’edge Meglio nel cloud
Ridurre i segnali ad alta frequenza a grandezze caratteristiche Sì
Buffering durante le interruzioni di rete Sì
Reazioni locali rapide (millisecondi) Sì, ma il controllo resta nel PLC
Confrontare macchine tra linee e siti Sì
Storico e reportistica di lungo periodo Sì
Avvisi che devono raggiungere le persone ovunque si trovino Sì
Aggiornare la logica di molti siti contemporaneamente Sì

Dalla tabella derivano due regole pratiche. Tutto ciò che deve funzionare quando internet non è disponibile va nell’edge o nel PLC. Tutto ciò che richiede una visione d’insieme su macchine, siti o mesi va gestito a livello centrale. Le funzioni di sicurezza non vanno in nessuno dei due: restano nei controllori di sicurezza dedicati.

Quale hardware serve per l’IoT industriale?

L’hardware IoT industriale per un progetto in stabilimento si riduce di solito a tre tipi di dispositivo: gateway per le apparecchiature cablate, sensori per ciò che non viene ancora misurato e gateway radio per i sensori wireless.

Per un gateway che legge i PLC conviene cercare caratteristiche adatte a un quadro elettrico più che a un ufficio:

  • montaggio su guida DIN e ingresso di alimentazione a 24 V DC, così si installa accanto al PLC e ne condivide l’alimentazione;
  • un intervallo di temperatura di esercizio adeguato al quadro, che in uno stabilimento caldo può superare i 50 °C;
  • porte seriali RS-485 per le apparecchiature Modbus RTU più vecchie, più almeno due porte Ethernet per tenere separate la rete di controllo e quella in uscita;
  • memoria sufficiente a conservare in buffer diversi giorni di dati durante un’interruzione;
  • secure boot e aggiornamenti firmware firmati, così il gateway non può essere riprogrammato di nascosto;
  • un produttore che pubblichi aggiornamenti di sicurezza per tutta la vita del dispositivo.

Il gateway non deve per forza essere un dispositivo dedicato. Il software del gateway può girare anche su un PC industriale già presente nel quadro, oppure in una macchina virtuale su un server di stabilimento, soluzione adatta ai siti che adottano un’unica piattaforma hardware per molti scopi. Il compromesso riguarda la responsabilità: un gateway dedicato ha un solo compito e un solo ciclo di aggiornamento, mentre l’hardware condiviso richiede un accordo tra OT e IT su chi lo aggiorna e quando.

Molte macchine hanno anche segnali che nessuno misura ancora: la temperatura di un cuscinetto, il livello di un serbatoio, lo stato di marcia di un motore. In questi casi i sensori wireless a batteria evitano nuovi cablaggi, e un solo gateway radio montato in alto nel capannone di solito può coprire un intero edificio.

Anche le apparecchiature più vecchie che parlano solo Modbus si possono collegare tramite piccoli convertitori che ne leggono i registri e inoltrano i valori. Kilo Electronics offre dispositivi Modbus per questo tipo di collegamento.

Domande frequenti sui gateway IoT industriali

Che differenza c’è tra un gateway IIoT e un router?

Un router inoltra pacchetti di rete tra reti diverse senza comprenderne il contenuto. Un gateway IIoT comprende i protocolli industriali: legge valori specifici dalle macchine, li converte, li etichetta e li pubblica in un nuovo formato. Alcuni dispositivi uniscono entrambe le funzioni in un unico apparecchio.

Un PLC può fare da gateway IoT industriale?

In parte. Molti PLC più recenti includono un server OPC UA o un client MQTT, quindi possono condividere i dati direttamente. Un gateway separato resta comunque frequente quando uno stabilimento ha controllori di produttori o generazioni diverse, perché offre un unico punto di connessione coerente e lascia il processore del PLC concentrato sul controllo.

I gateway IoT industriali supportano Sparkplug B?

Molti sì. Sparkplug B, gestito dalla Eclipse Foundation, definisce una struttura dei topic, un formato di payload binario compatto e messaggi di “birth” e “death” che comunicano ai sottoscrittori quando un dispositivo va online o si disconnette. Sapere sempre in che stato si trova ogni dispositivo è il suo principale vantaggio rispetto a un semplice MQTT con JSON personalizzato.

Si sceglie una macchina il cui PLC espone già i dati tramite Modbus TCP o OPC UA e le si affianca un gateway che pubblica quattro tag tramite MQTT: corrente del motore, velocità, una temperatura e un codice di guasto. Si visualizzano in un grafico in Kilo con il piano gratuito, poi si scollega per un’ora il cavo in uscita del gateway e si osserva se il suo buffer invia le letture mancanti quando la connessione torna disponibile.