3.5 边缘计算节点
3.5.1 边缘计算节点硬件与部署
“算力应该放在哪儿？”物联网架构师在设计感知层时经常遇到这个选择。传感器数据全部上传云端处理，网络带宽和实时性往往撑不住。一台振动传感器每秒产生上千个读数，但真正有用的大幅变化可能只持续几十毫秒。边缘计算节点的作用就在数据源头附近提供第一级处理——滤波、聚合、异常检测，只在必要时才把结果或压缩后的数据发给上层平台。它填补了从物理量采集到云端决策之间的算力鸿沟。
硬件选型：从MCU到AI处理器的谱系
硬件选型取决于场景对算力、功耗、成本和实时性的要求，大致分为三个梯队。
第一梯队：MCU级节点（微控制器，Microcontroller Unit）。 基于ARM Cortex-M系列或RISC-V内核，主频在几十到几百MHz，片内Flash和RAM以KB或MB计量。这类节点紧邻传感器，完成简单的滤波、阈值判断和格式变换。一些MCU厂商自带的工具链（如STM32Cube.AI）支持在片内部署轻量级神经网络，可实现关键词识别或简单振动分类。典型功耗在毫瓦级别，可用电池或能量采集供电，适合无线传感器网络末端。
第二梯队：应用处理器级节点。 以ARM Cortex-A系列为核心，主频在1GHz以上，运行Linux或Android系统。主流单板计算机采用四核Cortex-A72或类似处理器，内存从1GB到8GB不等。这类节点可承担协议转换、轻量图像处理或运行TensorFlow Lite做推理——比如把传感器侧的Modbus/RS-485数据转换为MQTT/HTTP发给云平台。功耗通常在几瓦到十几瓦，适合有稳定供电的网关或汇聚节点。
第三梯队：AI加速节点。 需要实时视频分析、多传感器融合或大规模特征提取时，需使用带GPU或NPU（神经网络处理器）的硬件。入门级AI开发套件搭载多核CPU和数百个CUDA核心（或等效NPU），可在端侧完成目标检测、人体姿态估计，无需回传视频流。功耗在5W到25W之间，适合AI推理但受网络带宽限制的场景。
表3-3 常见边缘计算节点硬件定性对比
| 维度 | MCU级节点 | 应用处理器级 | AI加速节点 |
|---|---|---|---|
| 典型CPU架构 | Cortex-M系列/RISC-V | Cortex-A系列四核 | Cortex-A系列+GPU/NPU |
| 可支持操作系统 | 裸机、FreeRTOS | Linux、Android | Ubuntu、Linux for Tegra |
| AI推理能力 | 极小模型（<100KB） | 中等模型（TensorFlow Lite） | 神经网络加速，支持主流深度学习框架 |
| 功耗水平 | 毫瓦级 | 瓦级（3–15W） | 中瓦级（5–25W） |
| 典型接口 | SPI/I2C/UART/GPIO | USB/GPIO/HDMI/以太网 | CSI/USB/以太网/GPIO |
| 适用场景 | 传感器端滤波、阈值告警 | 协议转换、轻量处理、Web服务 | 视频分析、多传感器融合、AI推理 |
| 供电方式 | 电池、能量采集 | USB供电、PoE、直流电源 | USB供电、直流电源 |
部署位置：传感器侧与网关侧的权衡
边缘节点放得越靠近传感器，响应越快，但单节点能覆盖的传感器数量和承担的计算复杂度也越低。
传感器侧部署：把边缘节点集成进传感器模组内部，或紧挨着传感器。能在原始模拟信号阶段做处理——比如在加速度传感器端做FFT后只上传频谱特征，而不是原始时域波形；在温湿度传感器端做滑动平均去噪，只上传变化超过阈值的采样值。这能显著减少通信量，对电池供电或无线传输的场景尤其有利。代价是算力受限，很难跑大模型或处理多路数据。
网关侧部署：把传感器汇聚到边缘网关，由网关做统一的数据预处理。网关可以接收几十个传感器节点的数据，做时间对齐、异常检测、数据压缩，然后批量上传。典型场景是智能楼宇或工厂车间：一个室内网关收集周围所有传感器（温度、湿度、光照、CO₂、门磁）的数据，聚合后每分钟批量上报。网关侧算力更充裕，但原始数据仍需从每个传感器传输到网关，如果传感器端不做预过滤，链路上仍会携带大量冗余数据。
工程上常见的折中方案是：传感器端做“轻过滤”，只上传关键事件或异常数据；网关侧做“重处理”，对汇聚后的多源数据做融合分析和AI推理。传感器端负责采样降噪和事件检测，边缘节点承担模型推理和本地决策——这一分工与第2章提到的“云侧训练、边缘推理、端侧响应”思路一脉相承。
部署注意事项
硬件选型和位置确定后，部署中还有几个工程问题需要预判。
环境适应性。工业现场可能面临高温、高湿、振动、粉尘。消费级硬件不适用于此类场景——一些基于SD卡存储的开发板在高温下容易损坏，无风扇的AI加速套件在密闭空间可能需要降频运行。工业级方案通常会选择加固外壳、宽温级芯片和被动散热设计。
供电稳定性。网关侧边缘节点通常有稳定电源，但传感器侧可能依赖电池或能量采集。如果选用高性能处理器但功耗跟不上，反而不如用低功耗MCU做简单处理。建议项目初期做功耗预算，评估电池更换周期或能量采集能力是否匹配选型。
安全边界。边缘节点作为感知层与网络层的交界点，是安全攻击的薄弱环节。攻击者可能篡改传感器值、拦截上传数据或注入虚假指令。原则：边缘节点上不要保留敏感配置明文，不要在不可信网络上暴露不必要的端口，固件更新要有签名验证。具体安全措施将在第8章详述。
运维与升级。传感器侧边缘节点数量庞大且位置分散，固件升级和状态监控需要远程管理能力。建议选用支持OTA（Over-The-Air）更新的硬件平台，并在设计阶段预留远程诊断接口。网关侧节点通常可达，但也要考虑批量升级流程和回退机制。
边缘节点的数据预处理能力为设备抽象提供了基础数据入口——关于如何将千差万别的传感器、执行器、网关抽象为统一的物模型（Thing Model），我们将在3.7节展开。
3.5.2 边缘节点上的数据预处理与过滤
硬件选型回答的是“在哪算”，但架构师真正需要判断的是“算什么”。一台网关可能同时接入十几路传感器——温度、湿度、振动、电流、气压。如果每个传感器每秒钟的原始读数都往云端推，带宽和存储都会迅速变成瓶颈，更关键的是大量数据对业务毫无贡献。一台5kHz采样率的振动传感器连续运行，平台真正需要的只是故障发生前后的短时异常波形。更棘手的是，现场的保护性动作要求毫秒级响应——等数据经过云平台、触发规则、再下发指令的往返耗时，通常已经超过了设备的容忍极限。
边缘节点上的数据预处理，核心任务可以归结为三个工程目标：滤除噪声、减少数据量、独立决策。这三个目标按顺序实现后，上行流量通常能压缩到原始量的一个数量级以下，而本地响应的延迟可以从秒级压缩到采样周期级别。
滤波去噪：从混乱中提取干净信号
传感器采集到的原始信号几乎不会干净。电源纹波会在模拟前端叠加周期性干扰；电机启停引起的电磁感应会在ADC输入端注入高频脉冲；机械振动会使压电式传感器产生持续的基线漂移。如果直接拿单次读数判断是否超限，一个短暂出现的电磁尖峰就可能触发误告警——风机关了又开，温度根本没过限。
MCU（Microcontroller Unit，微控制器单元）上最经济的去噪手段是滑动平均滤波（Moving Average Filter）。它维护一个固定深度的环形缓冲区，每次收到新采样值时替换最旧的样本，重新计算缓冲区中所有值的算术平均，用这个均值作为当前输出。窗口长度决定了滤波的“惯性”——窗口越长，平滑效果越强，但对真实变化的响应延迟也越大。调参的工程准则是：在信号变化速度与响应时效之间找到平衡。对于每分钟变化不到1°C的室温，窗口长度设到几十个采样点都不会有问题；但对于齿坯接触瞬间的振动信号，窗口超过几个采样点就足以抹平关键的冲击特征。
代码清单3-1：滑动平均滤波实现示例（示意）
// 滑动平均滤波示例 - 具体数值为示意
#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;
}
// 使用示意（假设场景）
// 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);
// }滑动平均不是唯一的选项。如果噪声频谱与信号频谱明显分离，无限脉冲响应（Infinite Impulse Response, IIR）低通滤波器在极少的运算量下就能达到更好的通带平坦度，只是对浮点精度敏感——在定点MCU上用IIR容易出现数值漂移。如果原始数据中偶发野点（因电磁脉冲或接触不良导致的跳变），中值滤波更有优势——它取窗口内排序后的中间值，对单个异常点完全不敏感。但中值滤波要求每次排序，窗口稍大就会显著增加MCU的开销。
数据聚合：上传承结果，而非样本
滤波输出的是干净的连续数值流，但平台端通常不需要每一条。边缘节点可以在一个时间窗口内对多个采样值做统计压缩，只上传最能代表该窗口状态的几个特征量。常见的聚合操作包括：算术平均、最大值、最小值、峰值、累积积分值。
用一个环境监测的例子来说明：节点每秒采集一次温度，平台每5分钟读取一次均值做能效分析。节点在300秒窗口内累积300个采样值，算出均值，只向平台推送一条记录。上行数据量显著降低。对电机电流而言，边缘节点可以在一个工频周期内计算有效值和峰值，只上传这两个特征值，而不是全波形的数千个采样点。
明显不适用的场景也存在：如果上层需要原始波形做精细分析（例如振动频谱的边频带诊断），就不能在边缘层压缩掉时域细节。但这一点反过来正是边缘处理能力的延伸机会——节点在本地做快速傅里叶变换（Fast Fourier Transform, FFT），只上传频谱特征矢量或若干主要频段的幅值。既保留了与故障关联的频域信息，又把传输量压缩到原始数据的百分之一甚至千分之一量级。
异常检测与本地决策机制
滤波和聚合减小了数据量，但边缘节点的真正架构价值在于不依赖云平台就能完成快速控制。常见做法是在节点内预设阈值规则：当处理后的数据命中阈值时，节点立即执行本地动作——驱动继电器、输出PWM信号、触发声光告警，同时将异常事件的上下文（时间戳、带标记的原始值快照）上传给平台做持久化和分析。
再以一个假设的车间温控场景为例：滑动平均滤波后的温度值若连续3次超过预设阈值，节点立即通过GPIO输出高电平驱动风扇继电器，同时发布一条带事件ID的MQTT报文。从传感器读数异常到风扇启动，整体延迟在滑动窗口深度加判定次数的时间范围内。这个延迟远低于“上传云端解析再等待指令下发”的往返耗时，后者即使在较好的网络条件下也需要数百毫秒，遇到网络拥塞时可能达到数秒甚至超时。
本地闭环还有一个重要的工程价值：网络断开时，节点仍能独立完成保护性动作；网络恢复后，缓存在非易失存储器中的事件日志再补推给平台。在工业现场和偏远监测站点中，这一特性尤为关键——一次短暂的网络抖动不会导致设备失控。
闭环的最后一环是执行器，它常被当作“接到继电器就算完成”，实际最小可用的执行器闭环有两道检查：一是指令回执，下发动作指令后启动回执超时计时，规定时间内未收到执行确认即判定本次下发失败，转入重试或告警；二是状态回读比对，动作应已完成时回读接触器辅助触点、阀门回讯等独立状态量，与期望状态比对，不一致则升级告警。回执回答“指令是否送达”，回读回答“动作是否真正发生”——缺了任何一道，“下发后无动作”这类最隐蔽的故障就只能等人工巡检来发现。
工程权衡：边缘该处理多少才算够
在边缘节点上做预处理不是越多越好。每引入一个处理环节，就多一层代码复杂度和算力开销，也可能带来新的故障点。作者在多个项目后归纳的经验准则是：只在边缘执行“无需跨设备上下文”的操作。滤波、去噪、格式变换、单点阈值判定——这些只依赖当前读数或短窗口内的历史值，不需要跨传感器的关联比对，也不需要长时间维度的统计规律。趋势预测、多传感器融合分析、需要大数据建模的任务，应该留给边缘网关或云平台来处理。
本节介绍的滤波、聚合和异常检测，都是围绕着“向上传干净数据”和“向下做快速动作”这两个核心目标展开的。如何让边缘节点在端侧学习区分正常与异常，则是TinyML（端侧AI）要回答的另一个问题。