2024年7月，我们在唐山一家钢厂做轧机监测项目的第一个月，加速度传感器坏了三个。不是数据质量问题，是物理意义上的坏------普通IEPE传感器标称耐温125°C，而轧机轴承座附近的环境温度，夏天实测62°C，加上设备本体传导的热，传感器内部电子件直接老化失效。
设备科长倒是见怪不怪："你们之前装的？"我说是。"哦，那正常，上一家也是一个月就坏了。"
那一刻我明白了：在钢铁厂做预测性维护，第一个要解决的不是算法问题，是让传感器活下来的问题。这篇就把我这两年在钢厂攒下的环境生存经验捋一捋。
高温：选型、隔热、安装方式一个都不能省
先说选型。轧机、加热炉周边，直接上高温型压电传感器，耐温250°C起步的陶瓷剪切型，别心疼那点差价------普通传感器三四百，高温型的两千多，但坏一次的代价是停机爬架子换传感器，人工加误工远超差价。
安装方式也有讲究。磁吸安装座方便，但高温下磁力衰减，40多度就开始打滑。我们吃过亏：传感器滑落之后贴在设备防护罩上，采回来的"振动数据"其实是罩子的嗡嗡声，还据此误报过一次故障。后来轧机上全部改螺纹安装+高温安装脂，再垫一片不锈钢隔热垫，把传导热隔掉一截。
风冷是常规操作。给传感器加个压缩空气吹扫的护罩，一举两得：降温顺带吹走粉尘。就是得多花一路气源，仪表风从哪接、谁出改造费，进场之前就得跟厂里谈清楚，这种事到了现场再谈就晚了。
粉尘：IP67只是入场券，"假故障"才是大坑
钢铁厂的粉尘量级和一般制造业完全不是一个概念，烧结、高炉区域，防护不够的设备两周就能糊一层。IP67是底线，但我们踩过的更深一个坑是：粉尘不直接弄坏传感器，它制造"假故障"。
有个配料皮带的电机，温度监测突然持续走高，眼看要触发报警。运维爬上去一看------散热风罩被粉尘糊死了，电机本身没坏，是散热失效。你可能会说，这报警也不算错啊，再不管电机迟早烧。对，但监测系统区分不了"电机自身故障"和"环境导致的散热恶化"，这两种情况的处置措施完全不同，工单派错了人，人家白跑一趟，几次之后一线就不信系统了。
所以后来我们的报警逻辑里加了环境关联规则：电机温度告警先联动看同区域其他设备的温度趋势------一片都涨，先怀疑环境因素（散热、季节、负荷）；单点独涨，才指向设备自身问题。就这么一条规则，把电机温度类的无效工单砍掉了六成。
传感器本体每季度人工巡检一次，拿压缩空气吹扫膜片和线缆接头。这个制度看着原始，比任何高端算法都保命。
强电磁：钢厂里信号干净是一种奢侈
钢厂是强电磁环境的重灾区：大功率变频器、中频炉、直流母线，几百伏到几千伏的开关动作此起彼伏。我们第一版采集链路用的普通屏蔽双绞线+单端采集，信号里全是开关毛刺，频谱底噪比干净环境高20个dB，特征峰直接泡在噪声里。
后来改了三件事：屏蔽双绞线双端等电位接地------注意是接在同一个接地排上，如果两点接地存在电位差，反而引入环流，这是另一个坑；采集改成差分输入；关键长距离传输直接上光纤，光电隔离之后什么电磁干扰都过不来。
无线方案在这里基本歇菜。我们试过用LoRa传高炉平台的测点数据，丢包率高达15%，车间钢结构对2.4GHz和470MHz的衰减比想象中狠得多。最后的架构是有线工业以太网+边缘计算盒子就地预处理：RMS、峭度、包络谱峰值这些特征值上传，原始波形本地存储按需调取。这就是现在常说的云边协同，只不过在钢厂，它是"不得不"的选择，不是赶时髦。
传感器自己也要做"预测性维护"
最后这条是我认为最值钱的经验：监测传感器本身也会失效、漂移、被干扰，得给它们也装一套"健康监测"。我们写了个很朴素的数据质量巡检脚本，每天凌晨跑一遍：
python
import numpy as np
import pandas as pd
def check_sensor_health(df: pd.DataFrame, col: str, fs: float) -> list:
"""传感器数据质量巡检，返回问题列表
df: 当日数据(时间索引); col: 测点列名; fs: 采样率
"""
issues = []
s = df[col].dropna()
# 1. 卡值检测：连续1小时标准差近零，传感器大概率坏了或线缆脱落
win = int(fs * 3600)
roll_std = s.rolling(win).std()
if (roll_std < 1e-4).sum() > len(s) * 0.3:
issues.append(f"{col}: 疑似卡值(输出长时间无变化)")
# 2. 灵敏度漂移：本月与上月的日RMS中位数对比，漂移超20%告警
# 注意剔除停机时段，只用"相似工况"的数据做对比
# 3. 丢包检测：按采样间隔构建完整索引，缺失率超5%说明链路有问题
full_idx = pd.date_range(df.index.min(), df.index.max(),
freq=f"{1/fs}s")
loss_rate = 1 - len(s) / len(full_idx)
if loss_rate > 0.05:
issues.append(f"{col}: 丢包率{loss_rate:.1%}")
return issues踩坑提醒：卡值检测的窗口要卡在设备运行时段。钢厂有检修班，检修时整条产线停机，那时段的数据全是平线，会把正常数据误判成传感器卡值。我们从产线PLC拿运行状态位做了过滤才解决。做环境监控，永远要问一句：这段数据是设备"睡了"，还是传感器"死了"？
这套监控上线后抓到过一起典型的灵敏度衰减------某个测点半年内RMS中位数悄悄掉了22%，是压电元件老化。要不是脚本天天盯着，等它彻底失效，那个位置就成了监测盲区，而且是悄无声息的那种。
最后说两句
回头看，钢铁厂这两年教会我的事是：预测性维护的可靠性上限，不是模型准确率决定的，是数据可用性决定的。而数据可用性，是传感器选型、安装工艺、布线接地、日常巡检这些"不性感"的工程细节撑起来的。
算法工程师纸上谈兵，谈不出一个能活过夏天的传感器。去现场，摸一摸滚烫的轴承座，你就什么都懂了。