工业故障诊断框架：样本不平衡、物理约束与边缘实时部署实践

1. 工业故障诊断的真实困境与框架设计初衷

1.1 为什么工业场景下的故障诊断这么难做

干过工业设备监测的人都有一个共同感受：实验室里跑得通的方法，到了产线上往往活不过三天。原因不复杂，工业现场的数据分布和学术数据集完全是两回事。学术数据集里各类故障样本数量均衡、标注干净、工况稳定，而真实产线上，正常运行的样本占了绝大多数，故障样本稀少且类型极不均衡——某种轴承内圈故障可能半年才出现一次，而外圈故障一年也就攒下几十条记录。这种样本极度不平衡是工业故障诊断绕不开的第一道坎。

第二道坎是物理约束。工业设备不是随便转的，转速、负载、温度、振动响应之间存在明确的物理规律。纯数据驱动的方法如果无视这些规律，很容易学出一些在统计上成立、在物理上荒谬的映射关系。比如把某个频段的能量突增直接判为故障，但实际上那可能只是负载切换引起的正常瞬态。模型在测试集上准确率很高，一上产线就频繁误报，根子就在这里。

第三道坎是实时部署。很多论文里的模型参数量动辄几百万，推理一次要几百毫秒甚至更久，而工业现场对诊断延迟的要求往往是毫秒级。你不可能在PLC旁边挂一张高端显卡，边缘设备的算力、内存、功耗都是硬约束。所以一个真正能落地的框架，必须同时解决样本不平衡、物理一致性、实时性这三个问题，缺一不可。

1.2 这个框架到底想解决什么问题

我理解的这个框架，核心目标就一句话：在样本严重不平衡的条件下，训练出一个既尊重物理规律、又能在边缘设备上实时运行的故障诊断模型。它要处理的是从数据预处理、模型训练、物理约束注入，到模型压缩、部署推理的完整链路，而不是单点地刷一个准确率指标。

适合参考这个框架的人，我大致分三类。第一类是做工业设备预测性维护的算法工程师，手里有真实的振动、电流、温度信号，但被样本不平衡和误报率折磨得够呛。第二类是做边缘计算部署的开发者，模型训好了却塞不进目标硬件，或者推理延迟压不下来。第三类是做相关方向研究的人，想把物理信息神经网络（PINN）那一套思路用到工业诊断上，但不确定工程上怎么落地。这三类人关注的点不同，但都能从这个框架的分层设计里找到自己需要的那部分。

1.3 整体架构的分层思路

这个框架我倾向于把它拆成四层来看，这样每一层的职责清晰，替换和调试也方便。

第一层是数据层，负责信号采集、清洗、增强和不平衡处理。第二层是物理约束层，把设备运行的物理方程、频域特征、工况先验编码成约束项，注入到模型训练里。第三层是模型层，主干网络负责特征提取和分类，同时接受物理约束的正则。第四层是部署层，做量化、剪枝、算子融合，最后落到边缘推理引擎上。

这么分层的好处是，每一层的问题可以独立定位。比如误报率高，可能是数据层的不平衡处理没做好，也可能是物理约束权重设得不对，分层之后排查就有方向了。下面我逐层展开，把每一层的关键细节和踩坑经验讲透。

2. 数据层：不平衡样本的处理与信号预处理

2.1 工业信号的清洗与分段

拿到原始信号的第一步不是急着喂给模型，而是清洗和分段。工业现场采集的振动信号里，工频干扰、传感器松动造成的冲击、电磁噪声都很常见。我一般会先做带通滤波，把关注频段之外的成分滤掉，比如轴承故障特征频率通常集中在几千赫兹以内，那高频噪声就可以先砍掉。

分段这一步很多人做得粗糙。常见做法是固定窗口切分，比如每1024个点一段。但工业信号的故障冲击往往有周期性，固定窗口可能把一次完整的冲击事件切成两半，导致每段都学不到完整特征。我的经验是用转速信号做同步分段，让每段窗口覆盖整数个旋转周期，这样故障冲击的相位信息才不会被破坏。如果拿不到转速信号，退而求其次可以用自相关分析估计主周期，再按周期对齐切分。

注意：分段窗口长度不要拍脑袋定。窗口太短，低频故障特征（比如转频相关的调制成分）提取不出来；窗口太长，样本数量骤减，本来就不平衡的数据会更雪上加霜。我通常从覆盖3到5个旋转周期开始试。

2.2 样本不平衡的三种应对策略对比

样本不平衡是这一层的核心矛盾。我试过的方法大致归为三类，各有适用场景，下面用表格对比一下。

我的实际选择是组合拳：先用类别权重把损失函数调平，再用条件生成模型对极稀缺的故障类型做定向增强，最后用欠采样控制正常样本的比例。单纯靠一种方法，在工业场景下很难稳住。

这里重点说下生成增强的坑。用生成对抗网络生成故障样本，最大的风险是生成出来的信号在物理上不成立。比如生成了一段轴承故障冲击，但冲击的重复频率和转速对不上，这种样本喂给模型，等于教模型学假知识。所以生成器的输出必须过一遍物理校验，这个后面在物理约束层会详细讲。

2.3 数据增强中的物理一致性校验

数据增强不是随便加噪声、做时移就完事。工业信号有明确的物理结构，增强操作必须保持这些结构不被破坏。

时移增强要注意不能破坏故障冲击的周期性。如果你把一段信号随机平移，可能导致冲击间隔变得不规律，模型学到的周期特征就乱了。我的做法是按时移整数个旋转周期，这样周期性保持不变。

加噪增强要注意信噪比不能低于现场实际水平。实验室里为了提升鲁棒性，有时候会把噪声加得很大，但现场信号的信噪比是有下限的，加过头会让模型对噪声过度敏感，反而降低实际表现。我一般把增强后的信噪比控制在比现场实测最低信噪比再低3到5个分贝，留一点余量就行。

幅值缩放增强要小心不能破坏幅值与故障严重程度的对应关系。故障越严重，冲击幅值通常越大，如果你随机缩放幅值，可能把轻微故障放大成严重故障的样子，标签就错了。所以幅值缩放要么不用，要么只在很小的范围内做。

3. 物理约束层：把领域知识注入模型

3.1 物理约束的三种注入方式

物理约束怎么加到模型里，这是整个框架最有技术含量的部分。我总结下来有三种注入方式，复杂度递增，效果也递增。

第一种是数据级约束，就是在数据预处理阶段，把物理规律变成特征工程的一部分。比如根据转速计算轴承故障特征频率，然后提取这些频率处的能量作为额外输入特征。这种方式最简单，不改变模型结构，但物理信息只停留在输入层，模型内部还是黑箱。

第二种是损失级约束，在损失函数里加物理正则项。比如要求模型预测的故障严重程度和振动能量单调相关，或者要求模型对转速变化的响应符合物理规律。这种方式能让物理约束影响整个训练过程，但正则项的权重需要仔细调。

第三种是结构级约束，把物理方程直接嵌入网络结构。比如在网络的某一层用物理方程替换掉普通的全连接层，让前向传播本身就满足物理规律。这种方式最彻底，但实现难度最大，而且物理方程必须足够准确。

我的建议是从数据级约束起步，逐步过渡到损失级约束，结构级约束除非物理模型非常成熟，否则不要轻易上。因为物理方程本身有近似误差，硬嵌到结构里，一旦方程不准，模型连拟合数据的能力都会受影响。

3.2 损失函数中的物理正则项设计

损失级约束是性价比最高的方案，重点说下正则项怎么设计。一个典型的复合损失函数长这样：

def composite_loss(y_pred, y_true, physics_features, model_outputs): # 分类损失，用焦点损失处理不平衡 cls_loss = focal_loss(y_pred, y_true, gamma=2.0, alpha=class_weights) # 物理正则一：单调性约束 # 故障严重程度预测值应与振动能量单调正相关 severity_pred = model_outputs['severity'] energy = physics_features['vibration_energy'] mono_loss = monotonicity_penalty(severity_pred, energy) # 物理正则二：频域一致性约束 # 模型关注的频段应与故障特征频率吻合 attention_map = model_outputs['attention'] fault_freqs = physics_features['fault_frequencies'] freq_loss = frequency_consistency(attention_map, fault_freqs) total = cls_loss + lambda1 * mono_loss + lambda2 * freq_loss return total

这里的lambda1和lambda2是两个关键超参。我的经验是物理正则的权重不能太大，否则模型会为了满足物理约束而牺牲分类精度。一般从0.01开始试，逐步加到0.1，观察验证集上的表现。如果分类精度开始明显下降，说明物理约束压得太狠了。

单调性约束的实现也有讲究。不能简单地要求严格单调，因为实际信号有噪声，严格单调会导致模型对噪声过度敏感。我一般用软单调，允许小幅波动，只惩罚大的违反。频域一致性约束则要注意故障特征频率的计算精度，转速估计有误差的话，特征频率也会偏，约束就失准了。

3.3 物理约束的边界与失效场景

物理约束不是万能的，有些场景下强行加约束反而有害。我踩过的坑里，最典型的是变工况场景。设备在不同转速、不同负载下，物理规律的形式可能不一样。如果你用单一工况下的物理方程去约束所有工况，模型在变工况下会表现很差。

还有一种情况是复合故障。单个故障的物理规律相对清晰，但多个故障同时发生时，物理响应会耦合，简单的线性叠加假设往往不成立。这时候物理约束的准确性下降，权重就应该调低，让数据本身说话。

我的处理原则是：物理约束的可信度有多高，权重就设多大。如果物理模型经过充分验证，在目标工况下误差很小，那权重可以设大一些；如果物理模型只是粗略近似，权重就要保守。这个判断没有公式，靠的是对设备和物理过程的深入理解。

4. 模型层：主干网络与训练策略

4.1 主干网络的选型考量

主干网络的选择要同时考虑精度和部署成本。我试过几类网络，说说各自的适用性。

一维卷积网络是最常用的，直接处理原始振动信号，参数量小，推理快，适合边缘部署。但它的感受野有限，对长程依赖的建模能力弱，如果故障特征需要跨越较长时间才能体现，一维卷积就吃力。

循环神经网络能建模时序依赖，但推理是串行的，延迟高，不适合实时性要求高的场景。而且循环网络在边缘设备上的算子支持往往不好，部署麻烦。

Transformer 这两年很火，建模能力强，但参数量和计算量都大，原始版本很难塞进边缘设备。如果要用，必须做大幅度的剪枝和量化，或者用轻量化的变体。

我的实际选择是以一维卷积为主干，在关键层引入轻量注意力机制。这样既有卷积的效率和局部特征提取能力，又能通过注意力捕捉重要的长程依赖。注意力模块要设计得足够轻，比如用通道注意力而不是空间注意力，计算开销小很多。

4.2 多任务学习框架的搭建

单一的分类任务往往不够，工业诊断还需要输出故障严重程度、故障位置等信息。多任务学习能让模型共享特征，提升泛化能力，但任务之间的平衡是个难点。

我一般把任务分成主任务和辅助任务。主任务是故障分类，辅助任务包括严重程度回归、故障位置定位等。损失函数里主任务的权重最大，辅助任务权重小一些，起到正则化的作用。辅助任务的选择要和主任务相关，如果选了一个不相关的任务，反而会干扰主任务的学习。

多任务学习还有一个好处是缓解样本不平衡。分类任务里稀缺的故障类型，在严重程度回归任务里可能有更多样本（因为严重程度是连续值，每个样本都有），辅助任务能帮主任务学到更鲁棒的特征表示。

4.3 训练策略与超参调优经验

训练策略上，我踩过的坑主要集中在学习率调度和早停策略上。

学习率方面，工业信号的数据分布往往比较复杂，一开始用大学习率容易震荡，我一般用预热加余弦退火。前几个epoch用很小的学习率预热，让模型先稳定下来，然后再逐步升到主学习率，最后余弦退火到接近零。这样训练曲线平滑，最终精度也更好。

早停策略不能只看验证集准确率，因为不平衡数据下准确率会被多数类主导。我一般同时监控少数类的召回率和整体F1分数，两个指标都开始下降才早停。如果只看准确率，模型可能早就过拟合了，但准确率还在涨，因为它在拼命拟合正常样本。

批量大小的选择也有讲究。批量太大，少数类样本在一个批次里可能一个都没有，梯度更新会偏向多数类。我一般用中等批量加分层采样，保证每个批次里各类样本都有一定比例。分层采样虽然改变了数据分布，但配合类别权重，整体效果是正向的。

5. 部署层：从模型到边缘设备的落地

5.1 模型压缩的实操路径

模型压缩我一般按剪枝、量化、算子融合的顺序来。顺序很重要，先剪枝再量化，因为剪枝后的模型结构更稀疏，量化时更容易保持精度。

剪枝分结构化和非结构化。非结构化剪枝把不重要的权重置零，压缩率高但需要专门的稀疏计算库支持，边缘设备往往不支持。结构化剪枝直接砍掉整个通道或层，压缩率低一些但部署友好。我一般用结构化剪枝，按通道的L2范数排序，砍掉最小的那部分，然后微调恢复精度。

量化是把浮点权重转成低比特整数。8比特量化最成熟，精度损失小，大部分边缘推理引擎都支持。4比特量化压缩率更高，但精度损失明显，需要量化感知训练来补偿。我的经验是优先用8比特，如果模型还是太大再考虑4比特，不要一上来就追求极致压缩。

5.2 边缘推理引擎的选型与适配

推理引擎的选择取决于目标硬件。常见的几类引擎各有特点，我列个表对比。

我的实际做法是先用ONNX做中间格式，再根据目标硬件转成专用引擎。ONNX的好处是通用，训练框架导出的模型先转ONNX，验证推理结果一致后，再转TensorRT或OpenVINO做性能优化。这样既保证了灵活性，又能拿到专用引擎的性能。

适配过程中最常见的坑是算子不支持。训练时用的某些算子，推理引擎可能没有实现，或者实现方式和训练框架不一致，导致精度对不上。我的排查方法是逐层对比输出，把训练框架和推理引擎的每一层输出都拿出来比，找到第一个对不上的层，然后针对性地替换或重写。

5.3 实时性保障与延迟优化

实时性不只是模型推理快就行，整个链路包括数据采集、预处理、推理、后处理都要算进去。我一般把延迟预算拆开，比如总预算10毫秒，数据采集占2毫秒，预处理占2毫秒，推理占4毫秒，后处理占2毫秒。哪一部分超了，就针对性地优化。

推理延迟的优化手段主要有几个。批处理能提升吞吐，但会增加单样本延迟，实时场景下批量一般设为1。算子融合把多个小算子合并成一个大算子，减少调度开销，这个在推理引擎里通常是自动做的。内存复用避免频繁分配释放内存，对延迟稳定性很重要。

还有一个容易被忽略的点是数据预处理的延迟。滤波、分段、特征提取这些操作如果实现得低效，可能比推理本身还慢。我一般把预处理也用C++重写，或者用SIMD指令加速，确保它不成为瓶颈。

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

6.1 模型在测试集上表现好但现场误报多

这是最典型的问题，几乎每个做工业诊断的人都遇到过。排查思路我一般按这个顺序走。

先查数据分布是否一致。测试集和现场数据的采集条件、工况、传感器位置是否相同？如果不同，模型学到的特征在现场可能不成立。解决办法是用现场数据做微调，或者做域自适应。

再查物理约束是否失效。现场工况如果超出了物理模型的适用范围，约束就会误导模型。这时候要降低物理正则的权重，或者重新标定物理模型。

最后查阈值设置是否合理。分类模型的输出是概率，判为故障的阈值如果设得太低，误报自然多。我一般用现场的正常数据做验证，把阈值调到误报率可接受的水平，哪怕牺牲一点召回率。工业场景下，误报的代价往往比漏报还高，因为频繁误报会让运维人员对系统失去信任。

6.2 少数类故障完全检测不到

少数类检测不到，根子还是在样本不平衡。排查时先看少数类在训练集里到底有多少样本。如果只有几条，那什么方法都难救，必须想办法补充数据，要么现场多采集，要么用生成模型增强。

如果样本量还行但还是检测不到，检查损失函数的类别权重是否生效。有些框架的类别权重实现有bug，或者权重设得不够大。我一般会把少数类的权重设到多数类的几十倍，先看看能不能检测到，能检测到再慢慢往下调，找平衡点。

还有一个隐蔽的原因是特征层面少数类和多数类混在一起。如果少数类的特征和某个多数类很接近，模型很难分开。这时候要做特征分析，看看是不是需要引入新的特征，或者调整网络结构增强区分能力。

6.3 部署后推理结果和训练时对不上

这个问题我在部署阶段遇到过好几次，原因五花八门，整理成速查表方便对照。

我的经验是部署前一定要做数值一致性测试，拿一批样本，在训练框架和推理引擎上各跑一遍，逐样本对比输出。差异超过阈值就排查，不要等到上线了才发现问题。

6.4 独家避坑技巧汇总

最后分享几个我在实操中总结的技巧，都是文档里不会写的。

技巧一：物理约束的权重用验证集上的物理一致性指标来调，而不是用分类精度。分类精度对物理权重不敏感，但物理一致性指标敏感，用它来调更准。

技巧二：部署前用现场数据做一次端到端测试，包括传感器到推理结果的完整链路。很多问题只在完整链路上才暴露，单独测模型是测不出来的。

技巧三：模型版本管理要严格，训练、量化、部署各阶段的模型都要存档。出问题时能快速回滚，也能对比不同版本的表现。

技巧四：边缘设备的温度会影响推理稳定性，长时间运行后要监控延迟变化。有些设备过热会降频，延迟突然变大，诊断就会漏报。

技巧五：现场数据的标注往往有噪声，训练前要做标注质量检查。我遇到过标注员把正常样本标成故障的情况，这种脏数据对不平衡场景的伤害特别大，因为少数类本来就少，再混进错的，模型直接学歪。

这套框架我从数据到部署完整跑过几轮，最大的体会是：工业故障诊断没有银弹，每个环节都要抠细节。物理约束、不平衡处理、实时部署这三块，任何一块偷懒，最后都会在现场暴露出来。把这三块都做扎实，模型才能真正从论文走进产线。