Perché MQTT si è affermato nell’IoT industriale
L’IoT industriale genera milioni di misurazioni al giorno: sensori che inviano dati ogni minuto, controllori che trasmettono stati ogni secondo, contatori che trasmettono i valori orari. Questi flussi di dati devono essere trasmessi in modo affidabile, leggero e sicuro.
MQTT risponde esattamente a queste esigenze:
- Ultraleggero — intestazione da 2 a 5 byte. HTTP/REST genera centinaia di byte di intestazioni per un payload di pochi byte.
- Connessione persistente — il gateway si connette una sola volta al broker e mantiene la connessione. Nessun handshake TCP per ogni messaggio.
- Publish/Subscribe — più abbonati (monitoraggio cloud, ERP, BI) possono ricevere gli stessi dati senza che il gateway ne sia a conoscenza.
- QoS configurabile — in base alla criticità dei dati.
- Resilienza — i messaggi vengono memorizzati se il client è temporaneamente disconnesso (retain, persistent session).
Architettura MQTT industriale
Argomenti MQTT: struttura e buone pratiche
Un topic MQTT è una catena gerarchica separata da /:
eziwan/{id_sito}/{attrezzatura}/{variabile}
Exemples :
eziwan/sito-pompaggio-01/controllore/pressione_di_mandata
eziwan/site-pompage-01/compteur/energie_kwh
eziwan/batiment-paris/cvc/temperature_zone_a
Buone pratiche di denominazione:
- Includere sempre l’identificativo del sito per filtrare per sito.
- Separare i tipi di dati (misura, stato, allarme, comando) in argomenti distinti.
- Utilizzare nomi leggibili, non codici oscuri.
- Evitare argomenti troppo generici (
eziwan/#) per gli abbonamenti in produzione.
Livelli di QoS: quale scelta per l’industria?
| QoS | Garanzia | Overhead | Utilizzo consigliato |
|---|---|---|---|
| 0 | Al massimo una volta (best-effort) | Minimo | Misurazioni frequenti (1/s), perdita accettabile |
| 1 | Almeno una volta (con conferma) | Basso | Monitoraggio standard, avvisi |
| 2 | Esattamente una volta (4 scambi) | Medio | Comandi, dati critici |
Per il monitoraggio IoT industriale tipico (misurazioni ogni 5-60 secondi), QoS 1 rappresenta il giusto compromesso: affidabilità sufficiente, overhead accettabile.
MQTT vs HTTP per l’IoT: confronto
| Criterio | MQTT | HTTP/REST |
|---|---|---|
| Modello | Pubblica/Sottoscrivi | Richiesta/Risposta |
| Overhead | 2–5 byte | 200–400 byte |
| Connessione | Persistente | Per richiesta (o keep-alive) |
| Invio dati | Nativo (subscribe) | Polling o WebSocket |
| Latenza | < 50 ms | 100–500 ms |
| Multi-abbonati | Nativo | Webhook/code esterne |
| Adatto all’IoT a bassa larghezza di banda | ★★★★★ | ★★ |
L’approccio Eziwan
L'Eziwan Gateway implementa un client MQTT che pubblica i dati Modbus/OPC UA raccolti sul broker MQTT dell'Eziwan Cloud. Gli argomenti vengono generati automaticamente in base alla configurazione di ciascuna apparecchiatura. Il trasporto è protetto tramite TLS con autenticazione tramite certificato client: non vengono mai effettuate connessioni MQTT non protette.
Per approfondire: Modbus Cloud, gateway IoT industriale e monitoraggio di siti remoti.