引言2019年秋天浙江慈溪一家轴承厂的设备主管老陈给我打了个电话。 我们厂里有台磨床三个月前刚换的轴承上星期又崩了整条产线停了18个小时。 我到现场一看振动监测系统是有的——2008年装的一套国产设备8个通道同时采数据屏幕上花花绿绿的频谱图一直在跳。但问题在于没人看得懂。操作工会看灯——绿灯正常黄灯注意红灯停机。等红灯亮起来的时候轴承内圈已经剥落了0.3毫米神仙都救不回来。 这就是传统振动分析在制造业里最典型的处境——有数据、有设备、缺判断力。 ! 预测性维护一、从一根振动传感器说起说白了预测性维护的第一步就是把物理信号变成数字。 最常用的传感器是IEPE型加速度传感器——说白了就是一个压电晶体设备振动的时候晶体受压产生电荷经内置放大器转成电压信号。市面上常见的像PCB 356A16、CTC AC102几百到一千多块钱一个工业级够用了。 数据采集这块现在主流方案是用NI的采集卡或者国产的阿尔泰板卡采样频率一般设到振动特征频率的10倍以上。举个例子你监控的轴承特征频率大概在2000Hz左右那采样率至少设到20kHz。有个细节很多人不注意——采样频率设太高了噪声也跟着上来25600Hz是个不错的选择正好是2的幂做FFT快。 采集到的原始数据长这样 - 一个10秒的采样窗口 - 256000个加速度数据点 - 采样率25.6kHz 光看时域波形说实话跟心电图似的看着唬人但没什么用。 ! 预测性维护二、传统频域分析的三板斧有了时域数据下一步就是转到频域这是预测性维护的老本行。 我刚入行的时候跟一个搞振动诊断20年的老师傅学的他管这叫做三板斧第一板斧频谱分析FFT把时域信号做快速傅里叶变换横轴是频率纵轴是幅值。轴承内圈故障在频谱上会表现为特征频率 BPFIBall Pass Frequency Inner处出现峰值。拿6205轴承举例转速1797RPM的时候BPFI大概是162Hz。如果在162Hz处看到有突起八九不离十是内圈出了问题。第二板斧包络谱分析有时候轴承早期故障的信号太小被齿轮啮合频率这种大信号盖住了。这时候先做希尔伯特变换取包络再做频谱微弱信号就出来了。这招特别好使我在某化工企业的循环水泵上靠这个方法提前三周预警了一次轴承外圈剥落。第三板斧时频分析短时傅里叶/小波频谱分析有个致命缺陷——它假设信号是平稳的。但实际工况经常在变电机启动、负载波动、变速运行都是非平稳信号。这时候用短时傅里叶变换STFT或者连续小波变换CWT能同时看到频率随时间的变化。 你可能会问三板斧都上了是不是就万事大吉了 说实话远远不够。 这三个方法本质上都是在看图找规律——说白了就是依赖人的经验。资深诊断工程师能一眼看出轴承内圈磨损和外圈剥落的频谱特征不一样但这样的人整个行业没多少。而且人总会疲劳、漏看、判断失误。三、机器学习是怎么杀进来的大概2018年前后深度学习开始往工业领域渗透预测性维护大概是落地最快的场景之一。 核心逻辑其实不复杂把故障诊断从一个看图找规律的问题变成一个分类问题。 传统的做法是人工提取特征均值、峰峰值、峭度、频谱能量分布……→ 扔进一个分类器SVM、随机森林→ 输出故障类型。这条路大概2015年左右就在学术界走通了工业界跟进得慢一些。 后来深度学习的路子更暴力直接把原始振动波形或者频谱图喂给卷积神经网络CNN让网络自己去学特征。2019年有个叫WDCNN的模型Zhang et al., 2019在凯斯西储轴承数据集上准确率干到了99%以上当时在PHM圈子里轰动不小。 但我想泼盆冷水。 凯斯西储的数据集是在实验室里拿电火花加工的人造缺陷转速恒定、负载恒定跟工厂真实工况差了十万八千里。我见过的真实产线上模型准确率能稳定在90%以上就是非常不错的表现了。 反过来想在工业场景里准确率高有时候反而是坏事——说明你的数据太干净了模型没见到真正的工况变化一旦上线遇到噪声、负载波动、传感器松动这些问题直接崩。 一个实用的Python示例——用scikit-learn搭一个轴承故障分类器 python import numpy as np from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report特征提取函数踩坑提醒这里的窗长和重叠率要根据具体转速调def extract_features(signal, fs25600): window 2048 overlap 1024 features [] for start in range(0, len(signal) - window, overlap): frame signal[start:startwindow] features.append([ np.mean(frame), # 均值 np.std(frame), # 标准差 np.max(np.abs(frame)), # 峰值 # 峭度——对冲击类故障特别敏感 np.mean((frame - np.mean(frame))4) / np.std(frame)4, ]) return np.array(features).mean(axis0).reshape(1, -1)假设你已经有了打好标签的数据 X 和 yX: (n_samples, 4) 特征矩阵y: (n_samples,) 0正常, 1内圈, 2外圈, 3滚珠X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, stratifyy, random_state42 )随机森林——现阶段工业场景最实用的选择不用GPU、不调参也能跑出不错的效果rf RandomForestClassifier( n_estimators100, max_depth10, random_state42 ) rf.fit(X_train, y_train) y_pred rf.predict(X_test) print(classification_report(y_test, y_pred)) 注意这里有个细节峭度这个特征对轴承冲击类故障极其灵敏但如果你做的是齿轮磨损渐变型故障峭度的效果就没那么好了。所以特征工程要跟故障机理对上而不是无脑堆。四、一个完整的端到端方案长什么样说说我们团队去年给一家钢铁企业做的一个项目整体架构大概分了四层数据采集层20台风机的驱动端和非驱动端各装一个加速度传感器加上一个转速传感器做同步采样。数据通过边缘网关用的研华UNO-2484G跑Linux做本地缓存和预处理再通过MQTT推到云端。特征工程层边缘侧实时计算时域特征RMS、峰峰值、峭度、波峰因子频域特征在云端用Spark做批量FFT和包络谱分析。这一层最关键的设计决策是什么特征在边缘算、什么特征上云算——既要保证实时性又要控制带宽成本。模型推理层我们同时跑了两个模型一个轻量级随机森林在边缘侧做毫秒级实时报警一个CNN在云端每小时跑一次做精细诊断。两个模型的判断再做一次融合投票。这个双模型架构看起来重实际上比单独跑一个大模型在边缘侧更可靠——万一断网了至少边缘侧的轻模型还能撑住。决策与展示层Grafana做实时仪表盘InfluxDB存时序数据维保工单自动推企业微信。故障预测结果分三个等级预警48小时、告警24小时、紧急停机6小时内。 有意思的是这个项目上线三个月后发生了一件事系统在一次计划停机前72小时发出了驱动端轴承内圈早期磨损的橙色告警。检修人员打开轴承座一看内圈上确实出现了0.08mm的微剥落——肉眼几乎看不到但模型的峭度特征已经明显上扬了。这次提前发现帮他们避免了约12小时的意外停机按照那条产线的产值计算单次止损超过30万。写在最后预测性维护这条路从傅里叶变换走到深度学习跨度超过半个世纪。但工具在变核心问题其实一直没变你能不能在设备还没坏的时候就感知到它在不舒服。 刚入行的时候我沉迷于各种花哨的模型——Transformer、图神经网络、自监督学习啥都往上堆。后来发现真正在产线上跑得稳的是那些基本功扎实的方案传感器装对了位置、数据采干净了、特征提取贴合故障机理、报警阈值调得合理。 说到底预测性维护不是一道算法题它是一道工程题。 如果你正在做或者打算做这方向我的建议是先花时间搞懂你要监控的设备再考虑用什么模型。别像我一样走了两年弯路才明白这个道理。