Testing & Validation · Study deck

OTA Update Architecture for IoT

A roadside controller downloads a new image, then loses power before its first successful boot.

Test Tessa is your guide for this deck.

ota-updatesfirmware-validationrelease-gates

Test Tessa, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

treat an OTA update as a controlled release, not a file copy
build release-side and device-side update evidence
use atomic slots and the three install states to support real recovery
Explain: On restart, it must not run a half-written image or report the new version before that image is accepted.

Major section

Start With the Device You Cannot Touch

On restart, it must not run a half-written image or report the new version before that image is accepted.

An over-the-air update is a software change delivered through a network instead of a local cable.
OTA is its short name.
Firmware is the stored device code and its version.

Major section

Overview: An Update Is a Controlled Release, Not a File Copy

The device must then prove readiness, verify the received bytes, boot the inactive image, and report health before the old image can be released.

If that check fails, the last panel sends the device back to the saved image.

OTA update gate path from change record, signed artifact, manifest, and rollout cohort to device readiness, transfer verification, boot confirmation, and recovery record. — The OTA gate path separates release-side identity and authorization from device readiness, verification, boot confirmation, and recovery.

Major section

Practitioner: Release-Side and Device-Side Evidence

A full download is not yet an approved image.

This record carries release control onto the device instead of ending it when the bytes arrive.

An OTA review record preserves artifact identity, manifest constraints, readiness, verification, boot confirmation, recovery evidence, and the retest trigger.

Major section

Under the Hood: Three States, Atomic Slots, and Real Recovery

End at the retest trigger, which prevents the same unsafe candidate from cycling indefinitely.

This closes the dual-slot story with evidence that rollback is executable, not merely promised.

Major section

Rollback and Staged Rollouts

Firmware is stored device software.

This sequence connects the banquet analogy to the engineering purpose of staged rollout: a measurable blast radius and a tested way back.
The sequence connects a predefined health condition to an executable rollback rather than an improvised reaction.
That path is not always available.

The staged-rollout gate path sends a candidate to a bounded cohort, checks readiness and observed health, then continues, pauses, rolls back, or waits for retest evidence.

Major section

Rollback and Staged Rollouts (continued)

The chapter's running rule is therefore to bound the blast radius and prove the available way back before exposing the fleet.

A canary or staged ring sends the candidate to a small device cohort and expands only through evidence gates, while blue-green switching serves gateways or backends that can maintain two swappable environments.
Those conditions turn each expansion into a repeatable decision and make missing check-ins a warning rather than allowing a silent, possibly bricked device to count as healthy.
Rollout and rollback strategy should define cohorts, gates, stop conditions, compatibility checks, and recovery evidence before production release.

A rollback record ties release-side identity to device-side evidence: v3.2.7 build 8142, the 0.1 percent canary of 10 devices, the failed healthy-boot gate, missing check-ins, rollback to the v3.2.6 A/B slot, owner, and the fixed v3.2.8 retest trigger.

Major section

Prove the Trial Slot before Expanding the Cohort

A 480 KiB candidate leaves 32 KiB within its slot for any slot-resident overhead.

The update must check the actual signed image layout rather than comparing only the uncompressed application binary with nominal flash capacity.
The architecture should recover according to its documented state machine without selecting partially written code.

Major section

Prove the Trial Slot before Expanding the Cohort (continued)

Download complete means the bytes arrived; verification checks their integrity and authorization; confirmation establishes that the new running image met the defined health conditions.

The boot architecture needs power-loss evidence to establish its flash-write and metadata guarantees.
The exposed fraction is 10 divided by 10,000 = 0.001, or 0.1%.
If two fail the healthy-boot check, that is 20% of the trial cohort.

Major section

Summary

On the release side, the change record, immutable artifact identity, hash, signature, and manifest establish what may be installed; the manifest also fixes the target, version intent, slot or install mode, recovery expectation, and reporting fields.

On the device side, readiness, transfer, verification, boot confirmation, and recovery remain separate states.
In particular, downloaded is not installed, and installed is not confirmed: success requires a defined healthy-boot checkpoint rather than the mere arrival of bytes.
A dual-slot layout leaves the running image untouched during the write and retains the previous image for recovery.

Deck summary

Key takeaways

On restart, it must not run a half-written image or report the new version before that image is accepted.

The device must then prove readiness, verify the received bytes, boot the inactive image, and report health before the old image can be released.
A full download is not yet an approved image.
End at the retest trigger, which prevents the same unsafe candidate from cycling indefinitely.
Firmware is stored device software.

Retrieval practice

Recall check 1 of 6

Test Tessa says: answer from memory, then check your reasoning.

Q1Why is an over-the-air (OTA) update best treated as a controlled release rather than a simple file transfer?

ABecause firmware is large, so compression is the main safety control

BBecause phased downloads spread bandwidth use across the device fleet

CBecause bytes arriving on flash mean the update is complete and trusted

DBecause it must authorize, verify, confirm boot, and retain recovery

Show answer

Answer: D The transfer is the easy part.

Retrieval practice

Recall check 2 of 6

Test Tessa says: answer from memory, then check your reasoning.

Q2A device downloaded an OTA artifact, but the manifest's target does not match the device's hardware and version profile. What should the review record show first?

AA reject or defer at the manifest/readiness gate, with a target-mismatch reason

BThe device installed the artifact because the transfer had completed

CThe same artifact was retried until the device accepted the manifest

DThe device reported only a generic failure status for the release dashboard

Show answer

Answer: A A target mismatch belongs in the manifest or readiness evidence, with a reason that distinguishes it from a transfer or device fault.

Retrieval practice

Recall check 3 of 6

Test Tessa says: answer from memory, then check your reasoning.

Q3After an OTA install, a device reports 'installed' but then keeps restarting before the application ever runs. Which design lets the fleet recover automatically?

AMarking the update successful as soon as the bytes are written, because a completed transfer proves the image is good

BOverwriting the previous image during install to save storage, then re-downloading if the device fails

CA boot-confirmation handshake with a dual-slot

DIncreasing the download retry count so the device eventually boots

Show answer

Answer: C Confirmation distinguishes 'installed' from 'running healthy,' and the retained slot makes the failure survivable.

Retrieval practice

Recall check 4 of 6

Test Tessa says: answer from memory, then check your reasoning.

Q4Why are staged rollouts and a defined rollback path especially important for IoT firmware compared with a typical web service deploy?

AFirmware updates never fail, so staging and rollback are only paperwork

BDevices are hard to reach physically

CWeb deploys are riskier than firmware, so IoT needs less caution

DStaging exists only to make releases slower for compliance reasons

Show answer

Answer: B The cost of a fleet-wide bad update is high and hard to undo by hand, so bounding exposure and planning recovery in advance are essential.

Retrieval practice

Recall check 5 of 6

Test Tessa says: answer from memory, then check your reasoning.

Q5A canary cohort reports successful transfer and signature verification of the new firmware, but several devices never report a confirmed healthy boot. What is the strongest rollout decision?

AContinue to the next wave, since the artifact was downloaded and its signature verified

BImmediately roll back every device in every cohort across the whole fleet

CDelete the boot-confirmation gate so the rollout can be marked complete

DPause the rollout and review the affected devices for recovery or rollback

Show answer

Answer: D A downloaded, verified image that never confirms a healthy boot is exactly the condition a boot-confirmation gate exists to catch; expanding would risk bricking more devices.

Retrieval practice

Recall check 6 of 6

Test Tessa says: answer from memory, then check your reasoning.

Q6A firmware update rewrites each device's stored configuration into a new on-flash format. Field reports come in, and the team triggers a rollback to the previous version, but the reverted devices now fail to start. What most likely happened, and what should have been planned?

AThe network download failed; the team should retry the same downgrade after congestion clears

BThe migration was forward-incompatible; recovery needed a compatible data path or roll-forward fix

CAnti-rollback blocked the old image; the team should bypass version checks in production

DThe rollback succeeded; boot confirmation can be skipped once the version number changes

Show answer

Answer: B State migrations can make rollback effectively impossible; the safe options are backward-compatible migrations or recovering by rolling forward, decided before the release ships.

Print reference

Answers 1 of 2

Answer key.

D · The transfer is the easy part.
A · A target mismatch belongs in the manifest or readiness evidence, with a reason that distinguishes it from a transfer or device fault.
C · Confirmation distinguishes 'installed' from 'running healthy,' and the retained slot makes the failure survivable.
B · The cost of a fleet-wide bad update is high and hard to undo by hand, so bounding exposure and planning recovery in advance are essential.

Print reference

Answers 2 of 2

Answer key.

D · A downloaded, verified image that never confirms a healthy boot is exactly the condition a boot-confirmation gate exists to catch; expanding would risk bricking more devices.
B · State migrations can make rollback effectively impossible; the safe options are backward-compatible migrations or recovering by rolling forward, decided before the release ships.