Fondamenti AIoT · base

Che cos'è l'AIoT?

L'AIoT unisce dispositivi connessi e machine learning. Scopri cosa significa, dove gira l'intelligenza e quando vale la complessità in più.

A yellow robotic arm with a mechanical hand

Foto: Enchanted Tools / Unsplash

Dopo aver letto questo articolo saprai:

  • Spiegare cosa distingue un sistema AIoT da un IoT ordinario basato su regole
  • Confrontare l'inferenza eseguita nel cloud, all'edge e sul dispositivo
  • Decidere quando aggiungere un modello a un prodotto connesso vale la complessità
In questa pagina
  1. Come si definisce l’AIoT?
  2. Cosa cambia quando si aggiunge un modello?
  3. Dove gira l’intelligenza?
  4. Quali schemi ricorrono più spesso?
  5. Quando l’AIoT vale la pena, e quando no?
  6. Per continuare

AIoT è l’abbreviazione che indica la combinazione di intelligenza artificiale e Internet of Things. Il termine copre un’ampia gamma di sistemi, dal termostato che impara gli orari di una famiglia alla fabbrica che prevede i guasti dei cuscinetti dai dati di vibrazione, ma l’idea di fondo è sempre la stessa: i dispositivi connessi producono dati, e un modello addestrato trasforma quei dati in decisioni, sul dispositivo stesso o da qualche parte più a monte.

L’accoppiata conta perché le due tecnologie si coprono a vicenda i punti deboli. Un deployment IoT classico è bravo a raccogliere telemetria e pessimo a interpretarla; le dashboard si riempiono di numeri che nessuno legge. Il machine learning è bravo a trovare schemi, ma ha bisogno di un flusso costante di dati dal mondo reale, che è esattamente ciò che i sensori forniscono. Messi insieme, si ottengono sistemi capaci di notare, classificare e agire senza una persona che sorvegli ogni stream.

Questa guida dà una definizione operativa, spiega dove può risiedere l’intelligenza, elenca gli schemi che ricorrono più spesso nella pratica e, cosa altrettanto importante, descrive i casi in cui aggiungere AI a un prodotto connesso è un errore.

Come si definisce l’AIoT?

Un sistema AIoT ha tre ingredienti. Primo, ci sono oggetti dotati di sensori e spesso di attuatori: un motore, una telecamera, una serratura, una sonda per il terreno. Secondo, c’è la connettività che porta i dati da quegli oggetti verso il punto in cui verranno elaborati e riporta indietro i comandi. Terzo, c’è un modello che è stato addestrato sui dati invece di essere scritto a mano come insieme di regole fisse, e che esegue l’inferenza su dati nuovi per produrre un risultato: un’etichetta di classe, un punteggio, un riquadro di delimitazione (bounding box), un valore previsto o un’azione consigliata.

Il terzo ingrediente è ciò che distingue l’AIoT dall’IoT ordinario. Un motore di regole che invia un avviso quando la temperatura supera una soglia è automazione, non AI. Un modello che impara com’è il funzionamento “normale” di un particolare compressore e segnala le deviazioni è AI, perché il confine della decisione è venuto dai dati e non da un ingegnere che digita un numero.

Cosa cambia quando si aggiunge un modello?

Aggiungere un modello addestrato a un prodotto connesso cambia il problema ingegneristico in modi facili da sottovalutare.

La pipeline di dati diventa una pipeline di addestramento oltre che operativa. Servono dati etichettati, o almeno rappresentativi, prima del deployment, il che significa una fase di raccolta che su apparecchiature reali può durare settimane. L’addestramento del modello avviene di solito nel cloud o su una workstation, mentre l’inferenza avviene dove serve la decisione.

Il comportamento diventa probabilistico. Una regola scatta oppure no; un classificatore ha una confidenza, un tasso di falsi positivi e un tasso di falsi negativi. Le decisioni di prodotto devono tenerne conto, per esempio chiedendo una conferma quando la confidenza è bassa invece di agire subito.

Il sistema può degradare in silenzio. I sensori vanno in deriva, le macchine vengono revisionate, le stagioni cambiano, e un modello addestrato sui dati dell’anno scorso può diventare lentamente sbagliato. Questo fenomeno si chiama drift del modello, e per coglierlo serve un monitoraggio che la maggior parte delle piattaforme IoT non offre di serie. Le pratiche di riaddestramento, versionamento e nuovo deployment dei modelli vanno collettivamente sotto il nome di MLOps, e aggiungono un ciclo di vita sopra al ciclo di vita del dispositivo già esistente.

Dove gira l’intelligenza?

La scelta architetturale più importante in assoluto in un sistema AIoT è dove avviene l’inferenza. Le opzioni di massima sono tre, e la maggior parte dei deployment reali le combina.

Nel cloud

I dispositivi inviano in streaming dati grezzi o leggermente elaborati a un back end, e i modelli girano lì. È l’opzione più semplice da costruire e la più facile da aggiornare, perché il modello vive in un solo posto. Va bene quando le decisioni non sono critiche nei tempi, quando il modello è grande o quando il valore sta nel confrontare molti dispositivi tra loro. I costi sono la banda, la latenza, il calcolo nel cloud e la dipendenza dalla connettività.

All’edge

L’inferenza gira su un gateway o su un server locale vicino ai dispositivi, ed è l’argomento della guida all’edge AI. Così i dati grezzi restano in sede, cosa che conta per il video e per i deployment sensibili alla privacy, e il sistema continua a funzionare quando cade il collegamento a internet. Il compromesso è una flotta di macchine da gestire e modelli abbastanza piccoli da girarci sopra.

Sul dispositivo

Il modello gira sul microcontrollore o sul system on chip dentro l’oggetto stesso. È il dominio del TinyML spiegato e dei chip con una neural processing unit integrata. L’inferenza sul dispositivo offre la latenza più bassa e la privacy migliore, e permette ai dispositivi a batteria di decidere localmente cosa vale la pena trasmettere. I modelli coinvolti sono minuscoli, spesso compressi con la quantizzazione per stare in poche centinaia di kilobyte o meno.

Una regola pratica utile: spingere l’inferenza il più vicino possibile al sensore, per quanto lo consentono la dimensione del modello e la strategia di aggiornamento, e inviare a monte solo ciò che a monte serve davvero. La guida edge vs cloud vs fog tratta la versione generale di questa decisione.

Quali schemi ricorrono più spesso?

Una manciata di schemi AIoT copre la maggior parte dei deployment.

Il rilevamento delle anomalie impara una linea di base per un segnale e segnala gli scostamenti. È popolare perché non richiede esempi di guasti, che per definizione sono rari. È alla base della maggior parte dei prodotti di monitoraggio delle condizioni.

La manutenzione predittiva fa un passo in più e cerca di stimare quando un componente si guasterà, usando le firme di vibrazione, di corrente, di temperatura o acustiche. La guida alla manutenzione predittiva spiega i segnali e i modelli.

La visione artificiale (computer vision) trasforma le telecamere in sensori che contano persone, leggono manometri, ispezionano pezzi o rilevano intrusioni. Eseguirla in locale evita di inviare il video in streaming al cloud, come descritto nella guida alla visione sul dispositivo.

Il riconoscimento di parole chiave (keyword spotting) e gli altri compiti audio permettono a un dispositivo di ascoltare in continuo a bassissimo consumo e di risvegliare un sistema più grande solo quando sente qualcosa di rilevante.

La sensor fusion combina più modalità, per esempio un accelerometro e un microfono, per classificare un’attività o lo stato di una macchina in modo più affidabile di quanto farebbe ciascuno da solo.

Lo schema più recente è l’agente AI: un modello linguistico di grandi dimensioni (LLM) che legge lo stato dei dispositivi, ragiona su un obiettivo e richiama le funzioni dei dispositivi come strumenti. Gli agenti sono trattati nelle guide sulla smart home e sulla fabbrica.

Quando l’AIoT vale la pena, e quando no?

L’AI si guadagna il suo posto quando la decisione dipende da schemi difficili da scrivere come regole, quando il volume di dati è troppo grande perché le persone lo esaminino, o quando il valore sta nel reagire rapidamente sul posto. Un modello che rileva una pompa in via di guasto una settimana prima che si blocchi si ripaga la prima volta che ha ragione.

Non vale la pena quando basterebbe una soglia. Molti prodotti “basati su AI” sono motori di regole con un’etichetta di marketing, e la versione onesta è più economica e più facile da debuggare. È rischioso anche quando non si possono raccogliere dati di addestramento rappresentativi, quando il costo di una decisione sbagliata è alto e non c’è un essere umano nel ciclo, o quando il team non ha un piano per il monitoraggio e il riaddestramento dopo il lancio. Un modello che non viene mai aggiornato è un rischio in attesa che il mondo cambi.

Un percorso sensato è partire da telemetria e regole semplici, strumentare abbastanza bene da raccogliere dati di qualità e introdurre i modelli dove le regole mostrano chiaramente i loro limiti. La guida alla pipeline di dati descrive l’impianto che deve esistere prima che tutto questo funzioni.

Per continuare

Argomenti: AIoT, machine learning, edge AI, fondamenti

Diagramma