搞工业设备预测性维护PdM的人很多都经历过这样的尴尬振动传感器装了波形也能看了领导问“这台风机到底还能撑多久”你只能回一句“数据有点异常”。问题往往不在传感器也不在某个算法而是从“振动大不大”到“哪个部件坏了、坏到什么阶段、该什么时候停机检修”之间缺了一条能闭环的诊断链路。这篇文章以一个可以实际落地的诊断架构为主线把高频时序特征提取、轴承/齿轮机理模型、劣化状态机闭环这三块拆开讲清楚。不是为了堆概念而是想回答现场最常问的几个问题采样频率到底要多高特征算出来之后怎么用为什么明明有报警拆开检查却没事适合正在做设备健康管理、准备上预测性维护系统或者已经存了大量振动数据但不知道怎么转化为决策的工程师参考。1. 振动信号里的故障信息先想清楚再下手1.1 幅值、频率、相位三个坐标缺一个都容易误判很多人刚接触振动诊断时第一个动作就是看幅值。RMS大不大、峰值高不高这些当然重要但光看幅值只能回答“振动剧烈不剧烈”回答不了“哪里坏了”。真正可用的故障定位需要同时看三个维度幅值反映能量大小用来判断劣化程度。频率反映故障源轴承外圈、内圈、滚动体、齿轮啮合都有不同的特征频率。相位反映激励源的方向性和位置关系转子动平衡、不对中、轴弯曲等问题经常要靠相位才能分辨。举个最常见的例子一个滚动轴承出现早期外圈点蚀RMS可能只比正常状态高10%到20%只看趋势曲线很容易忽略。但如果算包络谱在外圈故障特征频率处会出现明显的峰值旁边还跟着转频边带。这时候幅值只是“敲门声”频率才是“门牌号”。所以我在做预测性维护项目时第一件事不是选模型而是把所有可能的故障频率先算出来做成一张查找表。后面所有特征提取、状态判定的工作都围绕这些频率展开。1.2 高频到底要多高采样率和传感器安装要一起算标题里强调“高频时序特征提取”这里的“高频”很多时候被人误解成ADC采样率越高越好。实际上采样率需要覆盖的目标频带取决于你要诊断的故障类型。滚动轴承早期故障的冲击能量通常集中在高频共振区常见范围是2kHz到20kHz。齿轮箱的啮合冲击、齿面剥落引起的调制信号也经常在数千赫兹以上。如果采样率只有2kHz很多早期故障冲击根本采不到。工程上一般按目标最高频率的2.56倍以上设定采样率。比如要分析到10kHz采样率至少25.6kHz想覆盖轴承共振峰常规配置就是51.2kHz甚至更高。但注意采样率只是第一个门槛传感器和安装方式同样关键。加速度传感器有一个谐振频率安装得越牢靠可用频带越宽。磁座吸附在高频段的响应会比胶粘差很多现场图省事用磁座往往会把10kHz以上的细微冲击直接滤掉。另外数据采集卡前面必须有抗混叠滤波器否则高频成分混叠到低频区FFT频谱上会凭空多出一堆假峰。这一步是硬件层面最容易踩的坑。1.3 整周期采集让特征频率不随转速漂移很多设备不是恒转速运行的。泵、风机、压缩机经常变负荷电机转速也会有波动。转速一变所有特征频率都会跟着漂移。如果只是固定时间长度采集一段数据直接做FFT频谱里的频率会“糊”掉峰被展宽甚至淹没在噪声里。更稳的做法有两种同步整周期采集利用键相传感器或编码器信号每转固定采样N个点保证每个周期点数一致。软件阶比跟踪先记录转速曲线再通过插值重采样把等时间间隔的时域波形转成等角度间隔的角度域信号。这两种做法本质都是把“转速变化”从信号里剥离出去让后面的特征频率能对上一个固定的转频基准。我在现场调试时最深的体会是不要急着上复杂算法先把转速通道做准后面所有计算都顺很多。转速不稳时算出来的包络谱常常让人怀疑轴承坏了实际上只是轴转速在波动。2. 高频时序特征提取的工程链路从波形到趋势曲线2.1 时域统计量RMS、峰值因子、峭度的分工时域特征是成本最低、最容易在线计算的一类特征。它们虽然不能直接定位故障但用来做劣化趋势跟踪非常有效。常用的几个量各有分工特征物理含义适合场景RMS振动能量总体水平整体劣化趋势跟踪峰值瞬时最大冲击冲击类故障的早期发现峰值因子峰值/RMS反映波形尖锐程度滚动轴承点蚀、齿轮点蚀早期峭度四阶矩统计量对冲击敏感早期微弱冲击正常值约3附近波峰系数峰值/RMS和峰值因子类似冲击性故障的辅助判断RMS适合做慢变化趋势因为稳定性好不容易被单次冲击干扰。峭度是早期冲击的“放大镜”但有一个明显缺点单点冲击容易让峭度瞬时飙得很高制造很多假警报。所以我在实际系统里不会单独用峭度而是对峭度做滑动平均或者把“峭度超过阈值且RMS也同步上升”作为联合判定条件。峰值因子这类无量纲指标有个好处对负载和转速变化不敏感适合跨设备横向比较。但也因为无量纲它在故障晚期反而可能下降因为RMS涨上去了峰值涨得没RMS快。用的时候要明白它的脾气不能永远按“越高越坏”理解。2.2 FFT与包络谱特征频率才是诊断主线时域特征只能告诉你“信号变得不正常了”要定位故障必须回到频域。对原始波形直接做FFT可以得到工频、谐波、啮合频率、轴承特征频率的谱线。这个方法对齿轮啮合类故障很有效但对轴承早期故障往往无效原因在于早期冲击能量不是集中在低频特征频率上而是集中在轴承元件的高频固有共振区特征频率本身以调制边带的形式隐藏在共振峰两侧。这时候需要用包络谱先对信号做带通滤波把共振频带提取出来再通过Hilbert变换求包络最后对包络做FFT。这样等于先把高频载波“解调”下来再在低频段看冲击的重复频率。Python里实现并不复杂import numpy as np from scipy.signal import butter, filtfilt from scipy.signal import hilbert from numpy.fft import rfft, rfftfreq def envelope_spectrum(x, fs, band(2000, 10000)): # 带通滤波把目标共振频带提出来 nyq fs / 2.0 b, a butter(4, [band[0] / nyq, band[1] / nyq], btypebandpass) y filtfilt(b, a, x) # Hilbert变换求包络 analytic hilbert(y) env np.abs(analytic) # 包络信号的频谱 spec np.abs(rfft(env)) freqs rfftfreq(len(env), 1.0 / fs) return freqs, spec注意带通滤波的带宽选择很重要。选窄了可能把共振区切掉一半选宽了会引入其他振源干扰。实际操作中可以先算一次宽带FFT或者谱峭度图找到共振峰集中的频带再回过来定滤波上下限。谱峭度在这里特别有用它能在全频带里自动找“冲击能量占比高”的频带相当于给包络谱装了一个自动选频窗口。2.3 特征压缩与归一化别掉进“特征越多越好”的坑很多工程师一开始恨不得算上百个特征RMS、峰值、峭度、重心频率、频带能量……全堆进模型。结果往往是模型训练时效果很好上线后误报不断。原因很简单特征多了噪声也跟着多很多特征之间高度相关模型学到的可能是无关的随机波动。我的做法是先以机理模型为线索选特征大体思路是每个部件预留一组“机理特征”轴承特征频率幅值、边带幅值、包络谱能量占比、齿轮啮合频率幅值、边带能量。再加上几个通用统计量RMS、峰值因子、峭度、低频段能量。最后用趋势归一化把每个特征值和设备健康基线做比值。归一化的细节经常被忽略。同一型号的设备安装位置不同、基础刚度不同绝对特征值差异很大。最好在设备刚装好、确认状态良好时采集一段“基线”后续所有特征都除以基线值变成相对劣化倍数。例如轴承外圈特征频率幅值从基线的1.0涨到3.5比绝对幅值50m/s²更有工程意义。如果确实需要降维可以用PCA或者自编码器把特征压成1到2个健康指标但我不建议在系统初期就上黑盒模型。先用机理特征把规则跑通积累几个月现场数据后再考虑用数据驱动模型做剩余寿命预测这条路更稳。3. 轴承/齿轮机理模型故障指纹是怎么算出来的3.1 滚动轴承四类特征频率机理模型的价值在于它能把“某个部件坏了”这件事从模糊的经验判断变成一组可以计算的频率。滚动轴承有四个经典的故障特征频率分别对应外圈、内圈、滚动体、保持架。以滚动轴承节径为Dp、滚动体直径为Bd、滚动体个数为n、转速频率为fr、接触角为φ计算公式如下外圈故障频率BPFO (n / 2) × fr × (1 - Bd / Dp × cos φ)内圈故障频率BPFI (n / 2) × fr × (1 Bd / Dp × cos φ)滚动体故障频率BSF (Dp / (2 × Bd)) × fr × (1 - (Bd / Dp × cos φ)²)保持架故障频率FTF (fr / 2) × (1 - Bd / Dp × cos φ)这里需要理解一个关键点外圈固定时外圈故障的冲击位置相对传感器位置基本不变所以冲击序列比较“整齐”包络谱上特征频率峰值明显旁边常有转速边带。内圈故障就不一样了内圈随轴转故障点周期性进入和离开承载区所以包络谱上除了BPFI还会出现以转频fr为间距的边带族。实际诊断时千万不要只算基频谐波和边带同样重要。早期故障常常只在2倍频或3倍频处先冒头基频反而不明显。所以我在诊断规则里会同时检查特征频率的前三阶谐波以及±1倍转频边带任何一个出现同步增长都会触发“疑似故障”标记。3.2 齿轮啮合频率和边带族调制是磨损的语言齿轮箱的振动诊断核心是啮合频率。一对啮合齿轮中主动轮齿数z1、转速fr1从动轮齿数z2、转速fr2啮合频率GMF z1 × fr1 z2 × fr2。齿轮处于正常状态时啮合频率本身就有谱线幅值不一定很低。真正判断故障的更多是看啮合频率两侧的边带族均匀磨损或齿轮偏心会在啮合频率两侧出现幅值对称的边带边带间距等于该齿轮的转频。局部断齿或点蚀边带数量增多、幅度增大啮合频率基频幅值可能下降能量向边带扩散。齿面胶合或严重磨损高频啮合谐波幅值上升同时边带范围变宽整个谱底都被抬起来。所以我处理齿轮箱数据时会算一个很实用的指标边带能量比。把啮合频率附近±3倍转频范围内的边带能量加起来除以啮合频率基频幅值。这个比值一旦持续上升往往比单一啮合频率幅值更能反映局部损伤。需要提醒的是齿轮箱的转频是分级变速的不同轴转速不一样边带间距也跟着变。做频谱分析前一定要把每一根轴的转频都算清楚否则边带间距很容易被认错。这个细节在现场特别容易出问题尤其是两级、三级齿轮箱轴的转速经过减速后差异很大。3.3 机理模型和数据模型的分工不要互相替代现在工业界一提预测性维护就喜欢上深度学习但我个人经验是纯数据驱动模型在故障诊断系统里应该做“辅料”不应该做“主菜”。原因很现实故障数据本来就稀缺多数设备从健康到严重故障可能跨越一年以上能采集到的故障样本极少。深度学习模型在样本不足时很容易过拟合换个设备、换个工况就失效。机理模型在这时候有天然优势它不依赖历史故障样本只要知道轴承型号、齿数、转速就能算出特征频率。哪怕设备从没坏过也能建立“正常基线”和“异常嫌疑”的边界。更合理的做法是混合架构机理模型负责候选故障定位根据特征频率是否存在、幅值是否增长列出一个“嫌疑故障列表”。数据驱动模型负责劣化趋势预测在确认故障类型后把健康指标随时间的变化喂给回归模型估算从“早期故障”到“严重故障”的时间窗口。现场反馈负责修正每次检修后把实际原因回填持续校准模型参数和阈值。简单说机理模型回答“什么东西坏了”数据模型回答“还能撑多久”现场反馈回答“模型说得对不对”。三个角色合在一起才算真正可用的诊断系统。4. 劣化状态机闭环给健康分值装上“执行机构”4.1 为什么单阈值报警会被现场怼回来很多预测性维护系统最初的实现方式很简单健康指标超过阈值就报警。结果往往是被现场设备员反复投诉——报警太频繁拆开检查又没事或者干脆没人信变成“狼来了”。问题不在于阈值算得不对而在于“连续劣化过程”被简化成了“一个开关量”。实际设备的振动信号有波动工况变化、转速波动、环境噪声都会让特征值忽高忽低。一个刺耳的瞬时冲击就能把峭度顶上阈值但它可能真就是一次启动冲击不代表轴承已经开始损坏。状态机的作用就是把连续的健康指标映射成有限的离散阶段并且用迁移条件“过滤”掉瞬时抖动。给状态机加上迟滞、冷却时间和最小驻留时间之后报警的准确率会明显提升。4.2 三段式状态机判定层、迁移层、动作层分离借用嵌入式领域常见的设计习惯我把劣化状态机拆成三段式结构判定层每个巡检周期输入健康指标输出当前等级。迁移层根据当前状态和输入等级结合消抖规则决定是否发生状态迁移。动作层迁移到某状态后触发对应动作比如生成工单、通知点检、建议降负荷。状态定义不用太细现场能执行就好。我常用四个状态状态含义对应动作HEALTHY健康指标在基线范围内维持常规点检WATCH注意指标有上升趋势但未确认故障加密监测人工复核EARLY早期劣化机理特征明确生成诊断工单安排计划检修SEVERE严重劣化指标快速上升停产检修准备备件下面是一个简化版Python状态机核心思想是“连续命中多次才迁移、返回正常需要更严格的条件”class DegradationStateMachine: def __init__(self, low, high, severe, required_hits3, cooldown5): self.state HEALTHY self.low low self.high high self.severe severe self.required_hits required_hits self.cooldown cooldown def evaluate(self, health_index): # 判定层 if health_index self.severe: level SEVERE elif health_index self.high: level EARLY elif health_index self.low: level WATCH else: level HEALTHY # 迁移层 if level self.state: return self.state if level in (EARLY, SEVERE): self.cooldown - 1 if self.cooldown 0: self.state level self.cooldown 5 elif level HEALTHY and self.state in (WATCH, EARLY): self.cooldown - 2 if self.cooldown 0: self.state HEALTHY self.cooldown 5 else: self.cooldown 5 # 动作层由外部根据 state 触发 return self.state这个版本为了简洁做了不少简化但它体现了最重要的一点状态迁移不是单纯比大小而是有“记忆”的。一次超阈值不会立刻拉响防空警报连续多次超阈值才会升级同理回到正常也不是一两个周期就能回去。4.3 迟滞、冷却时间、最小驻留时间现场消抖三板斧状态机上线的第一版最常遇到的问题就是状态来回跳。早上刚到EARLY下午指标回落又回到WATCH第二天又跳回EARLY。设备员看状态一直在闪比不报警还头疼。解决来回跳有三个工程手段我习惯三个一起用迟滞区间进入某个状态用较高的阈值返回上一个状态用较低的阈值。比如健康指标0.8进入EARLY但指标回落到0.6以下才允许回到WATCH。中间0.6到0.8这段就是迟滞区相当于给状态切换加了一个“缓冲带”。冷却时间状态升级之后至少保持一定周期数才会再迁移。比如触发EARLY后如果指标只是偶尔回调不会立刻回到WATCH冷却周期内其他迁移条件暂时不生效。最小驻留时间任何状态一旦进入至少停留N个巡检周期。这个和冷却时间有点类似但更强调“状态必须有稳定持续时间”方便动作层安排工单。这三个参数不需要一开始就调得很准先用保守的默认值跑两周把误报记录拉出来看再针对性的放宽或收紧。我的经验是宁可让劣化状态晚确认一个周期也不要让错误报警把系统信用消耗掉。4.4 维修反馈线把闭环真正合上状态机本身只是一个“输出动作的判定器”它负责把健康指标变成检修建议但真正的闭环还需要一条维修反馈线。每次设备停机检修后把实际结果回填到系统里是什么故障、故障类型是否和诊断一致、更换了哪些零件、拆解照片是什么状态。这些反馈数据就是诊断系统最好的“监督标签”。回填之后系统可以做三件事更新特征库把这次故障样本的特征向量加入对应故障类型的参考库。校准阈值如果系统诊断为EARLY但实际拆开完全正常说明阈值偏紧按反馈自动上调。如果诊断WATCH但实际已经严重剥落说明阈值偏松需要下调。优化状态机参数统计不同状态迁移后的维修结果自动调整迟滞区宽度和冷却周期。我在实际项目中把这条反馈线做成半自动的维修工单完成后点检员在App上勾选故障类型和严重程度后台每天跑一次阈值更新。跑了三个月后系统的误报率明显下降很多早期故障在RMS几乎没变化时就能靠机理特征提前锁定。最后再分享一个调试技巧状态机上线初期不要急着关掉所有旧报警规则。把旧规则和新状态机并行运行一段时间两边都报警才通知现场两边有分歧的先记录。等积累足够多的对照样本后再切到状态机主导决策。这样既能验证新架构又不至于因为一次误配置就丢了现场信任。工业设备诊断这行模型的准确性很重要但系统的稳定性和可信度更重要。