3.5 Edge Computing Nodes
3.5.1 Edge Computing Node Hardware and Deployment
"Where should computing power live?" IoT architects run into this question again and again when designing the sensing layer. Pushing every sensor's data up to the cloud for processing often overruns network bandwidth and real-time deadlines. A vibration sensor produces thousands of readings per second, yet the large-amplitude changes that actually matter may last only tens of milliseconds. The role of the edge computing node is to provide first-stage processing near the data source — filtering, aggregation, anomaly detection — and to send results or compressed data to the upper-layer platform only when necessary. It fills the computing gap between physical-signal acquisition and cloud-side decision-making.
Hardware Selection: A Spectrum from MCU to AI Processors
Hardware selection depends on what the scenario demands in computing power, energy draw, cost, and real-time performance; the options fall roughly into three tiers.
Tier 1: MCU-level nodes (Microcontroller Unit). Built on ARM Cortex-M series or RISC-V cores, clocked from tens to hundreds of MHz, with on-chip Flash and RAM measured in KB or MB. These nodes sit right next to the sensor and handle simple filtering, threshold judgment, and format conversion. The toolchains that some MCU vendors ship (such as STM32Cube.AI) support deploying lightweight neural networks on-chip, enough for keyword spotting or simple vibration classification. Typical power draw is at the milliwatt level; they can run on batteries or energy harvesting, fitting the far ends of wireless sensor networks.
Tier 2: application-processor-level nodes. Centered on the ARM Cortex-A series, clocked above 1 GHz, running Linux or Android. Mainstream single-board computers carry a quad-core Cortex-A72 or similar processor, with memory ranging from 1 GB to 8 GB. Such nodes can take on protocol conversion, lightweight image processing, or TensorFlow Lite inference — for example, converting sensor-side Modbus/RS-485 data into MQTT/HTTP for the cloud platform. Power draw is typically a few watts to a dozen or so, fitting gateways or aggregation nodes with a stable power supply.
Tier 3: AI-accelerator nodes. When a scenario calls for real-time video analytics, multi-sensor fusion, or large-scale feature extraction, hardware with a GPU or an NPU (neural processing unit) is required. Entry-level AI development kits pair a multi-core CPU with hundreds of CUDA cores (or an equivalent NPU) and can run object detection or human pose estimation on the device, with no video stream sent back. Power draw falls between 5 W and 25 W — fitting scenarios that need AI inference but are constrained by network bandwidth.
Table 3-3 A qualitative comparison of common edge computing node hardware
| Dimension | MCU-level node | Application-processor level | AI-accelerator node |
|---|---|---|---|
| Typical CPU architecture | Cortex-M series / RISC-V | Cortex-A series, quad-core | Cortex-A series + GPU/NPU |
| Supported operating systems | Bare metal, FreeRTOS | Linux, Android | Ubuntu, Linux for Tegra |
| AI inference capability | Very small models (<100 KB) | Medium models (TensorFlow Lite) | Neural-network acceleration, supports mainstream deep-learning frameworks |
| Power draw | Milliwatt level | Watt level (3–15 W) | Mid-watt level (5–25 W) |
| Typical interfaces | SPI/I2C/UART/GPIO | USB/GPIO/HDMI/Ethernet | CSI/USB/Ethernet/GPIO |
| Applicable scenarios | Sensor-side filtering, threshold alarms | Protocol conversion, lightweight processing, web services | Video analytics, multi-sensor fusion, AI inference |
| Power supply | Battery, energy harvesting | USB power, PoE, DC supply | USB power, DC supply |
Deployment Location: The Sensor-Side vs. Gateway-Side Trade-Off
The closer an edge node sits to the sensors, the faster the response — but the fewer sensors a single node can cover, and the lower the computational complexity it can shoulder.
Sensor-side deployment: integrate the edge node inside the sensor module, or immediately next to the sensor. Processing can then happen at the raw analog-signal stage — running an FFT at the accelerometer and uploading only the spectral features instead of the raw time-domain waveform, or applying moving-average denoising at a temperature-humidity sensor and uploading only the samples whose change exceeds a threshold. This cuts communication volume significantly, which especially favors battery-powered or wireless-transmission scenarios. The price is limited computing power: running large models or handling multiple channels of data becomes difficult.
Gateway-side deployment: aggregate the sensors onto an edge gateway, which performs unified data preprocessing. The gateway can take in data from dozens of sensor nodes, do time alignment, anomaly detection, and data compression, then upload in batches. The typical setting is a smart building or a factory workshop: one indoor gateway collects data from all the sensors around it (temperature, humidity, light, CO₂, door contacts), aggregates it, and reports in a batch once per minute. Gateway-side computing is more plentiful, but the raw data still has to travel from each sensor to the gateway; without pre-filtering at the sensor end, the link still carries a large amount of redundant data.
The common engineering compromise is: "light filtering" at the sensor end, uploading only key events or anomalous data, and "heavy processing" at the gateway side, running fusion analysis and AI inference over the aggregated multi-source data. The sensor end is responsible for sampling denoising and event detection, while the edge node carries model inference and local decision-making — a division of labor in the same vein as the "train in the cloud, infer at the edge, respond on the device" idea from Chapter 2.
Deployment Considerations
Once hardware selection and placement are settled, several engineering issues in deployment still need to be anticipated.
Environmental adaptation. Industrial sites may face high temperature, high humidity, vibration, and dust. Consumer-grade hardware does not fit such settings — SD-card-based development boards fail easily under high temperature, and fanless AI acceleration kits may have to run throttled in enclosed spaces. Industrial-grade designs usually choose rugged enclosures, wide-temperature-grade chips, and passive cooling.
Power supply stability. Gateway-side edge nodes usually have a stable power source, but sensor-side nodes may depend on batteries or energy harvesting. Choosing a high-performance processor whose power budget cannot be sustained is worse than using a low-power MCU for simple processing. Draw up a power budget in the early phase of the project, and assess whether the battery replacement cycle or the energy-harvesting capacity matches the selection.
Security boundary. The edge node, sitting at the junction of the sensing layer and the network layer, is a weak point for attacks. An attacker may tamper with sensor values, intercept uploaded data, or inject forged commands. The principles: keep no sensitive configuration in plaintext on edge nodes, expose no unnecessary ports on untrusted networks, and require signature verification on firmware updates. Chapter 8 details the specific security measures.
Operations and upgrades. Sensor-side edge nodes are numerous and scattered, so firmware upgrades and status monitoring call for remote management capability. Prefer hardware platforms that support OTA (Over-The-Air) updates, and reserve a remote-diagnosis interface at design time. Gateway-side nodes are usually reachable, but batch upgrade procedures and rollback mechanisms still need to be planned for.
The edge node's data preprocessing capability provides the base data entry point for device abstraction — Section 3.7 covers how to abstract wildly differing sensors, actuators, and gateways into a unified thing model.
3.5.2 Data Preprocessing and Filtering on the Edge Node
Hardware selection answers "where to compute," but what the architect really has to judge is "what to compute." One gateway may take in a dozen sensor channels at once — temperature, humidity, vibration, current, air pressure. If every sensor pushes its raw per-second readings to the cloud, bandwidth and storage quickly become bottlenecks; more to the point, the bulk of that data contributes nothing to the business. A vibration sensor sampling at 5 kHz runs continuously, yet what the platform truly needs is only the short anomalous waveform just before and after a fault. Thornier still, protective actions on site demand millisecond-level response — the round trip of data going up through the cloud platform, triggering a rule, and a command coming back down usually already exceeds what the device can tolerate.
The core task of data preprocessing on the edge node comes down to three engineering goals: filter out noise, cut the data volume, and decide independently. Once these three goals are met in order, upstream traffic can usually be compressed to below one-tenth of the raw volume, and local response latency can drop from seconds to the order of a sampling period.
Filtering and Denoising: Extracting a Clean Signal from the Chaos
Raw signals from sensors are almost never clean. Power-supply ripple superimposes periodic interference on the analog front end; electromagnetic induction from motor starts and stops injects high-frequency pulses at the ADC input; mechanical vibration makes piezoelectric sensors drift steadily off their baseline. If limit checks are made directly on individual readings, one brief electromagnetic spike can trigger a false alarm — the fan cycles off and on while the temperature never crossed the limit at all.
The most economical denoising tool on an MCU is the moving average filter. It keeps a ring buffer of fixed depth: on each new sample it replaces the oldest entry, recomputes the arithmetic mean of everything in the buffer, and outputs that mean as the current value. The window length sets the filter's "inertia" — the longer the window, the stronger the smoothing, and the greater the delay in responding to real changes. The tuning rule of thumb: find the balance between how fast the signal changes and how timely the response must be. For room temperature that changes by less than 1 °C per minute, a window of dozens of samples causes no problem; for the vibration signal at the instant a gear blank makes contact, a window of more than a few samples is already enough to flatten the crucial impact signature.
Code Listing 3-1: Example implementation of a moving average filter (illustrative)
// Moving average filter example - the specific values are illustrative
#define WINDOW_SIZE 5
float buffer[WINDOW_SIZE] = {0};
uint8_t index = 0;
uint8_t count = 0;
float sum = 0;
float moving_average_filter(float new_sample) {
if (count == WINDOW_SIZE) {
sum -= buffer[index];
}
buffer[index] = new_sample;
sum += new_sample;
index = (index + 1) % WINDOW_SIZE;
if (count < WINDOW_SIZE) {
count++;
}
return sum / count;
}
// Usage example (hypothetical scenario)
// float raw = read_adc_channel(0);
// float cleaned = moving_average_filter(raw);
// if (cleaned > 45.0f) {
// gpio_write(LED_WARN, HIGH);
// mqtt_publish("temp_alert", cleaned);
// }The moving average is not the only option. When the noise spectrum and the signal spectrum are clearly separated, an infinite impulse response (IIR) low-pass filter reaches better passband flatness with very few operations — its weakness is sensitivity to floating-point precision, and on fixed-point MCUs an IIR is prone to numerical drift. When the raw data contains occasional wild points (jumps caused by electromagnetic pulses or poor contact), the median filter has the edge — it takes the middle value of the sorted window and is entirely insensitive to a single outlier. But a median filter must sort on every sample, so a slightly larger window adds noticeably to the MCU's overhead.
Data Aggregation: Upload Results, Not Samples
Filtering outputs a clean, continuous stream of values, but the platform side usually does not need every one of them. Within a time window, an edge node can statistically compress multiple samples and upload only the few feature quantities that best represent that window's state. Common aggregation operations include arithmetic mean, maximum, minimum, peak value, and cumulative integral.
An environmental-monitoring example makes this concrete: a node samples temperature once per second, and the platform reads the mean once every 5 minutes for energy-efficiency analysis. Over a 300-second window the node accumulates 300 samples, computes the mean, and pushes a single record to the platform — upstream data volume drops markedly. For motor current, the edge node can compute the RMS and peak values within one mains cycle and upload just those two feature values, instead of the thousands of samples of the full waveform.
Clearly unsuitable cases also exist: if an upper layer needs the raw waveform for fine-grained analysis (sideband diagnosis of a vibration spectrum, for example), time-domain detail must not be compressed away at the edge. But this is, in reverse, exactly where edge processing extends its reach — the node performs a fast Fourier transform (FFT) locally and uploads only the spectral feature vector or the amplitudes of a few principal frequency bands. The frequency-domain information tied to faults is preserved, while transmission is compressed to one-hundredth, even one-thousandth, of the raw data.
Anomaly Detection and Local Decision Mechanisms
Filtering and aggregation reduce the data volume, but the edge node's true architectural value is completing fast control without depending on the cloud platform. The common practice is to preset threshold rules in the node: when the processed data hits a threshold, the node immediately executes a local action — driving a relay, outputting a PWM signal, triggering an audible-and-visual alarm — while uploading the context of the anomalous event (timestamp, flagged snapshots of the raw values) to the platform for persistence and analysis.
Take a hypothetical workshop temperature-control scenario: if the moving-average-filtered temperature exceeds the preset threshold 3 times in a row, the node immediately drives the fan relay through a GPIO high level and at the same time publishes an MQTT message carrying an event ID. From the anomalous sensor reading to the fan starting, the overall latency stays within the time span of the sliding-window depth plus the number of confirmations. That latency is far below the round trip of "upload to the cloud, parse, and wait for the command to come down" — the latter takes hundreds of milliseconds even under good network conditions, and under congestion can reach several seconds or time out.
The local closed loop carries one more important engineering value: when the network goes down, the node can still complete protective actions independently; once the network recovers, the event log cached in non-volatile memory is pushed up to the platform. In industrial sites and remote monitoring stations, this property is critical — a brief network glitch will not leave a device out of control.
The last link in the closed loop is the actuator, which is often treated as "done the moment it is wired to a relay." The minimal usable actuator closed loop in fact has two checks. The first is the command acknowledgment: after an action command is sent down, an acknowledgment-timeout timer starts, and if no execution confirmation arrives within the allotted time, the dispatch is judged to have failed and the flow turns to retry or alarm. The second is the state read-back comparison: when the action should have completed, independent state quantities such as a contactor's auxiliary contact or a valve's return signal are read back and compared with the expected state, and any mismatch escalates the alarm. The acknowledgment answers "was the command delivered," and the read-back answers "did the action actually happen" — with either check missing, the most insidious kind of fault, "command sent but no action," can only be discovered by manual inspection rounds.
Engineering Trade-Off: How Much Processing Is Enough at the Edge
Preprocessing on the edge node is not a case of the more the better. Every processing stage added brings one more layer of code complexity and computing overhead, and possibly a new failure point. The rule of thumb the author drew from multiple projects: execute at the edge only the operations that need no cross-device context. Filtering, denoising, format conversion, single-point threshold judgment — these depend only on the current reading or the history within a short window; they need no cross-sensor correlation, and no long-horizon statistics. Trend prediction, multi-sensor fusion analysis, and tasks that require big-data modeling should be left to the edge gateway or the cloud platform.
The filtering, aggregation, and anomaly detection introduced in this section all revolve around the two core goals of "uploading clean data upward" and "taking fast actions downward." Teaching the edge node to distinguish normal from abnormal on the device side is another question — the one TinyML (on-device AI) is there to answer.