Design Methodology · Study deck

Virtual Hardware: Evidence Transfer

Saying code ran in a named tool is not test evidence.

Blueprint Bina is your guide for this deck.

simulatinghardwareprogramming
Blueprint Bina, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Explain: 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.
  • Explain: 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.
  • Explain: A first virtual run might use an ESP32 or Arduino Uno in Wokwi with a DHT22 or DS18B20-style temperature input, one LED, and serial logging.
  • Explain: Simulation Can Usually Support.
iotclass.org

Major section

Define the Model Boundary

Simulation quality depends on the model boundary.

  • The model boundary describes what the simulator represents and what it leaves out.
  • Simulation Can Usually Support.
  • Expected order of transactions, device address use, command framing, and basic response handling.
  • Display text, LED behavior, button state transitions, alarm states, and serial command flow.
iotclass.org

Major section

Simulation Pass Is Not Release

Simulation can clear a development gate.

  • 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.
  • 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.
A simulator can exercise firmware behavior, but physical claims still need bench evidence.
A simulator can exercise firmware behavior, but physical claims still need bench evidence.

Try it: Simulation Pass Is Not Release in the chapter

iotclass.org

Major section

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.
  • This virtual path makes firmware behavior reviewable; ADC accuracy, radio behavior, power, and dashboard integration still need separate bench checks.
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.
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.
iotclass.org

Major section

Interpret Simulation Evidence Carefully

Simulation evidence is strongest when the claim is phrased narrowly.

  • "The hardware works.".
  • "The firmware enters the fault state when the virtual I2C sensor is missing.".
  • "Timing is validated.".
  • "The simulated waveform shows the intended transaction order; real rise time and timing margin still need bench capture.".

Try it: Interpret Simulation Evidence Carefully in the chapter

iotclass.org

Major section

Transfer From Simulation to Hardware

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.

  • Bench setup: Prepare power limits, serial logging, logic analyzer channels, sensor inputs, and safe actuator handling.

Why it matters

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

A simulation pass should feed a controlled hardware-transfer gate, not replace it.
A simulation pass should feed a controlled hardware-transfer gate, not replace it.

Try it: Transfer From Simulation to Hardware in the chapter

iotclass.org

Major section

Incremental Examples

A first virtual run might use an ESP32 or Arduino Uno in Wokwi with a DHT22 or DS18B20-style temperature input, one LED, and serial logging.

  • The simulation claim is narrow: the firmware enters normal, warning, alarm, and sensor-missing states and prints the expected diagnostic message.
  • A Raspberry Pi Pico or RP2040 firmware build may use an I2C BME280 or SHT31 sensor model, an OLED display, and a button.
  • The virtual circuit can test the pin map, state transitions, wrong I2C address handling, missing-device timeout, display text, and repeated button input.
iotclass.org

Major section

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.
  • Virtual circuit uses the same named GPIO pins as the schematic draft and records the bus address.
  • Serial log shows the node starts safely with sensor present, sensor absent, and invalid reading.
  • Simulated disconnect produces retry limit, fault indicator, and no unsafe output.
iotclass.org

Deck summary

Key takeaways

Simulation quality depends on the model boundary.

  • Simulation can clear a development gate.
  • A virtual circuit should be treated like source code.
  • Simulation evidence is strongest when the claim is phrased narrowly.
  • 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.
iotclass.org

Retrieval practice

Recall check 1 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q1Place each virtual-hardware artifact where it lives so you can use simulation to improve firmware without claiming unmeasured timing, power, or analogue behavior.

ADesign Claim
BModel Scope
CVirtual Build
DTest Stimuli
EObserved Evidence
FHardware Transfer
Show answer

Answer: A Place each virtual-hardware artifact where it lives so you can use simulation to improve firmware without claiming unmeasured timing, power, or analogue behavior.

iotclass.org

Retrieval practice

Recall check 2 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q2A virtual board simulation shows that firmware enters a fault state when a sensor is missing. Which conclusion is strongest?

ASimulator exercised the firmware fault branch; bus timing, wiring, and recovery still need bench validation.
BProduction hardware is validated because the simulator covered the missing-sensor branch.
CDatasheet review can be skipped because the virtual sensor returned the expected fault.
DBench testing can skip missing-sensor recovery and focus only on nominal readings.
Show answer

Answer: A Simulation evidence should be phrased by claim.

iotclass.org

Retrieval practice

Recall check 3 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q3A simulated waveform shows the intended order of SPI transactions. What must still be checked on physical hardware before release?

ASignal integrity, voltage levels, timing margin, chip-select behavior, and actual peripheral behavior.
BNothing else, because a waveform view is the same as a logic analyzer capture.
COnly virtual jumper color and pin labels, because transaction order already passed.
DOnly whether the simulator is shareable, because peer replay replaces board measurement.
Show answer

Answer: A Simulation can show intended sequence and firmware behavior.

iotclass.org

Print reference

Answers

Answer key.

  1. A · Place each virtual-hardware artifact where it lives so you can use simulation to improve firmware without claiming unmeasured timing, power, or analogue behavior.
  2. A · Simulation evidence should be phrased by claim.
  3. A · Simulation can show intended sequence and firmware behavior.
iotclass.org