我们厂里三台空压机、两条包装线过去一年因为非计划停机直接损失超过四十万。后来我把预测性维护这套东西真正落地了——用 MyEMS 做数据底座自己训练了一个 CNN-LSTM 混合模型把设备故障预警准确率做到了 92%。这篇文章就把整个实战过程拆开讲数据怎么接、标签怎么打、模型怎么调、告警怎么跟运维流程咬合每一步我都会说清楚当时为什么这么选踩过哪些坑。不管你是工厂设备管理员、做工业 IoT 的工程师还是刚接触预测性维护的学生照着这条链路走一遍至少能少走我半年的弯路。1. 项目背景与方案选型为什么是 MyEMS 加 CNN-LSTM1.1 预测性维护到底在解决什么问题先聊一个最基本的问题我们为什么需要预测性维护传统的设备维护无非两种模式。一种是坏了再修叫事后维护设备突然停机、产线中断损失最直接另一种是定期保养按固定周期换油、换轴承、清洁滤芯这比事后维护强但存在两个毛病——没坏也换浪费备件和工时坏了没到周期照样停机。预测性维护的思路是第三种通过设备运行数据实时判断健康状态在故障真正发生之前给出预警让维护人员有充足时间安排停机窗口、准备备件把非计划停机变成计划停机。这个项目的目标很明确以厂里的空压机系统为试点采集振动、温度、电流、压力等运行参数训练一个深度学习模型提前若干小时预测设备是否会在未来发生故障并且把误报率控制在可接受范围内。当时我们给项目定的指标是故障预警准确率不低于 90%提前量不少于 6 小时。后面实际跑出来的 92% 准确率就是在这个口径下统计出来的。1.2 为什么选 MyEMS 作为数据底座选型这件事我花了两周调研。市面上做设备数据采集和监控的平台很多商业软件功能全但授权费用高而且数据接口封闭想把自己训练的模型接进去做告警往往要折腾 API 甚至被拒之门外。开源自建的话又要考虑数据采集、存储、可视化、告警全套都要自己搭工作量不小。MyEMS 是行业里比较成熟的开源能源管理系统它本身的定位是能源管理但底层的数据采集、时序数据存储、历史曲线、报表和告警推送模块都非常完整。我实际用下来最大的感受是它的数据模型是围绕设备点位来设计的每台设备的每个采集项天然就是一个点位这跟做设备健康监测的数据结构几乎完全一致不需要做太多二次抽象。另一个关键点是 MyEMS 的告警模块可以直接复用。它支持自定义告警规则告警触发后可以推送到企业微信、短信、邮件。我们训练好的模型输出一个故障概率值本质上也是一个点位数据只要把这个值写进 MyEMS 的点位体系告警联动就全打通了。这比从零开发一套告警通知系统省太多事。1.3 CNN-LSTM 选型的逻辑以及为什么不试 SVM 和单纯 LSTM模型选型是另一个重要决策点。我最初其实先试过传统机器学习方案比如 SVM 和随机森林。它们在小样本、特征清晰的任务上表现不错但我的场景有个特点设备故障是时序事件早期征兆往往藏在振动信号的局部模式变化里比如一个特定频率分量在几十秒内出现小幅抬升。这类局部时序特征传统机器学习模型需要人工去提取工作量极大而且不同故障类型对应的特征频段还不一样很难用一套手工特征全覆盖。单纯用 LSTM 也能处理时序数据它擅长捕捉长时间依赖关系比如温度缓慢爬升这类趋势性变化。但 LSTM 对局部短时模式比如振动脉冲、电流突降又恢复的识别能力偏弱而这些短时模式恰恰是很多机械故障的早期信号。CNN 擅长的事正好是提取局部特征。一维卷积可以沿时间轴滑动自动抓取短窗口内的模式变化。所以 CNN-LSTM 混合结构就是让 CNN 先做特征提取器把原始时序数据中的局部模式抽出来再把抽象特征序列喂给 LSTM让 LSTM 去学习这些特征在更长时间尺度上的演变规律。打个比方CNN 像是值班巡检员盯着最近几秒钟的仪表读数发现异常波动立刻记下来LSTM 像是老班长把值班记录一条条串起来判断设备整体状态是不是在持续恶化。两者配合既有局部敏感度又有全局趋势判断力。2. 数据链路搭建从设备传感器到训练样本的完整管道2.1 传感器点位设计与采集策略数据是整个预测性维护项目的地基这步做得不好后面模型再先进都是白搭。我们工厂的空压机是螺杆式空压机故障类型主要集中在轴承磨损、转子不平衡、进气阀卡滞、温度异常这几类。针对这些故障模式我当时设计了以下采集点位点位名称传感器类型采样频率安装位置对应故障征兆振动加速度IEPE 加速度传感器20 kHz驱动端轴承座轴承磨损、转子不平衡排气温度PT100 热电阻1 Hz排气口冷却不良、阀件卡滞排气压力压力变送器1 Hz排气管道负载异常、泄压电机电流电流互感器10 Hz电机进线端负载突变、堵转润滑油温度PT100 热电阻1 Hz油路润滑不良、轴承故障这里有一个需要特别说明的点振动信号的采样频率为什么定 20 kHz。根据奈奎斯特采样定理采样频率至少要是信号最高频率的两倍。螺杆空压机的转子转速一般在 3000 转/分左右基频是 50 Hz但轴承故障的特征频率往往是基频的数倍到数十倍特别是早期点蚀产生的冲击脉冲能量集中在 1 kHz 到 10 kHz 的频段。20 kHz 的采样率可以覆盖到 10 kHz 的分析频段既能捕捉到早期故障信号又不至于因为采样率过高而产生海量数据。如果你只关心温度和压力这类缓变参数1 Hz 采样完全够用没必要高采样率浪费存储。2.2 数据清洗与特征工程原始数据拿到手第一件事不是建模而是清洗。工业现场的传感器数据质量远比论文里的理想数据集要脏。我遇到过的问题大概这几类第一类是数据缺失。网络闪断、传感器临时离线、PLC 扫描周期抖动都会导致时间序列里出现空洞。处理方案是分情况对待缺失时间短比如几秒内用线性插值补齐缺失时间长超过 5 分钟直接丢弃这一段不参与样本构造。为什么因为长时段缺失后传感器恢复瞬间的数据往往有异常跳变硬插值会把假特征喂给模型。第二类是异常值。传感器受到电磁干扰偶尔会出现一个远超出物理量程的尖峰比如温度突然从 80 度跳到 800 度又跳回来。这类尖峰必须剔除做法是用中值滤波加阈值判断计算每个点与前后 5 个点中位数的偏差超过设定阈值就标记为异常用中位数替换。特别提醒异常值剔除一定要在特征工程之前做否则那些统计特征均值、方差会被尖峰污染得一塌糊涂。第三类是趋势项消除。振动信号的均值会随工况缓慢漂移如果直接把原始波形丢给模型模型会学到均值越高越危险这种错误规律。解决办法是对振动信号做高通滤波或减去滑动平均值只保留波动成分。做完清洗之后就要把原始波形转换成模型能吃的特征。我采用的方法是滑动窗口切分加统计特征提取。具体做法是以 30 秒为一个窗口对窗口内的振动信号做 FFT 变换提取频段的能量分布比如 0-100 Hz、100-500 Hz、500-2 kHz、2 kHz-10 kHz 四个频段的均方根值同时计算时域特征包括峰值、峰峰值、峭度、波形因子、脉冲因子。温度、压力、电流这些缓变参数直接在窗口内取均值、标准差和斜率。这样每个样本就是一组 20 维左右的特征向量既保留了原始信息的关键部分又大幅降低了数据维度。2.3 故障标签体系构建最容易翻车的一步模型训练需要标注数据也就是得知道每个时刻设备是健康还是故障。这一步看着简单实际上是最容易翻车的环节。因为设备在真实故障之前会有一个退化的渐变过程从完全健康到彻底失效之间并没有一条清晰的界线。我们的标注策略分三层。第一层是故障期标注以设备真正停机或检修记录确认故障的时间点为 T0向前回溯一段时间我们取 12 小时这段区间标记为即将故障标签为 1。第二层是健康期标注取故障发生前 72 小时以外的正常运行数据以及设备刚完成保养后一周内的数据标记为健康标签为 0。第三层是模糊期T0 往前 72 小时到 12 小时之间这是退化的开始阶段特征可能与健康时重叠我们不把这段数据用在二分类训练里等模型跑通后再单独验证它能不能提前识别。这里有个容易被忽略的细节行业里常说的稀有类别问题在你做故障预测时几乎一定会遇到。设备绝大多数时间是健康的故障样本占比可能不到 1%。如果直接把原始数据喂给模型模型会把所有样本都预测成健康准确率照样很高因为 99% 的样本都猜对了但这恰恰是我们要避免的陷阱。解决办法是重采样。健康样本量大采用欠采样随机抽取与故障样本数量相近的健康样本如果故障样本太少则采用过采样用滑动窗口重叠的方式从有限故障段里切出更多样本。我当时还用了数据增强的技巧把健康样本切片加一点随机高斯噪声增加模型对噪声的鲁棒性。3. CNN-LSTM 模型设计与训练细节3.1 模型结构拆解每一层在干什么我用 TensorFlow 框架构建模型整体结构分为四段。第一段是输入层每个样本是一个时间序列块具体格式是 30 个时间步、每个时间步 20 维特征也就是一个 30x20 的矩阵。为什么是 30 个时间步因为前面滑动窗口是 30 秒我又把每 30 秒的特征聚合为一个时间步这样模型能看到最近 15 分钟30 步 x 30 秒的设备状态演变。第二段是 CNN 特征提取层。我堆叠了两层一维卷积第一层 64 个卷积核、卷积核大小 3第二层 128 个卷积核、卷积核大小 3激活函数用 ReLU。每层卷积后接一个最大池化层池化窗口为 2。卷积核大小 3 意味着每个卷积操作覆盖相邻 3 个时间步。这个设计意图是让模型学会识别局部三步变化模式比如温度连续三个时间步持续爬升、振动能量突然跳增并持续这些都是故障的局部前兆。第三段是 LSTM 时序建模层。CNN 输出的是一个更高层的特征序列我把这个序列喂给一个包含 64 个隐藏单元的 LSTM 层。LSTM 在这里的作用是把 CNN 提取的局部特征串起来学习它们在 15 分钟尺度上的演化规律。我加了 Dropout 层丢包率 0.3用来防止过拟合。第四段是输出层。LSTM 的输出经过一个全连接层16 个神经元最后通过 Sigmoid 激活函数输出一个 0 到 1 之间的故障概率值。模型结构对应的伪代码如下from tensorflow.keras.models import Sequential from tensorflow.keras.layers import Conv1D, MaxPooling1D, LSTM, Dense, Dropout model Sequential() # 第一段卷积层提取局部时间模式 model.add(Conv1D(filters64, kernel_size3, activationrelu, input_shape(30, 20))) model.add(MaxPooling1D(pool_size2)) # 第二段卷积层更高层抽象特征 model.add(Conv1D(filters128, kernel_size3, activationrelu)) model.add(MaxPooling1D(pool_size2)) # LSTM 层学习长时间依赖 model.add(LSTM(units64, return_sequencesFalse)) model.add(Dropout(0.3)) # 输出层 model.add(Dense(16, activationrelu)) model.add(Dense(1, activationsigmoid)) model.compile(optimizeradam, lossbinary_crossentropy, metrics[accuracy])3.2 训练策略与关键参数调优数据准备好了结构定了接下来就是训练。我前后跑了大概六十多组实验可以说调参的过程才是真正把准确率从 80% 推到 92% 的关键。几个核心参数的调整逻辑如下先说损失函数。二分类任务最常用的是二元交叉熵。但我在训练初期发现一个问题故障样本虽然做了重采样但模型还是倾向于输出偏小的概率值也就是宁可漏报也不误报。这是因为设备健康数据的模式比较集中模型对健康模式学得过于自信。解决办法是用带权重的交叉熵给故障样本的损失乘以一个权重系数让模型对故障模式的误判付出更大代价。我实验下来权重系数设在 3 到 5 之间效果较好太小起不到修正作用太大模型又会过度敏感导致误报增多。最终我选了 4。再说学习率。这是个经典问题学习率太大会震荡损失降不下去太小收敛又太慢。我用的是自适应学习率优化器 Adam初始学习率设置为 0.001。另外加了学习率衰减策略每当验证集损失连续 5 个轮次不下降学习率就乘以 0.5。这个策略实测效果很明显模型在 50 个轮次之后还能继续缓慢优化而不是早早停在平台期。批次大小设的是 64。这个参数影响训练稳定性和显存占用。批次太小时梯度噪声大训练不稳定批次太大时模型容易陷入局部最优。64 是个比较中庸的取值实测收敛曲线平稳。训练集验证集测试集的划分我按时间顺序来切分而不是随机切分。这一点非常重要。时序数据如果随机切分会让模型在训练时看到未来的数据测试评估时就会虚高。我的划分方式是取前 70% 时间段的数据做训练中间 15% 做验证最后 15% 做测试。同时保证故障和健康样本在每个集合里的比例大致一致。3.3 92% 准确率是怎么统计出来的说一个很多人做预测性维护项目时会犯的迷糊混淆了分类准确率和预警准确率。分类准确率是模型对所有样本判断正确的比例包括健康样本也占分母。而预警准确率我们项目里定义的是在所有模型发出预警的事件次数中真正发生了设备故障的比例也就是精确率Precision。为什么用精确率作为核心指标因为在真实运维场景里误报的成本很直接。运维人员接到告警要停线检查、要安排人手、要写记录如果模型三天两头报假警大家对系统的信任度会迅速下降最后干脆把告警屏蔽掉。所以我们在项目指标里明确预警准确率 90% 指的是精确率不低于 90%。最终测试集的结果是模型一共发出了 25 次故障预警其中 23 次对应的设备在提前 6 至 20 小时内真的出现了故障精确率 92%。同时漏报率约 12%也就是 100 次真实故障里大约有 12 次没有被提前预警。这个漏报率我们当时认为可以接受因为模型的价值在于把大多数故障提前识别出来而不是100%完备。另外模型性能评估我还看了 AUC 曲线下面积最终在 0.95 左右。AUC 的意义在于衡量模型在所有概率阈值上的综合区分能力0.95 说明健康样本和故障样本的概率分布重叠部分很小模型整体区分度很好。实际部署时把输出概率大于 0.7 判定为故障预警小于 0.3 判定为健康中间 0.3 到 0.7 设为观察区只记录不告警。这个阈值设置尽量靠经验测试。4. 部署落地与告警联动模型从实验室到车间的最后一公里4.1 模型服务化ONNX 导出与推理接口模型训练好了不能放在 Jupyter Notebook 里当摆设。部署的第一个问题是模型服务化。我们有两条路可以选一是用 TensorFlow Serving 搭一个完整的模型服务功能强大但比较重还需要单独维护一个服务进程二是把模型导出成 ONNX 格式用 ONNX Runtime 做推理轻量且容易嵌入现有系统。我选了第二种。原因很简单我们的推理频率不高每 30 秒对每台设备跑一次预测ONNX Runtime 的 CPU 推理延迟大约在 20 毫秒以内完全够用没有必要引入 GPU 和重框架。导出用 tf2onnx 工具一行命令搞定python -m tf2onnx.convert --saved-model ./saved_model \ --output ./cnn_lstm_model.onnx \ --opset 13推理代码封装成一个 Python 模块提供 predict(features) 接口输入 30x20 的特征矩阵输出故障概率。这个模块跑在厂里的边缘服务器上服务器通过 Modbus TCP 从 PLC 读取传感器数据计算特征后调用模型推理再把结果写入 MyEMS 点位系统。这样整个链路就通了传感器到 PLCPLC 到边缘服务器边缘服务器处理后进 MyEMSMyEMS 负责展示和告警。4.2 通过 MyEMS 告警模块实现及时通知MyEMS 的告警模块本身支持在值域变化时触发规则。我的做法是把模型输出的故障概率作为一个虚拟点位注册到 MyEMS 设备模型中点位 ID 设为air_compressor_1_fault_prob。然后在告警规则里配置当这个点位的值大于 0.7 时触发一级预警大于 0.85 时触发二级严重预警。一级预警推送给当班设备工程师二级预警同时推送给设备主管和厂长。告警消息模板我设计得很具体不是简单一句设备可能故障而包含设备名称、故障概率、预测的故障类型模型同时输出故障类别、建议的检查项。比如1号空压机驱动端轴承故障概率 0.86建议检查轴承振动频谱准备备用轴承安排 4 小时内停机检查。这样的告警信息运维人员拿到手就知道下一步该干什么不用再去翻数据。MyEMS 映射点位和配置告警规则这一步不同版本界面略有差异但核心逻辑是一致的先建点位再建规则规则绑定点位。在测试阶段我建议把告警阈值临时调低到 0.5故意制造几次告警验证通知链路是不是通的。这个验证一定要做我一开始就是忽略了它结果模型上线当天告警推送失败排查了半天才发现是消息网关配置里漏填了密钥。4.3 运维闭环告警之后的动作流程预测性维护系统不是模型输出一个告警就结束了真正的价值在告警后面的运维闭环。我们把整个流程分成四个环节告警确认、诊断分析、维护执行、效果复盘。告警确认环节接到告警后运维人员在第一时间手动确认设备当前状态。有时候是传感器误报模型确实发现了异常模式但那个异常模式是外部原因导致的比如旁边设备启停造成的电压波动并不是设备本身故障。这时候在系统里标记为外部干扰已排除这个反馈数据后续可以用来优化模型。诊断分析环节系统自动调出该设备最近 24 小时的振动频谱、温度趋势、电流曲线运维人员结合模型输出的故障类别确定故障部位和严重程度。我的经验是模型给出的故障类别判断在七八成的情况下是靠谱的剩下两三成需要运维人员结合频谱图人工确认。维护执行环节根据诊断结果安排维护。如果故障概率高且影响产线运行立即安排停机检修如果还有缓冲时间就排入计划维护计划。这部分跟厂商的备件库联动提前锁定备件避免临到检修发现没库存。效果复盘环节每次维护完成后把实际的故障原因、更换的部件、维护耗时登记到系统里。这些信息是最宝贵的模型优化素材。我们统计了半年数据后发现轴承类故障占了总量的 46%于是我专门增加了针对轴承故障频段的特征这个改动直接让整体准确率提高了大约 3 个百分点。5. 常见问题与排查技巧这半年踩过的坑都在这里5.1 数据质量问题的排查思路我先列一个高频问题速查表这些都是实际运维中最常遇到的情况异常现象可能原因排查方法解决办法传感器读数恒定不变传感器断线或 PLC 通道死锁查看原始报文是否更新重启 PLC 通道检查线路端子数据跳变巨大电磁干扰或接地不良对比相邻设备读数加屏蔽层改善接地凌晨数据批量缺失网络交换机定时重启查交换机日志调整重启时间增加冗余链路模型预测概率长期偏高传感器安装位置松动检查物理安装重新紧固标定传感器零漂训练集和线上分布差异大工况变化季节、负载率统计特征分布对比定期增量训练引入新数据这里我要重点强调一个经验不要把时间浪费在完美清洗上。工业数据永远不可能是干净的追求 100% 的清洗质量会陷入泥潭。我一开始花了整整一周做数据清洗后来发现模型性能并没有显著提升。正确的做法是先做基础清洗去缺失、剔尖峰把模型快速跑通再根据模型预测误差分析有针对性地优化数据质量。模型本身就具有一定抗噪能力它能告诉你哪些噪声是关键的、哪些是可以忽略的。5.2 误报漏报怎么权衡一个真实的调优案例机型是 2 号空压机曾经连续三天半夜触发一级预警概率值在 0.72 到 0.76 之间徘徊。运维人员每次赶过去检查设备都正常运行振动值、温度都正常。这就是典型的误报。排查过程是这样的先看原始数据发现告警时间段内电流信号确实有轻微波动幅度大约 3%但振动和温度没有异常。我调出频谱图发现电流波动频率和厂区另一台大功率风机的启动时间完全吻合。原因清楚了那台风机启动瞬间的电流冲击通过共用变压器耦合到了空压机的电流互感器上属于电气干扰。这类问题的处理方案分两个方向。一是信号层面加滤波对电流信号做低通滤波去掉高频干扰分量二是逻辑层面加确认机制模型连续三次预测概率超过 0.7 才真正触发告警单次突刺不告警。两个方案结合后这类误报基本消失了。但要注意确认机制会增加响应延迟三次预测之间间隔 30 秒意味着从首次检测到异常到发出告警有 90 秒延迟。对空压机这类设备90 秒延迟不影响预警提前量可以接受但如果是对响应时间要求极高的场景就需要缩短滑动窗口和预测间隔。漏报问题则往往是训练样本覆盖不全导致的。我们遇到过一例一台空压机的排气压力传感器缓慢劣化读数漂移但模型没有告警。原因是训练样本里没有包含传感器自身故障的数据模型只学了设备机械故障的模式。这类问题只能靠持续收集数据、不断补充训练样本来解决。模型上线后三个月我做了第一次增量训练把新收集的两个月数据混入训练集漏报率从 12% 降到了 8% 左右。5.3 模型退化的监控与重训策略深度学习模型上线后会面临一个客观问题模型退化。设备磨损特性会变、检修后状态会变、季节气温变化会导致温升基线漂移模型在旧数据上学到的规律会慢慢不适用。我的做法是建立三重监控。第一重是数据分布监控每周对比最近一周的输入特征分布和训练集特征分布如果 KL 散度超过阈值说明工况发生了显著变化需要触发重训。第二重是预测输出监控统计每周告警总量和告警确认率。如果告警量突然暴增而确认率大幅下降说明模型开始误报需要检查输入数据源头。如果告警量骤减可能是设备状态确实很好也可能是传感器出了问题信号根本没传上来。第三重是实际故障反馈监控每次停机维护后把实际故障情况跟模型预测做对照累积一定样本数量就评估一次精度。模型重训也不是每次都要从头训练。通常的做法是在原模型权重基础上继续训练也就是迁移学习思路。用最近三个月的新数据以较低学习率0.0001微调模型收敛周期短、数据需求少。只有在新数据与旧数据分布差异非常大时才考虑全量重训。我们基本上保持一个季度的重训周期但如果发生重大设备改造或更换核心部件会临时加训一次。最后再分享一个细节。模型上线时我给运维团队的承诺是92% 准确率但实际运行中这个数字是动态变化的。第一个月因为工况波动精确率掉到 86%当时压力很大。后来通过增加确认机制、补充训练数据才慢慢回到 90% 以上。预测性维护不是一次性项目它更像是一个需要持续灌溉的花园——模型只是种子数据、反馈、优化才是让它不断生长的养料。现在这套系统已经稳定运行了八个多月累计提前识别出 17 次设备故障其中至少 5 次是如果没有预警就会导致产线停机的重大故障。看到运维人员从最初的怀疑、到逐渐依赖系统、再到主动反馈维护结果我觉得这件事做得值。如果你正准备做类似的项目我的建议是不要一开始就追求大而全挑一台你最头疼的设备做试点跑通一个最小闭环让团队看到实际效果后面推起来会顺畅得多。