Un nodo di smart sensing non è definito dalla presenza di una rete neurale. È definito dalla sua capacità di acquisire, filtrare, interpretare e reagire localmente, con vincoli reali di tempo, energia e memoria. Nel 2026 questa capacità non è più teorica: i microcontrollori integrano estensioni vettoriali DSP e acceleratori neurali nello stesso die, i sensori MEMS eseguono algoritmi a bordo, e i framework di machine learning producono modelli che occupano pochi kilobyte. Ma il fatto che si possa fare non significa che convenga sempre farlo. La domanda progettuale vera non è “metto l’AI sul sensore?”, ma: dove elaboro cosa, con quale architettura, e perché.
Questo articolo affronta la questione dal punto di vista di chi progetta sistemi embedded per l’automazione e l’IIoT, partendo dalla distinzione che molti sottovalutano: cosa è DSP e cosa è AI, e quando serve davvero l’uno, l’altro, o entrambi.
DSP prima dell’AI: il livello che molti sottovalutano
Filtraggio, FFT e feature extraction
In vibrazioni, corrente, pressione, audio e segnali MEMS, gran parte del valore nasce ancora da catene di signal processing ben progettate. Denoising, decimazione, FFT, analisi a inviluppo, estrazione di feature robuste (RMS, kurtosis, fattore di cresta, energie in banda). Queste operazioni sono deterministiche, verificabili, a basso consumo, e producono risultati interpretabili. Un filtro FIR che estrae la banda di interesse da un segnale vibrazionale non ha bisogno di dati di training, non soffre di drift, e si valida con un generatore di segnale.
Le estensioni vettoriali Helium (MVE, Armv8.1-M), disponibili sui core Cortex-M55 e M85, portano 4-5× di accelerazione su FFT e filtri FIR rispetto al Cortex-M4 a parità di clock, con FP16 vettoriale nativo. Per chi lavora con microcontrollori intelligenti per IoT, questo significa che la pipeline DSP che prima saturava un M4 ora gira con margine su un M55, lasciando cicli liberi per l’elaborazione successiva.
Dove il DSP resta la scelta migliore
Misure ripetitive con segnature note. Soglie evolute ma stabili. Compressione intelligente per ridurre banda e RAM. Pre-processing che trasforma un segnale grezzo in poche feature pronte per la trasmissione o per un classificatore. In tutti questi casi, il DSP non è un ripiego: è la scelta ottimale. Nel benchmark HUMS 2023 sui riduttori in endurance, le pipeline di signal processing tradizionale hanno superato i detector deep learning su tutti i canali testati. Nella MCSA (Motor Current Signature Analysis), la stima spettrale con decomposizione wavelet resta la tecnica più robusta per diagnosticare rotori rotti e eccentricità sotto carichi variabili.
Quando le feature non bastano più o il contesto operativo è troppo variabile, lì entra in gioco l’AI.
Quando l’AI embedded ha senso davvero
Pattern complessi, variabilità elevata, classificazione locale
L’AI aggiunge valore in tre scenari precisi. Il primo: quando la segnatura di guasto è sconosciuta e non esistono dati etichettati di guasto. È il caso dell’anomaly detection su una macchina nuova, dove un autoencoder sull’errore di ricostruzione o un one-class SVM sulle feature DSP rileva deviazioni dal profilo appreso senza sapere cosa sta cercando. Il secondo: con condizioni operative fortemente variabili dove le soglie fisse producono falsi allarmi inaccettabili. Studi recenti su motori asincroni riportano il 96% di accuratezza con classificatori ML single-sensor e oltre il 99% fondendo scalogrammi di corrente e immagini termiche tramite CNN. Il terzo: nella fusione multi-sensore non lineare (accelerometro + corrente + temperatura + acustico) dove gli algoritmi formulaici peggiorano rapidamente.
Il pattern che si afferma nella produzione industriale è ibrido: DSP per l’estrazione feature, seguito da un classificatore ML compatto. Non “AI everywhere”, ma AI dove serve.
Quando invece è solo complessità inutile
Se il problema è lineare, stabile e ben modellabile, il DSP classico o le regole deterministiche restano la scelta migliore. Serve davvero una rete neurale per distinguere un evento che un filtro e tre feature separano già bene? La risposta, in molti casi industriali, è no. Un modello ML aggiunge complessità di training, rischio di drift, necessità di validazione su dati reali, e un layer di opacità che in contesto safety non è trascurabile. Chi progetta sistemi di misura per l’Industria 4.0 sa che la ripetibilità e l’interpretabilità del risultato contano quanto l’accuratezza.
Le architetture che oggi contano per smart sensing
MCU con DSP vettoriale
La famiglia Cortex-M55 con Helium rappresenta il salto generazionale nel DSP embedded. Le istruzioni vettoriali a 128 bit con supporto INT8/INT16/FP16/FP32 accelerano sia le catene DSP classiche sia l’inferenza di reti neurali quantizzate, usando gli stessi registri. In pratica: un M55 senza acceleratore neurale chiude già la maggior parte dei casi di keyword spotting, riconoscimento attività, anomaly detection vibrazionale e fusione sensori di piccola taglia. Per chi viene dal Cortex-M4, il guadagno su CMSIS-NN (le librerie Arm ottimizzate per inferenza) è nell’ordine di 5-15× a seconda del kernel e della precisione. Il Cortex-M85 spinge oltre, arrivando a 6,3 CoreMark/MHz con disponibilità fino a 1 GHz.
MCU con acceleratore neurale integrato
Quando il solo DSP vettoriale non basta, la generazione 2024-2026 di MCU integra NPU (Neural Processing Unit) dedicate nello stesso die. L’architettura tipica prevede un core Cortex-M per il controllo e il pre/post-processing DSP, affiancato da un acceleratore che esegue i layer della rete neurale in parallelo. I risultati misurati su piattaforme in produzione parlano chiaro: modelli di object detection che su un Cortex-M7 impiegano 3 secondi, su un MCU con NPU girano in 20-30 ms. Per la computer vision embedded a 30+ FPS su risoluzioni 256×256 o superiori, l’NPU è necessaria. Per audio always-on e vibrazione, spesso no.
Il punto da tenere a mente: l’NPU accelera l’inferenza ML, ma il core Cortex-M con Helium diventa più importante, non meno. FFT, MFCC, normalizzazione, softmax, decodifica bounding box, NMS: tutto il preprocessing e postprocessing gira sul core DSP, e spesso domina il budget energetico complessivo. Chi progetta l’architettura deve dimensionare entrambi.
Smart sensor con elaborazione a bordo
Il confine tra sensore e MCU sta sfumando. I sensori MEMS più recenti integrano nel package un core programmabile con FPU, fino a 32 KB di RAM, capace di eseguire FFT, filtri, piccole reti neurali e anomaly detection senza svegliare il microcontrollore esterno. Il consumo dell’intera catena (acquisizione + elaborazione + classificazione) resta sotto il milliampere. La logica è semplice: se l’algoritmo è fisso e la batteria è il vincolo, conviene spostare l’intelligenza nel sensore. Se il modello deve evolvere via OTA e la RAM serve in abbondanza, il sensore resta “dumb” e l’intelligenza sta sull’MCU.
Per chi segue l’evoluzione dei sensori IIoT, è un cambio architetturale concreto: il sensore non si limita a misurare, ma filtra, classifica e decide se comunicare.
Dove far girare cosa: sensore, nodo smart sensing, gateway
La distribuzione del carico computazionale è il primo atto progettuale di un nodo intelligente.
Il sensore tiene a bordo: bias correction, sensor fusion di base, event detection, wake-up intelligente. Consuma microampere, trasmette solo quando c’è qualcosa da segnalare. Il nodo edge gestisce: feature extraction pesante, inferenza locale, logica di controllo, connettività. Il backend si occupa di: training dei modelli, fleet analytics, correlazioni lunghe tra macchine, distribuzione OTA.
La trasmissione del dato grezzo verso il cloud è quasi sempre un errore. Si trasmettono feature estratte, embedding compressi, decisioni con livello di confidenza, o riassunti periodici. I modelli aggiornati viaggiano in direzione opposta.
Le metriche che contano più dei TOPS
I numeri di marketing (TOPS, GOPS) sul datasheet hanno valore ingegneristico limitato. Le metriche che decidono se un nodo di smart sensing funziona in campo sono altre.
Latenza sensore-decisione: in un loop di condition monitoring a 250 µs, conta il tempo dall’acquisizione alla classificazione. Consumo per inferenza (µJ/inferenza): determina l’autonomia reale di un nodo a batteria; le differenze tra architetture sono di ordini di grandezza. RAM e Flash occupate dal modello reale: un modello che occupa più RAM dell’arena allocata al runtime è un brick silenzioso. Accuratezza sul dato reale di campo, non sul dataset di laboratorio: il gap è spesso superiore al 10%. Robustezza al drift: un modello che funziona al 100% sul banco non resterà al 100% per sei mesi, perché il profilo operativo cambia con usura, carichi, stagione. Tempo di boot per nodi a duty cycle basso. Aggiornabilità: l’OTA per modelli ML richiede validazione del nuovo modello in parallelo al vivo e rollback automatico se i falsi positivi salgono.
Validazione: dove falliscono davvero gli smart sensing industriali
Dataset sbagliato, contesto sbagliato
Il fallimento più comune non è tecnico: è metodologico. Un modello addestrato su dati di un banco prova non generalizza a un impianto reale perché il profilo vibrazionale dipende dal montaggio, dal carico, dall’ambiente. La regola: split del dataset di test per macchina diversa e giorno diverso, mai random split. Il random split nasconde l’overfitting agli artefatti del banco. I benchmark accademici più citati (CWRU) sono ormai saturi; il dataset Paderborn PU, con guasti naturalmente indotti, è oggi il discriminatore più affidabile.
Drift, rumore, condizioni reali
La temperatura influenza l’offset dei MEMS e la risposta del front-end analogico. L’EMI industriale può corrompere il segnale in modi che il modello non ha mai visto. Il drift (aumento dei falsi positivi nel tempo) si rileva monitorando la divergenza statistica sulle feature. Le contromisure: retraining incrementale on-device, selezione dinamica tra modelli candidati, self-test periodico su golden dataset in flash.
Test hardware-in-the-loop sul target smart sensing
Un nodo di smart sensing non si valida solo con accuracy offline. Si valida con prove su target reale: latenza misurata, stabilità termica (−40…+85 °C), robustezza EMC (IEC 61000-4), comportamento dopo OTA update. Per chi progetta sistemi di monitoraggio nell’Industria 4.0, questa è la differenza tra un prototipo che funziona in demo e un prodotto che funziona in campo.
Casi d’uso che valgono davvero
Il condition monitoring vibrazionale è il caso più maturo: pipeline DSP (FFT, envelope, feature extraction) + classificatore ML compatto, con modelli da 5-8 KB di RAM che raggiungono il 99%+ su anomaly detection. L’acoustic event detection (cavitazione pompe, leak, keyword spotting industriale) richiede front-end MFCC + CNN leggera; i dispositivi con acceleratore audio dedicato operano always-on sotto il milliwatt. La visione embedded (ispezione difetti, conteggio persone) è dove l’NPU fa la differenza: object detection a 30+ FPS su 256×256 è possibile solo con acceleratore dedicato. La MCSA (Motor Current Signature Analysis) è il caso in cui DSP e ML convergono: il segnale di corrente è già nel drive, nessun sensore aggiuntivo, pipeline FFT/wavelet + classificatore ML sotto 100 KB di flash.
La scelta come atto progettuale
La battaglia “DSP contro AI” è un titolo da convegno. La pratica quotidiana è una pipeline ibrida in cui il signal processing fisico-basato resta il nucleo e il deep learning si aggiunge dove il DSP formulaico cede: anomaly detection senza dati di guasto, carichi variabili, fusione multi-sensore non lineare. Il cambiamento più rilevante dell’ultimo biennio non è la nascita di NPU da centinaia di GOPS. È la consapevolezza che il partizionamento tra sensore smart, edge MCU e gateway è diventato il primo atto progettuale di un nodo di smart sensing. È lì che si decide il consumo, l’autonomia, la latenza, l’aggiornabilità e la robustezza sul campo. Chi lo ignora paga in milliampere e in giorni di autonomia. Chi lo progetta bene costruisce un sistema che funziona, non solo un sistema che inferisce.
Per chi progetta elettronica embedded per l’industria, la buona notizia è che gli strumenti ci sono. La cattiva è che usarli bene richiede competenze che attraversano hardware, firmware, signal processing e machine learning. Nel 2026 il nodo intelligente non è un componente. È un sistema.
