La piramide classica e i suoi limiti
La letteratura descrive l'architettura IoT come una piramide: device → gateway → cloud → applicazione. Funziona, ma applicata rigidamente crea sistemi fragili — ogni nuovo dispositivo richiede modifiche al gateway, ogni nuovo requisito di reporting tocca il cloud, ogni cambiamento si propaga su tutti i livelli.
Un'architettura IoT agile separa i concern in modo che cambiarli non richieda di toccare tutto il sistema. Il collante che rende possibile questo è il design event-driven.
I livelli dell'architettura di riferimento
Perché l'edge non è opzionale
In molti sistemi IoT industriali, la connessione Internet non è garantita. Interruzioni di rete che durano ore sono normali in contesti di fabbrica, campo agricolo o installazione remota. L'edge layer non è un'ottimizzazione: è un requisito di resilienza.
Ma il motivo più rilevante per elaborare all'edge non è la resilienza — è la latenza. Alcune decisioni non possono aspettare un round-trip verso il cloud: l'arresto di emergenza di un macchinario, il cambio di setpoint in risposta a un sensore di pressione, il filtro anti-rimbalzo su un segnale digitale. Queste logiche devono vivere localmente, vicino al dato.
Tutto ciò che richiede una risposta in meno di 100ms appartiene all'edge. Tutto ciò che richiede dati storici o correlazione tra più sorgenti appartiene al cloud. La linea di confine tra i due non è mai perfetta — ma averla esplicita evita architetture che falliscono silenziosamente.
MQTT e la gerarchia dei topic
MQTT è il protocollo dominante per l'IoT industriale perché è progettato per connessioni instabili (QoS 0/1/2, Last Will and Testament), è leggero su dispositivi con risorse limitate, e il modello publish/subscribe disaccoppia naturalmente produttori e consumatori.
La gerarchia dei topic diventa il primo schema dati del sistema. Un design tipico:
bw/{plant}/{machine}/{sensor}/telemetry— dati di telemetriabw/{plant}/{machine}/status— stato del dispositivobw/{plant}/{machine}/command— comandi verso il dispositivobw/{plant}/{machine}/alert— allarmi e notifiche
Una gerarchia mal progettata è difficile da modificare senza rompere i consumer esistenti. Vale la pena investire tempo qui prima che il sistema vada in produzione.
Il digital twin come pattern architetturale
Il digital twin — la rappresentazione digitale in tempo reale di un asset fisico — non è solo una buzzword. È un pattern architetturale utile: centralizza lo stato di un asset, espone un'API uniforme indipendentemente da come i dati arrivano, e diventa il punto di integrazione per tutti i sistemi che devono conoscere quello stato.
Invece di avere ogni sistema (dashboard, alerting, ERP) che legge direttamente dal broker MQTT, leggono tutti dallo stesso "gemello digitale" — che è l'unica fonte di verità sullo stato attuale dell'asset fisico.
L'approccio MVP: come avvicinarsi per gradi
Un progetto IoT non si consegna tutto insieme. L'approccio che funziona:
- MVP: un sensore, un dato, una dashboard. Verifica che l'architettura regga e che gli utenti trovino il dato utile. Dura 4-6 settimane.
- Expand: aggiungi asset, sensori, metriche. Il transport layer e il cloud non cambiano — solo nuovi publisher MQTT e nuove visualizzazioni.
- Enrich: aggiungi ML per anomaly detection, alerting intelligente, integrazione con ERP. Il dato c'è già — ora gli dai un cervello.
Ogni step ha un deliverable misurabile. Se lo step 1 non produce valore, non si spende su step 2 e 3. Questa è l'agilità applicata all'IoT.
Event-driven: il collante che rende il sistema modificabile
Il principio event-driven significa che i componenti comunicano attraverso eventi pubblicati su un bus (MQTT, Kafka), non attraverso chiamate dirette. Aggiungere un nuovo consumer — un sistema di allerta, un modello ML, un'integrazione ERP — non richiede di modificare il producer.
Questo è esattamente quello che serve in un sistema che deve evolvere: la capacità di aggiungere nuovi comportamenti senza toccare quelli esistenti.