10 ACE and Shared Context Sensing
Inference Cache, Rule Miner, Sensing Planner, and Evidence Gates
10.1 Start With One Shared Fact
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 Why
Every “full occupancy sense” this chapter prices out has a sensor behind it, and the classic cheap occupancy sensor – pyroelectric PIR – does not measure temperature at all. Its crystal generates a surface charge only while temperature is changing, which is exactly why a body has to move across the Fresnel-lens zones to be seen and why a stationary warm object goes electrically silent. That “rate, not level” behavior is also why the sensor cannot be read instantly: the charge amplifier’s own filter needs a few time constants to settle before the output means anything. The settle time in this chapter’s energy ledger is not an arbitrary firmware delay – it is that filter’s physics.
The Derivation
A pyroelectric element’s surface charge tracks temperature change, not temperature itself:
\[Q = p\,A\,\Delta T \qquad i(t) = p\,A\,\frac{dT}{dt}\]
where \(p\) is the material’s pyroelectric coefficient and \(A\) the electrode area – this is the governing equation an occupancy reading inverts: a current above threshold means “something warm is moving,” nothing more.
The charge amplifier’s first-order RC filter sets how long the output takes to settle:
\[\tau = \frac{1}{2\pi f_c}\]
A standard rule of thumb treats three time constants as effectively settled:
\[t_{settle} \approx 3\tau\]
Worked Numbers: This Chapter’s Occupancy Sense
Recomputing the chapter’s own ledger: \(E_{mcu} = 8 \times 0.030 = 0.24\) mA-s, \(E_{sensor} = 2 \times 0.050 = 0.10\) mA-s, so \(E_{sense} = 0.24 + 0.10 = 0.34\) mA-s – matching the chapter exactly.
The chapter does not derive where the 50 ms settle time comes from, so check it against standard PIR filter values: a typical pyroelectric amplifier’s upper corner sits near \(f_c = 10\) Hz (matched to walking-speed crossings of the lens zones), giving
\[\tau = \frac{1}{2\pi(10)} = 0.0159\ \mathrm{s} = 15.9\ \mathrm{ms}, \qquad 3\tau = 47.7\ \mathrm{ms}\]
– close to the chapter’s 50 ms figure, not forced to match, which is what a settle time set by real filter physics should look like. For scale, a standard LiTaO\(_3\) element (\(p \approx 200\ \mu\mathrm{C/m^2K}\), \(A \approx 2\ \mathrm{mm}^2\)) crossed by a body producing an effective 4 K modulation over a 0.1 s crossing yields \(i = pA(dT/dt) = 200\times10^{-6} \times 2\times10^{-6} \times 40 = 16.0\) nA – a tiny signal, which is why the sensor needs that settled, filtered 50 ms window rather than a raw instantaneous sample.
10.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.
10.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.
- A context value needs a value, timestamp, source, TTL, confidence, and owner.
- Cache reuse across apps is safe only while freshness and access rules hold.
- Rule inference should be gated by consequence, not only by energy savings.
- Sensing planners should try cheaper proxy attributes before expensive target sensing when that proxy is reliable enough.
- Every accepted shortcut needs validation evidence: saved activations, miss rate, latency, retries, and fallback count.
10.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.
10.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.
10.5.1 Context broker
Receives app requests such as AtHome, Walking, RoomOccupied, or GatewayReachable. It applies access control and routes the request to cache, inference, or sensing.
10.5.2 Inference cache
Stores recent context values with metadata. The cache can answer a request only if the value is fresh enough and trusted enough for the requesting decision.
10.5.3 Rule miner
Learns associations from context history, such as Driving = true implying AtHome = false. It records support and confidence so rules can be filtered.
10.5.4 Sensing planner
Chooses the cheapest acceptable sensing path. It may try a low-power proxy before activating a high-power target sensor.
10.6 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.
Field
Example
Review question
Value
Walking = true
Is this the target attribute or an intermediate proxy?
Timestamp and TTL
21:40:00, valid for 120 seconds
Is the value still fresh enough for the requesting app?
Source
Accelerometer contexter, cached from App A
Can the requesting app trust this source?
Confidence
0.93 from classifier or rule
Is the confidence high enough for the consequence of being wrong?
Fallback
Use direct sensing if stale or below threshold
Does the system have a reliable recovery path?
10.7 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.
Support gate Reject rules that appear too rarely to validate. A rule observed twice in a month should not control an energy policy without more evidence.
Confidence gate Require higher confidence when the wrong inference can cause a missed event, lockout, safety issue, billing error, or service failure.
Freshness gate Apply the rule only if the antecedent context value is still fresh. An old Driving = true value should not infer current location.
Fallback gate Every rule needs a direct sensing or conservative fallback when confidence drops, the context changes, or validation detects drift.
10.8 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.
Plan option
When it fits
Main risk
Reuse cache
Value is fresh, trusted, and allowed for this consumer.
Stale context can silently make the wrong policy look cheap.
Infer from proxy
Rule confidence clears the threshold and the proxy is cheaper than target sensing.
The proxy may drift when user behavior or deployment patterns change.
Sense a proxy
A low-power sensor can update a rule antecedent before using an expensive target sensor.
Proxy sensing can become wasted work if the proxy is weak.
Sense target
Cache and inference fail, or the decision needs direct evidence.
Highest energy cost, but often the correct reliability fallback.
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.
10.9 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.91Review
- 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.
10.10 Evidence Record
For each promoted ACE rule or shared context cache, keep a compact review record:
- Attribute: target context value, such as
RoomOccupied. - Consumers: apps or services allowed to reuse it.
- Source: sensor, contexter, classifier, or rule.
- Freshness: TTL, age at use, and expiry behavior.
- Confidence: rule confidence or classifier confidence.
- Fallback: direct sensor, conservative policy, or reject path.
- Outcome: saved activations, direct sensing count, miss rate, latency, and retries.
10.11 Common Pitfalls
10.11.1 Calling every prediction ACE
ACE is specifically about acquisition: avoiding unnecessary context acquisition while preserving evidence quality.
10.11.3 One TTL for all context
Location, motion, occupancy, light, and network reachability change at different rates. Each needs its own freshness policy.
10.11.4 Confidence without consequence
A 0.75 rule may be fine for a dashboard summary and unacceptable for an access, safety, or alarm decision.
10.11.6 No drift monitoring
Rules learned during normal weeks can fail during holidays, maintenance, outages, storms, or changed building schedules.
10.13 Check Your Understanding
10.15 Knowledge Check: Rule Threshold
10.16 Matching Quiz: ACE Component Responsibilities
10.17 Ordering Quiz: ACE Request Path
10.19 What’s Next
10.19.1 Baseline Duty Cycle
Compare ACE shortcuts against a fixed duty-cycle baseline.
10.19.2 Place Computation
Code Offloading and Heterogeneous Computing
Use the same evidence-gated thinking for local versus remote computation.
10.19.3 Practice Review
Energy Optimization Worksheets and Assessment
Apply support, confidence, TTL, and fallback review to practice scenarios.
10.19.4 Measure The Saving
Measure whether reduced sensing actually lowers average current in the device.
10.20 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.
Intuition only: the savings scale with the cache hit rate and with how many readers share one sensing operation. If ten subsystems reuse a single occupancy reading, they split its cost ten ways instead of paying ten times.
Where The Energy Goes
Full sense
Wake, power the sensor, wait for settling, sample, and classify. This is the expensive path a cache tries to avoid.
Cache hit
Return a still-fresh cached context with a lookup. Orders of magnitude cheaper than a fresh sense.
Correlation
Infer an expensive context from a cheap one using a learned rule, skipping the costly sensor entirely.
Freshness
A validity window decides how long a cached value may be reused before it must be sensed again.
Overview Knowledge Check
10.21 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.
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.
Cache Energy Ledger
Practitioner Knowledge Check
10.22 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.
Design Tensions
Window too short
Frequent misses collapse the hit rate. The cache pays lookup overhead without avoiding many senses.
Window too long
Stale context leaks into decisions. A wrong actuation can waste far more energy than the sense it avoided.
Correlation drift
A rule that held during training can break. A stale "stationary implies same place" rule can hide real movement.
First-reader cost
Every miss still pays the full sense to repopulate the cache, so miss-heavy workloads keep the expensive path hot.
Under-the-Hood Knowledge Check
10.23 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.
10.24 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.