“这次换下来的 2 号循环水泵电机轴承离计划检修还有三个月。”拆开之后滚动体已经出现严重点蚀再让它跑上一周大概率会在夜班电力负荷最高的时候突然报过流跳闸。这种场景在很多工厂并不算特例——大部分中低速旋转设备的故障都是“温水煮青蛙”式发展出来的前面几周甚至一两个月电流、功率、温度这些参数早就悄悄偏离了正常形态只是现场没有人天天盯着趋势曲线看。真正让我把“预测性维护 MyEMS CNN-LSTM”这三件事串在一起的正是这个现场痛点。MyEMS 本身是开源能源管理系统擅长采集、存储和展示设备运行数据但它默认不带机器学习算法。我们要做的是在 MyEMS 这套数据底座之上用 CNN-LSTM 模型去学习设备故障前的劣化趋势再把模型推理结果接回 MyEMS 完成预警闭环。最终在循环水泵这个试点设备上拿到了“预警准确率 92%”的结果。这篇文章会把这条技术路线完整讲清楚。我不打算只讲模型结构因为真正决定项目成败的往往不是网络本身而是数据怎么清洗、标签怎么打、准确率口径怎么定义、线上怎么部署。下文从选题逻辑、样本工程、模型训练、指标评估、部署闭环到现场踩坑一条线走完。适合正在做设备健康管理、想用机器学习做故障预警又不太确定从哪下手的工程师。1. 预测性维护落地难的根源数据在、样本不全、指标混乱先说一个我观察到的普遍现象很多工厂早就有了 DCS、SCADA、能源管理平台日常运行数据一抓一大把但“预测性维护”这件事还是做不起来。原因不外乎三个数据散落在不同系统里没人整合故障样本太少或标签混乱算法没有高质量的训练素材还有一个更隐蔽的问题——项目组自己都说不清“准确率”到底指什么。1.1 事前预警和故障诊断是两件事很多团队把它们混着做故障诊断是故障已经发生或者特征已经非常明显的时候去定位“哪里坏了、为什么坏”。比如轴承温度超过 85 度系统弹出一条“轴承温度高”的报警这算诊断也算阈值报警本质上只是监测。预测性维护要的是“事前”信号——在故障真正发生之前的 24 小时、48 小时甚至更早告诉运维“这台设备大概率正在劣化建议安排检查”。这两者的工程难度完全不是一个量级。把二者混着做的后果就是很多号称“预测性维护”的项目实际交付物只是一堆上下限阈值报警。这种方案根本不需要机器学习也不需要 CNN-LSTM配置几条报警规则就够了。真正值得上模型的恰恰是那些阈值还没超标、但运行趋势已经在变化的时间段。1.2 MyEMS 在项目里的定位统一采集、统一存储、统一展示MyEMS 给我的感觉是它把“工业数据进得来、存得住、看得见”这三件事做得很扎实。它支持通过 Modbus 等常见工业协议采集设备数据历史数据落到 MySQL 一类的关系库里前端自带看板、报表、告警和 API 接口。对做算法的人来说最大的价值是省掉了最痛苦的“数据管道整合”环节——泵、风机、电机的电流、功率、温度、压力不再散落在不同系统里而是已经在同一个平台拉历史数据、取实时数据都方便。需要强调一点MyEMS 本身不内置 CNN-LSTM也不负责训练模型。更准确的说法是MyEMS 负责采集和存储设备运行数据我们用独立的环境基于这些数据训练模型推理完成后把结果回写进 MyEMS用它的界面和告警能力做展示通知。这个“数据底座 外部训练 结果回流”的架构是当前比较可复制的一条路径也避免了为了一个算法去改造能源管理平台核心代码的尴尬。1.3 项目背景为什么选循环水泵做试点我们最终选的是车间循环水泵而不是某台精密机床或者大型压缩机原因很简单泵、风机、压缩机这类旋转设备故障模式相对连续比如轴承磨损、对中不良、润滑劣化都属于渐变性故障。渐变意味着运行特征在故障前的一段窗口里会留下“脚印”机器学习才有东西可学。另外还有一个很现实的理由循环水泵的维修工单和故障记录比较完整。标签是预测性维护项目里最容易卡壳的环节而这类设备有历史检修记录我们可以相对准确地把“故障发生时间点”标出来样本质量才能有保障。像雷击、断轴这类突发型故障目前的技术路线很难提前预报也不适合放在第一批试点里。2. 喂给 CNN-LSTM 的不是原始数据而是“标注好的劣化窗口”很多第一次做工业时序预测的同学拿到数据后第一反应就是把 CSV 丢进模型。结果往往是训练 loss 降得不错一到线上就失灵。问题基本都出在“训练数据”和“模型想要的输入”之间差了好几步——特征没选、窗口没切、标签没标、清洗没做。下面把每一步掰开说。2.1 特征通道怎么选不要一上来就堆几十个点我见过不少项目把所有能采集的模拟量全部塞进模型几十个通道觉得“数据越多模型越聪明”。实际效果通常相反特征多了之后模型参数变多、过拟合风险变大而且线上某个传感器一断流整个推理链路就崩了。我们的做法是先看物理过程再选通道。以循环水泵为例最终保留了 8 个特征通道A 相电流、有功功率直接反映电机负载和摩擦变化轴承磨损初期阻力增加电流功率会缓慢抬升。泵进出口压差反映水力状态叶轮磨损或管路异常时压差曲线会变。电机轴承温度、电机绕组温度热积累信号对润滑劣化比较敏感。泵体振动烈度如果现场有振动变送器可作为一个强预测通道。运行状态开关量用于区分启停防止把停机状态当异常。环境温度作为工况补偿避免季节变化导致误报。选完通道之后我们还会做一次简单的相关性和趋势目视检查把那些“故障前看不出任何变化”的点删掉。10 个以内通道足够关键是有物理含义而不是盲目堆维度。2.2 时间窗口与滑窗采样模型看多长、怎么滑动CNN-LSTM 吃的是一个三维张量形状是样本数时间步数特征通道数。这里的“时间步数”就是一次输入里包含多少个连续时间点。MyEMS 里很多点位是分钟级入库的如果 15 分钟一条记录64 个时间点适合看 16 小时之内的短期波动256 个时间点相当于 64 小时能覆盖更长的劣化趋势但也意味着模型更复杂、训练更慢。我们在试点里折中选了 128 个时间步。这个窗口大致覆盖 32 小时轴承磨损这类发展较慢的故障32 小时里已经能看出明显的电流或温度趋势变化短时扰动又不容易在 128 个点里形成假信号。滑动步长取窗口的四分之一也就是每次前进 32 个点相邻样本之间有 75% 的重叠。重叠的意义在于两点一是样本量成倍增加缓解工业故障样本稀缺的问题二是劣化过程本来就是连续的滑窗之间有重叠也更符合实际。2.3 标签制作故障记录如何变成正负样本这是整个项目里最容易被低估、也最影响准确率的一步。模型不是凭空学会“预测故障”的它学的是“把某一段输入和某个标签对应起来”。我们以维修工单或停机故障记录里的实际故障时刻 t_fault 为基准点把 [t_fault - 48h, t_fault] 这个时间范围内的滑动窗口标记为“正样本”也就是“故障前劣化段”。其余正常运行段一律标为“负样本”。这里有几个细节很关键故障前的预警窗口不宜太长。标成故障前 30 天模型会学不到“临近故障”的紧迫感线上很容易提前很久就报警运维没法处理。停机检修段、计划维护段要单独剔除。设备停机时温度下降、电流归零这类数据如果混进正样本模型学到的会是“停机模式”而不是“故障前劣化模式”这是很容易踩的坑。一台设备如果出过多次故障每次故障前都要单独标注不能只标最后一次。标签的来源也很重要。最理想的来源是维修工单或故障分析记录而不是靠老师傅“拍脑袋回忆”。因为标签一旦错后面所有环节都跟着错模型再优秀也救不回来。2.4 清洗与标准化一个常见泄漏点藏在这里原始数据里几乎一定有坏数据传感器瞬时掉线、通讯中断导致的值跳零、温度突变超过物理极限等。我们的清洗逻辑是运行状态下电流为 0 的记录直接视为异常删除或前向填充明显超出物理范围的值用前后有效值的均值修复缺失值统一用前向填充ffill因为工业时序里最接近的上一时刻值通常最可信。标准化我特别提一句。模型一般需要输入归一化我们用的是 Z-score即减去均值除以标准差。听起来很简单但有很多项目在这里泄漏用全部数据的均值和方差去标准化等于让测试集的信息提前进入了训练过程。正确的做法是均值、方差只从训练集统计验证集、测试集、包括线上推理全部沿用训练集算好的同一套标准化参数。这个细节看着小实际造成的影响可能相差几个百分点的准确率。3. CNN-LSTM 结构设计与训练策略小模型、快迭代、不容易过拟合模型部分我先说结论对工业中低频时序数据CNN-LSTM 是性价比很高的组合。它不需要像 Transformer 那样海量数据才能训好也不像纯 LSTM 那样输入维度高、收敛慢。CNN 负责提取局部模式LSTM 负责学习模式之间的先后依赖分工非常明确。3.1 一维 CNN 在工业时序里到底提了什么特征一维 CNN 其实就是一个滑动的小滤波器kernel 在时间轴上从左往右扫。比如 kernel_size 8它每一次看 8 个连续时间点的局部形态从中提取出“短时快速抬升”“持续处于高位”“周期性波动”这类局部特征。这就像用放大镜先看每个片段的纹理跟图像 CNN 看局部轮廓是一个道理。做完卷积之后再接 MaxPooling作用是降采样——保留每个局部区域里最明显的特征丢掉冗余。这样进入 LSTM 的数据已经是 CNN “提炼”过的特征序列而不是原始的高维信号。3.2 LSTM 在劣化过程中捕捉的“趋势记忆”LSTM 的核心能力是记忆。它通过门控机制决定哪些历史信息要保留、哪些要遗忘。对设备劣化场景来说最近几个时间步的特征很重要但“过去 12 小时温度一直在缓步爬升且波动越来越大”这种长期趋势光靠看局部片段是不够的。LSTM 的细胞状态可以把这种“持续劣化”的语义记住最后输出一个“当前处于故障前状态的概率”。我在实际使用中更愿意用单层 LSTM 再加 Dropout而不是堆叠多层 LSTM。工业样本量通常不大堆叠 LSTM 很容易过拟合而且推理速度也会变慢。单层 LSTM 在很多工业时序任务上表现已经足够好关键是前面 CNN 提的特征质量要高。3.3 网络结构与参数选择下面这份 Keras 代码结构基本就是最终线上跑的模型结构。输入形状是 (128, 8)代表 128 个时间步、8 个特征通道。from tensorflow.keras.models import Sequential from tensorflow.keras.layers import Conv1D, MaxPooling1D, LSTM, Dense, Dropout, BatchNormalization model Sequential([ Conv1D(filters32, kernel_size8, activationrelu, input_shape(128, 8)), BatchNormalization(), MaxPooling1D(pool_size2), Conv1D(filters64, kernel_size4, activationrelu), BatchNormalization(), MaxPooling1D(pool_size2), LSTM(64), Dropout(0.3), Dense(1, activationsigmoid) ]) model.compile(optimizeradam, lossbinary_crossentropy, metrics[accuracy])参数选择上有几个经验值初始学习率用 1e-3batch size 用 64最大训练 100 个 epoch同时加 EarlyStoppingpatience10和 ReduceLROnPlateau。如果验证 F1 上不去先怀疑数据和标签而不是急着加层数。多数时候把网络调大只会让过拟合来得更快。3.4 训练划分与超参数验证集必须按时间切分训练集和验证集的划分是工业时序里最重要的一个环节也是最容易出问题的地方。一个原则不能随机洗牌切分。同一台设备的同一次故障劣化过程如果前半段进训练集、后半段进验证集模型相当于“看过标准答案再考试”验证准确率会虚高上线之后立刻露馅。我们采用两层防护。第一层按时间顺序切分训练集取前 80% 时间范围内的样本验证集取最后 20%第二层如果是多台设备至少让验证集设备在训练集里没有出现过这样能测出跨设备的泛化能力。对于样本量太少、做不到完全跨设备的情况按时间切分是必须保证的底线。4. 92% 预警准确率的定义、评估与调试过程标题里的“92% 预警准确率”我在这里把口径彻底说清楚。这不是随便抽一个测试集算出来的“总体准确率”而是在一个严格定义的评估条件下得到的“报警命中率”。这一章就是要讲明白这个数字是怎么算的、为什么不能只看 Accuracy、以及阈值不是拍脑袋定的 0.5。4.1 为什么“总准确率”在故障预测里几乎没用假设测试集有 10000 个样本窗口其中只有 50 个是故障前窗口。一个“什么都不报”的模型Accuracy 也有 (9950 / 10000) 99.5%。是不是听起来很厉害但它一个故障也抓不到毫无使用价值。故障预测天然是样本不平衡问题正类极少所以总准确率这个指标在这个场景下基本可以忽略。正确的方法是关心“有效预警率”模型报出一次预警最终到底有没有真的出事这就是 Precision。它回答的是运维最关心的问题——“我是不是又要白跑一趟现场”。4.2 预警准确率 Precision、召回率 Recall 与 F1 的关系四个基础量先对齐TP真阳性模型报警且该设备在预警窗口内真实发生故障或劣化事件。FP假阳性模型报警但设备实际没出问题也就是误报。FN假阴性设备出了故障但模型没有提前报警。预警准确率 Precision TP / (TP FP)含义是所有报警中真正命中的比例。召回率 Recall TP / (TP FN)含义是所有真实故障中我们提前抓住了多少。F1 是两者的调和平均用来综合衡量。我们最终报的“92%”指的就是 Precision 0.92。也就是说模型每发出 100 次预警大约有 92 次最终在预期时间窗口内查出了实际问题剩下 8 次是误报或最终检查无异常。这个口径对现场运维最有参考价值因为误报直接关系到工程师对系统的信任度。4.3 PR 曲线选阈值0.5 不一定是对的选择模型最终输出的是一个 0 到 1 之间的概率默认阈值 0.5 只是一个中性起点并不是最优操作点。我们在验证集上从 0.1 到 0.9 每隔 0.01 扫一遍计算每个阈值下的 Precision 和 Recall画出一条 PR 曲线。选择阈值的逻辑是看业务目标。运维团队最怕“狼来了”效应——频繁误报之后真正报警也没人当回事。所以我们的目标不是追求 Recall 最高而是在保证 Precision 不低于 0.9 的前提下尽量提高 Recall。最终选定的阈值在 0.72 左右那个操作点下 Precision 约 0.92Recall 约 0.78F1 约 0.84。如果你遇到的场景更看重“少漏报”可以下调阈值但要接受误报增多反之就是上调。这是工程取舍没有完美解。4.4 用 92% 这个数字时背后真正的评估条件为了避免“一个数字说不清”我在内部报告里会把评估条件完整列出来报警命中窗口报警发出后 48 小时内有故障或异常维修记录才计为一次命中。窗口外不算数报警后 48 小时内没出事计为一次误报故障发生后才报警也不计入有效命中。冒警太早也不作数报警距真实故障超过 10 天视为无用预警因为现场无法据此安排检修。数据切分测试集严格按时间顺序切分且经过跨设备泛化验证。平均提前量命中样本中平均每起故障提前约 37 小时发出了预警。如果你看到别人只说“准确率 92%”却不提命中窗口、正样本定义和切分方式那这个数字没有比较价值。这是我做工业项目最深的体会之一。5. 模型上线到 MyEMS 的最后一公里从推理服务到预警闭环训练精度再高部署不下去也是白搭。这一章讲的是模型怎么跟 MyEMS 形成协作而不只是“训完存个文件”就结束。5.1 模型服务化与 MyEMS 的对接方式我们的做法是把模型导成 SavedModel 或 ONNX 格式用 FastAPI 起一个独立的推理服务监听固定端口接收特征数组返回故障概率。MyEMS 侧不需要改核心代码通过它自带的任务调度或外部 cron每隔 5 分钟把在线设备最近 128 个时间点的特征拉出来拼成输入请求推理服务把返回的概率写回 MyEMS 的数据表。这个“旁挂式”架构好处是解耦。算法迭代不需要动 MyEMSMyEMS 升级也不影响模型服务。推理服务单独部署资源占用也容易控制避免在 MyEMS 主进程里跑 Python 推理导致平台卡顿。5.2 实时推理的滑动窗口与数据一致性线上推理最怕的是“线下训练好好的上线就抽风”。绝大多数问题出在输入数据口径不一致。我举几个真实见过的坑特征顺序不一致。训练时是电流、功率、压差、温度的顺序线上拼接时少了一个通道或换了个顺序模型还能跑但结果已经失真。应对方案是在推理服务入口做特征数量、名称、顺序的严格校验。标准化参数不一致。线上如果重新用窗口内数据算均值和方差而不是沿用训练集的标准化参数推理结果就会偏。线上必须把训练集的那组 mean 和 std 存成 json 或环境变量推理时直接加载。时间戳不对齐。跨天、跨月、夏令时切换时如果直接用本地时间做窗口对齐可能少取或多取一个点。我们统一用 UTC 存储前端展示时再转成本地时间。5.3 误报抑制连续触发、冷却期与人工确认模型输出概率是波动的单次超过阈值不建议直接报警否则现场会被抖动噪声折腾疯。我们最终采用了三级确认机制第一级单窗口概率超过 0.72。第二级连续 3 个预测周期即约 15 分钟都维持在阈值以上。第三级触发后该设备进入 12 小时冷却期冷却期内不再重复报警但继续记录概率曲线备查。这样设计之后误报率明显下降现场值班人员对告警的信任度也上来了。另外报警等级也可以分档概率在 0.60 到 0.72 之间只写一条“关注”级日志超过 0.72 且连续触发才升级为“预警”。5.4 预警记录如何回流成下一次训练的数据资产模型上线不是终点而是下一轮数据闭环的起点。我们的操作是每次预警发出后要求运维在 MyEMS 里补充处置结论——“属实轴承磨损”“不属实仪表波动”“属实对中不良”等。这些反馈会进入一张结果表后续训练时作为标签修正和错误样本分析的依据。这个闭环的价值怎么强调都不过分。没有反馈模型就是一个静态模型时间一长工况变化准确率自然往下掉。有反馈模型才能持续迭代从 92% 继续往上走。6. 几次翻车记录与最终沉淀的调优清单最后分享几个现场真实翻车的案例。这些坑几乎每个做工业时序 ML 的人都会踩区别只是踩得早还是晚。6.1 翻车一标签里混入“检修段”模型学到了错误模式第一次训练之后模型在正常数据上也打出高概率验证集曲线乱成一团。排查了很久发现标签制作时把停机检修段也标成了正样本。设备停机检修时电流为零、温度下降这些“非运行状态”在模型眼里成了故障模式线上设备一停下来重启模型就报警。解决方式是把停机、检修、校准段全部单独标记并剔除。这之后模型才真正学的是运行过程中的劣化趋势而不是“设备停下来”这种状态切换。6.2 翻车二随机切分让准确率虚高到 96%有一个早期版本用随机洗牌切分训练和验证集验证集准确率 96%团队当时很兴奋。但基于这个模型做出来的线上试跑实际准确率只有 80% 多。回头一查罪魁祸首就是数据泄漏——同一台设备的同一次故障劣化过程一部分样本进了训练集另一部分进了验证集模型等于见了答案再考试。改成按时间顺序切分后验证准确率掉到 90% 左右和线上表现基本一致。这个教训让我从此把“切分方式”列进每个项目的第一检查项。6.3 翻车三模型跨设备迁移效果打折在 3 号泵上训练的模型直接部署到 5 号泵误报率明显上升。原因是设备安装位置、负载率、老化程度都有差异特征分布不一样。用目标设备的一小段数据做微调微调后误报才回到可接受范围。这次之后我们对多台同类设备的策略是先做一个通用模型再用每台设备自己的近期数据做少量微调。如果数据量实在不够至少要在部署早期对输出概率做校准而不是直接照搬原阈值。6.4 调优清单影响效果的因素按优先级排序这几个翻车经历如果汇总成一张清单大致是这样优先级改进项影响程度1标签质量与口径故障时间、预警窗口、剔除停机段最高2数据切分方式按时间、跨设备验证最高3阈值选择与误报抑制策略高4特征选择与数据清洗高5标准化一致性与线上推理一致性高6模型复杂度中7跨设备泛化与再校准中每次调优之前先问自己是哪一层出了问题。多数时候问题不在神经网络而在清单的前三项。做到这里再回头看“92% 预警准确率”并不是一个靠调参调出来的魔术数字更像是在数据质量、标签口径、评估方法和部署细节上逐个抠干净之后自然出现的结果。如果让我重新做一遍这个试点我还是会把大部分时间花在标签和评估上而不是反复调整网络结构。对大部分中低速旋转设备CNN-LSTM 这种组合已经足够能打。真正拉开差距的是你如何定义一次命中、如何切分数据、如何让现场愿意反馈每一次预警的处置结果。这三点做扎实92% 乃至更高的准确率都会是水到渠成的事。