11  ACE & Shared Context Sensing

11.1 ACE System and Shared Context Sensing

This section provides a stable anchor for cross-references to the ACE system and shared context sensing across the curriculum.

11.2 Learning Objectives

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

  • Understand Context-Aware Systems: Explain how context information (location, activity, environment) can optimize energy consumption
  • Implement Shared Context Sensing: Design systems that share cached context values across multiple applications
  • Apply Association Rule Mining: Use support and confidence metrics to discover reliable context correlations
  • Design ACE System Components: Understand how inference cache, rule miner, and sensing planner work together
  • Evaluate Cache Trade-offs: Balance cache hit rate against context freshness for optimal performance
In 60 Seconds

The ACE system reduces IoT energy consumption by 60–80% through three cooperating components: an Inference Cache that returns stored context values at zero sensing cost, a Rule Miner that discovers cross-attribute correlations, and a Sensing Planner that finds the cheapest proxy sensing path when cache misses occur.

Key Concepts

  • ACE System (Adaptive Context Engine): IoT energy management architecture combining context prediction, energy forecasting, and adaptive scheduling to achieve 60-80% energy savings.
  • Context Prediction Module: ACE component using historical patterns and current sensor inputs to predict relevant future contexts, enabling proactive sleep scheduling.
  • Energy Forecasting: ACE component estimating energy consumption for different operating modes to select the most energy-efficient option meeting application requirements.
  • Adaptive Scheduler: ACE component using context and energy forecasts to dynamically adjust sensing intervals, sleep duration, and transmission frequency.
  • Cache Hit Rate: Fraction of context lookups answered from cached predictions without re-computation; higher hit rate reduces processor wake-ups and energy consumption.
  • Context Freshness: Relevance of cached context predictions given elapsed time; predictions become stale and must be refreshed as environmental conditions change.
  • Energy Budget Allocation: ACE process distributing available energy across sensing, processing, and communication tasks based on predicted context importance.

11.3 Prerequisites

Before diving into this chapter, you should be familiar with:

“The ACE system is like having a crystal ball for energy management,” said Max the Microcontroller. “It has three parts: an Inference Cache that remembers recent context, a Rule Miner that discovers patterns, and a Sensing Planner that decides the cheapest way to figure out what is happening.”

Sammy the Sensor explained with an example: “The Rule Miner noticed that every weekday at 8 AM, the office motion sensor triggers right after the door sensor. So instead of running both sensors all morning, the system just checks the door sensor first. If the door opened at 8 AM on a Tuesday, it PREDICTS motion without even checking me. That saves my energy!”

“Shared context sensing is even cooler,” said Lila the LED. “If Sammy already measured the temperature, and three other apps also need the temperature, they just read Sammy’s cached value instead of all measuring separately. One measurement, many users!” Bella the Battery celebrated, “The ACE system saves 60 to 80 percent of my energy. Instead of sensing everything all the time, it only senses what is actually needed. Smart!”

11.4 Cross-Hub Connections

Learning Hub Resources for Context-Aware Energy

This chapter connects to multiple learning resources:

Interactive Tools:

  • Simulations Hub - Try the Duty Cycle Calculator and Power Budget Calculator to experiment with energy optimization scenarios
  • Knowledge Gaps Hub - Common misconceptions about battery life and power management

Assessment Resources:

  • Quizzes Hub - Test your understanding of ACE system components and energy calculation methods
  • Videos Hub - Watch demonstrations of context-aware systems in real-world IoT devices

Concept Maps:

  • Knowledge Map - Explore relationships between sensing, power management, and ML inference

11.5 The Challenge of Continuous Monitoring

Imagine your smartphone being smart about when to check for new emails. Instead of checking every minute (draining battery), it learns: “My owner usually checks email at 9 AM, lunch, and 5 PM.” So it checks more often during those times and sleeps the rest of the day. That’s context-aware energy management.

For IoT devices, context means understanding the situation: Are you home or away? Is it day or night? Are you moving or sitting still? Using this information, devices can save massive amounts of battery by only sensing and computing when actually needed.

Real-world example: A fitness tracker doesn’t need to check your heart rate every second when you’re sleeping. By detecting “sleeping” context (nighttime, no movement), it can check every 5 minutes instead of every second—using 300 times less energy!

Block diagram showing ACE system architecture with three main components: applications requesting context at top, inference cache and rule miner in middle providing cached and inferred values, and sensing planner at bottom coordinating actual sensor activation only when needed
Figure 11.1: ACE System Overview: Context-Aware Energy-Saving Solutions
Vertical ladder diagram showing ACE energy optimization strategy. App requests context 'Is user at home?' which flows to Energy Cost Ladder with four rungs tried in order: 1. Cache Lookup at 0 mW (check if answer already stored), 2. Inference from Proxy at ~0.1 mW (Driving=True implies AtHome=False), 3. Low-Power Sensor at ~10 mW (Accelerometer for walking detection), 4. High-Power Sensor at ~100 mW (GPS for exact location). Arrows show progression: Cache miss leads to proxy check, proxy hit leads directly to answer, misses continue down ladder. Result box shows 'User is NOT at home' using inference method at 0.1 mW with 99.9% energy saved. Green colors indicate cheap methods, orange and red indicate expensive methods.
Figure 11.2: Alternative View: Energy Cost Ladder - This diagram shows ACE’s decision process as an energy “ladder” - always starting with the cheapest method (cache lookup at 0 mW) and only climbing to more expensive methods if needed. Most requests are satisfied at the top two rungs (cache hit or proxy inference), saving 99%+ energy compared to always using GPS. The ladder metaphor helps students understand that ACE’s core insight is preferring cheap answers over accurate-but-expensive ones when context hasn’t changed.

The Problem:

  • Apps need continuous sensing to understand and relate the context of the user and trigger actions
  • Monitoring through sensors continuously is expensive battery-wise
  • Duty cycling sensors provides incomplete view of user activity

Solutions:

  1. Share context sensing among multiple apps
  2. Use cached context data
  3. Learn cross-app context correlations
  4. Make intelligent offloading decisions

11.6 Shared Context Sensing

Sequence diagram showing App1 requesting Driving context at 10:00 AM, system senses and caches the result, then App3 requesting same Driving context at 10:05 AM and receiving cached value without sensing, demonstrating cross-app cache sharing
Figure 11.3: Shared Context Sensing: Cross-App Cache Reuse Sequence

Key Idea: At 10:00 AM, App1 asks for “Driving” status. System senses and caches it. At 10:05 AM, App3 asks for “Driving” - cache value is returned, avoiding sensor sampling and saving energy.

11.7 Cross-App Context Correlations

Diagram showing context inference through learned associations: App1 monitors accelerometer for Driving status, App2 needs AtHome status, and system infers AtHome equals false from cached Driving equals true using learned negative correlation rule, avoiding GPS sensing
Figure 11.4: Cross-App Context Correlation: Inferring Context from Cached Attributes

Context Inference: Context can be inferred from “other” features. An app can learn one attribute by the attributes learned for other apps.

Example:

  • App1 monitors accelerometer (walking/driving)
  • App2 uses location sensors (at home/at work)
  • Context History: Driving=true → AtHome=false (negative correlation)
  • When App2 asks for “AtHome” and cache has Driving=true, system returns false without sensing!

Explore how cache hit rate affects energy consumption and battery life:

Key Takeaway: The % hit rate (combining cache hits and inference) extends battery life by × compared to always sensing. Try adjusting the sliders to see how different hit rates and sensor characteristics affect energy savings!

Best Attribute Strategy: Always use the cheapest cached attribute to infer the target value.

Common Misconception: “Higher Cache Hit Rate Is Always Better”

The Misconception: Students often think a 95% cache hit rate is better than 70%, so they increase cache duration to maximize hits.

The Reality: Longer cache duration improves hit rate but reduces accuracy. There’s an optimal balance between energy savings and context freshness.

Quantified Example:

Scenario: Location tracking app requesting “AtHome” status

Short Cache (2 minutes, 70% hit rate):

  • Fresh data: 95% accuracy
  • Energy per request: 0.30 × 100mW (GPS) = 30 mW average
  • User experience: Accurate “arriving home” detection within 2 minutes
  • Battery savings: 70% compared to always-sensing

Long Cache (15 minutes, 95% hit rate):

  • Stale data: 75% accuracy (user moved but cache says “still at work”)
  • Energy per request: 0.05 × 100mW = 5 mW average (better!)
  • User experience: Smart home doesn’t unlock door for 15 minutes after arriving
  • Battery savings: 95% compared to always-sensing

The Trade-off:

  • Energy savings: 95% vs 70% (25% improvement)
  • Accuracy loss: 75% vs 95% (20% degradation)
  • User frustration: High vs Low

ACE’s Solution: Dynamic cache duration based on context volatility: - Stationary context (sleeping, at desk): Long cache (10-15 min) → 92% hit rate, 90% accuracy - Mobile context (driving, walking): Short cache (2-5 min) → 65% hit rate, 94% accuracy - Average: 78% energy savings with 92% average accuracy

Key Insight: Optimize cache duration per attribute type, not globally. GPS location changes slowly when stationary (long cache OK), but accelerometer activity changes rapidly (short cache needed).

11.8 ACE System Architecture

Detailed ACE architecture showing four layers: contexters at bottom performing actual sensing, sensing planner finding cheapest attribute sequence, inference cache providing cached and inferred values, and rule miner learning context correlations from history using association rule mining
Figure 11.5: ACE System Architecture: Inference Cache, Rule Miner, and Sensing Planner

Components:

Contexters: Determine context values with sensors using inference algorithms. Cached sensed values can be shared among contexters instead of redundant sensing.

Rule Miner: Maintains user’s context history and automatically learns relationships among various context attributes using association rule mining.

Inference Cache: Returns a value not only if raw sensor cache has a value, but also if it can be inferred using context rules and cached values of other attributes.

Sensing Planner: Finds the sequence of proxy attributes to speculatively sense to determine target attribute value in the cheapest way.

11.9 Worked Example: Context-Aware Adaptive Duty Cycling

Worked Example: Context-Aware Adaptive Duty Cycling for Smart Building Occupancy Sensor

Scenario: You are deploying 200 occupancy sensors in a commercial office building. The sensors use PIR (passive infrared) motion detection and transmit occupancy status via Zigbee. The goal is to maximize battery life while maintaining accurate occupancy tracking for HVAC optimization.

Given:

  • Sensor: PIR motion detector with digital output
  • MCU: Atmel ATmega328P (0.2 mA/MHz active, 0.1 µA power-down)
  • Radio: Zigbee XBee S2C (45 mA TX, 15 mA RX, 1 µA sleep)
  • Battery: 2x AA lithium primary (3,000 mAh @ 3.0V = 9 Wh)
  • Building hours: 7 AM - 7 PM weekdays (occupied), nights/weekends (unoccupied)
  • Baseline approach: Sample PIR every 5 seconds, transmit on change
  • Target: 5-year battery life with context-aware optimization

Steps:

  1. Analyze baseline (non-context-aware) power consumption:

    PIR sampling (every 5 seconds = 17,280/day):
- MCU wake + PIR read: 1 mA × 1 ms = 1 µAs per sample
- Daily: 17,280 × 1 µAs = 17.28 mAs

Zigbee transmission (assume 50 transitions/day on weekdays):
- TX event: 45 mA × 50 ms + 15 mA × 20 ms = 2.55 mAs per TX
- Daily (weekday): 50 × 2.55 = 127.5 mAs
- Daily (weekend): 5 × 2.55 = 12.75 mAs (minimal activity)

Sleep current (MCU + XBee):
- I_sleep = 0.1 µA + 1 µA = 1.1 µA
- Daily: 1.1 µA × 86,400 s = 95.04 mAs

Total daily average:
Weekday: 17.28 + 127.5 + 95.04 = 239.8 mAs = 0.067 mAh
Weekend: 17.28 + 12.75 + 95.04 = 125.1 mAs = 0.035 mAh
Weekly: (5 × 0.067) + (2 × 0.035) = 0.405 mAh
Annual: 0.405 × 52 = 21.06 mAh

Battery life = 3,000 / 21.06 = 142 years (theoretical, ignoring self-discharge)

  2. Apply context-aware optimizations:

    Optimization 1: Time-based duty cycling
- Occupied hours (7 AM-7 PM weekdays): Sample every 5 seconds
- Unoccupied hours: Sample every 60 seconds

Unoccupied time: 12 hours/day + 48 hours/weekend = 108 hours/week
Occupied time: 60 hours/week

Sampling reduction:
Occupied: 60 h × 720 samples/h = 43,200 samples/week
Unoccupied: 108 h × 60 samples/h = 6,480 samples/week
Total: 49,680 samples/week vs baseline 120,960 samples/week
Reduction: 59% fewer samples

Optimization 2: Event-driven transmission batching
- Instead of transmitting each change, batch 5 changes
- Reduces TX events by 80%

Optimization 3: Predictive occupancy caching
- After 30 days, system learns: "Room 304 empty Mon-Thu after 5 PM"
- Reduce sampling to every 5 minutes when prediction confidence > 90%
- Saves additional 90% of sampling during predictable periods

  3. Calculate context-aware power consumption:

    PIR sampling (49,680/week × 0.41 for prediction savings):
- Weekly samples: 20,369
- Weekly energy: 20,369 × 1 µAs = 20.4 mAs

Zigbee transmission (80% reduction):
- Weekly TX events: (50 × 5 + 5 × 2) × 0.2 = 52 TX/week
- Weekly TX energy: 52 × 2.55 = 132.6 mAs

Sleep current (unchanged):
- Weekly: 1.1 µA × 604,800 s = 665.3 mAs

Total weekly: 20.4 + 132.6 + 665.3 = 818.3 mAs = 0.227 mAh
Annual: 0.227 × 52 = 11.8 mAh
Battery life = 3,000 / 11.8 = 254 years (theoretical)

  4. Apply real-world derating factors:

    Self-discharge: 1-2% per year for lithium primary
After 5 years: ~90% capacity = 2,700 mAh effective

Temperature derating (office environment 20-25°C): None needed

End-of-life voltage (2.4V cutoff): 80% usable capacity
Effective capacity: 2,700 × 0.8 = 2,160 mAh

Realistic battery life = 2,160 / 11.8 = 183 years

With 20× safety factor for real-world variations:
Conservative estimate: 183 / 20 = 9.2 years ✓

  5. Compare baseline vs context-aware:

    | Metric | Baseline | Context-Aware | Improvement |
|--------|----------|---------------|-------------|
| Samples/week | 120,960 | 20,369 | 83% reduction |
| TX events/week | 260 | 52 | 80% reduction |
| Weekly energy | 1.95 mAs | 0.818 mAs | 58% reduction |
| Battery life | 6.5 years | 9.2 years | 42% longer |

Result: Context-aware optimization extends battery life from 6.5 years to 9.2 years (42% improvement) by reducing PIR sampling 83% during predictable unoccupied periods and batching Zigbee transmissions. The occupancy prediction model provides the largest savings by learning building usage patterns over the first 30 days of deployment.

Key Insight: Context-aware energy management is most effective when activity patterns are predictable. Office buildings with regular occupancy schedules are ideal candidates - the system learns “Room 304 is always empty after 5 PM on Thursdays” and dramatically reduces sensing during those periods. For unpredictable environments (e.g., retail stores with varying foot traffic), baseline duty cycling may be more appropriate than complex prediction models.

11.10 Worked Example: Energy-Neutral Solar Harvesting

Design and verify energy-neutral solar systems:

Worked Example: Energy-Neutral Solar Harvesting Design Verification

Scenario: You have designed a solar-powered LoRaWAN air quality sensor for deployment on streetlight poles. Before deployment, you need to verify the design will achieve “energy neutrality” - harvesting more energy than consumed over a complete year, including worst-case winter conditions.

Given:

  • Location: London, UK (51.5°N latitude)
  • Solar panel: 5 cm × 8 cm monocrystalline (40 cm²)
  • Panel efficiency: 18% at STC (Standard Test Conditions)
  • Panel orientation: Vertical on pole, south-facing
  • MPPT charger: BQ25570 (80% end-to-end efficiency)
  • Battery: 100 mAh LiPo (370 mWh @ 3.7V)
  • Sensor: SPS30 PM2.5 sensor (60 mA active, 38 µA idle)
  • MCU: STM32L0 (3.5 mA active @ 32 MHz, 0.29 µA stop mode)
  • LoRa: SX1276 (120 mA TX, 10.5 mA RX, 0.2 µA sleep)
  • Sampling: Hourly PM2.5 measurement (10 second warmup + 1 second sample)
  • Transmission: Hourly LoRa uplink (SF10, 125 kHz)

Steps:

  1. Calculate daily energy consumption:

    PM2.5 sensor (24 cycles/day):
- Warmup: 60 mA × 10 s × 24 = 14,400 mAs = 4.0 mAh
- Sampling: 60 mA × 1 s × 24 = 1,440 mAs = 0.4 mAh
- Idle: 38 µA × 86,400 s = 3,283 mAs = 0.91 mAh
Subtotal: 5.31 mAh @ 5V sensor = 26.6 mWh

MCU (24 active cycles/day):
- Active: 3.5 mA × 2 s × 24 = 168 mAs = 0.047 mAh
- Sleep: 0.29 µA × 86,352 s = 25.04 mAs = 0.007 mAh
Subtotal: 0.054 mAh @ 3.3V = 0.18 mWh

LoRa transmission (24 cycles/day):
- TX: 120 mA × 200 ms × 24 = 576 mAs = 0.16 mAh
- RX windows: 10.5 mA × 1 s × 24 = 252 mAs = 0.07 mAh
- Sleep: 0.2 µA × 86,400 s = 17.28 mAs = 0.005 mAh
Subtotal: 0.235 mAh @ 3.3V = 0.78 mWh

Total daily consumption:
E_consumed = 26.6 + 0.18 + 0.78 = 27.6 mWh/day
Average power: 27.6 mWh / 24 h = 1.15 mW

  2. Calculate solar energy harvest by season:

    Solar irradiance data for London (vertical south-facing):
- Winter (Dec-Feb): 1.2 kWh/m²/day average
- Spring (Mar-May): 3.5 kWh/m²/day average
- Summer (Jun-Aug): 4.8 kWh/m²/day average
- Autumn (Sep-Nov): 2.1 kWh/m²/day average

Panel output calculation:
Panel area: 40 cm² = 0.004 m²
Panel efficiency: 18%
MPPT efficiency: 80%
Net efficiency: 18% × 80% = 14.4%

Winter harvest:
E_winter = 1.2 kWh/m²/day × 0.004 m² × 0.144
E_winter = 0.000691 kWh/day = 0.691 Wh/day = 691 mWh/day

Spring harvest:
E_spring = 3.5 kWh/m²/day × 0.004 m² × 0.144 = 0.00202 kWh/day = 2.02 Wh/day = 2,020 mWh/day

Summer harvest:
E_summer = 4.8 kWh/m²/day × 0.004 m² × 0.144 = 0.00276 kWh/day = 2.76 Wh/day = 2,760 mWh/day

Autumn harvest:
E_autumn = 2.1 kWh/m²/day × 0.004 m² × 0.144 = 0.00121 kWh/day = 1.21 Wh/day = 1,210 mWh/day

  3. Calculate energy balance by season:

    | Season | Harvested | Consumed | Balance | Status |
|--------|-----------|----------|---------|--------|
| Winter | 691 mWh | 27.6 mWh | +663 mWh | SURPLUS |
| Spring | 2,020 mWh | 27.6 mWh | +1,992 mWh | SURPLUS |
| Summer | 2,760 mWh | 27.6 mWh | +2,732 mWh | SURPLUS |
| Autumn | 1,210 mWh | 27.6 mWh | +1,182 mWh | SURPLUS |

✓ SUCCESS: Design IS energy-neutral!

  4. Verify energy neutrality achieved:

    ✓ Current design is already energy-neutral!
Winter surplus: 691 - 27.6 = 663 mWh/day
Summer surplus: 2,760 - 27.6 = 2,732 mWh/day

Battery sizing verification:
- Battery: 100 mAh LiPo @ 3.7V = 370 mWh capacity
- Daily surplus ranges from 663 to 2,732 mWh
- Battery can buffer 370/663 = 0.56 days of worst-case (cloudy winter) deficit
- Continuous operation verified for London climate

Design already meets energy-neutral requirements with excellent margins!
No redesign needed.

  5. Optimize with context-aware sampling for extended range:

    Optional enhancement for even better performance:

Context-aware strategy:
- Standard mode: Sample every 1 hour (24 cycles/day) - current design
- Extended mode: Sample every 4 hours when battery > 80% charged (6 cycles/day)
- Adaptive: Use battery voltage to trigger mode changes

Extended mode consumption (6 cycles/day):
PM2.5: 5.31 mAh × 6/24 = 1.33 mAh @ 5V = 6.65 mWh
MCU: 0.054 mAh × 6/24 = 0.0135 mAh @ 3.3V = 0.045 mWh
LoRa: 0.235 mAh × 6/24 = 0.059 mAh @ 3.3V = 0.19 mWh
Sleep: 0.007 mAh @ 3.3V = 0.023 mWh (unchanged)
Total: 6.91 mWh/day

Extended mode winter surplus:
Harvest: 691 mWh vs Consume: 6.91 mWh = +684 mWh/day (99× surplus!)

Context-aware sampling provides additional safety margin for prolonged cloudy periods.

Result: Initial design verification shows energy-neutral operation achieved (691 mWh/day winter harvest vs 27.6 mWh/day consumption = 25× surplus). The 40 cm² solar panel with 18% efficiency provides sufficient energy even in worst-case London winter conditions. Optional context-aware sampling (reducing from hourly to 4-hour intervals) provides 99× winter surplus for extended autonomy during prolonged cloudy periods.

Key Insight: Energy-neutral design requires analyzing the WORST season, not annual averages. London’s winter solar irradiance is only 25% of summer. Always calculate seasonal energy balance with accurate unit conversions (kWh → Wh → mWh) to verify surplus/deficit. Even small solar panels (40 cm²) can achieve energy neutrality when low-power sensors and LoRaWAN are used. Context-aware sampling provides additional safety margin for high-latitude solar-harvesting IoT.

11.11 Knowledge Check

Test your understanding of ACE system concepts.

11.13 Concept Relationships

The ACE system integrates multiple computer science and engineering concepts:

Machine Learning Foundations:

  • Association Rule Mining (Apriori algorithm): ACE’s Rule Miner uses support and confidence metrics borrowed from data mining
  • Supervised Learning: Historical context data serves as labeled training data for pattern discovery
  • Caching Theory: LRU/LFU replacement policies influence cache design decisions

Distributed Systems:

  • Shared Memory Models: Cross-app context sharing resembles distributed shared memory with cache coherency
  • Pub/Sub Messaging: Applications subscribe to context attributes; ACE publishes updates
  • Consistency vs Availability: ACE trades strong consistency (fresh data) for availability (cached stale data)

Energy Optimization:

  • Dynamic Voltage/Frequency Scaling: ACE complements DVFS by reducing sensor activation frequency
  • Duty Cycling: Association rules enable intelligent variable-interval duty cycling
  • Load Prediction: Context prediction enables proactive power management

Related IoT Concepts:

  • Edge Intelligence: Local inference reduces dependence on cloud processing
  • Sensor Fusion: Combining low-power sensors (accelerometer) to avoid high-power sensors (GPS)
  • Quality of Service: Confidence thresholds balance energy savings against application accuracy requirements

ACE demonstrates how applying data mining principles to energy management creates emergent system-wide benefits that exceed component-level optimizations.

11.14 See Also

Core Prerequisites:

Related Optimization Techniques:

System Architecture:

Practical Applications:

  • Smart Home Use Cases - ACE’s origin: energy-aware mobile and IoT context management
  • Wearables - Fitness trackers use ACE-style caching for battery life

Research Papers:

  • “ACE: Exploiting Correlation for Energy-Efficient and Continuous Context Sensing” (MobiSys 2013)
  • “Association Rule Mining Algorithms for Context Prediction” (Pervasive Computing 2012)

11.15 Try It Yourself

Hands-On Exercise: Build a Minimal ACE System (30 minutes)

Implement a simplified ACE system with cache, rule miner, and sensing planner:

from datetime import datetime, timedelta
import time

class ACESystem:
    def __init__(self):
        self.cache = {}  # Inference Cache
        self.rules = []  # Learned association rules
        self.sensor_costs = {  # Energy cost in mW
            "GPS": 100,
            "Accelerometer": 1,
            "WiFi": 50
        }
        self.total_energy_saved = 0

    # Inference Cache
    def get_cached(self, attribute, max_age_sec=300):
        if attribute in self.cache:
            value, timestamp = self.cache[attribute]
            age = (datetime.now() - timestamp).total_seconds()
            if age < max_age_sec:
                print(f"  [CACHE HIT] {attribute} = {value} (age: {age:.0f}s)")
                return value
        return None

    def update_cache(self, attribute, value):
        self.cache[attribute] = (value, datetime.now())

    # Rule Miner (simplified)
    def add_rule(self, antecedent_attr, antecedent_val, consequent_attr,
                 consequent_val, confidence):
        self.rules.append({
            "ant_attr": antecedent_attr,
            "ant_val": antecedent_val,
            "cons_attr": consequent_attr,
            "cons_val": consequent_val,
            "confidence": confidence
        })

    def infer_from_rules(self, target_attr):
        for rule in self.rules:
            if rule["cons_attr"] == target_attr:
                # Check if antecedent is cached
                cached = self.get_cached(rule["ant_attr"], max_age_sec=600)
                if cached == rule["ant_val"]:
                    print(f"  [INFERENCE] {target_attr} = {rule['cons_val']} "
                          f"(via {rule['ant_attr']}={rule['ant_val']}, "
                          f"confidence {rule['confidence']:.0%})")
                    return rule["cons_val"]
        return None

    # Sensing Planner
    def get_attribute(self, attribute):
        print(f"\n[REQUEST] {attribute}")

        # Step 1: Check cache
        cached = self.get_cached(attribute)
        if cached is not None:
            return cached

        # Step 2: Try inference
        inferred = self.infer_from_rules(attribute)
        if inferred is not None:
            self.update_cache(attribute, inferred)
            return inferred

        # Step 3: Must sense directly
        print(f"  [DIRECT SENSING] {attribute}")
        value = self._sense_attribute(attribute)
        self.update_cache(attribute, value)

        # Track energy cost
        cost = self.sensor_costs.get(attribute, 10)
        print(f"  [ENERGY COST] {cost} mW")

        return value

    def _sense_attribute(self, attribute):
        # Simulate actual sensing (replace with real sensors)
        time.sleep(0.05)
        if attribute == "AtHome":
            return "Yes"  # Simulated GPS result
        elif attribute == "Driving":
            return "No"   # Simulated motion result
        return "Unknown"

# Demo
ace = ACESystem()

# Add learned rule: Driving=No → AtHome=Yes (confidence 85%)
ace.add_rule("Driving", "No", "AtHome", "Yes", 0.85)

# Scenario: Multiple apps request context
print("=== ACE Energy Savings Demo ===\n")

# App1 requests Driving status (must sense)
driving = ace.get_attribute("Driving")

# App2 requests AtHome status 2 seconds later
time.sleep(2)
at_home = ace.get_attribute("AtHome")  # Inferred from Driving!

# App3 requests AtHome again 3 seconds later
time.sleep(3)
at_home2 = ace.get_attribute("AtHome")  # Cache hit!

print("\n=== Summary ===")
print("Without ACE: 3 sensor reads × 100 mW = 300 mW")
print("With ACE: 1 sensor read × 1 mW (Accelerometer) = 1 mW")
print("Energy savings: 99.7%")

What to observe: The second AtHome request uses inference (0 mW), the third uses cache (0 mW). Only the first Driving request actually activates a sensor.

Extension: Add cache expiration, implement support/confidence calculation from observation history, add more complex multi-hop inference rules.

11.16 Summary

The ACE (Adaptive Context-aware Energy-saving) system provides a comprehensive framework for energy optimization:

  1. Shared Context Sensing: Cache context values and share across apps to avoid redundant sensing
  2. Cross-App Correlations: Learn relationships between context attributes to infer values without sensing
  3. Association Rule Mining: Use support and confidence metrics to discover reliable correlations
  4. Inference Cache: Return cached or inferred values with zero energy cost when possible
  5. Sensing Planner: Find the cheapest sequence of proxy attributes when sensing is required

ACE systems typically achieve 60-80% energy savings compared to direct sensing approaches by intelligently combining caching, inference, and selective sensing.

Common Pitfalls

Reusing cached context values for too long causes the system to act on stale information — for example, classifying a room as occupied when everyone has left. Always set TTL based on how rapidly each context attribute changes in your environment, not a one-size-fits-all timer.

Association rules derived from rare events (support < 5%) may appear to have high confidence due to small sample sizes. Require meaningful support thresholds (>10%) before deploying any rule in the inference engine.

The Sensing Planner must evaluate multiple proxy paths to find the cheapest route. If this decision-making computation runs on a high-power processor every cycle, the overhead can negate the savings. Implement the planner on a low-power co-processor or with precomputed lookup tables.

Shared context sensing exposes one app’s context data to all other apps on the device. In privacy-sensitive deployments (healthcare, smart home), enforce access policies so apps only see the context attributes they are authorized to use.

11.17 What’s Next

If you want to… Read this
Learn when to offload computation to the cloud Computation Offloading
Understand full context optimization workflows Context Energy Optimization
Go back to duty cycling fundamentals Duty Cycling Fundamentals
See hardware implementations of energy management Hardware & Software Optimisation
Explore energy harvesting as a power source Energy Harvesting