💻 computer science

Embedding Formal Worst-Case Latency Proofs and Memory-Safety Certificates into the snn-mlir MLIR Lowering Pipeline for IEC 62304-Compliant Edge Deployment of Spiking Neural Networks

Questo articolo introduce una pass di analisi MLIR di post-elaborazione per il compilatore snn-mlir che genera prove di latenza massima verificabili dalla macchina e certificati di sicurezza della memoria, consentendo così l'implementazione conforme alla norma IEC 62304 Classe B delle reti neurali spiking per dispositivi medici edge critici per la sicurezza come i rilevatori di crisi epilettiche.

Autori originali: Hassan Farooq

Pubblicato 2026-07-07

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Hassan Farooq

Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di aver costruito un cervello robotico molto intelligente ed efficiente dal punto di vista energetico (chiamato Rete Neurale Spiking o SNN) progettato per ascoltare le onde cerebrali di un paziente e individuare le crisi epilettiche prima che accadano. Questo cervello robotico è perfetto per piccoli dispositivi medici alimentati a batteria perché è veloce e consuma pochissima energia.

Tuttavia, c'è un grande problema: nessuno si fida ancora di lui.

Nel mondo dei dispositivi medici, non puoi semplicemente dire: "Funziona la maggior parte delle volte". Hai bisogno di una prova assoluta che non sarà mai troppo lento o che non si bloccherà, anche nello scenario peggiore possibile. Se il cervello robotico impiega troppo tempo a reagire, il paziente potrebbe essere in pericolo. Attualmente, gli strumenti usati per costruire questi cervelli robotici sono come un panificio che sforna torte deliziose ma si rifiuta di fornirti un certificato che provi che la temperatura del forno fosse sicura o che la torta non ti scotti la lingua.

Questo articolo presenta un nuovo "ispettore della sicurezza" che colma questa lacuna. Ecco come funziona, usando semplici analogie:

1. L'anello mancante: L' "Ispettore della Sicurezza"

Gli autori hanno creato uno speciale strumento software (un "passaggio di post-elaborazione") che agisce come un ispettore della sicurezza super rigoroso.

Il vecchio modo: Costruisci il cervello robotico, lo trasformi in codice (C11) e speri che sia abbastanza veloce.
Il nuovo modo: Dopo che il codice è stato costruito, questo ispettore esamina il progetto (il grafo di flusso di controllo), calcola il tempo assolutamente più lento che il robot potrebbe mai impiegare per pensare e scrive un certificato direttamente sul codice.

2. Il calcolo del "Caso Peggiore" (L'analogia dell'ingorgo stradale)

Per provare che il cervello robotico è sicuro, l'ispettore utilizza un metodo chiamato IPET. Pensa al processo di pensiero del robot come a un'auto che guida attraverso una città con molti incroci (cicli e decisioni).

Di solito, l'auto guida veloce.
Ma l'isttore chiede: "Qual è l'ingorgo peggiore che potrebbe accadere? E se ogni semaforo fosse rosso e ogni strada fosse bloccata?"
L'ispettore risolve un complesso puzzle matematico (un "Programma Lineare Intero") per trovare l'ingorgo peggiore possibile.
Il Risultato: Hanno scoperto che, anche nell'ingorgo peggiore, il cervello robotico impiega solo 100,6 microsecondi per prendere una decisione.
Il Margine di Sicurezza: Il dispositivo medico deve reagire entro 50 millisecondi (50.000 microsecondi). Il cervello robotico è 497 volte più veloce della scadenza. È come finire una gara di 100 metri in 0,2 secondi quando la regola dice di finire entro 100 secondi. Sei al sicuro.

3. Il "Libro delle Prove" (Lean4 Stubs)

L'articolo menziona anche Lean4, che è come un notaio digitale.

L'ispettore non si limita a scrivere una nota dicendo "È veloce". Scrive una promessa matematica formale (un "obbligo di prova") in un linguaggio speciale che i computer possono controllare.
Considera queste come "segnaposto" in un contratto. L'articolo dice: "Abbiamo scritto il contratto che dice 'Questo codice è sicuro'. Un avvocato (un esperto umano) potrebbe firmarlo in seguito".
Questa è la prima volta che un simile contratto formale è stato allegato a questo tipo di codice per cervello robotico.

4. Lo Standard Medico (IEC 62304)

I dispositivi medici devono seguire un rigido libro di regole chiamato IEC 62304. È come una lista di controllo per costruire un aereo sicuro.

Gli autori hanno dimostrato che il loro nuovo processo crea una "traccia documentale" che copre la maggior parte della lista di controllo (circa il 75% dei requisiti principali).
Hanno dimostrato di poter tracciare il codice fino al progetto originale, il che è un grande passo verso l'ottenimento dell'approvazione ufficiale per l'uso medico.

5. La Prova su Strada (Rilevamento delle Crisi)

Per dimostrare che questo funziona, lo hanno testato su dati reali di due pazienti con epilessia (dal dataset CHB-MIT).

Il Risultato: Il cervello robotico ha identificato correttamente le crisi nel 78,8% dei casi.
La Velocità: Funzionava così velocemente che aveva un enorme margine di sicurezza. Anche se hanno testato il sistema su un computer standard (non ancora sul minuscolo chip medico), la matematica ha provato che sarebbe stato sicuro anche sul piccolo chip.

Riassunto di ciò che è stato raggiunto

Il Probleo: Avevamo un'IA medica intelligente, ma nessun modo per provare che fosse abbastanza veloce per situazioni di vita o di morte.
La Soluzione: Un nuovo strumento che calcola automaticamente la velocità del "caso peggiore" e allega un certificato di sicurezza formale al codice.
Il Risultato: Hanno costruito con successo un cervello robotico per il rilevamento delle crisi, hanno provato matematicamente che è 497 volte più veloce del limite di sicurezza e hanno creato la documentazione necessaria per iniziare il processo di certificazione come dispositivo medico.

Nota Importante: L'articolo ammette che questa è una "prima bozza" del processo di sicurezza. Non hanno ancora costruito il dispositivo medico finale e non hanno ancora firmato i contratti legali finali (le "prove Lean4" sono attualmente solo la struttura del contratto). Ma hanno costruito la tabella di marcia e gli strumenti per arrivarci, cosa che non è mai stata fatta prima per questo specifico tipo di tecnologia.

Sintesi Tecnica: Inserimento di Prove di Latenza del Caso Peggiore Formali e Certificati di Sicurezza della Memoria nella Pipeline di Lowering di snn-mlir MLIR

1. Definizione del Problema

Le Reti Neurali Spiking (SNN) neuromorfiche offrono un calcolo temporale efficiente dal punto di vista energetico, adatto a dispositivi medici edge, come i neurostimolatori a circuito chiuso per l'epilessia. Tuttavia, la loro implementazione in contesti critici per la sicurezza è attualmente bloccata da un "gap tecnologico". Sebbene gli framework esistenti come snnTorch e i compilatori come snn-mlir possano generare codice C11 valido da modelli addestrati, essi non riescono a produrre evidenze verificabili da macchina che dimostrino che le funzioni di inferenza compilate soddisfino i limiti di Worst-Case Execution Time (WCET) o i requisiti di documentazione della certificazione IEC 62304 Classe B.

Gli attuali compilatori SNN non integrano metodi di verifica formale (come la tecnica dell'Implicit Path Enumeration, o IPET) per provare che il codice soddisfi i rigorosi vincoli di latenza richiesti per l'hardware impiantabile. Senza tali prove, le SNN non possono essere certificate per l'uso medico secondo standard come l'IEC 62304, che impone la tracciabilità dai requisiti all'implementazione verificata.

2. Metodologia

Gli autori propongono una fase di analisi post-processing che opera sulla Multi-Level Intermediate Representation (MLIR) emessa dal compilatore snn-mlir. La pipeline consiste nelle seguenti fasi:

Addestramento e Esportazione del Modello: Una SNN Leaky Integrate-and-Fire (LIF) feedforward a tre strati è stata addestrata utilizzando snnTorch sul dataset EEG scalare CHB-MIT (pazienti chb01 e chb02) per la rilevazione delle crisi epilettiche. Il modello è stato esportato nel formato Neuromorphic Intermediate Representation (NIR).
Compilazione: Il grafo NIR è stato abbassato (lowered) a codice C11 utilizzando snn-mlir (commit 89b65e0). Il codice è stato compilato con GCC al livello di ottimizzazione -O0 per garantire una corrispondenza stabile e non ottimizzata tra la struttura della sorgente e le istruzioni emesse, necessaria per un'accurata estrazione del grafo del flusso di controllo (CFG).
Analisi Formale WCET (IPET): Una fase di post-processing in Python (certify.py) estrae il CFG di ogni strato LIF compilato. Essa formula un Programma Lineare Intero (ILP) basato sulla tecnica dell'Implicit Path Enumeration Technique (IPET), parametrizzato dalla temporizzazione delle istruzioni del microcontrollore ARM Cortex-M4F. L'ILP massimizza il flusso di cicli soggetto a vincoli di conservazione del flusso e limiti di ritorno dei cicli (loop-back).
Annotazione e Certificazione: La fase annota il codice C11 risultante con commenti @wcet_bound e genera stub di obbligo di prova in Lean4. Questi stub dichiarano formalmente i limiti WCET come obblighi di prova, collegando l'output del compilatore a un assistente alla prova.
Mappatura IEC 62304: Gli artefatti generati (documentazione CFG, codice annotato, log di test) sono mappati su specifiche clausole della norma IEC 62304 Classe B (Processo di Sviluppo Software) per dimostrare la conformità ai requisiti di documentazione e tracciabilità.

3. Contributi Principali

L'articolo rivendica quattro contributi primari:

Formulazione del WCET per le SNN: Gli autori formulano l'analisi WCET per le funzioni di inferenza LIF compilate con snn-mlir come un ILP IPET parametrizzato dalla temporizzazione delle istruzioni ARM Cortex-M4F.
Fase di Post-Processing Automatizzata: Implementazione di una fase Python che automatizza l'estrazione del CFG, la risoluzione dell'ILP, l'annotazione WCET e la generazione di stub Lean4 senza richiedere modifiche al codice sorgente C++ del compilatore sottostante.
Validazione End-to-End: Validazione della pipeline su un compito di rilevamento delle crisi clinicamente rilevante, dimostrando che l'inferenza in C11 compilata corrisponde al modello di riferimento Python pur rispettando i vincoli di analisi statica.
Bundle di Artefatti IEC 62304: Fornitura di un bundle di artefatti mappati che copre le categorie di processo di sviluppo software IEC 62304 Classe B, rappresentando un percorso dalla formazione di un modello alla documentazione conforme alle normative.

4. Risultati

Performance del Modello: La SNN addestrata ha ottenuto una accuratezza bilanciata del 78,8% (95% CI: 74,5–83,2%) sul set di test tenuto da parte, superando la soglia di credibilità del 75%. La sensibilità era del 68,6% e la specificità dell'89,1%.
Correttezza della Compilazione: La funzione di inferenza C11 compilata ha mostrato una divergenza trascurabile rispetto al riferimento Python di snnTorch (divergenza massima $\approx 1 \times 10^{-5}$ ), attribuibile a differenze di precisione in virgola mobile piuttosto che a un bias sistematico.
Limiti WCET:
- L'analisi IPET ha prodotto un limite uniforme per strato di 5.634 cicli.
- Il limite certificato della rete per la rete a tre strati è di 16.902 cicli (100,6 µs a 168 MHz).
- Questo limite fornisce un margine di 497× al di sotto della scadenza in tempo reale rigida di 50 ms per la neurostimolazione.
- Il tempo di esecuzione misurato è stato di 8.627 cicli (51,4 µs), ampiamente entro il limite certificato.
Copertura degli Artefatti: Il bundle generato copre interamente cinque delle otto categorie di processo di sviluppo software §5.x di IEC 62304 e copre parzialmente altre due, con un punteggio di 6,0/8,0 per il processo di sviluppo. Copre interamente la gestione della configurazione (§8.0) ma segnala la mancanza di un'analisi formale della gestione del rischio del software (§7.1).

5. Significato e Rivendicazioni

Gli autori pongono questo lavoro come il primo percorso documentato pubblicamente da un modello snnTorch addestrato a un bundle di documentazione IEC 62304 Classe B per una funzione di inferenza SNN.

Novità: Il lavoro colma il divario tra gli output dei compilatori neuromorfici e gli standard di verifica formale, applicando specificamente l'IPET alle SNN e generando obblighi di prova in Lean4.
Modestia e Limitazioni: Gli autori dichiarano esplicitamente che gli stub Lean4 sono specifiche, non prove verificate; la risoluzione di queste prove è lasciata a futuri collaboratori. I limiti WCET sono derivati da build non ottimizzate (-O0) e applicati come approssimazione cross-architettura (host x86_64 con modelli di temporizzazione ARM) piuttosto che attraverso una cross-compilazione ARM nativa. L'analisi della gestione del rischio (§7.1) non è stata eseguita e lo studio è limitato a due pazienti del dataset CHB-MIT.
Conclusione: La pipeline stabilisce una base riproducibile per il lavoro futuro verso un deployment neuromorfico edge completamente verificato, dimostrando che le SNN possono essere compilate in codice C11 con limiti di latenza verificabili da macchina, adatti alla certificazione di dispositivi medici critici per la sicurezza.