那台离心空压机是凌晨四点坏的工单是第二天早上九点才开的。等我们把备件凑齐、停机拆装一条产线已经低负荷晃了一整天。事后我把 MyEMS 里的历史曲线拉出来看油温在故障前六个小时已经有一条非常清晰的爬升弧线——如果那时候有一套预测性维护系统能自动识别这种模式我们完全可以把这次故障压在计划停机窗口里处理根本不用付出这一整天的停产代价。这个项目就是围绕这件事展开的用 MyEMS 这个开源能源管理平台作为数据底座把设备历史运行数据喂给 CNN-LSTM 模型训练出一个设备故障预警模型最终在保留测试集上做到了 92% 的预警准确率。这篇文章会把我从数据准备、标签定义、模型选型到部署上线的完整链路重新走一遍重点聊那些论文里不会写的坑和处理方式。如果你是做设备管理、能源管理或工业数据方向的想在现有能耗/SCADA系统上做预测性维护这篇应该能帮你省掉不少弯路。1. 先把这个92%说清楚它是准确率不是神话我的习惯是看到“XX准确率”先问一句分母是什么正负样本怎么定义的不然这个数字没有任何意义。这个项目针对的是厂区离心空压机组MyEMS 里已经积累了十几个月的运行数据。我们处理的其实不是一个“设备还有多久坏”的回归问题而是一个二分类问题给出一段最近 T 分钟的传感器窗口判断这台设备是否已经进入“故障前状态”。92% 是二分类预测的 AUC 之外那个 accuracy准确率也就是所有测试窗口里模型把“故障前”和“正常”判断正确的比例。但说实话单看 accuracy 在故障预测里是容易自欺欺人的。因为故障窗口天然是少数如果负样本占 90%你什么都不干、全预测“正常”准确率就有 90%。所以我们项目内部更看重另外三个数精确率大概在 83% 左右召回率在 88% 左右F1 在 85% 左右。换句话说真正进入故障前状态的窗口模型能拉回来八成多而模型每次报警大约有八成最后被证实确实有问题。这个水平对做预测性维护来说已经具备实用价值因为它能保证现场工程师不会被无效告警折腾到集体把报警关掉。还有一点必须讲清楚这个 92% 是对“故障前窗口”的识别准确率不是对“故障发生的精确时刻”的预测。工业现场需要的也从来不是一个精确的倒计时而是一个足够提前的预警期——我在第 6 部分会专门讲评估指标和误报成本的权衡。再说说模型的输入。我们采集的是每分钟一组的多通道数据包括排气温度、油温、振动、电流、排气压力这几个关键测点再加上设备启停标志。窗口长度取了 120 分钟。模型需要在 120×6 的矩阵上判断这台设备是不是正处于故障演化的后半段。2. 数据侧改造MyEMS 不是为故障预测设计的得先把历史数据“喂”给模型2.1 从 MyEMS 里到底能导出什么MyEMS 是开源能源管理系统工厂里常见的电、水、气、汽、冷热量这些能耗数据都在里面。它本身不是设备健康管理平台核心能力是采集、存储、展示和统计。但正因为它有完整的采集链路——Modbus、OPC UA、BACnet 这些协议都支持——对我们来说就省掉了新建数据采集系统这一大块工程直接把 MyEMS 的 MySQL 库当成建模数据源就行。在我的项目里MyEMS 历史库中有两类表最有用一类是设备台账和测点定义相关表里面维护了设备编号、测点名称、单位、量程这些信息另一类是趋势明细表基本的字段就是点位 ID、采集时间、数值。不同版本的 MyEMS 表结构略有差异但思路是通用的先把设备下的所有测点找出来再按测点把历史趋势数据拉出来。值得注意的一个点是不要让建模任务直接在生产库上执行大范围查询尤其不要高频扫全表。MySQL 扛不住长年累月的实时采集加复杂分析同时跑。我当时是在同一台数据库主机上搭了从库让 ETL 任务每隔半小时把增量趋势数据同步到一个独立的建模库之后所有数据加工和特征计算都对着建模库做。这样可以保证不干扰 MyEMS 的正常采集写入。2.2 把故障事件拆成可训练的标签有数据还不够机器学习需要标签。这一步是整条链路里最依赖业务经验的环节也是最容易翻车的地方。我们的做法是把维修工单、点检记录和故障停机报表整理出来和 MyEMS 里的历史曲线时间轴对齐标注每次真实故障的发生时刻 T_failure。然后定义一个“故障前窗口”从 T_failure 往回推 4 小时这期间发生的样本都标记为正样本从 T_failure 往回推 24 小时之外到下一次故障前的正常时段标记为负样本。中间的缓冲窗口不要避免过渡态把标签搞脏。这里有几个容易忽略的细节。第一T_failure 不能只看工单创建时间工单创建往往滞后一定要结合停机事件和曲线突变点去校准。第二一次故障前如果设备已经带病运行很久窗口不要拉太长否则模型没办法区分早期异常和即将故障学到的东西会很模糊。第三故障结束后要有一段冷却期不要把恢复阶段的数据当负样本因为恢复期的曲线形态和正常状态差别也很大模型会学到不想要的特征。经过反复比对我们把正样本窗口定为故障前 4 小时到故障前 10 分钟既保留提前量又剔除了即将完全失稳的最后那段抖动。2.3 数据清洗与重采样频率不一致是常态MyEMS 的趋势数据采集频率并不总是一分钟一条。有些老设备走 Modbus 轮询一分钟一条有些仪表五分钟才存一条还有断网、仪表重启导致的空洞。如果直接拿原始时间戳丢给模型窗口内部的序列点数量不一致根本没法训练。我的做法是以一分钟为基准做重采样把所有点位对齐到同一个时间轴上。缺失值用前向填充但如果连续缺失超过 10 分钟就不填充了直接截断这一段。另一个大坑是停机状态设备不转的时候温度、压力、振动全都往下掉这些平稳的低值数据如果混进训练集模型很容易学到“低值等于正常”这种错误规律。对旋转设备来说这个坑尤其致命。最后我们通过启停标志位把停机时段的样本全部剔除只用运行状态的数据去训练和推理。3. 模型选型CNN-LSTM 凭什么比 XGBoost 和纯 LSTM 更适合设备预警3.1 为什么不能只用几条阈值规则搞定很多人第一反应是故障预警不就是温度超过 85 度就报警吗我一开始也这么想但真正跑过数据就明白了固定阈值在工业现场根本站不住脚。冬天和夏天环境温度差十几度设备不同负载下的正常油温能差二十度以上同一个时间点不同设备的正常振动水平也完全不同。阈值设低了天天误报设高了故障前根本来不及响应。设备故障的征兆往往是趋势形态的变化比如温度爬升速率异常、振动从平稳变为间歇性冲击这些不是单点数值能表达的。要不要用规则引擎当然可以规则适合处理已经非常明确的故障模式比如某个安全联锁参数越限。但预测性维护的目标是在联锁动作之前给出预警这时候需要的是从历史故障数据里学出“这套组合拳打出来就是要出事”的复杂模式用规则一条一条写既不现实也维护不起。3.2 几种常见模型在这个场景下的真实表现我把候选方案都实际跑过一遍横向对比结果大致如下模型对多传感器趋势数据的适配度训练/调参成本实测效果ARIMA / 指数平滑基本只能单变量多通道难以融合低不适用故障前序列非线性手工特征 XGBoost需要人工设计大量统计特征中特征好时约 0.85但特征工程工作量巨大纯 LSTM能学时序演化但局部模式提取弱中高约 0.88收敛慢需要的样本更多1D CNN 全连接局部特征学习强但缺少跨时间记忆低中约 0.86CNN-LSTM局部模式 时序演化都覆盖中约 0.92性价比最优表格里的数据来自我们自己的测试集不代表通用水平但趋势是确定的对于“从多通道原始趋势里识别故障前兆”这种任务CNN-LSTM 的组合比单用其中任意一种都要稳。3.3 CNN 在干什么LSTM 又在干什么理解这个模型的钥匙是把它们拆开看各自负责什么。1D 卷积层沿时间轴滑动本质上是一个可学习的局部模式提取器。它的卷积核可以自动学到“温度在最近 20 分钟内持续爬升”“振动出现周期性尖峰”“电流和压力同时出现波动”这类短时形态。这比人工设计特征要省力而且卷积核在不同通道上共享参数少不容易过拟合。LSTM 层承接 CNN 输出的特征序列负责把局部模式在时间上串起来捕捉更长程的演化趋势。举个例子CNN 可能识别出“某 20 分钟内温度上升斜率偏大”LSTM 则能进一步判断“这种斜率偏大已经连续出现了 3 个窗口并且还在加速”——这种演化趋势恰恰是早期故障和正常负荷波动的关键区别。把卷积核想象成“放大镜”它先看每段局部波形像什么LSTM 是“录像回放”它把这些局部片段的顺序和趋势放在一起推理。两个角色结合才能在多传感器数据上同时抓住空间跨通道关系和时序演化关系。这也是纯 LSTM 做不到的纯 LSTM 对“某个通道 20 分钟内的尖峰形态”这类局部模式不敏感需要靠网络自己从原始序列里慢慢磨样本量不够时效果很不稳定。4. 特征工程与窗口设计92% 的准确率其实是在这一步攒下来的4.1 滑动窗口长度选 60 还是 120背后是故障演化时间模型输入是一个固定长度的窗口。窗口长度怎么选直接影响模型能不能看到完整的故障演化过程。我一开始用 60 分钟窗口效果差强人意准确率大概 85%。后来把窗口拉到 120 分钟准确率到了 90% 以上。原因很直观这台设备的主要故障模式是冷却不良和轴承初损从异常苗头到真正故障的演化时间往往在 2 到 4 小时之间。窗口太短模型只截到了故障最快的一小段误报自然多窗口拉得太长也有问题我又试过 240 分钟准确率反而掉到 88%因为窗口把太多早期正常状态和末期异常状态混在一段序列里模型反而分不清哪个阶段才是关键。窗口长度最终是跟着业务问题走的先看历史故障曲线故障前多久开始出现明显异常再乘以一个 1.5 到 2 的系数给出足够的上下文。对不同的设备类别这个值通常不一样建议分别标定。4.2 每个窗口里放什么原始值通道 一次差分通道我们模型输入的实际尺寸是 [batch, 120, 7]120 个时间步7 个通道。这 7 个通道包括排气温度、油温、振动、电流、排气压力、环境温度外加一个“主机运行状态标志”作为条件信息。标准化是按通道独立做的用的是训练集统计量。这个细节很重要如果拿全量数据的均值和方差去标准化就相当于让模型偷看到了未来分布在线推理时会因为数据分布不同而性能衰减。scaler 要保存下来上线推理时用同一个对象转换。除了原始值我们还叠加了一次差分通道吗在最终方案里没有叠太多只在数据预处理时对温度和振动做了 1 阶差分组成了额外两个通道。差分的作用是让模型更容易捕捉“上升速度”而不是绝对数值。你可以把差分理解成“变化量”温度本身可以因季节变化滑来滑去但故障前的温度差分曲线会出现持续的正值这个信号比绝对温度稳健得多。经验是不要把过多手工特征一股脑塞进去。CNN-LSTM 本身就具备特征提取能力你塞一堆相关性很高的统计量进去只会增加训练负担不会明显提升准确率。CNN-LSTM 模型里什么特征最重要我做过一个简单消融实验去掉振动通道准确率掉了大约 4 个点去掉油温通道掉了约 3 个点去掉差分通道掉了约 2 个点。这告诉我们多通道信息对故障识别是有叠加作用的删哪一个都会让模型少一只眼睛。4.3 正负样本不平衡别急着上 SMOTE先试阈值和类权重设备故障数据天然就是极度不平衡的。在我们的数据集里正样本故障前窗口占比不到 8%负样本是绝对多数。第一步我试了调整损失函数的类别权重比如给正样本加权 5 倍。这个方法简单直接几乎不用改代码。第二步因为很多正样本的预测概率虽然比负样本高但还是没超过 0.5于是我把预测阈值从默认的 0.5 降到 0.3。这一步提升非常明显召回率从 75% 一下跳到 88%而精确率只掉了 5 个点左右。第三步是时序数据增强对正样本窗口施加微小的加性高斯噪声以及对局部时间段做轻微的时间拉伸或压缩相当于把“同样的故障模式但速度略有不同”的变体复制出来喂给模型。我不建议对时序数据用 SMOTE 插值。SMOTE 原本是给表格数据设计的强行在时间序列窗口之间插值会产生平滑的伪信号让模型学到不是真实物理过程的模式。实测下来SMOTE 版本在验证集上看着还行一到真实在线数据就露馅。如果你想做数据增强沿着时间轴做噪声或缩放要比样本插值安全得多。5. 训练流程和调参细节从数据划分到模型收敛5.1 数据划分最大的坑随机打乱会让 92% 变成“虚假繁荣”这是整篇文章里我最想强调的一个坑。很多人在处理时序建模时沿用表格数据的习惯把所有样本打乱然后随机按 7:3 切训练集和测试集。在故障预测场景里这样做等于作弊——因为相邻的时间窗口高度重叠前一个窗口和后一个窗口只是平移了一分钟如果它们被随机分到训练集和测试集模型几乎等于已经看到过答案。测试集和训练集互相“剧透”准确率虚高是必然的。正确的做法是按时间先后切分比如前 70% 的时间窗口做训练中间 10% 做验证最后 20% 做测试。更进一步如果数据集涉及多台设备还要保证同一台设备的样本不能同时出现在训练集和测试集——用设备 ID 做分组切分否则模型可能偷学到“这台设备本身容易坏”的捷径而不是真正学到故障前特征。我当时是用 scikit-learn 的TimeSeriesSplit外加设备分组约束实现的代码大致长这样split_idx int(len(windows) * 0.7) train_windows windows[:split_idx] val_windows windows[split_idx:split_idx int(len(windows) * 0.1)] test_windows windows[split_idx int(len(windows) * 0.1):] # 再验证每个集合里没有重叠的设备ID for dev_id in train_devices: assert dev_id not in test_devices这样切完后测试集上的表现才能真实反映“用过去训练、预测未来”的实际场景。5.2 CNN-LSTM 模型结构到底怎么搭我用 TensorFlow/Keras 实现模型的核心结构如下import tensorflow as tf from tensorflow.keras import layers def build_cnn_lstm(input_shape(120, 7)): inputs tf.keras.Input(shapeinput_shape) x layers.Conv1D(filters64, kernel_size5, paddingsame, activationrelu)(inputs) x layers.BatchNormalization()(x) x layers.MaxPooling1D(pool_size2)(x) x layers.Conv1D(filters128, kernel_size3, paddingsame, activationrelu)(x) x layers.BatchNormalization()(x) x layers.MaxPooling1D(pool_size2)(x) x layers.LSTM(64, return_sequencesFalse)(x) x layers.Dropout(0.3)(x) x layers.Dense(32, activationrelu)(x) x layers.Dropout(0.2)(x) outputs layers.Dense(1, activationsigmoid)(x) model tf.keras.Model(inputs, outputs) return model几个参数的选择理由第一层卷积核大小用 5因为我们希望第一个卷积核能覆盖 5 分钟内的时间跨通道模式第二层用 3感受野逐层递增。padding 用 same保持时间维度不过早萎缩。池化层把时间分辨率降下来这是为了减少 LSTM 层的计算压力但池化不要太多——工业上很多故障前兆本身就是秒级到分钟级的瞬态特征池得太多会把关键突变磨平。LSTM 层只返回最后的状态因为我们的任务是对整个窗口做二分类不需要对每个时间步做预测。LSTM 单元数 64 在这个数据规模下够用了再往上加会显著增加训练时间但准确率提升非常有限。Dropout 主要放在 LSTM 输出之后用来抑制对训练集噪声的过拟合。5.3 训练阶段的实用做法早停、学习率、batch size训练参数我按经验设了这样一组初始值Adam 优化器初始学习率 0.001batch size 64最大训练 60 个 epoch。光靠固定 epoch 不行我加了早停验证集 loss 连续 10 个 epoch 不下降就停同时用ReduceLROnPlateau在学习率停滞时降一半。训练过程中要看的不只是 loss 和 accuracy建议同时打印验证集上的召回率和精确率。因为在这个不平衡数据集上训练集 accuracy 很可能一路高涨但验证集的召回率却纹丝不动——那是模型在学“把所有负样本猜对就能拿高分”的偷懒策略。如果验证集出现这种“准确率高但召回率低”的分裂情况优先调整类别权重和预测阈值而不是盲目加网络层数。一个容易被忽略的操作在训练前把正负样本顺序 shuffle 一下。如果不 shuffle前几个 epoch 里模型可能连续看到大量负样本把预测概率整体压得很低后续要花很久才能缓过来。6. 评估与落地模型不只看 accuracy还要看误报代价6.1 用混淆矩阵拆解 92% 背后的真实画面测试集上的混淆矩阵大约长这样预测/实际实际正常实际故障前预测正常TN ≈ 5100FN ≈ 38预测故障前FP ≈ 66TP ≈ 256在这个矩阵上accuracy (5100 256) / (5100 38 66 256) ≈ 0.92。但更关键的是召回率 256 / (256 38) ≈ 87%精确率 256 / (256 66) ≈ 79.5%。换句话说从全量报警流量看大约五分之一的报警是误报但从实际故障看五次故障里大概能提前拦住四次左右。对现场运维来说最怕听到的词是“漏报”因为漏报意味着设备真的坏到停机。所以我们的第一优先级是保住召回率宁可多一点误报让工程师去看一下也不能让故障悄悄溜过去。还有一个比混淆矩阵更有业务价值的指标提前告警时间。对测试集里每一起真实故障我记录模型首次连续输出“故障前”的时间点计算它到 T_failure 的间隔。中位数大约是 3.2 小时最长的一次给到了 6 小时以上。这才是预测性维护的核心价值不只是“报得准”还要“报得早”。6.2 阈值调整宁可漏报还是宁可误报决策边界不是固定 0.5 死的。我把测试集上所有预测概率导出来在 0.1 到 0.6 之间扫了一遍画了 PR 曲线然后再结合现场运维的接受度做选择阈值调低到 0.3召回率上到 88%精确率掉到 80% 左右阈值调到 0.5召回率掉到 74%精确率上到 89%阈值调到 0.7几乎不误报但漏报会明显增多。我们最终选了 0.3。原因是和现场主管聊过他们的态度很务实一天顶多处理两三次模型报警每次让工程师花五分钟看一眼趋势曲线成本可控但如果设备真的趴窝一次一次就是几十万的损失。这个权衡关系在每个工厂都不一样不建议抄答案但方法论是通用的——先把 PR 曲线画出来再和业务方谈“一次误报的成本”与“一次漏报的成本”分别是多少。6.3 部署成实时预警服务并接入 MyEMS 告警模块模型在 Notebook 里跑出 92% 只是第一步真正的挑战在部署环节。我的落地方式是把训练好的 Keras 模型导出模型服务用 FastAPI 封装一个 HTTP 接口。MyEMS 的外部程序通过一个常驻 Python 进程定时调用这个服务每 1 分钟从 MyEMS 的 MySQL 库里读取最近 120 分钟的多个测点数据构造特征窗口调用模型得到故障概率再判断是否触发告警。这里有一个很实际的问题推理时的数据预处理必须和训练时完全一致。标准化用的 scaler、差分窗口的宽度、每个通道的顺序任何一个地方不一致模型输出的概率就可能全面漂移。所以我把 scaler 也存成文件和模型放在一起部署。在线告警不能单靠一次预测就决定。我加了两个机制去抖和冷却。去抖是指连续两次预测结果都超过阈值才真的产生告警这能过滤掉绝大多数单点噪声冷却是指同一台设备触发告警后30 分钟内不再重复告警避免“狼来了”效应让工程师失去耐心。告警产生后写入一张自定义的pred_alarm表MyEMS 的数据看板直接读这张表做一个“设备健康预警”卡片同时通过企业微信/邮件把消息推给值班人员。如果你不想额外部署 HTTP 服务在 MyEMS 的采集程序旁边加一个同样的推理任务进程也可以但要把服务和采集模块解耦避免模型推理拖垮采集链路。6.4 上线之后必须做的模型监控和重训模型部署后会遇到一个新问题设备磨损、季节交替、工艺调整都会让输入数据分布缓慢漂移。今天跑得好好的三个月后可能误报越来越多但 nobody 会主动告诉你模型退化了。我的做法是每两周计算一次近两周输入样本分布与训练集分布的 PSIPopulation Stability Index超过 0.2 就发出提示同时每月人工复盘一次所有告警和漏报记录把误报案例、漏报案例整理后补充进训练集。故障样本少是常态所以每一次真实故障发生之后都值得把这一段数据归档进“新故障案例”库攒到一定数量后就重新训练一版模型先小流量对比再全量切换。可以提前说一句预测性维护不是一锤子买卖部署才是生命周期管理的开始。如果团队没有意愿去持续维护这个模型那上线三个月之后的效果可能还不如一个精心调过的规则引擎。7. 关于准确率之外我还想分享的几点体会这个项目做下来我最深的感受是92% 准确率不是模型单方面的功劳而是“清晰的故障标签 合理的窗口设计 严格的时序划分 务实的阈值策略”共同堆出来的。换一个项目哪怕模型结构一模一样只要故障标签糊弄、窗口乱设、划分随机结果可能连 80% 都到不了。还有一点经验是先用简单模型跑通全链路再回来优化模型。我一开始甚至连 CNN-LSTM 都没跑先用 LightGBM 加手工特征搭了一套能出结果的基线把数据管线、评估脚本、部署框架全部打通然后才替换成 CNN-LSTM。这样每一步的改进都能量化而不是在一个复杂模型里同时排查数据问题和模型问题。最后再分享一个小技巧工单记录里很多故障时间是不准的但 MyEMS 里的曲线不会骗人。建模之前花时间把历史曲线和故障事件一条一条对齐这比之后想尽办法提升模型复杂度划算得多。数据质量决定了准确率的天花板CNN-LSTM 再强也填不了标签错误的坑。