Come funziona l'IoT, dal sensore al cloud?

Il modo più chiaro per capire un sistema IoT è seguire una singola misura dal momento in cui una grandezza fisica cambia al momento in cui qualcuno agisce di conseguenza. Ogni installazione, da una presa intelligente a una raffineria, ripete lo stesso percorso.

Prendiamo un esempio concreto: un sensore di temperatura in una cella frigorifera. Il proprietario vuole ricevere un SMS se la cella si scalda troppo e vuole poter accendere da remoto un compressore di riserva. Questa guida segue quella lettura attraverso ogni fase, nomina i componenti coinvolti e spiega le decisioni che si prendono a ogni passaggio.

Le fasi sono: rilevare, elaborare in locale, trasmettere, aggregare su un gateway, consegnare tramite un protocollo, acquisire in una piattaforma, archiviare e analizzare, agire. Il percorso di ritorno, da un comando nel cloud a un relè sul dispositivo, attraversa le stesse fasi al contrario.

Come fa il rilevamento a trasformare la fisica in numeri?

Un sensore è un trasduttore. Un termistore cambia la propria resistenza elettrica con la temperatura; un chip di temperatura digitale misura quella resistenza al proprio interno ed espone un numero su un bus seriale. In entrambi i casi il microcontrollore del dispositivo deve leggerlo: attraverso un convertitore analogico-digitale per un componente analogico, oppure attraverso un bus come I2C o SPI per uno digitale.

Qui si prendono due decisioni. La prima è la frequenza di campionamento: ogni quanto leggere. La temperatura di un frigorifero cambia lentamente, quindi una lettura al minuto è più che sufficiente, e leggere meno spesso fa risparmiare energia. La seconda riguarda calibrazione e filtraggio: le letture grezze sono rumorose, quindi il firmware di solito fa la media di più campioni o scarta i valori anomali prima di riferire.

Come decide il dispositivo che cosa inviare?

Il firmware del dispositivo ora ha un numero. Può inviare ogni lettura oppure essere selettivo. Inviare solo quando il valore cambia più di una certa soglia, o solo quando supera un limite di allarme, riduce drasticamente il traffico radio. Su un dispositivo a batteria la radio è il componente che consuma più energia, quindi è in questo passaggio che l’autonomia della batteria si guadagna o si perde.

Tra una lettura e l’altra, un dispositivo ben progettato entra in deep sleep e si risveglia con un timer. Il rapporto tra tempo attivo e tempo in sleep è il duty cycle, ed è un duty cycle ridotto a permettere a un sensore di funzionare per anni con una batteria a bottone.

La lettura viene impacchettata in un payload. Per un collegamento a risorse limitate possono essere pochi byte in un formato binario compatto; per un dispositivo Wi-Fi è spesso un piccolo oggetto JSON:

{"t": 4.8, "ts": 1760690400, "bat": 92}

Come funziona il primo salto radio?

La radio del dispositivo ora invia il payload. Quale radio dipende dalle esigenze di portata, consumo e banda, un compromesso trattato nella panoramica sulla connettività. Per una cella frigorifera dentro un edificio le opzioni comprendono il Wi-Fi direttamente verso il router della sede, Zigbee o Thread verso un hub vicino, oppure LoRaWAN verso un gateway che potrebbe trovarsi sul tetto di un altro edificio.

Il Wi-Fi consuma molto ma non richiede hardware aggiuntivo. Zigbee e Thread consumano pochissimo ma hanno bisogno di un hub. LoRaWAN arriva lontano con un’energia minima, ma trasporta solo pochi byte alla volta.

Che cosa fa il gateway?

A meno che il dispositivo non parli IP in modo nativo su Wi-Fi, Ethernet o rete cellulare, qualcosa deve fare da tramite tra la rete radio locale e internet. Quel qualcosa è il gateway. Un hub per la smart home, un gateway LoRaWAN e un gateway edge industriale svolgono tutti lo stesso ruolo: ricevere frame da molti dispositivi da un lato e inoltrarli come pacchetti IP dall’altro.

I gateway spesso fanno più che inoltrare: mettono i dati in un buffer quando l’uplink è assente, convertono protocolli come Modbus in MQTT ed eseguono regole locali, così che un allarme scatti anche se internet non funziona. È qui che comincia l’edge computing.

Quale protocollo parla con la piattaforma?

Una volta che esiste un percorso IP, il dispositivo o il gateway ha bisogno di un protocollo applicativo per consegnare il payload. La scelta più comune per la telemetria è MQTT. Il dispositivo pubblica il payload su un topic come site/coldroom-1/temperature presso un broker; chiunque sia interessato sottoscrive quel topic. Lo schema publish-subscribe fa sì che il dispositivo non debba sapere chi consuma i suoi dati, e il broker gestisce le garanzie di consegna attraverso i livelli di QoS.

Per i dispositivi con risorse molto limitate, CoAP su UDP è più leggero. I dispositivi con risorse abbondanti a volte usano semplicemente HTTP. In ogni caso la connessione va cifrata con TLS o DTLS, e il dispositivo deve dimostrare la propria identità con un certificato o un token rilasciato durante il provisioning.

Che cosa succede in acquisizione, archiviazione e analisi?

La piattaforma IoT riceve il messaggio. Il suo primo compito è l’acquisizione dei dati (ingestion): autenticare il mittente, convalidare il payload, aggiungere metadati come il cliente e la sede a cui il dispositivo appartiene, e passare il record alla fase successiva.

Le letture finiscono in un database di serie temporali, ottimizzato per dati in sola aggiunta indicizzati per tempo. La piattaforma può inoltre mantenere un device shadow, un piccolo documento che registra l’ultimo stato noto di ogni dispositivo, così che le applicazioni possano interrogarlo senza aspettare il rapporto successivo.

Un motore di regole o un processo di elaborazione in streaming valuta ogni lettura al suo arrivo. Nel nostro esempio la regola è semplice: se la temperatura supera un limite per più di qualche minuto, genera un avviso. Regole più complesse combinano più sensori, confrontano i valori con riferimenti storici o eseguono un modello di machine learning per il rilevamento delle anomalie. La guida alla pipeline di dati approfondisce queste fasi.

Come si chiude il cerchio?

La regola di allarme scatta. La piattaforma invia una notifica tramite un webhook a un servizio SMS e il proprietario riceve il messaggio. Una dashboard mostra l’andamento, così può valutare se il problema è una porta lasciata aperta o un compressore che sta cedendo.

Il proprietario tocca “avvia compressore di riserva” in un’app. Il comando percorre la strada inversa: l’app chiama l’API della piattaforma, la piattaforma pubblica un messaggio sul topic dei comandi del dispositivo, il broker lo consegna e il firmware del dispositivo pilota un relè attraverso un pin GPIO. Il dispositivo pubblica una conferma, così che lo shadow e l’app riflettano il nuovo stato.

Un dispositivo che resta in sleep per la maggior parte del tempo non può ricevere un comando finché non si risveglia, quindi il comando resta in attesa nello shadow finché il dispositivo non lo preleva.

Che cosa insegna questo percorso sulla progettazione?

Ogni fase ha il suo modo di fallire. I sensori sono soggetti a deriva. Le radio perdono pacchetti e i dispositivi devono ritentare senza inondare la rete. I gateway vanno offline e hanno bisogno di un buffer. I broker devono scalare. Le regole hanno bisogno di soglie che evitino sia gli allarmi mancati sia l’assuefazione agli avvisi.

Una buona ingegneria IoT consiste soprattutto nel prevedere questi guasti. Le domande da porsi per qualsiasi nuova installazione sono: che cosa succede se questo collegamento resta interrotto per un’ora, come fa il dispositivo a sapere che i suoi dati sono stati ricevuti, e come si correggerà il firmware una volta che mille unità sono sul campo. L’ultima è l’argomento della guida su gestione dei dispositivi e aggiornamenti OTA.

Per continuare

• Architettura IoT: i livelli formalizza le fasi descritte qui nel modello a livelli standard.
• MQTT spiegato tratta il protocollo su cui viaggia la maggior parte di questo traffico.
• La pipeline di dati IoT approfondisce che cosa succede dopo l’acquisizione.
• Tipi di dispositivi IoT e i vincoli che ne determinano la progettazione spiega il lato hardware di questi compromessi.

Argomenti: basi IoT, architettura, telemetria, fondamenti