A simpler, safer programming and execution model for intermittent systems

Abstract

Energy harvesting enables novel devices and applications without batteries, but intermittent operation under energy harvesting poses new challenges to memory consistency that threaten to leave applications in failed states not reachable in continuous execution. This paper presents analytical models that aid in reasoning about intermittence. Using these, we develop DINO (Death Is Not an Option), a programming and execution model that simplifies programming for intermittent systems and ensures volatile and nonvolatile data consistency despite near-constant interruptions. DINO is the first system to address these consistency problems in the context of intermittent execution. We evaluate DINO on three energy-harvesting hardware platforms running different applications. The applications fail and exhibit error without DINO, but run correctly with DINO’s modest 1.8–2.7× run-time overhead. DINO also dramatically simplifies programming, reducing the set of possible failure- related control transfers by 5–9×.

Optimal checkpointing for secure intermittently-powered IoT devices

“…To address this issue, previous work has proposed enforcing a checkpoint between every non-idempotent memory access pairs [26], or versioning the inconsistent data [27] so that every non-idempotent memory access pair is eliminated. Liu et.…”

Operating Wireless Sensor Nodes without Energy Storage: Experimental Results with Transient Computing

“…As a follow-up to the above, DINO ("Death Is Not an Option") [23] adds support for dealing with the inconsistency between volatile and non-volatile data that may occur due to frequent interrupts. Another novelty in DINO is the use of a microcontroller based on FRAM instead of Flash memory.…”

On intermittence bugs in the battery-less internet of things (WIP paper)

“…Intermittence bugs. Intermittent execution introduces the possibility of intermittence bugs [4,14,20,25], where programs reach a state unattainable in a continous execution. Fig.…”

“…2, however, that intermittence bugs may appear in other settings as well, overlooked by prior work. Existing literature addresses intermittence bugs at compile time by placing checkpoints to avoid their occurrence [16,25] or with custom programming abstractions that encourage programmers to write bug-free code [5,14,15].…”

“…Ratchet energy overhead is significant; system performance is arguably practical only where all data but registers and program counter are on NVM. Custom programming abstractions [5,14,15] force programmers to learn new concepts and possibly to refactor existing codebases, hampering adoption. They also incur in significant run-time overhead.…”