To realize the scale of device deployments as envisioned by the Internet of Things (IoT), we inevitably face the issue of how these numerous “Things” are to be powered. In the case of many smart appliances, for example your Philips Hue bulbs or Amazon Echo Dot, this is a non-issue since these devices are connected to mains power. The same may be said for battery-powered appliances, such as smart watches and fitness bands, where recharging or replacing a battery is easy and convenient.
The delinquents are the deeply embedded and remotely located devices, such as microchip implants, retrofitted utility meters, forest fire monitoring sensor nodes and so on. These are untethered from mains, and battery replacement or recharge is at a premium. This is an issue that is exacerbated by the deployment scale of some of these systems. A future where hundreds of ubiquitous intelligent devices augment our homes may sound enticing, but it quickly turns into a nightmare once they all decide to beep at you for a battery replacement or recharge.
Scavenging energy from the environment is a potential solution. Ambient power sources include electromagnetic radiation (solar, radio frequency), mechanical (vibration, motion), and temperature gradients. They can be harvested using micro-generators, such as solar cells, RF rectennas (as found in Arm’s Project Triffid), tiny wind turbines, piezoelectric devices, and Peltier devices. However, these power sources are quite finicky. They typically have limited power density (watts per volume or surface area) and may exhibit significant temporal and spatial variation in their output power.
The first issue relates to scarcity, whereas the latter is about intermittency. Functionality and performance of the device may be scaled down to cope with scarcity. On the other hand, intermittency issues may be circumvented by introducing some large energy buffers, and so decoupling the power demand characteristics of the application from the properties of the power supply. To elaborate on this issue, consider this equation:
All it says is that in a functional system, the energy supply needs to meet the energy demand of the workload. For instance, for long time intervals, solar powered sensor node needs to harvest enough energy while the sun is up to account for both daytime and night-time operations. The same condition should also hold at a larger timescale, accounting for summer versus winter variations. At the other extreme with short intervals, there should be sufficient energy to fulfill “atomic” operations, for example, a sensor sample, an instruction execution on the processor, or a radio transmission event.
The key takeaway is that the previous equality should hold for all, regardless if the unit of measurement is in the microseconds or whether it is measured in months or years. This demands a flexibility in the design process and the tools to account for both macro and microvariations in the hardware and software components (the demand side), and in the physical environment (the supply side).
Based on the discussion above, we argue that an effective study of energy scavenging systems requires:
Our virtual prototyping framework, captured in figure 1, is designed to meet the items listed.
Figure 1: Architecture of proposed virtual prototyping framework for energy scavenging IoT devices.
The framework is based on the Fused simulator, an open-source full-system simulator for energy-driven computers. For a detailed discussion on the “board-level” extensions to the Fused simulator to enable virtual prototyping of energy harvesting IoT device, refer to our paper and video presentation recently delivered at ENSsys 2020.
Figure 2 illustrates an example energy scavenging sensor node virtual prototype built in our framework. The example output traces in figure 3 illustrate the signals captured in Fused when a real application binary is executed on the microcontroller model. In this case, a simple sensor sampling and radio transmission. It also shows the current measured on the corresponding physical prototype executing the exact same code. In the virtual prototype, all data structures, analog and digital signals, can be easily traced. This includes such as state machines, on-chip bus traffic and power-rails, for example.
Figure 2: An example system virtual prototyped in Fused.
Figure 3: Output traces for virtual prototype simulation.
The extensions described have been upstreamed to the Fused GitHub repository. The original intention of Fused was to “accelerate the proliferation of tiny connected smart device”, by providing a useful tool that simulates computation and energy in a closed loop. We expanded on this to enable the simulation of an entire IoT device and, believe it will be an invaluable tool for early-stage design space exploration. If your research topic involves energy scavenging networked cyber physical systems, stay tuned because we are working on a networking extension. Fused is open source and we would be thrilled if the community can join us in what we believe is a very meaningful endeavor.
Explore the Fused GitHub repository