ESBMC-Arduino: Hardware-Faithful PLC Verification

• The paper introduces ESBMC-Arduino, a verification approach that bridges the gap between abstract PLC models and actual Arduino hardware by integrating sensor and finite-word constraints.
• It employs a declarative hardware abstraction layer to model finite word widths and realistic ADC/PWM ranges, eliminating 44% false alarms in a 123-program corpus.
• The lightweight implementation within the ESBMC framework demonstrates that hardware-faithful models can detect genuine safety defects while preserving robust verification for embedded systems.

Searching arXiv for the target paper and closely related ESBMC background papers. ESBMC-Arduino is a hardware-faithful verification approach for IEC 61131-3 programs deployed on open-hardware programmable logic controller platforms built around Arduino-class microcontrollers, including OpenPLC, Arduino OPTA, CONTROLLINO, and Industrial Shields M-Duino. It was introduced to address the “deployment gap” between verification over an abstract scan-cycle model with unbounded integers and execution on a resource-constrained microcontroller unit with finite word width and finite-resolution peripherals. In the formulation reported for 123 real programs, naive width-aware verification without a hardware input model produced 44% false alarms, namely 54 out of 123 programs, and found no genuine defects, because it explored sensor values that no analog-to-digital converter can produce. ESBMC-Arduino closes that gap through a declarative hardware abstraction layer descriptor and a sound lowering that interprets arithmetic at target width while constraining inputs to hardware-realizable ranges (Dantas et al., 9 Jul 2026).

1. Definition and problem setting

ESBMC-Arduino targets a specific mismatch between formal verification models and deployed PLC artifacts. Existing open-source verifiers for IEC 61131-3, including ESBMC-PLC, prove safety over an abstract scan-cycle model with idealized unbounded integers, whereas the deployed board artifact runs on a microcontroller with board-specific machine integers and with sensor inputs mediated by finite-resolution peripherals such as ADCs (Dantas et al., 9 Jul 2026).

The deployment gap has two directions. One direction is missed defects: a property may hold in the abstract model but fail on the actual device because arithmetic is performed at the target width. The other direction is false alarms: verification may report bugs by exploring sensor values that cannot arise on the physical hardware. The paper formalizes this contrast with an abstract model $M_{abs}(P)$ and a deployment model $M_{dev}(P,H)$, where the gap appears when

$$M_{abs}(P) \models \varphi \text{ but } M_{dev}(P,H) \not\models \varphi$$

or vice versa (Dantas et al., 9 Jul 2026).

The paper locates the critical failure mode “where computation meets the physical process”: a bounded sensor reading is scaled by finite-width arithmetic into an actuation command. Under these circumstances, an overflow can silently suppress a safety action, such as a high-level alarm. Conversely, an unbounded input model can fabricate alarms that no environment can trigger (Dantas et al., 9 Jul 2026).

2. Hardware model and declarative HAL descriptor

The central abstraction in ESBMC-Arduino is a declarative hardware abstraction layer descriptor:

$$H = \langle w,\, b_{\mathrm{adc}},\, b_{\mathrm{pwm}},\, \mu \rangle$$

where $w$ is the target machine word width, $b_{\mathrm{adc}}$ is the ADC resolution, $b_{\mathrm{pwm}}$ is the PWM resolution, and $\mu$ maps IEC addresses to input or output types and domains (Dantas et al., 9 Jul 2026).

The descriptor is board-specific and compact. For Arduino Uno, the paper gives the example $w=16$, $b_{\mathrm{adc}}=10$, and $M_{dev}(P,H)$0. The mapping function $M_{dev}(P,H)$1 is used to recover realizable domains from IEC addressing. The details give the following representative bindings:

$M_{dev}(P,H)$2

$M_{dev}(P,H)$3

with $M_{dev}(P,H)$4 and $M_{dev}(P,H)$5 corresponding to outputs (Dantas et al., 9 Jul 2026).

A notable engineering property is that HAL parameters are derived from official Arduino cores, described as “Auto inputs,” so that manual annotations are not required from the user. The implementation reported in the paper instantiates this abstraction for Arduino as ArduinoTool, deriving parameters such as INT_BITS and ADC_MAX from official cores and realizing the input-range model in the ESBMC Ladder Diagram frontend (Dantas et al., 9 Jul 2026).

A concise comparison with the preexisting abstract style of verification is as follows.

Aspect	Abstract verification	ESBMC-Arduino
Arithmetic semantics	Unbounded integers	HAL-specified word width
Input domains	Unconstrained	Hardware-realizable ranges
I/O interpretation	Abstract scan-cycle	Width, ADC/PWM resolution, I/O binding

This structure suggests that ESBMC-Arduino is not merely a bug-finding refinement, but a semantic alignment mechanism between IEC 61131-3 verification and MCU deployment.

3. Lowering to a hardware-faithful verification model

The lowering process transforms a PLC program $M_{dev}(P,H)$6, a property $M_{dev}(P,H)$7, and a hardware descriptor $M_{dev}(P,H)$8 into a hardware-faithful verification model $M_{dev}(P,H)$9. The paper decomposes this lowering into several components (Dantas et al., 9 Jul 2026).

First, arithmetic is interpreted at the HAL-specified word width $$M_{abs}(P) \models \varphi \text{ but } M_{dev}(P,H) \not\models \varphi$$0, so overflow, underflow, and wrap-around follow the semantics of the target board. For 16-bit AVR-based boards this means that verification reasons about 16-bit behavior rather than idealized integers.

Second, each input variable sampled nondeterministically during the PLC scan cycle is constrained immediately afterward with an assumption derived from the IEC address and the HAL domain. For an ADC-backed input this yields assumptions such as assume(0 ≤ i ≤ 1023), while Boolean inputs receive assumptions such as assume(i == 0 || i == 1). Integer bounds are derived automatically from IEC addresses, with no programmer intervention (Dantas et al., 9 Jul 2026).

Third, quantization and saturation are modeled explicitly. ADC reads are represented as nondeterministic values within representable codes, and writes to PWM are clamped to the interval $$M_{abs}(P) \models \varphi \text{ but } M_{dev}(P,H) \not\models \varphi$$1 (Dantas et al., 9 Jul 2026).

Fourth, nonlinear or floating-point function blocks are handled by over-approximation: outputs are modeled as nondeterministic values constrained only by their declared output range. The paper characterizes this as safe but possibly imprecise, preserving soundness while limiting semantic commitments in blocks whose computations are not faithfully lowered (Dantas et al., 9 Jul 2026).

The scan-cycle structure is summarized as

$$M_{abs}(P) \models \varphi \text{ but } M_{dev}(P,H) \not\models \varphi$$2

with sampling refined to

$$M_{abs}(P) \models \varphi \text{ but } M_{dev}(P,H) \not\models \varphi$$3

so that symbolic inputs range only over hardware-realizable values (Dantas et al., 9 Jul 2026).

4. Soundness, realizability, and false-alarm elimination

A defining claim of ESBMC-Arduino is that naive width-aware checking is unsound when it ignores the hardware input model. On the 123-program corpus, checking 16-bit overflow without hardware input constraints flagged 54 of 123 programs as unsafe, a 44% false-alarm rate, and found no genuine defects, because it explored out-of-range input values that an Arduino cannot produce (Dantas et al., 9 Jul 2026).

ESBMC-Arduino addresses this by integrating HAL information through automatic per-variable constraint insertion. As a result, only hardware-realizable input values are considered, and every counterexample reported by the deployment model is intended to correspond to a physically realizable witness. The paper states a soundness theorem: for a faithful descriptor $$M_{abs}(P) \models \varphi \text{ but } M_{dev}(P,H) \not\models \varphi$$4, every counterexample reported by $$M_{abs}(P) \models \varphi \text{ but } M_{dev}(P,H) \not\models \varphi$$5 is physically realizable, and all device behaviors are admitted in the model (Dantas et al., 9 Jul 2026).

The state-space inclusion underlying that claim is written as

$$M_{abs}(P) \models \varphi \text{ but } M_{dev}(P,H) \not\models \varphi$$6

which ensures that the verification model covers reachable device behaviors. The details also note that proof soundness is stated modulo the abstraction used for nonlinear blocks (Dantas et al., 9 Jul 2026).

The significance of this result is methodological as much as practical. It distinguishes between a broad over-approximation of the software state space and an over-approximation that remains faithful to the device interface. This suggests that, in embedded control verification, unconstrained nondeterminism at the sensor boundary is not a neutral modeling choice but a source of systematic spurious defects.

5. Evaluation on real and controlled corpora

The reported evaluation uses a 123-program corpus and an additional controlled corpus. For naive width-aware checking at 16 bits with no input model, 54 out of 123 programs were flagged unsafe, all false alarms, and zero genuine hardware defects were detected (Dantas et al., 9 Jul 2026).

For ESBMC-Arduino with HAL annotation, all 54 false alarms were eliminated, reducing the count from 54 to 0. At the same time, all 32 previously known safe programs remained proved safe, which the paper describes as preserving robustness proofs. A small number of programs remained “unknown” because of tool limitations associated with proof completeness on programs with internal loops, and the paper states that this status was not caused by the HAL model (Dantas et al., 9 Jul 2026).

The controlled corpus was designed to expose rare width-dependent defects. In that setting, deliberately overflowing programs were detected as unsafe, and the counterexamples used realizable inputs. The paper gives an example in which scaling an ADC input by 100 on 16-bit hardware produces an unsafe condition, with a realizable witness such as adc = 898 in a tank-control high-level alarm scenario (Dantas et al., 9 Jul 2026).

These results position ESBMC-Arduino as a verifier that simultaneously removes a substantial class of spurious alarms and preserves the ability to detect device-level arithmetic faults. A plausible implication is that its principal contribution is not increased aggressiveness of bug finding, but improved discriminative power between realizable and non-realizable counterexamples.

6. Implementation and relation to the ESBMC line

The implementation is described as lightweight in the frontend and conservative in the backend. The paper states that the approach is realized in approximately 40 lines of code in the ESBMC frontend as a pluggable annotator hook. Input-domain constraints are injected immediately after each variable’s nondeterministic assignment, while backend analyses such as k-induction and SMT solving remain unchanged (Dantas et al., 9 Jul 2026).

ESBMC-Arduino builds on the broader ESBMC tradition of bit-precise SMT-based bounded model checking for embedded software. Earlier ESBMC work extended SMT-based bounded model checking for embedded ANSI-C with accurate support for finite variables, bit-vector operations, arrays, structures, unions, and pointers, and showed that this style of encoding could analyze larger embedded programs while reducing verification time (0907.2072). That lineage is relevant because ESBMC-Arduino depends on exact reasoning about fixed-width arithmetic rather than abstract numerical domains.

There is also a direct thematic connection to prior ESBMC work on fixed-point digital filters. That work verified overflows, limit cycles, and timing constraints in C implementations that model microcontroller deployment, using nondeterministic inputs and assertions over fixed-point ranges (Abreu et al., 2013). ESBMC-Arduino differs in focus: it does not simply make arithmetic finite-width, but couples width precision to a board-level input model so that input exploration respects ADC realizability (Dantas et al., 9 Jul 2026).

A further connection appears in timing-oriented ESBMC research, where discrete-time constraints were encoded into ordinary program variables and verified with an untimed model checker (Barreto et al., 2011). In both cases, the strategy is to enrich source-level verification with concrete deployment semantics rather than to reason over a detached abstraction. This suggests a broader methodological pattern in ESBMC research: deployment properties are often recovered by instrumentation that preserves the existing backend.

7. Scope, limits, and implications for open-hardware PLC verification

ESBMC-Arduino is formulated for IEC 61131-3 on open hardware, with an instantiated tool chain for Arduino-based targets and with a focus on LD frontend integration (Dantas et al., 9 Jul 2026). Its immediate scope is the semantic region defined by target word width, ADC/PWM resolution, and I/O binding. Within that region, its main claim is that verification results become hardware-faithful: proofs correspond to absence of hardware-induced defects under the modeled assumptions, and bug reports carry physically realizable witnesses.

The paper is explicit about one limit of precision. For nonlinear or floating-point function blocks, outputs are over-approximated nondeterministically within declared output ranges. This preserves soundness but may reduce precision (Dantas et al., 9 Jul 2026). It is therefore not a complete physical plant model; rather, it is a faithful interface model for the MCU-side computational semantics and I/O domains.

The work also clarifies a common misconception in PLC verification: making arithmetic width-aware is not sufficient to model deployment correctly. The 54 false alarms in the 123-program corpus arose precisely because width awareness without a hardware input model explored impossible ADC values (Dantas et al., 9 Jul 2026). The correction is not simply more bit precision, but joint modeling of arithmetic width and sensor realizability.

In that sense, ESBMC-Arduino defines a board-conscious verification regime for open-hardware PLCs. It preserves the verification workflow of ESBMC while shifting the semantic reference point from an idealized PLC scan-cycle to the actual microcontroller execution environment.