Perché l'AI deve stare sull'edge
L'AI cloud ha latenza strutturale: trasmissione dati, round-trip di rete, elaborazione server-side, risposta. Per un sensore di vibrazione che deve rilevare un'anomalia e bloccare un macchinario in meno di 10ms, il cloud non è un'opzione.
Tre ragioni concrete per scegliere l'edge:
- Latenza: inferenza su MCU in 1-50ms vs 50-500ms via cloud. Per detection in tempo reale, è un ordine di grandezza.
- Privacy e sovranità del dato: immagini di sorveglianza, audio ambientale, dati biometrici — spesso non possono lasciare il perimetro. L'elaborazione locale risolve il problema alla radice.
- Resilienza: nessuna connessione internet richiesta. In ambienti industriali, la connettività è spesso inaffidabile. L'edge funziona indipendentemente.
La toolchain completa
Quantizzazione: da float32 a int8
Un modello addestrato in float32 è accurato ma occupa troppa memoria per un microcontrollore. La quantizzazione converte i pesi da 32 bit floating point a interi a 8 bit, con tre effetti:
- Dimensione ridotta 4x: un modello da 4MB diventa ~1MB
- Velocità aumentata 2-4x: le MCU eseguono aritmetica intera molto più velocemente del floating point
- Perdita di accuratezza minima: tipicamente 0.5-2% su task di classificazione
Due approcci:
- Post-Training Quantization (PTQ): quantizza il modello già addestrato con un dataset di calibrazione rappresentativo. Veloce, spesso sufficiente.
- Quantization-Aware Training (QAT): simula la quantizzazione durante il training. Più accurato del PTQ, ma richiede un ciclo di training aggiuntivo. Preferibile per modelli piccoli dove la perdita di accuratezza è più impattante.
STM32Cube.AI: conversione e deployment
STM32Cube.AI è il tool ufficiale STMicroelectronics per convertire modelli TFLite o ONNX in codice C ottimizzato per la famiglia STM32. Il workflow:
- Importa il modello .tflite quantizzato
- Analisi automatica del footprint: flash necessaria per i pesi, SRAM per le activation maps
- Generazione del codice C con le API di inferenza (
ai_run()) - Integrazione con il progetto STM32CubeIDE / HAL
STM32Cube.AI supporta la maggior parte delle architetture standard: Conv2D, LSTM, GRU, Dense, BatchNorm, ReLU. Architetture esotiche potrebbero richiedere workaround o non essere supportate.
Vincoli di memoria per famiglia STM32
| MCU | Flash | SRAM | Use case tipico |
|---|---|---|---|
| STM32F4 | 512KB-1MB | 128-256KB | Keyword spotting, anomaly detection semplice |
| STM32L4+ | 1MB | 640KB | Classificazione sensori, gesture recognition |
| STM32H7 | 2MB | 1MB | Computer vision leggera, MobileNet int8 |
| STM32N6 | 4MB | 4MB + NPU | Neural Processing Unit dedicato, modelli più grandi |
Dimensionare l'MCU partendo dai requisiti del modello, non il contrario. Il footprint del modello deve stare entro il 60-70% della memoria disponibile per lasciare spazio al firmware base, allo stack, e a eventuali buffer I/O. STM32Cube.AI mostra l'analisi di footprint prima della compilazione — usarla in fase di design, non di porting.
Caso d'uso concreto: anomaly detection su vibrazione
Un progetto reale: anomaly detection su un motore elettrico tramite accelerometro a 3 assi campionato a 1 kHz.
- Acquisizione: STM32F4 legge l'accelerometro via SPI a 1 kHz, accumula una finestra di 256 campioni per asse
- Feature extraction: FFT sulla finestra (eseguita via CMSIS-DSP, ottimizzata per Cortex-M4F), estrazione di 32 feature spettrali per asse
- Modello: piccola rete LSTM addestrata su 500 ore di dati (normale vs anomalia). Quantizzata int8: 48KB di pesi, 12KB di activation SRAM.
- Inferenza: ~8ms a 168MHz. Output: probabilità di anomalia ogni 256ms.
- Output: se P(anomalia) > 0.85 per 3 inferenze consecutive → alert via MQTT verso il gateway edge.
OTA per i modelli
Un sistema AI embedded non è statico: il modello va aggiornato quando migliora o quando cambiano le condizioni dell'impianto. Il meccanismo OTA (Over-The-Air) per i modelli deve essere sicuro — firma digitale del file del modello, verifica prima di applicarlo, rollback automatico se l'avvio con il nuovo modello fallisce.
Il nuovo modello viene consegnato via MQTT o HTTPS, scritto in un'area di staging in flash, verificata la firma ECDSA, poi copiata nell'area attiva al prossimo reboot. Questo pattern evita di restare con un firmware corrotto dopo un aggiornamento parziale.
TFLite Micro vs ONNX Runtime Micro
TFLite Micro è più maturo e ha il supporto ufficiale STM32Cube.AI. ONNX Runtime Micro è più recente ma offre compatibilità con il formato ONNX, che è lo standard de facto per l'export da PyTorch. Per la maggior parte dei progetti su STM32, TFLite Micro rimane la scelta più pratica per l'ecosistema di tooling disponibile.