⚡ electrical engineering

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

This paper introduces ESBMC-Arduino, a hardware-faithful verification framework that bridges the deployment gap for open-hardware PLCs by integrating a declarative hardware abstraction layer and sound input-range modeling to eliminate false alarms caused by idealized integer assumptions while detecting genuine width-dependent defects in IEC 61131-3 programs running on resource-constrained microcontrollers.

Original authors: Pierre Dantas, Lucas Cordeiro, Waldir Junior

Published 2026-07-10

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Pierre Dantas, Lucas Cordeiro, Waldir Junior

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a robot to manage a water tank. You write the instructions in a special language called IEC 61131-3, which is like a universal recipe book for industrial machines. For years, engineers have used "super-robot" simulators to check if these recipes are safe. These simulators are like wizards who can think with infinite numbers; they assume the robot can hold any number in its head, from negative infinity to positive infinity, and that sensors can report any value imaginable.

But here is the twist: the actual robot you build isn't a wizard. It's a tiny, cheap microcontroller (like an Arduino) that lives in the real world. This little chip has a very specific, limited brain. It can only hold numbers up to 32,767. If a calculation goes higher, the number doesn't just get bigger; it breaks, snaps back to the bottom, and turns into a negative number. It's like a car odometer that rolls over from 999,999 back to 000,000.

The Great Disconnect
The paper calls this the "deployment gap." It's the difference between the wizard's dream world and the robot's cramped reality.

The authors found that when engineers used the old "wizard" simulators to check their code for safety, they were getting a massive amount of false alarms. Out of 123 real-world programs they tested, the old simulators screamed "DANGER!" 54 times (a 44% false-alarm rate). But when they looked closer, they realized these "dangers" were impossible. The simulators were imagining sensor readings like -32,764. In the real world, a sensor connected to this robot can only read numbers between 0 and 1,023 (because it's a 10-bit sensor). A value of -32,764 is like a thermometer reading "minus 32,764 degrees"—it simply cannot happen.

The paper argues that relying on these old simulators is like a security guard yelling "Intruder!" because they saw a ghost. The guard is technically "correct" about the ghost, but useless because ghosts don't exist. The authors explicitly rule out the idea that you can just check for math errors without also checking what the sensors can actually see. They show that doing so makes the verification "unsound" (unreliable) in practice.

The Magic Fix: The HAL Descriptor
To fix this, the authors built a new tool called ESBMC-Arduino. Think of this tool as a "Reality Check" filter.

Before the wizard simulator looks at the code, this new tool attaches a tiny, automatic note to every sensor. It says, "Hey, remember, this sensor can only give numbers between 0 and 1,023." It also reminds the simulator, "And remember, the robot's brain can only hold numbers up to 32,767."

When the simulator runs with these rules, the magic happens:

The 54 false alarms vanish instantly. The ghost of -32,764 is gone because the simulator now knows that number is impossible.
The 32 programs that were already proven safe stay safe.
Most importantly, the tool didn't miss any real bugs. It found that the old simulators were hiding a specific type of real danger: when a sensor reading gets multiplied by a big number (like turning a raw sensor value into a percentage), the math can overflow the tiny robot's brain.

The Real Danger (and how rare it is)
The paper found that while the "ghost alarms" were common, the real bugs caused by this gap were actually quite rare in the public code they tested. They only found genuine defects in specific scenarios where a sensor reading was multiplied by a large constant (like 100) on a 16-bit board.

For example, if a sensor reads 898 (which is a normal, real value), and the code multiplies it by 100, the result is 89,800. This is too big for the 16-bit robot brain (max 32,767). The number wraps around, becomes a negative number, and the robot thinks the water tank is empty when it's actually overflowing. The new tool caught this exact scenario and gave the engineers a real, physical example of the sensor reading that would cause the crash.

What the Paper Doesn't Claim
The authors are very honest about what they didn't do. They didn't prove that every program is now safe. Out of the 123 programs, 91 ended up with a verdict of "unknown." This isn't because the tool is broken; it's because the math to prove those specific programs safe is too hard for the current engine to finish. The tool successfully removed the noise (the false alarms) and kept the signal (the real proofs), but it couldn't solve the hardest puzzles yet.

Also, they didn't test this on floating-point numbers (decimals like 3.14) or complex physics simulations. They focused strictly on whole numbers (integers) and Boolean logic (on/off switches).

The Bottom Line
The paper demonstrates that to verify open-hardware PLCs (like those used in schools and small factories), you can't just check the math; you have to check the limits of the hardware. By automatically adding a "Reality Check" that tells the simulator what the sensors can actually do, they turned a noisy, unreliable tool into a trustworthy one. They didn't find a million new bugs, but they stopped the tool from crying wolf, making it possible for engineers to trust the safety checks again.

Technical Summary: ESBMC-ARDUINO

Problem: The Deployment Gap in Open-Hardware PLCs
Open-hardware Programmable Logic Controllers (PLCs), such as OpenPLC running on Arduino OPTA, CONTROLLINO, and Industrial Shields M-Duino, have democratized IEC 61131-3 programming for low-cost, microcontroller-class devices. These platforms are increasingly used in education, small-scale automation, and as the runtime substrate for Industrial Control Systems (ICS) security research. However, a critical "deployment gap" exists between the abstract models used by existing open-source verifiers (e.g., ESBMC-PLC, PLCverif) and the actual hardware execution environment.

Current verifiers operate on an abstract scan-cycle model assuming idealized, unbounded integers and unconstrained inputs. In contrast, the deployed artifacts run on resource-constrained Microcontroller Units (MCUs) with specific machine word widths (e.g., 16-bit int on 8-bit AVR boards) and finite-resolution Analog-to-Digital Converters (ADCs, typically 10-bit, yielding values in $[0, 1023]$ ). This discrepancy leads to two failure modes:

Missed Defects: A program may be proven safe in the abstract model but unsafe on the device due to integer overflow caused by narrow word widths (e.g., a scaling calculation wrapping on a 16-bit board).
Phantom Alarms (False Positives): More critically, naive width-aware verification that accounts for word width but ignores hardware input bounds explores sensor values that no physical ADC can produce (e.g., negative values or values exceeding 1023). This results in spurious overflow reports. Evaluation on a corpus of 123 real third-party programs showed that naive 16-bit overflow checking yields a 44% false-alarm rate (54/123) while finding zero genuine defects.

Methodology: Hardware-Faithful Verification
The paper proposes a method to close this gap by constructing a "deployment model" ( $M_{dev}$ ) that faithfully represents the target hardware. The core of this approach is a Hardware Abstraction Layer (HAL) descriptor and a sound lowering process.

HAL Descriptor ( $H$ ): A declarative tuple $H = \langle w, b_{adc}, b_{pwm}, \mu \rangle$ $H = ⟨ w, b_{a d c}, b_{pw m}, μ ⟩$ that captures:
- $w$ : The machine word width (e.g., 16-bit for AVR, 32-bit for ARM).
- $b_{adc}$ and $b_{pwm}$ : The resolution of Analog-to-Digital Converters and Pulse-Width Modulation outputs.
- $\mu$ : An I/O binding map derived automatically from the IEC 6131-3 direct-addressing scheme (e.g., %IW addresses map to analog inputs with specific ADC ranges).
Faithful Lowering: The method transforms the PLC program ( $P$ $P$ ) into a deployment model ( $M_{dev}(P, H)$ $M_{d e v} (P, H)$ ) by:
- Interpreting arithmetic at the target word width $w$ (reproducing two's-complement wrap-around exactly).
- Injecting assume constraints immediately after input sampling to restrict variables to their hardware-realizable ranges (e.g., $0 \leq adc \leq 1023$ ).
- Over-approximating non-linear function blocks (e.g., PID) with nondeterministic outputs to maintain tractability.
Verification Engine: The method reuses the ESBMC backend (SMT-based Bounded Model Checking and $k$ -induction) without modification. The lowering occurs in the Ladder Diagram (LD) frontend, adding a lightweight hook (approx. 40 lines) that enforces input bounds and sets the architecture word width.

Key Contributions

Hardware-Faithful Verification Method: A formal approach that transfers the target-model discipline of safety-critical embedded C (established by tools like Frama-C and Astrée) to the PLC domain. Unlike those tools, which require manual input contracts, this method automatically derives input bounds from the standard IEC 61131-3 addressing scheme and board descriptors.
ESBMC-Arduino Instantiation: A concrete implementation for Arduino-class targets, sourcing HAL parameters from official Arduino cores. It supports both 16-bit (AVR) and 32-bit (ARM) targets.
Empirical Evaluation: A rigorous evaluation on 123 real-world programs and a controlled corpus of 20 patterns.

Results

Elimination of False Alarms: On the 123-program corpus, enabling the HAL annotator eliminated all 54 false alarms (reducing the unsafe count from 54 to 0) while preserving every robustness proof (32 programs remained proven safe).
Detection of Genuine Defects: A controlled corpus demonstrated that the method detects genuine, width-dependent defects (e.g., overflow in ADC-to-percentage scaling on 16-bit boards) with physically realizable witnesses.
Cross-Tool Validation: The phenomenon of "phantom alarms" was reproduced using independent tools (CBMC and Frama-C/EVA) on C mirrors of the logic, confirming that the issue is inherent to naive width-aware verification without input modeling, not specific to ESBMC.
Performance: The overhead of the HAL annotator is negligible; verification times remain under one second per program.
Limitations: While false alarms are eliminated, 91 programs in the real corpus returned "unknown" verdicts due to $k$ -induction incompleteness on function blocks with internal state. This is a limitation of the prover's ability to close inductive steps, not the input model.

Significance
The paper argues that the primary value of this work is not in the count of discovered bugs (which are rare in the specific public corpora surveyed, dominated by Boolean and timer logic), but in the restoration of soundness. The authors demonstrate that naive width-aware verification is unusable for assurance due to a 44% false-alarm rate that drowns out genuine findings. By automatically deriving hardware-realizable input ranges, the method converts an unreliable tool into one that issues only realizable reports, enabling engineers to trust verification results for open-hardware PLCs. The approach is presented as a realistic, low-cost adoption strategy (a 4-field descriptor and a 40-line hook) that integrates with mature verification infrastructure rather than requiring a clean-slate proposal.

Technical Summary: ESBMC-ARDUINO

More like this