Rivoluzione industriale e automotive: l'Edge AI in tempo reale con STM32N6

L'AI nel microcontrollore

Chi ha avuto l'esperienza di lavorare nell'automazione industriale con telecamere intelligenti o sistemi embedded, saprà certamente che per anni il confine è stato abbastanza chiaro, perché il microcontrollore leggeva sensori, comandava motori, gestiva timer ed interrupt mentre quando entravano in gioco reti neurali serie, visione artificiale oppure analisi video si passava quasi inevitabilmente ad un SOC con Linux, comunque sia con qualche cosa di più "grande", io stesso ho avuto esperienza con i vari moduli X86 della ICOP (prima) e DIMM-PC (dopo), perchè mettere assieme elettronica intelligente e spazi miniaturizzati era piuttosto complesso. Oggi le cose sono cambiate ed è proprio un controller come STM32N6 che rompe questo confine, perché STMicroelectronics ha costruito un MCU che rimane nella filosofia STM32, quindi avvio rapido, controllo deterministico delle periferiche, RTOS e consumi contenuti, ma gli ha affiancato una NPU abbastanza potente da far girare reti neurali che fino a pochissimo tempo fa sarebbero sembrate fuori scala per un microcontrollore. Il punto non è soltanto avere più MHz, che da soli non risolvono quasi nulla quando una rete deve eseguire milioni di moltiplicazioni ed accumuli, il punto è portare nel chip un'architettura pensata apposta per quelle operazioni ed inserirla accanto ad una CPU general purpose che continua ad occuparsi del resto del sistema.

Il cuore tradizionale dell'STM32N6 è un Arm Cortex-M55 che arriva fino ad 800 MHz ed utilizza la tecnologia Helium, ovvero la MVE (M-Profile Vector Extension), con la quale il core può trattare vettori di dati in maniera molto più efficiente rispetto ad un'esecuzione puramente scalare. Già questo sarebbe un salto importante per DSP, filtri, audio ed elaborazione numerica, ma la parte che cambia veramente il gioco è il Neural-ART Accelerator presente nelle varianti STM32N6x7, una NPU proprietaria di ST che lavora fino ad 1 GHz ed arriva a 600 GOPS, cioè circa seicento miliardi di operazioni al secondo secondo il metodo di conteggio usato per questo tipo di acceleratori. Io trovo particolarmente interessante che ST non abbia semplicemente comprato un blocco neurale standard e lo abbia inserito nel chip, perché Neural-ART nasce da uno sviluppo interno iniziato anni prima e questo ha permesso all'azienda di costruire attorno all'hardware anche il compilatore, i tool di quantizzazione, il Model Zoo ed il resto della catena software.

600 GOPS!

Quando leggiamo 600 GOPS il numero sembra enorme, ma è utile capire da dove arriva perché altrimenti rimane soltanto marketing. Neural-ART dispone di 288 unità MAC configurabili, dove MAC significa Multiply-Accumulate, cioè moltiplicare due valori ed aggiungere il risultato ad un accumulatore, l'operazione elementare che troviamo continuamente nelle convoluzioni e nei layer fully connected; siccome una MAC comprende normalmente una moltiplicazione ed un'addizione, in molti benchmark la si conta come due operazioni, quindi 288 MAC per ciclo significano fino a 576 operazioni elementari per ciclo e, lavorando nell'ordine di 1 GHz, si arriva al valore commerciale arrotondato di circa 600 GOPS. Questi numeri non significano però che qualunque rete neurale riceva automaticamente 600 miliardi di operazioni utili ogni secondo, perché il throughput reale dipende dagli operatori presenti, dalla precisione numerica, dal flusso dei dati, dalla memoria, dal grado con cui il modello riesce ad essere mappato sulla NPU e da quanta parte deve eventualmente tornare sulla CPU.

La cosa tecnicamente più importante è proprio il flusso dei dati, perché in una rete neurale non basta avere moltiplicatori velocissimi se poi pesi ed attivazioni non arrivano in tempo. Neural-ART utilizza motori di streaming dedicati, bus AXI a larga banda, decompressione dei pesi al volo ed una gestione pensata per ridurre i buffer intermedi, e questo serve non solo ad aumentare la velocità ma anche a contenere i consumi. ST dichiara un'efficienza media nell'ordine di 3 TOPS/W, che riportata ai 600 GOPS massimi fa subito capire la filosofia del progetto, cioè ottenere una quantità di inferenza molto elevata senza entrare nei consumi tipici di una piattaforma applicativa con CPU multicore e GPU. Non è un confronto diretto con una GPU da PC, naturalmente, perché cambiano precisione, modelli ed obiettivi, ma è proprio questo il punto: l'STM32N6 non vuole sostituire una GPU, vuole evitare di doverne mettere una dove il compito è circoscritto e deve funzionare sempre, con poco spazio, poco calore ed un'alimentazione ridotta.

Un Cortex-M55 da 800 MHz che di sicuro non rimane a guardare..

Il Cortex-M55 non è soltanto il direttore d'orchestra che aspetta che la NPU finisca, perché continua a svolgere tutta quella parte di elaborazione che una rete neurale non copre oppure che non conviene spostare sull'acceleratore. Il core dispone di cache istruzioni e dati da 32 KB, di memoria TCM dedicata con ECC per le routine real-time più critiche, di FPU con supporto a precisione half, single e double ed appunto delle estensioni Helium, quindi può gestire preprocessing, postprocessing, trasformazioni numeriche, logica applicativa, protocolli, controllo macchina ed algoritmi DSP senza costringere il progettista ad aggiungere un secondo processore.

Questo accoppiamento diventa ancora più interessante quando il carico non è soltanto AI, perché un'applicazione industriale reale non vive di inferenze isolate. Una telecamera può dover acquisire un'immagine, correggere esposizione e colore, ridimensionarla, passare una versione alla rete neurale, disegnare un riquadro sul display, salvare un evento, pilotare un'uscita ed inviare una notifica Ethernet, ed in un sistema tradizionale finiamo facilmente con il distribuire queste funzioni su più chip. Nell'STM32N6 molte di queste operazioni trovano invece un blocco hardware dedicato, con la CPU che coordina, la NPU che esegue la rete, l'ISP che prepara l'immagine, i DMA che spostano i dati ed i motori grafici che si occupano dell'interfaccia.

4,2 MB di RAM interna ed una scelta insolita: non c'è la Flash

L'STM32N6 contiene 4,2 MB di SRAM embedded continua, che per un microcontrollore sono una quantità notevole e diventano preziosi quando dobbiamo tenere attivazioni, buffer video, tensori e strutture di lavoro della rete neurale. A questo punto però arriva una scelta che può sorprendere chi conosce bene gli STM32, perché il chip è flashless, cioè NON possiede la classica memoria Flash interna nella quale mettere direttamente tutto il firmware. La ragione è legata anche al processo produttivo a 16 nm FinFET scelto da ST, che permette di spingere frequenze e densità ma non integra la tradizionale Flash embedded nello stesso modo delle famiglie precedenti, quindi il codice permanente risiede in memoria esterna ed il BootROM interno gestisce la catena di avvio sicuro.

Questa architettura non significa avviare il sistema in maniera improvvisata, perché ST ha previsto secure boot, OTP per le informazioni permanenti, supporto ad un FSBL (First Stage Boot Loader) firmato e diverse modalità per caricare oppure eseguire il firmware da memoria esterna. Il progettista può quindi usare memorie XSPI, HyperFlash, eMMC oppure altre interfacce previste dalla piattaforma, con la possibilità di eseguire codice esterno in XIP oppure caricarlo nella SRAM interna prima dell'esecuzione. In un ambiente industriale questa parte è fondamentale, perché un dispositivo che prende decisioni localmente sulla base di una rete neurale deve essere protetto non solo dagli errori casuali ma anche dalla sostituzione del firmware, dalla manipolazione del modello e da aggiornamenti non autorizzati.

La pipeline video è quasi importante quanto la NPU

Se lo scopo è fare Computer Vision, la NPU da sola serve relativamente a poco se il percorso che porta i pixel dalla camera alla rete è lento oppure consuma tutta la CPU, ed è per questo che STM32N6 integra una pipeline specifica con interfaccia MIPI CSI-2, ingresso parallelo ed un ISP (Image Signal Processor) dimensionato per sensori fino a 5 megapixel a 30 fotogrammi al secondo. L'ISP può eseguire correzione dei pixel difettosi, black level, esposizione, demosaicizzazione, conversioni cromatiche, crop, ridimensionamento ed altre trasformazioni, producendo più flussi d'uscita dalla stessa immagine ed inviando direttamente uno di questi alla NPU attraverso DMA.

Questa possibilità cambia parecchio l'efficienza complessiva, perché il modello non ha quasi mai bisogno dell'immagine originale a piena risoluzione. Una camera da 5 megapixel può alimentare contemporaneamente un flusso più grande destinato alla registrazione od alla visualizzazione ed un'immagine ridotta, per esempio 256 × 256 oppure 320 × 320 pixel, destinata alla rete neurale, evitando di costringere il Cortex-M55 a ridimensionare ogni frame via software. A fianco troviamo inoltre l'encoder hardware H.264 fino a 1080p a 30 fps, il codec JPEG ed il NeoChrom Accelerator per la grafica 2.5D, quindi una stessa MCU può acquisire la scena, eseguire l'inferenza, mostrare il risultato ed eventualmente registrare oppure trasmettere il video senza trasformare la CPU in un collo di bottiglia.

Il tempo reale non è proprio zero, ma è qui che i numeri sono interessanti

Quando si parla di Edge AI si legge spesso che l'elaborazione locale avrebbe latenza quasi zero, ma io preferisco non usare questa formula perché una rete neurale impiega comunque tempo a girare. Il vantaggio vero è togliere dal percorso il viaggio verso il cloud, con connessione, coda, elaborazione remota e ritorno del risultato, lasciando una latenza locale che può essere misurata e progettata. I benchmark pubblicati da ST aiutano molto a capire di quale ordine di grandezza stiamo parlando, perché un YOLOv8n con ingresso 256 × 256 viene indicato intorno a 35,6 ms per inferenza, cioè circa 28 inferenze al secondo, mentre portando l'ingresso a 320 × 320 si sale a circa 47,1 ms, cioè circa 21 inferenze al secondo.

Un MobileNet V2 224 × 224 viene indicato attorno a 23,2 ms, quindi circa 43 inferenze al secondo, mentre YAMNet per analisi audio scende intorno a 9,9 ms e supera le 100 inferenze al secondo nelle condizioni di prova riportate da ST. Questi test sono ancora più interessanti perché la documentazione pubblica anche energia e potenza misurate in una configurazione nominale nella quale il Cortex-M55 lavora a 600 MHz e Neural-ART ad 800 MHz, quindi non alla frequenza massima assoluta, con consumi medi nell'ordine di poche centinaia di milliwatt per l'inferenza di questi modelli, per esempio circa 225 mW per YOLOv8n 256 × 256 e circa 275 mW per YAMNet secondo la metodologia indicata. Non significa che tutto il prodotto finito consumerà 225 mW, perché camera, memoria esterna, alimentatori, display, comunicazioni ed altre periferiche aggiungono il loro contributo, ma significa che la parte neurale può davvero stare dentro un budget energetico da MCU e questa è forse la differenza più concreta rispetto ad una piattaforma Linux molto più pesante.

In fabbrica l'AI smette di essere un servizio remoto

Immaginiamo una linea sulla quale scorrono pezzi meccanici, confezioni oppure schede elettroniche, perché qui un sistema di visione tradizionale può già fare moltissimo ma tende a diventare più complesso quando difetti, posizioni ed illuminazione variano. Con STM32N6 posso invece acquisire l'immagine localmente, passare una versione corretta e ridimensionata ad una rete di object detection o classificazione, individuare un componente mancante, una saldatura anomala, un'etichetta errata oppure un oggetto fuori posizione ed attivare immediatamente l'uscita che deve fermare, scartare o deviare il pezzo. Non ho bisogno di spedire ogni fotogramma fuori dalla macchina e soprattutto non devo affidare il tempo di reazione alla qualità della rete aziendale oppure ad un servizio remoto.

Lo stesso ragionamento vale per la manutenzione predittiva, nella quale spesso non serve neppure una camera, perché accelerometri, microfoni, sensori di corrente e temperatura producono segnali che raccontano come sta funzionando un motore, un cuscinetto, una pompa oppure un compressore. Una rete può imparare la firma vibrazionale od acustica normale e riconoscere deviazioni prima che diventino un guasto evidente, e portare questa inferenza direttamente vicino alla macchina permette di analizzare continuamente il segnale senza riversare una montagna di dati grezzi su server esterni. Il cloud può continuare ad avere un ruolo per la supervisione di flotta, lo storico oppure l'addestramento di modelli più complessi, ma la decisione immediata rimane sul bordo, cioè esattamente dove il fenomeno fisico sta avvenendo.

Dal modello Python al microcontrollore (ma senza riscrivere tutto)

Una NPU potentissima serve poco se per usarla bisogna diventare specialisti del microcodice proprietario, ed è per questo che la parte software conta quasi quanto il silicio. Nel 2026 ST ha introdotto STM32Cube AI Studio come ambiente standalone che sostituisce X-CUBE-AI per i nuovi sviluppi, ed il suo compito è importare modelli già addestrati, quantizzarli, ottimizzarli, validarli e generare il codice necessario all'esecuzione sul dispositivo. Quando il target contiene Neural-ART, il tool genera anche il microcodice che mappa sulla NPU gli operatori supportati, mentre quelli che non possono essere accelerati vengono eseguiti sulla CPU, una soluzione che evita di obbligare il progettista a riscrivere manualmente la rete pezzo per pezzo.

La compatibilità con TensorFlow Lite ed ONNX permette di partire da pipeline di machine learning già comuni, mentre il Model Zoo di ST fornisce modelli ed esempi per object detection, classificazione, pose estimation, audio ed altre applicazioni, e la documentazione del 2026 comprende ormai procedure specifiche per portare sulla Discovery Kit anche famiglie YOLO recenti come YOLOv8, YOLO11 e YOLO26. In pratica il lavoro non consiste più nello scrivere l'algoritmo neurale in C, consiste nell'addestrare o scegliere il modello, quantizzarlo in una forma adatta all'hardware, controllare che gli operatori siano supportati, misurare accuratezza, RAM, tempi ed energia, quindi lasciare che la toolchain trasformi quella rete in qualcosa che il microcontrollore possa realmente eseguire.

Automotive con attenzionamento RT

L'STM32N6 è già entrato in applicazioni automotive reali, ed il caso più interessante pubblicato da ST è quello di Autotrak, che lo ha utilizzato in un sistema di driver monitoring montato sul parabrezza, nel quale la camera osserva il conducente ed il modello analizza localmente gesti e comportamenti per rilevare situazioni di distrazione. Qui l'integrazione fra ISP, NPU e resistenza alle alte temperature diventa particolarmente utile, perché permette di costruire un dispositivo compatto che non ha bisogno di un microprocessore esterno per elaborare continuamente il video, ed è un esempio concreto del fatto che l'Edge AI può arrivare dentro un veicolo senza essere per forza affidata ad un computer centrale molto potente.

Ma questo NON significa che possiamo prendere automaticamente STM32N6 ed usarlo per qualunque funzione ADAS safety-critical. ST aveva chiarito nella propria documentazione tecnica che l'N6 non era certificato per il dominio automotive quando la sicurezza dell'utente era direttamente coinvolta, ed il fatto che nel 2026 l'azienda abbia presentato Stellar P3E come il primo microcontrollore automotive ST con Neural-ART integrato conferma quanto questa distinzione sia importante. Stellar P3E porta la stessa idea di accelerazione neurale dentro una famiglia progettata specificamente per il settore automobilistico e per i relativi requisiti di sicurezza funzionale, quindi io vedo STM32N6 come una piattaforma molto forte per sistemi in-cabin, aftermarket, prototipazione, visione non direttamente safety-critical e sviluppo di algoritmi, mentre per funzioni che devono entrare nella catena certificata di controllo del veicolo bisogna guardare alle piattaforme automotive dedicate ed alla certificazione dell'intero sistema.

Questa precisazione non riduce affatto l'importanza dell'N6 nell'automotive, perché anzi mostra un percorso molto interessante, nel quale gli sviluppatori possono sperimentare modelli, visione ed inferenza su una piattaforma STM32 general purpose e poi trasferire concetti e parte della toolchain verso dispositivi automotive della famiglia Stellar quando il progetto entra nella fase certificata. È un ponte fra due mondi che fino a poco tempo fa erano molto più separati, quello del machine learning rapido da sviluppare ed aggiornare e quello del controllo embedded automotive che pretende determinismo, ridondanza, diagnostica e livelli di sicurezza rigorosi.

Riconoscere il pedone

La traccia più affascinante è naturalmente quella dei sistemi ADAS che riconoscono persone, ciclisti, veicoli oppure ostacoli, ma qui è importante non confondere il tempo di inferenza con il tempo totale necessario ad una funzione di sicurezza. Se una rete YOLO impiega 35 ms non significa che l'auto reagisca in 35 ms, perché prima ci sono acquisizione ed esposizione della camera, trasferimento, preprocessing ed eventualmente sincronizzazione con altri sensori, poi dopo l'inferenza arrivano postprocessing, fusione dei dati, decisione ed attuazione. L'Edge AI riduce una parte importante della catena, soprattutto eliminando ogni dipendenza dal cloud, ma un ADAS serio si progetta misurando l'intero worst case e non soltanto il numero più favorevole della NPU.

In questo senso il valore dell'elaborazione locale è perfino più importante della velocità assoluta, perché un veicolo oppure una macchina industriale non possono smettere di riconoscere un pericolo soltanto perché una connessione è caduta. Se l'inferenza è sul dispositivo, la telecamera ed il modello continuano a lavorare anche senza Internet, il dato sensibile può rimanere localmente e la latenza dipende da una catena hardware e software che il progettista può conoscere, profilare e validare. Il cloud può aggiornare modelli, raccogliere statistiche oppure aiutare nell'analisi a lungo termine, ma non diventa il passaggio obbligatorio per prendere una decisione che deve arrivare subito.

L'Edge AI ora è davvero industriale

A mio parere STM32N6 è interessante non perché abbia portato l'AI su un microcontrollore in senso assoluto, visto che modelli piccoli giravano già da anni su MCU molto meno potenti, ma perché ha spostato parecchio più avanti il punto nel quale dobbiamo arrenderci e passare ad un microprocessore. Con 4,2 MB di SRAM, un Cortex-M55 ad 800 MHz, una NPU da 600 GOPS, MIPI CSI-2, ISP, H.264, grafica accelerata, Ethernet Gigabit e memorie esterne veloci possiamo costruire una classe di prodotti che conserva molti vantaggi di un microcontrollore ma comincia ad offrire esperienze che prima associavamo a sistemi molto più grossi.

La conseguenza concreta è che l'AI non deve più essere pensata come una funzione aggiunta dopo, magari con un piccolo computer collegato alla macchina, perché può entrare nel controller stesso che osserva il processo e reagisce. Una pressa può ascoltare il proprio rumore, una telecamera può distinguere un difetto prima che il pezzo lasci la linea, un pannello può riconoscere la presenza di una persona, un sistema di bordo può analizzare localmente il comportamento del conducente ed un robot può interpretare la scena senza spedire ogni immagine altrove, con tutto ciò che questo comporta in termini di latenza, privacy, robustezza e costi operativi.

Ed è forse questa la vera rivoluzione industriale dell'Edge AI, perché non stiamo semplicemente costruendo microcontrollori più veloci, stiamo trasformando il punto più vicino al sensore in un posto nel quale si può anche decidere, classificare e riconoscere. Quando una rete neurale da milioni di parametri riesce a vivere accanto ai timer, agli ADC, ai bus industriali ed alle routine real-time dello stesso chip, il confine fra controllo elettronico ed Intelligenza Artificiale smette lentamente di avere senso, ed STM32N6 è uno dei segnali più chiari che quel confine si è già spostato.