4. TinyML技术栈

工业听诊项目的本质，是在嘈杂的工厂环境中，通过声音信号识别设备（电机、泵、风扇）的异常状态。要实现这一目标，我们需要一套完整的技术栈：从感知物理世界的传感器，到承载推理任务的微控制器（MCU），再到支撑模型训练与部署的TinyML框架。本章将系统梳理这四层技术栈的选型逻辑、数据流走向与工程约束，帮助你在硬件选型和架构设计阶段建立全局视野。

上图展示了工业听诊系统的完整技术栈架构。从左侧的传感器采集原始声学信号，经过信号调理与数字化，进入MCU进行特征提取和推理，最终输出决策结果并上传云端。值得注意的是，数据流是单向的，但模型更新是闭环的——云端训练的优化模型需要定期回传到边缘设备，这要求我们在设计初期就考虑OTA（空中升级）能力。

4.1 核心原理：边缘计算与TinyML的定位

边缘计算的核心思想是将数据处理能力下沉到数据产生的地方。在工业听诊场景中，这意味着将声学分析从云端服务器迁移到靠近电机的嵌入式设备上。TinyML是边缘计算在机器学习领域的延伸，特指在微控制器等资源受限设备上运行机器学习模型的技术。

为什么工业听诊必须依赖边缘计算？我们可以从三个维度分析：

• 实时性要求：电机故障（如轴承磨损、转子断条）的声学特征往往在毫秒级变化。如果依赖云端推理，网络延迟（通常50-200ms）加上排队时间，可能错过关键故障特征。边缘推理可以将延迟压缩到10ms以内。
• 带宽与成本约束：一台电机以16kHz采样率、16bit精度连续采集，每秒产生32KB数据。一个中型工厂有200台设备，每天产生的数据量超过500GB。将所有原始数据上传云端既不经济也不现实。
• 数据隐私与可靠性：工厂声学数据可能包含工艺参数、设备运行状态等敏感信息。边缘计算确保原始数据不出厂区，同时即使网络中断，本地告警功能依然可用。

TinyML的"小"体现在三个层面：模型大小（通常<100KB）、内存占用（<256KB）、功耗（<10mW）。这些约束决定了我们不能直接使用传统的深度学习模型，而需要针对嵌入式环境进行专门设计。

4.2 传感器选型与信号链设计

传感器是整个系统的"耳朵"，其性能直接决定了后续分析的准确性。工业听诊场景对麦克风有特殊要求：需要承受工业环境的温度变化（-20℃至+70℃）、振动干扰、电磁噪声，同时保持平坦的频率响应。

信号链设计的关键在于抗混叠滤波。根据奈奎斯特采样定理，采样率必须大于信号最高频率的两倍。对于电机声学监测，我们通常关注1kHz-10kHz频段（轴承故障特征频率），因此采样率设置为16kHz或32kHz。在ADC之前，必须使用低通滤波器滤除高于采样率一半的频率成分，否则会产生混叠失真。

4.3 微控制器选型与资源评估

MCU是TinyML推理的"大脑"。选择MCU时，需要综合评估算力、内存、外设接口和功耗。以下是工业听诊项目中最常用的几款MCU对比：

对于工业听诊项目，我们推荐ESP32-S3作为首选平台。原因有三：其一，其内置的向量指令（SIMD）可以加速FFT运算，实测1024点FFT仅需0.8ms；其二，512KB的SRAM足以容纳特征缓冲区（256KB）和模型中间变量（128KB）；其三，内置Wi-Fi/BLE模块，无需外挂通信芯片，简化了硬件设计。

在资源评估时，需要精确计算内存预算。以一个典型的1D-CNN模型为例：输入特征为128×32（128个时间帧，每帧32个MFCC系数），模型包含3个卷积层和2个全连接层，参数量约50K。在INT8量化后，模型大小为50KB，推理时中间激活值占用约80KB，加上特征提取缓冲区256KB，总内存需求约400KB。这已经接近STM32F446的极限，因此选择ESP32-S3更为稳妥。

4.4 TinyML框架选型与部署流程

TinyML框架负责将训练好的模型转换为可在MCU上高效运行的代码。目前主流框架包括TensorFlow Lite Micro（TFLM）、Edge Impulse、CMSIS-NN和STM32Cube.AI。选择框架时，需要关注模型支持度、量化工具链、推理速度和社区活跃度。

部署流程分为五个关键步骤：

1. 模型训练：在PC端使用TensorFlow/Keras训练声学分类模型，输入为频谱特征，输出为设备状态类别（正常、轴承磨损、不平衡、松动等）。
2. 量化转换：使用TFLite Converter将FP32模型转换为INT8量化模型。量化过程需要校准数据集，统计激活值的动态范围。
3. 模型验证：在PC上模拟量化模型的精度损失。通常INT8量化后精度损失应控制在2%以内，如果超过5%，需要调整量化策略或使用INT16混合量化。
4. 嵌入式集成：将TFLM运行时库和模型数组集成到MCU工程中，编写推理调用代码。
5. 硬件在环测试：在真实电机上测试推理结果，对比PC端仿真结果，验证时序和内存占用。

// TFLM推理核心代码示例
#include "tensorflow/lite/micro/micro_interpreter.h"
#include "tensorflow/lite/micro/micro_mutable_op_resolver.h"

// 模型数据（由convert.py生成）
extern const unsigned char model_data[];

// 初始化解释器
static tflite::MicroMutableOpResolver<10> resolver;
resolver.AddConv2D();
resolver.AddFullyConnected();
resolver.AddSoftmax();

static tflite::MicroInterpreter interpreter(
    tflite::GetModel(model_data), resolver,
    tensor_arena, kTensorArenaSize);

// 推理调用
void run_inference(float* mfcc_features) {
  // 将特征数据拷贝到输入张量
  memcpy(interpreter.input(0)->data.f, mfcc_features, 
         kFeatureCount * sizeof(float));
  // 执行推理
  interpreter.Invoke();
  // 获取输出概率
  float* output = interpreter.output(0)->data.f;
  float anomaly_score = output[1]; // 异常类别概率
}

4.5 实战案例：离心泵轴承故障监测系统

我们为一个化工厂的循环水泵设计声学监测系统。该泵为离心式，转速2950rpm，轴承型号SKF 6205-2RS。初始目标是检测轴承外圈故障（特征频率BPFO=178Hz）。

系统约束：

• 泵房环境温度45℃，有轻微振动（加速度<0.5g）
• 要求告警延迟<2秒，误报率<1次/周
• 设备已有Wi-Fi覆盖，但网络不稳定（丢包率5%）
• 供电为24V DC，功耗预算<2W

方案设计：

选用ESP32-S3 + INMP441麦克风，采样率32kHz，每次采集2秒音频（64K采样点）。特征提取采用短时傅里叶变换（STFT），窗口1024点，重叠50%，生成128×128的频谱图。模型采用MobileNetV1的简化版（深度可分离卷积），参数量80K，INT8量化后大小80KB。

关键参数：

• FFT计算时间：1.2ms/帧，总特征提取时间：150ms
• 模型推理时间：85ms（使用CMSIS-NN加速）
• 总处理周期：约300ms（含数据采集和缓冲）
• 内存占用：特征缓冲区256KB + 模型80KB + 中间变量64KB = 400KB

部署结果：系统连续运行30天，共采集有效样本86,400条。在轴承故障初期（振动速度0.8mm/s），模型准确率98.2%，误报3次（均为外部冲击干扰）。相比传统振动分析方案，成本降低60%，部署时间从2天缩短到4小时。

4.6 常见误区与设计建议

在TinyML工业听诊项目的实践中，以下误区值得特别注意：

• 误区一：盲目追求高采样率。32kHz采样率已经足够覆盖电机声学特征（最高10kHz），过高的采样率只会增加存储和计算负担。对于大型低速设备（如风机转速<500rpm），16kHz采样率即可。
• 误区二：忽略传感器安装位置。麦克风应尽量靠近轴承座，距离不超过30cm，且避免正对冷却风扇（气流噪声会淹没故障特征）。建议使用硅胶减震支架隔离机械振动。
• 误区三：模型训练数据与现场数据分布不一致。实验室采集的声学数据与工厂现场差异巨大（背景噪声、混响、设备负载）。建议在部署初期收集至少1周的现场数据，用于模型微调。
• 误区四：忽视功耗管理。虽然MCU推理功耗较低，但Wi-Fi传输是功耗大户。建议采用"采集-推理-告警"的间歇工作模式，仅在检测到异常时才启动Wi-Fi传输。

最后，建议在设计初期就建立完整的测试矩阵，包括不同负载条件、不同环境噪声水平、不同设备型号的验证。TinyML项目失败的主要原因往往不是模型精度不够，而是系统集成和现场适配不足。