基于MyEMS与CNN-LSTM的设备预测性维护实战解析

做设备运维这些年我最大的感受就是设备从来不会提前打招呼再坏。往往是最忙的时候电机烧了、泵停了、空压机跳了然后整个产线停在那里等配件。后来我们在MyEMS这个开源能源管理系统上接了一套预测性维护方案用CNN-LSTM模型对关键设备做故障预警跑了800多天的数据准确率稳定在92%左右。这篇文章就把整个实战过程拆开讲清楚从数据怎么洗、特征怎么构造到模型怎么设计、阈值怎么调再到上线后踩过的那些坑一次性说完。先说清楚这个项目到底做了什么。MyEMS本身是个开源的能源管理系统主要负责能耗数据的采集、存储和分析支持Modbus、OPC UA、M-Bus这些主流协议数据库端支持MySQL、PostgreSQL、SQL Server等。很多用过MyEMS的朋友都把它当能耗看板用看看今天用了多少电、多少水、多少蒸汽。但MyEMS底层其实沉淀了大量的设备运行数据这些数据只用来算电费太可惜了。我们的想法很简单把这些高频采集的电流、电压、温度、振动、压力等信号利用起来通过深度学习模型识别设备从正常状态退化到故障状态的模式提前几小时甚至几天发出预警让运维人员有时间安排检修而不是被动等着设备报警停机。为什么选CNN-LSTM这个组合后面会详细说。先给结论CNN负责从多通道时序数据里提取局部特征LSTM负责建模这些特征在时间上的依赖关系两者搭配特别适合处理设备运行数据这种多变量、强时序、有周期性的数据形态。整套方案跑在MyEMS数据层之上模型输出预测结果后再回写MyEMS在原有系统里就能看到每台设备的健康状态和预警记录不需要额外搞一套独立的平台。1. 项目背景与整体思路1.1 为什么在MyEMS里做预测性维护说到预测性维护很多团队第一反应是上一套专业的状态监测系统比如振动分析仪、油液检测设备、在线红外测温费用动辄几十万起步。但我们当时面对的情况是厂里已经有MyEMS在跑现场电表和传感器数据一直在采只是这些数据都躺在数据库里睡大觉。与其重复投资不如把现有数据盘活。MyEMS的数据采集架构是这样的现场仪表和设备控制器通过Modbus等协议把数据传给采集网关网关再写入MyEMS的数据库。MyEMS里有一个meter表记录了所有计量点每个计量点有对应的时间序列数据。比如一台空气压缩机我们可以采集到它的三相电压、三相电流、有功功率、功率因数、排气温度、排气压力、运行状态等十几个测点采集频率可以做到1秒到5分钟不等。这些数据经过一段时间积累就是非常好的模型训练样本。用MyEMS做预测性维护的另一个好处是省掉了数据接入的麻烦。MyEMS支持通过内置的API和数据库视图向外导出数据我们只需要写一个定时任务从数据库读取数据处理后丢给模型推理就行不用重新对接协议、不需要了解每个仪表内部怎么存储数据。而且预测结果可以再通过MyEMS的报警通知模块推给运维人员和能耗报警共用一套通知渠道运维人员不用额外装App直接在微信或邮件里就能收到预警。这里也顺便区分三个概念事后维护是设备坏了再修停产损失最大预防性维护是按固定周期保养比如每3000小时换一次轴承这种方式虽然能降低故障率但存在过度保养的问题——很多时候轴承状态明明很好也强制换掉了预测性维护则是根据设备的实际运行状态判断什么时候该修做到“按需维护”。我们做的这个项目就是典型的预测性维护目标是识别出故障前设备表现出的异常模式。1.2 为什么选CNN-LSTM而不是其他方案选模型的时候我们其实比较过好几种路线各有各的适用场景。第一种是阈值规则方式。比如电流超过额定值10%持续30秒就报警排气温度超过100度就报警。这种做法实现简单、现场也容易理解但问题很明显阈值设得松了容易漏报设得紧了天天误报而且不同工况下同一个设备的正常范围差异很大一台刚启动的空压机和一台稳定运行的空压机各项参数差出一倍还多固定阈值很难适配。第二种是传统机器学习比如随机森林、XGBoost。我们用XGBoost做过一版效果也不差在部分设备上准确率能做到87%左右。但传统机器学习有一个短板它需要人为设计特征比如时域的均值、方差、峰值因子频域的某些频带能量占比等。这些特征设计很大程度上依赖经验换一台设备、换一个工况特征可能就不适用了。第三种是纯LSTM。LSTM在时间序列预测和分类上确实很强能很好地捕获长期依赖但它对局部模式的提取能力偏弱。设备故障往往刚开始表现在几个连续采样点上的细微异常比如电流波形某个频率分量突然变大这时候直接丢给LSTM前期特征提取不够充分模型不容易抓住这些早期信号。第四种就是最终选定的CNN-LSTM。这个结构的思路是先用一维卷积层在时间维度上滑动自动提取每个测点内部的局部特征以及不同测点之间的空间关联特征再把CNN提取出来的特征序列送入LSTM层让LSTM学习这些特征随时间变化的规律最后接全连接层输出故障概率。相当于CNN干的是“特征工程师”的活LSTM干的是“时间序列建模”的活分工明确效果确实比单独用其中任何一个都要好。另外还有一个现实考量CNN和LSTM都是深度学习模型里相对成熟的组件PyTorch里直接调用就行不需要自己从零实现。训练时对GPU的要求也不高我们用的是一块消费级的RTX 3060模型参数量也不大训练一轮的时间基本控制在10分钟以内工程落地上很现实。2. 数据准备与特征工程2.1 设备数据怎么采集与清洗模型效果的天花板是数据质量决定的。这句话虽然听起来像老生常谈但在这个项目里真的是最深的感受。我们最初拿到的原始数据质量参差不齐如果直接丢进模型训练别说92%的准确率能到70%就算烧高香了。数据采集这块MyEMS的数据库里记录的方式是这样的每个计量点有一条数据表记录表名类似于meter_hourly、meter_minutely根据配置的采集频率不同数据粒度也不一样。我们的方案是统一从MyEMS的数据库视图里读取每天跑一次ETL任务把近期的运行数据同步到独立的分析库中。为什么用独立的库因为MyEMS的生产库不能随便加索引、跑重查询万一影响正常读写就麻烦了。分析库用PostgreSQL建好复合索引后按设备ID和时间范围查询百万级数据基本在毫秒级。数据清洗是整个流程里最琐碎但又最关键的一步。我们遇到的典型问题有这几类数据缺失。通讯中断、设备停机、仪表掉线都会导致某段时间没有数据记录。对于缺失率低于5%的测点用前后时刻的线性插值补齐缺失率在5%~20%的用同设备同工况的历史中位数填充超过20%就直接丢弃该时间段的数据不做训练样本。重复数据。有些采集网关网络抖动时会重发数据包导致同一时间戳出现多条记录。处理方式是按设备ID加时间戳去重保留最后一条。异常跳变。传感器偶尔会出现毛刺比如电流瞬间从50A跳到500A又跳回来。这类数据大部分是传感器故障或电磁干扰不是设备真实状态。我们用一个简单的中值滤波做预处理某个采样点的值与前后两个点的中位数差距超过3倍标准差就判定为毛刺用中位数替代。时间对齐。不同测点的采集频率可能不一样比如电流每5秒采一次温度每30秒采一次如果直接拼接成一张表时间戳对不齐模型就会学错。我们把所有测点统一重采样到10秒一个点采用向前填充的方式补齐短间隔缺失再按10秒窗口聚合求均值确保所有特征在同一时间轴上。2.2 特征构造与故障标签数据清洗完接下来就是特征工程和标签标注。很多做深度学习的朋友会觉得“深度学习不需要特征工程喂原始数据就行”至少在这个场景下这个想法是错的。虽然CNN-LSTM能自动提取特征但我们通过特征工程给模型提供更合适的数据形态可以让模型学得更快、更稳。我们最终使用的特征分为三个维度原始物理量。包括三相电流、三相电压、有功功率、无功功率、功率因数、排气温度、排气压力、润滑油温度、电机轴承温度、振动加速度这些原始值标准化之后直接作为模型输入的一部分。统计特征。每个滑动窗口我们采用60个采样点也就是10分钟长度内的均值和标准差用来刻画设备在该时间段内的整体水平和波动程度。标准差这个特征特别有用很多故障早期的表现不是数值变高而是波动变大。差分特征。相邻时间点的差值反映参数的变化趋势。比如轴承磨损早期振动信号可能没有明显变大但振动加速度的一阶差分会出现规律性波动这个差分特征能帮CNN更容易抓到异常模式。标签标注是整个项目里最花精力的环节。我们的故障样本主要来自历史维修记录厂里的设备维修工单记录了每次故障的时间、现象、处理措施和更换的配件。根据维修记录我们把故障发生前24小时内的数据标注为“故障前状态”其余正常运行时间标注为“正常状态”。这里有一个细节值得注意故障前24小时到底怎么定义我们一开始用的是故障前6小时模型效果很一般因为很多故障的早期征兆在24小时甚至48小时前就出现了。后来调整成24小时窗口后CNN-LSTM才有足够多的“渐变过程”去学习。不过标签标注这件事还有个绕不开的难点故障样本太少了。我们这套系统覆盖12台关键设备两年下来真正记录在案的故障只有30多次和几十万条正常运行数据相比正负样本比例悬殊。如果不处理类别不平衡模型会“学聪明”——反正正常样本多全部预测正常准确率也有99%但一个故障都报不出来。所以我们在后面训练环节加入了加权损失函数和过采样策略这部分后面细说。3. CNN-LSTM模型搭建与训练3.1 模型结构设计模型的整体结构不复杂但每个模块的细节都经过反复调整。最终版本的结构是这样的输入是一个形状为(batch_size, 60, 14)的张量60代表时间步长10分钟的采样点数14代表特征通道数各个测点加统计特征。数据先经过两个一维卷积层卷积核大小为3第一层16个卷积核第二层32个卷积核每层后面接ReLU激活和最大池化池化后的特征序列送入一个两层的LSTM隐藏层维度都是64LSTM的最后一层输出经过全连接层映射到两个神经元用softmax输出正常和故障前状态的预测概率。这里说一下为什么要用60步的窗口长度。我们尝试过30步5分钟、60步10分钟、120步20分钟三种窗口60步的效果最优。30步太短模型看到的历史信息不够很多慢性的退化趋势还没展开就被截断了120步太长一方面计算量增大另一方面故障前状态的样本会变得更长正负样本的时序重叠更严重模型反而学糊涂了。60步是性能和效果之间的一个平衡点这个参数不要照搬应该根据你实际的采样频率和设备故障演化周期来定如果你的设备故障前征兆要提前48小时才明显而你的采样间隔是1分钟那窗口可能至少得设到120步以上。PyTorch里的模型定义大致长这样import torch import torch.nn as nn class CnnLstmPredictor(nn.Module): def __init__(self, n_features, n_hidden64, n_layers2, n_classes2): super().__init__() self.conv1 nn.Sequential( nn.Conv1d(n_features, 16, kernel_size3, padding1), nn.ReLU(), nn.MaxPool1d(2) ) self.conv2 nn.Sequential( nn.Conv1d(16, 32, kernel_size3, padding1), nn.ReLU(), nn.MaxPool1d(2) ) self.lstm nn.LSTM(32, n_hidden, n_layers, batch_firstTrue) self.fc nn.Linear(n_hidden, n_classes) def forward(self, x): # x: (batch, seq_len, n_features) x x.permute(0, 2, 1) # 转成 (batch, n_features, seq_len) 给Conv1d x self.conv1(x) x self.conv2(x) x x.permute(0, 2, 1) # 转回 (batch, seq_len, channels) out, _ self.lstm(x) out out[:, -1, :] # 取最后一个时间步的隐状态 return self.fc(out)有几个容易踩坑的细节。Conv1d默认接收的输入是(batch, channels, length)所以要从原始输入转过来这个很多人第一次写会漏。池化不要设成全局池化否则LSTM失去时间维度的输入就只有1个时间步等于白接了LSTM。批大小我们设64学习率0.001优化器用的Adam训练轮次上限50轮配合早停机制防止过拟合。3.2 类别不平衡问题与损失函数设计前面提到了故障样本远少于正常样本如果我们用普通的交叉熵损失函数模型会把所有样本都预测成正常因为这样整体损失最小。我们尝试了几种解决方案最终用组合拳解决了。最直接的方法是加权交叉熵。给少数类故障前状态更高的权重让模型对分错少数类的惩罚变大。具体实现上nn.CrossEntropyLoss可以直接传入weight参数我们设正常类权重为1.0故障前状态权重为5.0~8.0之间实际跑下来权重7.0的效果最好。权重太大会导致模型过度敏感把正常工况误判为故障权重太小又起不到纠正类别不平衡的作用。第二种方法是过采样。对故障前状态的样本做随机过采样让每个batch里正常样本和故障样本的比例接近2:1。但我们不用简单的重复采样而是在每次epoch开始前重新采样让模型在训练过程中看到更多元的故障样本分布减少过拟合风险。第三种方法是利用时间滑窗产生更多样本。故障前24小时的数据我们每隔10分钟切一个窗口这样一次故障事件能产生大约140个正样本。不要觉得这样会产生“重复样本”窗口虽然重叠但每个窗口的序列模式不同对模型来说是有差异的输入。这也是深度学习做时间序列分类时扩增样本的有效手段。损失函数方面我们试过Focal Loss这是目标检测中解决类别不平衡常用的损失对难分类样本给予更大关注。但在我们的场景下效果和加权交叉熵相差不大考虑到实现复杂度和调参成本最终保留了加权交叉熵方案。如果你的故障样本更稀少比如只有个位数样本可以试试Focal Loss超参数alpha和gamma分别设为0.25和2.0起步调。3.3 训练过程与关键参数训练前数据划分有一个非常重要的原则绝对不能用随机划分必须按时间顺序划分。我们用前80%的时间段作为训练集后20%作为测试集。为什么不能随机划分因为时间序列数据具有时间依赖性如果训练集里包含了测试集后面时间段的数据模型相当于“偷看”了未来信息这样得到的准确率是虚高的上线后真实效果会大打折扣。我就见过一个案例有人用随机划分跑出96%的准确率上线后发现连70%都不到最后查下来就是时序泄漏的问题。我们的划分方式是取历史数据前700天做训练集中间50天做验证集最后50天做测试集。验证集的作用是调超参数和触发早停测试集只用来最终评估一次不做任何调参决策。模型训练过程中监控验证集的F1分数连续5个epoch没有提升就停止训练并恢复最佳模型权重。实测下来模型一般在第18到25轮左右收敛50轮上限很少真正跑满早停能省下不少时间。还有一个细节是学习率衰减。我们使用PyTorch的ReduceLROnPlateau当验证集损失连续3轮不降时学习率乘以0.5。初始学习率0.001经过两三次衰减后降到0.00025附近。学习率不减的话模型会在最优解附近震荡损失曲线下不去准确率也卡在85%左右上不来。这些小细节叠加起来才最终把准确率推到92%。4. 模型评估与92%准确率是怎么得来的4.1 评估指标与验证方法很多项目汇报时只提准确率Accuracy但做预测性维护的人都知道准确率不能反映全部问题。比如1000个正常样本里有1个故障样本模型把所有样本都判为正常准确率是99.9%但这样的模型没有任何实用价值。所以我们评估时重点看三项精确率召回率和F1值。精确率Precision的含义是模型报警的所有事件中真正发生故障的比例。精确率高意味着误报少现场运维人员对报警的信任度高。召回率Recall的含义是所有真实故障中模型成功预报出来的比例。召回率高意味着漏报少这是预测性维护的核心价值——不能让设备真的坏了才想起来报警。F1是两者的调和平均综合衡量模型表现。我们这个项目的目标是在保证召回率不低于85%的前提下尽可能提高精确率。为什么先把召回率作为底线因为预测性维护漏掉故障的代价远大于误报一次。故障了没报设备停机损失可能几十万误报一次运维人员白跑一趟损失的是时间成本。在调参过程中我们发现分类阈值可以灵活控制精确率和召回率的平衡默认阈值是0.5但把阈值提高到0.65之后精确率从88%升到94%召回率从92%降到86%F1基本不变。实际部署时我们取了一个折中的阈值0.58最终在测试集上的指标是准确率92.1%、精确率90.6%、召回率89.7%、F1值90.1%。4.2 从80%到92%关键优化的三个转折点这版模型不是一步到位的中间经历了三个比较大的转折点每一次都让准确率上了一个台阶。第一次是改进标签定义方式。最初我们按照维修记录把故障前6小时标注为故障状态模型在测试集上只有82%的准确率而且漏报率很高。后来分析发现很多故障根本不是突然发生的而是慢慢劣化的比如轴承磨损会导致振动逐步增大、温度逐步升高这个退化过程往往持续两三天。故障前6小时的窗口太窄模型根本没学到“劣化趋势”这个关键模式。把窗口放宽到24小时后模型准确率直接跳到87%。第二次是加入差分特征。我们之前的输入特征全部是原始值加统计值模型学到的是“设备当前状态是否异常”。但有些故障尤其是机械类故障表现出来的是“变化趋势异常”而不是“当前值异常”。加入一阶差分特征后模型能捕捉到参数的变化速率相当于多了一个“速度视角”。这个改动让准确率从87%升到89.5%左右。第三次是调整类别权重与过采样比例。早期用1:1过采样让多数类和少数类数量完全一样模型对故障状态过度敏感误报率飙升。后来通过实验发现正常样本和故障样本比例为2:1到3:1时模型表现最稳定。同时类别权重从10.0下调到7.0模型开始能区分“正常波动”和“故障前兆”之间的微妙差异。这一轮调整后准确率终于突破了91%最终稳定在92%左右。5. 预测落地与MyEMS集成实践5.1 推理服务怎么和MyEMS对接模型训练完只是第一步真正产生价值的是把它部署到实际环境中让预警信息及时到达运维人员手里。我们最后的落地架构是这样的一台Linux服务器上跑一个Python定时服务每5分钟从MyEMS的数据库里读取最近10分钟的实时数据执行模型推理把每台设备的故障概率写入一个独立的结果表然后根据设定的阈值判断是否触发报警。推理服务的核心代码逻辑大致是这样def predict_and_alert(): device_ids get_device_list() for device_id in device_ids: df fetch_data(device_id, period10min) if len(df) 60: continue features build_features(df) X torch.tensor(features, dtypetorch.float32).unsqueeze(0) with torch.no_grad(): prob model(X).softmax(dim1)[0][1].item() write_result(device_id, prob) if prob ALERT_THRESHOLD: send_alert(device_id, prob) elif prob WARNING_THRESHOLD: send_warning(device_id, prob)这个服务通过MyEMS的数据库直接读写不依赖MyEMS自身的API好处是部署简单、不会干扰MyEMS的正常运行。但要注意权限和性能问题最好给预测服务创建独立的数据库账号只授予目标表的SELECT权限和结果表的INSERT/UPDATE权限避免误操作影响生产数据。另外每5分钟跑一次全量推理12台设备的数据量不算大单次推理时间也就几百毫秒不会对数据库造成压力。报警通道方面我们采用了二级预警策略故障概率在0.4到0.58之间发警告提醒运维人员关注超过0.58直接发报警包括抢修工单自动创建。这样既避免了对所有轻微异常都大动干戈也能对高概率故障快速响应。5.2 报警准确性验证与运维流程调整模型上线后我们还做了几个重要的验证动作确保92%的准确率不是只在实验室里好看。第一个动作是并行试运行。正式替换原有维护策略前我们让模型的新报警系统和原有的阈值报警系统并行运行了两个月。新系统的报警信息不直接通知运维人员而是每周汇总一次和实际情况对照验证。这个阶段模型一共报了17次“故障前状态”其中有15次被实际维修记录证实有2次经检查后发现设备确有异常但未造成停机相当于提前发现了隐患。这两个月让我们对模型有了足够信心确认可以上线替代原有策略。第二个动作是建立报警闭环反馈。每次模型报警后无论运维人员通过检查确认故障还是判断为误报都要在系统里做一次记录说明实际检查结果。这些反馈数据被保存下来后续可以定期用于模型验证和微调。如果某一台设备近期频繁误报我们就需要检查是不是该设备的工况发生了变化而不只是简单调低报警阈值。第三个动作是定期重训练。模型上线运行3个月后我们用新积累的数据和反馈样本对模型重新训练了一次。重训练时保留了原有模型的大部分结构和超参数只对类别权重和阈值做了微调F1值从90.1%提升到91.3%。不过要注意重训练之前要确认新数据的质量并且在验证集上重新评估不能每次都让模型分数往上走就盲目上线。我们有一次重训练后准确率反而掉了3个百分点查下来是新标注的某个故障样本标签时间窗口有误导致模型学了错误的模式。6. 常见问题与排查技巧实录6.1 数据层面的坑与解法第一个高频问题故障样本太少了怎么办除了前面提到的过采样和窗口滑动扩增还有一种实用做法是迁移学习思路。如果同型号设备从别的厂区或资料中能拿到故障数据可以先让模型在其他设备的数据上预训练再用自己的少量数据做微调。我们有一台新接入的冷冻机组历史故障记录很少就是用同批次的另一台设备的故障数据预训练然后微调参数效果还不错。第二个问题设备工况变化导致数据分布漂移。工厂里设备不是永远在额定工况运行的比如冬天和夏天的空压机排气温度差异很大春节和双十一的生产负荷完全不同。如果模型训练数据只覆盖了一种工况遇到冷热交替季节就会频频误报。解决方法是尽可能收集覆盖一年四季的数据并且在特征层面增加“工况标志位”比如根据功率把所有运行状态聚类成轻载、中载、重载三个级别作为额外输入。第三个问题停机时间算不算正常样本这是一个容易忽视的问题。设备关机、待机状态下的电流电压都是零如果把这些数据当作正常样本模型会学到“零就是正常”一旦设备启动所有数值都偏离“正常”误报成故障。我们的处理方式是只保留设备运行状态下的数据过滤掉停机状态段时间用运行状态位做条件过滤。6.2 训练与部署阶段的坑与解法训练阶段遇到最典型的是过拟合问题。由于故障样本相对较少模型容易把训练集里的故障模式背下来在训练集上表现极好换一批数据就露馅。除了早停和数据扩增我们还加了Dropout层LSTM层间的Dropout设为0.3CNN部分不设置Dropout实测能明显提升验证集的泛化能力。部署阶段需要注意的坑也不少。模型推理时间虽然短但如果用CPU推理配合PyTorch的重量级依赖启动时载入模型可能要好几秒。我们一开始在报警函数里直接实例化模型每次推理都要重新载入权重导致单台设备推理要等2到3秒。后来把模型在服务启动时加载一次放到全局变量里复用单次推理时间降到50毫秒以内。输出结果的延迟也要关注。模型是从MyEMS数据库里读数据做推理的这意味着结果天然比真实状态滞后一段时间。我们使用的数据是10秒粒度的重采样数据数据库同步本身有延迟实测从设备产生数据到模型推理完成大约有30秒到1分钟的延迟。对于缓慢发展的故障轴承磨损、绝缘老化这个延迟完全够用但如果要预测突发性故障比如瞬间短路这个方案就不适用了。理解方案的能力边界比追求一个好看的数字更重要。6.3 常见问题速查表问题现象可能原因排查思路与解法模型一直预测“正常”类别不平衡严重检查标签权重和过采样比例必要时换成Focal Loss训练准确率高、测试准确率低时序泄漏或者过拟合确认数据划分是否按时间先后降低模型复杂度或增加Dropout上线后误报很多数据分布漂移检查设备工况变化重新标注当前数据考虑增加工况标志位某些设备报警准确率特别差该设备故障样本不足用同型号其他设备数据预训练后微调或适当增加该设备的类别权重推理延迟高模型反复加载模型初始化放到服务启动阶段用全局变量复用断电/重启后服务不报警服务没有守护进程用systemd或容器编排工具管理推理服务启动后自动恢复6.4 实战经验补充最后分享几个不容易想到但实际很有用的点这些经验不在标准教程里但真的能帮你在项目里少走弯路。第一故障诊断报告要保留原始数据。每次模型报警后除了把结果记录到结果表我们还会把触发报警的那段原始时序数据单独归档保存。在后续复盘时这些原始数据可以用于分析误报原因也可以积累下来作为下一轮模型训练的候选样本。如果只保存报警结论不保存原始数据后面想分析原因都没有素材。第二报警消息里带上可解释信息。模型的输出只是一个概率数值运维人员收到“设备A故障概率87%”的报警后还是很懵。我们在报警消息里附加了近期该设备各项测点的变化趋势摘要比如“排气温度较24小时前升高8度电流波动幅度增大2倍”这样运维人员能快速判断报警是否合理也能更信任这套系统。这个附加信息不需要太复杂取前24小时和后24小时的关键测点均值做对比就很有说服力。第三不要盲目追求模型复杂化。我们有同事一开始想上Transformer理由是现在大模型这么火效果肯定会更好。但试下来之后发现Transformer在小规模时序数据上收益有限参数量大、训练时间长、部署占用资源多关键是准确率只比CNN-LSTM高了不到1个百分点性价比很低。CNN-LSTM在中小规模的设备预测性维护场景下已经足够实用模型不是越花哨越好能稳定高效地解决现场问题才是王道。在MyEMS上扩展预测性维护这个方向我们目前还在持续迭代。下一步计划把更多的设备类型纳入预测范围比如电机、泵、风机、压缩机都要覆盖同时尝试将模型从分类改成剩余寿命预测直接告诉运维人员“这台设备预计还能用多少小时”。如果有同行也在用MyEMS做类似的事情欢迎一起交流经验把设备管理这件事做得更智能一点。