14 ACE and Shared Context Sensing

14.1 Start With One Shared Fact

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.

Phoebe’s Field Notes: Why the Occupancy Sensor Needs Its 50 ms

The mathematical gist. A PIR element responds to temperature change through $i=pA(dT/dt)$, not to a stationary temperature level. With a 10 Hz charge-amplifier corner, $\tau=1/(2\pi f_c)=15.9$ ms and three time constants give 47.7 ms, independently supporting the chapter’s 50 ms sensing window and 0.34 mA-s ledger.

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 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

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

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

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

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.

A useful review of shared context sensing needs both Context Consumers and App 1 in view. The visual in Figure 14.2 places them on one evidence path so an attractive partial result is not mistaken for acceptance.

Start the figure at Figure 14.2 with Context Consumers and ask how it adds a distinct review condition. Against it, App 1 adds a distinct review condition; the later Location Tracker adds a distinct review condition. The ordering is consequential: ACE context-aware energy management architecture where an application layer of context consumers queries ACE middleware whose inference cache returns shared context values at near-zero power per lookup. Carry that ordering into the next shared context sensing review.

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.

14.11 Cross-App Context Correlations

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.

For Ada, Figure 14.5 shows the heuristic at 48 versus the exhaustive plan at 42 and the baseline at 100. Cleo remains more expensive at 62 because the context is less stable; that spread is why a planner should test cheap evidence first and stop when another sensor is not worth its uncertainty reduction.

14.12 Sensing Planner

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

The next choice depends on separating 4000 mJ from IsWalking. The figure at Figure 14.6 makes that boundary visible before the chapter commits to sensing planner.

Enter Figure 14.6 at 4000 mJ, which adds a distinct review condition. Continue to IsWalking, where the visual adds a distinct review condition; then check IsDriving, which adds a distinct review condition. This progression makes the point concrete: Bar chart of energy cost per sense for ten context attributes. Accelerometer-based attributes such as walking, driving, jogging, and sitting cost about 259 millijoules. WiFi-based attributes such as at-home and in-office cost about 605 millijoules. GPS-plus-WiFi indoor detection costs about 1985 millijoules. Microphone and WiFi-plus-microphone attributes such as alone, in-meeting, and working cost about 2895 to 3505 millijoules, roughly fourteen times the accelerometer attributes. The result feeds the chapter’s sensing planner decision with the boundary still attached.

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

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

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

14.22 Related Chapters

14.27 Knowledge Check

14.28 Knowledge Check: Shared Cache Reuse

14.29 Knowledge Check: Rule Threshold

14.30 Matching Quiz: ACE Component Responsibilities

14.31 Ordering Quiz: ACE Request Path

14.32 Label the Diagram: ACE Shared Context Path

14.33 What’s Next

14.38 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. 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

14.40 Overview Knowledge Check

14.41 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. 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

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

14.44 Practitioner Knowledge Check

14.45 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. 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

14.47 Under-the-Hood Knowledge Check

14.48 Sensing-Planner Complexity and a Practical Heuristic

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 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

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.