4 Edge Acquisition: Power Budgets and Pipelines

4.1 Start With the Decision

A fast edge pipeline is useless when its node drains before service day. Power, window size, and model work must fit one budget.

4.2 Route Overview

This is part 3 of 3. Review Edge Acquisition: Control Paths and Bandwidth for the preceding evidence.

4.3 Learning Objectives

• Build a power budget for an edge acquisition node.
• Design an IMU aggregation pipeline from energy and latency limits.

4.4 Chapter Roadmap

• Power Budget Decision Framework
• Power Budget Decision Tree
• IMU Edge Aggregation Pipeline
• Checkpoint: Data Volume and Aggregation
• Knowledge Check
• Quiz: Device Categories
• Fonterra Edge Acquisition
• Edge Processing Savings Calculator
• Checkpoint: Gateway Economics
• Interactive Quiz: Match Concepts
• Interactive Quiz: Sequence the Steps
• Common Pitfalls
• Edge Acquisition Storage Tiers
• Use Sensor Interrupts
• Define the Data Budget First
• Plan Timestamp Accuracy
• 4. Not Designing for Sensor Hot-Swapping
• Checkpoint: Operational Contracts
• Label the Diagram
• Acquisition Timing and Buffers
• Summary
• Concept Relationships
• What’s Next

4.5 Power Budget Decision Framework

Device capabilities directly impact acquisition strategies. The key decision point is power source:

• Mains-powered devices (factory equipment, building systems): Can sample continuously and transmit frequently — edge processing focuses on bandwidth reduction, not power savings
• Battery-powered devices (field sensors, wearables): Must duty-cycle both sampling and transmission — edge processing is essential to extend battery life from days to years
• Energy-harvesting devices (solar-powered nodes): Operate with variable power budgets — edge processing must adapt to available energy

Power Budget Decision Tree

The decision tree in Figure 4.1 visualizes how to select the optimal duty cycle based on power constraints:

Trace Figure 4.1 from the power source. Mains power permits continuous acquisition while edge work primarily controls bandwidth; a battery branch makes wake time and radio duty cycle explicit; harvesting adds a variable energy budget that must adapt sampling and transmission. The branches show why the same sensor workload needs different scheduling evidence in different deployments. This continues the running narrative from data volume to feasibility: acquisition policy must fit both the information required and the energy that can sustain it.

4.6 IMU Edge Aggregation Pipeline

This Python example demonstrates edge aggregation for the inertial measurement use case discussed above. A 100 Hz IMU produces 600 samples/second across 6 axes. Transmitting raw data is unsustainable, so the edge pipeline computes 1 Hz statistical summaries (RMS and peak per accelerometer axis, RMS per gyroscope axis), reducing bandwidth by ~67x:

import math
import time

class IMUEdgeAggregator:
    """Aggregate high-frequency IMU data into 1 Hz statistical summaries.

    Reduces 600 samples/second (100 Hz x 6 axes) to 9 summary values
    per second, cutting transmission from 1200 bytes/s to 18 bytes/s
    (67x reduction).
    """
    def __init__(self, sample_rate_hz=100, window_sec=1):
        self.sample_rate = sample_rate_hz
        self.window_size = sample_rate_hz * window_sec
        self.buffer_accel = {"x": [], "y": [], "z": []}
        self.buffer_gyro = {"x": [], "y": [], "z": []}

    def add_sample(self, ax, ay, az, gx, gy, gz):
        """Add one raw IMU sample (called at 100 Hz)."""
        self.buffer_accel["x"].append(ax)
        self.buffer_accel["y"].append(ay)
        self.buffer_accel["z"].append(az)
        self.buffer_gyro["x"].append(gx)
        self.buffer_gyro["y"].append(gy)
        self.buffer_gyro["z"].append(gz)

    def _rms(self, values):
        """Root mean square -- captures vibration energy."""
        if not values:
            return 0.0
        return math.sqrt(sum(v * v for v in values) / len(values))

    def _peak(self, values):
        """Peak absolute value -- detects impacts."""
        if not values:
            return 0.0
        return max(abs(v) for v in values)

    def window_ready(self):
        """Check if enough samples collected for one summary."""
        return len(self.buffer_accel["x"]) >= self.window_size

    def compute_summary(self):
        """Compute 1 Hz summary from buffered samples.

        Returns dict with RMS and peak for each axis -- enough
        to detect vibration anomalies without raw data.
        """
        summary = {"timestamp": int(time.time()), "samples": self.window_size}
        for axis in ["x", "y", "z"]:
            accel = self.buffer_accel[axis][:self.window_size]
            gyro = self.buffer_gyro[axis][:self.window_size]
            summary[f"accel_{axis}_rms"] = round(self._rms(accel), 4)
            summary[f"accel_{axis}_peak"] = round(self._peak(accel), 4)
            summary[f"gyro_{axis}_rms"] = round(self._rms(gyro), 2)

        # Clear processed samples
        for axis in ["x", "y", "z"]:
            self.buffer_accel[axis] = self.buffer_accel[axis][self.window_size:]
            self.buffer_gyro[axis] = self.buffer_gyro[axis][self.window_size:]
        return summary

    def estimate_bandwidth(self):
        """Compare raw vs aggregated data rates."""
        raw_bytes_per_sec = self.sample_rate * 6 * 2  # 6 axes, 2 bytes each
        summary_bytes = 9 * 2  # 9 summary values, 2 bytes each
        ratio = raw_bytes_per_sec / summary_bytes
        return {
            "raw_bytes_per_sec": raw_bytes_per_sec,
            "summary_bytes_per_sec": summary_bytes,
            "reduction_ratio": f"{ratio:.0f}x",
        }

# Simulate: factory motor vibration monitoring
agg = IMUEdgeAggregator(sample_rate_hz=100, window_sec=1)

# Feed 100 simulated samples (1 second of data)
import random
for i in range(100):
    # Normal vibration: small accelerations around 0g with noise
    agg.add_sample(
        ax=random.gauss(0, 0.05), ay=random.gauss(0, 0.05),
        az=random.gauss(1.0, 0.03),  # 1g gravity on Z
        gx=random.gauss(0, 2), gy=random.gauss(0, 2),
        gz=random.gauss(0, 1)
    )

if agg.window_ready():
    summary = agg.compute_summary()
    print("1-second summary (transmitted via LoRa):")
    for key, val in summary.items():
        print(f"  {key}: {val}")

bw = agg.estimate_bandwidth()
print(f"\nBandwidth: {bw['raw_bytes_per_sec']} B/s raw -> "
      f"{bw['summary_bytes_per_sec']} B/s summary = "
      f"{bw['reduction_ratio']} reduction")
# Output:
# 1-second summary (transmitted via LoRa):
#   timestamp: 1738900000
#   samples: 100
#   accel_x_rms: 0.0498
#   accel_x_peak: 0.1523
#   accel_y_rms: 0.0512
#   accel_y_peak: 0.1389
#   accel_z_rms: 1.0004
#   accel_z_peak: 1.0891
#   gyro_x_rms: 1.98
#   gyro_y_rms: 2.05
#   gyro_z_rms: 0.99
#
# Bandwidth: 1200 B/s raw -> 18 B/s summary = 67x reduction

The edge device transmits only RMS (vibration energy) and peak (impact detection) values at 1 Hz instead of raw waveforms at 100 Hz. A sudden increase in accel_x_rms from 0.05g to 0.5g flags a developing bearing fault without requiring cloud-side waveform analysis.

Checkpoint: Data Volume and Aggregation

You now know:

• A 10 Hz sensor can become 17 MB/day and 6.3 GB/year, so fleet scale turns small samples into a storage budget.
• A 100 Hz, 6-axis IMU creates 600 samples/second, or about 1.2 KB/s before local aggregation.
• Summarising to 1 Hz cuts the IMU stream from 1200 B/s to 18 B/s, a 67x reduction, before any cloud upload.

Those rates only work if the device has enough energy and link budget.

4.7 Knowledge Check

4.8 Quiz: Device Categories

4.9 Fonterra Edge Acquisition

Scenario: Fonterra, New Zealand’s largest dairy cooperative, deploys IoT sensors across 200 milking sheds to monitor milk quality and cow health in real-time. Each shed has a mix of device categories requiring different acquisition strategies.

Given:

• 200 sheds, each with the following devices

  • 1 SCADA controller (Big Thing) — monitors vat temperature, logs milk volume
  • 8 IP cameras (Small IP Things) — 1080p at 15 fps for mastitis detection via udder imaging
  • 40 Non-IP sensors per shed: 20 milk flow meters (Modbus RTU), 10 temperature probes (4-20 mA), 10 cow ID readers (RFID 134.2 kHz)

• Rural connectivity: 4G LTE at NZD 12/GB, typical 15 Mbps downlink / 5 Mbps uplink

• Power: Mains-powered shed, solar-powered paddock sensors

Step 1: Classify devices and estimate raw data

Step 2: Design acquisition strategy per category

Step 3: Calculate connectivity costs

4.10 Edge Processing Savings Calculator

Adjust the parameters below to see how edge processing affects connectivity costs for a multi-shed IoT deployment. The dominant cost driver is typically the highest-bandwidth device (cameras).

Result: A single Raspberry Pi 4 gateway (NZD 900 with edge ML accelerator) per shed handles all three device categories: protocol translation for Non-IP sensors, video analytics for IP cameras, and pass-through for the SCADA controller. The 99% data reduction makes rural 4G connectivity economically viable.

Key Insight: The three device categories in Fonterra’s deployment map directly to three gateway functions: Big Things need routing (IP to IP), Small IP Things need edge inference (reduce high-bandwidth streams), and Non-IP Things need protocol translation (Modbus/4-20 mA/RFID to MQTT). A single edge gateway serves all three roles, and the dominant cost driver is always the highest-bandwidth device category (cameras, in this case).

4.11 Interactive Quiz: Match Concepts

4.12 Interactive Quiz: Sequence the Steps

4.13 Label the Diagram

4.14 Acquisition Timing and Buffers

For the deeper implementation contract behind source timestamps, clock synchronisation, bounded buffers, backpressure, drift, and replay metadata, continue to Acquisition Timing and Buffer Contracts.

The split acquisition architecture in Figure 4.2 shows why device count and consequence produce different evidence contracts even when the layer names match.

Compare Many quiet devices with Few urgent control loops in Figure 4.2. The massive branch moves through Capacity + coverage first to Compress and batch; the critical branch moves through Latency + resilience first to Decide and prove locally, so one generic acquisition policy cannot satisfy both.

4.15 Summary

Edge data acquisition architecture is built on understanding three fundamental device categories:

• Big Things: Full-capability computers with direct cloud connectivity - minimal edge processing needed
• Small IP Things: Embedded devices with IP connectivity - benefit from edge compression and filtering
• Non-IP Things: Simple sensors requiring gateways - need edge aggregation for efficient transmission

The acquisition strategy must match device capabilities: high-volume devices (cameras) need compression, low-volume devices (temperature sensors) need aggregation, and non-IP devices need protocol translation through gateways.

4.16 Concept Relationships

This chapter establishes the foundational architecture for edge data collection:

Core Classification (This chapter):

• Three device categories (Big Things, Small IP Things, Non-IP Things) determine connectivity paths and acquisition strategies
• Data generation patterns vary 1000x across categories (door sensors: bytes/day vs cameras: gigabytes/day)

Technical Implementation (Apply this foundation):

• Edge Data Acquisition: Sampling and Compression - How to reduce data volume based on device category (cameras need compression, temperature sensors need aggregation)
• Edge Data Acquisition: Power and Gateways - Battery constraints drive duty cycling; gateways bridge Non-IP Things to cloud

Processing Context:

• Edge Compute Patterns - Where to process (edge/fog/cloud) depends on device capabilities established here
• Edge Fog Computing - Big Things can participate in fog layer; Small/Non-IP Things need edge gateways

Data Quality Integration:

• Data Quality and Preprocessing - Edge acquisition is where validation catches errors at 1% cost vs cloud fixes
• Multi-Sensor Data Fusion - Fusing data from different device categories requires understanding their generation patterns

4.17 What’s Next

4.18 Continue Your Route

This final part closes the route from Power Budget Decision Framework through What’s Next. Return to Edge Acquisition: Control Paths and Bandwidth or continue from the analytics-ml module index.