1. 课程导入
欢迎来到《TinyML异常告警闭环从检测到本地执行》的第一章。在正式开始技术细节之前，我们需要先建立一张“认知地图”。TinyML并非简单的“在单片机上跑神经网络”，而是一套涉及信号采集、模型推理、结果判定、本地执行与反馈的完整工程闭环。本章将帮助你理解：为什么我们需要在资源极度受限的终端设备上构建异常检测能力？这个闭环由哪些关键环节构成？以及它在真实工业与消费场景中究竟能解决什么问题。我们将通过核心概念拆解、闭环框架解析、典型场景对比以及一个贯穿全书的“电机轴承异常预警”案例，为你后续章节的动手实践打下坚实的认知基础。
上图展示了TinyML异常告警闭环的四大核心层级：感知层、处理层、决策层与执行层。请注意，这不是一个单向流水线，而是一个带有反馈回路的闭环系统。感知层负责将物理世界的连续信号（如振动、电流、温度）转换为离散的数字序列；处理层在极低功耗的MCU上运行经过量化压缩的神经网络模型，提取异常特征；决策层根据模型输出的置信度或异常评分，结合动态阈值逻辑，判断是否触发告警；执行层则直接驱动本地硬件（如LED、蜂鸣器、继电器）完成物理动作。反馈回路意味着，每一次告警事件及其后续验证结果，都可以作为更新模型或调整阈值的依据，使系统越用越准。
1.1 核心概念：什么是TinyML异常告警闭环
TinyML是机器学习与嵌入式物联网的交叉领域，特指在功耗受限（毫瓦级）、内存受限（KB级）、算力受限（几十MHz级）的MCU上部署机器学习模型的技术总称。而异常告警闭环则强调从“感知异常”到“执行动作”再到“反馈优化”的完整链路，而非孤立的检测算法。一个完整的闭环必须包含以下五个要素：
- 数据源：传感器类型（加速度计、麦克风、电流互感器）、采样率、位深、数据预处理方式。
- 边缘模型：经过TensorFlow Lite for Microcontrollers或CMSIS-NN优化的模型，通常为1D-CNN、LSTM或决策树集成。
- 决策逻辑：不仅仅是模型输出，还包括滑动窗口平滑、滞回比较、多级阈值等工程化策略。
- 执行机构：GPIO控制的指示灯、蜂鸣器、电机断电继电器，或通过UART/SPI发送控制指令。
- 反馈通道：可以是本地存储的日志，也可以是BLE/WiFi上传的元数据，用于后续模型微调。
关键认知：在TinyML场景中，“异常”的定义往往是相对稀缺的。正常数据容易采集，但故障数据极难获取。因此，异常检测模型通常采用单类学习（One-Class Learning）或重构误差（如Autoencoder）方法，仅用正常数据训练，对偏离正常分布的数据进行告警。这与传统的分类任务有本质区别。
1.2 判断方法：如何评估一个场景是否适合TinyML闭环
并非所有异常检测问题都适合在TinyML设备上解决。作为工程师，你需要一套快速判断标准。以下四个维度缺一不可：
| 评估维度 | 适合TinyML的条件 | 不适合TinyML的信号 |
|---|---|---|
| 延迟要求 | 响应时间 < 100ms（如电机保护） | 允许秒级延迟（如周期性报表） |
| 数据带宽 | 原始数据量大，传输成本高（如40kHz振动） | 数据量小，云端处理更划算 |
| 隐私/安全 | 数据敏感，不允许出设备（如医疗体征） | 非敏感数据，可上传云端 |
| 功耗预算 | 平均电流 < 1mA，电池供电 | 有稳定电源，功耗不敏感 |
一个实用的判断流程是：首先确认是否有实时性或隐私性的硬性要求；其次估算传感器数据率（采样率×位深/8），如果数据率超过1KB/s且需要持续分析，则TinyML优势明显；最后检查目标MCU的Flash和RAM是否足够容纳量化后的模型（通常模型大小需小于256KB）。
1.3 案例拆解：工业电机轴承异常预警闭环
为了让你更直观地理解闭环的价值，我们引入一个贯穿全书的实战案例——化工厂冷却水泵电机轴承异常预警系统。该场景具有典型的TinyML应用特征。
背景与约束：化工厂的冷却水泵电机（功率15kW，转速2900rpm）位于防爆区，不允许WiFi/蓝牙无线传输，且现场电磁干扰强。电机轴承故障是导致非计划停机的首要原因，一旦损坏，维修成本高达数万元，且影响生产安全。传统方案是人工巡检，每4小时用测振笔测量一次，无法捕捉突发性故障。
初始目标：设计一个电池供电的无线传感器节点（尽管在防爆区，但节点本身需本安设计），在电机轴承座上安装加速度计（ADXL355，量程±16g，采样率4kHz），通过TinyML模型实时检测轴承磨损初期的振动特征变化，并在检测到异常时，通过硬连线继电器直接切断电机控制回路（本地执行），同时点亮防爆指示灯。
关键输入数据与参数：
- 正常振动加速度RMS值：0.8~1.2g（频段500Hz-2kHz）
- 轴承故障特征频率（BPFO/BPFI）：约120Hz和180Hz
- MCU选型：STM32L4系列（Cortex-M4，80MHz，512KB Flash，128KB RAM）
- 模型选型：1D-CNN，输入长度512点（128ms窗口），输出为异常概率值
分析判断过程：我们首先在PC端采集了200小时正常工况数据，训练了一个自编码器模型（输入512点，中间瓶颈层32维）。模型在正常数据上的重构误差均值为0.02。设定告警阈值为0.08（4倍标准差）。当实时重构误差连续3个窗口超过阈值时，判定为异常。这个“连续3次”的滞回逻辑有效避免了单次噪声尖峰导致的误报。
实际操作步骤（闭环执行）：
- 节点上电后，MCU初始化传感器，采集前10秒数据用于计算基线噪声。
- 进入低功耗循环：每100ms唤醒一次，采集512点数据（128ms），送入模型推理。
- 推理结果（重构误差）与阈值比较，若连续3次超限，则置位GPIO输出，驱动继电器断开电机主回路。
- 同时，将告警事件（时间戳、误差值、原始数据片段）存入外部Flash，供事后分析。
结果对比与复盘：在实验室注入轴承外圈故障（人为电火花加工凹痕）后，系统在故障发生后的第2.3秒触发告警并断电，而此时轴承温度尚未明显上升。相比人工巡检，提前了约3.8小时发现隐患。但我们也发现，在电机启动瞬间（电流冲击导致振动剧烈），系统出现了1次误报。复盘后，我们在决策逻辑中增加了“启动抑制”功能：电机启动后5秒内不进行异常判定。这个案例说明，算法模型只是闭环的一部分，工程化的决策逻辑和现场经验同样至关重要。
风险提示：在工业安全场景中，TinyML设备作为保护装置时，必须考虑“失效安全”模式。即当MCU死机或传感器断线时，应默认触发告警或保持安全状态，而不是静默失效。本案例中，我们增加了硬件看门狗，并在传感器自检失败时强制断开继电器。
1.4 常见误区与总结复盘
在规划TinyML异常告警项目时，初学者常陷入以下误区，需要特别警惕：
- 误区一：追求模型精度而忽略资源占用。一个99%精度的模型如果导致MCU无法运行其他任务，就是失败的。在TinyML中，“够用就好”是黄金法则。通常将模型量化到int8，精度损失控制在2%以内即可接受。
- 误区二：忽略数据采集的物理约束。传感器安装位置、共振频率、温漂都会影响数据质量。例如，将加速度计安装在轴承座正上方与侧面，信号幅值可能相差3倍以上。
- 误区三：将云端AI的思路直接搬到端侧。云端可以处理海量数据和复杂模型，但端侧必须考虑数据分帧、实时性、功耗预算。例如，云端常用的LSTM模型在MCU上可能因内存不足而无法部署，需要改用TCN或轻量级Transformer。
- 误区四：忽视“闭环”中的执行环节。很多项目止步于“检测到异常并发送通知”，但真正的闭环必须包含本地自动执行动作。如果只是发通知，当网络故障时，告警就丢失了。