Intermittent Computing
1. Overview
A. Definition
An ultra-low-power computing paradigm in which a device runs solely on ambient energy harvesting without a battery, and preserves and restores its computational state so that work continues without interruption even when power is supplied and cut off erratically.
A conventional von Neumann computer loses the contents of its volatile storage — registers, SRAM, DRAM — the moment power is cut, so it must restart from boot. This model rests on the implicit premise that "power is always supplied stably." Intermittent computing inverts that premise: it treats power being cut and restored on the order of milliseconds to seconds as the normal state, saving the progress of computation up to the instant before a power failure into non-volatile storage, and resuming from that point when power returns. In other words, it is a computing paradigm that treats a power failure not as an exceptional condition but as a recurring, everyday event.
The significance of this shift goes beyond a mere power-saving technique. Whereas traditional low-power design takes a "keep power on but reduce consumption" approach such as sleep modes or DVFS (dynamic voltage and frequency scaling), intermittent computing takes a "eliminate or minimize the energy store (battery) and survive on harvested power alone" approach. Consequently the hardware (non-volatile memory, ultra-low-power MCU), the software (checkpointing and recovery runtime), and the programming model (idempotency and transactions) must be redesigned as a single body.
B. Background and Necessity
As billions to trillions of tiny IoT sensors are forecast to spread, the limits of battery replacement, disposal, and lifetime have become a real obstacle. A sensor embedded in structural concrete, implanted or attached to the human body, or placed inside industrial equipment that is hard to reach may make swapping a battery physically impossible or economically unjustifiable. Even for a sensor costing a few cents, replacing tens of thousands of them every few years makes the total cost of ownership (TCO) unbearable. Discarded lithium batteries also carry environmental burden and safety (ignition) concerns.
As an alternative, harvesting ambient energy — solar, RF, vibration, thermoelectric (temperature difference) — allows near-perpetual operation without a battery. However, energy harvested this way has three intrinsic characteristics: it is intermittent, irregular, and feeble. Indoor light harvesting yields only microwatts (µW), RF harvesting changes sharply with distance from the source, and vibration harvesting stops the instant the vibration source stops. When power failures repeat on a millisecond scale atop such a power source, an ordinary execution model can never complete a computation. Hence a state preservation and recovery technique that guarantees a computation reaches completion despite frequent power failures is required, and this is the very reason intermittent computing exists.
2. Overall Operating Structure
An intermittent computing system operates as three interlocking layers: the energy subsystem (harvesting, storage, power management), the compute subsystem (MCU, volatile memory), and the state preservation subsystem (non-volatile memory, recovery runtime). An overview of the whole structure is as follows.
flowchart TB
subgraph ENERGY["Energy subsystem"]
HV["Energy harvester (solar/RF/vibration/thermoelectric)"] --> PM["Power management (PMU)"]
PM --> CAP[("Capacitor storage")]
end
subgraph COMPUTE["Compute subsystem"]
MCU["Ultra-low-power MCU"] --- VM["Volatile memory (registers/SRAM)"]
end
subgraph PERSIST["State preservation subsystem"]
NVM["Non-volatile memory (FRAM/MRAM)"]
RT["Recovery runtime/compiler support"]
end
CAP -->|"Power supplied when threshold voltage reached"| MCU
MCU -->|"Write checkpoint"| NVM
NVM -->|"Restore state when power recovers"| RT
RT --> MCU
The key is that the capacitor must reach a certain threshold voltage (e.g., 3.0V) before power is applied to the MCU, and the computational state must be safely recorded into non-volatile memory (NVM) before the voltage falls below a lower bound (e.g., 1.8V). That is, the system runs atop a sawtooth power profile in which "waiting-to-charge" intervals and "executing" intervals alternate. The power management unit (PMU) monitors the voltage to judge when execution is possible, and raises an interrupt to trigger an emergency checkpoint when it nears the falling threshold.
3. Execution/Recovery Process and Core Technical Elements
If the overall structure above shows "what exists," the process below shows "how it flows." Within one power cycle, harvest → accumulate → execute → save → (power failure) → recover cycles around.
sequenceDiagram
participant H as Harvester
participant C as Capacitor
participant M as MCU
participant N as NVM
H->>C: Accumulate feeble energy
C->>M: Threshold reached, power ON
M->>M: Execute (part of a task)
M->>N: Save checkpoint (registers/variables)
Note over C,M: Voltage falls, power failure
H->>C: Recharge
C->>M: Power recovers, reboot
M->>N: Look up last checkpoint
N->>M: Restore state and resume
A. Energy Harvesting and Power-Aware Execution
The gist of operation is the harvest → accumulate → execute → save → recover cycle, and the first thing to handle is how to deal with "energy whose amount is unknown." Because harvested energy is hard to predict, the system uses the capacitor voltage as an "energy fuel gauge" to decide whether to execute. When the voltage is high it runs a longer task; when it is low it immediately leaves a checkpoint and waits.
Power-aware scheduling extends this judgment to the task level. For example, when available energy is plentiful it performs compute-heavy filtering or inference, and when it is scarce it adjusts priorities to perform only light work such as sensor sampling. This reduces the waste of an expensive computation collapsing partway through due to a power failure.
The crux is sizing the capacitor. If the capacity is too small it cannot do meaningful work in one go; if too large, charging takes a long time and responsiveness drops. In practice, the "minimum capacity that can complete the largest atomic unit of work" is determined experimentally.
B. Non-Volatile Memory (NVM) and Checkpointing
To preserve state even when power is cut, the storage medium itself must be non-volatile. FRAM (ferroelectric RAM) and MRAM (magnetoresistive RAM), unlike flash, allow byte-granular writes and have very small write energy and latency, making them the de facto standard for intermittent computing. For instance, TI's MSP430FR-series MCUs embed FRAM and handle checkpoint writes at the scale of a few nanoseconds to a few microseconds. Flash, with its block-granular erase and high write energy, is unsuited to frequent checkpointing.
Checkpointing is the technique of copying the intermediate computational state (program counter, registers, stack, global variables) into NVM. The crux is "when and how often to save." Saving frequently means little loss on a power failure but slows progress through save overhead; saving rarely means much work must be re-executed on each failure. Methods to optimize this trade-off include (1) static checkpointing that saves at fixed points in the code, (2) adaptive (voltage-based) checkpointing that saves only when the voltage nears the lower bound, and (3) differential checkpointing that saves only the changed variables.
Another approach forgoes explicit checkpoints entirely and instead splits the program into task units so that each task either completes atomically or is re-executed wholesale (e.g., research runtimes such as Alpaca and Chain). In this case the developer need not worry about power-failure points and only declares task boundaries, raising productivity.
C. Idempotency and Consistency Guarantees
Each element shares one goal atop the premise of power failure: "how to safely keep and restore state."
| Element | Description |
|---|---|
| Energy harvesting | Collect and store ambient energy such as solar, RF, heat, vibration |
| Non-volatile memory (NVM) | Preserve state even on power cut with FRAM, MRAM, etc. |
| Checkpointing | Periodically/adaptively save intermediate computational state to NVM |
| Idempotency | Ensure results do not change even when re-executed |
| Power-aware scheduling | Split and execute work to match available energy |
There is a reason idempotency matters especially. When a power failure occurs after a checkpoint, the code re-executes from that point; if there was an operation in between that changes external state (e.g., incrementing a sensor counter, wireless transmission, updating an NVM variable), then re-execution triggers the same side effect twice and corrupts data. A representative example is code like count = count + 1 that reads and updates an NVM variable. If a power failure occurs mid-update so that it is only partially applied and then re-executes, the value may be added twice or left in an in-between state. To prevent such a WAR (Write-After-Read) hazard, the update must be wrapped in an atomic transaction, or double buffering must preserve the pre-update value so that on re-execution it is recomputed from the original.
Another axis of consistency is "the atomicity of the checkpoint itself." If a power failure occurs while a checkpoint is being written, a corrupted half-written checkpoint may remain. To prevent this, double buffering (alternating between two checkpoint slots and setting a valid flag only on the completed one) guarantees that an intact last checkpoint always exists.
4. Key Issues and Forward Progress
| Issue | Content |
|---|---|
| Forward progress | Balance of checkpoint overhead vs. re-execution loss |
| Consistency | Prevent memory inconsistency at the moment of failure (non-atomic updates) |
| Performance | Processing delay from frequent save/restore |
| Debugging | Non-deterministic failures make errors hard to reproduce and verify |
The most fundamental issue is forward progress. If the distance between two checkpoints is longer than the interval executable on the energy held in the capacitor, a power failure occurs before that interval completes every time, and the system can fall into a non-termination state that never moves forward. This is also called "Sisyphean execution," likening it to Sisyphus pushing a boulder to just below the summit only for it to roll back down repeatedly. Hence splitting work into sizes that can be reliably completed on the available energy is the crux of design, and some runtimes observe the re-execution count to dynamically split tasks even finer.
Debugging is also important in practice. Because the point at which a power failure occurs is non-deterministic, a bug that reproduces only at a specific failure timing (e.g., the earlier WAR hazard) is very hard to catch with an ordinary debugger. Hence fault-injection test beds that inject power failures at arbitrary points for repeated testing, and emulators (e.g., Ekho, Fused) that reproduce actual harvested power waveforms, are researched and used.
Comparison of Power Management Paradigms
To clarify where intermittent computing sits, it helps to compare it with adjacent power-management approaches. The three approaches fundamentally diverge on "how much of an energy store to keep" and "how to treat power failure." The difference arises because the assumptions about power availability of the target applications differ. Where constant power or a large battery can be assumed, sleep-based low-power design is simple and safe; but in environments where that assumption breaks down, only the intermittent approach can keep operating.
| Category | Mains low-power (sleep/DVFS) | Battery-based IoT | Intermittent computing |
|---|---|---|---|
| Energy store | Mains power | Battery (large) | Capacitor (small)/batteryless |
| Failure handling | Exception (assumed not to occur) | Exception (low-power alert) | Normal event (assumed recurring) |
| State preservation | Unnecessary | Held by battery | Checkpoint mandatory |
| Lifetime constraint | None | Battery lifetime | Near-perpetual (while harvesting continues) |
| Main applications | Servers, mobile | Most IoT | Embedded/implanted/ultra-long-life sensors |
The practical implication is clear. If the battery approach is a "store enough energy in advance and avoid failures" strategy, the intermittent approach is a "minimize storage and endure failures" strategy. The former is simpler to design but pays battery lifetime and disposal costs; the latter is more complex to design but saves maintenance and environmental costs. Thus the two are best seen not as substitutes but as complements chosen according to application characteristics.
5. Application Areas and Cases
| Area | Use |
|---|---|
| Batteryless IoT | Environmental/structural monitoring sensors (bridge cracks, indoor air quality, etc.) |
| Wearable/health | Ultra-low-power biosensors for body temperature, heart rate, etc. |
| Edge AI (TinyML) | Ultra-low-power on-device inference |
First, a structural health monitoring (SHM) case. A vibration-harvesting sensor embedded in a bridge normally gathers power from the minute vibrations of passing traffic to measure and store crack/deformation data, and transmits wirelessly to a gateway only when enough power has accumulated. The goal is to operate throughout the structure's lifetime (decades) without battery replacement.
Second, an RFID-based batteryless sensing case. Notably, the WISP (Wireless Identification and Sensing Platform) drives an MSP430 MCU on RF energy from an RFID reader alone to measure temperature and acceleration, and has been widely used as a standard platform for intermittent computing research. It extends to applications in logistics and asset tracking where the tag senses its environment on its own.
Third, a TinyML inference atop intermittent power case. Research is active on carving a lightweight neural network into pieces (checkpointed per layer) at a power level of a few µW to a few mW so as to complete inference across several power cycles. This makes possible "a sensor that classifies sound or images on its own without a power line or a battery." For example, an ultra-low-power vision sensor that discerns human presence using only indoor light has been demonstrated at the prototype level.
6. Deep Dive — Research Trends and Standardization/Commercialization Flow
Intermittent computing has matured rapidly, led by academia, and the recent flow can be summarized in three directions. First, making the programming model transparent. Early on, developers had to insert checkpoints by hand, but now compilers automatically find safe points to insert checkpoints (e.g., automatic-checkpointing LLVM passes), or task-based language extensions try to abstract away power failures entirely. This is the key to lowering the biggest commercialization barrier, "development difficulty."
Second, embedding hardware support. FRAM-embedded MCUs (TI MSP430FR series) are already commercialized, and hardware checkpoint triggering via voltage monitoring and interrupts, as well as non-volatile processors (NVP, whose register file itself is non-volatile), are under research. As the write energy and endurance of next-generation NVMs such as MRAM and ReRAM improve, checkpoint cost drops further.
Third, combining intermittency with real-time requirements. For applications that must meet deadlines even in environments where power failures recur (e.g., safety-related sensing), research integrating energy prediction with real-time scheduling is emerging. That said, this area has not yet reached standardization, so it should be approached on the premise that specific performance and assurance levels vary greatly by application and platform.
7. Considerations and Implications
- Checkpointing optimization is the crux of performance: Instead of saving the entire state each time, choose differential checkpointing that saves only the changes, adaptive techniques that adjust the save timing to the remaining energy, and task-based models to match application characteristics. Determine the save period at the point where "re-execution loss × failure frequency" balances "checkpoint overhead."
- Design for consistency/correctness assurance: Take atomic updates and double buffering as the baseline to prevent WAR hazards and checkpoint corruption, and verify non-deterministic failure scenarios thoroughly with fault injection. Unverified intermittent code carries the risk of "occasionally wrong values."
- Sustainability (green)/maintenance-free value: Eliminating battery waste and minimizing replacement labor carries great value from the ESG and circular-economy viewpoints. From a TCO viewpoint too, the larger and longer the deployment, the more advantageous it is over the battery approach.
- Application strategy and trade-offs: For applications requiring stable power and strict real-time behavior, the battery approach still prevails. Intermittent computing is most advantageous where "low duty, low data rate, hard access, and ultra-long life" overlap, so decide on adoption by first analyzing the application's power profile and deadline requirements.
- Outlook on related technologies: Combining ultra-low-power NVM (FRAM/MRAM/ReRAM), non-volatile processors, automatic-checkpointing compilers, and TinyML extends toward "sensors that judge on their own without power." From a professional engineer's perspective, vertically integrated design capability spanning hardware, compiler, and runtime determines the success of adoption.
References
- ACM Computing Surveys, "Intermittent Computing: Challenges and Opportunities" — https://dl.acm.org/doi/10.1145/3524051
- Texas Instruments, MSP430FRxx FRAM Microcontrollers — https://www.ti.com/microcontrollers-mcus-processors/msp430-microcontrollers/overview.html
- University of Washington Sensor Systems Lab, WISP (Wireless Identification and Sensing Platform) — https://sensor.cs.washington.edu/WISP.html
In one line: Intermittent computing is ultra-low-power computing that treats intermittent power from energy harvesting as the normal state and, via checkpointing, non-volatile memory, and idempotency, preserves and restores state to carry work through to completion; forward progress and consistency are its core challenges, and it is used in batteryless IoT and edge AI.