简介预测性维护2.0PhoenixContactPLCnext的振动频谱深度学习是一份聚焦工业设备智能运维的技术文档面向嵌入式开发、PLC编程与设备维护工程师尤其适合智能制造、能源管理等领域的技术人员。文档以PhoenixContact PLCnext平台为主线系统讲解预测性维护从传统模式向数据驱动模式演进的路径涵盖振动信号产生机理、时域与频域分析、傅里叶变换应用以及CNN、LSTM等深度学习模型在振动频谱特征提取与故障诊断中的实战方法。全文共26页采用单个PDF文件打包压缩包大小仅1.74MB支持目录章节跳转及阅读器左侧大纲快速定位内容结构完整、图文清晰便于按需查阅。目前已有26人学习使用。除基础理论外文档还提供了Python与Structured Text代码示例、基于PLCnext的软硬件搭建步骤、案例研究与经济性分析有助于读者在真实场景中快速落地预测性维护方案。1. 把振动频谱深度学习压进 PLCnext 控制器才能抓住转瞬即逝的故障特征在传统预测性维护方案里振动数据要先上传到云端再由后端跑谱分析和深度学习模型。这个链路在数据中心没问题但到了风机塔筒、注塑机机台和大型泵组旁边抖动网络、时断时续的工业无线和不在同一网段的设备群都会让“边缘-云端”这条路变脆。Phoenix Contact PLCnext 控制器里跑的是 Linux支持 Python/C 应用容器本身又有实时 IO 采集能力意味着可以把频谱计算和深度学习推理放到设备侧完成传感器采集、滑动窗口 FFT、CNN 分类都在同一个控制器内闭环故障特征出现后的几十毫秒内就能给出预警。这不是让 PLC 去取代振动分析仪而是把 PLCnext 当工业边缘节点用只承担最适合本地处理的这一层。适合正在做预测性维护 2.0 落地、又不想依赖云端推理的自动化与 IT 融合团队。2. PLCnext 振动频谱预处理从原始波形到频谱张量在训练深度学习模型之前必须先解决一个问题喂给模型的频谱数据怎么来。在 PLCnext 环境下振动信号一般通过 IEPE 加速度计进入控制器接线方式有两种一种是用支持 IEPE 供电的模拟量输入模块直接接入另一种是把加速度计接到独立采集终端再通过 EtherCAT 总线把原始波形同步到 PLCnext。两种方式在程序侧没有差别后文代码都只需要一个返回一维 float 数组的采集函数。2.1 采样率、抗混叠与 FFT 窗口的三个关键参数振动频谱深度学习最容易在第一步埋坑采样率不够轴承故障的特征频率被混叠成低频尖峰模型学得再好也会把缺陷当正常。我一般先把目标频率范围定下来。普通电机和泵组分析 010 kHz 已经覆盖到轴承故障特征频率和主要倍频要观察齿轮箱啮合频率至少要分析到 30 kHz。根据奈奎斯特采样定律采样率取分析带宽的 2.56 倍是工程上稳妥的做法也就是常见振动分析仪里 25600 Hz 对应 10 kHz 带宽。FFT 窗口长度直接影响频率分辨率。分辨率的计算公式是 Δf fs / N比如 25600 Hz 采样、取 1 秒窗长N 25600频率分辨率只有 1 Hz。滚动轴承的外圈内圈故障特征频率往往不是整数值1 Hz 分辨率足够识别但相邻的倍频成分如果靠得太近就需要更长的窗口。LSTM 这类时间序列模型对长度敏感而 CNN 对频谱形状敏感所以窗口长度不能拍脑袋。下面这张表是我在调试 PLCnext 振动项目时常用的默认参数设备类型分析带宽采样率窗口长度频率分辨率普通电机0~10 kHz25.6 kHz1 s1 Hz高速主轴0~20 kHz51.2 kHz2 s0.5 Hz齿轮箱0~30 kHz76.8 kHz4 s0.25 Hz需要注意PLCnext 是 PLC不是专用采集卡模拟量采集的实时性受循环周期影响。我一般不在中断里做 FFT而是把原始波形写到环形缓冲再放到 Linux 用户态线程里批量处理。这样即使某一段波形因为总线抖动少了 100 个样本也不至于让整个推理链路崩溃后面在频谱张量里直接按时间戳对齐即可。2.2 用 SciPy 在 PLCnext 中实现滑动窗口 FFTPLCnext 的 Python 运行时一般基于容器部署常见做法是在 PLCnext Store 或自定义镜像里安装 numpy 和 scipy再通过控制器网口映射到宿主机。下面这段代码可以在 PLCnext 的 Python 容器里直接运行import numpy as np from scipy.signal import welch SAMPLE_RATE 25600 # 25.6 kHz 采样 WINDOW_SEC 1.0 # 频谱窗口 1 秒 N_PER_SEG 4096 N_OVERLAP N_PER_SEG // 2 def compute_spectrum(ring_buffer): # ring_buffer 是最近 1 秒的原始振动信号 windowed ring_buffer * np.hanning(ring_buffer.size) freqs, psd welch( windowed, fsSAMPLE_RATE, npersegN_PER_SEG, noverlapN_OVERLAP, scalingdensity ) # 只保留 0~10 kHz 部分后续模型输入固定为 2048 维 mask freqs 10000 return freqs[mask], psd[mask]代码里welch用的是 Welch 平均周期图法把 1 秒信号切成多个 4096 点小段分别做 FFT 再平均能显著降低频域方差。nperseg决定谱的形状太大则时间平均不足太小则频率分辨率下降对 1 秒窗口来说4096 是兼顾速度和细节的取值。最后用 mask 把 10 kHz 以上的部分去掉一方面减少计算量另一方面也避免传感器共振频段干扰模型训练。得到psd之后我会将它取对数再做归一化形成固定维度的一维频谱张量直接喂给后面的深度学习模型。这个预处理不依赖 PLCnext 的特殊 API普通 Python 环境也可以跑方便先在 PC 上把整条链路调通再搬到 PLCnext 里。现场调试时还需要检查一个容易被忽略的点PLCnext 的容器 CPU 配额如果设得太低FFT 线程会被系统调度打断频谱会周期性出现整段噪声。遇到这种情况我会先调大容器内存限制再把 FFT 线程绑定到第二个 CPU 核上。3. 在 PLCnext 中部署 CNN 振动频谱分类模型题目里说的“振动频谱深度学习”最直接的落点是对频谱图做分类。深度学习常用的模型有很多但到了 PLCnext 这种 Arm 架构工业控制器上模型参数量和推理延迟都要被严格约束。一维 CNN 是这里最合适的选择之一。3.1 为什么用一维 CNN 而不是 LSTMLSTM 在时间序列预测里确实很强但振动频谱已经把时域波形转成了频域能量分布。频谱中的故障特征表现为某些频带的能量集中、边带结构和倍频关系这些更像是局部模式组合而不是长距离时序依赖。一维 CNN 的感受野逐层扩大第一层卷积核看见若干频点第二层就能组合出边带和倍频结构这种归纳偏置非常适合频谱张量。另外推理延迟在工业环境里是硬指标。LSTM 需要逐步推理在 PLCnext 的 CPU 上容易出现批次变长导致延迟抖动CNN 是一次性前向传播每层都是固定矩阵运算更容易在规定的扫描周期内完成。我曾在类似配置的 Arm 控制器上做过对比相同精度的 CNN 比 LSTM 快 5 倍以上内存占用少一个数量级。对于预测性维护 2.0 的现场场景我会把深度学习模型分为两条路线监督分类路线适用于已知故障样本较多的设备直接输出“正常、不平衡、轴承外圈故障、轴承内圈故障、松动”五类。频谱残差路线则用于故障样本不足的现场用自编码器学习正常频谱的流形再以重建误差作为异常分数。后者在预测性维护 2.0 里越来越常见因为真实设备上“坏样本”总是很难等。3.2 在 PC 上训练一个频谱 CNN 并导出 ONNX训练环境和 PLCnext 运行时环境可以完全分离。我在 PC 上用 PyTorch 训练模型输入特征是上一章生成的 2048 维对数功率谱。以下是一个足够小的 CNN 结构import torch.nn as nn import torch CLASSES [normal, unbalance, bearing_outer, bearing_inner, looseness] class VibrationCNN(nn.Module): def __init__(self): super().__init__() # 输入形状(batch, 1, 2048) 的频谱张量 self.conv nn.Sequential( nn.Conv1d(1, 16, kernel_size8, stride2, padding3), nn.BatchNorm1d(16), nn.ReLU(), nn.MaxPool1d(2), nn.Conv1d(16, 32, kernel_size5, stride2, padding2), nn.BatchNorm1d(32), nn.ReLU(), nn.AdaptiveAvgPool1d(8) ) self.head nn.Linear(32 * 8, len(CLASSES)) def forward(self, x): x self.conv(x) return self.head(x.flatten(1))这个模型参数量只有两万多文件大小不到 100 KB。训练时注意把每一类样本按不同时间段的采集记录切分而不是把一个连续波形切成的相邻窗口同时放进训练集和测试集否则频谱之间的相关性会让验证指标虚高。训练收敛后用验证集确定早停轮次再导出 ONNXmodel VibrationCNN() model.load_state_dict(torch.load(vib_cnn.pt)) model.eval() dummy torch.randn(1, 1, 2048) torch.onnx.export( model, dummy, vib_cnn.onnx, input_names[spectrum], output_names[logits], dynamic_axes{spectrum: {0: batch}}, opset_version11 )opset_version11是 ONNX Runtime 兼容性和新算子之间的平衡点PLCnext 容器里的 ONNX Runtime 不一定支持更高版本。导出的vib_cnn.onnx放进 PLCnext 容器目录后后续部署只需要加载一次模型避免每次推理都重复读取文件。部署方式的选择可以看下表部署方式模型大小推理延迟参考适用场景原始 ONNX FP32~100 KB5~10 ms大多数 PLCnext 现场ONNX int8 量化~30 KB2~4 ms高速主轴、超大窗口自编码器残差模型~80 KB8~15 ms故障样本不足的未知设备延迟数值受 PLCnext 的 Arm CPU 主频和容器资源配额影响上表只是我测试过的量级不是产品指标。量化虽然能降低延迟但必须用设备的真实频谱数据校准否则精度损失可能在 5% 以上。4. 预测性维护 2.0 标定故障频率、阈值与误报控制深度学习模型不是一训就完。现场最常见的问题是正常样本远多于故障样本训练后的模型会倾向于把所有状态判为“正常”。所以落地时必须结合物理标定和动态阈值把深度学习的输出变成稳定的告警信号。4.1 用轴承故障特征频率校核 CNN 的分类结果CNN 输出的概率分布不能直接当告警依据。我建议先用轴承故障特征频率公式做一层物理校核。比如外圈故障频率 BPFO、内圈故障频率 BPFI 由滚动体数量、转频和接触角共同决定不同设备之间可能接近。当 CNN 把某种频谱判为“轴承外圈故障”时调试者应该能在频谱图上看到对应的外圈特征频率及其倍频。特征频率近似计算公式诊断意义转频 f_r转速 / 60轴类故障的基础频率外圈 BPFO0.4 × N × f_r外圈缺陷内圈 BPFI0.6 × N × f_r内圈缺陷保持架 BTF0.4 × f_r保持架异常这些公式在精度上不够严格但用来校核模型输出等级足够了。如果 CNN 高概率输出“内圈故障”而频谱主峰却集中在外圈特征频率附近就要怀疑训练样本标注错误而不是急着调阈值。把特征频率计算写成 PLCnext 上的一个查询函数每次模型输出后自动对比可以大大降低“自信误判”。4.2 频谱残差与 EWMA 动态阈值抑制误报生产现场转速波动、负载变化都会引起频谱能量整体偏移固定阈值会频繁报警。常见做法是让模型维护一个“正常频谱”的残差流形用训练好的自编码器重建当前频谱重建误差越大说明越远离正常模式。然后对重建误差做指数加权平均再叠加 n 倍标准差作为动态阈值。class AdaptiveThreshold: def __init__(self, alpha0.02, k5): self.alpha alpha self.k k self.mean 0.0 self.var 0.0 def update(self, residual): # residual 来自自编码器重建误差 self.mean (1 - self.alpha) * self.mean self.alpha * residual self.var (1 - self.alpha) * self.var self.alpha * (residual - self.mean) ** 2 threshold self.mean self.k * np.sqrt(self.var) return threshold这里的alpha决定阈值跟踪速度。太大阈值会跟着故障信号走异常永远追不上太小对设备老化这类缓变漂移不收敛。我一般设 0.02相当于约 50 个频谱窗口完成一次基线更新。k是标准差倍数k5 时误报很少但早期轻微故障可能漏报。现场先记录两周正常数据得到稳定基线再根据可接受的最大漏报率去调 k。参数调整时还要注意 PLCnext 的扫描周期和频谱窗口之间的匹配关系。比如窗口是 1 秒重叠率 50%那么每 0.5 秒就产生一条频谱如果update放在每个频谱都执行alpha0.02的等效时间常数只有 25 秒这对大多数慢变故障已经足够。对冲击性瞬时故障阈值模块应该主动冻结避免一次瞬态冲击就把基线拉偏。5. 在 PLCnext Runtime 里回放历史频谱验证深度学习模型命中率模型部署完不是结束必须验证在 PLCnext 上跑的模型和 PC 上训练时的表现是否一致。最直接的办法是用历史振动数据做离线回放把现场录制好的原始波形文件放进 PLCnext 容器重新计算频谱再让模型逐条推理与停机检修记录做对照。5.1 用 ONNX Runtime 批量回放历史数据PLCnext 容器里加载 ONNX 模型只需要 onnxruntime推理代码很简短import onnxruntime as ort import numpy as np sess ort.InferenceSession(vib_cnn.onnx, providers[CPUExecutionProvider]) def infer_spectrum(psd): input_data np.expand_dims(psd.astype(np.float32), axis(0, 1)) logits sess.run(None, {spectrum: input_data})[0] probs softmax(logits[0]) return int(np.argmax(probs)), float(np.max(probs))回放时把每条频谱的时间戳、模型输出、最大概率和频谱文件路径写入 CSV方便后期和检修记录对照。这里有一个常被忽略的细节PLCnext 文件系统写入较慢不要在推理循环里逐条写盘应该在容器内存里积累成一个列表等到回放结束后一次性写出。这样既避免 IO 阻塞又不会漏掉高并发推理时的数据。5.2 验证命中率时加入未知故障样本最后一个技巧不要只用已知故障类别去衡量模型命中率。我会在验证集中故意混入几种训练时从未出现过的故障波形看模型会给出什么反应。如果模型对未知故障也输出 95% 以上的置信度指向某一个已知类别说明特征提取鲁棒性不足后面的维护动作很可能是错误的。在 PLCnext 推理逻辑里同时输出 softmax 的最大概率低于 0.75 的状态一律进入“待观察”缓冲由频谱残差模块决定是否告警。这个方法在多个预测性维护 2.0 项目里都能显著减少“自信误判”比单纯调阈值更有效。把这种带未知故障样本的回放流程固化成一个自动化脚本每次模型更新后都跑一遍就能长期守住告警准确率这条底线。本文还有配套的精品资源点击获取
