A Reconfigurable Energy Storage Architecture for Energy-harvesting Devices

Abstract

Battery-free, energy-harvesting devices operate using energy collected exclusively from their environment. Energyharvesting devices allow maintenance-free deployment in extreme environments, but requires a power system to provide the right amount of energy when an application needs it. Existing systems must provision energy capacity statically based on an application's peak demand which compromises efficiency and responsiveness when not at peak demand. This work presents Capybara: a co-designed hardware/software power system with dynamically reconfigurable energy storage capacity that meets varied application energy demand. The Capybara software interface allows programmers to specify the energy mode of an application task. Capybara's runtime system reconfigures Capybara's hardware energy capacity to match application demand. Capybara also allows a programmer to write reactive application tasks that pre-allocate a burst of energy that it can spend in response to an asynchronous (e.g., external) event. We instantiated Capybara's hardware design in two EH devices and implemented three reactive sensing applications using its software interface. Capybara improves event detection accuracy by 2x-4x over statically-provisioned energy capacity, maintains response latency within 1.5x of a continuously-powered baseline, and enables reactive applications that are intractable with existing power systems.

Capacity over capacitance for reliable energy harvesting sensors

“…When we began the design of Permamote, we initially intended to use capacitors as the rechargeable energy store. At the time, the assertion that batteries were expensive, bulky, and had extremely limited lifetimes was prevalent [10,[15][16][17][18]29]. Upon further examination, we find that these claims are no longer true for many applications due to technology improvements, and the gains provided by increased energy storage capacity are numerous.…”

“…Still, significant progress has been made in making these systems more reliable and programmable. Progress latching and checkpointing techniques [30,40] enable forward progress through reboots, special debugging tools [9] can emulate and replay energy state, and finely-tuned or reconfigurable power supplies [10,16] increase sensor availability under varying workloads. Even with these techniques, capacitor-based energy harvesting sensors are less reliable and more difficult to use than their battery-powered counterparts.…”

Intermittent Learning

“…The board consists of an ATmega328p microcontroller having a 1KB internal EEPROM, light and temperature sensors, a 32KB external non-volatile EEPROM, a 0.2F supercapacitor as the energy reservoir, output indicator LEDs, and energy harvester circuitry. Although more advanced energy management hardware such as multiple capacitors [16,32,34] can be used for more efficient use of harvested energy, we keep our hardware design simple to focus on the feasibility, behavior, and performance of the learning framework. The air-quality sensors measuring UV, eCO2, and TVOC are externally connected to the PCB (not shown in the figure).…”

“…Clank [36] proposes a set of hardware buffers and memory access monitors that dynamically maintain idempotency. Several studies [16,33] focus on the power management of batteryless systems.…”

“…The fundamental difference between a machine learning task and a typical task on a batteryless system (e.g., sensing and executing an offline-trained classifier) lies in the data and application semantics, which requires special treatment for effective learning under an extreme energy budget. Existing works on intermittent computing address important problems, such as ensuring atomicity [14,57], consistency [14,56,57], programmability [35], timeliness [35], and energy-efficiency [7,16,33], which enable efficient code execution of general-purpose tasks. Our work complements existing literature and specializes in a batteryless system on efficient and effective on-device learning by explicitly considering the utility of sensor data and the execution order of different modules of a machine learning task.…”