13 Edge Processing: Aggregation Decisions
13.1 Start With the Decision
A threshold that saves bandwidth can also erase a short alarm. Test the rule before the edge node groups samples into summaries.
13.2 Route Overview
This is part 2 of 3. Review Edge Processing: Filtering Patterns for the preceding evidence.
13.3 Learning Objectives
- Tune filter thresholds with false-alarm evidence.
- Select an edge aggregation window from latency and bandwidth needs.
13.4 Chapter Roadmap
- Try It: Filter Threshold Simulator
- Pattern 2: Aggregate at Edge
- Putting Numbers to It
- Pattern 3: Infer at Edge
- Try It: Edge ML vs Cloud ML Comparison
- Pattern 4: Store and Forward
- Try It: Store-Forward Buffer Simulator
- Checkpoint: Run the Four Contracts
- Trade-off Analysis
- Edge ML Inference vs Cloud ML Inference
- Edge ML vs Cloud ML Inference
- Batch Processing vs Real-Time Streaming
- Batch vs Streaming at Edge
- When Edge Saves Money
- Edge Does Not Always Save Cost
- Edge vs Cloud Breakeven Calculator
- Checkpoint: Price the Trade-off
- Danfoss Refrigeration Edge
- Checkpoint: Validate the Fleet Mix
- Interactive Quiz: Match Concepts
- Interactive Quiz: Sequence the Steps
- Label the Diagram
- Continue: Edge Stream Window Contracts
Aggregation should reduce traffic without erasing the field story. Figure 13.1 follows soil, air, and leaf readings through alignment, combination, outage buffering, and an irrigation decision.
At ALIGN, Figure 13.1 allows at most 2 s clock skew inside the 60 s event window; COMBINE takes the median of redundant probes and retains quality flag Q1. When BUFFER stores 1,080 rows during the 18-minute outage, ordered replay and the raw-lineage link keep aggregation from silently changing the irrigation evidence.
13.5 Pattern 2: Aggregate at Edge
The aggregate pattern computes statistics locally and sends summaries:
# Example: Statistical aggregation
import statistics
def aggregate_window(readings, window_minutes=60):
return {
"min": min(readings),
"max": max(readings),
"avg": sum(readings) / len(readings),
"stddev": statistics.stdev(readings),
"count": len(readings),
"window_end": now()
}
Consider 200 temperature sensors sampling at 1 Hz:
Without aggregation (transmit every reading):
With 1-hour aggregation (transmit min/max/avg/stddev every hour):
Reduction ratio:
Aggregation compresses 3,600 readings into 4 statistical values, achieving near-perfect bandwidth savings while preserving trend information for analytics.
Best for:
- Trend analysis where individual readings are less important than patterns
- Environmental monitoring (temperature, humidity, air quality)
- Capacity planning and historical analysis
13.6 Pattern 3: Infer at Edge
The infer pattern runs machine learning models locally:
# Example: Anomaly detection at edge
model = load_tflite_model("anomaly_detector.tflite")
def infer_anomaly(sensor_data):
prediction = model.predict(sensor_data)
if prediction["anomaly_score"] > 0.85:
return {"anomaly": True, "score": prediction["anomaly_score"],
"features": sensor_data}
return None # Normal - don't transmit
Best for:
- Visual inspection (defect detection in manufacturing)
- Predictive maintenance (vibration analysis)
- Safety systems requiring immediate response
13.7 Pattern 4: Store and Forward
Read the Pattern 4: Store and Forward material as a decision path rather than as isolated entries. First identify the operating condition in each entry and keep its units, timing, source, and assumed system state attached to it. Next compare the entries at the point where responsibility changes between device, gateway, network, analytic service, and operator; that hand-off is where apparently similar choices often produce different outcomes. Then follow the failure case: ask what becomes stale, delayed, unavailable, or unsafe, who detects it, and what evidence permits recovery. Finally connect the result to the chapter’s running design record by naming the selected behavior, the rejected alternative, the measurement that justifies the choice, and the condition that forces a recheck. That order turns the examples or comparison into an auditable engineering argument.
The store-and-forward pattern handles intermittent connectivity:
# Example: Store-and-forward buffer
class EdgeBuffer:
def __init__(self, max_size_mb=100):
self.buffer = []
self.max_size = max_size_mb * 1024 * 1024
def store(self, reading):
self.buffer.append(reading)
self.compact_if_needed()
def forward_when_connected(self):
if network_available():
batch = self.buffer.copy()
if upload_batch(batch):
self.buffer.clear()
Best for:
- Remote sites (oil rigs, agricultural fields, offshore platforms)
- Mobile assets (vehicles, shipping containers, drones)
- Any deployment with unreliable connectivity
Checkpoint: Run the Four Contracts
- A threshold filter sends exceptions and discards routine readings.
- A windowed aggregate compresses many samples into min, max, avg, stddev, count, and window metadata.
- An inference step sends anomaly evidence, while Store-Forward keeps buffered readings until the network returns.
Next, decide which trade-off the deployment can defend when latency, accuracy, power, connectivity, and cost conflict.
13.8 Trade-off Analysis
13.9 Edge ML Inference vs Cloud ML Inference
Option A (Edge ML): Deploy 2-10 MB quantized models on gateways (TensorFlow Lite, ONNX Runtime), achieving 10-50 ms inference latency with 85-92% accuracy for classification tasks on Cortex-M4/ESP32 class devices.
Option B (Cloud ML): Run 100 MB - 1 GB full-precision models in cloud (TensorFlow Serving, AWS SageMaker), achieving 200-500 ms round-trip latency with 95-99% accuracy using GPUs for complex pattern recognition.
Decision Factors: Choose edge ML when latency requirements are under 100 ms (safety systems, real-time control), privacy mandates data cannot leave premises (healthcare, industrial IP), or connectivity is unreliable (remote assets, mobile equipment). Choose cloud ML when model complexity requires GPU acceleration (video analytics, NLP), training data continuously improves models (recommendation systems), or centralized management simplifies updates. Hybrid architectures run simple detection at edge (anomaly flags, threshold checks) while cloud handles deep analysis (root cause diagnosis, long-term forecasting). A factory safety system needs 20 ms edge response, but weekly predictive maintenance reports can use cloud-trained models updated monthly.
13.10 Batch Processing vs Real-Time Streaming
Option A (Batch Processing): Collect sensor data locally for 1-60 minutes, process in batches, upload aggregated results. Reduces compute cycles by 80-95%, extends battery life 3-5x on constrained devices, but introduces 1-60 minute detection latency.
Option B (Real-Time Streaming): Process each sensor reading immediately as it arrives with sub-second latency. Enables instant anomaly detection and immediate control responses, but requires 5-10x more edge compute power and continuous network connectivity for cloud integration.
Decision Factors: Choose batch processing for delay-tolerant analytics (hourly environmental reports, daily asset utilization), bandwidth-constrained links (satellite, cellular metered), and battery-powered devices where duty cycling extends deployment life from weeks to years. Choose real-time streaming for safety-critical monitoring (gas leaks, machine failures requiring less than 1 s response), control systems with tight feedback loops (HVAC, robotics), and applications where stale data has no value (live tracking, interactive systems). A smart meter can batch hourly readings, but a pipeline pressure sensor must stream in real-time to detect ruptures within seconds.
13.11 When Edge Saves Money
The Myth: “Processing at the edge always saves money compared to cloud processing.”
The Reality: Edge computing reduces bandwidth costs but introduces hardware and maintenance costs that can exceed cloud savings in many scenarios.
Real-World Example: Agricultural Soil Monitoring
A precision agriculture company deployed 10,000 soil moisture sensors across 5,000 acres:
Cloud-Only Approach (Initial Design):
- 10,000 sensors x 1 reading/hour x 24 hours x 30 days = 7.2M readings/month
- Data size: 7.2M readings x 50 bytes = 360 MiB/month
- Cloud egress cost: 360 MiB / 1,024 MiB/GiB x $0.09/GB = $0.03/month
- Cloud compute/storage: ~$50/month
- Total: ~$50/month
Edge Gateway Approach (Actual Deployment):
- 50 edge gateways ($200 each): $10,000 upfront capital
- Edge aggregation reduces cloud traffic by 90%: 36 MB/month
- Cloud costs: $5/month (minimal compute)
- Gateway maintenance: $100/month (cellular data, power, repairs)
- Amortized gateway cost over 3 years: $278/month
- Total: $383/month
The Hidden Costs:
- Hardware depreciation: $10,000 / 36 months = $278/month
- Cellular connectivity: 50 gateways x $2/month = $100/month
- Maintenance visits: 1 failed gateway/month x $150/visit = $150/month (later reduced with better hardware)
- Software updates: Edge devices require OTA update infrastructure
When Edge Actually Saved Money (Year 2): After initial deployment issues were resolved and maintenance costs dropped to $50/month:
- Edge total: $278 (amortized) + $100 (cellular) + $50 (maintenance) + $5 (cloud) = $433/month
- Cloud total: $50/month
Edge remained more expensive until the company expanded to 100,000 sensors in Year 3. At that scale, cloud compute costs grew to ~$500/month while edge gateways were already provisioned with spare capacity, making the per-sensor cost of edge processing lower than cloud.
Key Takeaway: Edge computing provides the greatest cost savings when:
- High data volumes overwhelm bandwidth costs (>10 GB/month)
- Hardware is amortized over multi-year deployments
- Maintenance is minimal (reliable hardware, remote updates)
- Latency/privacy requirements justify the investment regardless of cost
Decision Framework:
- Small deployments (<1,000 sensors, <1 GB/month): Cloud is usually cheaper
- Medium deployments (1,000-10,000 sensors): Hybrid (edge aggregation + cloud) often optimal
- Large deployments (>10,000 sensors, >10 GB/month): Edge pays for itself within 6-12 months
Checkpoint: Price the Trade-off
- Edge ML is attractive for 10-50 ms decisions, while cloud ML often pays a 200-500 ms round trip.
- Batch processing can reduce compute cycles by 80-95%, but it introduces 1-60 minute detection latency.
- Cost savings need enough volume: the chapter’s decision framework separates small deployments, medium deployments, and large deployments above 10,000 sensors or 10 GB/month.
Those trade-offs are clearest in a fleet where each stream can choose its own pattern.
13.12 Danfoss Refrigeration Edge
Scenario: Danfoss, a Danish climate technology company, manages refrigeration controllers in 40,000 European supermarkets. Each store has 12 display cases with 3 sensors each (temperature, defrost status, compressor current), reporting every 30 seconds.
Given:
- 40,000 stores x 12 cases x 3 sensors = 1,440,000 sensors
- 30-second intervals = 86,400 s / 30 s = 2,880 readings/sensor/day
- Raw payload: 8 bytes per reading (timestamp + value)
- Cellular backhaul at EUR 0.50/MB
Step 1: Calculate raw data volume
| Metric | Value |
|---|---|
| Daily readings (total) | 1,440,000 x 2,880 = 4.15 billion |
| Daily raw data | 4.15 x 10^9 x 8 bytes = 33.2 GB |
| Daily cellular cost | 33,200 MB x EUR 0.50/MB = EUR 16,600 |
Step 2: Apply edge patterns per sensor type
| Sensor | Pattern | Logic | Reduction |
|---|---|---|---|
| Temperature | Filter | Transmit only if outside -22 to -18 C (freezer) or 2 to 4 C (chiller) | 97% (normal 97% of time) |
| Defrost status | Filter | Transmit only on state change (start/stop) | 99.5% (2 events/day vs 2,880) |
| Compressor current | Aggregate | Transmit 5-minute RMS + peak | 90% (10 summaries/hour vs 120 raw) |
Step 3: Calculate optimized volumes
Each sensor type accounts for one-third of the 1,440,000 sensors (480,000 sensors each):
| Metric | Raw | After Edge | Savings |
|---|---|---|---|
| Temperature data/day | 11.1 GB | 333 MB | 97% |
| Defrost data/day | 11.1 GB | 55 MB | 99.5% |
| Compressor data/day | 11.1 GB | 1.1 GB | 90% |
| Total daily | 33.2 GB | 1.49 GB | 95.5% |
| Cellular cost/day | EUR 16,600 | EUR 745 | EUR 15,855 saved |
Result: Edge processing reduces daily cellular costs from EUR 16,600 to EUR 745 — a 95.5% reduction. The fleet-wide gateway investment (40,000 gateways x EUR 120 = EUR 4.8 million) recovers in about 10 months through cellular savings of EUR 15,855 per day.
Key Insight: The three sensor types in the same deployment use three different edge patterns. Temperature uses Filter (only exceptions matter), defrost uses Filter (only state changes matter), and compressor current uses Aggregate (trend data matters). Pattern selection is per-sensor, not per-deployment.
Checkpoint: Validate the Fleet Mix
- The Danfoss case starts with 40,000 stores, 12 display cases per store, and 3 sensors per case.
- The raw daily total is 33.2 GB, and the mixed edge plan reduces it to 1.49 GB.
- The same calculation drops daily cellular cost from EUR 16,600 to EUR 745, but only because each sensor type gets the pattern that matches its evidence need.
13.13 Continue: Edge Stream Window Contracts
The four processing patterns above still need precise stream semantics before a gateway emits reliable metrics. Continue to Edge Stream Window Contracts for tumbling, sliding, and session window rules, state budgets, late-event policy, and replay metadata.
The level map in Figure 13.2 locates the processing patterns in this chapter between bit transport and durable storage.
In Figure 13.2, Transform near the source names the Level 3 work: filter noise, normalize units, detect thresholds, and retain provenance. Its output then reaches Turn streams into queryable records at Level 4, preventing filter, aggregate, and infer patterns from being confused with the storage system that retains their results.
13.14 Continue to the Next Part
Carry this evidence into Edge Processing: Stream Window Contracts, which begins with Edge Stream Window Contracts.
