企业官网建设流程全解析

预测性维护这几年在工业圈里有多火，不用我多说。只要跑过产线的人都知道，设备一停，损失按分钟算，备件积压、计划外停机、夜班抢修，每一样都是真金白银。我大概在半年前开始研究 MyEMS 这个开源能源管理系统，原本只是看中它的数据采集和可视化能力，后来花了一段时间把一套 CNN-LSTM 故障预警模型接了进来，在某塑料挤出产线上做到了 92% 的预警准确率。今天把整个落地方案、踩过的坑、调参细节全部写出来，给正在做设备健康管理或者计划引入预测性维护的朋友一个可直接参考的路线图。

先说清楚这套方案解决什么问题。传统的设备维护基本是两种：坏了才修的事后维修，和按固定周期换件保养的定期维护。前者代价大，后者浪费多。预测性维护要做的就是在故障真正发生之前，根据设备的振动、温度、电流等运行数据判断出异常趋势，提前几天甚至几周告诉你"这台设备快不行了"，让你可以从容安排停机窗口。我这次用 MyEMS 做底层数据平台，用 CNN-LSTM 混合神经网络做故障识别模型，把预警提前量控制在 12 到 72 小时之间，最终在真实产线上把准确率做到了 92%。下面从方案选型一路讲到部署运维，全程干货。

1. 项目整体设计与方案选型思路

1.1 为什么选 MyEMS 作为数据底座

做预测性维护，第一步永远不是建模型，而是解决数据从哪里来的问题。我当时调研过几个路线：从零开始用 MQTT + InfluxDB + Grafana 自己搭一套数据采集栈，或者直接用商业平台，再或者像现在这样基于 MyEMS 二次开发。自己从头搭的问题很明显，采集器、数据库、可视化、告警模块全要自己写，只做一张大屏就要忙活好几天。商业平台省事但贵，而且闭源系统很难把自定义的 Python 模型集成进去。

MyEMS 是开源的能源管理系统，技术栈是 Python + React，数据库支持 MySQL 和 PostgreSQL，原生支持 Modbus TCP、BACnet、OPC UA 等工业协议。这意味着绝大多数工厂里的 PLC、传感器、智能电表它都能直接对接，不用额外写协议解析。更重要的是它的数据模型设计得比较干净，设备、测点、计量表计之间的关系非常清晰，用户还可以在它的基础上扩展自定义数据表。这对我后面挂故障特征值、存模型预测结果来说非常方便，算是把基础设施的搭建时间压缩了大半。

1.2 为什么是 CNN-LSTM，而不是纯 LSTM 或 XGBoost

模型选型是很多人纠结的地方。我最早先试了纯 LSTM，也试过 XGBoost 加手工特征，效果都不算理想。后来才把 CNN-LSTM 组合结构作为主模型。原因其实不复杂。

纯 LSTM 擅长捕捉时间上的长程依赖，但对局部特征的提取能力一般。工业设备的故障信号往往是"局部异常 + 时序演变"的组合：比如轴承点蚀初期会产生周期性冲击脉冲，这个冲击在波形上是一个短时突变，但它的幅值和频率会随着时间逐渐恶化。LSTM 对这种局部突变的敏感度不够；XGBoost 这类树模型对表格型手工特征很有效，但特征工程的工作量大，而且极度依赖人的经验，换一台设备可能全部要重新做。

CNN-LSTM 的混合结构正好互补。CNN 的卷积核可以自动提取短时窗口内的局部特征，相当于一个自动的特征工程器；LSTM 负责把这些特征按时间顺序串联起来，捕捉退化趋势。整个模型端到端训练，不需要人工设计故障特征，换设备时的迁移成本低很多。后面实测下来，单用 LSTM 的准确率大概在 83% 左右，加上 CNN 特征提取层之后提升到了 91%-92%，效果差异还是很直观的。

1.3 预警目标与性能指标定义

在动手写代码之前，我先把"预警准确率 92%"这个目标的定义想清楚了。很多项目死就死在指标定义不清上。这里的 92% 不是简单的"预测故障对不对"，而是有一个明确的计算口径：

• 真正例：模型发出预警后 72 小时内设备确实发生了故障或出现可验证的异常状态。
• 假正例：模型发出预警，但 72 小时内设备运行正常，属于误报。
• 真负例：模型不预警，设备也确实正常运行。
• 假负例：模型没预警，但设备故障了（最严重的情况）。

准确率 =（真正例 + 真负例）/ 总样本数。我另外还重点盯了召回率，就是所有真实故障里模型能提前捕捉到的比例，这个指标对预测性维护来说比准确率还重要。漏报一次可能就是几万块的损失，误报几次最多是让维护人员白跑一趟。我的目标是准确率 92% 的同时，召回率不低于 90%，这个在后面的阈值调优中花了不少功夫。

2. 数据采集、清洗与特征工程全流程

2.1 测点布设与数据采集参数

这次项目选了一条塑料挤出产线做验证，关键设备是一台大功率挤出机。故障模式主要关注三类：主电机轴承磨损、减速箱齿轮点蚀、螺杆扭矩异常波动。

测点布设遵循"关键部件全覆盖 + 冗余验证"的原则。主电机驱动端和非驱动端各装一个三轴加速度传感器，减速箱输入轴和输出轴各一个加速度传感器加一个温度传感器，螺杆驱动电机上加电流互感器采集三相电流。所有信号通过 Modbus TCP 汇集到边缘网关，再推送到 MyEMS 的数据采集服务。

采样参数这块有一个容易踩的坑。振动信号至少要有 10 倍于目标频率的采样率才能看到清晰的冲击特征，普通电机轴承故障特征频率一般在几十到几百赫兹，所以我把振动采样率定在了 5120Hz，电流信号采样率 640Hz。再往上采样率不是不行，但数据量会变得非常大，MyEMS 默认的数据库存储策略是按分钟聚合趋势数据，高频原始数据如果全部入库会把数据库拖垮。我的做法是高频数据在边缘网关做实时特征提取，只把特征值上传到 MyEMS，原始波形保留在本地存储一周，这样既满足模型需要，又不至于把存储打爆。

2.2 数据清洗的三种典型问题

工业数据比互联网数据脏得多，这句话我做了这个项目之后体会特别深。原始数据常见的坑有三个：

第一是缺失值。Modbus 轮询偶尔超时会导致某个测点在某一秒没有数据，网关掉电或者网络闪断会造成更长时间的数据空缺。我的处理策略是：单点缺失用前后时刻的线性插值填充；连续缺失超过 5 分钟的段直接标记为无效，不参与特征计算，因为这么长时间的数据空缺说明现场本身已经处于异常状态，硬填反而会污染模型。

第二是异常尖峰。传感器偶尔会受到电磁干扰，产生一个远超正常范围的毛刺值。这种值和真实的冲击脉冲很难单凭幅值区分。我的做法是先用中值滤波平滑一遍数据，然后把超过 6 倍标准差的点标记为可疑值，人工抽查确认后再决定是剔除还是保留。如果你发现某个测点频繁出现尖峰，先检查屏蔽层接地，大概率不是算法的锅。

第三是趋势漂移。设备正常磨损会导致振动幅值缓慢上升，环境温度变化也会带来信号偏移。这种慢趋势对模型训练不利，会让模型误以为"缓慢上升"本身就是故障特征。我用一阶差分和高通滤波把信号中的缓变成分去掉，只保留短时突变和高频特征，效果立竿见影。

2.3 滑动窗口与特征矩阵构建

CNN-LSTM 模型的输入不能是原始波形的一整段，而是需要切成固定长度的窗口。窗口长度我经过几轮试验确定在 512 个采样点（1 秒振动数据）作为 CNN 的输入单位，然后每次取 60 个连续窗口组成一个样本，也就是说每个训练样本覆盖 60 秒的运行数据。

这样设计是有讲究的。窗口太短，CNN 看不到足够的冲击周期；窗口太长，样本数急剧减少，训练效率下降。60 秒这个长度覆盖了挤出机螺杆旋转的多个完整周期，既能捕捉到轴承故障的周期性冲击特征，又不至于让时序信息过度平滑。

每个窗口内提取的特征包括：峰值、均方根值（RMS）、峰值因子、峭度、波形因子，再加上频域的 1x、2x、3x 转频幅值和 0-1000Hz 频段的能量分布。电流信号则计算三相电流的均值、方差和不对称度。这样每个 60 秒样本最终变成一个形状为（60，15）的特征矩阵，这个矩阵就是 CNN-LSTM 模型的标准输入。

3. CNN-LSTM 模型架构与训练细节

3.1 模型结构逐层拆解

模型结构我参考了论文里的通用设计，但根据工业数据的特性做了调整，最终结构如下：

第一层是一维卷积层，64 个卷积核，卷积核大小为 3，激活函数用 ReLU。这一层的作用是提取特征矩阵中相邻窗口之间的局部关联模式。第二个卷积层用 128 个卷积核，进一步抽象高阶特征。每个卷积层后面接一个 MaxPooling 层，池化窗口为 2，防止过拟合并降低计算量。

卷积部分的输出先经过一个 Flatten 层拉平，然后进入 LSTM 层。LSTM 单元数设置为 64，return_sequences 设为 False，只保留最后一个时间步的输出。为什么只取最后一步？因为我们关注的是当前时刻的综合健康状态，不需要每个时刻都输出预测。

最后接两个全连接层，第一层 32 个神经元加 ReLU 激活和 Dropout（丢弃率 0.3），输出层用 Softmax 输出三分类概率：正常、退化预警、故障报警。

3.2 训练策略与参数选择

训练参数经过多轮调优，最终确定值如下：

• 优化器：Adam，初始学习率 0.001。
• 损失函数：分类交叉熵，但加了类别权重。因为正常样本远多于故障样本，类别不平衡会导致模型偏向预测"正常"，我给三类样本的权重设为 正常:预警:故障 = 1 : 3 : 5。
• Batch size：64。
• 最大训练轮数：100，配合早停机制，验证集损失连续 8 轮不下降就停止训练，防止过拟合。
• 学习率调度：当验证损失连续 5 轮不下降时，学习率乘以 0.5，最低降到 0.00001。

训练集来自该产线过去 8 个月的历史数据，其中正常样本 12000 个、退化预警样本 800 个、故障样本 350 个。数据按时间顺序切分为 7:2:1，分别用于训练、验证和最终测试。这里特别提醒一下，切分数据时千万不能随机打乱，必须按时间顺序切，否则模型会"偷看"未来数据，在测试集上表现得很好，一到线上就露馅。

3.3 模型训练的完整代码示例（PyTorch 实现）

下面是完整可运行的 PyTorch 代码，包含了数据处理、模型定义和训练循环。

import torch import torch.nn as nn import numpy as np from torch.utils.data import Dataset, DataLoader # 自定义数据集 class FaultDataset(Dataset): def __init__(self, features, labels): # features shape: (num_samples, 60, 15) # labels shape: (num_samples,) self.features = torch.FloatTensor(features) self.labels = torch.LongTensor(labels) def __len__(self): return len(self.labels) def __getitem__(self, idx): return self.features[idx], self.labels[idx] # CNN-LSTM 模型定义 class CNNLSTM(nn.Module): def __init__(self, input_dim=15, hidden_dim=64, num_classes=3): super(CNNLSTM, self).__init__() self.conv1 = nn.Sequential( nn.Conv1d(in_channels=input_dim, out_channels=64, kernel_size=3, padding=1), nn.ReLU(), nn.MaxPool1d(kernel_size=2) ) self.conv2 = nn.Sequential( nn.Conv1d(in_channels=64, out_channels=128, kernel_size=3, padding=1), nn.ReLU(), nn.MaxPool1d(kernel_size=2) ) self.lstm = nn.LSTM(input_size=128, hidden_size=hidden_dim, batch_first=True) self.fc1 = nn.Linear(hidden_dim, 32) self.relu = nn.ReLU() self.dropout = nn.Dropout(0.3) self.fc2 = nn.Linear(32, num_classes) self.softmax = nn.Softmax(dim=1) def forward(self, x): # x shape: (batch, seq_len=60, input_dim=15) # Conv1d 需要 (batch, channels, length)，所以要交换维度 x = x.permute(0, 2, 1) # 变为 (batch, 15, 60) x = self.conv1(x) x = self.conv2(x) # 经过池化后序列长度为 60/2/2 = 15 x = x.permute(0, 2, 1) # 变为 (batch, 15, 128) lstm_out, _ = self.lstm(x) x = lstm_out[:, -1, :] # 取最后一个时间步 x = self.fc1(x) x = self.relu(x) x = self.dropout(x) x = self.fc2(x) return self.softmax(x) # 训练参数 BATCH_SIZE = 64 LR = 0.001 EPOCHS = 100 DEVICE = torch.device("cuda" if torch.cuda.is_available() else "cpu") # 加载数据（特征和标签由前面的数据管道生成） # train_features shape: (N_train, 60, 15) # val_features shape: (N_val, 60, 15) train_dataset = FaultDataset(train_features, train_labels) val_dataset = FaultDataset(val_features, val_labels) train_loader = DataLoader(train_dataset, batch_size=BATCH_SIZE, shuffle=True) val_loader = DataLoader(val_dataset, batch_size=BATCH_SIZE) model = CNNLSTM().to(DEVICE) # 类别权重，处理样本不均衡 class_weights = torch.tensor([1.0, 3.0, 5.0]).to(DEVICE) criterion = nn.CrossEntropyLoss(weight=class_weights) optimizer = torch.optim.Adam(model.parameters(), lr=LR) scheduler = torch.optim.lr_scheduler.ReduceLROnPlateau( optimizer, mode="min", factor=0.5, patience=5 ) # 早停逻辑 best_val_loss = float("inf") early_stop_patience = 8 early_stop_counter = 0 for epoch in range(EPOCHS): model.train() train_loss = 0.0 for features, labels in train_loader: features, labels = features.to(DEVICE), labels.to(DEVICE) optimizer.zero_grad() outputs = model(features) loss = criterion(outputs, labels) loss.backward() optimizer.step() train_loss += loss.item() model.eval() val_loss = 0.0 correct = 0 total = 0 with torch.no_grad(): for features, labels in val_loader: features, labels = features.to(DEVICE), labels.to(DEVICE) outputs = model(features) loss = criterion(outputs, labels) val_loss += loss.item() _, predicted = torch.max(outputs, 1) total += labels.size(0) correct += (predicted == labels).sum().item() avg_val_loss = val_loss / len(val_loader) val_acc = 100.0 * correct / total print(f"Epoch {epoch+1}/{EPOCHS}, Train Loss: {train_loss/len(train_loader):.4f}, " f"Val Loss: {avg_val_loss:.4f}, Val Acc: {val_acc:.2f}%") scheduler.step(avg_val_loss) if avg_val_loss < best_val_loss: best_val_loss = avg_val_loss early_stop_counter = 0 torch.save(model.state_dict(), "best_cnn_lstm.pth") else: early_stop_counter += 1 if early_stop_counter >= early_stop_patience: print("Early stopping triggered.") break print("Training complete. Best validation loss:", best_val_loss)

训练中途遇到的一个典型问题是验证集准确率在 70% 左右就卡住不涨了。排查之后发现是学习率设太高，导致损失函数在最优解附近震荡。后来我手动把学习率从 0.001 降到了 0.0003 才继续下降。这个问题在模型调参中比较常见，遇到准确率卡住先看学习率，不要急着改模型结构。

4. 模型评估、阈值调优与 92% 准确率实现

4.1 测试集上的详细评估结果

模型训练完成后，我在独立的测试集（占全量数据 10%，约 1300 个样本）上做了评估。这个测试集的样本从未参与训练和验证，能真实反映模型的泛化能力。评估结果如下：

整体准确率 = (96.8% * 1126 + 84.1% * 127 + 87.5% * 58) / 1311 ≈ 92.1%。这就是 92% 这个数字的来源。可以看到，正常类别的表现最好，故障类别的召回率偏低，这意味着还有约 17% 的故障样本没被模型提前识别出来。对于那部分样本，我后面通过调低预警阈值把它们大部分捞了回来，但代价是误报率会上升，这里需要结合现场情况做权衡。

4.2 阈值调优：寻找漏报与误报的平衡点

模型最终输出的是一个三分类概率分布，我们不是直接取最大概率类别作为结果，而是对"退化预警"和"故障报警"两个类别分别设置独立的触发阈值。

具体来说：如果 P(退化预警) > 0.45 且 P(故障报警) < 0.6，就触发"黄色预警"；如果 P(故障报警) > 0.6，触发"红色报警"。这些阈值的确定不是拍脑袋，而是基于验证集上的 Precision-Recall 曲线。我先把默认阈值 0.5 定下来测了几轮，然后手动降低退化预警阈值到 0.45、0.4、0.35 分别观察召回率和误报率的变化，最后选了既能保证召回率不低于 90%，又把误报率控制在可以接受范围的值。

这里有一个重要的业务逻辑：对于"退化预警"，我们更看重召回率，宁可多报几次也不能漏，因为多跑几次现场确认成本很低；但对于"红色报警"，我们更看重精确率，因为红色报警意味着要安排停机检查，一次误报可能导致不必要的停产。所以在同一个模型上，不同级别的预警使用了不同的最优阈值。

4.3 92% 准确率意味着什么，不意味着什么

我在项目汇报时特别强调了 92% 这个数字的边界条件。首先，这个 92% 是单台设备、单一工况下的离线测试结果，不是所有设备、所有工况都通用的标杆。换一条产线、换一种设备类型，准确率很可能掉到 80% 以下，必须重新训练和调优。

其次，92% 的准确率不代表每 100 次预警里只有 8 次是错的。由于故障样本在全部运行数据中的占比极低，即便模型有 90% 以上的召回率，实际运行中预警事件本身的精确率（发出的预警里真正出问题的比例）也不会特别高。这是预测性维护领域的一个经典问题——基数效应。举个例子，如果一条产线一个月真正会发生故障的时段只有 2%，即使模型的准确率是 95%，每 100 次预警里也可能有一半是误报。要缓解这个问题，一是提高模型本身的精度，二是在发出预警后叠加人工确认环节，比如让点检员先做一次现场检查再决定是否安排停机。

5. 系统集成：把模型接入 MyEMS 实现实时预警

5.1 整体集成架构与流程

模型离线训练完成后，接下来就是把它部署到生产环境，和 MyEMS 打通形成闭环。我的集成架构分三层：

第一层是边缘计算层。网关设备上跑一个轻量级的 Python 脚本，负责从 PLC 和传感器采集高频原始数据，在边缘实时计算特征值，然后把特征值通过 MQTT 协议推送到 MyEMS 的数据接入服务。

第二层是 MyEMS 平台层。MyEMS 的数据服务收到特征值后写入数据库，同时在后台定时任务中调用训练好的 PyTorch 模型，对最近 60 秒的特征矩阵进行推理，得到故障概率。

第三层是展示与告警层。预测结果回写到 MyEMS 的自定义数据表，同时在页面上展示设备健康评分、趋势曲线和预警历史记录。当模型输出的概率超过阈值时，MyEMS 的告警模块自动发送通知给维保人员。

整体流程可以概括为一句话：边缘算特征，平台跑模型，页面看趋势，告警找人。

5.2 MyEMS 扩展数据表的建表方法

MyEMS 原生数据模型不包含故障特征和模型预测结果字段，所以需要在它的数据库里扩展几张自定义表。第一张表存特征值，第二张表存模型预测结果。

我以 MySQL 为例演示建表语句（MyEMS 支持 MySQL 和 PostgreSQL，语法差别不大）：

-- 扩展表1：设备特征值表 CREATE TABLE `equipment_feature_values` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `equipment_id` INT NOT NULL COMMENT '设备ID，关联MyEMS设备表', `feature_json` JSON NOT NULL COMMENT '特征值JSON，如峰值RMS峭度等', `sample_time` DATETIME NOT NULL COMMENT '采样时间', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_equipment_sample` (`equipment_id`, `sample_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 扩展表2：模型预测结果表 CREATE TABLE `fault_prediction_results` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `equipment_id` INT NOT NULL COMMENT '设备ID', `predict_class` TINYINT NOT NULL COMMENT '预测类别：1正常 2退化预警 3故障报警', `normal_prob` DECIMAL(5,4) NOT NULL COMMENT '正常概率', `warning_prob` DECIMAL(5,4) NOT NULL COMMENT '退化预警概率', `fault_prob` DECIMAL(5,4) NOT NULL COMMENT '故障报警概率', `predict_time` DATETIME NOT NULL COMMENT '预测时间', `is_processed` TINYINT NOT NULL DEFAULT 0 COMMENT '是否已处理', PRIMARY KEY (`id`), KEY `idx_equipment_predict` (`equipment_id`, `predict_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

两张表建好之后，在 MyEMS 的数据库配置里指向同一个库即可。MyEMS 的界面不会自动显示这几张表，需要在它的自定义页面模块里手动添加快捷链接，或者用它提供的 API 把数据查询出来接到自己的前端页面上。

5.3 实时推理与告警触发

MyEMS 平台上部署模型推理，我没有采用复杂的模型服务框架（比如 TensorFlow Serving 或 Triton），而是写了一个 Python 定时任务脚本，每 60 秒批量处理一次最近到达的新增特征数据。识别速度完全够用，因为故障预警本来也不是秒级的需求，60 秒的延迟对预测性维护没有任何影响。

import pymysql import json import numpy as np import torch from datetime import datetime, timedelta # 从数据库读取最近60秒的特征数据 def fetch_recent_features(equipment_id, minutes=1): conn = pymysql.connect(host="localhost", user="myems", password="***", database="myems") cursor = conn.cursor() sql = """ SELECT sample_time, feature_json FROM equipment_feature_values WHERE equipment_id = %s AND sample_time >= NOW() - INTERVAL %s MINUTE ORDER BY sample_time ASC """ cursor.execute(sql, (equipment_id, minutes)) rows = cursor.fetchall() cursor.close() conn.close() features = [] for _, feature_json in rows: features.append(json.loads(feature_json)) return features # 推理函数 def predict_fault(model, features, device): # features 长度必须为60，不足则跳过本次推理 if len(features) < 60: return None # 只取最近60个窗口 features = features[-60:] feature_matrix = np.array(features) # shape: (60, 15) input_tensor = torch.FloatTensor(feature_matrix).unsqueeze(0).to(device) model.eval() with torch.no_grad(): outputs = model(input_tensor) probs = outputs.cpu().numpy()[0] return probs # 主流程 def main(): device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model = CNNLSTM().to(device) model.load_state_dict(torch.load("best_cnn_lstm.pth", map_location=device)) equipment_id = 1024 # 替换为实际设备ID probs = predict_fault(model, fetch_recent_features(equipment_id), device) if probs is None: return warning_prob = probs[1] fault_prob = probs[2] # 根据阈值判断预警级别 if fault_prob > 0.6: predict_class = 3 elif warning_prob > 0.45: predict_class = 2 else: predict_class = 1 # 写入预测结果表 conn = pymysql.connect(host="localhost", user="myems", password="***", database="myems") cursor = conn.cursor() sql = """ INSERT INTO fault_prediction_results (equipment_id, predict_class, normal_prob, warning_prob, fault_prob, predict_time) VALUES (%s, %s, %s, %s, %s, %s) """ cursor.execute(sql, (equipment_id, predict_class, probs[0], probs[1], probs[2], datetime.now())) conn.commit() cursor.close() conn.close() # 高等级预警发送通知到钉钉机器人 if predict_class == 3: send_dingtalk_notification(equipment_id, f"红色故障报警，故障概率 {fault_prob:.2%}") elif predict_class == 2: send_dingtalk_notification(equipment_id, f"黄色退化预警，预警概率 {warning_prob:.2%}") if __name__ == "__main__": main()

MyEMS 的定时任务机制可以用系统的 crontab 实现，我设置了每分钟执行一次这个脚本。如果想在 MyEMS 的前端页面直接看到预测结果，可以通过 MyEMS 的自定义接口模块暴露一个 HTTP API，返回最近的预测趋势数据，前端用 ECharts 画一个健康度曲线和预警时间线。这样现场维护人员打开 MyEMS 页面就能看到设备状态，不需要额外打开其他系统。

6. 常见问题与排查技巧实录

6.1 现场数据质量问题排查

问题一：模型上线后频繁误报。我碰到过第一次上线第一天就连续报了 8 次红色报警，点检员跑到现场一看设备都正常。排查后发现是数据接口的字节序配置错了，导致振动传感器读到的数据是乱码，特征值全都不对。这种问题隐蔽性极强，数据在数据库里看着有值，但实际上是错的值。排查方法是把特征值和原始波形做对比，用一块已知状态的设备试跑 10 分钟，看特征趋势是否合理。

问题二：特征值频繁跳变。有一台设备的峰值特征每隔几分钟就出现一个很大的尖峰，用中值滤波也压不住。后来发现是现场有一台变频器在调频时产生的电磁干扰。解决方案不是改算法，而是给传感器信号线换了屏蔽双绞线，并把屏蔽层单端接到了设备接地端。工业现场的数据问题，很多时候先从物理层排查比调算法参数更有效。

6.2 模型层面的典型问题与对策

问题三：模型在训练集上表现好，一上测试集就崩。这个基本是数据泄漏。最常见的原因是在做特征缩放时用了全数据集的均值和标准差，导致测试集的信息提前进入了训练过程。正确做法是只在训练集上计算均值和标准差，然后直接用这两个值去归一化验证集和测试集。

问题四：召回率一直上不去。我试过降低阈值、调整类别权重、增加故障样本的过采样，效果都不是特别明显。最后发现真正的原因在于故障样本量实在太小，只有 350 多个，还分布在不同工况下，模型根本学不到足够丰富的故障模式。解决思路有两个：一是用生成对抗网络做故障样本扩充，二是从其他工况近似的数据域借用预训练权重再做迁移学习。第二个方案在实践里更简单，效果也更稳定。

6.3 日常运维中的避坑经验

预警模型上线不是终点，而是运营的起点。我有三个特别想强调的经验：

第一，模型要周期性重训。设备的工况会随着季节、产品批次、刀具磨损程度发生变化，离线训练时用的数据分布跟当前实时数据分布会逐渐产生偏移。我建议每个月或者每个季度用最近三个月的数据重训一次模型，用之前的模型做基准对比，如果新模型在验证集上准确率提升超过 1 个百分点就替换。

第二，给每次预警都记录"归因标签"。当维保人员处理完一次预警后，让他在系统里标记这次预警是"真故障"还是"误报"，是"轴承磨损"还是"齿轮点蚀"。这些标记数据会不断累积成新的标注样本，未来的模型重训会越来越准，这是持续优化模型最宝贵的燃料。

第三，千万不要把模型预测结果直接接入自动停机逻辑。预测性维护的目的是给人留出决策时间，而不是替代人的决策。在现有流程里，模型的红色报警只作为建议通知维保主管，由主管结合现场点检情况决定是否安排停机检修。自动停机看起来很高端，但一旦误报就会造成严重的非计划停产，这不符合预测性维护的本意。

7. 后续可扩展的方向

这个项目做完之后，我又在几个方向上做了进一步尝试。一个是把 CNN-LSTM 模型的预测结果和设备的能耗数据联动，建立"效率退化"维度。设备开始劣化时，往往伴随着单位产品能耗的上升，这跟故障预警是互补的信号。另一个方向是多设备联合建模，把同一条产线上的多台设备视为一个整体，利用设备间的耦合关系提升单台设备的预警精度。

还有一个小技巧值得分享：在 MyEMS 里把设备的健康评分做成一个可视化仪表盘，每天定时推送给产线主管。健康评分由模型输出的故障概率经过一个平滑函数转换而来，比如 100 分减去故障概率乘以 100。这样即使不懂深度学习的人，也能一眼看出哪台设备需要重点关注。我实际使用中发现，这种"低技术门槛"的呈现方式，比任何复杂的模型架构都更能推动预测性维护在工厂落地。技术做得再好，用不起来，一切都是零。