Battery life and low power consumption are ongoing concerns of modern battery-powered electronics. Estimating them at the beginning of a design process can be quite challenging. Indeed, battery life and power consumption depend on almost all of the device characteristics: its hardware, battery, firmware, use case, and its environment. If each of these system aspects can be evaluated on their own more or less accurately, considering them in the same design space is a complex task.
One can argue that it’s not that important as long as they can be evaluated separately.
It’s a wrong and dangerous assumption.
All of these aspects are interdependent. The conventional approaches consist on:
building analytical models using spreadsheets and datasheets and/or
developing a partial prototype to test and evaluate most of these aspects.
Both approaches have their shortcomings. The analytical approach doesn’t account for the dynamic behavior of the device. That leads to misleading results and an under-performing device (if performing at all). The partial prototyping approach is incomplete; it implies time to manufacture/develop the prototype and a lot of work for engineers to measure and produce results that can also be misleading (i.e. because it’s partial and not complete).
Not mentioning the case of several years long battery life devices where measurement is nearly impossible.
In this article, I will present how we solved this estimation issue and created a simulation tool and a model library that is helping hundreds of engineers to explore several possible architectures and better design their device.
The models
Figure 1: modeling abstraction
The first object to model is the hardware (i.e., the electronic components that are assembled and embedded in a device). There are several modeling languages and frameworks that allow modeling electronic components (cf. Fig 1.). Each of them has its own characteristics and limitations. At Wisebatt we chose to model components based on their internal behavior. The power consumption is modeled at a very low level (i.e., close to Spice models) and all the functions of the component are modeled at a very high level. The input parameters of a component are defined using its datasheet. We considered each of their power modes and associated consumption as well as each of their internal state machines. This approach can be used for analog, digital and mixed signals components.
The second object to consider is the battery. Whether it is primary (non-rechargeable) or secondary (rechargeable) it is a complex chemical power source with characteristics that varies according to several parameters. The most important facts in our context are that 1) their nominal capacity isn’t fully accessible and 2) their supply voltage isn’t steady nor linear [1-3]. There are several ways of modeling a battery. We chose to model them by using a hybrid approach that considers internal resistance variation, supply voltage drops and realistic non-linear capacity decrease all along with the discharge. By doing so, we can simulate the moment when the battery supply voltage is going beyond the device’s cutoff voltage: this is precisely what is necessary to have an accurate battery life estimation.
Figure 2: Schematics view of the Sigfox Sens’it hardware
The last “object” to consider is the firmware. Each component has a functional model. This functional model embeds an instruction set that represents what the component can achieve (e.g., go to low power mode, transmit a signal, etc.). We developed a universal instruction set simulator called UISS that allows our users to describe in a simple way their device firmware and behavior. The other advantage of having a UISS is that computing elements (e.g., microcontrollers) can be swapped very easily.
The simulation
Beyond modeling, running a consistent simulation is also a challenge. Once the components and battery models are assembled by the users (cf. Fig. 2) and the device’s behavior defined in the firmware modeling, the simulation has to be run consistently. Our simulation kernel uses a discrete event mechanism derived from the Fast Event Driven (FED) method. For the aforementioned approach, each simulation’s event (i.e., each instruction) will be processed (i.e., executed by the UISS) at a given time and the overall time will progress after each processed event.
By default, nothing is supposed to happen between two events in FED. We added a Self Adaptive (SA) mechanism that inserts a number of events between two registered events depending on the nonlinearity degree of the battery and components models. This allows more accurate results as the electrical parameters of the components and battery will be updated more often. In comparison, the discrete approach is more likely to induce calculation errors.
The simulation then stops when the first cut-off voltage (i.e. the maximum value of the cut-off voltage) is reached. The time that was spent by the system in simulation is its battery life.
The results and their accuracy
At the end of the simulation, all the individual components logs are available. These logs include supply voltage (cf. fig. 3) and current draw (cf. fig. 4) as well as how much energy it has spent in its operating modes (cf. fig 5). These logs can be used to optimize the power consumption by very quickly spotting and optimizing the power-hungry components/features. Each simulation takes a couple of minutes which drastically reduces the time needed to evaluate an architecture or an optimizing.
Figure 3: Supply voltage curve example
Figure 4: Current draw curve example
Simulation results were validated over more than 200 devices. The experiments consisted of both environment-controlled and ambient-temperature tests for different devices that had from several days to several years of battery life, using both primary and secondary batteries, and different hardware and firmware. Overall, the average error made on battery supply voltage estimation is 6.17%. Regarding battery life accuracy, we observed results between 88.44% and 103.25% of the real battery life with an average error of around -6.93%.
Figure 5: Consumption breakdown and time vs energy comparison example
The presented simulation tool, its power consumption and battery life analysis are available in the feature “Power Analysis”. In addition, we do now offer complementary information that is essential to design or optimize a low power device. The goal: automate most of the low added value and time-consuming tasks (i.e., bill of material estimation, component’s electrical and functional compatibility, component’s configuration and supply constraints).
