最近在调试一块 STM32 上的振动监测固件时脑子里反复出现一个项目标题MCUs Enable AI-Based Predictive Maintenance。翻译过来就是用 MCU 在设备端实现基于 AI 的预测性维护。干了这么多年设备健康管理和边缘计算我越来越觉得这句话不是厂商宣传而是被现实逼出来的方向。设备坏了再修叫事后维护按日历工时换件叫预防性维护真正能根据设备状态判断“大概还能撑多久”的才是预测性维护。过去这套逻辑基本跑在上位机或云端但工业现场总有网络不稳、延迟不定、数据量大到你根本不想传的情况。于是在一个几千瓦的电机旁边塞一个几块钱的 MCU让它学会分辨正常声音和早期故障声音就成了最有性价比的解法。这篇文章把我从选传感器、采数据、训练模型到部署固件、现场校准、排坑的全过程串起来。不搞玄学只说能落地的做法。嵌入式工程师、设备运维和设备健康管理相关的朋友应该都能从中找到对自己有用的部分。1. 为什么预测性维护一定要被塞进 MCU 里1.1 维护方式的进化路径本质是决策权的前移先花两分钟把维护方式这件事说透。事后维护很简单设备停机了维修队上场问题找到零件换上。代价是生产停摆维修时间不可控关键设备一旦出问题可能就是几十万的损失。预防性维护则是“不管坏没坏到时间就换”比如变频器每运行 5000 小时换一次风扇。这种做法能降低突发故障率但会造成大量浪费很多零件在健康状态下就被换掉了你换下来的旧件其实还能用很久。预测性维护不一样它依靠状态监测数据判断设备是否出现早期退化然后在故障恶化前安排维修窗口。轴承外圈磨损、齿轮断齿、转子不对中、基础松动这些故障都会在振动、电流、温度信号里留下痕迹。经验丰富的老师傅拿一根听诊器贴在轴承座上就能听出外圈故障的“哒哒哒”节奏就是因为故障特征频率确实存在而且耳朵能捕捉到。但人不能 24 小时守在每台设备旁边所以传感器的角色就是替老师傅值班。AI 在这个链条里扮演的不是“预测未来”的玄学角色而是识别退化模式。故障早期信号很微弱传统固定阈值很难识别但一个经过充分训练的模型能发现振动频谱中微小的边带变化。于是问题变成了模型应该跑在哪里我的结论是能跑在 MCU 上就尽量别上云。1.2 云端 AI 能识别故障却常常救不了现场我见过不少企业一开始做预测性维护架构是这样的传感器或网关采集数据通过 WiFi 或 4G 传到云平台模型在云端推理结果再通过 APP 推给运维人员。听起来很完整实际用起来有三道坎。第一道是延迟。从采样到云端返回正常情况几百毫秒一旦网络波动就是几秒甚至失败。预测性维护虽然不像工业控制那样要求毫秒级响应但状态监测需要连续性中间断了这一段故障可能就在断档期发展成停机。第二道是带宽和成本。以三轴加速度计为例采样率 12.8kHz、16bit 量化一条通道数据速率是 25.6KB/s三个通道就是 76.8KB/s。如果你 30 秒传一次窗口一天下来单台设备就是 6GB 以上。工业现场几十上百台设备云端存储和带宽账单会很感人。更别说很多设备还在用 Modbus、4-20mA 这类老掉牙的通信方式根本承载不了原始波形传输。第三道是数据边界。设备厂商往往不愿意把振动波形这类核心运行数据传到外部平台数据安全是个越来越敏感的合规问题。与其把原始数据全量上送不如在设备端完成判断只把“异常类型、置信度、关键频谱”这类结论上报。云端的价值在于全局分析和模型迭代而现场判断这件事交给 MCU 更合适。1.3 MCU 的底线和上限能跑什么、不能跑什么很多人一听到“AI”就想到 GPU、服务器潜意识里觉得 MCU 不可能做 AI。但实际上现代 MCU 已经不是 20 年前的 8051 了。Cortex-M4 主频 100MHz 级别、带 FPU 和 DSP 指令能在一秒内完成几十次小型神经网络推理Cortex-M7 和 M33 性能更强M55 甚至带了 Helium 向量扩展。Flash 做到 1MB 以上RAM 做到 256KB 以上放一个压缩后的模型和推理框架绰绰有余。但 MCU 有它的边界。它跑不了几百 MB 的大模型也扛不住需要长时间并行计算的 Transformer 类结构。真正适合 MCU 的是压缩后 100KB 到 300KB 的模型、单次推理 5 到 50ms 的小型 CNN、决策树或异常检测器。应用场景集中在旋转设备电机、泵、风机、压缩机、输送带、减速机这些都是振动特征明显、故障模式相对清晰的设备。MCU 没法替代云端但它能把预测性维护的“最后一公里”打通在设备旁边持续监测、实时判断、断网也能兜底只在必要时上报。这就够了。2. 端侧预测性维护的完整技术链路从一线传感器到退化指标2.1 信号采集决定你后面所有 AI 工作的上限模型再强也是基于输入信号做判断的。传感器选错了采样率设低了那 AI 学到的东西从源头就是错的。这个环节我建议花大力气因为后期改造成本非常高。传感器选型方面工业现场常用 IEPE 压电加速度计精度高、频响宽但要恒流源供电外围电路复杂。在 MCU 做嵌入式监测的场景里MEMS 加速度计更常见比如 ADXL345 是数字输出便宜但噪声偏大ADXL357 是低噪声高分辨率适合做振动监测的量级。如果设备恶劣、温度高、振动大可以选择量程 ±50g 的产品防止过载削波。安装方式也有讲究螺纹安装最好胶粘次之磁座最容易因吸附不牢导致额外共振频谱里多出莫名其妙的峰AI 会把这些当成故障特征。采样率怎么定工程上有个习惯倍数最大分析频率的 2.56 倍以上。电机转速 3000rpm基频 50Hz轴承故障特征频率往往到几百甚至几千赫兹所以主流采样率取 2560Hz 到 5120Hz。如果你做的是高速主轴或齿轮箱直接上 12.8kHz 留足余量。这里有个容易忽略的坑ADC 采样前必须有模拟低通滤波器也就是抗混叠滤波器。否则高频成分会被折叠到低频区间频谱里会出现根本不存在的假峰模型在训练时会学到虚假的故障模式。帧长和重叠率也要提前设计。2048 点或 4096 点一帧对应的频率分辨率大概是 1 到 2Hz对旋转设备来说够用了。相邻窗口重叠 50% 到 75%能提高故障特征的时间分辨率避免故障正好落在两帧之间的尴尬。多通道同步也很关键读数字加速度计的时候最好用一个硬件触发沿同时启动所有通道否则相位错位会导致后续频谱分析失败。数据格式上16bit 整型采集后在 MCU 内部统一换算成 g 值或 m/s²再做特征计算。不要直接拿 ADC 原始码值去训练模型的可迁移性和可解释性都会变差。2.2 特征工程的两种路线手工专家特征还是端到端小模型拿到原始波形后下一步是特征提取。这里有两条路线我实际工程中都用过各有利弊。路线 A 是手工特征加轻量模型。时域特征包括 RMS、峰峰值、标准差、峭度、偏度、波峰因数等这些计算量小、机理明确。比如 RMS 能反映振动总体能量峭度对早期冲击类故障敏感。频域特征是先做 FFT再提取基频、谐波能量、特定频段的能量占比。轴承外圈故障在包络谱里有明显的故障特征频率齿轮故障则表现为啮合频率边带。这种路线最大的好处是可解释性维修工程师看到某个特征超标能理解到底哪里出了问题。路线 B 是端到端小模型直接输入归一化后的时域窗口或频谱切片让卷积网络自动学特征。优点是省去大量人工构造特征的工程量模型对复杂工况的适应能力可能更强。缺点是需要更多训练数据对样本质量要求高而且在 MCU 上要跑的卷积算子会增加一些实现复杂度。我的实际做法是折中在 MCU 上先做轻量级 FFT 和时域统计提取几十个特征然后丢给一个小网络或树模型判断。这既能控制 MCU 的算力开销又能保留特征的可解释性。对于想快速跑通原型、验证可行性的人来说这条路是最稳的。2.3 从“故障分类”到“退化评分”业务真正要的是什么很多团队做预测性维护第一个版本就想着分类正常、外圈故障、内圈故障、滚动体故障。但实际运维的人真正想问的是这台设备还能撑多久也就是健康度评分。在 MCU 端我更建议做“连续性退化评分”。思路是这样的采集健康工况下的特征分布比如计算每个特征的均值 m 和标准差 s之后每来一帧数据计算当前特征向量与健康基线的偏差用马氏距离或标准化欧氏距离作为异常分数然后设置两个阈值一个警告阈值一个报警阈值。设备刚开始退化时异常分数不会突变而是缓慢上升。这比分类模型输出的 0.35、0.8 这类概率更容易被运维系统接受。分类模型适合故障诊断而退化评分适合预判维修窗口两者组合使用效果最好。模型输出这块也要做校准。分类器 softmax 输出的置信度并不等于真实概率尤其是训练数据不均衡时预测概率会有偏差。我在实践中会用温度缩放或 Platt Scaling 做概率校准否则阈值设了也没有可靠的数学意义。3. 从故障数据到 INT8 模型一份可复现的部署流程3.1 数据从哪来公开数据集、实验室台架和故障注入训练一个能工作的预测性维护模型第一件事是拿到“健康数据”和“故障数据”。健康数据很容易现场正常运行几小时就能攒一大堆。难的是故障数据。公开数据集是起步的利器。凯斯西储大学轴承数据中心CWRU、NASA/IMS 轴承数据集都比较常用涵盖了外圈、内圈、滚动体故障的不同尺寸和负载工况。但要注意公开数据来自实验室环境它的传感器安装、设备转速、负载条件和你现场的设备大概率不一致。直接拿公开集训练出的模型到现场几乎一定会掉点。我的办法是用公开数据做预训练再采集少量现场数据做微调。如果条件允许做实验室台架是最理想的选择。把轴承外圈用激光切割或电火花打一个小凹坑人为制造故障然后在不同转速、不同负载下采集数据。故障注入的尺寸要分级从微小的点蚀到明显的严重磨损都要覆盖模型才有机会学到“退化程度递增”的连续性。现场数据是最终验证场。一台设备从健康到故障的完整生命周期可能长达几个月甚至一年数据采集策略要有耐心。可以把历史维修记录和停机前的历史数据倒推出来作为初始故障数据。标签的准确度比样本数量更重要标签打错一个模型学到的就是错误映射。数据增强也很实用。给原始波形加少量白噪声、做小幅时间拉伸、随机缩放振幅模拟不同安装条件和环境噪声。这个操作能在不增加现场采集工作量的前提下显著提高模型鲁棒性。3.2 模型选型与训练一个小到能塞进 MCU 的 1D CNN关于模型选型我从不一上来就奔着大模型去。MCU 上的预测性维护模型参数量控制在几万以内比较合理。这里我给出一个自己验证过的 1D CNN 结构输入是 256 维的频谱或特征向量输出是 3 类故障状态。训练可以用 TensorFlow 写import tensorflow as tf from tensorflow import keras from tensorflow.keras import layers model keras.Sequential([ layers.Input(shape(256, 1)), layers.Conv1D(8, 3, activationrelu, paddingsame), layers.MaxPooling1D(2), layers.Conv1D(16, 3, activationrelu, paddingsame), layers.MaxPooling1D(2), layers.Conv1D(32, 3, activationrelu, paddingsame), layers.GlobalAveragePooling1D(), layers.Dense(16, activationrelu), layers.Dense(3, activationsoftmax) ]) model.compile( optimizeradam, losssparse_categorical_crossentropy, metrics[accuracy] )这个模型实际参数量在 1 万左右量化后不到 50KB对大部分 MCU 非常友好。训练时要注意不要随机打乱窗口后再切分训练集和测试集。因为相邻窗口高度相关随机切分会导致测试集被污染评估结果虚高。应该按时间段切分用设备早期数据训练后期数据测试模拟真实部署场景。其他模型选型对比方案优点缺点适用场景手工特征 决策树/XGBoost可解释性最好训练快依赖专家经验树库部署体积偏大特征明确、工况稳定1D CNN 频谱输入抗噪好模型小适合 MCU需要较多训练数据故障模式复杂的旋转设备TinyLSTM/TCN能捕捉慢退化趋势状态存储和计算开销大时间依赖明显的场景Autoencoder 重构误差无监督故障样本缺失时可用只能检测异常无法分类故障数据极少的冷启动阶段如果现场故障数据很少Autoencoder 方案值得做冷启动。用大量健康数据训练一个自编码器让它在健康数据上重构误差小在异常数据上重构误差大。这个思路在早期阶段能非常快地建立监测能力。3.3 量化与内存优化FP32 模型是给 PC 用的MCU 只认 INT8模型在 PC 上验证通过后不能直接把浮点模型塞进 MCU。MCU 虽然有些带 FPU但浮点计算比定点慢得多内存占用也大。所以必须做量化把权重从 FP32 压到 INT8模型体积减小到四分之一推理速度提升数倍。我用的是 TensorFlow Lite 后训练量化PTQ核心代码是converter tf.lite.TFLiteConverter.from_keras_model(model) converter.optimizations [tf.lite.Optimize.DEFAULT] converter.representative_dataset representative_gen converter.target_spec.supported_ops [tf.lite.OpsSet.TFLITE_BUILTINS_INT8] tflite_model converter.convert() with open(model.tflite, wb) as f: f.write(tflite_model)这里有个特别容易踩的坑representative_dataset 必须覆盖模型可能遇到的各种工况不能只放正常样本。我曾因为代表数据集只放了健康工况导致量化模型对故障样本的敏感度急剧下降。量化校准数据集取 100 到 500 个样本分布越广越好。量化之后转成 C 数组xxd -i model.tflite model_data.c生成的 model_data.c 里就是一个 const unsigned char model_data[] 数组直接编译进固件。部署时别忘了读输入张量的 scale 和 zero_point 参数否则你喂进去的数据和模型期望的数据不在一个数值空间推理结果完全不可信。3.4 在 STM32 上运行 TFLite Micro工程配置与推理调度部署框架我推荐 TensorFlow Lite for MicrocontrollersTFLite Micro它专门为 MCU 设计支持 ARM Cortex-M 系列配合 CMSIS-NN 可以进一步加速卷积。STM32 上的工程配置大概是这样的static tflite::MicroErrorReporter error_reporter; static const tflite::Model* model tflite::GetModel(model_data); static tflite::MicroMutableOpResolver10 resolver; resolver.AddConv2D(); resolver.AddMaxPool2D(); resolver.AddFullyConnected(); resolver.AddSoftmax(); static uint8_t tensor_arena[60 * 1024]; static tflite::MicroInterpreter interpreter( model, resolver, tensor_arena, tflite::MicroAllocator::Create(tensor_arena, sizeof(tensor_arena)), error_reporter);每次推理前把缩放后的特征写入输入张量调用 interpreter.Invoke() 读输出。我在实际工程里用 DWT-CYCCNT 寄存器测过推理耗时上面那个 1D CNN 在 100MHz 的 Cortex-M4 上整帧推理大概 20 到 60 毫秒对 1 秒一轮的监测来说绰绰有余。真正的难点不在推理本身而在调度。我的建议是ADC 用 DMA 连续采集采用双缓冲机制一缓冲采满后 CPU 处理特征提取和推理另一缓冲继续采集避免数据丢失。整个“采集-处理-推理-判断”是个流水线不要让推理阻塞采集。中断的优先级也要仔细配置推理任务放在后台不在高优先级中断里跑否则会打乱其他实时任务。3.5 验证模型别只看整体准确率要看时间维度和代价模型在开发机上验证准确率 98%不代表到了现场就是神机。我见过太多团队在这个点上翻了车。验证的时候不要只按样本算准确率要按时间序列去评估让模型连续处理一段完整的监测数据看异常分数是否随着设备状态恶化而单调上升看是否有突兀的单点误报。这种时间维度上的稳定性比整体准确率更重要。还有个容易忽略的矩阵是代价矩阵。不同的错误类型代价完全不同。该报警没报警可能导致设备损坏、产线停机代价可能是几十万而误报警最多让运维人员跑一趟代价是几百块。所以在选择阈值时评估指标应该加权而不是简单找准确率最高的点。4. 现场校准与阈值设定比训练更耗神的部分4.1 基线漂移和工况变化你标注的“正常”不是永远的“正常”模型训练到部署只是完成了 60% 的工作。剩下的 40% 是现场调试而这个环节往往比训练模型更耗时间。最大的坑是什么基线漂移。一台设备冷启动和热稳定后的振动水平完全不同。泵在空载和满载时振动特征差距巨大。新风机的安装基础、温度环境也会影响振动特性。你拿 3 月份采集的正常数据做基线到 7 月份设备热膨胀变化正常数据分布已经完全偏移了。我的解决方案是把数据按工况分段建基线。不只记录振动信号还要同步采集转速、负载电流、温度等辅助变量。模型推理时先判断当前工况再调用对应的基线。如果没有这些辅助变量至少要在软件里留一个人工切换工况的入口让运维人员根据实际运行状态设置。4.2 阈值怎么定阈值不是 0.5而是来自代价函数很多人在模型输出层用 softmax然后默认取 argmax阈值就卡在 0.5。这是分类任务的惯性思维但在预测性维护里行不通。我建议把阈值选择当做一个代价优化问题。列出四种情况正常识别为正常、故障识别为故障、正常误报为故障、故障漏报为正常分别估一个代价。比如故障漏报代价是 20 万正常误报代价是 500 元。然后扫描阈值计算在这个阈值下的总代价选择总代价最低点。实际操作中我还会设两个阈值形成“黄区”和“红区”。异常分数超过警告阈值只记录并在软件界面里提醒不打扰运维人员超过报警阈值才发短信或推送。这样既不会漏掉早期退化趋势又不会因为误报让运维人员疲劳。4.3 多设备迁移与模型版本管理同型号设备不能“一次训练到处部署”就算两台设备型号相同、安装位置相同振动特征也会有差异。因为轴承预紧力、对中精度、基础刚度不同。所以模型迁移时至少要做基线重新校准也就是用目标设备几小时的健康数据重新计算基线分布。条件允许的话用少量故障样本做模型微调效果会更好。这里还有个工业现场常常忽略的问题模型版本管理。我见过 OTA 升级后某台设备的报警策略突然变化结果没人能说清楚是模型变了还是设备真出了问题。所以模型文件要带唯一版本号、训练时间、训练数据范围、部署设备列表。每次升级要能回滚最好先在 1 到 2 台试点设备上跑一段时间验证没问题再全面推广。5. 我在 MCU 预测性维护项目里踩过的几个真坑5.1 传感器安装位置一变整个模型直接失效有一次我把振动传感器从轴承座的螺纹安装孔换到旁边的磁性底座上结果频谱里出现了一大堆新的共振峰。模型的故障评分直接从 0.2 飘到 0.8差点触发报警。原因很简单磁座相当于在振动路径里加了一个弹簧-质量系统改变了传感器感受到的频响特性。从那以后我在项目文档里强制要求传感器安装点必须在整机设计图中固化不同设备要保持同一位置。现场施工时如果确实需要改变安装位置必须重新做基线校准而不是指望模型自适应。5.2 地环路和电源噪声让模型学到的不是故障而是电磁干扰实验室里调好的模型到工厂现场就疯狂误报。排查了很久最后把传感器电源和电机变频器电源分开用差分输入症状才消失。原来现场的变频器开关噪声通过地环路进入了信号链路频谱上 50Hz、100Hz 及其谐波的能量异常高。这个问题的教训是信号链路的设计必须从第一天就按工业现场标准做。传感器供电要隔离ADC 用差分输入必要的时候加 50Hz 陷波滤波器。训练数据里如果只有实验室本底噪声模型就学不会分辨“真实故障”和“工业噪声”现场必然翻车。5.3 看门狗和推理任务互相打架系统频繁复位早期版本我把推理函数放在一个高优先级中断里执行结果推理耗时太长主循环里的看门狗没有得到及时喂狗系统反复复位。后来把推理放到后台任务里看门狗喂狗不在推理期间执行问题才解决。推理耗时不是固定的受中断频率、缓存命中率影响会波动。所以看门狗超时时间一定要留足余量按最坏情况推理时间再乘 1.5 到 2 倍来设置。不能因为引入 AI 推理把系统稳定性搭进去。5.4 连续采集加满负荷推理电池供电项目三个月就废了有个无线传感器项目计划用电池支撑一年结果三个月就断电了。一测功耗才发现MCU 在全速跑 FFT 和 CNN 推理时加上传感器和无线模块平均电流大得惊人。后来改了采集策略设备状态比较平稳时每 10 分钟只采集 1 秒数据做一次推理其余时间系统进入 STOP 模式。只有异常分数超过阈值时才切换到连续监测模式并提高上报频率。这样功耗下降了至少一个数量级。对旋转设备这类慢退化对象根本不需要每时每刻都在算睡眠唤醒的周期策略远比“一路高功耗运行”实用。5.5 不是所有故障都靠振动信号就能提前预测做预测性维护项目选切入点时要分清哪些故障能从振动信号里看出苗头。轴承故障、不平衡、不对中、基础松动这些在振动信号里表现明显是很好的切入点。但电机绝缘老化、电子器件失效、润滑油变质这类问题振动信号往往不敏感需要电流分析、温度监测、油液分析等多模态手段。所以不要一上来就想着建一个万能模型。先选一台故障模式清晰的设备做试点把链路跑通用真实效果说服团队再逐步扩展。这条路虽然慢但每一步都稳。6. 如果让我再做一次这类项目我会把顺序调整成这样最后聊聊我个人的体会。第一个建议是“先跑链路再上 AI”。很多人一听到预测性维护就急着训练模型。但实际上把传感器、采集、存储、可视化链路跑通能连续稳定地拿到一周以上的真实数据这件事比模型本身重要得多。数据链路不稳后面所有工作都是空中楼阁。第二个建议是“云端训练、边缘部署、现场校准”三者缺一不可。模型首先在云端或 PC 上训练和验证然后部署到 MCU在现场用真实运行数据做校准。不要相信任何没有经过现场校准的离线模型。校准过程最好让设备运维人员参与进来因为他们最了解设备什么时候在什么工况下运行哪些报警是合理的哪些是误报。第三个建议是项目启动时保留足够的调试能力。MCU 端要留日志输出和安全升级通道这样模型出问题能及时定位和回滚。不要做“一次性写死”的固件因为模型一定会在现场迭代这是必然的。MCUs Enable AI-Based Predictive Maintenance 这个标题的真正含义是把 AI 的推理能力从云端下沉到设备侧用最小的代价完成最有价值的判断。这条路我已经验证过很多次可行但需要耐心。如果手上的项目刚起步别追求一步到位先把第一台设备的数据链路跑通让异常评分能真实反映设备状态你就已经超过了大多数停留在 PPT 和 Demo 阶段的团队。