29 Virtual Hardware: Evidence Transfer

29.1 Start With the Decision

Saying code ran in a named tool is not test evidence. The record needs the model, input, output, and open physical checks.

29.2 Route Overview

This is part 2 of 2. Review Virtual Hardware: Test Harnesses for the preceding evidence.

29.3 Learning Objectives

• Separate virtual claims from required bench claims.
• Transfer firmware evidence from simulation to hardware.

29.4 Chapter Roadmap

• Tool Names Are Not Evidence
• Define the Model Boundary
• Simulation Pass Is Not Release
• Build a Repeatable Virtual Circuit
• Exercise Firmware Behavior
• Fault Injection Belongs Early
• Interpret Simulation Evidence Carefully
• Transfer From Simulation to Hardware
• Incremental Examples
• Virtual Sensor Node Review
• Try It Now
• Separate Virtual/Physical Claims
• Practice Checks
• Match Simulation Artifact to Claim
• Order Hardware Simulation Flow
• Label Simulation Evidence Loop
• Concept Check: Simulation Scope
• Concept Check: Physical Signal Claims
• Common Pitfalls
• 1. Virtual Peripherals Are Not Exact
• 2. Pullups, Voltage, Variants
• 3. Simulating Only the Happy Path
• 4. Overclaiming Timing and Power
• 5. Losing the Simulation Handoff
• Summary
• References
• See Also
• What’s Next
• Key Takeaway

29.5 Define the Model Boundary

Simulation quality depends on the model boundary. The model boundary describes what the simulator represents and what it leaves out.

Inspect Figure 29.1 before promoting a simulation pass to release evidence. The left Physical Hardware column names ESP32 boards, sensors, and wires, while the right Simulation column uses virtual components and a simulated microcontroller; those are different evidence surfaces even when the same firmware logic runs.

Across Figure 29.1, compare TIMING first: physical execution includes real device and bus delays, while simulated timing is approximate. DEBUGGING contrasts logic analysers and oscilloscopes with software breakpoints and watches; COST contrasts a physical bill of materials with a zero-cost virtual run; and SETUP SPEED explains why simulation is excellent for rapid logic checks. Those advantages do not establish supply stability, sensor accuracy, pull-up sizing, interrupt jitter, radio coexistence, current peaks, thermal behavior, enclosure effects, or component variation. Use simulation to prove state transitions, message parsing, boundary values, timeouts, and reproducible fault cases. Repeat the identical scenario on hardware and align simulator events with GPIO, bus, serial, network, and power timestamps; any unexplained difference becomes a model limitation or a product defect, not noise to discard. Exercise brownout, disconnected or stuck sensors, delayed acknowledgements, reset during state persistence, full queues, clock drift, and update rollback at the boundary where each physical effect matters. Then bind each physical claim to a bench artifact: schematic and part revision, firmware hash, power trace, bus capture, latency measurement, RF or environmental result, production-fixture check, and recovery observation. Record which simulator assumption was exercised, which physical effect it omits, the hardware owner, acceptance limit, observed result, and the change that forces a rerun. A release can cite both surfaces, but it cannot substitute the instant virtual setup for the measurements required by the actual product risk.

29.6 Build a Repeatable Virtual Circuit

A virtual circuit should be treated like source code. It should be reviewable, versioned, and tied to a design assumption.

Use the figure Figure 29.2 to test Build a Repeatable Virtual Circuit against the depicted system. Sensor and ESP32 expose the two named boundaries behind A Wokwi-style virtual circuit can make the firmware path reviewable, but the captioned model still needs separate bench checks for ADC accuracy, Wi-Fi behavior, power, and dashboard integration.

Follow Figure 29.2 from the sensor ADC pin through ESP32 processing and WiFi transmission to dashboard visualization. This virtual path makes firmware behavior reviewable; ADC accuracy, radio behavior, power, and dashboard integration still need separate bench checks.

For small projects, a compact checklist is enough:

Simulation handoff:
- design claim: alarm state machine handles normal, warning, and fault states
- firmware: commit id and board target
- virtual hardware: board type, sensor model, display model, pin map
- stimuli: normal sample, high sample, sensor disconnect, reset during alarm
- expected evidence: serial log, LED state, display text, fault counter
- not proven: real sensor accuracy, interrupt latency, current draw, enclosure behavior
- hardware transfer: repeat pin, power, timing, and sensor checks on the bench

29.7 Exercise Firmware Behavior

Simulation is valuable because it makes difficult test conditions cheap to repeat. Use it to cover firmware paths that are easy to skip on the bench.

29.8 Interpret Simulation Evidence Carefully

Simulation evidence is strongest when the claim is phrased narrowly.

29.9 Transfer From Simulation to Hardware

Pause at the figure Figure 29.3 before applying Transfer From Simulation to Hardware. Its Simulation Packet and claim, model, logs labels show why A simulation pass should feed a controlled hardware-transfer gate, not replace it needs an evidence check for Transfer From Simulation to Hardware here.

View Figure 29.3 as a hand-off: Simulation Packet first uses Simulation Packet to show the next hand-off, claim, model, logs then uses claim, model, logs to test technical feasibility, and Schematic Check finally highlights Schematic Check. For Transfer From Simulation to Hardware, these labelled responsibilities give A simulation pass should feed a controlled hardware-transfer gate, not replace it its place in the running narrative.

The transfer gate prevents a clean virtual run from becoming a false release decision.

29.10 Incremental Examples

29.11 Virtual Sensor Node Review

A team is building a small sensor node that reads a digital sensor, displays a status indicator, and sends an event to a gateway. The physical board is not ready, but firmware work can start.

This is enough to keep firmware moving while hardware is delayed. It is not enough to ship the product.

29.12 Try It Now

Rewrite this weak simulation result into a scoped evidence statement:

“The Wokwi project works, so the hardware design is ready.”

A stronger answer should name the firmware behavior, board or simulator model, virtual peripherals, test stimuli, observed logs or waveforms, model limits, and the physical bench checks that still have to pass.

29.13 Separate Virtual/Physical Claims

For each claim, decide whether simulation can support it, hardware must measure it, or both are needed:

1. The firmware enters a fault state when the virtual sensor is missing.
2. The I2C bus has enough timing margin with the selected pullup resistors.
3. The sleep path disables the display before the node enters low-power mode.

For each answer, name the artifact: virtual project, serial log, simulated waveform, logic-analyzer trace, oscilloscope capture, current profile, or bench note.

29.14 Practice Checks

29.15 Common Pitfalls

29.16 Summary

Simulating hardware programming helps teams develop embedded firmware before every physical detail is ready. It is strongest when the simulation has a named design claim, a documented model boundary, a versioned virtual circuit, intentional test stimuli, captured evidence, and a hardware-transfer plan. Use simulation to move faster and improve coverage. Use physical hardware to prove the electrical, timing, analog, RF, power, environmental, and manufacturing claims that simulation cannot prove.

29.17 References

First: Wokwi Documentation - official browser-based hardware simulation documentation.

Next: Wokwi Diagram Format - official reference for virtual circuit project files.

Then: Autodesk Tinkercad Circuits - official learning resources for Tinkercad circuit simulation.

After that: Renode Documentation - official embedded-system emulation documentation.

Also inspect: QEMU System Emulation Documentation - official QEMU system-emulation documentation.

Finally: Arduino CLI Documentation - official command-line build and upload documentation for Arduino workflows.

29.18 See Also

First: Specification Sheet Fundamentals: convert datasheet limits into model boundaries and bench checks.

Next: End-to-End Test Strategy: decide when a simulator pass is enough for development and when physical evidence is required.

Then: Simulating Testing and Validation: connect virtual runs to validation workflows.

After that: Hardware Prototyping: move from virtual wiring to breadboard, bench, and prototype hardware checks.

29.19 What’s Next

29.20 Key Takeaway

Hardware simulation is useful when it tests wiring, timing, sensor behavior, and firmware logic before physical parts are available. It should reduce risk, not replace bench testing.

29.21 Continue Your Route

This final part closes the route from Tool Names Are Not Evidence through Key Takeaway. Return to Virtual Hardware: Test Harnesses or continue from the design-methodology module index.