14 ACE and Shared Context Sensing

14.1 Start With One Shared Fact

This section: Start With One Shared Fact — Picture three phone apps waking the same motion sensor for the same answer.

Sense the Room Once and Reuse the Result

Picture three phone apps waking the same motion sensor for the same answer. A broker means a service that receives information and passes it to the right users or systems.

Name the requested fact, sensor cost, broker, cached answer, age limit, and requesting apps. Test a fresh answer, a stale answer, conflicting needs, and a missing sensor while comparing energy use.

Keep requests, sources, times, cache decisions, energy estimates, and fallbacks. This proves one shared context rule, not every privacy or accuracy case; the deeper sections cover the ACE roles, planning, inference, reuse, and limits.

If one sensor reading can answer several questions, repeating the same sensing work wastes energy. ACE starts from that shared fact: sense once, cache the context, reuse it while it is fresh, and fall back when confidence expires.

Read this chapter as a broker story. Ownership, freshness, correlation, and validation decide whether shared context is an energy saving or a stale shortcut.

Math Bridge · guided foundationsWhy does occupancy sensing need a settling window?Let Battery Bruno connect pyroelectric current, filter bandwidth, and the ACE energy ledger. Learn the maths

14.2 ACE System and Shared Context Sensing

This section: ACE System and Shared Context Sensing — This chapter focuses on the ACE pattern inside context-aware energy management.

This chapter focuses on the ACE pattern inside context-aware energy management. The previous overview introduced the high-level cache -> infer -> sense loop. Here, the goal is to understand the three ACE responsibilities that make that loop reviewable:

• Shared context ownership and cache freshness.
• Rule mining with support, confidence, and consequence-aware thresholds.
• Sensing-planner fallback when cached or inferred evidence is not strong enough.

14.3 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• Explain why shared context sensing can reduce redundant sensor activations.
• Distinguish an inference cache, rule miner, contexter, and sensing planner.
• Calculate support and confidence for a simple context association rule.
• Choose when to reuse, infer, sense a proxy, or sense the target attribute directly.
• Define evidence records that keep shared context decisions auditable.

14.4 Prerequisites

This section: Prerequisites — The component names become useful when they answer one application request.

Review these chapters if the terms are unfamiliar:

• Context-Aware Energy Management: the control loop and policy gates.
• Duty Cycling Fundamentals: average-current baselines and wake interval trade-offs.
• Modeling and Inferencing: basic model and inference vocabulary.

The component names become useful when they answer one application request. Figure 14.1 places the cache, planner, contexters, history, and energy record on that path.

+

Follow Get(inMeeting) into Inference cache in Figure 14.1, then continue through Planner only when a fresh hit is unavailable. The Energy record beside Context result is essential: the returned value must name both its confidence and the sensing cost used to obtain it.

14.5 The ACE Architecture

This section: The ACE Architecture — ACE separates a context request from the physical sensor that might answer it.

ACE separates a context request from the physical sensor that might answer it. That separation lets one app reuse another app’s recent context value, infer a target value from a correlated attribute, or choose a lower-cost proxy sensor before paying for a high-cost sensor.

14.10 Shared Context Sensing

This section: Shared Context Sensing — Shared context sensing avoids redundant sensor activation when multiple apps or services ask for the same attribute.

Shared context sensing avoids redundant sensor activation when multiple apps or services ask for the same attribute. The cached value is not just a raw answer; it is an evidence record.

Use Figure 14.2 to decide when several applications may safely reuse one cached context result instead of waking sensors independently.

+

Open one context record. Check its age and source. Read Figure 14.2 from the context consumers through ACE middleware to the inference cache and underlying sensors. Several applications can reuse a result at near-zero lookup cost only when the cached record still satisfies their purpose. The path therefore needs more than a value: source, observation time, location or subject, confidence, freshness limit, and invalidation trigger travel with it. A location tracker may tolerate an older estimate than a safety rule, so reuse is approved per consumer contract. Shared sensing saves energy by avoiding redundant activation without hiding provenance or staleness.

Correlation is valuable only when its fallback order remains inspectable. Figure 14.3 prices a cache hit, inferred hit, and sensor proxy on one route.

+

At CACHE, Figure 14.3 prices a fresh answer at 0.4 mJ; PROXY lists Wi-Fi at 29 mJ before audio at 155 mJ and GPS at 1385 mJ. The intervening INFER rule carries 80% support and 88% confidence, so it cannot masquerade as a directly sensed fact. The last RECORD box keeps the answer’s source, age, confidence, and energy cost. Read the boxes left to right as a fallback order, not as equal sources of truth. That distinction matters when the next section uses correlations to infer a new attribute.

14.11 Cross-App Context Correlations

This section: Cross-App Context Correlations — ACE becomes more powerful when it can infer one context attribute from another.

ACE becomes more powerful when it can infer one context attribute from another. This is where association rules matter.

Rule:
  Driving = true  ->  AtHome = false

Support:
  Count(Driving = true and AtHome = false) / Count(all observations)

Confidence:
  Count(Driving = true and AtHome = false) / Count(Driving = true)

Support tells whether the rule occurs often enough to matter. Confidence tells whether the rule is reliable when the antecedent is true. A rare rule with high confidence may still be useful for a niche event; a common rule with weak confidence should not drive high-consequence decisions.

Before treating cross-app context correlations as settled, compare observed contexts with Candidates in the diagram at Figure 14.4. Their relationship shows which part of the claim still needs evidence.

+

In the diagram at Figure 14.4, observed contexts comes first because it adds a distinct review condition. The next checkpoint, Candidates, adds a distinct review condition, while if-then rules adds a distinct review condition. Together those labels show that no-panel ACE rule mining gates showing observed context history, candidate rules, support filter, confidence filter, consequence threshold, and accepted rule set. That is the evidence chain the running cross-app context correlations argument now relies on.

Planning should change the sensor order, not merely rename an always-sense baseline. Figure 14.5 compares that baseline with exhaustive and heuristic choices across four users.

+

Read Figure 14.5 by comparing each person’s two colored bars with the grey baseline of 100. For Ada the exhaustive plan is 31 and the heuristic plan is 38; for Ben they are 42 and 47. Cleo’s pair is 58 and 62, and Dara’s is 49 and 55. In every displayed case, the heuristic uses a little more energy than the exhaustive plan but much less than the baseline. The next section asks how to choose a sensing path without losing required coverage.

14.12 Sensing Planner

This section: Sensing Planner — The sensing planner decides which evidence to acquire next.

The sensing planner decides which evidence to acquire next. A good planner orders options by total expected cost, not by sensor name alone.

Use Figure 14.6 to decide whether a requested context attribute justifies its sensor combination or should reuse a cheaper, fresher inference.

+

Read one attribute at a time. Tie each cost to evidence. Read Figure 14.6 from the accelerometer attributes near 259 mJ through Wi-Fi and GPS combinations to the microphone combinations near 2,895–3,505 mJ. The bars show that context names conceal different sensing costs: walking and driving can share a low-cost motion source, while meeting or working inference activates more expensive inputs. Using the displayed endpoints, 3,505/259 ≈ 13.5, which supports the stated roughly fourteen-fold gap. The planner should therefore check cache freshness and confidence before activating the highest-cost sensor set, while retaining reliability fallbacks for cases where reuse is unsafe.

def answer_context(request, cache, rules, planner):
    cached = cache.lookup(request.attribute)
    if cached and cached.age_s <= request.max_age_s and cached.confidence >= request.min_confidence:
        return Decision("reuse_cache", cached.value, cached.evidence)

    rule = rules.best_for(request.attribute, cache.available_values())
    if rule and rule.confidence >= request.min_confidence:
        return Decision("infer_from_rule", rule.output_value, rule.evidence)

    proxy_plan = planner.cheapest_proxy(request.attribute)
    if proxy_plan and proxy_plan.expected_confidence >= request.min_confidence:
        proxy_value = proxy_plan.sense()
        return Decision("sense_proxy_then_infer", proxy_value, proxy_plan.evidence)

    target_value = planner.sense_target(request.attribute)
    return Decision("direct_target_sensing", target_value, target_value.evidence)

The planner should also record the rejected options. That makes it possible to review why the system sensed directly even though a cached value or proxy rule existed.

14.13 Worked Example: Room Occupancy Context

This section: Worked Example: Room Occupancy Context — Promote the shared-context policy only if the evidence record shows reduced sensor activations without increasing missed occupancy events or first-light latency.

Scenario: A building platform has three services requesting room occupancy:

• HVAC wants occupancy every 5 minutes.
• Lighting wants occupancy within 30 seconds.
• Analytics wants a room-use summary every hour.

Available evidence

Door event:
  Room 304 opened at 09:01:10, confidence 0.98, TTL 60 seconds

Motion event:
  Motion detected at 09:01:25, confidence 0.95, TTL 120 seconds

Rule:
  DoorOpened and WeekdayMorning -> RoomOccupied
  support = 0.28
  confidence = 0.91

Review

• The analytics request can reuse a cached occupancy value because hourly summaries tolerate moderate staleness.
• The HVAC request can use the rule if the door event is fresh and the policy has a conservative fallback.
• The lighting request should require fresher direct or motion evidence because user-visible delay is more obvious.

Decision

Promote the shared-context policy only if the evidence record shows reduced sensor activations without increasing missed occupancy events or first-light latency.

14.14 Evidence Record

This section: Evidence Record

For each promoted ACE rule or shared context cache, keep a compact review record:

1. Attribute: target context value, such as RoomOccupied.
2. Consumers: apps or services allowed to reuse it.
3. Source: sensor, contexter, classifier, or rule.
4. Freshness: TTL, age at use, and expiry behavior.
5. Confidence: rule confidence or classifier confidence.
6. Fallback: direct sensor, conservative policy, or reject path.
7. Outcome: saved activations, direct sensing count, miss rate, latency, and retries.

14.15 Common Pitfalls

This section: Common Pitfalls

14.22 Related Chapters

This section: Related Chapters

14.27 Knowledge Check

This section: Knowledge Check

14.28 Knowledge Check: Shared Cache Reuse

This section: Knowledge Check: Shared Cache Reuse

14.29 Knowledge Check: Rule Threshold

This section: Knowledge Check: Rule Threshold

14.30 Matching Quiz: ACE Component Responsibilities

This section: Matching Quiz: ACE Component Responsibilities

14.31 Ordering Quiz: ACE Request Path

This section: Ordering Quiz: ACE Request Path

14.32 Label the Diagram: ACE Shared Context Path

This section: Label the Diagram: ACE Shared Context Path

14.33 What’s Next

This section: What’s Next

14.38 Sense Once, Reuse Many

This section: Sense Once, Reuse Many — Continuous context sensing is expensive because every fresh reading wakes the processor, powers a sensor, waits for it to settle, samples it, and runs an inference.

Continuous context sensing is expensive because every fresh reading wakes the processor, powers a sensor, waits for it to settle, samples it, and runs an inference. When several apps or subsystems each ask "is the room occupied?" independently, they each pay that full cost. A shared context engine senses once and lets every reader reuse the cached result until it goes stale.

Two levers cut the energy. An inference cache converts most context requests from a full sensing operation into a cheap table lookup. Learned correlations let a cheap sensor stand in for an expensive one, so the engine can answer a query without ever powering the costly sensor. Both are the core ideas of the ACE approach to energy-efficient continuous context.

Worked example: a thermostat service, security rule, room-usage logger, and dashboard each ask for occupancy once per minute. If each reader senses independently and a full occupancy check costs 0.34 mA-s, the system spends 4 x 0.34 = 1.36 mA-s every minute. With a shared cache and a 60-second freshness window, the first reader pays 0.34 mA-s and the next three readers pay only 0.016 mA-s lookups, for 0.34 + 3 x 0.016 = 0.388 mA-s. The hardware did not become more efficient; the system simply stopped repeating the same evidence collection four times.

Before choosing a cache or inference path, inspect Figure 14.7. It shows where a shared request can reuse evidence and where the system must pay for a fresh sensing operation.

+

Read Figure 14.7 from the applications into the broker. Follow a cache hit to immediate reuse, then compare that short path with the rule-mining and sensing-planner path that wakes contexters and produces new validation evidence. The comparison identifies which requests save energy and which still require measurement.

14.39 Where The Energy Goes

This section: Where The Energy Goes

14.40 Overview Knowledge Check

This section: Overview Knowledge Check

14.41 Cost A Cache Hit Against A Full Sense

This section: Cost A Cache Hit Against A Full Sense — Model the average energy per context request as E_req = h x E_cache + (1 - h) x E_sense, where h is the cache hit rate.

Model the average energy per context request as E_req = h x E_cache + (1 - h) x E_sense, where h is the cache hit rate. The full-sense energy is the sum of every state the reading touches; the cache-hit energy is just a lookup while the processor is briefly awake.

14.42 Worked Example: Shared Occupancy Context

This section: Worked Example: Shared Occupancy Context — A full occupancy sense holds the MCU active at 8 mA for 30 ms (0.24 mA-s) and powers a sensor at 2 mA for a 50 ms settle plus sample (0.10 mA-s), so E_sense = 0.34 mA-s.

A full occupancy sense holds the MCU active at 8 mA for 30 ms (0.24 mA-s) and powers a sensor at 2 mA for a 50 ms settle plus sample (0.10 mA-s), so E_sense = 0.34 mA-s. A cache hit is a 2 ms lookup at 8 mA, so E_cache = 0.016 mA-s - about twenty times cheaper. The context is requested 240 times per hour across all subsystems (5760 times per day).

• No cache (h = 0): 5760 x 0.34 mA-s = 1958 mA-s/day = 0.544 mA-h/day.
• Hit rate 80%: E_req = 0.8 x 0.016 + 0.2 x 0.34 = 0.081 mA-s; 5760 x 0.081 = 467 mA-s/day = 0.130 mA-h/day.
• Saving: about 0.41 mA-h/day, roughly 150 mA-h/year - a large fraction of a coin cell.

Equivalently, if one sense serves four readers inside the validity window, the per-reader cost falls to 0.34/4 + 0.016 = 0.10 mA-s, about 3.4x cheaper than four independent senses.

14.43 Cache Energy Ledger

This section: Cache Energy Ledger

14.44 Practitioner Knowledge Check

This section: Practitioner Knowledge Check

14.45 Freshness Gates The Savings, Correlation Skips The Sensor

This section: Freshness Gates The Savings, Correlation Skips The Sensor — The cache only helps if reused values are still valid, so the freshness window is the real control knob.

The cache only helps if reused values are still valid, so the freshness window is the real control knob. Set the validity window too short and almost every request misses, driving the hit rate - and the savings - toward zero. Set it too long and readers act on stale context, which can trigger wrong decisions and wasted downstream energy that dwarfs the sensing you saved. The right window matches how fast the context actually changes.

The second lever is correlation. If a learned rule says a cheap sensor determines an expensive context - for example, an accelerometer reporting "stationary" implies location has not changed - the engine can answer a location query without a GPS fix. That matters because the costs are wildly different: a GPS module in tracking mode draws roughly 25 mA, so a 10-second fix costs about 250 mA-s (0.069 mA-h), while a low-power accelerometer check at about 10 uA for 100 ms costs roughly 0.001 mA-s. If the device is stationary 70% of the time and would otherwise take 100 fixes a day, skipping 70 of them by trusting the accelerometer saves about 70 x 250 mA-s = 4.9 mA-h/day.

Freshness math explains the failure mode. Suppose 20 components request the same context each minute. With a 60-second validity window, one full sense plus 19 lookups costs 0.34 + 19 x 0.016 = 0.644 mA-s/min. With a 2-second window, the cached value expires roughly every other request; ten full senses plus ten lookups cost 10 x 0.34 + 10 x 0.016 = 3.56 mA-s/min. That is still better than 20 independent senses, but it is more than five times the 60-second cache cost. The validity window is therefore an energy-control parameter, not just a data-quality label.

14.46 Design Tensions

This section: Design Tensions

14.47 Under-the-Hood Knowledge Check

This section: Under-the-Hood Knowledge Check

14.48 Sensing-Planner Complexity and a Practical Heuristic

This section: Sensing-Planner Complexity and a Practical Heuristic — A conditional sensing plan is a decision tree.

A conditional sensing plan is a decision tree. Each internal node either tests a cached attribute, wakes a sensor, or runs an inference; each outgoing edge represents a possible result. A leaf returns the requested context with an explicit confidence and freshness state. The planner’s job is to find a tree that minimizes expected energy without violating those correctness gates.

For a plan node $a$ with sensing cost $c(a)$ and outcomes $v$, the expected remaining cost is

At a terminal leaf, $J=0$ only when the available evidence is sufficient to answer. Otherwise that branch must pay for another test or fall back to the authoritative sensor. This recurrence explains why “always choose the cheapest sensor first” can fail: a cheap sensor whose result rarely resolves the query merely adds its own cost before the expensive fallback.

Consider a request for InMeeting:

The time rule is the cheapest individual test, but the accelerometer is the cheaper plan because it avoids the fallback more often. Outcome probabilities must come from representative traces; invented confidence values only make the optimizer precisely wrong.

Why not enumerate every tree? With $n$ optional attributes there are already $2^n$ possible subsets, $n!$ possible full orderings, and a branch can expose a different remaining choice after every outcome. Exact optimal decision-tree and related sensing-plan formulations contain known NP-hard problems. That statement applies to the general planning problem; a small, constrained instance can still be searched exactly.

A scalable planner can use the following bounded heuristic:

1. Prune invalid evidence. Remove stale cache entries, forbidden sensors, and rules below their confidence threshold.
2. Estimate marginal value. For each remaining test, estimate how much probability mass it moves to a valid terminal answer.
3. Score the test. One useful greedy score is $\Delta P_{resolved}/(E_{test}+E_{wake})$; include shared wake cost only once when several tests can run in the same active window.
4. Expand a small beam. Keep the best $k$ partial trees rather than only the single greedy choice. This preserves alternatives when two tests interact.
5. Attach an authoritative fallback. Every unresolved or low-confidence branch must terminate in a known sensor path or an explicit “unknown,” never an unsupported guess.
6. Measure regret. On replay traces, compare heuristic energy and answer quality with exact search for small cases. Record the gap so scaling up does not hide a poor approximation.

Branch-and-bound can improve the exact small-case search: stop expanding a partial tree once its accumulated cost plus an optimistic lower bound exceeds the best complete plan found so far. In production, re-plan when energy costs, cache-hit rates, or correlations drift. The planner is an adaptive policy built from evidence, not a one-time static ordering of sensors.

14.49 Summary

This section: Summary — This chapter introduces the ACE system: shared context sensing, a context broker, inference cache, rule miner, and sensing planner.

This chapter introduces the ACE system: shared context sensing, a context broker, inference cache, rule miner, and sensing planner. It shows how applications can reuse context while managing freshness, confidence, ownership, and validation evidence.

14.50 Key Takeaway

This section: Key Takeaway — ACE reduces duplicate sensing only when shared context is governed.

ACE reduces duplicate sensing only when shared context is governed. TTLs, confidence thresholds, ownership, fallback cost, and drift monitoring must be explicit before multiple applications rely on the same inference.