开头做设备维护这么多年最头疼的从来不是“设备坏了怎么修”而是“设备什么时候会坏、能不能提前知道”。传统的定期点检和事后维修要么保养过剩浪费工时要么突发停机直接打乱整个生产节拍。所以当预测性维护这个概念在工业圈里火起来之后我第一时间就把目光锁定在了数据驱动的故障诊断方向上。这次要聊的项目就是基于 MyEMS 能源管理系统做数据底座用 CNN-LSTM 混合模型对设备运行状态做故障预警最终在真实产线数据集上把预警准确率做到了 92%。如果你正在搭预测性维护系统手头有设备运行数据但不知道怎么处理或者已经在用 MyEMS 这类平台做能源管理却不知道怎么往智能运维方向延伸这篇文章应该能给你省下不少摸索时间。我会把整个项目从数据采集、特征工程到模型设计、训练调参、部署避坑讲透核心思路和踩过的坑都会交代清楚。1. 整体方案设计与技术选型1.1 为什么选 MyEMS 作为数据底座先说项目背景。现场车间里有十几台关键设备每台设备都接了温振传感器和电流采集模块数据先进 PLC再通过 Modbus TCP 上传到上位机。之前的做法是把数据落到 MySQL 里配合一套简单的阈值告警规则——比如温度超过 75 度就报警。这种方式有个明显的问题等温度真的冲到 75 度故障往往已经发生了根本没有提前量。而且单一阈值规则完全无法捕捉设备劣化的渐变趋势误报率也高得离谱。后来团队评估了几套方案最终确定用 MyEMS 作为整个系统的数据中枢。原因很简单MyEMS 本身就是一套开源的能源管理系统自带设备台账管理、数据采集接入、历史数据存储和基础的可视化看板功能。我们不需要从零开发一套数据平台直接复用 MyEMS 的设备管理模型和数据表结构把自己采集的温度、振动、电流数据作为能耗监测点位接入等于顺手把能源管理的经验迁移到了设备健康管理上。从实际使用体验来说MyEMS 的数据库结构很清爽设备信息、数据点配置、历史采样值都有对应的数据表二次开发接模型很方便。这也是后面做 CNN-LSTM 预测能落地的关键前提——数据清洗和特征提取必须建立在稳定、可追溯的数据存储基础上。1.2 为什么是 CNN-LSTM 而不是更简单的模型做预测性维护模型选型直接决定项目上限。我当时试过三条路线传统机器学习随机森林、XGBoost、单用 LSTM、以及 CNN-LSTM 混合模型。传统机器学习模型最大的问题是需要人工构造大量时序特征比如滑动均值、峰值因子、峭度、均方根等而且特征之间往往存在严重的多重共线性调起来非常耗时。XGBoost 这类模型对表格数据很强但原始传感器数据本质上是时间序列直接把原始信号丢给树模型效果很差必须做特征工程而特征工程的质量又非常依赖人的经验。单用 LSTM 能建模时序依赖但对局部模式的提取能力偏弱。简单说LSTM 擅长记住“过去一段时间发生了什么”却不擅长快速识别“这一小段波形里有什么异常特征”。而设备故障往往先从局部信号异常开始比如轴承点蚀会产生周期性冲击脉冲齿轮磨损会在啮合频率附近产生边频带。这些局部特征在原始波形里非常典型但被 LSTM 拿到之后容易被长程依赖稀释掉。CNN-LSTM 正好互补。CNN 用一维卷积核直接在时序窗口上滑动相当于自动做局部特征提取不需要人工算峭度、峰值因子这些统计量LSTM 再接在 CNN 输出的特征序列后面负责捕捉特征之间的时序演变规律。对于旋转机械这种“异常先局部、劣化后传导”的故障模式这个组合比任何单一模型都合适。1.3 技术路线与项目目标拆解整个项目的技术路线分为五层数据采集 → 数据清洗与预处理 → 特征工程 → 模型训练 → 预警结果落库与展示。第一层不用多说传感器信号经过 PLC 汇聚之后写入 MySQL由 MyEMS 统一管理。第二层负责剔除停机段、处理异常跳变和缺失值。第三层是基于滑窗切片的特征矩阵构建。第四层是模型训练、验证、调优。第五层把预测结果回写到 MyEMS 里后续可以直接对接看板和告警通知。项目目标不是“用上 AI”而是能提前一定时间预警设备故障并控制误报率在可接受范围内。我给自己定的指标是故障预警准确率不低于 90%每台设备每月误报不超过 3 次预警提前量至少比实际故障时间早 1 小时。92% 这个数字就是在这个目标体系下经过交叉验证得到的结果。2. 数据采集与预处理细节2.1 传感器测点布局与采样参数数据质量决定模型上限这句话在预测性维护里就是铁律。项目采集的是设备主轴轴承座位置的振动加速度信号量程 ±50g灵敏度 100mV/g和驱动电机三相电流信号通过电流互感器采集变比 100A/5A。振动采样率定在 12.8kHz电流采样率定在 6.4kHz每 10 秒保存一次 1 秒钟的数据块相当于每次保存 12800 个振动采样点和 6400 个电流采样点。这里有个经验采样率不是越高越好合适就行。12.8kHz 能覆盖到设备主要故障特征频率一般齿轮啮合频率在 2-5kHz 这个范围再高的话数据量翻倍存储和计算压力同步增大。数据块长度定为 1 秒是考虑到设备转速约 1470rpm约 24.5Hz1 秒钟能覆盖 24 个完整旋转周期足够捕捉轴承故障的周期冲击特征。2.2 数据清洗的坑停机段和跳变值原始数据拉回来第一件事不是建模型而是清洗。我踩过的最大的坑是停机段数据。设备不转的时候振动传感器输出的是环境噪音加传感器本底噪声幅值很低但电流数据可能有一点点残留。这些数据对模型没有任何学习价值反而会拉偏模型对“正常运行”状态的理解。清洗策略是先用转速信号做判据。MyEMS 里存了设备的启停状态点位训练时只保留状态为“运行”的数据段。没有转速信号的情况可以用电流有效值的阈值来判断三相电流的平均有效值低于额定值的 5% 时认定设备处于停机状态直接剔除。另一个坑是信号跳变。有一次排查误报发现某台设备连续出现虚假“故障预警”查来查去发现是传感器线缆接触不良信号偶尔会瞬间跳到满量程再瞬间掉回来。这种尖峰脉冲对 CNN 特别不友好因为卷积核会把它识别成一个强特征。处理办法是先用中值滤波把孤立尖峰消除掉再做后续分析。中值滤波窗口长度选 5既不会损伤真实冲击信号的幅值又能干掉单点跳变。2.3 滑窗切片与样本标签构造清洗完数据之后进入特征矩阵构建环节。这里采用的策略是固定长度滑窗切片。每个样本是连续 512 个振动采样点约 40ms加上对应时间段的电流有效值、转速、温度等低速变量的数值共同组成一个多通道输入。这里有个设计关键样本标签不能简单地按“正常”和“故障”二分类。设备故障是一个渐变过程从健康状态到严重故障之间往往经历数月甚至数年的劣化期。标签构造需要结合历史维修记录把设备停机维修前的一段时间标记为“即将故障”其余时间标记为“正常”。我当时的做法是根据历史维修工单把故障停机前 72 小时到停机时刻之间的数据标记为故障样本这个提前量可以根据设备维修响应时间调整。这个标签设计直接影响了模型的实用价值。如果只标记“故障时刻”模型学到的只是“已经坏了”的识别器而不是预警器。把故障标签提前 72 小时模型才有时间在设备真正停机之前发出警报真正实现“预测性维护”。3. CNN-LSTM 模型结构与原理拆解3.1 CNN 部分一维卷积如何提取局部异常特征先看数据输入维度。假设每个样本是 1×512 的振动信号加几个辅助变量那输入张量就是 (batch_size, 512, 1)。CNN 部分的第一层用一维卷积卷积核大小通常选 3、5 或 7。为什么不用更大的核因为设备的早期故障特征比如轴承外圈点蚀产生的冲击脉冲持续时间只有几个采样点太宽的卷积核会把脉冲和周围的正常信号混在一起反而模糊了特征。我最终用了两层一维卷积第一层 32 个卷积核核大小 7第二层 64 个卷积核核大小 5。每层后面接一个最大池化层池化窗口 2。最大池化的作用不是降维那么简单它可以让模型对冲击脉冲的微小时间偏移不敏感。同一个轴承故障每次出现的冲击位置可能有几个采样点的偏差最大池化能在一定程度上吸收这种时间抖动增加模型的鲁棒性。卷积层提取到的是局部波形特征但一个故障往往通过多个特征维度的组合来表征。比如轴承磨损既会产生周期性冲击又会导致频谱能量分布变化还会传递到电流信号引起波动。CNN 的多个卷积核天然就承担了“多通道特征提取”的角色不同的卷积核学到的是不同角度、不同频段的特征。3.2 LSTM 部分时序依赖与状态演化CNN 的输出是一个特征序列每个时间步对应原信号中的一小段局部特征。比如 512 个采样点经过两层卷积和池化后序列长度可能压缩到 64 个时间步每个时间步是一个 64 维的特征向量。这个序列直接输入 LSTM。LSTM 的核心能力是“选择性记忆”。每一个时间步它通过输入门决定“要不要记住当前这一步的特征”通过遗忘门决定“之前记住的信息要不要丢掉”通过输出门决定“当前时刻输出什么”。在设备故障演化的场景里这意味着模型可以捕捉到类似“前 10 个时间步冲击幅度稳定后 5 个时间步冲击幅度逐渐增大”这样的渐变规律。我这边的 LSTM 设置是两层隐藏单元数 128dropout 取 0.3。两层 LSTM 相比单层能学习到更高层次的时序抽象但层数再多就会出现训练困难。dropout 是为了防止模型对训练数据中的噪声模式过度拟合——工业现场的数据噪声模式太多如果模型连传感器的一点小波动都记住了到新数据上预测效果必然崩。3.3 全连接层与训练策略LSTM 最后一步的隐藏状态会接一个全连接层输出两个节点的 logits对应“正常”和“即将故障”两个类别。这里我没有把所有时间步的隐藏状态都取出来做处理而是只取最后一步。原因很简单在故障预警场景下最后一步的隐藏状态已经汇总了整个时间窗内的历史信息再叠加所有时间步只会增加参数量对准确率帮助有限。损失函数用交叉熵优化器用 Adam初始学习率 1e-3。训练时用了早停机制验证集 loss 连续 5 个 epoch 不下降就停止训练避免过拟合。批大小 64最大训练 60 个 epoch。这些参数不是拍脑袋定的都是实际跑了几轮实验之后调出来的最优组合。比如学习率用 1e-3 时前 10 个 epoch 收敛很快后面改成阶段性下降到 1e-4 之后继续微调权重整个过程的损失曲线比较平滑。3.4 评估指标92% 是怎么算出来的这里要特意强调一下评估方法。很多 AI 落地项目死在“准确率虚高”上——训练集和测试集来自同一时间段模型记住了噪声而不是规律。我做的是时间序列预测数据存在严重的时间相关性如果按普通的随机划分会让模型“偷看”未来数据评估结果毫无意义。我采用的划分方式是按时间顺序用前 70% 的数据做训练集后 30% 的数据做验证集和测试集。模拟的是真实的“用历史训练、预测未来”场景。最终测试集结果显示模型对故障样本的准确识别率为 92%正常样本的误判率控制在了 3.8%。这里“准确率”指的不是全量样本的简单准确率而是故障样本被正确预警的比例这个含义要分清否则容易被表面数字误导。4. 基于 MyEMS 的数据管道实现4.1 从 MyEMS 数据库读取监测数据MyEMS 的数据库里设备台账、数据点配置和历史值表格结构很规整。我们的监测点位在 MyEMS 里以“设备”和“数据点”两个层级管理历史采样值存在按时间戳记录的数据表里。训练模型前第一步就是把原始数据从 MyEMS 的 MySQL 数据库里抽出来。我用的是 Python 的 pymysql 连接库直接对 MyEMS 数据库做查询。查询条件一般包括设备编号、数据点名称、时间范围。核心 SQL 类似这样SELECT points.point_name, raw_history.value, raw_history.record_time FROM raw_history INNER JOIN points ON raw_history.point_id points.id INNER JOIN equipments ON points.equipment_id equipments.id WHERE equipments.equipment_name PAC-01 AND raw_history.record_time BETWEEN 2025-01-01 00:00:00 AND 2025-03-31 23:59:59 AND points.point_name IN (vib_x, current_a, temp_bearing) ORDER BY raw_history.record_time ASC;实际执行的时候要注意一点数据量非常大一次全查出来会占满内存。我的做法是按天循环查询比如每 7 天查一次边查边清洗边落盘。这里必须加索引否则按时间范围扫全表会把查询时间拉到无法接受的程度。MyEMS 默认就对 record_time 建了索引这块压力不大。4.2 特征矩阵构建示例代码数据从数据库拉出来之后需要按照 2.3 节里的滑窗逻辑切分成样本。这里用 Python 的 numpy 和 pandas 实现。振动信号是一个长时间序列按 512 个点一个窗口切片窗口之间有 50% 重叠这样能增加样本数量也能避免某个故障时刻恰好被窗口边界切掉的尴尬情况。下面是我在项目里实际用过的核心切片逻辑简化版本import numpy as np import pandas as pd def sliding_window(data, window_size512, step_size256): samples [] for i in range(0, len(data) - window_size 1, step_size): window data.iloc[i:iwindow_size].values samples.append(window) return np.array(samples) # 假设 raw_df 包含 vib_x振动和 label_actual实际状态标签 # 清洗后过滤停机段 running_df raw_df[raw_df[running_status] 1] # 按设备分组处理每台设备独立切片 samples sliding_window(running_df[vib_x], window_size512, step_size256) # 每个样本的标签取该窗口内出现故障标记的最大值 labels running_df[label_actual].rolling(window512, step256).max().dropna().values print(f切片后的样本数量: {len(samples)})标签计算使用窗口内的最大值这个操作要解释一下。如果一个 512 点的窗口内有任何一段属于故障预警期整个窗口都标记为故障样本。因为故障特征往往不是从窗口第一个点就开始出现的可能出现在窗口的后半段。如果只按最后一个点的标签来标记整个窗口会漏掉大量故障信息。4.3 多通道特征拼接与归一化振动信号只是模型输入的一部分。电流有效值、轴承温度这类低速变量虽然采样周期比振动慢得多但对设备劣化趋势的判断非常关键。比如轴承温度从 65 度缓升到 75 度这个过程在振动信号里可能不明显但温度趋势本身就是强烈的预警信号。拼接的方式是每个 512 点的振动窗口对应时间段内的温度平均值、电流有效值、转速平均值作为辅助特征拼接到这个样本的特征矩阵里。最终每个样本的输入维度是 512 个高分辨率振动点 3 个低分辨率状态量。这样相当于把高速信号和慢速趋势量放进了同一个输入空间让模型同时看到“细粒度波形”和“宏观状态演化”。归一化是最后一步也是很容易被忽略的一步。振动信号我用的是 z-score 归一化即减去训练集均值、除以训练集标准差。这里有个大坑归一化的均值和标准差必须只从训练集计算然后应用到验证集和测试集。如果直接用全量数据算均值方差会让测试集的信息泄漏到训练集评估结果偏乐观。5. 模型训练与调优实录5.1 环境配置与训练流程模型用 PyTorch 实现。硬件是单张 RTX 3090 显卡显存 24G训练数据集大概有 12 万个样本。最开始我担心显存不够实际跑起来发现完全没压力因为单样本输入很小512×4 的矩阵批大小 64 时单步计算很轻。训练流程分三步数据准备按 4.3 节的流程构建特征矩阵和标签按时间顺序切分训练集、验证集、测试集。模型实例化初始化 CNN-LSTM 网络设定损失函数、优化器和学习率调度器。迭代训练每个 epoch 结束后在验证集上评估监控 loss 和准确率触发早停条件就结束训练。核心模型结构定义大致如下import torch import torch.nn as nn class CNNLSTM(nn.Module): def __init__(self, input_channels4, cnn_out64, lstm_hidden128, num_layers2, num_classes2): super(CNNLSTM, self).__init__() self.conv1 nn.Conv1d(input_channels, 32, kernel_size7, padding3) self.pool1 nn.MaxPool1d(kernel_size2) self.conv2 nn.Conv1d(32, cnn_out, kernel_size5, padding2) self.pool2 nn.MaxPool1d(kernel_size2) self.lstm nn.LSTM(cnn_out, lstm_hidden, num_layersnum_layers, batch_firstTrue, dropout0.3) self.fc nn.Linear(lstm_hidden, num_classes) self.relu nn.ReLU() def forward(self, x): # x shape: (batch, seq_len, input_channels) x x.permute(0, 2, 1) # to (batch, channels, seq_len) x self.pool1(self.relu(self.conv1(x))) x self.pool2(self.relu(self.conv2(x))) x x.permute(0, 2, 1) # back to (batch, seq_len, cnn_out) lstm_out, _ self.lstm(x) # 取最后一个时间步 last_out lstm_out[:, -1, :] logits self.fc(last_out) return logits5.2 从 86% 到 92%三轮关键的调优第一版模型跑出来测试集准确率只有 86%。这个数字单看不算差但距离项目目标的 90% 还有明显差距。我复盘了整个过程发现问题出在数据层面而不是模型结构上。第一个问题是设备之间的差异没被建模。车间里六台设备虽然型号相同但安装条件、负载特性、维护历史都不一样同一套模型参数很难适配所有设备。解决办法是加入设备编号的 one-hot 编码作为额外输入特征让模型能够区分不同设备的状态基线。仅仅这一个改动准确率提升到了 89%。第二个问题是窗口长度不够。512 个采样点才 40ms这对于捕捉轴承故障的周期性冲击来说够用但要判断“故障劣化趋势”需要更长时间跨度的信息。我在输入中额外拼接了一个低频趋势通道用一阶差分和滑动平均来表征信号在数分钟时间尺度上的变化。这个改动让准确率从 89% 跳到了 91.5%。第三个问题是类不平衡。故障样本占比只有大约 8%模型天然偏向把大多数样本预测为“正常”。我加入了类别权重交叉熵损失给故障样本更高的误分类惩罚同时用随机过采样对故障样本重复采样来平衡训练集的类别比例。最终把准确率稳定到了 92%。5.3 混淆矩阵与误报分析为了看清楚模型的真实表现我打印了测试集上的混淆矩阵和分类报告指标值故障样本总数测试集1860正确预警故障样本1711故障预警准确率92.0%误报警数量正常被预测为故障96正常样本误报率3.8%故障样本的 F1-score0.9096 次误报看着多但要放在时间维度上看测试集时间跨度 3 个月换算成“每台设备每月误报”大约是 1.8 次低于项目要求的 3 次可以接受。而且误报的样本大多集中在设备启停瞬间和负载剧烈波动的时段这些时段信号本身就有很强的扰动模型难以判断也是正常表现。在工程应用时可以在告警逻辑里加一个“连续 N 个窗口预测为故障才触发告警”的防抖策略可以进一步压低误报率。5.4 提前量评估预警时间够不够用准确率 92% 只能说明“判断得准”但预测性维护更关键的是“提前多久发现”。如果预警时间只有 10 分钟维修人员根本来不及准备备件和工单预警就没有价值。我对测试集中每台设备的故障预警提前量进行了统计结果如下85% 的故障样本在发生前至少提前 2 小时被模型标记为异常49% 的样本提前超过 24 小时出现连续异常信号平均预警提前时间约 18 小时中位数约 9 小时。这个时间窗口对现场维修安排来说非常理想。设备管理员有足够的时间通知维修班、确认备件库存、安排生产计划错峰停机而不是在故障发生那一刻被动响应。6. 常见问题与排查技巧6.1 数据不平衡怎么处理故障样本在整个生命周期里占比很小数据不平衡几乎是预测性维护项目的必经问题。我在处理时优先用的是类别权重方案而不是粗暴地删除正常样本。因为工业场景下正常样本本身信息量丰富删除会让模型失去对“正常状态多样性”的学习。如果故障样本实在太少比如不到总样本的 1%我的建议是先用异常检测思路比如只对正常样本做自编码器重建重建误差超过阈值判定为异常。这种“只学正常、不会正常就是异常”的方式在某些故障数据少的场景比有监督分类更实用。6.2 模型跑得准但一上线就崩这个现象有两种常见原因。一是归一化参数保存错误——推理阶段用的归一化参数必须和训练阶段完全一致否则输入分布一偏输出就乱。二是设备运行工况和训练数据分布不一致比如原来设备一直 80% 负载运行最近改成了 50% 负载模型没见过这种工况就会把正常的低负载状态判成异常。解决对策是定期用最新数据增量训练模型同时监控告警率的变化趋势如果告警率持续走高大概率是工况漂移而不是真的故障增多。6.3 推理延迟对预警及时性的影响模型推理延迟直接决定了预警系统的实效性。我部署时的目标是将单次推理延迟控制在 20 毫秒以内这样才能保证每 10 秒一次的预测周期不会产生累积延迟。实测下来纯 PyTorch CPU 推理下每个样本大概 35-45 毫秒明显超出预算。后来改用 TorchScript 脚本化模型并开启 CPU 推理优化将延迟压低到 15 毫秒左右。如果未来需要同时监测几十台设备就要考虑 ONNX Runtime 或 TensorRT 加速。实际操作中我用 ONNX Runtime 在同样 CPU 环境测试过批量推理时可以再把延迟压到 8 毫秒以下完全满足边缘计算节点的要求。6.4 传感器故障对模型的影响最后这点特别想说。模型再准也架不住传感器本身出问题。我在项目里给每台设备加了数据质量自检模块专门监测传感器信号的质量。如果信号出现持续为 0、恒定值、超出物理量程三种情况判断传感器失效直接跳过该设备的预测并发出传感器故障告警。不做这一层保护模型会把传感器断线产生的异常数据当成“新型故障”疯狂误报最后整个预测系统会被现场人员拉黑。几点实在的心得做完整套系统之后我最深的体会就是预测性维护真正的难点从来不在模型结构上而在数据管道的扎实程度。CNN-LSTM 只是一个特征提取器它能不能起作用取决于你交给它的数据是不是干净、标签是不是合理、评估方式是不是公平。对比试验里同样的模型结构数据清洗前后准确率差了将近 15 个百分点这个差距比任何模型调参都大。另外一个想分享的经验是不要一开始就追求复杂模型。MyEMS 平台上已经有大量的设备台账和能耗数据如果场景比较简单先用 LightGBM 加统计特征跑一版基准效果满足要求就直接用不满足再上 CNN-LSTM 也不迟。这套项目因为故障信号藏在振动波形里统计特征确实表达不出来才需要上深度学习。最后说下后续扩展。目前的模型对单台设备的故障预警已经比较稳定团队正在尝试把多台设备的特征合并成一个图结构用图神经网络建模设备之间的关联影响比如一条产线上游设备异常会对下游设备产生什么传导效应。如果你刚做完 CNN-LSTM 的单设备预测盯一下设备间关联这个方向可能是预测性维护下一个值得投入的突破口。