边缘计算与TinyML基础
在开始设计边缘告警设备之前，我们必须先厘清两个关键问题：为什么要把智能判断放到设备本地？以及TinyML在这其中扮演什么角色？本章将围绕边缘计算的核心思想、TinyML的技术定位、微控制器与传感器节点的工程角色，以及边缘推理与云端推理的差异展开。理解这些基础概念，是后续设计低功耗告警算法、优化无线传输策略的前提。
边缘计算的核心思想：把计算推向数据源头
边缘计算并非一个新概念，但在物联网设备爆发式增长的今天，它从可选方案变成了刚需。传统云计算模型要求所有数据上传到集中式数据中心处理，这在带宽、延迟、功耗和隐私四个维度上都面临瓶颈。以工业振动监测为例，一台旋转机械每秒产生数千个采样点，如果全部上传云端，不仅消耗大量无线带宽，而且电池供电的传感器节点会在数小时内耗尽电量。
边缘计算的核心思想是：在靠近数据源的位置完成数据处理和决策。对于告警设备而言，这意味着传感器采集数据后，由本地微控制器直接运行推理模型，判断是否发生异常事件，只有确认告警时才通过无线模块发送消息。这种"本地判断、按需上报"的模式，将无线传输功耗降低了90%以上。
边缘计算的架构通常分为三层：终端层（传感器+MCU）、边缘层（网关或边缘服务器）、云端层（数据中心）。TinyML主要部署在终端层，而边缘层可以运行更复杂的模型进行二次确认。理解这个分层架构，有助于我们在设计告警设备时合理分配计算任务。
TinyML：让机器学习在微控制器上运行
TinyML是机器学习与嵌入式系统的交叉领域，其目标是在功耗受限、计算资源有限的微控制器上部署机器学习模型。一个典型的TinyML模型大小在10KB到500KB之间，RAM占用不超过256KB，推理时间在10ms到100ms量级。这些约束决定了TinyML模型必须经过特殊设计：量化、剪枝、知识蒸馏是常用的模型压缩技术。
以TensorFlow Lite for Microcontrollers为例，它支持将训练好的模型转换为C++字节数组，直接编译进MCU固件。模型推理时，MCU从Flash中读取权重，在RAM中执行卷积或全连接运算。对于告警设备，常用的模型类型包括：
- 异常检测模型：基于自编码器或One-Class SVM，判断当前数据是否偏离正常模式。
- 分类模型：识别特定事件类型，如振动频谱中的轴承故障特征。
- 回归模型：预测剩余寿命或趋势变化，用于预防性维护。
选择TinyML方案时，需要评估MCU的算力（通常以MAC/s衡量）、Flash和RAM容量、以及外设接口。Cortex-M4或M7内核的MCU带有DSP指令集，可以加速矩阵运算；而Cortex-M0+则更适合极简模型。表1对比了常见MCU平台的TinyML能力。
| MCU平台 | 内核 | Flash/RAM | 推理能力 | 典型功耗 |
|---|---|---|---|---|
| STM32L4系列 | Cortex-M4F | 512KB/128KB | 支持CNN/RNN | 100μA/MHz |
| ESP32-S3 | Xtensa LX7 | 8MB/512KB | 支持TFLite Micro | 240mA(活跃) |
| nRF52840 | Cortex-M4F | 1MB/256KB | BLE+ML | 1.9μA(待机) |
| RP2040 | Cortex-M0+ | 2MB/264KB | 仅简单模型 | 1.5mA(活跃) |
传感器节点：数据采集的物理基础
传感器节点是边缘告警设备的"感官系统"。不同类型的传感器决定了我们能监测哪些物理量，也决定了数据采样的频率和功耗。在工业告警场景中，常用的传感器包括：
- 加速度计（如ADXL345、MPU6050）：监测振动，采样率可达1kHz以上，用于轴承故障、不平衡检测。
- 温度传感器（如DS18B20、SHT30）：监测设备温度，采样率低（1Hz足够），功耗极低。
- 电流传感器（如ACS712）：监测电机电流，用于过载和堵转检测。
- 气体传感器（如MQ系列）：监测环境气体，响应时间较慢，适合低频采样。
传感器节点的设计需要关注三个关键参数：采样率、分辨率和功耗模式。采样率决定了我们能捕捉到多快的信号变化；分辨率决定了测量精度；功耗模式则直接影响电池寿命。例如，一个振动监测节点以1kHz采样加速度数据，每次采样需要2ms，MCU在采样期间处于活跃状态，其余时间进入深度睡眠，平均功耗可以控制在50μA以下。
边缘推理与云端推理的差异分析
理解边缘推理与云端推理的差异，是设计告警策略的基础。表2从多个维度进行了对比。
| 对比维度 | 边缘推理 | 云端推理 |
|---|---|---|
| 端到端延迟 | 10-100ms | 1-10秒（含传输） |
| 单次决策能耗 | 约0.1mJ（MCU计算） | 约50mJ（无线传输+云端） |
| 数据隐私 | 数据不出设备 | 需上传原始数据 |
| 网络依赖 | 完全离线可用 | 断网即失效 |
| 模型复杂度 | 轻量模型（<1MB） | 深度模型（>100MB） |
| 更新频率 | 需OTA或本地烧录 | 云端即时更新 |
从表中可以看出，边缘推理在延迟、功耗和隐私方面具有压倒性优势，但在模型复杂度和更新便利性上不如云端。因此，实际系统通常采用混合推理架构：边缘设备运行轻量模型进行初步筛选，只有疑似异常时才将特征数据（而非原始数据）发送到云端，由云端复杂模型做最终确认。这种"边缘粗筛+云端精判"的模式，既保证了实时性，又提高了准确率。
案例拆解：工业电机轴承故障告警
下面通过一个具体案例，展示边缘推理如何在实际项目中发挥作用。
背景与约束：某工厂需要在50台电机上安装无线振动传感器，监测轴承早期故障。每台电机配备一个电池供电的传感器节点，要求电池寿命至少2年。节点通过BLE将告警信息发送到车间网关，网关再上传到工厂云平台。原始振动数据采样率为2kHz，每个样本16位，如果持续上传，每台设备每天产生约345MB数据，显然不可行。
初始方案与问题：最初设计是传感器节点每10秒上传一次振动波形的RMS值，由云端判断是否异常。但实际运行发现两个问题：一是RMS值无法捕捉轴承故障的冲击特征，漏报率高达40%；二是每10秒一次的BLE传输导致节点平均电流达到2.3mA，电池寿命仅3个月。
改进方案：在节点MCU上部署一个轻量级异常检测模型。具体步骤如下：
- 在MCU上对2kHz振动数据做FFT，提取1kHz以内的频谱特征（每帧128个频点）。
- 训练一个自编码器模型，输入为128维频谱特征，输出为重构误差。正常数据重构误差低，故障数据重构误差高。
- 将模型量化到8位整数，模型大小约32KB，RAM占用约20KB。
- MCU每5秒执行一次推理，若重构误差超过阈值，则通过BLE发送告警事件（包含时间戳和误差值）。
结果对比：改进后，节点平均电流降至0.12mA（其中MCU推理占0.08mA，BLE传输占0.04mA），电池寿命延长至2.5年。告警准确率提升至92%，漏报率降至8%。云端收到的数据量从每天345MB降至每天不到1KB（仅告警事件）。
风险与代价：边缘推理的代价是模型更新不便。当轴承故障类型变化时，需要重新训练模型并通过OTA更新固件。此外，自编码器的阈值需要根据每台电机的工况进行校准，否则可能出现误报。
复盘经验：这个案例验证了"本地判断减少无线传输能耗"的核心价值。关键成功因素包括：选择合适特征（频谱而非时域）、模型轻量化（量化+剪枝）、以及合理的阈值校准流程。后续章节将深入讲解如何在MCU上实现FFT和模型推理。
总结与设计要点
本章的核心结论可以归纳为以下几点：
- 边缘计算将计算推向数据源头，解决了带宽、延迟、功耗和隐私四大问题。
- TinyML是边缘计算在微控制器上的具体实现，模型必须经过量化、剪枝等压缩处理。
- 传感器节点的设计要平衡采样率、分辨率和功耗，特征提取应在MCU本地完成。
- 边缘推理与云端推理各有优劣，实际系统应采用"边缘粗筛+云端精判"的混合架构。
- 告警设备的设计目标是：尽可能在本地完成判断，无线传输只发送"事件"而非"数据"。