4、项目生命周期：从需求分析、数据采集、模型训练、模型转换、部署到监控复盘的完整流程

TinyML预测性维护项目并非一个单纯的算法竞赛或模型训练任务，而是一个覆盖硬件、数据、算法与运维的复杂系统工程。许多团队在实验室中取得了极高的模型准确率，却在真实产线上遭遇“水土不服”——要么模型无法在资源受限的MCU上运行，要么部署后误报率飙升，要么因缺乏监控机制导致模型悄然失效。本章将沿着项目生命周期的六个核心阶段展开，剖析每个阶段的关键任务、交付物与常见陷阱，帮助读者建立从“想法”到“长期稳定运行”的完整工程视图。

上图展示了TinyML预测性维护项目的完整生命周期。与传统的IT系统开发不同，TinyML项目具有强烈的“硬件-算法耦合”特征：需求分析阶段必须考虑MCU的算力与内存限制，数据采集阶段需要关注传感器采样率与功耗的平衡，模型转换阶段更是直接影响最终部署效果。整个流程并非单向线性推进，而是通过监控复盘形成闭环反馈，持续优化系统性能。

4.1 需求分析：定义问题边界与成功标准

核心原理：需求分析是项目的第一道关口，其核心任务是将模糊的业务诉求转化为可量化、可验证的工程指标。对于TinyML预测性维护项目，需求分析需要同时回答三个层面的问题：业务层面（预测什么故障？提前多久预警？）、技术层面（使用什么传感器？部署在什么硬件上？）、经济层面（误报和漏报哪个代价更高？）。

判断方法或操作流程：需求分析阶段建议采用“四步法”进行结构化梳理：

1. 业务目标量化：将“减少设备停机”转化为“提前48小时预警轴承故障，准确率≥90%，误报率≤5%”这样的可测量指标。
2. 硬件约束盘点：明确目标MCU型号（如STM32L4、ESP32、RP2040）、Flash/RAM大小、电池供电还是外接电源、通信方式（BLE/WiFi/有线）。
3. 数据可行性评估：确认传感器类型（振动、温度、电流）、采样频率、数据标注成本、历史数据是否可用。
4. 风险与代价分析：建立混淆矩阵的代价模型——漏报导致设备损坏的损失 vs 误报导致停机检查的损失。

4.2 数据采集与预处理：高质量数据的工程化获取

核心原理：数据是TinyML模型的“燃料”，但工业场景中的数据采集远比互联网场景复杂。振动信号需要高采样率（通常≥10kHz），但MCU的存储和功耗有限；温度信号变化缓慢，采样率可以降低但需要长时间监测。数据采集的核心矛盾在于“信息完整性”与“资源有限性”之间的平衡。

操作流程：数据采集阶段需要完成以下关键任务：

• 传感器选型与安装：加速度计（如ADXL345、MPU6050）需考虑量程和灵敏度；安装位置直接影响信号质量，应尽量靠近轴承或齿轮箱。
• 采样策略设计：根据故障特征频率确定采样率（遵循奈奎斯特采样定理），采用分段采集（如每10分钟采集1秒数据）降低功耗。
• 边缘预处理：在MCU上完成简单的滤波（低通/带通）、去直流分量、归一化，减少传输数据量。
• 数据标注与存储：记录设备运行状态（正常/异常/故障类型），标注需要结合设备维护记录和专家经验。

4.3 模型训练与验证：在精度与资源之间寻找平衡

核心原理：TinyML模型训练与云端深度学习有本质区别。云端模型追求极致精度，可以使用数百MB的参数量；而TinyML模型必须在几十KB的模型大小内实现可接受的精度。因此，模型训练阶段需要同时关注两个目标：分类/回归精度和模型复杂度（参数量、计算量）。

判断方法：模型选型应遵循“从简到繁”的原则：

1. 基线模型：先使用简单的决策树、随机森林或1D-CNN作为基线，评估数据可分性。
2. 特征工程：提取时域特征（RMS、峰值因子、峭度）和频域特征（FFT主频、边带能量），减少模型对原始信号的依赖。
3. 模型压缩预判：在训练时就考虑量化敏感性——使用QAT（量化感知训练）而非训练后量化（PTQ），可减少精度损失。
4. 验证策略：采用时间序列交叉验证（按时间顺序划分训练/验证集），避免数据泄漏。

4.4 模型转换与优化：跨越“训练”与“部署”的鸿沟

核心原理：模型转换是TinyML项目中最具工程挑战性的环节。训练框架（如TensorFlow、PyTorch）生成的模型文件无法直接在MCU上运行，需要经过格式转换、量化、编译等一系列步骤。这一阶段的核心目标是：在保持模型精度的前提下，将模型压缩到目标硬件的资源限制内。

操作流程：以TensorFlow Lite for Microcontrollers为例，标准转换流程如下：

# 1. 训练并保存模型（Keras）
model.save('bearing_model.h5')

# 2. 转换为TFLite格式（float32）
converter = tf.lite.TFLiteConverter.from_keras_model(model)
tflite_model = converter.convert()

# 3. 量化（int8）
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset_gen
tflite_quant_model = converter.convert()

# 4. 转换为C字节数组（用于MCU部署）
with open('model_quant.tflite', 'rb') as f:
    model_bytes = f.read()
    c_array = ', '.join(f'0x{b:02x}' for b in model_bytes)
    with open('model_data.cc', 'w') as out:
        out.write(f'const unsigned char model_data[] = {{{c_array}}};')

关键优化技术：

• 量化：将float32权重转换为int8或int16，模型大小减少4倍，推理速度提升2-3倍。注意：量化后需验证精度损失，若超过2%则考虑QAT。
• 剪枝：移除权重接近零的连接，减少计算量。对于1D-CNN，可剪枝30-50%而不显著影响精度。
• 算子融合：将Conv+ReLU+Pooling融合为单一算子，减少内存访问次数。
• 内存规划：使用“arena”内存分配器，避免动态内存分配带来的碎片和不确定性。

4.5 部署与集成：从固件到系统的最后一公里

核心原理：部署阶段将转换后的模型集成到嵌入式系统中，使其成为设备固件的一部分。这不仅仅是“烧录代码”，还涉及传感器驱动、数据采集调度、推理触发逻辑、结果输出（本地告警/无线传输）等多个模块的协同工作。

部署架构设计：一个典型的TinyML预测性维护节点包含以下模块：

部署验证清单：

1. 功耗测试：测量待机、采集、推理、传输四种状态下的电流，计算平均功耗和电池寿命。
2. 时序验证：确认从传感器触发到告警输出的端到端延迟满足需求（如<2秒）。
3. 异常处理：测试传感器断线、数据异常（全零/饱和）、模型推理超时等异常场景。
4. 现场校准：在真实设备上运行24小时，收集实际数据与训练数据分布进行对比。

4.6 监控与复盘：模型生命周期的持续管理

核心原理：模型部署不是终点，而是持续运营的起点。工业设备的工作条件会随时间变化（磨损加剧、负载变化、季节温度波动），导致模型性能逐渐下降——这就是“概念漂移”。监控阶段的核心任务是：检测模型性能退化，触发重新训练或调整，形成数据-训练-部署的闭环。

监控指标体系：

• 数据漂移检测：监控输入数据分布（均值、方差、频谱能量）与训练数据的偏差。常用方法：PSI（群体稳定性指数）或KS检验。
• 预测置信度：记录每次推理的softmax输出概率，若置信度持续低于阈值（如0.7），提示模型可能遇到未知模式。
• 误报/漏报追踪：与设备维护记录关联，统计实际故障与预测结果的匹配度。
• 资源使用率：监控MCU的CPU占用、内存使用、Flash剩余空间，防止固件更新后资源不足。

复盘与迭代机制：建议建立月度复盘会议，分析以下问题：

1. 模型在哪些场景下表现不佳？是数据分布变化还是硬件老化？
2. 误报和漏报的代价是否与需求分析时的假设一致？
3. 是否有新的故障模式出现？需要增加新的训练数据类别？
4. 当前模型大小和推理延迟是否还有优化空间？