- The paper proposes AERO, Runtime-Aware OTA Updates, an method to handling over-the-air (OTA) firmware updates for energy-harvesting IoT devices. This PCR method introduces a novel approach to avoid incomplete or failed updates by protecting partially-applied updates.
- AERO achieves a zero update error rate across all evaluated scenarios, demonstrating superior reliability, 12.4× less completion time and lower deadline miss rate compared to baseline methods, while exposing trade-offs with runtime-safety mechanisms.
- The study assumes tasks encapsulate local state and access shared resources only at boundaries it proposes task-boundary state encapsulation for OTA updating and proposes changes at dependency levels.
- AERO includes a dependency-driven algorithm into actual task graphs, prioritizes just street dependencies in preprocess prior and takes final changes at processing entities inside these task groups.
Problem and motivation
Energy-harvesting (EH) IoT devices operate under intermittent power, which fragments execution into unpredictable windows and makes over-the-air (OTA) firmware updates — an energy-intensive operation — difficult to complete reliably. Conventional OTA mechanisms reboot into a bootloader to apply updates; on memory-constrained devices, updates must be processed in chunks, causing multiple reboots whose cumulative energy and latency costs prolong downtime and increase the risk of incomplete or failed updates. Live update techniques avoid reboots by patching code at runtime, but they introduce a correctness hazard the paper identifies as mixed-version execution: updated and non-updated code regions temporarily coexist, and residual volatile state can become inconsistent with new logic. The paper categorizes the possible outcomes as no impact, incorrect computation, execution failure, or unintended interaction, and notes that these risks are amplified in EH devices where tasks are decomposed finely enough that a task may span only a few instructions. Prior intermittent live-update work acknowledges this issue but does not resolve it.
A second motivation is structural: some updates modify not only task code but also the DAG itself — adding tasks, removing obsolete ones, or changing dependencies. No existing OTA approach for EH IoT supports such DAG-level updates.
Design overview
AERO treats update operations as schedulable entities integrated directly into the device's execution DAG, alongside routine tasks, under both energy and deadline constraints. Its design rests on four components:
- Dependency-driven update packet format: each packet carries a group field (present only in the first packet) encoding the mutually dependent update group with one bit per routine task, plus an update operation with a 2-bit operation code, a 1-bit DAG flag indicating whether dependency information follows, a task ID, and the code segment. This supports incremental processing when device memory cannot hold the entire update.
- Mutually dependent update groups and update-affected blocks: a mutually dependent update group is the minimal subset of update tasks that must be applied together for correctness; the update-affected block is the minimal subgraph containing those tasks plus all intermediate nodes and edges on their dependency paths.
- Runtime DAG adjustment algorithm: upon receiving an update notification, AERO inserts a virtual start node connected to all sources, identifies the affected block, removes all incoming edges to it, and inserts update tasks either before their associated routine tasks (if runtime is outside the block) or after them (if runtime is inside, deferring so the current cycle completes under the old version). Blocking entry into the block is essential when packets arrive incrementally: without it, routine tasks inside the block could execute under outdated code. Checkpointing in non-volatile memory allows partially applied updates to be recovered after power loss.
- Unified scheduling algorithm: a priority queue ordered by deadline then priority selects among ready tasks; routine tasks execute directly, while update tasks first add any declared dependency edges before applying their operation. Once all update tasks in the group complete, blocked edges are restored and update artifacts are cleaned from the graph.
The correctness model assumes tasks encapsulate local state and access shared memory, peripherals, and interrupts only at task boundaries — a nontrivial assumption for legacy firmware, discussed further below.
Evaluation methodology
Experiments target the TI MSP430FR5994 microcontroller with embedded FRAM, profiling execution time and energy via TI EnergyTrace in Code Composer Studio. Four benchmarks cover distinct DAG topologies: Quick Sort (linear, 1,696 B), AES encryption with hardware/software paths (parallel, 3,975 B), LeNet-5 inference (linear, 50,632 B), and a PPG-based heart rate monitor (fork-join, 46,050 B). Six update scenarios range from 130 B parametric changes (AES key size) to a 6,246 B heart-rate model update delivered over UART. Capacitor sizes are set so stored energy just covers the most expensive task, driving operation near the system's energy limits. Simulation uses real-world solar traces from an EH IoT deployment, with pseudo-random update arrivals. Two baselines are compared: trampoline-based live update and a checkpoint-assisted intermittent OTA framework. The evaluation assumes sufficient non-volatile storage and that all update packets arrive before integration, deliberately excluding communication cost to isolate runtime behavior.
Results
Update error rate is the strongest result: AERO maintains a zero error rate across all six scenarios. The live baseline reaches error rates as high as 98.3% in Scenario 6, where updates overlap computation-intensive tasks, and even fails frequently on lightweight Scenario 1 because uniformly short tasks increase the chance of interrupting active code. The intermittent baseline also achieves zero errors, but only by postponing updates until all routine tasks finish, producing long delays that may be unacceptable for time-sensitive patches such as security fixes.
Update completion time: AERO outperforms the intermittent baseline in Scenarios 1–5 and slightly beats it even in Scenario 6 despite its largest update size. Against live update, completion times are comparable in Scenarios 1–3 and 5; small delays occur only when the update-affected block is executing, since deferral is the price of correctness. In Scenarios 4 and 6, live update finishes faster but at very high error rates — the paper's clearest illustration of the speed-versus-correctness trade-off.
Deadline miss rate (DMR): deadlines apply only to routine tasks (profiled execution time plus a 0.5× margin). AERO matches or slightly exceeds the intermittent baseline's DMR, and in Scenario 6 achieves a lower DMR than live update, which applies changes immediately regardless of execution state and thereby delays routine tasks. The authors report that runtime DAG adjustment overhead — primarily non-volatile memory writes — is negligible for the evaluated scenarios.
Limitations and open questions
Several constraints bound the results. First, evaluation is simulation-based: task timings and energies come from standalone profiling rather than end-to-end execution under AERO, and communication cost is excluded by assuming all packets arrive before integration. Real-world multi-packet delivery over lossy links remains unmeasured. Second, the consistency guarantee depends on the task-boundary abstraction — tasks must encapsulate local state and confine shared-resource access to boundaries — which may require restructuring existing firmware. Third, deadlines use a fixed 0.5× margin heuristic, and update tasks carry no deadlines at all, leaving open how AERO behaves under hard real-time constraints on updates themselves. Fourth, the paper evaluates single-device operation; coordinated OTA updates across EH IoT networks remain unexplored. Finally, the claim that DAG-adjustment overhead is negligible is supported only for the six evaluated scenarios and would need validation for larger graphs or more frequent updates.
Conclusion
AERO addresses a specific gap in OTA support for intermittently powered devices: ensuring update consistency during runtime execution while supporting DAG-level structural changes. By encoding mutually dependent update groups in a lightweight packet format, identifying update-affected blocks, and scheduling update tasks within the executing DAG under energy and deadline constraints, it achieves zero update errors across all evaluated scenarios with competitive completion times and deadline miss rates relative to live and intermittent baselines. The main caveats — simulation-based evaluation, the task-boundary state encapsulation assumption, and exclusion of network effects — define the scope within which these results hold.