预测性维护这几年几乎是工业物联网领域最常被提起的应用方向之一但真正能落地、能稳定跑上几个月的项目并不多见。我在多个产线项目里碰过不少壁也总结出一套比较实用的构建思路从传感器选型、数据链路搭建到特征工程、模型训练再到边缘推理和阈值策略每一层都有比算法本身更磨人的工程细节。这篇文章就把这套完整的实战过程拆开讲清楚适合准备把预测性维护从Demo推向真实产线的工程师也适合想系统理解IIoT数据管道如何与机器学习结合的读者。1. 为什么我在车间里反复摔轴承只为了建一套预测性维护系统先讲个背景。很多工厂的设备管理还停留在定期点检 坏了再修的阶段这种方式有两个明显的成本黑洞一是过度维护轴承、齿轮箱这类部件明明状态良好但到了计划保养周期就必须更换备件和人工都被浪费二是突发停机设备没有任何预兆地罢工产线一停就是按小时计算的损失夜间故障尤其致命。我见过一条自动化装配线因为末端减速机轴承失效整条线停了两小时后道排产全部打乱那次的损失足够买好几套传感器系统。我最早做的项目就是给一台大型旋转设备做振动监测。当时想着直接套一些公开数据集训练一个分类模型就完事结果发现不对劲公开数据集里的故障类型、转速工况和现场完全不一样模型在实验室里跑出来的准确率到了现场直接崩盘。于是我开始转换思路——不追求一个万能算法而是认真从传感器布点、数据质量、特征语义这些底层问题入手把预测性维护当成一个系统工程来做而不是一个机器学习实验。这个过程花了很长时间但最终产出的系统稳定运行了很久误报率和漏报率都控制在了可接受范围。为什么选Python而不是厂商自带的封闭分析工具因为Python的生态实在太适合这个场景了。数据采集端用Python写边缘网关脚本特征计算用NumPy和SciPy模型训练用scikit-learn或PyTorch导出成ONNX放到边缘侧推理整个过程可以用同一种语言贯穿。而且Python的调试成本低改动模型策略的时候不需要厂商工程师介入这对于需要快速迭代的工厂项目来说价值非常大。这篇文章面向的读者有两类第一类是工业物联网方向的工程师正在规划预测性维护功能想知道数据管道怎么搭、模型怎么选、部署有哪些坑第二类是机器学习背景的学习者想了解算法在真实工业场景下会遇到什么非理想情况。两种读者都能在这里找到对应内容。2. 预测性维护系统的整体架构从传感器到告警台2.1 传感器选型与布点信号质量决定模型上限很多项目一开始就栽在传感器上。预测性维护的技术路径有很多种包括振动分析、温度监测、油液分析、电流特征分析等其中振动分析是旋转机械故障诊断最主流的方式信息量最丰富。传感器选型要看的核心指标有几个频响范围、量程、分辨率、防护等级。我在现场通常会这样选型。加速度传感器是首选工业级的一般用ICP型压电式加速度计频响从0.5Hz到10kHz以上量程根据设备振动水平选择±50g。电机端和泵端的正常振动一般不大但要考虑启停瞬间的冲击。温度传感器用PT100铂电阻或者集成式温度变送器响应速度比热电偶慢一些但稳定性更好、抗干扰能力强。如果设备是变频驱动的还需要采集电流信号用电流互感器配合变频器输出端的信号调理模块。部署位置比传感器本身更关键。同样一个轴承加速度计贴在轴承座上和贴在设备外壳的四个角上信号特征天差地别。轴承故障激发的振动频率通常在1kHz到5kHz甚至更高如果安装在路径较长的外壳表面高频成分会被结构衰减掉故障特征就丢了。所以布点的原则是尽可能靠近被测的旋转部件路径越短越好表面要清洁、平整用磁吸座或胶粘固定。注意不要贴在薄壁钣金件上那会产生大量结构共振噪声。2.2 工业物联网数据链路中的消息总线选择传感器信号采集上来之后数据怎么流转到分析端这是工业物联网架构设计的核心问题。很多工厂内部有支持OPC UA或Modbus TCP的PLC和DCS系统但PLC里面的数据通常是控制用的过程变量采样率不高比如温度每秒一次、压力每百毫秒一次。而振动数据如果要完整保留轴承故障特征每通道采样率至少需要20kHz以上一次采集就是几万甚至几十万的点。所以我的方案是振动数据不走PLC单独建立一条高速采集通道。边缘采集网关通常是一台工业级工控机或者嵌入式设备负责同步采集多路传感器信号做初步的信号调理和特征计算然后把降维后的特征值定期发送到服务器。传输协议方面MQTT是一个很自然的选择它是轻量级的发布/订阅协议头部开销极小非常适合工业现场有限带宽和弱网环境。很多人在这个环节会犹豫为什么不用HTTP原因很简单HTTP是请求应答模式服务器需要不断去拉数据而且HTTP头比较大在高频上报场景下网络占用很高。MQTT则允许传感器设备主动推送数据到Broker断线自动重连、消息持久化这些特性都是现成的。设备端到服务端的链路大致是这样采集端加速度传感器 → 数据采集卡 / 采集模块 → 边缘网关边缘计算在网关内完成FFT、统计特征计算得到健康度特征向量消息推送特征向量通过MQTT发布到主题比如factory/line1/gearbox/vib_features服务端MQTT Broker接收消息写入时序数据库上层应用告警服务、可视化看板、模型训练平台从时序数据库读取数据2.3 数据管道的关键设计同步、对齐与断点续传工业数据管道和互联网日志管道有一个很不一样的地方时间对齐的精度要求高因为振动、温度、电流这些信号需要联合分析时时间戳错位一个采样周期特征组合的语义就变了。我们使用的边缘采集程序会为每个数据包打上设备本地时间戳再通过网络时间协议与服务器同步。数据到达时序数据库后按照设备定义好的时间分片做对齐和聚合。另一个容易忽略的问题是网络不稳定造成的断点和乱序。车间里的网络环境普遍不如办公室无线网络丢包率高网线接头氧化导致偶发断连这些都会造成数据空洞。解决方案是设备端的本地缓存加断点续传机制。边缘网关在本地维护一个缓存队列上报失败的消息不丢弃按序等待网络恢复后补偿上报。时序数据库端也要允许乱序写入不能因为时间戳比当前时间早而拒绝接收。还有双写机制也很重要一份写实时分析库用于在线告警一份写原始数据湖用于模型训练和事后分析。原始数据湖保留90天以上方便出现没有预料到的故障模式时可以回放历史数据重新训练模型。项目中的经验是原始波形数据虽然体积很大但存储成本通常能接受。要花大价钱存储的是误删不了的数据和训练不出来模型的残缺数据。3. 核心模型构建振动特征提取与健康度建模的Python实现3.1 特征工程时域、频域与包络谱的结合预测性维护模型最重要的不是算法有多花哨而是特征能不能覆盖故障模式的物理本质。以滚动轴承为例它的故障演化路径通常是早期剥落 → 冲击脉冲 → 高频共振 → 宽带振动。不同阶段的特征窗口不一样需要组合多种特征类型来捕捉。时域特征最容易理解包括均方根值RMS、峰值因子、峭度Kurtosis、波形因子等。RMS反映整体振动能量轴承磨损导致间隙增大时RMS会明显上升峰值因子和峭度对早期冲击型故障敏感因为早期故障的脉冲持续时间短、能量占比低但峰值却很突出。轴承保持架故障时峭度值往往在振动能量还没有明显变化前就已经异常了。频域特征通过快速傅里叶变换FFT把振动信号转换到频率域。正常的轴承频谱中转频及其低次谐波占主导。当轴承内圈或外圈出现局部缺陷时会产生特征频率及其谐波成分。特征频率的具体数值取决于轴承几何参数和转速通过轴承特征频率计算公式可以提前算出来然后直接看这些频率点附近的幅值是否异常。包络谱分析是一个更高级的工具也叫解调分析。高频冲击会激起传感器的固有共振频带把原始信号做带通滤波后再通过Hilbert变换提取包络然后对包络信号做FFT就能在低频段看到轴承故障特征频率。这相当于把藏在高频共振里的微弱故障信息解调出来对早期故障检测非常有效。Python里用SciPy的signal.hilbert就可以实现不复杂但滤波器的设计参数需要反复调。特征计算示例对采集到的一段原始振动波形进行滑窗处理import numpy as np from scipy import signal, stats def extract_features(waveform, fs, bearing_freqsNone): # 去直流 x waveform - np.mean(waveform) # 时域特征 rms np.sqrt(np.mean(x ** 2)) peak np.max(np.abs(x)) crest_factor peak / (rms 1e-8) kurtosis stats.kurtosis(x) # 频域特征全频谱的能量分布 freqs, psd signal.welch(x, fsfs, nperseg4096, scalingdensity) freq_energy np.trapezoid(psd, freqs) # 计算某个频段的能量集中度 band_mask (freqs 1000) (freqs 5000) high_band_ratio np.trapezoid(psd[band_mask], freqs[band_mask]) / (freq_energy 1e-8) features { rms: rms, crest_factor: crest_factor, kurtosis: kurtosis, high_band_ratio: high_band_ratio, } if bearing_freqs is not None: for name, f_char in bearing_freqs.items(): idx np.argmin(np.abs(freqs - f_char)) features[ffp_{name}] psd[idx] * fs return features提取窗口大小需要考虑设备的运行周期我习惯对每个通道每秒采集的数据做一次特征提取一个窗口取1秒的波形这样既能保留故障脉冲的统计意义又不会让数据量过于膨胀。对每台设备每秒钟产生几千个特征的场景会在采集端先把特征算好服务器收到的就不是原始波形而是规整的特征向量这大大降低了带宽压力和存储压力。3.2 模型选择监督与无监督的路线抉择预测性维护的建模路线通常分成两条有监督分类/回归和无监督异常检测。选哪条完全取决于一个现实问题你有没有足够多、足够干净的故障标签数据有监督路线适合数据条件好的场景。比如测试台架已经完成了多组轴承的全寿命试验记录从健康状况到完全失效的完整退化过程这些数据可以打上标签正常、早期缺陷、严重故障甚至可以用来训练剩余使用寿命RUL回归模型。工厂里面具备这样条件的设备其实不多大多数规模化产线的设备处于健康但不知道怎么定义故障标签的状态。无监督路线适合现实中的大多数场景。设备在正常工况下运行传感器数据源源不断但没有历史故障记录。这时候用异常检测算法建立正常模式边界一旦数据偏离正常范围就产生异常告警。常用的算法包括孤立森林、单类支持向量机、自编码器。我在实践中发现对于高维特征空间中的工业数据孤立森林是一个性价比很高的选择训练快、可解释性强可以输出每个特征的贡献度方便回溯是哪个振动指标异常导致的而且对非线性边界的要求不高。如果时序特征比较明显比如振动信号随转速变化呈周期性可以考虑长短期记忆网络LSTM或者Transformer做序列建模。但这类模型需要大量的数据和较长的调参周期在工程落地的现实节奏下往往不划算。我的原则是能用轻量级无监督模型解决的就不要上深度学习把复杂度留在需要那一层的地方。3.3 从故障分类到健康度打分剩余寿命预测的替代方案理想状态下预测性维护系统应该能给出这台设备还能跑多少天的明确答案。但在真实工厂里剩余使用寿命预测是一个很难的任务因为设备的退化过程受负载、转速、环境温度、润滑状态等多种因素影响而且故障往往是加速退化的早期预测的置信度很低。实践中更稳妥的做法是做一个健康度打分把多维特征压缩到一个0到100的分数区间直观反映设备当前状态和历史正常状态的偏离程度。构建健康度模型的思路是这样的用无监督模型算出样本到正常模式的异常得分对异常得分做平滑处理降低瞬时噪声干扰通过分段函数映射到健康度区间比如异常得分越高、健康度越低设置多级阈值关注分数80、预警分数60、告警分数40。健康度打分的最大好处是对现场操作人员友好。产线工人不需要理解峭度和包络谱看到仪表盘上的绿色黄色红色就能判断设备状态。管理层也能直接看到整条线的整体健康度分布方便安排检修计划。给一个完整训练流程的例子——用孤立森林构建正常状态模型import numpy as np import pandas as pd from sklearn.ensemble import IsolationForest from sklearn.preprocessing import StandardScaler def train_normal_model(feature_df): # 假设 feature_df 只包含设备处于正常状态的特征数据 scaler StandardScaler() X scaler.fit_transform(feature_df.values) model IsolationForest( n_estimators300, contamination0.02, max_samplesauto, random_state42 ) model.fit(X) return scaler, model def health_score(sample_df, scaler, model): # 对实时特征向量打分 X scaler.transform(sample_df.values) anomaly_score model.decision_function(X) # 越高越正常 # 把 decision_function 输出的分数归一化到 0~100 的健康度 min_score -0.5 max_score 0.0 normalized (anomaly_score - min_score) / (max_score - min_score) health np.clip(normalized * 100, 0, 100) return health[0]这里需要注意contamination参数的取值。它表示模型认为训练数据中异常样本的比例。在正常情况下训练数据应该都是正常样本但传感器偶尔会有毛刺或者设备某个瞬间工况波动较大这些都会被当作正常数据的噪声踢出去。我把contamination设为0.02也就是容忍2%的噪声这个值通常够用。如果误报率高可以考虑调低到0.005反之如果线上数据经常出现新的非正常模式可以考虑适当调高。3.4 模型评估工业场景下的指标不能只看准确率算法工程师习惯用准确率、AUC、F1来评价模型但在预测性维护场景里这些指标远远不够。原因是代价不对称漏报一次真实故障可能导致设备损坏、产线停摆甚至安全事故代价巨大而误报一次最多浪费一次巡检人力。所以必须引入代价敏感评估或者直接评估每百小时误报次数和故障检出率两个操作性强且简洁的指标。我做项目的时候会参考以下评估方式离线回放测试拿历史数据切分训练集和测试集测试集中包含已知发生故障的时段验证模型能否在故障发生前提前72小时或24小时捕捉到异常趋势。假阳性率控制正常工况下的数据不应该频繁触发告警一般要求误报间隔大于7天否则维保人员会对告警麻木。提前量分析如果故障已被证实对比第一次告警时间和实际停机时间得出提前预警了多少小时这是业务层最看重的数字。图表方面不是重点重点是数据管道能不能支撑这些评估。项目中一个常见做法是把每次告警事件、告警级别、人工确认结果都记录下来形成告警工单日志。这个日志是后续优化模型最重要的依据稽核人员确认哪次告警是准确的、哪次是误报然后把这些反馈喂回模型做在线学习或迭代训练。4. 边缘推理与动态阈值预测性维护系统能不能用的分水岭4.1 为什么必须把推理放到边缘侧很多工厂的现场网络条件并没有想象中那么好。车间里金属设备大量存在无线信号衰减严重有线网络也经常因环境恶劣而断连。如果把原始振动波形全部回传云端做推理网络带宽和稳定性先会成为瓶颈。更现实的需求是告警必须是低延迟的不能让设备已经异响了几分钟告警还在传输链路的队列里排队。边缘推理的方案是把训练好的模型导出并部署到边缘网关让网关直接对本地采集的特征数据做推理。只有当模型判定需要深入分析时才把原始波形回传给服务端。这种边算边传的模式把这个场景下的数据流量降低了90%以上。例如每台设备每通道20kHz的原始数据一天下来好几GB的流量经过边缘特征提取后只剩不到50MB的特征数据。告警延迟也从秒级降到了百毫秒级。4.2 模型导出与部署ONNX是连接Python和工业边缘的桥梁模型在Python里训练完毕导出成ONNX格式的流程图如下用scikit-learn或PyTorch训练模型用skl2onnx或torch.onnx.export导出到ONNX格式在边缘网关里用onnxruntime加载模型执行推理。ONNX的好处在于它是开放标准几乎所有主流的边缘计算硬件都有对应的运行时支持。用CPU推理的工业网关一般不是太强所以需要做一些优化。可以先从特征工程本身做降维比如保留最重要的20~30个特征去掉冗余。更激进的做法是模型轻量化把孤立森林的子树数量从300棵减少到100棵精度下降通常可以控制在1%左右但推理耗时可以减少60%以上。部署后的监控同样重要。我习惯为边缘推理程序加上一个看门狗如果GPU或CPU占用异常、特征输入异常比如全是NaN自动重启进程同时服务端会收到心跳告警。边缘程序崩溃是最容易被忽视的问题一旦崩溃设备变成盲区而管理者往往会误以为一切正常。4.3 动态阈值固定阈值在真实工况下必然引发误报潮第一次上线预测性维护系统的时候我犯过一个典型的错误全局设了一个固定的健康度阈值80分以下就告警。模型训练时用的是A工况数据比如泵转速在1500转/分左右。到了生产中操作人员根据需要把转速调到2400转/分振动规律完全变化了系统开始疯狂误报。每个值班工程师的手机都被告警轰炸最后大家形成告警疲劳真有故障了也没人看了。这其实就是很多预测性维护项目失败的核心原因阈值没有跟着工况走。解决办法是用动态阈值健康度打分不再是一个绝对分数而是把当前健康度与相同工况下历史健康度分布做比较计算一个标准分或百分位数。实现动态阈值的基本思路是引入工况标签。通过采集设备的转速信号、负载信号或运行模式标识把历史特征数据按工况聚类。每个工况组单独维护一个正常模型和阈值。实时数据先判断属于哪个工况再用对应工况的模型和阈值来判断是否异常。工况切换瞬间不用特别处理因为模型切换后特征分布自然对齐到正确的正常基线。4.4 一个基于百分位数的自适应阈值实现方案这里贴一个比较实用的方案。假设已经有一个设备的历史健康度序列接下来用百分位数法计算动态阈值import numpy as np class AdaptiveThreshold: def __init__(self, lookback_window7200, warning_percentile95, alarm_percentile99): self.scores [] self.lookback_window lookback_window self.warning_percentile warning_percentile self.alarm_percentile alarm_percentile def update(self, score): # 保留最近一段时间内的健康度分数 self.scores.append(score) if len(self.scores) self.lookback_window: self.scores.pop(0) def get_thresholds(self): if len(self.scores) 1000: return None, None # 数据量不足时不告警 warning_th np.percentile(self.scores, self.warning_percentile) alarm_th np.percentile(self.scores, self.alarm_percentile) return warning_th, alarm_th注意这里分数越高越健康的话找的是低百分位数或高百分位数要看分数方向。上面代码假设的是分数越高越健康的体系percentile分位数值越大对应分数越高所以warning_percentile要改成5和1或者用(100 - percentile)。模板代码只是演示思路各系统需要按自己健康度方向调整。我自己用的时候有个附加逻辑动态阈值不是无脑跟随近期数据的如果设备确实在持续退化健康度会一路走低此时百分位阈值也会跟着降低形成窗口效应退化信号就永远告警不出来了。解决办法是设置一个绝对底线阈值比如健康度低于40一定告警不受动态阈值影响。绝对阈值和动态阈值同时判断取更严格的一个作为最终告警条件。这个方案在几个项目里表现都不错。核心思想很直观用设备自身的历史表现作为基准线而不是拿一套外部统一定义的规则去套所有设备因为不同位置的传感器、不同负载工况下振动能量的日常波动范围差异太大了。5. 工厂实际部署时最常踩的四类坑与排查方法5.1 数据不平衡正常样本占比99%异常只在最后5分钟出现预测性维护项目里数据不平衡几乎必然存在。设备多数时间在正常状态运行真正的故障数据往往集中在设备即将损坏前的几个小时甚至几分钟。这样一个数据集如果直接用来训练有监督分类模型模型会很轻松地学到全都预测正常这种偷懒解法准确率还能达到99%以上。我在一个项目里遇到过类似的情况。某减速机的振动数据记录了三个月其中故障数据只有最后46分钟。直接用原始数据训练分类模型测试集准确率99.2%看起来漂亮得很但故障样本的召回率是6.7%。几乎所有故障都被漏掉了。解决数据不平衡的办法有几个对正常样本降采样对故障样本做SMOTE过采样或者在损失函数里给少数类加权重。但这些都是辅助手段最根本的还是要尽可能多地积累故障数据把故障演化过程完整留下来。解决思路也可以换一种放弃监督分类转用无监督异常检测。因为正常样本数据量巨大、分布清晰异常检测模型只需要学习正常模式的边界不需要见过所有故障模式。真实故障模式往往和已知故障都不一样无监督检测方法反而有更强的泛化能力。5.2 传感器漂移模型上线三个月后告警灵敏度明显下降工业传感器在恶劣温度、粉尘、电磁干扰环境下运行时间久了会出现灵敏度下降或基线漂移。加速度计的灵敏度漂移会导致相同振动水平下计算出的RMS值变小于是模型越来越麻木直到设备故障恶化到一定程度才触发告警。排查方法需要先区分是传感器问题还是设备问题。做法是找一个参考点在设备正常停机时采集一段静态数据理论上振动应为零附近。如果静态数据的基线噪声明显高于历史值或者产生明显漂移就可以怀疑是传感器或线缆松动问题。更规范的方式是设置定期标定计划比如每3个月用标准振动源校准一次传感器。当发现传感器状态异常时在数据管道里对该通道打上失效标签让模型忽略此通道的特征避免脏数据喂进模型影响判断。5.3 工况切换引起的误报不是设备坏了是转速变了这类问题在变频设备上非常典型。泵的转速从800转/分升到1450转/分振动能量会上升好几倍但这是正常工作状态的变化不是故障。如果模型没有工况感知能力就会在每一次转速调整后触发误报让现场人员对整个系统失去信任。我采用的方法是在特征里显式加入工况变量比如转速、电流平均值、阀门开度等过程变量。特征集包含两类一是振动、温度、电流等设备状态特征二是转速、负载等工况情境特征。模型训练时工况特征会帮助模型建立不同工况下振动正常范围不同的认知。部署时实时特征向量同样包含工况信息就能在当前工况的基准下评估设备状态。如果工况变量无法直接获取可以用聚类方法从振动特征自身推断工况模式。系统上线初期先跑两周数据用高斯混合模型或KMeans对特征向量聚类把聚类结果作为工况标签附加到数据上。之后再遇到相似的特征模式就能自动识别为同工况。5.4 标签缺失与标注不准最贵的东西不是机器是正确的历史结论到目前为止我遇到最难的问题既不是算法选型也不是阈值调参而是数据标注。故障数据的时间范围到底从哪里算起哪个时间点是故障开始如果故障发生在凌晨三点而设备到早晨八点才被巡检发现那这5个小时算正常还是故障没有一个明确的标注模型训练时就不知道边界在哪里。我的办法是和维修团队建立一套故障事件登记制度。每次设备停机检修维修工单上要求填写设备是否发生故障、故障类型、首次异常时间根据历史数据分析推测、更换的零部件信息。这些工单信息回填到时序数据库形成带标签的故障事件。数据标注这件事不能靠程序员在电脑前猜必须让最熟悉设备的人参与。系统上线后还要建立一个闭环反馈机制。每次模型发出告警巡检人员需要在工单里确认是真实故障设备正常还是工况变化。真实故障回填为故障样本续训练时纳入设备正常则回填为正常样本帮助调整阈值。这个闭环跑起来的标志是误报率随时间推移持续下降模型越来越了解这台设备。6. 从能用到好用告警场景化与运维联动模型告警只是第一步告警之后怎么办一个告警如果不能直接转化为运维动作价值就打折了。我见过不少系统告警推到手机上是没问题的但现场巡检人员一眼看不懂故障出在哪里。这样的系统用几天就被抛弃了。所以在做告警的时候我会把告警信息从健康度低于X翻译成故障模式可能位置建议动作。实现方式是给告警事件附带一个可解释性分析模块告诉现场人员是哪几个特征偏出正常范围。比如外圈故障的特征是外圈特征频率谱峰显著升高包络谱中可以看到故障频率基频及其谐波。把这些内容写入告警内容摘要里值班工程师拿着这条告警就能精准去检查轴承外圈对应位置效率高很多。告警与前端的联动也非常重要。如果工厂已有监控巡检系统比较好的是走告警工单。预测性维护系统推送事件到告警平台生成巡检工单分配给相应的维修班组工单处理结果回填。这样做的好处是彻底打通了状态监测和运维执行。7. 最后再分享一点经验预测性维护系统做到现在我最大的体会是从0到1搭建技术架构往往并不是最难的部分真正难的是让系统在工业现场长期稳定运行。网络会断、传感器会漂移、工况会变、生产计划会调整新问题永远比预期多。做这个方向心态上要把自己从算法工程师切换成系统工程师很多问题解法不在于模型而在于数据链路和运维流程。如果现在让我重新做一个预测性维护项目我第一件事不是选模型而是先花两周时间把历史数据翻个底朝天把每台设备的振动特点、工况变化规律摸清楚和老师傅聊清楚哪些异响是故障、哪些异响是正常。有了这些底数后面的技术工作会顺畅得多。另外如果想快速验证预测性维护的价值建议先选一台故障率最高的设备做试点不要一上来就铺全厂。把一两点做出体型再谈规模复制路径会踏实很多。 
长河君 · 2026/10/19 16:16:52 · 阅读 1.2k 预测性维护系统实战：从传感器选型到边缘推理的完整构建指南
预测性维护这几年几乎是工业物联网领域最常被提起的应用方向之一但真正能落地、能稳定跑上几个月的项目并不多见。我在多个产线项目里碰过不少壁也总结出一套比较实用的构建思路从传感器选型、数据链路搭建到特征工程、模型训练再到边缘推理和阈值策略每一层都有比算法本身更磨人的工程细节。这篇文章就把这套完整的实战过程拆开讲清楚适合准备把预测性维护从Demo推向真实产线的工程师也适合想系统理解IIoT数据管道如何与机器学习结合的读者。1. 为什么我在车间里反复摔轴承只为了建一套预测性维护系统先讲个背景。很多工厂的设备管理还停留在定期点检 坏了再修的阶段这种方式有两个明显的成本黑洞一是过度维护轴承、齿轮箱这类部件明明状态良好但到了计划保养周期就必须更换备件和人工都被浪费二是突发停机设备没有任何预兆地罢工产线一停就是按小时计算的损失夜间故障尤其致命。我见过一条自动化装配线因为末端减速机轴承失效整条线停了两小时后道排产全部打乱那次的损失足够买好几套传感器系统。我最早做的项目就是给一台大型旋转设备做振动监测。当时想着直接套一些公开数据集训练一个分类模型就完事结果发现不对劲公开数据集里的故障类型、转速工况和现场完全不一样模型在实验室里跑出来的准确率到了现场直接崩盘。于是我开始转换思路——不追求一个万能算法而是认真从传感器布点、数据质量、特征语义这些底层问题入手把预测性维护当成一个系统工程来做而不是一个机器学习实验。这个过程花了很长时间但最终产出的系统稳定运行了很久误报率和漏报率都控制在了可接受范围。为什么选Python而不是厂商自带的封闭分析工具因为Python的生态实在太适合这个场景了。数据采集端用Python写边缘网关脚本特征计算用NumPy和SciPy模型训练用scikit-learn或PyTorch导出成ONNX放到边缘侧推理整个过程可以用同一种语言贯穿。而且Python的调试成本低改动模型策略的时候不需要厂商工程师介入这对于需要快速迭代的工厂项目来说价值非常大。这篇文章面向的读者有两类第一类是工业物联网方向的工程师正在规划预测性维护功能想知道数据管道怎么搭、模型怎么选、部署有哪些坑第二类是机器学习背景的学习者想了解算法在真实工业场景下会遇到什么非理想情况。两种读者都能在这里找到对应内容。2. 预测性维护系统的整体架构从传感器到告警台2.1 传感器选型与布点信号质量决定模型上限很多项目一开始就栽在传感器上。预测性维护的技术路径有很多种包括振动分析、温度监测、油液分析、电流特征分析等其中振动分析是旋转机械故障诊断最主流的方式信息量最丰富。传感器选型要看的核心指标有几个频响范围、量程、分辨率、防护等级。我在现场通常会这样选型。加速度传感器是首选工业级的一般用ICP型压电式加速度计频响从0.5Hz到10kHz以上量程根据设备振动水平选择±50g。电机端和泵端的正常振动一般不大但要考虑启停瞬间的冲击。温度传感器用PT100铂电阻或者集成式温度变送器响应速度比热电偶慢一些但稳定性更好、抗干扰能力强。如果设备是变频驱动的还需要采集电流信号用电流互感器配合变频器输出端的信号调理模块。部署位置比传感器本身更关键。同样一个轴承加速度计贴在轴承座上和贴在设备外壳的四个角上信号特征天差地别。轴承故障激发的振动频率通常在1kHz到5kHz甚至更高如果安装在路径较长的外壳表面高频成分会被结构衰减掉故障特征就丢了。所以布点的原则是尽可能靠近被测的旋转部件路径越短越好表面要清洁、平整用磁吸座或胶粘固定。注意不要贴在薄壁钣金件上那会产生大量结构共振噪声。2.2 工业物联网数据链路中的消息总线选择传感器信号采集上来之后数据怎么流转到分析端这是工业物联网架构设计的核心问题。很多工厂内部有支持OPC UA或Modbus TCP的PLC和DCS系统但PLC里面的数据通常是控制用的过程变量采样率不高比如温度每秒一次、压力每百毫秒一次。而振动数据如果要完整保留轴承故障特征每通道采样率至少需要20kHz以上一次采集就是几万甚至几十万的点。所以我的方案是振动数据不走PLC单独建立一条高速采集通道。边缘采集网关通常是一台工业级工控机或者嵌入式设备负责同步采集多路传感器信号做初步的信号调理和特征计算然后把降维后的特征值定期发送到服务器。传输协议方面MQTT是一个很自然的选择它是轻量级的发布/订阅协议头部开销极小非常适合工业现场有限带宽和弱网环境。很多人在这个环节会犹豫为什么不用HTTP原因很简单HTTP是请求应答模式服务器需要不断去拉数据而且HTTP头比较大在高频上报场景下网络占用很高。MQTT则允许传感器设备主动推送数据到Broker断线自动重连、消息持久化这些特性都是现成的。设备端到服务端的链路大致是这样采集端加速度传感器 → 数据采集卡 / 采集模块 → 边缘网关边缘计算在网关内完成FFT、统计特征计算得到健康度特征向量消息推送特征向量通过MQTT发布到主题比如factory/line1/gearbox/vib_features服务端MQTT Broker接收消息写入时序数据库上层应用告警服务、可视化看板、模型训练平台从时序数据库读取数据2.3 数据管道的关键设计同步、对齐与断点续传工业数据管道和互联网日志管道有一个很不一样的地方时间对齐的精度要求高因为振动、温度、电流这些信号需要联合分析时时间戳错位一个采样周期特征组合的语义就变了。我们使用的边缘采集程序会为每个数据包打上设备本地时间戳再通过网络时间协议与服务器同步。数据到达时序数据库后按照设备定义好的时间分片做对齐和聚合。另一个容易忽略的问题是网络不稳定造成的断点和乱序。车间里的网络环境普遍不如办公室无线网络丢包率高网线接头氧化导致偶发断连这些都会造成数据空洞。解决方案是设备端的本地缓存加断点续传机制。边缘网关在本地维护一个缓存队列上报失败的消息不丢弃按序等待网络恢复后补偿上报。时序数据库端也要允许乱序写入不能因为时间戳比当前时间早而拒绝接收。还有双写机制也很重要一份写实时分析库用于在线告警一份写原始数据湖用于模型训练和事后分析。原始数据湖保留90天以上方便出现没有预料到的故障模式时可以回放历史数据重新训练模型。项目中的经验是原始波形数据虽然体积很大但存储成本通常能接受。要花大价钱存储的是误删不了的数据和训练不出来模型的残缺数据。3. 核心模型构建振动特征提取与健康度建模的Python实现3.1 特征工程时域、频域与包络谱的结合预测性维护模型最重要的不是算法有多花哨而是特征能不能覆盖故障模式的物理本质。以滚动轴承为例它的故障演化路径通常是早期剥落 → 冲击脉冲 → 高频共振 → 宽带振动。不同阶段的特征窗口不一样需要组合多种特征类型来捕捉。时域特征最容易理解包括均方根值RMS、峰值因子、峭度Kurtosis、波形因子等。RMS反映整体振动能量轴承磨损导致间隙增大时RMS会明显上升峰值因子和峭度对早期冲击型故障敏感因为早期故障的脉冲持续时间短、能量占比低但峰值却很突出。轴承保持架故障时峭度值往往在振动能量还没有明显变化前就已经异常了。频域特征通过快速傅里叶变换FFT把振动信号转换到频率域。正常的轴承频谱中转频及其低次谐波占主导。当轴承内圈或外圈出现局部缺陷时会产生特征频率及其谐波成分。特征频率的具体数值取决于轴承几何参数和转速通过轴承特征频率计算公式可以提前算出来然后直接看这些频率点附近的幅值是否异常。包络谱分析是一个更高级的工具也叫解调分析。高频冲击会激起传感器的固有共振频带把原始信号做带通滤波后再通过Hilbert变换提取包络然后对包络信号做FFT就能在低频段看到轴承故障特征频率。这相当于把藏在高频共振里的微弱故障信息解调出来对早期故障检测非常有效。Python里用SciPy的signal.hilbert就可以实现不复杂但滤波器的设计参数需要反复调。特征计算示例对采集到的一段原始振动波形进行滑窗处理import numpy as np from scipy import signal, stats def extract_features(waveform, fs, bearing_freqsNone): # 去直流 x waveform - np.mean(waveform) # 时域特征 rms np.sqrt(np.mean(x ** 2)) peak np.max(np.abs(x)) crest_factor peak / (rms 1e-8) kurtosis stats.kurtosis(x) # 频域特征全频谱的能量分布 freqs, psd signal.welch(x, fsfs, nperseg4096, scalingdensity) freq_energy np.trapezoid(psd, freqs) # 计算某个频段的能量集中度 band_mask (freqs 1000) (freqs 5000) high_band_ratio np.trapezoid(psd[band_mask], freqs[band_mask]) / (freq_energy 1e-8) features { rms: rms, crest_factor: crest_factor, kurtosis: kurtosis, high_band_ratio: high_band_ratio, } if bearing_freqs is not None: for name, f_char in bearing_freqs.items(): idx np.argmin(np.abs(freqs - f_char)) features[ffp_{name}] psd[idx] * fs return features提取窗口大小需要考虑设备的运行周期我习惯对每个通道每秒采集的数据做一次特征提取一个窗口取1秒的波形这样既能保留故障脉冲的统计意义又不会让数据量过于膨胀。对每台设备每秒钟产生几千个特征的场景会在采集端先把特征算好服务器收到的就不是原始波形而是规整的特征向量这大大降低了带宽压力和存储压力。3.2 模型选择监督与无监督的路线抉择预测性维护的建模路线通常分成两条有监督分类/回归和无监督异常检测。选哪条完全取决于一个现实问题你有没有足够多、足够干净的故障标签数据有监督路线适合数据条件好的场景。比如测试台架已经完成了多组轴承的全寿命试验记录从健康状况到完全失效的完整退化过程这些数据可以打上标签正常、早期缺陷、严重故障甚至可以用来训练剩余使用寿命RUL回归模型。工厂里面具备这样条件的设备其实不多大多数规模化产线的设备处于健康但不知道怎么定义故障标签的状态。无监督路线适合现实中的大多数场景。设备在正常工况下运行传感器数据源源不断但没有历史故障记录。这时候用异常检测算法建立正常模式边界一旦数据偏离正常范围就产生异常告警。常用的算法包括孤立森林、单类支持向量机、自编码器。我在实践中发现对于高维特征空间中的工业数据孤立森林是一个性价比很高的选择训练快、可解释性强可以输出每个特征的贡献度方便回溯是哪个振动指标异常导致的而且对非线性边界的要求不高。如果时序特征比较明显比如振动信号随转速变化呈周期性可以考虑长短期记忆网络LSTM或者Transformer做序列建模。但这类模型需要大量的数据和较长的调参周期在工程落地的现实节奏下往往不划算。我的原则是能用轻量级无监督模型解决的就不要上深度学习把复杂度留在需要那一层的地方。3.3 从故障分类到健康度打分剩余寿命预测的替代方案理想状态下预测性维护系统应该能给出这台设备还能跑多少天的明确答案。但在真实工厂里剩余使用寿命预测是一个很难的任务因为设备的退化过程受负载、转速、环境温度、润滑状态等多种因素影响而且故障往往是加速退化的早期预测的置信度很低。实践中更稳妥的做法是做一个健康度打分把多维特征压缩到一个0到100的分数区间直观反映设备当前状态和历史正常状态的偏离程度。构建健康度模型的思路是这样的用无监督模型算出样本到正常模式的异常得分对异常得分做平滑处理降低瞬时噪声干扰通过分段函数映射到健康度区间比如异常得分越高、健康度越低设置多级阈值关注分数80、预警分数60、告警分数40。健康度打分的最大好处是对现场操作人员友好。产线工人不需要理解峭度和包络谱看到仪表盘上的绿色黄色红色就能判断设备状态。管理层也能直接看到整条线的整体健康度分布方便安排检修计划。给一个完整训练流程的例子——用孤立森林构建正常状态模型import numpy as np import pandas as pd from sklearn.ensemble import IsolationForest from sklearn.preprocessing import StandardScaler def train_normal_model(feature_df): # 假设 feature_df 只包含设备处于正常状态的特征数据 scaler StandardScaler() X scaler.fit_transform(feature_df.values) model IsolationForest( n_estimators300, contamination0.02, max_samplesauto, random_state42 ) model.fit(X) return scaler, model def health_score(sample_df, scaler, model): # 对实时特征向量打分 X scaler.transform(sample_df.values) anomaly_score model.decision_function(X) # 越高越正常 # 把 decision_function 输出的分数归一化到 0~100 的健康度 min_score -0.5 max_score 0.0 normalized (anomaly_score - min_score) / (max_score - min_score) health np.clip(normalized * 100, 0, 100) return health[0]这里需要注意contamination参数的取值。它表示模型认为训练数据中异常样本的比例。在正常情况下训练数据应该都是正常样本但传感器偶尔会有毛刺或者设备某个瞬间工况波动较大这些都会被当作正常数据的噪声踢出去。我把contamination设为0.02也就是容忍2%的噪声这个值通常够用。如果误报率高可以考虑调低到0.005反之如果线上数据经常出现新的非正常模式可以考虑适当调高。3.4 模型评估工业场景下的指标不能只看准确率算法工程师习惯用准确率、AUC、F1来评价模型但在预测性维护场景里这些指标远远不够。原因是代价不对称漏报一次真实故障可能导致设备损坏、产线停摆甚至安全事故代价巨大而误报一次最多浪费一次巡检人力。所以必须引入代价敏感评估或者直接评估每百小时误报次数和故障检出率两个操作性强且简洁的指标。我做项目的时候会参考以下评估方式离线回放测试拿历史数据切分训练集和测试集测试集中包含已知发生故障的时段验证模型能否在故障发生前提前72小时或24小时捕捉到异常趋势。假阳性率控制正常工况下的数据不应该频繁触发告警一般要求误报间隔大于7天否则维保人员会对告警麻木。提前量分析如果故障已被证实对比第一次告警时间和实际停机时间得出提前预警了多少小时这是业务层最看重的数字。图表方面不是重点重点是数据管道能不能支撑这些评估。项目中一个常见做法是把每次告警事件、告警级别、人工确认结果都记录下来形成告警工单日志。这个日志是后续优化模型最重要的依据稽核人员确认哪次告警是准确的、哪次是误报然后把这些反馈喂回模型做在线学习或迭代训练。4. 边缘推理与动态阈值预测性维护系统能不能用的分水岭4.1 为什么必须把推理放到边缘侧很多工厂的现场网络条件并没有想象中那么好。车间里金属设备大量存在无线信号衰减严重有线网络也经常因环境恶劣而断连。如果把原始振动波形全部回传云端做推理网络带宽和稳定性先会成为瓶颈。更现实的需求是告警必须是低延迟的不能让设备已经异响了几分钟告警还在传输链路的队列里排队。边缘推理的方案是把训练好的模型导出并部署到边缘网关让网关直接对本地采集的特征数据做推理。只有当模型判定需要深入分析时才把原始波形回传给服务端。这种边算边传的模式把这个场景下的数据流量降低了90%以上。例如每台设备每通道20kHz的原始数据一天下来好几GB的流量经过边缘特征提取后只剩不到50MB的特征数据。告警延迟也从秒级降到了百毫秒级。4.2 模型导出与部署ONNX是连接Python和工业边缘的桥梁模型在Python里训练完毕导出成ONNX格式的流程图如下用scikit-learn或PyTorch训练模型用skl2onnx或torch.onnx.export导出到ONNX格式在边缘网关里用onnxruntime加载模型执行推理。ONNX的好处在于它是开放标准几乎所有主流的边缘计算硬件都有对应的运行时支持。用CPU推理的工业网关一般不是太强所以需要做一些优化。可以先从特征工程本身做降维比如保留最重要的20~30个特征去掉冗余。更激进的做法是模型轻量化把孤立森林的子树数量从300棵减少到100棵精度下降通常可以控制在1%左右但推理耗时可以减少60%以上。部署后的监控同样重要。我习惯为边缘推理程序加上一个看门狗如果GPU或CPU占用异常、特征输入异常比如全是NaN自动重启进程同时服务端会收到心跳告警。边缘程序崩溃是最容易被忽视的问题一旦崩溃设备变成盲区而管理者往往会误以为一切正常。4.3 动态阈值固定阈值在真实工况下必然引发误报潮第一次上线预测性维护系统的时候我犯过一个典型的错误全局设了一个固定的健康度阈值80分以下就告警。模型训练时用的是A工况数据比如泵转速在1500转/分左右。到了生产中操作人员根据需要把转速调到2400转/分振动规律完全变化了系统开始疯狂误报。每个值班工程师的手机都被告警轰炸最后大家形成告警疲劳真有故障了也没人看了。这其实就是很多预测性维护项目失败的核心原因阈值没有跟着工况走。解决办法是用动态阈值健康度打分不再是一个绝对分数而是把当前健康度与相同工况下历史健康度分布做比较计算一个标准分或百分位数。实现动态阈值的基本思路是引入工况标签。通过采集设备的转速信号、负载信号或运行模式标识把历史特征数据按工况聚类。每个工况组单独维护一个正常模型和阈值。实时数据先判断属于哪个工况再用对应工况的模型和阈值来判断是否异常。工况切换瞬间不用特别处理因为模型切换后特征分布自然对齐到正确的正常基线。4.4 一个基于百分位数的自适应阈值实现方案这里贴一个比较实用的方案。假设已经有一个设备的历史健康度序列接下来用百分位数法计算动态阈值import numpy as np class AdaptiveThreshold: def __init__(self, lookback_window7200, warning_percentile95, alarm_percentile99): self.scores [] self.lookback_window lookback_window self.warning_percentile warning_percentile self.alarm_percentile alarm_percentile def update(self, score): # 保留最近一段时间内的健康度分数 self.scores.append(score) if len(self.scores) self.lookback_window: self.scores.pop(0) def get_thresholds(self): if len(self.scores) 1000: return None, None # 数据量不足时不告警 warning_th np.percentile(self.scores, self.warning_percentile) alarm_th np.percentile(self.scores, self.alarm_percentile) return warning_th, alarm_th注意这里分数越高越健康的话找的是低百分位数或高百分位数要看分数方向。上面代码假设的是分数越高越健康的体系percentile分位数值越大对应分数越高所以warning_percentile要改成5和1或者用(100 - percentile)。模板代码只是演示思路各系统需要按自己健康度方向调整。我自己用的时候有个附加逻辑动态阈值不是无脑跟随近期数据的如果设备确实在持续退化健康度会一路走低此时百分位阈值也会跟着降低形成窗口效应退化信号就永远告警不出来了。解决办法是设置一个绝对底线阈值比如健康度低于40一定告警不受动态阈值影响。绝对阈值和动态阈值同时判断取更严格的一个作为最终告警条件。这个方案在几个项目里表现都不错。核心思想很直观用设备自身的历史表现作为基准线而不是拿一套外部统一定义的规则去套所有设备因为不同位置的传感器、不同负载工况下振动能量的日常波动范围差异太大了。5. 工厂实际部署时最常踩的四类坑与排查方法5.1 数据不平衡正常样本占比99%异常只在最后5分钟出现预测性维护项目里数据不平衡几乎必然存在。设备多数时间在正常状态运行真正的故障数据往往集中在设备即将损坏前的几个小时甚至几分钟。这样一个数据集如果直接用来训练有监督分类模型模型会很轻松地学到全都预测正常这种偷懒解法准确率还能达到99%以上。我在一个项目里遇到过类似的情况。某减速机的振动数据记录了三个月其中故障数据只有最后46分钟。直接用原始数据训练分类模型测试集准确率99.2%看起来漂亮得很但故障样本的召回率是6.7%。几乎所有故障都被漏掉了。解决数据不平衡的办法有几个对正常样本降采样对故障样本做SMOTE过采样或者在损失函数里给少数类加权重。但这些都是辅助手段最根本的还是要尽可能多地积累故障数据把故障演化过程完整留下来。解决思路也可以换一种放弃监督分类转用无监督异常检测。因为正常样本数据量巨大、分布清晰异常检测模型只需要学习正常模式的边界不需要见过所有故障模式。真实故障模式往往和已知故障都不一样无监督检测方法反而有更强的泛化能力。5.2 传感器漂移模型上线三个月后告警灵敏度明显下降工业传感器在恶劣温度、粉尘、电磁干扰环境下运行时间久了会出现灵敏度下降或基线漂移。加速度计的灵敏度漂移会导致相同振动水平下计算出的RMS值变小于是模型越来越麻木直到设备故障恶化到一定程度才触发告警。排查方法需要先区分是传感器问题还是设备问题。做法是找一个参考点在设备正常停机时采集一段静态数据理论上振动应为零附近。如果静态数据的基线噪声明显高于历史值或者产生明显漂移就可以怀疑是传感器或线缆松动问题。更规范的方式是设置定期标定计划比如每3个月用标准振动源校准一次传感器。当发现传感器状态异常时在数据管道里对该通道打上失效标签让模型忽略此通道的特征避免脏数据喂进模型影响判断。5.3 工况切换引起的误报不是设备坏了是转速变了这类问题在变频设备上非常典型。泵的转速从800转/分升到1450转/分振动能量会上升好几倍但这是正常工作状态的变化不是故障。如果模型没有工况感知能力就会在每一次转速调整后触发误报让现场人员对整个系统失去信任。我采用的方法是在特征里显式加入工况变量比如转速、电流平均值、阀门开度等过程变量。特征集包含两类一是振动、温度、电流等设备状态特征二是转速、负载等工况情境特征。模型训练时工况特征会帮助模型建立不同工况下振动正常范围不同的认知。部署时实时特征向量同样包含工况信息就能在当前工况的基准下评估设备状态。如果工况变量无法直接获取可以用聚类方法从振动特征自身推断工况模式。系统上线初期先跑两周数据用高斯混合模型或KMeans对特征向量聚类把聚类结果作为工况标签附加到数据上。之后再遇到相似的特征模式就能自动识别为同工况。5.4 标签缺失与标注不准最贵的东西不是机器是正确的历史结论到目前为止我遇到最难的问题既不是算法选型也不是阈值调参而是数据标注。故障数据的时间范围到底从哪里算起哪个时间点是故障开始如果故障发生在凌晨三点而设备到早晨八点才被巡检发现那这5个小时算正常还是故障没有一个明确的标注模型训练时就不知道边界在哪里。我的办法是和维修团队建立一套故障事件登记制度。每次设备停机检修维修工单上要求填写设备是否发生故障、故障类型、首次异常时间根据历史数据分析推测、更换的零部件信息。这些工单信息回填到时序数据库形成带标签的故障事件。数据标注这件事不能靠程序员在电脑前猜必须让最熟悉设备的人参与。系统上线后还要建立一个闭环反馈机制。每次模型发出告警巡检人员需要在工单里确认是真实故障设备正常还是工况变化。真实故障回填为故障样本续训练时纳入设备正常则回填为正常样本帮助调整阈值。这个闭环跑起来的标志是误报率随时间推移持续下降模型越来越了解这台设备。6. 从能用到好用告警场景化与运维联动模型告警只是第一步告警之后怎么办一个告警如果不能直接转化为运维动作价值就打折了。我见过不少系统告警推到手机上是没问题的但现场巡检人员一眼看不懂故障出在哪里。这样的系统用几天就被抛弃了。所以在做告警的时候我会把告警信息从健康度低于X翻译成故障模式可能位置建议动作。实现方式是给告警事件附带一个可解释性分析模块告诉现场人员是哪几个特征偏出正常范围。比如外圈故障的特征是外圈特征频率谱峰显著升高包络谱中可以看到故障频率基频及其谐波。把这些内容写入告警内容摘要里值班工程师拿着这条告警就能精准去检查轴承外圈对应位置效率高很多。告警与前端的联动也非常重要。如果工厂已有监控巡检系统比较好的是走告警工单。预测性维护系统推送事件到告警平台生成巡检工单分配给相应的维修班组工单处理结果回填。这样做的好处是彻底打通了状态监测和运维执行。7. 最后再分享一点经验预测性维护系统做到现在我最大的体会是从0到1搭建技术架构往往并不是最难的部分真正难的是让系统在工业现场长期稳定运行。网络会断、传感器会漂移、工况会变、生产计划会调整新问题永远比预期多。做这个方向心态上要把自己从算法工程师切换成系统工程师很多问题解法不在于模型而在于数据链路和运维流程。如果现在让我重新做一个预测性维护项目我第一件事不是选模型而是先花两周时间把历史数据翻个底朝天把每台设备的振动特点、工况变化规律摸清楚和老师傅聊清楚哪些异响是故障、哪些异响是正常。有了这些底数后面的技术工作会顺畅得多。另外如果想快速验证预测性维护的价值建议先选一台故障率最高的设备做试点不要一上来就铺全厂。把一两点做出体型再谈规模复制路径会踏实很多。