Design considerations for power-sensitive embedded devices
Planning the Use Cases
Once the hardware is chosen and the decision has been made to use a particular OS, it is time to specify use cases for the device. A use case is typically a function that a device performs, whether with or without user interactions.
Let’s consider a hypothetical, battery powered, wearable medical device with a small LCD display that collects a patient’s vitals (body temperature, heart rate, etc.) and uploads the data periodically to a central server over Wi-Fi network. In such a device we can break out the following use cases:
1. Device takes a complete measurement
2. Device uploads a set of measured data
3. User checks his/her own vitals using a built in display
4. Device is idle awaiting the next measurement
For each use case we should determine how much functionality is required from each driver (if any), which in turn determines which drivers (and therefore hardware blocks) need to be enabled per use case. Using estimated hardware power consumption numbers and estimated time-spent in a specific use case, we can estimate the power consumed by each use case.
Combining this with the expected frequency of each use case as the weight factor, we should be able to come up with an energy breakdown showing how much of the full battery charge is consumed, per use case, over a set time period, e.g., 24 hours.
Using hypothetical numbers shown in Table 1 above, an energy breakdown for our hypothetical device is shown in Figure 2 below. This can be very helpful in determining early whether the estimated battery life has a chance to meet the original product requirements, and if not, how things can be adjusted.
For example, given the energy consumption per use case in Figure 2, one can clearly see that Data Upload is the biggest consumer of energy. If measuring vitals every five minutes and immediately uploading them to the server is too power costly, maybe measuring every five minutes, but uploading every 30 minutes is sufficient for the customer.
This would allow for the lowering of overall daily energy consumption. Of course along with the 30-minute intervals, there could be an emergency threshold set so that if the patient’s vitals exceed some critical threshold they are immediately uploaded.
User Vitals Check use case is the second biggest consumer of energy. Our assumed duration of 30 seconds use case was based on a 30-second timeout during which the built-in display continues showing the measured vitals after the user presses a key.
From this, we can see that decreasing the timeout to a lower yet still acceptable number significantly increases the battery life of the device. This use case is also an excellent candidate for average current optimization by shutting down any unnecessary hardware and setting the minimum operating point required to display static vitals measurements.
Loading comments... Write a comment