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

Abstract: OpenPLC, Arduino OPTA, CONTROLLINO, and Industrial Shields M-Duino bring IEC 61131-3 to low-cost microcontrollers used in real automation and industrial control system (ICS) security research. Existing open-source verifiers for IEC 61131-3, including ESBMC-PLC, prove safety over an abstract scan-cycle model with idealized unbounded integers. The board artifact runs on a resource-constrained microcontroller unit (MCU) with 16-bit words (8-bit AVR Arduinos), and sensors are read via a finite-resolution analog-to-digital converter (ADC). We show this deployment gap makes naive width-aware verification unsound: across 123 real programs, checking 16-bit overflow without a hardware input model yields 44% false alarms (54/123) and finds no genuine defects, because it explores sensor values no ADC can produce. Since the gap lies where computation meets the physical process - a bounded sensor reading scaled by finite-width arithmetic into an actuation command - an overflow can silently suppress a safety action, such as a high-level alarm. An unbounded input model fabricates alarms that no environment can trigger. We present hardware-faithful verification for IEC 61131-3 on open hardware: a declarative hardware abstraction layer (HAL) descriptor (width, ADC/PWM resolution, I/O binding) and a sound lowering that interprets arithmetic at target width and constrains inputs to hardware-realizable ranges. We instantiate it for Arduino as ArduinoTool, deriving HAL parameters from official cores and realizing the input-range model in the ESBMC Ladder Diagram (LD) frontend. On the 123-program corpus, the HAL annotator eliminates all 54 false alarms while preserving robustness proofs, and a controlled corpus demonstrates the rare width-dependent defects it detects with realizable witnesses.

• The paper identifies a deployment gap in existing verification tools, reporting a 44% false-alarm rate due to ignoring hardware constraints.
• It introduces a HAL-based lowering transformation that automatically infers hardware-specific parameters, ensuring sound verification results.
• Empirical evaluation on 123 programs shows that the method eliminates false positives while preserving robustness proofs on low-cost microcontrollers.

ESBMC-Arduino: Hardware-Faithful Formal Verification for Open-Hardware PLCs

Problem Statement and Motivation

This work identifies a critical unsoundness in current open-source formal verification tools for open-hardware PLCs—OpenPLC, Arduino OPTA, CONTROLLINO, Industrial Shields M-Duino—deployed in both industrial automation and ICS security research. Existing verifiers such as ESBMC-PLC and PLCverif perform safety verification on abstract models, assuming idealized, unbounded integer arithmetic and unconstrained inputs. However, actual deployment targets are low-cost MCUs (e.g., AVR boards with 16-bit integers) with quantized physical inputs via finite-resolution ADCs. This "deployment gap" results in both soundness-violating false positives (alarms on unreachable or unphysical input values) and potentially missed defects due to ignoring hardware-constrained behaviors. Empirical evaluation on a corpus of 123 real programs revealed that naive width-aware checking without input modeling produced a 44% false-alarm rate with zero true positives.

Hardware-Faithful Verification Framework

To address this gap, the paper introduces a method for hardware-faithful verification built around a declarative Hardware Abstraction Layer (HAL) descriptor. Key elements are:

• HAL Descriptor: A 4-tuple capturing (i) machine word width, (ii) ADC resolution, (iii) PWM resolution, and (iv) per-address I/O binding. Parameters are extracted directly from the PLCopen XML address space and official Arduino core sources.
• Lowering Transformation: The verification task is compiled into a model where integer arithmetic uses the correct word width, Boolean and analog input domains are constrained to their physically realizable ranges, and nonlinear function blocks are soundly over-approximated.
• ESBMC-Arduino Implementation: The method is realized as a 40-line hook in the ESBMC Ladder Diagram (LD) frontend, automatically inferring and applying per-input bounds from IEC~61131-3 addresses. The SAT/SMT backend and induction reasoning are reused without modification.

This approach mirrors target-precise model disciplines from embedded C verification (cf. Frama-C, Astrée) but with the input model derived automatically from PLC-level addresses rather than manual contracts.

Empirical Evaluation and Numerical Results

The method is evaluated on two corpora:

• 123 Real-World Programs: Applying naive 16-bit overflow checking yielded 54 false alarms (44%), all spurious overflows on unphysical input values (e.g., extreme negatives unreachable by microcontroller-bound ADCs), and no genuine width-dependent defects. Enabling the HAL-derived input model removed all 54 false alarms (54→0) and preserved all robustness proofs (32 safe/91 unknown, where unknown arises from induction incompleteness).
• Controlled Defect Corpus: Synthetic benchmarks isolate scaling, accumulation, and other width-sensitive patterns. The approach only produces UNSAFE verdicts with physically realizable counterexamples for genuinely unsafe arithmetic (e.g., $adc \times 100$ on a 16-bit board), and all correct patterns are proved SAFE across hardware targets, establishing the method's diagnostic power and specificity.

These results are replicated in CBMC and Frama-C, demonstrating cross-tool validity and establishing that absence of hardware input modeling universally causes unsound and misleading results in width-aware analysis.

Practical and Theoretical Implications

The principal implication is that formal verification which ignores either (a) word width or (b) the bounded nature of device-level inputs, fails to provide meaningful assurance for deployed PLC binaries. This is especially critical for ICS testbeds, educational environments, and production deployments relying on Arduino-class platforms. By introducing a lightweight, automatically derived HAL model at the PLC source level, engineers can obtain sound robustness certification with zero manual annotation effort. Practically, this eliminates wasted debugging effort due to phantom alarms and provides actionable feedback when real hardware-induced defects are present (e.g., silent alarm suppression at high ADC values due to integer overflow).

Theoretically, this work delineates the limitations of abstract PLC model verification for deployment-level correctness and formally characterizes the class of width-dependent defects and false positives that can occur without device-model fidelity. The architecture enables generic transfer to other microcontroller families (e.g., ESP32, ARM-based), and the method can be cleanly composed atop mature backends and existing static analysis tools.

Limitations and Directions for Future Work

Classification is currently scoped to the integer/Boolean fragment of IEC~61131-3. The method over-approximates nonlinear function blocks and does not yet address hardware-in-the-loop validation or fine-grained per-address ADC width/peripheral distinctions beyond the current board-level HAL. The robustness proof count is bounded by k-induction's inability to always discharge invariants in function-block-heavy designs (91/123 unknown in the real corpus).

Future technical directions include invariant generation for induction completeness, precise modeling of quantization artifacts and pin bindings, introducing fixed-point abstraction for nonlinear/continuous controllers, and tighter integration of per-address peripherals. Hardware-level validation and testbed deployment are key for closing the remaining assurance gap.

Conclusion

The ESBMC-Arduino framework provides—via soundness-preserving, hardware-faithful lowering, and automatic per-input range inference—a practical and effective solution for formal PLC verification on open-hardware platforms. It eliminates the deployment gap that renders current approaches unsound for physical assurance. Robustness proofs become actionable, defects are detectable only when realizable on the target device, and verification effort is not wasted—ensuring trustworthy deployment in critical automation and security research environments (2607.08550).