💻 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

Cet article introduit une passe d'analyse post-traitement MLIR pour le compilateur snn-mlir qui génère des preuves de latence de pire cas et des certificats de sécurité mémoire vérifiables par machine, permettant ainsi le déploiement conforme à la norme IEC 62304 Classe B des réseaux de neurones impulsionnels pour les dispositifs médicaux de bord critiques pour la sécurité, tels que les détecteurs de crises d'épilepsie.

Auteurs originaux : Hassan Farooq

Publié 2026-07-07

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Hassan Farooq

Article original sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous ayez construit un cerveau de robot très intelligent et économe en énergie (appelé un Réseau de Neurones à Impulsions ou SNN) conçu pour écouter les ondes cérébrales d'un patient et détecter les crises avant qu'elles ne surviennent. Ce cerveau de robot est parfait pour les petits dispositifs médicaux alimentés par batterie car il est rapide et consomme très peu d'énergie.

Cependant, il y a un gros problème : personne ne lui fait encore confiance.

Dans le monde des dispositifs médicaux, on ne peut pas se contenter de dire : « Ça fonctionne la plupart du temps. » Vous avez besoin d'une preuve absolue qu'il ne sera jamais trop lent ou qu'il ne plantera pas, même dans le pire des scénarios. Si le cerveau du robot met trop de temps à réagir, le patient pourrait être en danger. Actuellement, les outils utilisés pour construire ces cerveaux de robots sont comme une boulangerie qui prépare de délicieux gâteaux mais refuse de vous donner un certificat prouvant que la température du four était sûre ou que le gâteau ne vous brûlera pas la langue.

Ce document présente un nouvel « inspecteur de sécurité » qui comble cette lacune. Voici comment cela fonctionne, en utilisant des analogies simples :

1. Le maillon manquant : L'« Inspecteur de Sécurité »

Les auteurs ont créé un outil logiciel spécial (une « passe de post-traitement ») qui agit comme un inspecteur de sécurité super strict.

L'ancienne méthode : Vous construisez le cerveau du robot, vous le transformez en code (C11), et vous espérez qu'il soit assez rapide.
La nouvelle méthode : Une fois le code construit, cet inspecteur examine le plan (le graphe de flux de contrôle), calcule le temps absolument le plus lent que le robot pourrait jamais prendre pour réfléchir, et inscrit un certificat directement sur le code.

2. Le calcul du « pire cas » (L'analogie du bouchon de circulation)

Pour prouver que le cerveau du robot est sûr, l'inspecteur utilise une méthode appelée IPET. Imaginez le processus de réflexion du robot comme une voiture circulant dans une ville avec de nombreux carrefours (boucles et décisions).

Habituellement, la voiture roule vite.
Mais l'inspecteur demande : « Quel est l'embouteillage le plus terrible qui puisse arriver ? Et si tous les feux étaient rouges et que toutes les routes étaient bloquées ? »
L'inspecteur résout un casse-tête mathématique complexe (un « Programme Linéaire en Nombres Entiers ») pour trouver ce pire cas de bouchon.
Le résultat : Ils ont découvert que même dans le pire embouteillage, le cerveau du robot ne prend que 100,6 microsecondes pour prendre une décision.
La marge de sécurité : Le dispositif médical doit réagir en moins de 50 millisecondes (50 000 microsecondes). Le cerveau du robot est 497 fois plus rapide que le délai imparti. C'est comme terminer un 100 mètres en 0,2 seconde alors que la règle dit que vous avez 100 secondes pour finir. Vous êtes en sécurité.

3. Le « Livre de Preuves » (Stubs Lean4)

Le document mentionne également Lean4, qui est comme un notaire numérique.

L'inspecteur ne se contente pas d'écrire une note disant « C'est rapide ». Il rédige une promesse mathématique formelle (une « obligation de preuve ») dans un langage spécial que les ordinateurs peuvent vérifier.
Considérez cela comme des « espaces réservés » dans un contrat. Le document indique : « Nous avons écrit le contrat qui dit 'Ce code est sûr'. Un avocat (un expert humain) pourrait le signer plus tard. »
C'est la première fois qu'un tel contrat formel est attaché à ce type de code de cerveau de robot.

4. La norme médicale (IEC 62304)

Les dispositifs médicaux doivent suivre un livre de règles strict appelé IEC 62304. C'est comme une liste de contrôle pour construire un avion sûr.

Les auteurs ont montré que leur nouveau processus crée une « piste de papier » qui couvre la majeure partie de la liste de contrôle (environ 75 % des exigences de base).
Ils ont prouvé qu'ils peuvent tracer le code jusqu'à la conception originale, ce qui est une étape majeure vers l'obtention de l'approbation officielle pour un usage médical.

5. L'essai routier (Détection de crises)

Pour prouver l'efficacité de cela, ils l'ont testé sur des données réelles de deux patients souffrant d'épilepsie (issues de l'ensemble de données CHB-MIT).

Le résultat : Le cerveau du robot a correctement identifié les crises 78,8 % du temps.
La vitesse : Il a fonctionné si vite qu'il disposait d'une marge de sécurité massive. Même s'ils ont testé cela sur un ordinateur standard (et non sur la minuscule puce médicale encore), les mathématiques ont prouvé que cela serait sûr sur la petite puce également.

Résumé de ce qui a été accompli

Le Problème : Nous avions une IA médicale intelligente, mais aucun moyen de prouver qu'elle était assez rapide pour des situations de vie ou de mort.
La Solution : Un nouvel outil qui calcule automatiquement la vitesse du « pire cas » et attache un certificat de sécurité formel au code.
Le Résultat : Ils ont réussi à construire un cerveau de robot de détection de crises, ont prouvé mathématiquement qu'il est 497 fois plus rapide que la limite de sécurité, et ont créé la documentation requise pour entamer le processus de certification de ce dispositif médical.

Note importante : Le document admet qu'il s'agit d'un « premier jet » du processus de sécurité. Ils n'ont pas encore construit le dispositif médical final et n'ont pas encore signé les contrats légaux définitifs (les « preuves Lean4 » ne sont actuellement que l'ébauche du contrat). Mais ils ont construit la feuille de route et les outils pour y parvenir, ce qui n'avait jamais été fait auparavant pour ce type spécifique de technologie.

Résumé technique : Intégration de preuves de latence du pire cas et de certificats de sécurité mémoire dans le pipeline de réduction MLIR de snn-mlir

1. Énoncé du problème

Les réseaux de neurones impulsionnels (SNN) neuromorphiques offrent un calcul temporel économe en énergie, adapté aux dispositifs médicaux en périphérie (edge), tels que les neurostimulateurs en boucle fermée pour l'épilepsie. Cependant, leur déploiement dans des contextes critiques pour la sécurité est actuellement entravé par un « fossé de l'outillage ». Bien que les frameworks existants comme snnTorch et les compilateurs comme snn-mlir puissent générer du code C11 valide à partir de modèles entraînés, ils ne parviennent pas à produire une preuve vérifiable par machine que les fonctions d'inférence compilées respectent les limites de temps d'exécution du pire cas (WCET) ou les exigences de documentation de la norme IEC 62304 Classe B.

Les compilateurs SNN actuels n'intègrent pas de méthodes de vérification formelle (telles que la technique d'énumération de chemins implicites, ou IPET) pour prouver que le code respecte les contraintes de latence strictes requises pour le matériel implantable. Sans ces preuves, les SNN ne peuvent pas être certifiés pour un usage médical selon des normes telles que l'IEC 62304, qui exige une traçabilité des exigences jusqu'à l'implémentation vérifiée.

2. Méthodologie

Les auteurs proposent une passe d'analyse post-traitement qui opère sur la représentation intermédiaire multi-niveau (MLIR) émise par le compilateur snn-mlir. Le pipeline se compose des étapes suivantes :

Entraînement et exportation du modèle : Un SNN de type Leaky Integrate-and-Fire (LIF) à trois couches (feedforward) a été entraîné via snnTorch sur le jeu de données d'EEG de scalp CHB-MIT (patients chb01 et chb02) pour la détection de crises d'épilepsie. Le modèle a été exporté au format Neuromorphic Intermediate Representation (NIR).
Compilation : Le graphe NIR a été réduit en code C11 via snn-mlir (commit 89b65e0). Le code a été compilé avec GCC au niveau d'optimisation -O0 pour garantir une correspondance stable et non optimisée entre la structure de la source et les instructions émises, ce qui est nécessaire pour une extraction précise du grapfe de contrôle de flux (CFG).
Analyse formelle du WCET (IPET) : Une passe de post-traitement en Python (certify.py) extrait le CFG de chaque couche LIF compilée. Elle formule un programme linéaire en nombres entiers (ILP) basé sur l'IPET, paramétré par le minutage des instructions du microcontrôleur ARM Cortex-M4F. L'ILP maximise le flux de cycles sous réserve de contraintes de conservation de flux et de bornes de retour de boucle.
Annotation et certification : La passe annote le code C11 résultant avec des commentaires @wcet_bound et génère des stubs d'obligations de preuve Lean4. Ces stubs énoncent formellement les bornes de WCET en tant qu'obligations de preuve, liant la sortie du compilateur à un assistant de preuve.
Correspondance IEC 62304 : Les artefacts générés (documentation CFG, code source annoté, journaux de tests) sont mis en correspondance avec des clauses spécifiques de l'IEC 62304 Classe B (Processus de développement logiciel) pour démontrer la conformité aux exigences de documentation et de traçabilité.

3. Contributions clés

Le papier revendique quatre contributions principales :

Formulation du WCET pour les SNN : Les auteurs formulent l'analyse du WCET pour les fonctions d'inférence LIF compilées par snn-mlir sous forme d'un ILP IPET paramétré par le minutage des instructions ARM Cortex-M4F.
Passe de post-traitement automatisée : Implémentation d'une passe Python qui automatise l'extraction du CFG, la résolution de l'ILP, l'annotation du WCET et la génération de stubs Lean4 sans nécessiter de modifications du code source C++ du compilateur.
Validation de bout en bout : Validation du pipeline sur une tâche de détection de crises cliniquement pertinente, démontrant que l'inférence C11 compilée correspond au modèle Python de référence tout en respectant les contraintes d'analyse statique.
Lot d'artefacts IEC 62304 : Fourniture d'un lot d'artefacts cartographiés couvrant les catégories de documentation du processus de développement logiciel IEC 62304 Classe B, représentant une voie allant d'un modèle entraîné vers une documentation conforme à la réglementation.

4. Résultats

Performance du modèle : Le SNN entraîné a atteint une exactitude équilibrée de 78,8 % (IC 95 % : 74,5–83,2 %) sur l'ensemble de test, dépassant le seuil de crédibilité de 75 %. La sensibilité était de 68,6 % et la spécificité de 89,1 %.
Correction de la compilation : La fonction d'inférence C11 compilée a montré une divergence négligeable par rapport à la référence Python snnTorch (divergence max $\approx 1 \times 10^{-5}$ ), attribuée aux différences de précision de virgule flottante plutôt qu'à un biais systématique.
Bornes WCET :
- L'analyse IPET a produit une borne uniforme par couche de 5 634 cycles.
- La borne du réseau certifié pour le réseau à trois couches est de 16 902 cycles (100,6 µs à 168 MHz).
- Cette borne offre une marge de 497× en dessous de la limite de temps réel strict de 50 ms pour la neurostimulation.
- Le temps d'exécution mesuré était de 8 627 cycles (51,4 µs), bien en deçà de la borne certifiée.
Couverture des artefacts : Le lot généré couvre entièrement cinq des huit catégories de processus de développement logiciel de l'IEC 62304 §5.x et couvre partiellement deux autres, résultant en un score de 6,0/8,0 pour le processus de développement. Il couvre entièrement la gestion de configuration (§8.0) mais note l'absence d'une analyse formelle de la gestion des risques logiciels (§7.1).

5. Signification et affirmations

Les auteurs positionnent ce travail comme la première voie documentée publiquement allant d'un modèle snnTorch entraîné vers un lot de documentation IEC 62304 Classe B pour une fonction d'inférence SNN.

Nouveauté : Ce travail comble le fossé entre les sorties de compilateurs neuromorphiques et les normes de vérification formelle, en appliquant spécifiquement l'IPET aux SNN et en générant des obligations de preuve Lean4.
Modestie et limites : Les auteurs précisent explicitement que les stubs Lean4 sont des spécifications, et non des preuves vérifiées ; la résolution de ces preuves est laissée aux futurs collaborateurs. Les bornes WCET sont dérivées de builds non optimisés (-O0) et appliquées comme une approximation cross-architecture (hôte x86_64 avec modèles de minutage ARM) plutôt que par une compilation croisée ARM native. L'analyse de gestion des risques (§7.1) n'a pas été réalisée, et l'étude est limitée à deux patients du jeu de données CHB-MIT.
Conclusion : Le pipeline établit une base reproductible pour les travaux futurs vers un déploiement neuromorphique en périphière entièrement vérifié, démontant que les SNN peuvent être compilés en code C11 avec des bornes de latence vérifiables par machine, adaptées à la certification de dispositifs médicaux critiques pour la sécurité.