💻 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

Dit artikel introduceert een post-processing MLIR-analysepass voor de snn-mlir compiler die machine-controleerbare bewijzen voor worst-case latentie en geheugenveiligheidscertificaten genereert, waardoor de IEC 62304 Class B-conforme inzet van spiking neural networks voor veiligheidskritische edge medische apparaten zoals epileptische aanvaldetectoren mogelijk wordt gemaakt.

Oorspronkelijke auteurs: Hassan Farooq

Gepubliceerd 2026-07-07

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Hassan Farooq

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer slim, energiezuinig robotbrein hebt gebouwd (een Spiking Neural Network of SNN), ontworpen om naar de hersengolven van een patiënt te luisteren en epileptische aanvallen te detecteren voordat ze plaatsvinden. Dit robotbrein is perfect voor piepkleine, op batterijen werkende medische apparaten omdat het snel is en zeer weinig stroom verbruikt.

Echter, er is een groot probleem: Niemand vertrouwt het nog.

In de wereld van medische hulpmiddelen kun je niet simpelweg zeggen: "Het werkt meestal wel." Je hebt absoluut bewijs nodig dat het nooit te traag zal zijn of zal vastlopen, zelfs niet in het slechtste scenario. Als het robotbrein te lang nodig heeft om te reageren, kan de patiënt in gevaar komen. Momenteel zijn de instrumenten die worden gebruikt om deze robotbreinen te bouwen als een bakkerij die heerlijke taarten bakt, maar weigert een certificaat te geven dat bewijst dat de oven op een veilige temperatuur stond of dat de taart je tong niet zal verbranden.

Dit artikel introduceert een nieuwe "veiligheidsinspecteur" die dit gat dicht. Hier is hoe het werkt, met behulp van eenvoudige analogieën:

1. De Ontbrekende Schakel: De "Veiligheidsinspecteur"

De auteurs hebben een speciale softwaretool gemaakt (een "post-processing pass") die fungeert als een extreem strikte veiligheidsinspecteur.

De Oude Manier: Je bouwt het robotbrein, zet het om in code (C11), en hoopt dat het snel genoeg is.
De Nieuwe Manier: Nadat de code is gebouwd, bekijkt deze inspecteur de blauwdruk (de control-flow graph), berekent de absoluut traagste tijd die het robotbrein ooit nodig zou kunnen hebben om na te denken, en schrijft een certificaat direct op de code.

2. De "Worst-Case" Berekening (De Verkeersopstopping-analogie)

Om te bewijzen dat het robotbrein veilig is, gebruikt de inspecteur een methode genaamd IPET. Denk aan het denkproces van de robot als een auto die door een stad rijdt met veel kruispunten (lussen en beslissingen).

Normaal gesproken rijdt de auto snel.
Maar de inspecteur vraagt: "Wat is de absoluut ergste verkeersopstopping die kan gebeuren? Wat als alle stoplichten op rood staan en elke weg geblokkeerd is?"
De inspecteur lost een complexe wiskundige puzzel op (een "Integer Linear Program") om die worst-case verkeersopstopping te vinden.
Het Resultaat: Ze ontdekten dat het robotbrein, zelfs in de ergste verkeersopstopping, slechts 100,6 microseconden nodig heeft om een beslissing te nemen.
De Veiligheidsmarge: Het medische apparaat moet binnen 50 milliseconden (50.000 microseconden) reageren. Het robotbrein is 497 keer sneller dan de deadline. Het is alsof je een 100-meter sprint voltooi in 0,2 seconden terwijl de regel zegt dat je 100 seconden de tijd hebt om te finishen. Je bent veilig.

3. Het "Bewijsboek" (Lean4 Stubs)

Het artikel vermeldt ook Lean4, wat een digitale notaris is.

De inspecteur schrijft niet alleen een notitie dat "het snel is." Hij schrijft een formeel wiskundig belofte (een "proof obligation") in een speciale taal die computers kunnen controleren.
Denk aan deze als "plaatsvervangers" in een contract. Het artikel zegt: "We hebben het contract geschreven dat stelt: 'Deze code is veilig.' Een advocaat (een menselijke expert) zou het later kunnen ondertekenen."
Dit is de eerste keer dat een dergelijk formeel contract aan dit type robotbrein-code is gekoppeld.

4. De Medische Standaard (IEC 62304)

Medische hulpmiddelen moeten een strikte regelset volgen die IEC 62304 wordt genoemd. Dit is als een checklist voor het bouwen van een veilig vliegtuig.

De auteurs hebben aangetoond dat hun nieuwe proces een "spoor van bewijslast" creëert dat de meeste vereisten (ongeveer 75% van de kernvereisten) dekt.
Ze hebben bewezen dat ze de code helemaal terug kunnen herleiden naar het oorspronkelijke ontwerp, wat een enorme stap is richting officiële goedkeuring voor medisch gebruik.

5. De Proefrit (Aanvaldetectie)

Om te bewijzen dat dit werkt, hebben ze het getest op echte gegevens van twee patiënten met epilepsie (uit de CHB-MIT dataset).

Het Resultaat: Het robotbrein identificeerde aanvallen correct in 78,8% van de gevallen.
De Snelheid: Het draaide zo snel dat het een enorme veiligheidsbuffer had. Hoewel ze dit op een standaard computer testten (en niet op de kleine medische chip zelf), bewees de wiskunde dat het ook op de kleine chip veilig zou zijn.

Samenvatting van wat er is bereikt

Het Probleem: We hadden slimme medische AI, maar geen manier om te bewijzen dat het snel genoeg was voor levensbedreigende situaties.
De Oplossing: Een nieuwe tool die automatisch de "worst-case" snelheid berekent en een formeel veiligheidscertificaat aan de code koppelt.
De Uitkomst: Ze hebben succesvol een robotbrein voor aanvaldetectie gebouwd, wiskundig bewezen dat het 497 keer sneller is dan de veiligheidslimiet, en de documentatie gecreëerd die vereist is om het proces te starten voor het maken van een gecertificeerd medisch hulpmiddel.

Belangrijke Opmerking: Het artikel geeft toe dat dit een "eerste versie" is van het veiligheidsproces. Ze hebben het definitieve medische apparaat nog niet gebouwd en ze hebben de definitieve juridische contracten nog niet volledig ondertekend (de "Lean4-bewijzen" zijn momenteel slechts de schets van het contract). Maar ze hebben de routekaart en de instrumenten gebouwd om daar te komen, wat nog nooit eerder is gedaan voor dit specifieke type technologie.

Technische Samenvatting: Inbedding van Formele Worst-Case Latentiebewijzen en Geheugelveiligheidscertificaten in de snn-mlir MLIR Lowering Pipeline

1. Probleemstelling

Neuromorfische Spiking Neural Networks (SNN's) bieden energiezuinige temporele berekeningen die geschikt zijn voor randapparatuur in medische toepassingen, zoals closed-loop neurostimulatoren voor epilepsie. Echter, hun implementatie in veiligheidskritische omgevingen wordt momenteel gehinderd door een "toolchain gap". Hoewel bestaande frameworks zoals snnTorch en compilers zoals snn-mlir geldige C11-code kunnen genereren van getrainde modellen, slagen ze er niet in om machine-controleerbaar bewijs te leveren dat de gecompileerde inferentiefuncties voldoen aan de Worst-Case Execution Time (WCET) grenzen of de documentatievereisten van de IEC 62304 Class B certificering.

Huidige SNN-compilers integreren geen formele verificatiemethoden (zoals de Implicit Path Enumeration Technique, of IPET) om te bewijzen dat code voldoet aan strikte latentiebeperkingen vereist voor implanteerbare hardware. Zonder deze bewijzen kunnen SNN's niet worden gecertificeerd voor medisch gebruik onder standaarden zoals IEC 62304, die traceerbaarheid van vereisten naar een geverifieerde implementatie voorschrijft.

2. Methodologie

De auteurs stellen een post-processing analysepass voor die opereert op de Multi-Level Intermediate Representation (MLIR) die door de snn-mlir compiler wordt uitgegeven. De pipeline bestaat uit de volgende fasen:

Model Training en Export: Een drie-laagse feedforward Leaky Integrate-and-Fire (LIF) SNN werd getraind met snnTorch op de CHB-MIT scalp EEG dataset (patiënten chb01 en chb02) voor epileptische insultdetectie. Het model werd geëxporteerd naar het Neuromorphic Intermediate Representation (NIR) formaat.
Compilatie: De NIR-grafiek werd verlaagd naar C11-code met behulp van snn-mlir (commit 89b65e0). De code werd gecompileerd met GCC op optimalisatieniveau -O0 om een stabiele, niet-geoptimaliseerde correspondentie tussen de bronstructuur en de uitgegeven instructies te garanderen, wat noodzakelijk is voor nauwkeurige extractie van de control-flow graph (CFG).
Formele WCET Analyse (IPET): Een Python post-processing pass (certify.py) extraheert de CFG van elke gecompileerde LIF-laag. Het formuleert een Implicit Path Enumeration Technique (IPET) Integer Linear Program (ILP) geparametriseerd door de instructietiming van de ARM Cortex-M4F microcontroller. De ILP maximaliseert de cyclusstroom onderhevig aan flow-conservatie beperkingen en loop-back grenzen.
Annotatie en Certificering: De pass annoteert de resulterende C11-code met @wcet_bound commentaren en genereert Lean4 proof-obligation stubs. Deze stubs formuleren de WCET-grenzen als bewijsverplichtingen, waardoor de compileroutput wordt gekoppeld aan een proof assistant.
IEC 62304 Mapping: De gegenereerde artefacten (CFG documentatie, geannoteerde broncode, testlogs) worden gemapt naar specifieke clausules van IEC 62304 Class B (Software Development Process) om naleving van documentatie- en traceerbaarheidvereisten aan te tonen.

3. Belangrijkste Bijdragen

Het artikel claimt vier primaire bijdragen:

Formulering van WCET voor SNN's: De auteurs formuleren de WCET-analyse voor snn-mlir-gecompileerde LIF-inferentiefuncties als een IPET ILP geparametriseerd door ARM Cortex-M4F instructietiming.
Geautomatiseerde Post-Processing Pass: Implementatie van een Python pass die de automatisering van CFG-extractie, ILP-oplossing, WCET-annotatie en Lean4 stub-generatie verzorgt zonder wijzigingen te vereisen in de onderliggende C++ compiler-codebase.
End-to-End Validatie: Validatie van de pipeline op een klinisch relevante insultdetectie-taak, waarbij wordt aangetoond dat de gecompileerde C11-inferentie overeenkomt met het referentiemodel in Python terwijl het aan statische analyse-beperkingen voldoet.
IEC 62304 Artifact Bundle: Voorzienheid van een gemapte artifact bundle die de IEC 62304 Class B softwareontwikkelingsproces categorieën dekt, wat een pad vertegenwoordigt van een getraind model naar een regelgevend-conforme documentatiebundel.

4. Resultaten

Modelprestaties: De getrainde SNN bereikte een 78,8% gebalanceerde accuratesse (95% CI: 74,5–83,2%) op de hold-out testset, waarmee de drempel van 75% voor geloofwaardigheid werd overschreden. De sensitiviteit was 68,6% en de specificiteit was 89,1%.
Compilatie Correctheid: De gecompileerde C11-inferentiefunctie vertoonde een verwaarloosbare divergentie van de snnTorch Python referentie (maximaal verschil $\approx 1 \times 10^{-5}$ ), toegeschreven aan verschillen in floating-point precisie in plaats van systematische bias.
WCET Grenzen:
- De IPET-analyse leverde een uniforme per-laag grens op van 5.634 cycli.
- De gecertificeerde netwerkgrens voor het drie-laagse netwerk is 16.902 cycli (100,6 µs bij 168 MHz).
- Deze grens biedt een 497× marge onder de 50 ms hard real-time deadline voor neurostimulatie.
- De gemeten executietijd was 8.627 cycli (51,4 µs), ruim binnen de gecertificeerde grens.
Artifact Dekking: De gegenereerde bundel dekt volledig vijf van de acht IEC 62304 §5.x softwareontwikkelingsproces categorieën en dekt gedeeltelijk twee andere, wat resulteert in een score van 6,0/8,0 voor het ontwikkelingsproces. Het dekt volledig de configuratiebeheer (§8.0) maar merkt een gebrek aan formele software risicomanagement analyse (§7.1) op.

5. Betekenis en Claims

De auteurs positioneren dit werk als de eerste publiekelijk gedocumenteerde route van een getraind snnTorch model naar een IEC 62304 Class B documentatiebundel voor een SNN-inferentiefunctie.

Nieuwigheid: Het werk overbrugt de kloof tussen neuromorfische compileroutputs en formele verificatiestandaarden, specifiek door IPET toe te passen op SNN's en Lean4 proof obligations te genereren.
Bescheidenheid en Beperkingen: De auteurs geven expliciet aan dat de Lean4 stubs specificaties zijn, geen geverifieerde bewijzen; het afhandelen van deze bewijzen wordt overgelaten aan toekomstige collaborators. De WCET-grenzen zijn afgeleid van ongeoptimaliseerde (-O0) builds en toegepast als een cross-architectuur benadering (x86_64 host met ARM timing modellen) in plaats van via native ARM cross-compilatie. De risicomanagement analyse (§7.1) is niet uitgevoerd, en de studie is beperkt tot twee patiënten uit de CHB-MIT dataset.
Conclusie: De pipeline vestigt een reproduceerbare baseline voor toekomstig werk richting volledig geverifieerde neuromorfische edge-implementatie, waarbij wordt aangetoond dat SNN's kunnen worden gecompileerd naar C11-code met machine-controleerbare latentie-grenzen die geschikt zijn voor veiligheidskritische medische certificering.