钢厂测温这事儿说起来简单做起来是真的闹心。炉子旁边一百多度是常态设备表面还全是灰电气柜里电磁干扰又重用便宜的测温枪靠人跑数据记完就忘根本没法形成趋势。更要命的是报警全靠老师傅的经验——等他觉得“不对劲”的时候往往设备已经出问题了。后来我们干脆整套搞了一个“钢厂测温一体化监控平台”把温度传感器、采集网关、中心监控软件全串起来不用人到现场温度变化曲线和告警都自动推到大屏上。这篇文章就把我们踩过的坑和最终落地的方案完整分享一下给做工业监控、设备维护、仪表自动化的朋友一个能直接参考的模板。1. 项目背景与整体设计思路1.1 钢厂测温场景为什么这么难搞先说现场环境。很多没去过钢厂的人以为测温就是拿个枪对着设备“滴”一下真实情况完全不是这样。第一个问题是环境温度过高。设备本身温度可能只有几十度但周围热辐射特别强普通红外测温枪对着目标测量时镜头里混进大量背景辐射测出来数值忽高忽低。以前我们试过用手持红外测温仪测辊道轴承座同一台设备早上测和中午测能差十几度根本不是设备变了是环境变了。第二个问题是粉尘和水汽。钢厂车间里氧化铁皮粉尘很重还会飘油雾。红外测温仪的镜头一旦被污染发射率标定就全乱了测出来的温度完全不具备参考性。热电偶和热电阻虽然不怕粉尘但在震动大的地方容易断线接口也容易松。第三个问题是电磁干扰。车间里大电机、变频器、电焊机到处都是普通传感器信号线如果屏蔽没做好采集到的温度信号经常出现尖刺上一秒80度下一秒能冲到130度然后又落回82度。这种数据你敢拿去触发联锁停机吗肯定不敢。所以这个项目从一开始就不是简单“加几个温度探头”而是要把整个测温链路统一设计用什么传感器、怎么接线、怎么采集、怎么传输、怎么存储、怎么展示、怎么告警全部作为一个整体来考虑。1.2 一体化监控平台的分层架构我们最终采用的分层架构从底到顶一共四层感知层温度传感器包括PT100热电阻、NTC热敏电阻、光纤测温主机和红外测温仪。传输层现场数据采集器通过RS485、Modbus TCP、4~20mA等方式把传感器数据统一采集再通过工业交换机或5G工业网关上传。平台层采用Prometheus作为监控核心负责时序数据存储、告警规则管理配合Grafana做可视化大屏。应用层报警通知、历史曲线查询、设备健康度分析、报表导出。这套架构最大的好处是每一层都可以独立扩容。比如后期想加一组测温点只需要在感知层加传感器传输层加一台采集器平台层的Prometheus配置里增加一条采集任务就行不需要推翻重来。另外一个关键是平台层选Prometheus而不是自己写一套数据存储原因很简单——普罗米修斯Prometheus本身就是为监控而生的时序数据压缩、自动发现、告警管理这些能力都是现成的。我们在服务器上部署了node_exporter监控服务器本身的CPU、内存、磁盘同时也用自定义exporter采集温度数据一套平台同时解决“测设备温度”和“监控平台自身健康”两个问题。这话听起来像套话但在工业项目里真不是小事平台运行三个月后很多莫名其妙的采集中断最后都是先通过Prometheus发现服务器磁盘满了或者CPU跑满才追查出来的。1.3 传感器方案选型热电偶、PT100、NTC、光纤怎么选很多新手一上来就问“什么传感器好”其实没有绝对的好坏只有适合场景的差异。我们在不同部位用了不同的测温方案核心原则是接触式测温看精度和稳定性非接触式测温看响应速度和能不能接触。传感器类型测温范围优势劣势典型应用位置热电偶K型/S型-200℃~1300℃测温上限高、响应快、成本低精度相对低、需要冷端补偿炉壁、烟道、钢水包外壳PT100热电阻-200℃~600℃精度高、稳定性好、互换性强响应慢、不耐高温轴承座、电机绕组、液压站油温NTC热敏电阻-50℃~300℃灵敏度高、成本最低、响应快非线性严重、测量范围窄电气柜环境温度、电缆接头表面荧光光纤测温-40℃~200℃抗电磁干扰、绝缘性好、适合高压成本高、测点分散时造价贵高压开关柜触头、母线连接处红外测温仪取决于型号非接触、响应快、可测运动目标受粉尘水汽影响大、发射率难定连续铸坯表面、轧辊表面现场配电室里我们还装了NTC探头测环境温度用分压电路加采集器直接读成本极低但它对电磁干扰比较敏感信号线必须用屏蔽双绞线而且分压电阻的精度直接决定测温精度千万不能随便找两个电阻就焊上去。2. 核心技术拆解测温电路与传感器原理2.1 PT100四线制测温电路把引线电阻的影响彻底干掉PT100的测温原理是铂电阻的阻值随温度近似线性变化0℃时阻值100欧姆100℃时阻值138.51欧姆。问题是现场传感器到采集器之间距离往往有几十米甚至上百米铜导线本身就有电阻两线制接法下线电阻会直接叠加到铂电阻阻值上造成明显误差。两线制为什么不行假设两根线各5欧姆串联进回路就是10欧姆对应PT100大约25℃的误差这已经远超工艺允许范围了。三线制能抵消一部分线电阻影响但在长距离、大温度变化现场钢厂车间昼夜温差可能就超过30℃三线制平衡效果也不理想。我们最终全部采用四线制接线原理很简单两根线给PT100施加恒定的激励电流另外两根线只负责测量电压因为测量回路里几乎没有电流流过所以线上不产生压降测到的电压就等于PT100本身两端的电压线电阻再大也没影响。接线时要注意几个细节恒流源激励电流一般取0.5mA~1mA。电流太小信号电压弱容易被干扰淹没电流太大PT100自身发热产生自热误差。我们在采集器上统一配置为1mA实测自热误差控制在0.05℃以内。四根线的颜色经常搞混我们约定红色接激励正黑色接激励负白色接测量正蓝色接测量负并在端子排上贴标签。不要相信设备出厂默认颜色每次接线后必须用万用表通断测试确认线序。屏蔽层只能单端接地一般接到采集器侧的地线端子排上。如果两端都接地会在屏蔽层中形成地环路电流反而引入更多干扰。2.2 NTC热敏电阻测温电路便宜但绝不简单NTC热敏电阻是负温度系数温度升高阻值下降。我们选的是10K NTCB值395025℃时标称阻值10K欧姆成本不到一块钱用在电气柜环境温度监测上非常划算。但NTC的阻值-温度关系是强烈非线性的不能像PT100那样用线性公式一算完事。工程上常用的做法有两种一是查表法把电阻值分成大量细密的小区间查表插值二是用Steinhart-Hart方程计算1/T A B·ln(R) C·(ln(R))³其中A、B、C是传感器厂商给出的校准系数。我们在软件里做了查表加线性插值每1℃一个表项实际测试在0~100℃范围内误差可以控制在±0.5℃以内对于电气柜监测来说完全够用。NTC采集电路一般是分压结构电源经过一个精密电阻R0再经过NTC到地采集NTC两端的电压。这里有几个关键选型分压电阻R0取10K欧姆与NTC在25℃时的阻值相同这样在常温附近电压变化率最大分辨率最高。R0必须用低温漂、1%精度的金属膜电阻或者更好一点的精密电阻。有些项目为了省钱用普通5%碳膜电阻结果电阻值随温度漂移测出来的温度自然是不准的。采集模块的ADC参考电压要稳定最好使用独立的精密参考电压源不要直接从开关电源5V上分压否则电源波动会直接变成测温误差。软件里要做滤波NTC响应快但也容易把干扰信号直接采进来。我们的做法是连续采三次去掉最大值最小值取中间值再把中间值做滑动平均。2.3 光纤测温原理与钢厂高压场景的应用钢厂里面很多测温点不能接触、不能停电比如高压开关柜的母排接头、电缆中间接头、变压器铁芯。这些东西一旦发热到一定程度就是严重事故但电气柜内部强电磁环境普通温度传感器加上金属导线本身就是一种隐患。我们最终在高压开关柜里用了荧光光纤测温效果非常稳。光纤测温的核心原理有两个方向一是分布式光纤测温基于拉曼散射。一束激光打进光纤光纤内部会产生散射光其中反斯托克斯光的强度对温度敏感。通过测量散射光返回的时间和强度变化就能算出光纤上每一点的温度一根光纤可以测出几公里路径上成千上万个点的温度。这个适合电缆隧道、长距离输送带等需要连续监测的场景。二是荧光光纤测温利用荧光物质的余辉衰减时间与温度的关系。激励光源发出紫外光荧光物质受激发射出荧光温度越高荧光衰减越快。测出衰减时间常数就能反推出温度。因为光纤本身是绝缘材料完全不导电所以特别适合高压电气设备的测温。我们最开始在现场敷设光纤时犯过一个典型错误光纤弯曲半径太小导致光路损耗急剧增大测点数据出现异常跳变。后来把所有小于30mm的弯曲全部重新走线问题立刻消失。光纤和连接器要保持清洁插拔时千万不要用手摸端面粉尘油污一旦附着上去光功率下降非常明显测温数据会整体偏高。3. 平台软件架构与Prometheus监控3.1 数据采集与协议转换把现场设备变成统一数据源现场传感器种类杂协议也杂。PT100和NTC接在采集器上采集器对外提供Modbus RTU接口红外测温仪有些带4~20mA模拟输出光纤测温主机则是通过网口输出Modbus TCP数据。我们把所有数据统一汇总到一台工业采集网关网关内部跑一个Node-RED流程把不同协议的数据轮询读取之后转换成统一的JSON结构再通过HTTP推送到平台。为什么选Node-RED因为它调试方便流程改起来快而且支持Modbus、MQTT、HTTP各种节点对我们这种传感器种类多的项目非常友好。网关推送数据之后平台侧用一个自定义exporter接收缓存最终暴露给Prometheus抓取。这里涉及到一个关键设计采集链路上尽量少用Pushgateway除非迫不得已。Prometheus的原生模型是“拉模式”也就是Prometheus主动去采集目标接口这样服务端能判断目标是否存活。Pushgateway适合短生命周期任务但工业场景下网关需要长期在线所以我们让Prometheus直接抓取自定义exporter的HTTP接口只要数据延迟超过30秒Prometheus马上能感知到目标丢失告警系统立即触发。3.2 时序数据存储与服务器资源监控一个平台管两摊事平台核心用的就是普罗米修斯Prometheus。我们部署了三个核心组件Prometheus Server负责时序数据抓取、存储、告警规则计算。node_exporter监控每台服务器的CPU、内存、磁盘、网络。自定义temperature_exporter把采集网关推送的温度数据转换为Prometheus指标。配置Prometheus时最核心的就是prometheus.yml里的抓取任务。我们的配置大概是这样global: scrape_interval: 15s evaluation_interval: 15s alerting: alertmanagers: - static_configs: - targets: [alertmanager:9093] rule_files: - /etc/prometheus/rules/*.yml scrape_configs: - job_name: node static_configs: - targets: [node-exporter:9100] labels: instance: platform-server-01 - job_name: temperature static_configs: - targets: [temperature-exporter:8080] labels: instance: steel-plant注意scrape_interval这里我们设的是15秒钢厂测温告警要求相对没那么苛刻15秒足够。如果你有特别关键的设备可以单独建一个job把scrape_interval改成5秒。另一个容易被忽略的点是数据保留时间。Prometheus默认只保留15天数据但设备温度需要做月度趋势分析15天远远不够。我们在启动参数里加了--storage.tsdb.retention.time180d保留半年数据。如果想存更久建议把旧数据转存到对象存储或使用Thanos但那套东西对工业项目来说有点重了半年基本够我们用。3.3 告警规则设计与可视化大屏不只看还要“管得住”告警是这套平台的价值所在。我们不是简单设一个“超过80度就报警”而是设计了三级告警体系级别触发条件通知方式处理要求预警连续5分钟超过预警阈值如75℃企业微信/群消息当班人员查看趋势安排巡检确认报警连续3分钟超过报警阈值如85℃短信 电话语音通知设备主管必要时调整工艺或停机严重连续1分钟超过严重阈值如95℃电话 现场声光报警立即应急处置告警规则文件rule.yml的写法大概是这样的groups: - name: steel_temperature_alerts rules: - alert: BearingHighTempWarning expr: steel_temperature{bearing_typeroll} 75 for: 5m labels: severity: warning annotations: summary: {{ $labels.device_name }} 轴承温度预警 description: 当前温度 {{ $value }}℃已持续超过5分钟。 - alert: BearingHighTempCritical expr: steel_temperature{bearing_typeroll} 95 for: 1m labels: severity: critical annotations: summary: {{ $labels.device_name }} 轴承温度严重超标 description: 当前温度 {{ $value }}℃立即检查设备。这个配置文件里有几个细节值得展开for参数是“持续时间”它的作用非常大。工业现场温度瞬时波动很常见如果一超过阈值就报警一天能报几百条。设置for: 5m之后必须持续5分钟都超过阈值才会触发告警能过滤掉大部分瞬时毛刺。expr表达式里可以用 75或者 75建议用因为精确等于75℃这种临界点在现实中几乎不存在但是为了严格起见用还是其实差别不大。告警消息里的{{ $labels.device_name }}是动态变量会自动替换成触发告警的那台设备名。千万别在告警文案里写死了设备名不然换一台设备你也得改一次配置。可视化方面我们用Grafana做了两个大屏。一个面向车间操作室展示各关键设备的实时温度、运行状态红色闪烁表示告警另一个面向办公室管理人员展示全天温度趋势、告警统计、设备健康度评分。Grafana的图表模板非常多直接把Prometheus数据源接上选“Time series”面板类型配上模板变量按设备筛选操作起来并不复杂。4. 部署落地实操从接线到上线4.1 现场设备安装与接线清单别让细节毁了整个系统传感器安装的正确性直接决定系统能不能用。我们总结了一份现场安装清单每次新增测点都按这个执行踩坑明显减少。首先是PT100的安装测温点表面要打磨干净去掉氧化铁皮和油污确保传感器探头与被测面紧密贴合。探头安装孔里要涂导热硅脂不是为了“润滑”而是填补空气间隙减小热阻。空气的导热系数极低如果不涂硅脂接触面会有几度的温差。固定螺栓不要拧太紧见过有人把PT100探头拧到外壳变形结果阻值异常温度显示乱跳。一般手用力拧紧后再用扳手带90度即可。线缆要固定好不能悬空晃动。钢厂设备震动大悬空的线缆时间长了接口处的铜丝会折断这个故障特别隐蔽外观看不出问题但温度数据会间歇性丢失。NTC探头的安装相对简单但有一条铁律探头不能直接暴露在强气流中。电气柜里如果正好有风扇吹着NTC测的是风温而不是柜内平均温度数据偏低。我们把NTC探头装在一个带孔的防尘罩里既通风又不被直吹。光纤测温的敷设是整个项目里返工最多的环节。除了弯曲半径问题光纤跟动力电缆不能同管敷设。动力电缆启动时的大电流会在周边产生强电磁场虽然光纤本身不受电磁干扰但光纤中的光信号在转弯处损耗本就不小如果再把光纤和动力电缆绑在一起机械振动和热胀冷缩会把光纤慢慢拉断。光纤一定要单独走金属线槽并且每隔一米用扎带固定。4.2 平台部署步骤用Docker Compose半小时搭起来软件部署我们用的是Docker Compose整套平台由四个容器组成Prometheus、Grafana、Alertmanager、自定义温度采集exporter。为什么用容器因为工厂环境里服务器操作系统五花八门如果直接装二进制依赖问题能折腾一整天。容器化之后只要装了Docker一条命令就能启动整套环境。部署的基本流程是这样的第一步安装Docker和Docker Compose插件然后新建项目目录。mkdir -p /opt/steel-monitor/{prometheus,grafana,alertmanager} cd /opt/steel-monitor第二步创建docker-compose.yml文件version: 3.8 services: prometheus: image: prom/prometheus:latest container_name: prometheus ports: - 9090:9090 volumes: - ./prometheus:/etc/prometheus - prom-data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.retention.time180d restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDyour_strong_password volumes: - grafana-data:/var/lib/grafana restart: unless-stopped depends_on: - prometheus alertmanager: image: prom/alertmanager:latest container_name: alertmanager ports: - 9093:9093 volumes: - ./alertmanager:/etc/alertmanager command: - --config.file/etc/alertmanager/alertmanager.yml restart: unless-stopped temperature-exporter: build: ./exporter container_name: temperature-exporter ports: - 8080:8080 restart: unless-stopped depends_on: - prometheus volumes: prom-data: grafana-data:第三步编写温度采集exporter。我们用Python写了这个exporter功能很简单启动一个HTTP服务每次Prometheus来抓取时从本地缓存读取最近一次网关推送的温度数据然后以Prometheus指标格式返回。之所以这么设计是因为Prometheus的抓取是周期性的15秒一次而网关那边推送的频率可以设为10秒一次这样即使某次抓取和推送正好错开数据也只延迟几秒钟。第四步登录Grafana添加Prometheus数据源地址填http://prometheus:9090然后导入模板或手动创建Panel。整套平台从零开始熟练的话30分钟能上线。但上线只是开始真正花精力的是后面对接现场设备和调告警规则。4.3 关键配置与参数计算以轴承温度告警阈值为例告警阈值不能拍脑袋定一定要结合设备历史数据和工艺要求。我们以轧机轴承为例说明阈值推算过程。先查看历史数据在Grafana上拉出过去两周的轴承温度曲线观察正常运行温度范围。假设正常工况下温度波动在55℃~70℃之间峰值偶尔到72℃。那么预警阈值取正常波动上限再加5℃左右余量设为75℃。为什么加5℃而不是直接设72℃因为夏季气温升高或者生产负荷加大的时候温度会整体上浮3℃~5℃但是设备依然安全不能动不动就报警。报警阈值预警阈值加10℃设为85℃。这个温度说明轴承润滑或磨损已经出现异常需要人工干预。严重阈值报警阈值加10℃设为95℃。超过这个值轴承很可能已经在干摩擦状态继续运行会损坏必须停机检查。这三个阈值之间有梯度递进关系不会一下子就从正常跳到严重给操作人员留出判断和处理时间。另外还要算一下采集精度的预算。假如PT100的误差是±0.3℃采集器的电压测量误差折算成温度是±0.2℃线缆引入的误差由于四线制可以忽略网关数据转换误差是±0.1℃整个链路累计误差约±0.6℃。这个精度远小于阈值之间的间隔10℃所以告警判断是可靠的。如果整个链路误差有±5℃那就得把阈值间隔加大否则告警本身就没意义了。5. 常见问题与排查技巧实录5.1 温度读数不准或跳变先接线再算法现场最常遇到的坑就是温度数据不准或者跳变。我们在项目上总结了一套由易到难的排查顺序。第一步查接线。用万用表在采集器端测量PT100的电阻值跟传感器端的阻值对比如果两边差得比较多说明线上有接触电阻或断线。注意不要用普通万用表的通断档去测长距离线缆因为线缆有电阻通断档会误判。要用欧姆档记录实际阻值。第二步查屏蔽接地。如果使用万用表测下来接线没问题但数据依然跳动十有八九是屏蔽层接地没有做对。屏蔽层必须单端接地而且接地点不能选在变频器附近否则地线上的噪声会直接耦合进信号。我们后来把所有采集器侧的屏蔽层都接到了单独的接地铜排上和动力地严格分开数据跳变问题少了80%。第三步查算法层面。信号硬件没问题数据还是偶尔出现离群值需要检查滤波策略。比如前面提到的NTC采集如果只用一次采样值干扰导致的尖刺就会直接进入数据库。我们改为“采三次取中间值再滑动平均”后效果立竿见影。5.2 数据断断续续与掉线处理“该丢的时候丢了”的问题工业现场不是理想网络环境交换机重启、网线松动、网关死机都是常态。数据掉线不可怕可怕的是掉线之后不知道等发现了数据已经丢了半天。我们在Prometheus侧的解决办法是监控采集目标本身的状态。Prometheus内置的up指标等于1表示抓取成功等于0表示抓取失败。我们针对这个指标也设置了告警规则- alert: ExporterDown expr: up{jobtemperature} 0 for: 2m labels: severity: critical annotations: summary: 温度采集目标离线 description: Prometheus 无法从 {{ $labels.instance }} 获取数据请检查网络和采集器状态。这块还有一个容易被忽略的细节网关侧要做数据缓存。我们要求采集网关在断网期间至少缓存1小时的数据等网络恢复后按顺序补传。否则断网半小时这半小时的温度就是个空白对于事后分析来说这是个致命的盲区。另外Modbus RTU轮询要注意超时时间设置。现场如果挂了很多台采集器一台设备响应慢会拖累后面所有设备。我们把网关的Modbus超时设为800毫秒如果某台设备连续3次超时就跳过这一路并记录日志而不是一直卡在那里等。5.3 告警轰炸如何让报警真正“有价值”告警系统上线第一周我们差点被狂轰滥炸的告警短信搞崩溃。原因很简单阈值设置不合理和告警恢复通知过于频繁。后来总结了三个教训教训一是告警必须做持续延时滤波。用前面的for: 5m、for: 3m参数可以过滤掉大部分瞬时波动。但如果你用的是其他监控平台也要寻找类似功能千万不要一超过阈值就触发。教训二是告警恢复通知要合并。Alertmanager默认会在告警恢复时再发一条“恢复”通知但如果同一时间段内有多条告警恢复每个都发短信那电话都得被打爆。我们在Alertmanager配置里设置了group_wait和group_interval把通知合并成批次发送同时把恢复通知的渠道降级为群消息不再发短信。教训三是告警升级机制要人工复核。我们给严重告警加了30秒的人工确认窗口现场操作人员收到“严重告警”后需要在监控大屏上点击“确认处理”。如果30秒内没人确认Alertmanager自动升级为电话通知值班主管。这个机制防止了人员休假时告警无人响应的局面。6. 避坑经验与后续优化方向这套平台上线后的效果非常明显关键设备温度数据实现了连续记录告警响应时间从以前的小时级缩短到分钟级设备故障导致的非计划停机明显减少。但做这个项目最大的收获不是技术本身而是对工业监控这件事的认识。第一个体会是监控平台做得再漂亮如果底层测温数据不准一切都是白搭。我们花在传感器安装、抗干扰处理上的时间比写代码的时间多得多但事实证明这些投入是值得的。数据源头错了后面做再多的趋势分析、机器学习也都是垃圾进垃圾出。第二个体会是阈值设置一定要结合历史数据不要拍脑袋。新系统上线后先跑两到三周积累足够的正常工况数据再根据数据分布去定阈值。我们前期的告警轰炸本质原因就是阈值设置得太激进了。第三个体会是工业现场的IT系统一定要考虑防呆设计。比如给传感器端子贴标签、给线缆做颜色管理、在代码里写清楚设备注释这些细节平时看着不起眼但半年后系统出问题你翻笔记的时候就知道有多重要了。后面我们还在规划两个扩展方向。一个是把温度数据和工艺数据做关联分析比如把轴承温度和轧制速度、冷却水流量放在一起建模尝试提前预测轴承失效。另一个方向是给移动设备比如钢水罐车上加装无线测温模块用LoRa或5G把数据传回平台解决移动场景下不好布线的问题。最后分享一个小技巧做工业测温项目一定要提前规划好“测试工装”。我们现场常备一个小型干井炉作为温度基准源每次校准传感器或者排查故障时先把传感器插进干井炉看平台读数是否和设定温度一致。这个操作看起来简单但能帮你快速区分是哪一段出了问题——是传感器坏了、线缆断了、还是平台配置错了。有了这个基准排查效率提升不是一点半点。