1. 从“选模型”到“信模型”的转变为什么故障诊断突然开始谈可解释性这两年做工业故障诊断的人大概都有一种共同的焦虑模型越来越准但胆子越来越小。卷积神经网络的准确率能轻松做到98%以上Transformer变体换着花样刷新指标但当你真的把模型部署到产线上设备主管问一句“它凭什么说这台泵的轴承坏了”你多半会愣住。因为深度学习模型给不出理由它只会给你一个概率值然后剩下的是黑箱。更麻烦的是黑箱模型一旦误报代价不只是停机还有整个班组对这套系统的信任崩塌——一次说不清原因的误报警比十次正确的报警更摧毁落地项目的生命力。这就是“可解释性”被反复提及的根本原因。它不是学术圈自嗨的新鲜词而是工业落地场景里绕不开的硬需求。故障诊断行业正在经历一个从“选一个准的模型”到“信一个能解释的模型”的阶段转换尤其是进入PHM故障预测与健康管理体系化建设之后准确率和可解释性已经不是二选一的取舍问题而是必须同时交付的两个指标。这个问题本质上是两类技术范式长期割裂的后果机理驱动方法有天然的物理逻辑但面对复杂工况常常建不出足够精确的模型数据驱动方法几乎不依赖物理假设能逼近任意非线性关系但代价是决策过程难以被人理解。跨过这条鸿沟就是现阶段故障诊断领域最值得投入的方向。我们团队过去三年落地过几个诊断项目从旋转机械的轴承故障到齿轮箱点蚀从泵组的空化到电机的匝间短路走了一圈之后我最大的体会是单纯堆准确率是最好做的事真正考验功力的地方是如何让模型在给出结论的同时给出让人信服的证据链。这篇文章就把我个人在这条路上摸索出的思路、方法、代码层面的落地方案以及踩过的坑完整做个梳理。2. 两种范式的“龟兔赛跑”机理模型的严谨与数据模型的强悍2.1 机理模型的天然优势与真实局限机理驱动方法说白了就是“先懂设备再判断故障”。工程师根据物理原理建立数学模型用方程去描述设备在健康状态和故障状态下的行为差异。比如滚动轴承的故障特征频率计算就是最典型的机理知识——外圈故障频率、内圈故障频率、滚动体故障频率都能用转速、几何尺寸算出来。理论上只要在频谱里找到这些特征频率及其谐波就能定位故障位置。这套逻辑的优势非常明显每个诊断结论都有物理依据可解释性天然饱满。你说轴承外圈有故障依据是频谱里出现了外圈故障特征频率的峰值这个解释工程师一听就认。在故障机理明确、设备结构相对简单、工况稳定的场景下机理模型非常可靠而且计算开销小这对工业现场大量边缘设备来说是硬指标。但它的局限同样突出。真实工业设备不是教科书里的理想模型转速波动、负载变化、多源耦合振动、传递路径衰减这些因素会让理论计算的特征频率发生偏移甚至淹没在噪声里。更麻烦的是复合故障、早期微弱故障、变工况条件下的故障特征很多时候机理模型根本给不出足够精确的数学描述。我见过不少把机理模型做到极致精细的项目模型复杂到仿真一跑就是几十个小时但真到现场一看测量条件和仿真边界条件差太远精度反而不如简单的频谱幅值对比。2.2 数据模型的强悍拟合与解释困境数据驱动方法是另一方极端。深度学习的理论拟合能力已经被反复验证你给它足够多的故障样本它就能自动从原始振动信号里学习到人类难以手工设计的特征。端到端的诊断模式是输入时域波形或频谱输出故障类别。准确率可以在公开数据集上做到碾压级水平甚至不需要信号处理的专家知识。问题在于模型学到了什么没人知道。CNN在卷积层提取的到底是故障特征频率还是某个环境噪声完全不透明。我们曾经在一次电机故障诊断实验里发现模型准确率高达99%但后来排查才发现数据集里有泄漏——健康样本和故障样本是在不同时间批次采集的模型学到的根本不是故障特征而是采集时间的分布差异。这要是直接上产线必然翻车。这就是数据模型最大的软肋它给出的结论没有可以追溯的物理证据。在学术论文里混淆矩阵和准确率就够了但在工业项目里客户要的是一份能写进维修工单的说明——“根据振动频谱中的哪几个特征判定存在何种故障建议安排什么检修”。数据模型给不出这种说明你总不能写“因为神经网络第37个神经元激活了”吧。2.3 为什么“准确率优先”策略在工业现场常常失效这两套范式各走极端但在真实工业场景里我们需要的其实是一个“中间状态”的解决方案准确率不能比纯数据模型差太多解释性不能比纯机理模型弱太多。这里要说一个很扎心的行业现实准确率在实验室是唯一指标在现场只是门槛指标。产线上的设备管理人员对诊断系统的基本信任来自——每次报警都能说清楚为什么每次不报警都有合理依据。一旦出现“哑巴报警”哪怕整体准确率是99%那1%的误报也会消耗掉大量信任储备。等你真的遇到设备故障而系统没有报警时整个系统就会被贴上“不靠谱”的标签再难翻身。在PHM体系建设里诊断只是中间环节后面还跟着维修决策和备件计划。一个只有结论没有依据的诊断结果没法支撑后续的RCM以可靠性为中心的维修分析。这也是为什么越来越多的行业标准开始明确要求诊断系统具备可解释的证据输出能力。所以说兼顾准确性和可解释性不是洁癖式的学术追求而是决定项目能否长期运转的现实需要。3. 真正的解法不是二选一而是“知识嵌入数据”三条可行的融合路线3.1 路线一物理特征作为先验特征输入最容易上手、最稳妥的融合思路是把机理知识转化为特征输入让数据模型在物理特征的基础上做学习。操作上不直接向模型输入原始振动波形或全频段频谱而是先把机理公式计算出的故障特征频率、边频带间隔、包络谱特征、时域统计指标等构造成特征向量再送入分类器。我们在轴承故障诊断项目里验证过这个思路。经典的CNN方案直接用原始信号做输入准确率确实高但无法解释我们改成混合特征方案后输入端包含FFT频谱主要峰值频率、包络谱特征频率幅值、时域峭度和均方根等19个特征模型用梯度提升树或轻量级MLP做分类。准确率比端到端CNN低大约1.5个百分点但每次诊断结果都能回溯到具体特征上——比如“判定为外圈故障主要依据是包络谱在154Hz处的峰值幅值异常”。这种解释对现场工程师来说比任何高深的注意力热力图都管用。这个方案的优点在于工程改动小不用推翻现有数据管道也不用设计复杂的损失函数。它的问题也很明显特征工程的边界由人的机理知识决定如果机理模型本身就不完备特征表达会有盲区。但作为融合思想的起点它性价比极高。3.2 路线二物理信息损失函数约束模型学习更进一步的做法是让物理规律参与神经网络的训练过程而不是仅仅在输入端做特征拼接。物理信息神经网络PINN是这两年比较热的方向核心思想是在损失函数里加入物理残差项让模型输出不仅拟合数据标签还要满足物理方程的约束。在故障诊断场景里这种思路可以这样落地模型输出的健康状态概率不能违背已知的物理规律。比如根据转子动力学方程特定转速下系统在某些频率范围内不可能出现共振峰如果模型在这种情况下仍然把高幅值判为轴承故障物理残差项就会惩罚这种输出让模型的学习目标在“拟合数据”和“符合物理”之间找平衡。我们在做齿轮箱复合故障诊断时用过这个思想。齿轮箱的啮合频率由齿数决定如果模型判定的故障特征频率与啮合频率及其谐波的物理关系矛盾就会在损失函数里增加额外惩罚。实验下来模型的误报率确实下降了尤其是在复杂工况下那些纯数据模型容易犯的“荒谬结论”——比如判定某频带存在故障但该频带在物理上根本不可能被激励——明显减少。这个路线的技术门槛比路线一高需要团队里既懂深度学习的loss设计又懂设备物理机理的人配合。但它的收益也大模型学到的表征天然具备物理合理性解释性不是在输出端“事后补救”而是内化在训练过程里。3.3 路线三残差学习与混合架构第三条路是结构层面的融合用简单可解释的机理模型做主体预测再用数据模型学习机理模型预测值与真实值之间的残差。这个思路在生态学、气象学里已经用得很成熟工业故障诊断反而用得不多。具体做法是先用机理模型计算理论故障指标比如轴承故障特征频率对应的理论幅值包络然后用数据模型拟合“理论值”和“实测值”之间的差异。因为残差本身通常是非线性映射数据模型不需要从头学全部规律只需要学“机理模型没考虑到的部分”所以模型规模可以做得小很多训练数据需求量也小不少解释起来也更轻松——模型输出可以拆成“物理预测的主体部分加数据校正的偏差部分”。我们做过一个有趣的小实验用这个架构做电机匝间短路诊断。纯机理模型用电流负序分量做判断常规工况下效果还行但变频供电时频谱复杂化机理模型性能骤降纯数据模型用原始电流波形做输入效果稳定但不可解释。改成残差架构后机理模型的负序分量阈值作为基础判断CNN负责学习电流波形中的非线性残差信息。最终准确率接近纯数据模型而诊断报告仍然能清晰地拆解出“哪部分结论来自物理依据哪部分来自数据模型修正”。对客户来说这种“有据可查的修正”远比一个孤立概率值可信。4. 实操代码路径三分钟看懂一个可解释故障诊断的最小实现光讲思路容易让人觉得虚我直接给一版可以跑通的最小代码框架。以轴承故障诊断中最经典的开路数据集为例我们混合使用物理特征和轻量级数据模型实现“能解释的诊断结论”。4.1 信号层面先算物理特征轴承故障特征频率的计算公式是机理知识的基础部分。以SKF 6205轴承为例节径39.04mm滚动体直径7.94mm滚动体数9接触角0度在转速1750rpm下外圈故障频率约为理论计算值。我习惯先用这个公式生成理论频率参考再做包络谱峰值搜索。import numpy as np from scipy.signal import hilbert, find_peaks def bearing_characteristic_frequencies(fr, n_balls, d_ball, pitch_dia, contact_angle0): 计算滚动轴承四类故障的特征频率 fr: 转频(Hz) n_balls: 滚动体数量 d_ball: 滚动体直径(mm) pitch_dia: 节圆直径(mm) contact_angle: 接触角(rad) cos_angle np.cos(contact_angle) bpfo n_balls / 2 * fr * (1 - d_ball * cos_angle / pitch_dia) # 外圈 bpfi n_balls / 2 * fr * (1 d_ball * cos_angle / pitch_dia) # 内圈 bsf pitch_dia / (2 * d_ball) * fr * (1 - (d_ball * cos_angle / pitch_dia) ** 2) # 滚动体 ftf fr / 2 * (1 - d_ball * cos_angle / pitch_dia) # 保持架 return {BPFO: bpfo, BPFI: bpfi, BSF: bsf, FTF: ftf} # 以SKF 6205为例 freqs bearing_characteristic_frequencies(fr1750/60, n_balls9, d_ball7.94, pitch_dia39.04) print(freqs)这段代码的输出就是后续解释的“坐标系”。诊断结论不会说“模型认为有内圈故障”而是说“包络谱中发现BPFI频率处有明显峰值”后者在物理上是站得住的。4.2 包络谱峰值搜索与证据提取得到理论特征频率后对振动信号做包络分析找特征频率附近的实际峰值幅值。如果峰值显著超过基准阈值就作为“故障证据”记录下来。def envelope_spectrum(signal, fs, freq_rangeNone): 计算信号的包络谱用于共振解调分析 analytic_signal hilbert(signal) envelope np.abs(analytic_signal) spectrum np.fft.rfft(envelope) freqs_out np.fft.rfftfreq(len(signal), 1/fs) magnitude np.abs(spectrum) # 去除直流分量 magnitude[0] 0 return freqs_out, magnitude def extract_fault_evidence(freqs_out, magnitude, theoretical_freqs, fs, tolerance0.03): 提取特征频率附近的峰值作为诊断证据 evidence {} for fault_type, tf in theoretical_freqs.items(): low tf * (1 - tolerance) high tf * (1 tolerance) mask (freqs_out low) (freqs_out high) band_peaks, _ find_peaks(magnitude * mask, height0) if len(band_peaks) 0: max_peak_idx band_peaks[np.argmax(magnitude[band_peaks])] evidence[fault_type] { theoretical_freq: tf, measured_freq: freqs_out[max_peak_idx], amplitude: magnitude[max_peak_idx] } return evidence这一步输出的evidence字典天然就是诊断报告的核心素材。注意这里的3%容差不是拍脑袋定的它考虑了实际工况下转速波动和轴承打滑带来的频率偏移。转速波动大时容差需要放宽到5%左右精密恒转速场景可以收紧到1%~2%。这个值我建议在生产系统中做成可配置参数。4.3 轻量级模型的“最后一跳”物理特征找到了但不宜直接拍板。因为实际信号里特征频率峰值有时会被调制边带干扰峰值高不等于一定故障。我们的做法是把物理特征特征频率处的幅值、边带能量、信噪比等和少量时域统计量组合成特征向量送入一个轻量级分类器做最终判定。代码上用梯度提升树举例换成MLP也完全可以。from sklearn.ensemble import GradientBoostingClassifier def build_feature_vector(evidence, time_domain_features): 组装物理特征 时域特征 vec [] for fault_type in [BPFO, BPFI, BSF, FTF]: if fault_type in evidence: vec.extend([ evidence[fault_type][amplitude], evidence[fault_type][measured_freq], ]) else: vec.extend([0.0, 0.0]) vec.extend(time_domain_features) # 峭度、均方根、峰值因子等 return np.array(vec) # 训练模型时特征向量和标签一一对应 model GradientBoostingClassifier(n_estimators100, max_depth3) model.fit(X_train_vec, y_train) # 预测时可以同时输出证据 x_test_vec build_feature_vector(evidence, time_domain_features) pred model.predict([x_test_vec])如果模型输出是故障直接可以把evidence输出为json格式的报告。这个格式在现场可以直接对接工单系统{ diagnosis: bearing_outer_race_fault, confidence: 0.95, evidence: [ { fault_type: BPFO, theoretical_freq: 105.3, measured_freq: 106.1, amplitude: 0.82, interpretation: 包络谱在理论外圈故障频率附近出现明显峰值为外圈故障最典型特征 } ], suggestion: 建议利用本次停机窗口优先检查电机驱动端轴承外圈并准备备用轴承 }这一整套流程跑下来诊断结论的每个环节都有记录理论频率怎么来的实测峰值在哪个位置幅度多少为什么判定为故障。这就是“可解释性”的工程落地。黑箱模型给一个孤立概率值这套方案给一条完整证据链在现场前者是“玄学”后者是“工作依据”。5. 落地过程中最常踩的六个坑每一条我都付过学费5.1 物理特征算得准但现场转速不稳怎么办教科书里故障特征频率公式默认转速恒定但产线上变频器和负载波动会让转频实时变化。我们刚开始做时直接按额定转速算特征频率结果包络谱峰值跟理论值偏了4%被容差吃掉漏报了一次。后来改成用转速计或从振动信号的转频分量实时估计转频再动态计算故障特征频率。基本思路先找时域信号里的转频再算特征频率。容差范围也做了自适应调整。这是融合方案落地时最容易忽略的细节但恰恰是它决定了现场可靠性。5.2 数据增强把故障特征“增强”没了做数据驱动模型时很多人习惯用加噪声、时间拉伸做数据增强。但在混合特征方案里物理特征对时间拉伸极其敏感——你把时域信号拉长10%转频变了特征频率全偏移原本正常的样本可能被“增强”成故障样本。解决方法是在特征空间做增强而不是信号空间。比如对特征向量的幅值部分做微小扰动对频率值做与转速波动量一致的小幅扰动。机理公式在这里成了增强合理性的天然约束——超出物理规律的扰动直接丢弃。5.3 可解释性不等于事后加一层SHAP这也是行业内比较大的认知误区。很多团队先把黑箱模型训练完然后发现没法解释赶紧补一层SHAP或LIME凑报告。不是说SHAP完全没用——它可以作为辅助分析工具用来发现模型是否学到了不该学的虚假相关。但SHAP解释的是“模型凭什么这么判”而不是“设备为什么故障”。前者是在描述模型行为后者需要物理证据支撑。项目验收时客户问的是后者你拿前者搪塞大概率被扣款。我们现在的检验标准很简单诊断报告能不能不依赖模型单凭证据部分就让一个没接触过AI的设备工程师做出基本判断。用这个标准衡量大部分SHAP输出都不合格。5.4 特征多了反而害事混合特征方案有个诱惑把能想到的物理特征全部堆进去有用的没用的都加。我们曾经堆到52个特征模型准确率不升反降还牺牲了解释性——一个判定结果后面跟着30多条证据信息维修人员根本看不过来。后来狠心做了减法保留19个关键特征准确率回升诊断报告也清爽得多。特征选择不能只看重要性分数还要考虑现场人员的信息消化能力。一个诊断结论有3-5个核心证据就够了超过这个数人脑处理不过来解释性就打了折扣。5.5 数据泄漏比想象中更隐蔽前面提到过采集时间批次导致的泄漏这是最典型的案例。还有一种更隐蔽的情况健康和故障样本来自不同工况的不同传感器安装点位模型学到的“故障特征”其实是安装点位差异。排查手段主要靠可视化分析——把样本在特征空间的分布按批次、点位、工况着色如果同一类样本内部颜色分块明显大概率存在构造性泄漏。这个动作建议写进数据验证流程每次做样本集都要跑一遍。5.6 物理一致性与数据准确性冲突时的取舍策略融合方案里最头疼的问题机理模型说A数据模型说B听谁的我们经验是分情况处理。早期微弱故障阶段故障特征尚未发展到机理模型可辨识的程度数据模型往往更敏感建议偏向数据结论但要标注“置信度中等建议加装监测或缩短巡检周期”。故障特征明显后机理结论基本可靠这时如果数据模型给出相反结论优先查数据模型是否学到了虚假相关。这个取舍逻辑写成规则放在预警系统里比人工判断更稳定。简单说置信度低时看数据置信度高时信机理中间地带人为介入。6. 三个高价值扩展方向让这套方法往深走如果前面的基础方案已经跑通下面几个方向值得深入研究第一个是物理约束生成对抗网络用生成器合成与物理规律一致的故障样本解决故障数据稀缺问题。核心逻辑是让生成器的输出通过物理判别器的审核那些违反机理规律的生成样本直接在训练阶段被淘汰。这个方向在数据极度不平衡的工业场景很有前景。第二个是因果推断在故障诊断里的应用。现有的很多“可解释性”还停留在相关关系层面但维修决策真正需要的是因果链条。比如发现包络谱峰值和轴承故障相关到底是故障导致峰值还是工况变化导致峰值这需要因果推断工具介入。这个方向学术上还比较前沿但已经在某些企业的PHM系统里试点。第三个是故障诊断大语言模型应用用LLM做诊断报告的自动生成和解释交互。不是让大模型直接判断故障——这个不可靠——而是让它把证据链翻译成维修人员能看懂的自然语言回答“为什么这个幅值意味着故障”这类追问。我们测试下来大模型只要不参与数值判断只做结构化报告到自然语言的转换效果是相当可用的。我个人的体会是这几个方向和融合诊断是天然互补的诊断模型负责说对结论物理规律负责守住底线语言模型负责把结论讲清楚。一条完整链条配合起来可解释性问题才算真正闭环。7. 轴承故障诊断的物理特征组合速查参考故障类型核心物理特征时域敏感指标典型频段特征外圈故障BPFO及谐波峭度升高、峰值因子增大高频共振解调后可见BPFO峰值内圈故障BPFI及边带波形存在周期性冲击边频带以转频为间隔滚动体故障BSF及谐波冲击周期不规则故障特征包含保持架频率调制保持架故障FTF信号整体波动低频段出现FTF成分复合故障多特征并存波形复杂化多个特征频率同时出现这组速查表我建议贴在工位旁边不管用什么模型最终诊断报告的核心内容都应该能对应上表某一行的特征。如果模型输出结论在这张表里找不到依据那不管准确率多高这个结论都值得怀疑。8. 一点个人体会做故障诊断多年我越来越觉得这个领域的核心竞争力不在于会跑多复杂的模型而在于能不能把勤奋的物理知识和强悍的数据模型协调在一个框架里。跨过机理与数据的鸿沟技术上的本质工作是想办法让两边互相作证——物理规律给数据模型设置边界数据模型反过来弥补物理规律无法覆盖的盲区。目前这套思路在工程上已经能落地但离“完美”还有相当距离。复合故障解耦、变工况自适应、小样本置信度估计这些问题都还值得继续啃。尤其是不同行业、不同设备类型的故障机理差异巨大目前很难找到一套通吃的融合框架大部分工作仍然需要针对具体的设备和故障模式做定制化开发。我个人的习惯是接到一个新故障诊断项目的需求先花至少三分之一的时间搞懂机理把能算的特征频率都算一遍用机理模型先跑一版基础诊断结果再考虑数据模型怎么补短板。顺序反了后面八成要返工。这个习惯建议刚开始做这个方向的朋友也试试。 
长河君 · 2026/10/26 21:59:08 · 阅读 1.2k 故障诊断可解释性落地：机理与数据融合的三种路线与工程实践
1. 从“选模型”到“信模型”的转变为什么故障诊断突然开始谈可解释性这两年做工业故障诊断的人大概都有一种共同的焦虑模型越来越准但胆子越来越小。卷积神经网络的准确率能轻松做到98%以上Transformer变体换着花样刷新指标但当你真的把模型部署到产线上设备主管问一句“它凭什么说这台泵的轴承坏了”你多半会愣住。因为深度学习模型给不出理由它只会给你一个概率值然后剩下的是黑箱。更麻烦的是黑箱模型一旦误报代价不只是停机还有整个班组对这套系统的信任崩塌——一次说不清原因的误报警比十次正确的报警更摧毁落地项目的生命力。这就是“可解释性”被反复提及的根本原因。它不是学术圈自嗨的新鲜词而是工业落地场景里绕不开的硬需求。故障诊断行业正在经历一个从“选一个准的模型”到“信一个能解释的模型”的阶段转换尤其是进入PHM故障预测与健康管理体系化建设之后准确率和可解释性已经不是二选一的取舍问题而是必须同时交付的两个指标。这个问题本质上是两类技术范式长期割裂的后果机理驱动方法有天然的物理逻辑但面对复杂工况常常建不出足够精确的模型数据驱动方法几乎不依赖物理假设能逼近任意非线性关系但代价是决策过程难以被人理解。跨过这条鸿沟就是现阶段故障诊断领域最值得投入的方向。我们团队过去三年落地过几个诊断项目从旋转机械的轴承故障到齿轮箱点蚀从泵组的空化到电机的匝间短路走了一圈之后我最大的体会是单纯堆准确率是最好做的事真正考验功力的地方是如何让模型在给出结论的同时给出让人信服的证据链。这篇文章就把我个人在这条路上摸索出的思路、方法、代码层面的落地方案以及踩过的坑完整做个梳理。2. 两种范式的“龟兔赛跑”机理模型的严谨与数据模型的强悍2.1 机理模型的天然优势与真实局限机理驱动方法说白了就是“先懂设备再判断故障”。工程师根据物理原理建立数学模型用方程去描述设备在健康状态和故障状态下的行为差异。比如滚动轴承的故障特征频率计算就是最典型的机理知识——外圈故障频率、内圈故障频率、滚动体故障频率都能用转速、几何尺寸算出来。理论上只要在频谱里找到这些特征频率及其谐波就能定位故障位置。这套逻辑的优势非常明显每个诊断结论都有物理依据可解释性天然饱满。你说轴承外圈有故障依据是频谱里出现了外圈故障特征频率的峰值这个解释工程师一听就认。在故障机理明确、设备结构相对简单、工况稳定的场景下机理模型非常可靠而且计算开销小这对工业现场大量边缘设备来说是硬指标。但它的局限同样突出。真实工业设备不是教科书里的理想模型转速波动、负载变化、多源耦合振动、传递路径衰减这些因素会让理论计算的特征频率发生偏移甚至淹没在噪声里。更麻烦的是复合故障、早期微弱故障、变工况条件下的故障特征很多时候机理模型根本给不出足够精确的数学描述。我见过不少把机理模型做到极致精细的项目模型复杂到仿真一跑就是几十个小时但真到现场一看测量条件和仿真边界条件差太远精度反而不如简单的频谱幅值对比。2.2 数据模型的强悍拟合与解释困境数据驱动方法是另一方极端。深度学习的理论拟合能力已经被反复验证你给它足够多的故障样本它就能自动从原始振动信号里学习到人类难以手工设计的特征。端到端的诊断模式是输入时域波形或频谱输出故障类别。准确率可以在公开数据集上做到碾压级水平甚至不需要信号处理的专家知识。问题在于模型学到了什么没人知道。CNN在卷积层提取的到底是故障特征频率还是某个环境噪声完全不透明。我们曾经在一次电机故障诊断实验里发现模型准确率高达99%但后来排查才发现数据集里有泄漏——健康样本和故障样本是在不同时间批次采集的模型学到的根本不是故障特征而是采集时间的分布差异。这要是直接上产线必然翻车。这就是数据模型最大的软肋它给出的结论没有可以追溯的物理证据。在学术论文里混淆矩阵和准确率就够了但在工业项目里客户要的是一份能写进维修工单的说明——“根据振动频谱中的哪几个特征判定存在何种故障建议安排什么检修”。数据模型给不出这种说明你总不能写“因为神经网络第37个神经元激活了”吧。2.3 为什么“准确率优先”策略在工业现场常常失效这两套范式各走极端但在真实工业场景里我们需要的其实是一个“中间状态”的解决方案准确率不能比纯数据模型差太多解释性不能比纯机理模型弱太多。这里要说一个很扎心的行业现实准确率在实验室是唯一指标在现场只是门槛指标。产线上的设备管理人员对诊断系统的基本信任来自——每次报警都能说清楚为什么每次不报警都有合理依据。一旦出现“哑巴报警”哪怕整体准确率是99%那1%的误报也会消耗掉大量信任储备。等你真的遇到设备故障而系统没有报警时整个系统就会被贴上“不靠谱”的标签再难翻身。在PHM体系建设里诊断只是中间环节后面还跟着维修决策和备件计划。一个只有结论没有依据的诊断结果没法支撑后续的RCM以可靠性为中心的维修分析。这也是为什么越来越多的行业标准开始明确要求诊断系统具备可解释的证据输出能力。所以说兼顾准确性和可解释性不是洁癖式的学术追求而是决定项目能否长期运转的现实需要。3. 真正的解法不是二选一而是“知识嵌入数据”三条可行的融合路线3.1 路线一物理特征作为先验特征输入最容易上手、最稳妥的融合思路是把机理知识转化为特征输入让数据模型在物理特征的基础上做学习。操作上不直接向模型输入原始振动波形或全频段频谱而是先把机理公式计算出的故障特征频率、边频带间隔、包络谱特征、时域统计指标等构造成特征向量再送入分类器。我们在轴承故障诊断项目里验证过这个思路。经典的CNN方案直接用原始信号做输入准确率确实高但无法解释我们改成混合特征方案后输入端包含FFT频谱主要峰值频率、包络谱特征频率幅值、时域峭度和均方根等19个特征模型用梯度提升树或轻量级MLP做分类。准确率比端到端CNN低大约1.5个百分点但每次诊断结果都能回溯到具体特征上——比如“判定为外圈故障主要依据是包络谱在154Hz处的峰值幅值异常”。这种解释对现场工程师来说比任何高深的注意力热力图都管用。这个方案的优点在于工程改动小不用推翻现有数据管道也不用设计复杂的损失函数。它的问题也很明显特征工程的边界由人的机理知识决定如果机理模型本身就不完备特征表达会有盲区。但作为融合思想的起点它性价比极高。3.2 路线二物理信息损失函数约束模型学习更进一步的做法是让物理规律参与神经网络的训练过程而不是仅仅在输入端做特征拼接。物理信息神经网络PINN是这两年比较热的方向核心思想是在损失函数里加入物理残差项让模型输出不仅拟合数据标签还要满足物理方程的约束。在故障诊断场景里这种思路可以这样落地模型输出的健康状态概率不能违背已知的物理规律。比如根据转子动力学方程特定转速下系统在某些频率范围内不可能出现共振峰如果模型在这种情况下仍然把高幅值判为轴承故障物理残差项就会惩罚这种输出让模型的学习目标在“拟合数据”和“符合物理”之间找平衡。我们在做齿轮箱复合故障诊断时用过这个思想。齿轮箱的啮合频率由齿数决定如果模型判定的故障特征频率与啮合频率及其谐波的物理关系矛盾就会在损失函数里增加额外惩罚。实验下来模型的误报率确实下降了尤其是在复杂工况下那些纯数据模型容易犯的“荒谬结论”——比如判定某频带存在故障但该频带在物理上根本不可能被激励——明显减少。这个路线的技术门槛比路线一高需要团队里既懂深度学习的loss设计又懂设备物理机理的人配合。但它的收益也大模型学到的表征天然具备物理合理性解释性不是在输出端“事后补救”而是内化在训练过程里。3.3 路线三残差学习与混合架构第三条路是结构层面的融合用简单可解释的机理模型做主体预测再用数据模型学习机理模型预测值与真实值之间的残差。这个思路在生态学、气象学里已经用得很成熟工业故障诊断反而用得不多。具体做法是先用机理模型计算理论故障指标比如轴承故障特征频率对应的理论幅值包络然后用数据模型拟合“理论值”和“实测值”之间的差异。因为残差本身通常是非线性映射数据模型不需要从头学全部规律只需要学“机理模型没考虑到的部分”所以模型规模可以做得小很多训练数据需求量也小不少解释起来也更轻松——模型输出可以拆成“物理预测的主体部分加数据校正的偏差部分”。我们做过一个有趣的小实验用这个架构做电机匝间短路诊断。纯机理模型用电流负序分量做判断常规工况下效果还行但变频供电时频谱复杂化机理模型性能骤降纯数据模型用原始电流波形做输入效果稳定但不可解释。改成残差架构后机理模型的负序分量阈值作为基础判断CNN负责学习电流波形中的非线性残差信息。最终准确率接近纯数据模型而诊断报告仍然能清晰地拆解出“哪部分结论来自物理依据哪部分来自数据模型修正”。对客户来说这种“有据可查的修正”远比一个孤立概率值可信。4. 实操代码路径三分钟看懂一个可解释故障诊断的最小实现光讲思路容易让人觉得虚我直接给一版可以跑通的最小代码框架。以轴承故障诊断中最经典的开路数据集为例我们混合使用物理特征和轻量级数据模型实现“能解释的诊断结论”。4.1 信号层面先算物理特征轴承故障特征频率的计算公式是机理知识的基础部分。以SKF 6205轴承为例节径39.04mm滚动体直径7.94mm滚动体数9接触角0度在转速1750rpm下外圈故障频率约为理论计算值。我习惯先用这个公式生成理论频率参考再做包络谱峰值搜索。import numpy as np from scipy.signal import hilbert, find_peaks def bearing_characteristic_frequencies(fr, n_balls, d_ball, pitch_dia, contact_angle0): 计算滚动轴承四类故障的特征频率 fr: 转频(Hz) n_balls: 滚动体数量 d_ball: 滚动体直径(mm) pitch_dia: 节圆直径(mm) contact_angle: 接触角(rad) cos_angle np.cos(contact_angle) bpfo n_balls / 2 * fr * (1 - d_ball * cos_angle / pitch_dia) # 外圈 bpfi n_balls / 2 * fr * (1 d_ball * cos_angle / pitch_dia) # 内圈 bsf pitch_dia / (2 * d_ball) * fr * (1 - (d_ball * cos_angle / pitch_dia) ** 2) # 滚动体 ftf fr / 2 * (1 - d_ball * cos_angle / pitch_dia) # 保持架 return {BPFO: bpfo, BPFI: bpfi, BSF: bsf, FTF: ftf} # 以SKF 6205为例 freqs bearing_characteristic_frequencies(fr1750/60, n_balls9, d_ball7.94, pitch_dia39.04) print(freqs)这段代码的输出就是后续解释的“坐标系”。诊断结论不会说“模型认为有内圈故障”而是说“包络谱中发现BPFI频率处有明显峰值”后者在物理上是站得住的。4.2 包络谱峰值搜索与证据提取得到理论特征频率后对振动信号做包络分析找特征频率附近的实际峰值幅值。如果峰值显著超过基准阈值就作为“故障证据”记录下来。def envelope_spectrum(signal, fs, freq_rangeNone): 计算信号的包络谱用于共振解调分析 analytic_signal hilbert(signal) envelope np.abs(analytic_signal) spectrum np.fft.rfft(envelope) freqs_out np.fft.rfftfreq(len(signal), 1/fs) magnitude np.abs(spectrum) # 去除直流分量 magnitude[0] 0 return freqs_out, magnitude def extract_fault_evidence(freqs_out, magnitude, theoretical_freqs, fs, tolerance0.03): 提取特征频率附近的峰值作为诊断证据 evidence {} for fault_type, tf in theoretical_freqs.items(): low tf * (1 - tolerance) high tf * (1 tolerance) mask (freqs_out low) (freqs_out high) band_peaks, _ find_peaks(magnitude * mask, height0) if len(band_peaks) 0: max_peak_idx band_peaks[np.argmax(magnitude[band_peaks])] evidence[fault_type] { theoretical_freq: tf, measured_freq: freqs_out[max_peak_idx], amplitude: magnitude[max_peak_idx] } return evidence这一步输出的evidence字典天然就是诊断报告的核心素材。注意这里的3%容差不是拍脑袋定的它考虑了实际工况下转速波动和轴承打滑带来的频率偏移。转速波动大时容差需要放宽到5%左右精密恒转速场景可以收紧到1%~2%。这个值我建议在生产系统中做成可配置参数。4.3 轻量级模型的“最后一跳”物理特征找到了但不宜直接拍板。因为实际信号里特征频率峰值有时会被调制边带干扰峰值高不等于一定故障。我们的做法是把物理特征特征频率处的幅值、边带能量、信噪比等和少量时域统计量组合成特征向量送入一个轻量级分类器做最终判定。代码上用梯度提升树举例换成MLP也完全可以。from sklearn.ensemble import GradientBoostingClassifier def build_feature_vector(evidence, time_domain_features): 组装物理特征 时域特征 vec [] for fault_type in [BPFO, BPFI, BSF, FTF]: if fault_type in evidence: vec.extend([ evidence[fault_type][amplitude], evidence[fault_type][measured_freq], ]) else: vec.extend([0.0, 0.0]) vec.extend(time_domain_features) # 峭度、均方根、峰值因子等 return np.array(vec) # 训练模型时特征向量和标签一一对应 model GradientBoostingClassifier(n_estimators100, max_depth3) model.fit(X_train_vec, y_train) # 预测时可以同时输出证据 x_test_vec build_feature_vector(evidence, time_domain_features) pred model.predict([x_test_vec])如果模型输出是故障直接可以把evidence输出为json格式的报告。这个格式在现场可以直接对接工单系统{ diagnosis: bearing_outer_race_fault, confidence: 0.95, evidence: [ { fault_type: BPFO, theoretical_freq: 105.3, measured_freq: 106.1, amplitude: 0.82, interpretation: 包络谱在理论外圈故障频率附近出现明显峰值为外圈故障最典型特征 } ], suggestion: 建议利用本次停机窗口优先检查电机驱动端轴承外圈并准备备用轴承 }这一整套流程跑下来诊断结论的每个环节都有记录理论频率怎么来的实测峰值在哪个位置幅度多少为什么判定为故障。这就是“可解释性”的工程落地。黑箱模型给一个孤立概率值这套方案给一条完整证据链在现场前者是“玄学”后者是“工作依据”。5. 落地过程中最常踩的六个坑每一条我都付过学费5.1 物理特征算得准但现场转速不稳怎么办教科书里故障特征频率公式默认转速恒定但产线上变频器和负载波动会让转频实时变化。我们刚开始做时直接按额定转速算特征频率结果包络谱峰值跟理论值偏了4%被容差吃掉漏报了一次。后来改成用转速计或从振动信号的转频分量实时估计转频再动态计算故障特征频率。基本思路先找时域信号里的转频再算特征频率。容差范围也做了自适应调整。这是融合方案落地时最容易忽略的细节但恰恰是它决定了现场可靠性。5.2 数据增强把故障特征“增强”没了做数据驱动模型时很多人习惯用加噪声、时间拉伸做数据增强。但在混合特征方案里物理特征对时间拉伸极其敏感——你把时域信号拉长10%转频变了特征频率全偏移原本正常的样本可能被“增强”成故障样本。解决方法是在特征空间做增强而不是信号空间。比如对特征向量的幅值部分做微小扰动对频率值做与转速波动量一致的小幅扰动。机理公式在这里成了增强合理性的天然约束——超出物理规律的扰动直接丢弃。5.3 可解释性不等于事后加一层SHAP这也是行业内比较大的认知误区。很多团队先把黑箱模型训练完然后发现没法解释赶紧补一层SHAP或LIME凑报告。不是说SHAP完全没用——它可以作为辅助分析工具用来发现模型是否学到了不该学的虚假相关。但SHAP解释的是“模型凭什么这么判”而不是“设备为什么故障”。前者是在描述模型行为后者需要物理证据支撑。项目验收时客户问的是后者你拿前者搪塞大概率被扣款。我们现在的检验标准很简单诊断报告能不能不依赖模型单凭证据部分就让一个没接触过AI的设备工程师做出基本判断。用这个标准衡量大部分SHAP输出都不合格。5.4 特征多了反而害事混合特征方案有个诱惑把能想到的物理特征全部堆进去有用的没用的都加。我们曾经堆到52个特征模型准确率不升反降还牺牲了解释性——一个判定结果后面跟着30多条证据信息维修人员根本看不过来。后来狠心做了减法保留19个关键特征准确率回升诊断报告也清爽得多。特征选择不能只看重要性分数还要考虑现场人员的信息消化能力。一个诊断结论有3-5个核心证据就够了超过这个数人脑处理不过来解释性就打了折扣。5.5 数据泄漏比想象中更隐蔽前面提到过采集时间批次导致的泄漏这是最典型的案例。还有一种更隐蔽的情况健康和故障样本来自不同工况的不同传感器安装点位模型学到的“故障特征”其实是安装点位差异。排查手段主要靠可视化分析——把样本在特征空间的分布按批次、点位、工况着色如果同一类样本内部颜色分块明显大概率存在构造性泄漏。这个动作建议写进数据验证流程每次做样本集都要跑一遍。5.6 物理一致性与数据准确性冲突时的取舍策略融合方案里最头疼的问题机理模型说A数据模型说B听谁的我们经验是分情况处理。早期微弱故障阶段故障特征尚未发展到机理模型可辨识的程度数据模型往往更敏感建议偏向数据结论但要标注“置信度中等建议加装监测或缩短巡检周期”。故障特征明显后机理结论基本可靠这时如果数据模型给出相反结论优先查数据模型是否学到了虚假相关。这个取舍逻辑写成规则放在预警系统里比人工判断更稳定。简单说置信度低时看数据置信度高时信机理中间地带人为介入。6. 三个高价值扩展方向让这套方法往深走如果前面的基础方案已经跑通下面几个方向值得深入研究第一个是物理约束生成对抗网络用生成器合成与物理规律一致的故障样本解决故障数据稀缺问题。核心逻辑是让生成器的输出通过物理判别器的审核那些违反机理规律的生成样本直接在训练阶段被淘汰。这个方向在数据极度不平衡的工业场景很有前景。第二个是因果推断在故障诊断里的应用。现有的很多“可解释性”还停留在相关关系层面但维修决策真正需要的是因果链条。比如发现包络谱峰值和轴承故障相关到底是故障导致峰值还是工况变化导致峰值这需要因果推断工具介入。这个方向学术上还比较前沿但已经在某些企业的PHM系统里试点。第三个是故障诊断大语言模型应用用LLM做诊断报告的自动生成和解释交互。不是让大模型直接判断故障——这个不可靠——而是让它把证据链翻译成维修人员能看懂的自然语言回答“为什么这个幅值意味着故障”这类追问。我们测试下来大模型只要不参与数值判断只做结构化报告到自然语言的转换效果是相当可用的。我个人的体会是这几个方向和融合诊断是天然互补的诊断模型负责说对结论物理规律负责守住底线语言模型负责把结论讲清楚。一条完整链条配合起来可解释性问题才算真正闭环。7. 轴承故障诊断的物理特征组合速查参考故障类型核心物理特征时域敏感指标典型频段特征外圈故障BPFO及谐波峭度升高、峰值因子增大高频共振解调后可见BPFO峰值内圈故障BPFI及边带波形存在周期性冲击边频带以转频为间隔滚动体故障BSF及谐波冲击周期不规则故障特征包含保持架频率调制保持架故障FTF信号整体波动低频段出现FTF成分复合故障多特征并存波形复杂化多个特征频率同时出现这组速查表我建议贴在工位旁边不管用什么模型最终诊断报告的核心内容都应该能对应上表某一行的特征。如果模型输出结论在这张表里找不到依据那不管准确率多高这个结论都值得怀疑。8. 一点个人体会做故障诊断多年我越来越觉得这个领域的核心竞争力不在于会跑多复杂的模型而在于能不能把勤奋的物理知识和强悍的数据模型协调在一个框架里。跨过机理与数据的鸿沟技术上的本质工作是想办法让两边互相作证——物理规律给数据模型设置边界数据模型反过来弥补物理规律无法覆盖的盲区。目前这套思路在工程上已经能落地但离“完美”还有相当距离。复合故障解耦、变工况自适应、小样本置信度估计这些问题都还值得继续啃。尤其是不同行业、不同设备类型的故障机理差异巨大目前很难找到一套通吃的融合框架大部分工作仍然需要针对具体的设备和故障模式做定制化开发。我个人的习惯是接到一个新故障诊断项目的需求先花至少三分之一的时间搞懂机理把能算的特征频率都算一遍用机理模型先跑一版基础诊断结果再考虑数据模型怎么补短板。顺序反了后面八成要返工。这个习惯建议刚开始做这个方向的朋友也试试。