Time-sensitive Intermittent Computing Meets Legacy Software

Abstract

Tiny energy harvesting sensors that operate intermittently, without batteries, have become an increasingly appealing way to gather data in hard to reach places at low cost. Frequent power failures make forward progress, data preservation and consistency, and timely operation challenging. Unfortunately, state-of-the-art systems ask the programmer to solve these challenges, and have high memory overhead, lack critical programming features like pointers and recursion, and are only dimly aware of the passing of time and its effect on application quality. We present Time-sensitive Intermittent Computing System (TICS), a new platform for intermittent computing, which provides simple programming abstractions for handling the passing of time through intermittent failures, and uses this to make decisions about when data can be used or thrown away. Moreover, TICS provides predictable checkpoint sizes by keeping checkpoint and restore times small and reduces the cognitive burden of rewriting embedded code for intermittency without limiting expressibility or language functionality, enabling numerous existing embedded applications to run intermittently. CCS Concepts. • Computer systems organization → Embedded software; • Hardware → Emerging architectures; Impact on the environment; • Software and its engineering → Runtime environments; Source code generation.

Battery-Free Game Boy

“…Maintaining state of computation-let alone game statethrough power failures from intermittent harvested energy is hard [77,89]. Many software frameworks that support computation progress despite these power failures exist, saving state in non-volatile memory like FRAM and then restoring state after power resumes (see Figure 2), such as TICS [68], TotalRecall [144], and many others. Most systems trade memory efficiency for performance, this approach is opposite of that needed for gaming, where a display buffer and numerous sprites and large game state variables must be saved, requiring high memory efficiency.…”

“…While designing ENGAGE we chose to use a checkpoint based system to allow emulation of arbitrary game code. We did not consider task-based runtimes simply because they are too complex to comprehend by a programmer and more difficult to design than a checkpoint-based system, see related discussion on this topic in [68]. But first and foremost, task-based system cannot execute a binary (machine) code, which ENGAGE is mostly executing.…”

“…As with traditional checkpoint-based systems that use double-buffering, an atomic variable , determines which of the two buffers should be used to restore the system in case of a power failure [68,109]. This variable is changed-often incremented-to mark the completion of a checkpoint.…”

“…From the publication of a first framework supporting intermittently-powered devices, Mementos [109]-voltage threshold-triggered checkpoining system, more efficient checkpoint systems are being published. These include Hibernus++ [8] and QuickRecall [57] (just like Mementos, both hardware-activated chceckpoints), Chinchilla [82], Rachet [137] and HarvOS [11] (all three compiler-instrumented checkpoints), TICS (time-aware checkpoints) [68], TotalRecall (checkpoints using volatile memory) [144], Elastin (adaptive checkpoints) [19], DICE (differential checkpoints) [2,3] and WhatsNext (checkpointing augmented with approximate computing) [35]. A second class of systems include runtimes based on specially instrumented code (by form for a task) such as Dino [78], Chain [22], Alpaca [81], MayFly [45], InK [150], Coati [110], CoSpec [20] and Coala [84].…”

BFree

“…Current and future programming models for batteryless systems. Two left-most dashed rectangles shown the stateof-the-art, expert-focused programming models using either task graphs where each task is a focused C/C++ fragment, to define a program (as in InK [102]), or automatically (with some caveats) checkpointing a C/C++ program (as in TICS [44]). These models run bare-metal, as in the CPU directly executes the machine code.…”