2、TinyML基础：嵌入式机器学习概念、资源约束、典型应用场景（预测性维护、工业监控等）
TinyML（微型机器学习）是机器学习与嵌入式物联网系统的交叉领域，核心目标是在毫瓦级甚至微瓦级功耗的微控制器（MCU）上部署和运行机器学习模型。与云端AI依赖高性能GPU/TPU不同，TinyML强调在资源极度受限的边缘设备上完成数据采集、特征提取、推理和决策。本章将系统阐述TinyML的基本概念、硬件与软件资源约束，并结合预测性维护和工业监控两大典型场景，剖析其工程落地的关键路径。理解这些基础，是后续在Arm Ethos-U系列NPU上完成模型部署与优化的前提。
2.1 TinyML的核心概念与设计哲学
TinyML并非简单地将深度学习模型压缩后塞入MCU，而是一套完整的系统工程方法论。其核心设计哲学可概括为"感知-处理-决策"闭环在极低功耗下的平衡。传统嵌入式系统依赖固定规则（如阈值比较、PID控制），而TinyML引入数据驱动的自适应能力，使设备能识别复杂模式（如轴承磨损的频谱特征、电机电流的谐波畸变）。
从技术栈角度看，TinyML涉及四个层次：硬件层（MCU、NPU、传感器）、算法层（模型架构、量化、剪枝）、工具链层（TensorFlow Lite Micro、CMSIS-NN、Vela编译器）、应用层（异常检测、预测性维护）。与云端AI不同，TinyML模型必须满足三个硬性指标：模型体积（通常小于2MB）、推理延迟（实时性要求通常在10-100ms内）、峰值功耗（电池供电场景下平均功耗需低于10mW）。
2.2 嵌入式环境的资源约束与应对策略
理解资源约束是TinyML工程化的第一步。下表对比了典型MCU平台与云端GPU的差异，这直接决定了模型设计和部署策略。
| 资源维度 | 典型MCU（Cortex-M55） | 云端GPU（A100） | TinyML应对策略 |
|---|---|---|---|
| 算力 | 4 GOPS（含NPU） | 312 TFLOPS | 模型量化至int8，使用深度可分离卷积 |
| 内存带宽 | 4GB/s（片内SRAM） | 2TB/s（HBM） | 权重驻留SRAM，避免外部Flash访问 |
| 存储容量 | Flash 1MB / RAM 256KB | 40GB HBM | 权重共享、K-means聚类量化、模型剪枝 |
| 功耗预算 | 50mW（全速运行） | 400W | 事件驱动采集、低功耗模式切换 |
| 数值精度 | int8/int16 | FP32/FP64 | 量化感知训练（QAT） |
在实际部署中，内存瓶颈往往比算力更早出现。一个典型的1D-CNN异常检测模型（输入长度512，4层卷积，32通道）在FP32下需要约1.2MB权重，远超多数MCU的Flash容量。通过int8量化可压缩至300KB，再结合权重剪枝（去除小于阈值的连接）可进一步降至180KB。但需注意，过度剪枝会导致精度下降，工程上通常采用"训练-剪枝-微调"的迭代流程。
2.3 典型应用场景一：预测性维护
预测性维护（PdM）是TinyML最具商业价值的场景之一。传统维护策略分为事后维修（故障停机损失大）和定期维护（过度维护浪费成本），而预测性维护通过持续监测设备状态，在故障发生前精准预警。其核心流程包括：信号采集（振动、温度、电流）、特征提取（时域RMS、频域FFT峰值）、健康指标计算（退化趋势）、剩余寿命预测（RUL）。
以旋转机械轴承故障为例，正常轴承的振动频谱主要集中在1倍频（1X），而故障轴承会出现2X、3X谐波以及边带频率。传统方法依赖专家手动设置阈值，难以适应工况变化。TinyML方案则直接在MCU上运行一个轻量级自编码器（Autoencoder），学习正常振动模式的低维表示，当重构误差超过动态阈值时触发报警。该模型仅需约80KB内存，推理时间小于15ms。
背景与约束：该厂有42台离心泵，原计划每季度停机检修，但曾因轴承故障导致非计划停机，单次损失约120万元。要求新系统功耗低于5mW，采用电池供电（2节AA电池，容量2000mAh），需连续运行18个月。
初始现象：振动传感器采集的加速度信号在1kHz-5kHz频段出现明显能量抬升，但RMS值仍在"正常"范围内（0.5g），传统阈值法无法识别。
关键参数：采样率12.8kHz，每次采集4096点（0.32秒），每10分钟采集一次。模型输入为FFT频谱（2048点），使用3层1D-CNN（通道数16/32/16），int8量化后模型大小142KB。
分析判断过程：通过对比正常与故障数据的频谱，发现故障特征集中在2.3kHz-2.8kHz的边带区域。自编码器重构误差从正常的0.02上升到故障前的0.15，且连续3次超过阈值0.1。
实际操作：在Cortex-M55+Ethos-U55平台上部署，使用Vela编译优化，推理耗时8.2ms，平均功耗3.8mW。系统在第27天发出预警，实际停机检查发现轴承滚珠已出现轻微点蚀。
结果对比：提前9天预警，避免了非计划停机。相比定期维护，维护成本降低62%，设备可用率从96.3%提升至99.1%。
风险与代价：初期误报率较高（约8%），通过增加温度融合特征和动态阈值调整，误报率降至1.5%。代价是模型体积增加至180KB，推理时间延长至11ms。
2.4 典型应用场景二：工业监控与异常检测
工业监控涵盖更广泛的场景，包括设备状态监测、环境安全监控、产品质量检测等。与预测性维护不同，工业监控更强调实时性和多模态融合。例如，在半导体制造车间，需要同时监测设备振动、洁净室颗粒物浓度、温湿度以及设备电流，任何一项异常都可能影响良率。
TinyML在此类场景中的优势在于边缘智能。以电机电流异常检测为例，电机启动瞬间的电流冲击、运行中的谐波畸变、以及堵转时的电流骤增，都是故障信号。传统方案需要将电流波形上传至PLC或云端分析，延迟高且占用带宽。TinyML方案直接在电机控制器的MCU上运行异常检测模型，当检测到电流波形异常时，可在5ms内切断电源，防止设备损坏。
多模态融合是工业监控的进阶需求。例如，将振动信号（加速度计）与声学信号（麦克风）结合，可以更准确地区分轴承故障与齿轮故障。但多模态数据同步和特征对齐在MCU上实现难度较大。工程上常采用时间窗口对齐和特征级融合策略：先分别提取各模态的统计特征（RMS、峰值因子、频谱质心），再拼接为特征向量输入分类器。这种方案比端到端融合更节省内存，且便于调试。
| 监控子场景 | 传感器类型 | 特征维度 | 模型类型 | 典型延迟要求 |
|---|---|---|---|---|
| 电机电流异常 | 电流互感器 | 时域波形+FFT | 1D-CNN | <10ms |
| 管道泄漏检测 | 压力传感器+声学 | 压力梯度+声谱 | 随机森林 | <50ms |
| 传送带跑偏 | 光电传感器阵列 | 位置偏差序列 | LSTM（轻量） | <20ms |
| 环境气体泄漏 | 电化学传感器 | 浓度时间序列 | 阈值+趋势预测 | <1s |
2.5 模型部署的工程流程与常见误区
从训练好的模型到可在Ethos-U上高效运行的部署包，需要经过一系列工程化步骤。标准流程如下：
- 模型设计：选择适合MCU的架构（如MobileNetV1的深度可分离卷积、1D-CNN、TinyLSTM），避免使用注意力机制等计算密集型算子。
- 量化感知训练：在训练过程中模拟int8量化误差，使用伪量化节点（fake quant）让模型适应低精度。
- 模型转换：将Keras/PyTorch模型转换为TensorFlow Lite格式，并设置优化选项（如默认int8量化）。
- NPU编译：使用Vela编译器将TFLite模型映射到Ethos-U的硬件算子库，生成针对NPU优化的C代码。
- 板级验证：在目标MCU上运行推理，对比输出与PC端浮点结果的差异，确认精度损失在可接受范围（通常<2%）。
- 功耗调优：利用MCU的低功耗模式（如睡眠、深度睡眠），在无推理任务时降低功耗。
误区1：认为模型越小越好。过度压缩会导致精度崩塌，应通过实验确定精度-体积的帕累托最优。
误区2：忽略数据预处理的计算开销。FFT、滤波等操作在MCU上可能比模型推理更耗时，需使用CMSIS-DSP库优化。
误区3：直接使用PC端验证的阈值。MCU端由于量化误差，激活值分布可能偏移，需在目标硬件上重新校准阈值。
误区4：忽视内存碎片问题。频繁的动态内存分配会导致堆碎片化，应使用静态内存池或预先分配缓冲区。
在Ethos-U系列NPU上部署时，还需特别注意算子支持范围。Vela编译器对某些算子（如LSTM、自定义激活函数）支持不完善，可能需要手动拆分或替换为等效算子组合。例如，将LSTM分解为矩阵乘法和逐元素操作，虽然增加了代码复杂度，但能充分利用NPU的矩阵加速单元。
--report选项生成算子级性能报告，识别瓶颈算子。如果某个算子耗时占比超过30%，优先考虑架构调整而非盲目优化代码。例如，将Conv1D的kernel size从5改为3，推理速度可能提升40%，而精度仅下降0.5%。
最后，TinyML项目的成功不仅取决于模型精度，更取决于系统工程能力。开发者需要同时具备嵌入式开发（中断管理、DMA传输、低功耗设计）和机器学习（模型训练、量化、调参）的双重技能。建议采用"数据-模型-部署"三阶段迭代开发模式，每个阶段设置明确的验收指标（如推理延迟、内存占用、功耗预算），避免后期返工。