2 Edge Acquisition: Device Architecture

2.1 Start With the Decision

This section: Start With the Decision — An accelerometer measures acceleration, including the effect of gravity.

An accelerometer measures acceleration, including the effect of gravity. Its stream is a sequence of readings that can overwhelm a small gateway, the device passing them to another network, before any model runs. The sample rate says how often readings are taken. A buffer holds readings briefly; the compute budget limits how much work the device can do. Device choice sets all three limits.

Practitioner Knowledge Check

2.2 Route Overview

This section: Route Overview — This is part 1 of 3.

This is part 1 of 3. Continue with Edge Acquisition: Control Paths and Bandwidth.

2.3 Part Objectives

This section: Part Objectives

• Compare MCU, gateway, and edge-computer acquisition roles.
• Size sampling and buffer needs from device constraints.

2.4 Start With the Story

This section: Start With the Story

2.4.1 Keep the Decision Close Enough to Survive

A conveyor bearing begins to shake. The local controller can stop the machine, while a remote service can compare the change with months of history. If every raw value must travel away before anyone acts, a broken link may turn a useful warning into late evidence. The operations owner must decide what stays near the machine.

Trace one reading from motion to action. Keep the source, event time, unit, quality, and device state with it. Mark the local rule, the summary sent upstream, and the person who may approve a stop. State how much delay is safe and what the local system should do when the remote service is absent.

Then inject poor evidence. Drop samples. Change the event time. Send a value outside the known range. Load the local computer with other work. Disconnect the remote path. Check whether the local rule stays bounded, whether uncertain data is marked, and whether stored records arrive later without losing order or identity.

This split does not prove that all analysis belongs near the machine. Local work has limits in power, memory, context, and upkeep. The deeper sections compare device classes, collection paths, local processing, remote history, and the evidence needed before a local result is allowed to change an operation.

The design record should answer: What must happen now? What can wait? What must stay on site? What history does the remote team need? Which source made the value? How old is it? What marks poor quality? Who may change the local rule? What safe state remains when the link is gone?

Prove the split with matched runs. Use a known good bearing trace. Use a known bad trace. Drop part of each one. Fill local storage. Slow the local task. Restore the remote path. Compare the local action with the later full record. Keep the code version, rule, input, time, and result together. A quick local answer is useful only when its scope and failure state are just as clear.

Place the urgent bearing warning near the device while retaining the trace needed to review a remote summary.

In 60 Seconds

Edge data acquisition is the process of collecting sensor data at the network periphery and deciding what to process locally versus what to send to the cloud. IoT devices fall into three categories — Big Things (servers), Small IP Things (smart cameras), and Non-IP Things (simple sensors needing gateways) — each requiring different acquisition strategies based on their connectivity and processing capabilities.

Phoebe’s Field Notes: What “0.05g Rising to 0.5g” Actually Moves

The mathematical gist. With a stated 20 kHz MEMS resonance, the chapter’s 0.05g baseline moves the proof mass only 31.1 pm and changes a 1 pF differential sense capacitor by 31.1 aF. The 0.5g alert is exactly ten times larger: 311 pm and 311 aF. A typical ±4g, 16-bit output steps by 122 µg/LSB, putting those two readings near codes 410 and 4,096.

Math Bridge · guided foundationsWhat physically moves when a vibration reading rises from 0.05g to 0.5g?Let Data Dora connect acceleration, proof-mass motion, capacitance, and ADC codes. Learn the maths

Chapter Roadmap

• Start With the Story
• In 60 Seconds
• Phoebe’s Field Notes: What “0.05g Rising to 0.5g” Actually Moves
• Quick Check: Edge Data Architecture
• Prerequisites
• Edge Data Acquisition Basics
• Introduction to Edge Data Acquisition
• Key Concepts
• Key Takeaway
• Why Edge Matters
• IoT Device Categories
• Three Categories of Things
• Mobile diagram summary
• Device Characteristics Comparison

2.5 Learning Objectives

This section: Learning Objectives

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

• Classify IoT Data Sources: Distinguish between Big Things, Small IP Things, and Non-IP Things in edge architectures
• Explain Device Connectivity Paths: Describe how different device types connect to cloud infrastructure through direct IP or gateways
• Analyze Data Generation Rates: Calculate data volumes across device categories and assess their implications for edge processing
• Design Data Acquisition Strategies: Select and justify appropriate transmission schedules based on device capabilities and constraints

2.6 Quick Check: Edge Data Architecture

This section: Quick Check: Edge Data Architecture

2.7 Prerequisites

This section: Prerequisites

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

• Edge, Fog, and Cloud Overview: Understanding the three-tier IoT architecture provides context for where edge data acquisition fits
• Sensor Fundamentals: Knowledge of sensor types and characteristics helps understand data acquisition requirements

2.8 Introduction to Edge Data Acquisition

This section: Introduction to Edge Data Acquisition

2.9 IoT Device Categories

This section: IoT Device Categories — The key sources of data in IoT are the ‘Things’ - the physical devices and controllers located on Level 1 of the IoT Reference Model.

The key sources of data in IoT are the ‘Things’ - the physical devices and controllers located on Level 1 of the IoT Reference Model. Things can be accessed directly to send and receive data, however, to be IoT ‘Things’, they must be connected to the Internet.

2.10 Three Categories of Things

This section: Three Categories of Things — The connectivity diagram in Figure 2.1 is the reason to compare device categories here: it shows when a thing can carry an IP path itself and when a gateway must preserve its meaning across a protocol boundary.

The connectivity diagram in Figure 2.1 is the reason to compare device categories here: it shows when a thing can carry an IP path itself and when a gateway must preserve its meaning across a protocol boundary.

+

Read Figure 2.1 from Big Things through Small IP Things to Non-IP Things. Big Things combine compute and direct connectivity; Small IP Things retain an IP path but operate with tighter local resources; Non-IP Things end at a field bus or short-range link and therefore require gateway translation before cloud services can use their data. The different routes, not the physical size of the device, define the categories. This connects the classification to the chapter’s running design path from source capability to acquisition, reduction, and reliable forwarding.

Big Things might be computers and databases. Small IP-enabled Things could include webcams, lights, and smartphones. Non-IP Things may need a Gateway or other device to assist - examples include lights, temperature gauges, locks, and gates.

2.12 Device Characteristics Comparison

This section: Device Characteristics Comparison — Read the Device Characteristics Comparison material as a decision path rather than as isolated entries.

Read the Device Characteristics Comparison 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.

2.13 Continue to the Next Part

This section: Continue to the Next Part — Carry this evidence into Edge Acquisition: Control Paths and Bandwidth, which begins with Cloud and Edge Control Paths.

Carry this evidence into Edge Acquisition: Control Paths and Bandwidth, which begins with Cloud and Edge Control Paths.