2、TinyML基础：什么是TinyML、边缘计算与云计算的对比、TinyML的硬件与软件生态

TinyML是机器学习与嵌入式物联网系统交叉融合的前沿领域，其核心目标是在功耗受限、计算资源有限的微控制器（MCU）上部署和运行机器学习模型。与传统的云端AI不同，TinyML强调在数据产生的物理位置附近完成推理，从而实现毫秒级响应、数据隐私保护和极低功耗运行。理解TinyML的基础概念、边缘与云端的本质差异以及软硬件生态的构成，是后续学习异常检测算法和部署优化的前提。

上图展示了边缘端与云端在异常检测任务中的典型分工。边缘端负责实时数据采集、特征提取和本地推理，云端则承担模型训练、优化和批量管理。这种“端云协同”架构是TinyML工程实践的核心模式，既发挥了MCU的低功耗优势，又利用了云端的强大算力。

2.1 TinyML的核心定义与技术边界

TinyML并非简单的“在单片机上跑神经网络”，而是一套完整的工程方法论，涵盖模型设计、压缩、编译优化和运行时管理。其技术边界由硬件资源、功耗预算和应用场景共同定义。

核心原理：资源约束下的机器学习

典型的TinyML目标硬件为ARM Cortex-M系列MCU，主频通常在几十MHz到几百MHz之间，Flash容量从256KB到2MB不等，RAM则仅有16KB到512KB。在这样的资源约束下，传统的深度学习框架（如TensorFlow、PyTorch）无法直接运行，必须经过专门的模型转换和优化。TinyML的推理过程通常采用INT8量化，将浮点运算转换为整数运算，从而在保持精度的同时大幅降低内存占用和计算延迟。

在异常检测场景中，TinyML通常处理的是振动信号、电流波形、温度曲线等时序数据。模型输入为滑动窗口截取的样本序列，输出为异常概率或分类标签。由于MCU不具备浮点单元（FPU）或仅具备单精度FPU，模型量化成为部署的关键步骤。

2.2 边缘计算与云计算的深度对比

边缘计算与云计算并非替代关系，而是互补关系。在工业设备状态监测场景中，两者承担不同职责，理解其差异有助于合理设计系统架构。

判断方法：何时选择边缘，何时依赖云端

选择边缘计算的核心判据包括：实时性要求（如设备保护需要在10ms内响应）、网络可靠性（工厂车间可能存在信号盲区）、数据隐私（生产数据不允许外传）、带宽成本（连续上传高频振动数据不现实）。而云端则适合模型训练、多设备聚合分析、长期趋势预测等非实时任务。

1. 延迟对比：边缘端推理延迟通常在5-20ms，云端即使使用5G网络也需要50-100ms以上，且受网络波动影响。
2. 带宽消耗：一个三轴加速度计以1kHz采样、16bit精度连续上传，每秒产生48KB数据，一天约4GB，边缘处理只需上传异常摘要（<1KB）。
3. 可靠性：边缘设备断网仍可运行，云端服务中断则导致监控失效。
4. 成本模型：边缘端一次性硬件成本（$5-20/设备），云端持续产生流量费和存储费。

案例拆解：电机轴承异常监测的端云分工

某工厂部署了50台电机状态监测系统，每台电机安装一个振动传感器+MCU节点。初始方案将所有振动波形上传至云端分析，结果发现：单台电机每天产生约3.6GB数据，50台设备每月流量费超过2万元，且云端检测到异常时，电机已损坏。改进后的方案采用TinyML边缘推理：MCU本地运行轻量级CNN模型，实时计算振动特征（RMS、峰值因子、频带能量），仅当本地模型判定异常概率超过阈值时，才上传1秒的原始波形片段至云端进行复核。改进后，流量费用降至每月不足100元，异常响应时间从分钟级缩短至秒级，且成功在轴承故障早期（振动幅值上升20%时）触发报警。

2.3 TinyML硬件生态：从MCU到专用加速器

TinyML硬件生态呈现多元化特征，从通用MCU到集成神经网络加速器的SoC，再到超低功耗专用芯片，为不同场景提供了丰富的选择。

硬件分类与选型要点

选型时需综合考虑：模型大小（Flash占用）、中间特征图（RAM占用）、计算量（延迟）、功耗预算（电池寿命）以及外设接口（ADC采样率、DMA通道）。对于振动异常检测，至少需要12位ADC、1kHz以上采样率，并支持DMA连续采样。

2.4 TinyML软件生态：工具链与工作流

TinyML软件生态围绕“训练-转换-部署-运行”四个阶段展开，形成了从云端到边缘的完整工具链。

核心工具链组成

• 训练框架：TensorFlow、PyTorch用于模型设计，需使用Keras API构建适合边缘的紧凑模型（如深度可分离卷积）。
• 模型转换：TensorFlow Lite for Microcontrollers（TFLM）将训练好的模型转换为C++字节数组，支持INT8量化。
• 编译优化：CMSIS-NN为ARM Cortex-M提供优化的神经网络内核函数，利用DSP指令加速卷积和全连接层。
• 运行时环境：裸机代码或RTOS（如FreeRTOS、Zephyr）管理任务调度，TFLM解释器负责模型推理。

// TFLM模型部署核心代码示例（伪代码）
#include "tensorflow/lite/micro/micro_interpreter.h"
#include "tensorflow/lite/micro/micro_mutable_op_resolver.h"

// 1. 加载模型（模型已转换为C数组）
const unsigned char model_data[] = {0x1c, 0x00, 0x00, ...};
// 2. 创建解释器
static tflite::MicroMutableOpResolver<10> resolver;
resolver.AddConv2D();
resolver.AddFullyConnected();
// 3. 分配内存（使用静态缓冲区）
static uint8_t tensor_arena[100 * 1024];
tflite::MicroInterpreter interpreter(model, resolver, tensor_arena);
// 4. 执行推理
interpreter.Invoke();

操作流程：从训练到部署的完整链路

1. 数据采集：使用开发板（如STM32F746G-DISCO）采集振动数据，标注正常/异常状态。
2. 模型训练：在PC端使用Keras训练1D-CNN或LSTM模型，目标精度>95%，参数量<50K。
3. 量化评估：使用TFLite Converter进行INT8量化，验证量化后精度损失<2%。
4. 嵌入式部署：生成C数组，集成到MCU工程，配置DMA和定时器。
5. 在线验证：使用实际设备运行，对比边缘推理结果与云端标注结果，调整阈值。

2.5 端云协同架构设计

实际工程中，TinyML设备并非完全独立工作，而是与云端形成协同系统。典型的端云协同架构包含三个层次：感知层（传感器+MCU）、边缘层（网关设备）、云端层（训练与管理系统）。

在异常检测场景中，边缘设备持续运行本地模型，当检测到潜在异常时，将压缩后的特征向量（如频域峰值、时域统计量）发送至边缘网关。网关汇聚多台设备数据，进行时空关联分析（如判断是否多台设备同时异常），再决定是否上报云端。云端则负责模型更新、跨设备学习（联邦学习）和长期趋势分析。

2.6 总结与工程实践要点

本章系统梳理了TinyML的基础知识体系。核心要点归纳如下：