⚡ electrical engineering

ESBMC-Arduino: Closing the Deployment Gap for Formal Verification of Open-Hardware PLCs

Dit artikel introduceert ESBMC-Arduino, een hardware-getrouwe verificatieframework die de implementatiekloof voor open-hardware PLC's overbrugt door een declaratieve hardware-abstractielaag en een sluitende input-bereikmodellering te integreren om valse alarmen veroorzaakt door geïdealiseerde integer-aannames te elimineren, terwijl het werkelijke breedte-afhankelijke defecten detecteert in IEC 61131-3 programma's die draaien op microcontrollers met beperkte middelen.

Oorspronkelijke auteurs: Pierre Dantas, Lucas Cordeiro, Waldir Junior

Gepubliceerd 2026-07-10

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Pierre Dantas, Lucas Cordeiro, Waldir Junior

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://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 robot bouwt om een watertank te beheren. Je schrijft de instructies in een speciale taal genaamd IEC 61131-3, wat een soort universeel receptenboek is voor industriële machines. Jarenlang hebben ingenieurs "super-robot" simulators gebruikt om te controleren of deze recepten veilig zijn. Deze simulators zijn als tovenaars die kunnen denken met oneindige getallen; ze gaan ervan uit dat de robot elk getal in zijn hoofd kan houden, van negatief oneindig tot positief oneindig, en dat sensoren elke denkbare waarde kunnen rapporteren.

Maar hier komt de twist: de eigenlijke robot die je bouwt, is geen tovenaar. Het is een kleine, goedkope microcontroller (zoals een Arduino) die in de echte wereld leeft. Deze kleine chip heeft een zeer specifieke, beperkte hersenstructuur. Hij kan alleen getallen aanhouden tot 32.767. Als een berekening hoger komt, wordt het getal niet zomaar groter; het breekt, springt terug naar de onderkant en verandert in een negatief getal. Het is als een kilometerteller van een auto die van 999.999 terugspringt naar 000.000.

De Grote Kloof
Het paper noemt dit de "deployment gap" (de implementatiekloof). Het is het verschil tussen de droomwereld van de tovenaar en de krappe realiteit van de robot.

De auteurs ontdekten dat wanneer ingenieurs de oude "tovenaars" simulators gebruikten om hun code te controleren op veiligheid, ze een enorme hoeveelheid valse alarmen kregen. Van de 123 echte programma's die ze testten, schreeuwden de oude simulators 54 keer "GEVAAR!" (een vals-positief percentage van 44%). Maar toen ze beter keken, realiseerden ze zich dat deze "gevaren" onmogelijk waren. De simulators stelden zich sensorwaarden voor zoals -32.764. In de echte wereld kan een sensor die verbonden is met deze robot alleen waarden rapporteren tussen 0 en 1.023 (omdat het een 10-bit sensor is). Een waarde van -32.764 is als een thermometer die "minus 32.764 graden" aangeeft—dat kan simpelweg niet gebeuren.

Het paper betoogt dat vertrouwen op deze oude simulators is als een beveiliger die "Indringer!" roept omdat hij een spook heeft gezien. De bewaker is technisch gezien "correct" over de geest, maar nutteloos omdat geesten niet bestaan. De auteurs sluiten expliciet de mogelijkheid uit dat je alleen wiskundige fouten kunt controleren zonder ook te controleren wat de sensoren daadwerkelijk kunnen zien. Ze laten zien dat het doen van enkel dat laatste de verificatie "onzuiver" (onbetrouwbaar) maakt in de praktijk.

De Magische Oplossing: De HAL Descriptor
Om dit op te lossen, hebben de auteurs een nieuwe tool gebouwd genaamd ESBMC-Arduino. Zie deze tool als een "Reality Check" filter.

Voordat de tovenaar-simulator naar de code kijkt, plakt deze nieuwe tool automatisch een klein briefje aan elke sensor. Er staat: "Hé, onthoud, deze sensor kan alleen getallen geven tussen 0 en 1.023." Het herinnert de simulator er ook aan: "En onthoud, de hersenen van de robot kunnen alleen getallen aanhouden tot 32.767."

Wanneer de simulator met deze regels draait, gebeurt er iets magisch:

De 54 valse alarmen verdwijnen onmiddellijk. De geest van -32.764 is weg omdat de simulator nu weet dat dit getal onmogelijk is.
De 32 programma's die al als veilig waren bewezen, blijven veilig.
Belangrijker nog: de tool heeft geen echte bugs gemist. Ze ontdekten dat de oude simulators een specif kind van echt gevaar verborgen: wanneer een sensorwaarde wordt vermenigvuldigd met een groot getal (zoals het omzetten van een ruwe sensorwaarde naar een percentage), kan de wiskunde de kleine hersenen van de robot laten overstromen (overflow).

Het Echte Gevaar (en hoe zeldzaam het is)
Het paper vond dat hoewel de "geest-alarmen" veel voorkwamen, de echte bugs veroorzaakt door deze kloof eigenlijk vrij zeldzaam waren in de publieke code die ze testten. Ze vonden alleen echte defecten in specifieke scenario's waar een sensorwaarde werd vermenigvuldigd met een grote constante (zoals 100) op een 16-bit bord.

Stel bijvoorbeeld dat een sensor een waarde van 898 leest (een normale, echte waarde), en de code vermenigvuldigt dit met 100, dan is het resultaat 89.800. Dit is te groot voor de 16-bit hersenen van de robot (maximaal 32.767). Het getal slaat om, wordt een negatief getal, en de robot denkt dat de watertank leeg is terwijl hij in werkelijkheid overstroomt. De nieuwe tool ving exact dit scenario en gaf de ingenieurs een echt, fysiek voorbeeld van de sensorwaarde die de crash zou veroorzaken.

Wat het Paper Niet Beweert
De auteurs zijn zeer eerlijk over wat ze niet hebben gedaan. Ze hebben niet bewezen dat elk programma nu veilig is. Van de 123 programma's eindigden 91 met een oordeel van "onbekend". Dit komt niet omdat de tool kapot is, maar omdat de wiskunde om die specifieke programma's veilig te bewijzen te moeilijk is voor de huidige engine om af te ronden. De tool heeft succesvol de ruis (de valse alarmen) verwijderd en de signalen (de echte bewijzen) behouden, maar kon de moeilijkste puzzels nog niet oplossen.

Ook hebben ze dit niet getest met floating-point getallen (decimalen zoals 3,14) of complexe natuurkundige simulaties. Ze concentreerden zich strikt op gehele getallen (integers) en Booleaanse logica (aan/uit-schakelaars).

De Kern van het Verhaal
Het paper demonstreert dat om open-hardware PLC's (zoals die gebruikt worden in scholen en kleine fabrieken) te verifiëren, je niet alleen de wiskunde kunt controleren; je moet ook de limieten van de hardware controleren. Door automatisch een "Reality Check" toe te voegen die de simulator vertelt wat de sensoren daadwerkelijk kunnen doen, hebben ze een lawaaierige, onbetrouwbare tool veranderd in een betrouwbare tool. Ze hebben niet een miljoen nieuwe bugs gevonden, maar ze hebben de tool gestopt met het "roepen om een wolf", waardoor het voor ingenieurs weer mogelijk werd om de veiligheidscontroles te vertrouwen.

Technische Samenvatting: ESBMC-ARDUINO

Probleem: De implementatiekloof in Open-Hardware PLC's
Open-hardware Programmable Logic Controllers (PLC's), zoals OpenPLC draaiend op Arduino OPTA, CONTROLLINO en Industrial Shields M-Duino, hebben de IEC 61131-3 programmering gedemocratiseerd voor goedkope microcontrollers-klasse apparaten. Deze platforms worden steeds vaker gebruikt in het onderwijs, kleinschalige automatisering en als runtime-substraat voor onderzoek naar de beveiliging van industriële controlesystemen (ICS). Er bestaat echter een kritische "implementatiekloof" tussen de abstracte modellen die door bestaande open-source verifiers (bijv. ES_BMC-PLC, PLCverif) worden gebruikt en de werkelijke hardware-executieomgeving.

Huidige verifiers werken op een abstract scan-cycle model dat uitgaat van geïdealiseerde, onbegrensde gehele getallen en onbeperkte inputs. In tegen tegenstelling hiertoe draaien de gedeponeerde artefacten op hulpbron-beperkte Microcontroller Units (MCU's) met specifieke machine-woordbreedtes (bijv. een 16-bit int op 8-bit AVR-borden) en eindige resolutie Analoog-naar-Digitaal Converters (ADC's, doorgaans 10-bit, resulterend in waarden in $[0, 1023]$ ). Deze discrepantie leidt tot twee foutmodi:

Gemiste defecten: Een programma kan veilig worden bewezen in het abstracte model, maar onveilig zijn op het apparaat door integer overflow veroorzaakt door smalle woordbreedtes (bijv. een schaleringsberekening die ronddraait op een 16-bit bord).
Fantoomalarmen (False Positives): Nog kritischer is dat naïeve breedte-bewuste verificatie, die wel rekening houdt met de woordbreedte maar de hardware-inputgrenzen negeert, sensorwaarden verkent die een fysieke ADC niet kan produceren (bijv. negatieve waarden of waarden boven de 1023). Dit resulteert in spookmatige overflow-rapportages. Evaluatie op een corpus van 123 echte derde-partij programma's toonde aan dat naïeve 16-bit overflow-controle een false-alarm rate van 44% (54/123) oplevert, terwijl het nul genuine defecten vond.

Methodologie: Hardware-getrouwe Verificatie
Het artikel stelt een methode voor om deze kloof te dichten door een "deployment model" ( $M_{dev}$ ) te construeren dat de doelhardware getrouw representeert. De kern van deze aanpak is een Hardware Abstraction Layer (HAL) descriptor en een sound lowering proces.

HAL Descriptor ( $H$ ): Een declaratieve tupel $H = \langle w, b_{adc}, b_{pwm}, \mu \rangle$ $H = ⟨ w, b_{a d c}, b_{pw m}, μ ⟩$ die het volgende vastlegt:
- $w$ : De machine-woordbreedte (bijv. 16-bit voor AVR, 32-bit voor ARM).
- $b_{adc}$ en $b_{pwm}$ : De resolutie van Analoog-naar-Digitaal Converters en Pulse-Width Modulation outputs.
- $\mu$ : Een I/O-binding map afgeleid van het automatische IEC 61131-3 direct-addressing schema (bijv. %IW adressen mappen naar analoge inputs met specifieke ADC-ranges).
Faithful Lowering: De methode transformeert het PLC-programma ( $P$ $P$ ) naar een deployment model ( $M_{dev}(P, H)$ $M_{d e v} (P, H)$ ) door:
- Rekenkundige operaties te interpreteren op de doel-woordbreedte $w$ (waarbij de two's-complement wrap-around exact wordt gereproduceerd).
- assume constraints direct na de input sampling te injecteren om variabelen te beperken tot hun hardware-realiseerbare bereiken (bijv. $0 \leq adc \leq 1023$ ).
- Niet-lineaire function blocks (bijv. PID) te over-approximeren met niet-deterministische outputs om de tractabiliteit te behouden.
Verificatie Engine: De methode hergebruikt de ESBMC backend (SMT-gebaseerde Bounded Model Checking en $k$ -induction) zonder modificatie. De lowering vindt plaats in de Ladder Diagram (LD) frontend, waarbij een lichte hook (ongeveer 40 regels) wordt toegevoegd die de inputgrenzen afdwingt en de architectuur-woordbreedte instelt.

Belangrijkste Bijdragen

Hardware-getrouwe Verificatiemethode: Een formele aanpak die de target-model discipline van veiligheidskritische embedded C (gevestigd door tools zoals Frama-C en Astrée) overbrengt naar het PLC-domein. In tegenstelling tot deze tools, die handmatige input-contracten vereisen, afleidt deze methode automatisch de inputgrenzen uit het standaard IEC 61131-3 adresseringsschema en de board descriptors.
ESBMC-Arduino Instantiatie: Een concrete implementatie voor Arduino-klasse targets, waarbij HAL-parameters worden gehaald uit officiële Arduino cores. Het ondersteunt zowel 16-bit (AVR) als 32-bit (ARM) targets.
Empirische Evaluatie: Een rigoureuze evaluatie op 123 echte programma's en een gecontroleerd corpus van 20 patronen.

Resultaten

Eliminatie van False Alarms: Bij de 123-programma corpus elimineerde het inschakelen van de HAL annotator alle 54 false alarms (waardoor het aantal onveilige gevallen werd gereduceerd van 54 naar 0) terwijl elke robuustheidsbewijs behouden bleef (32 programma's bleven veilig bewezen).
Detectie van Genuiene Defecten: Een gecontroleerd corpus demonstreerde dat de methode genuine, breedte-afhankelijke defecten (bijv. overflow in ADC-naar-percentage schaling op 16-bit borden) detecteert met fysiek realiseerbare witnesses.
Cross-Tool Validatie: Het fenomeen van "phantom alarms" werd gereproduceerd met onafhankelijke tools (CBMC en Frama-C/EVA) op C-mirrors van de logica, wat bevestigt dat het probleem inherent is aan naïeve breedte-bewuste verificatie zonder input-modellering, en niet specifief is voor ESBMC.
Prestaties: De overhead van de HAL annotator is verwaarloosbaar; verificatietijden blijven onder de één seconde per programma.
Beperkingen: Hoewel false alarms zijn geëlimineerd, gaven 91 programma's in het echte corpus een "unknown" verdict vanwege $k$ -induction incompletheid op function blocks met interne staat. Dit is een beperking van het vermogen van de prover om inductieve stappen te sluiten, niet van het input model.

Betekenis
Het artikel betoogt dat de primaire waarde van dit werk niet ligt in het aantal ontdekte bugs (die zeldzaam zijn in de specifieke publieke corpora die zijn onderzocht, die gedomineerd worden door Boolean en timer logica), maar in de herstel van de soundness (deugdelijkheid). De auteurs demonstreren dat naïeve breedte-bewuste verificatie onbruikbaar is voor assurance vanwege een 44% false-alarm rate die genuine bevindingen overstemt. Door hardware-realiseerbare inputbereiken automatisch af te leiden, zet de methode een onbetrouwbare tool om in een tool die alleen realiseerbare rapporten afgeeft, waardoor ingenieurs de verificatieresultaten voor open-hardware PLC's kunnen vertrouwen. De aanpak wordt gepresenteerd als een realistische, laag-kosten adoptiestrategie (een 4-veld descriptor en een 40-regels hook) die integreert met volwassen verificatie-infrastructuur in plaats van een nieuw ontwerp vanaf nul te vereisen.

Technische Samenvatting: ESBMC-ARDUINO

Meer zoals dit