Speciale IoT

Da Modbus RTU a MQTT — conversione e bridge industriale

Conversione da Modbus RTU a MQTT JSON: QoS 0/1/2, TLS, AWS IoT Core, Azure IoT Hub, Mosquitto, Sparkplug B. Architettura, configurazione e sicurezza. Guida Eziwan.

In breve
Un bridge Modbus RTU → MQTT verifica le vostre apparecchiature RS485/RS232 tramite polling Modbus, incapsula ogni misura in un messaggio JSON MQTT con timestamp, QoS configurabile e crittografia TLS 1.3, quindi pubblica i dati sul broker MQTT di tua scelta (AWS IoT Core, Azure, HiveMQ, Mosquitto o Eziwan). La conversione è completamente configurabile senza codice.

Perché convertire Modbus RTU in MQTT?​

Modbus RTU è il linguaggio delle macchine. MQTT è il linguaggio del cloud. Il bridge Modbus RTU → MQTT funge da ponte tra questi due mondi: consente alle vostre apparecchiature industriali legacy di comunicare con le moderne piattaforme IoT senza alcuna modifica all’impianto esistente.

Vantaggi di MQTT per il trasferimento dei dati industriali:

  • Leggerezza: intestazione di almeno 2 byte, ideale per il 4G e le connessioni costose
  • Publish/subscribe: separazione tra produzione (gateway) e consumo (dashboard, API)
  • Sessione persistente: i messaggi vengono messi in coda durante le interruzioni di rete
  • QoS configurabile: garanzia di consegna adeguata a ogni tipo di dato
  • TLS nativo: crittografia e autenticazione senza sovrapposizione applicativa

Architettura del bridge Modbus RTU → MQTT​

Il bridge funziona in due fasi distinte e indipendenti:

Fase 1 — Acquisizione Modbus RTU (lato campo) Il gateway funge da master Modbus. Invia richieste di lettura (FC01/02/03/04) agli slave RS485 secondo una pianificazione di polling configurabile. Ogni risposta viene decodificata, normalizzata e contrassegnata con data e ora a livello locale.

Fase 2 — Pubblicazione MQTT (lato cloud) I valori decodificati vengono incapsulati in messaggi JSON e pubblicati sul broker MQTT. Se la connessione non è disponibile, i messaggi vengono memorizzati temporaneamente in locale (72 ore) e ritrasmessi al momento della riconnessione con il loro timestamp originale.

Bus RS485, gateway Eziwan, broker MQTT
──────────               ──────────────────              ────────────
Esclave 1 ──┐            ┌── Modbus RTU master           AWS IoT Core
Esclave 2 ──┤── RS485 ──►│   Polling FC03/FC04    MQTT  Azure IoT Hub
Esclave 3 ──┤            │   Decode + Scale      ──TLS►  HiveMQ
Esclave n ──┘            └── JSON builder                Mosquitto
                              Buffer 72h                  Eziwan Cloud

Struttura dei topic MQTT per Modbus RTU​

L’organizzazione dei topic MQTT è fondamentale per la manutenibilità e l’integrazione:

Codice raccomandato:

{sito}/{area}/{attrezzatura}/{tag}

Esempi:

usine/atelier_a/variateur_01/frequence_hz
usine/atelier_a/variateur_01/courant_a
usine/tgbt/compteur_principale/puissance_active_kw
usine/tgbt/compteur_principale/energie_kwh

Argomenti dei metadati (Sparkplug B):

spBv1.0/fabbrica/NBIRTH/passerella_01 ← Messaggio di connessione
spBv1.0/fabbrica/NDATA/gateway_01 ← Dati di processo
spBv1.0/fabbrica/NDEATH/passerella_01 ← Disconnessione (LWT)

Broker MQTT compatibili​

Il gateway Eziwan è compatibile con i principali broker MQTT presenti sul mercato:

BrokerHostingProtocolloCasi d’uso
AWS IoT CoreCloud AWSMQTT TLSIntegrazione AWS (Lambda, S3, Timestream)
Azure IoT HubCloud AzureMQTT / AMQPIntegrazione Azure (Stream Analytics, Cosmos DB)
HiveMQ CloudCloud gestitoMQTT 5.0 + TLSSparkplug B, UNS, multi-broker
MosquittoSelf-hostedMQTT 3.1.1SCADA locale, latenza minima
Eziwan CloudCloud gestitoMQTT TLSSoluzione chiavi in mano, dashboard integrata

Gestione della disconnessione e del buffering​

Le reti industriali (4G, Wi-Fi in ambienti difficili) sono soggette a interruzioni. Il bridge Modbus RTU → MQTT gestisce questa situazione tramite:

  • Last Will Testament (LWT): messaggio automatico inviato dal broker quando il gateway si disconnette
  • Sessione persistente: il broker conserva le sottoscrizioni e i messaggi QoS 1/2 in attesa
  • Buffer locale: il gateway memorizza le misurazioni nella memoria flash durante l’interruzione
  • Risincronizzazione: al momento della riconnessione, i messaggi vengono ritrasmessi in ordine cronologico

Questo meccanismo garantisce nessuna perdita di dati anche in caso di interruzioni prolungate della rete — un aspetto fondamentale per le applicazioni di misurazione del consumo energetico o di monitoraggio della produzione.

Integrazione con i TSDB cloud​

I dati MQTT vengono generalmente memorizzati in un database di serie temporali (Time Series Database):

  • InfluxDB: open source, eccellente per le metriche industriali
  • AWS Timestream: serverless, integrato con AWS IoT Core
  • Azure Data Explorer: prestazioni elevate per grandi volumi
  • TimescaleDB: PostgreSQL esteso, SQL nativo
  • Eziwan Storage: archiviazione inclusa, conservazione configurabile

Dal TSDB, i dati vengono utilizzati per alimentare i dashboard Grafana, i report sulle prestazioni e i modelli di manutenzione predittiva.

Domande frequenti

Da consultare anche