Energy per Useful Measurement: Include Failed Work and Wake Overhead in the Energy Budget

Divide the energy consumed over a defined workload by the number of results that actually satisfy the product’s acceptance rules. Include failed attempts, retries, wake overhead, and idle time in the numerator. Counting every conversion or transmitted packet as a useful result can make an unreliable low-power policy look efficient.

Applicability: this is an original accounting method for periodic embedded sensing and reporting. It is not an EEMBC benchmark implementation or a measured product comparison. The numerical worksheet is hypothetical; acceptance rules, instrumentation, and operating conditions must be specified for the actual product.

1. Define useful work before measuring energy

Write one explicit acceptance predicate. For example, a result may need a valid sensor status, an allowed age, the required precision, a unique request identifier, and confirmed delivery to the intended consumer. Choose only the conditions the product actually requires, but do not weaken them after observing the power result.

Separate attempted acquisition, valid acquisition, accepted local result, and accepted remote delivery. These counters answer different questions. If the product requirement ends at local storage, a network retry need not determine measurement validity; if it requires remote availability by a deadline, delivery belongs in the acceptance rule.

Count duplicate deliveries once for useful-work purposes. Retain them as traffic and energy events. Likewise, a late result can be technically valid but fail the requested service deadline. Preserve its category rather than silently adding it to the denominator.

2. Use a fixed electrical and time boundary

Choose the measured rail or complete-device input and state what is excluded. Use the same boundary for every compared policy. A sensor-rail measurement excludes CPU and communication energy unless those paths are also measured and combined without overlap.

Energy over the window is the integral of voltage multiplied by current. Charge is the integral of current. If voltage varies materially, a charge total multiplied by nominal voltage is not automatically an accurate energy total. Retain units and the actual integration interval in the worksheet.

The PPK2 guide lists accumulated charge and average-current measurements among its uses. Those electrical quantities still need application-event evidence before they can become energy per accepted result. Instrument validity and missing samples require their own qualification.

Define whether the comparison includes cold startup, association, calibration, shutdown, and recharge of local buffers. If those costs are amortized over a deployment interval, publish that interval and the allocation rule. Do not remove startup from one policy while retaining it for another.

3. Build an event ledger that survives retries

Give each requested useful result a stable logical identifier. Give each acquisition or delivery attempt its own attempt identifier. Link retries back to the logical request so the same result cannot be counted repeatedly merely because several operations were required to obtain it.

Record start and finish times, outcome, rejection reason, retry number, and any accepted-result timestamp. Keep rejected samples, failed transmissions, timeouts, and cancellations in the ledger. Their energy remains part of the measured window even when their contribution to accepted work is zero.

Synchronize application events with the current trace using an appropriate marker or common timing reference. Document uncertainty. If operations overlap, prefer total-window energy divided by accepted count as the primary metric; attributing every joule to an individual operation may require assumptions that the data cannot justify.

4. Recalculate the denominator in a concrete worksheet

Consider two hypothetical policies evaluated over equal windows containing 100 acquisition attempts each. Policy A consumes 180 mJ and produces 90 accepted results. Policy B consumes 154 mJ but produces only 70 accepted results. All other attempts are rejected under the same fixed rules.

Policy B uses less total energy and less energy per attempt, yet its energy per accepted result is 10% higher. It also delivers fewer accepted results in the same window. The stage values are non-overlapping invented inputs for arithmetic illustration, not measurements of a particular sensing algorithm.

5. Keep efficiency beside service quality

Report accepted results per unit time, deadline success, rejected-result distribution, and energy per accepted result together. A policy can improve one metric by doing less useful work. A very sparse sampler might have attractive energy per sample while violating the required detection latency.

As a separate established example, EEMBC’s ULPMark-CoreMark overview presents energy efficiency as iterations per millijoule alongside performance and measurement voltage. Its benchmark rules are distinct from this worksheet, but the pairing illustrates why an efficiency number needs a work-rate context.

Similarly, ULPMark-CoreProfile includes sleep and transitions in a defined duty cycle. Do not call a custom application test a certified benchmark or compare its denominator directly with benchmark scores. Publish the actual workload and its acceptance semantics.

6. Handle zero success and incomplete windows honestly

If no result is accepted, energy per accepted result has no finite value. Report zero accepted results and the consumed energy; do not substitute zero for the ratio. If capture ends with requests still pending, either complete the agreed accounting window or report those unresolved requests explicitly.

For repeated runs, retain per-run energy and counts. The aggregate ratio is total energy divided by total accepted results. An unweighted average of per-run ratios can answer a different question when run sizes differ. State the aggregation method and variation rather than hiding bad runs behind one mean.

Classify missing electrical data separately from failed useful work. A recording failure is not a zero-energy interval. If the missing contribution cannot be bounded sufficiently for the comparison, the run is incomplete and needs another valid acquisition.

7. Turn the worksheet into a release decision

Freeze firmware, sensor settings, communication conditions, supply, temperature, workload, and acceptance rules. Compare policies only after both meet the required service envelope. Then investigate the largest avoidable energy contributions, including repeated failures and unnecessary wakeups.

The deliverable is the raw energy record, event ledger, accepted-result classifier, and reproducible arithmetic. It supports an efficiency claim for the stated workload once measured. It does not alone establish battery runtime, sensing accuracy, or performance under untested failure conditions.