简介石化行业人工智能巡检解决方案PPT围绕石化企业安全巡检痛点面向安全管理人员、生产运维主管及AI解决方案工程师。内容先梳理人工巡检面临的人身安全风险、效率瓶颈、判断标准差异与数据散乱难题也指出监控系统事后追溯和主控与现场科技落差问题随后按智能安防、智能巡检、油气田开采、场站、油气传输、炼化厂区等场景给出基于AI识别与告警联动的解决方案并附系统架构、轨道/轮式机器人、无人机、智能头盔等建设路径。演示文稿共5个章节配有案例场景和石化行业定制算法介绍图表完整、逻辑闭环适合项目论证、方案汇报或行业培训。资源为1个pptx演示文档大小约46.23MB已有76人学习浏览可作为石化智能化巡检选型与建设的重要参考。1. 石化行业人工智能巡检到底该“看”什么炼化装置区一天要“找”的东西可真没法靠人眼数过来法兰垫片渗油、压力表指针卡滞、静电接地线没夹好、夜班工人站进了危险区域。石化行业人工智能巡检在大多数项目里第一步解决的不是“智能”而是把这些零散的视觉问题统一成一套固定摄像头、挂轨机器人、无人机平台能共用的识别语言。决定方案能不能落地的往往是四件事感知目标、模型选型、误报治理、验收指标。下面直接按这四件事往下推目标是让没有专职算法团队的小项目组也能照着把原型搭起来。搞石化的人不需要一个会聊天的模型需要的是一个不会漏事的眼睛——把每一次发现变成工单把每一次误报变成数据。这套方案适合炼化企业设备管理、安全环保、信息化部门以及做工业视觉落地的实施工程师。2. 石化巡检 AI 的感知目标与模型选型为什么是多任务小模型任何一份像样的石化巡检方案开头都该先回答“看什么”。这决定了摄像头装在哪、镜头焦距选多少、模型用什么任务、报警阈值按什么调。把常见需求整理成一张表实施时直接照着它跟工艺人员逐条过能让需求会议缩短一大半。2.1 巡检目标清单AI 用什么能力识别目标典型现场形态AI 任务类型备注跑冒滴漏法兰、机封、管口渗油渗液目标检测 / 分割慢速滴漏必须配合时序聚合仪表读数指针压力表、数显温度计OCR / 指针回归表盘反光是误报主因液位磁翻板、玻璃管液位计语义分割对背景色差敏感需按设备调参人员防护安全帽、工作服、禁区闯入目标检测 属性分类视角不同穿戴识别难度差异很大设备状态阀门开关、电机运行灯、皮带跑偏目标检测 / 状态分类同一类设备在不同装置的“正常”外观并不一致环境异常明火、烟雾、积水、蒸汽泄漏目标检测 / 背景建模容易和自然蒸汽混淆需特殊规则过滤这张表的作用不是给算法看而是给工艺和设备人员看的。他们会告诉你哪个目标只会在夜班出现哪个管线区域冬天会结霜哪个压力表贴的位置天然反光。这些信息最后都会变成模型训练样本的标签规则和告警触发条件也是炼化装置智能巡检系统最原始的“需求规格”。方案里的技术选型如果跳过了这张表后面大概率会在现场返工。2.2 为什么固定场景选“多任务小模型”而不是通用大模型石化领域这两年被“人工智能”“大模型”的名词裹着走但真正生产侧要的是确定性和低延迟。同一个画面里同时出现渗油点、人员安全帽和仪表读数用一个大而全的模型统一输出是低效的更常见的做法是场景拆解跑冒滴漏用目标检测仪表用 OCR人员行为用分类网络最后在一个事件引擎里汇合。每个模型都小、都专现场工程师能看懂它的输入输出出问题也能立刻定位是感知层还是聚合层。我一般会强调一个原则小模型负责“判断这帧像不像”规则负责“该不该触发告警”人工复核负责“最后拍板”。生成式模型或大模型在石化巡检里的价值不在感知而在后续把事件数据整理成可读记录、把复核意见转成自然语言的处置说明属于场景数据的再利用。这套“感知-聚合-工单-复核”链路本质上是一个不需要大模型也能转起来的行业智能体。提示方案里如果堆了超过两个“大模型”先问问自己它们分别承担什么责任。说不清的那一个通常会在上线后变成新的故障点。2.3 数据冷启动DCS 报警、历史录像和工单也能成为训练集新装置上 AI 巡检最头疼的是没标注数据。第一版模型不需要一开始认全所有目标可以从 DCS 已有的报警记录和工艺人员的历史工单时间入手。比如 DCS 在某个时段记录了压力波动或泵出口温度异常就在对应摄像头的录像里按时间窗截取一段作为“疑似异常片段”先跑一个预训练检测模型生成候选框再让人在框上确认或纠正。这种做法的本质是用历史弱标签建立粗糙的候选集再用主动学习挑模型置信度低、或现场复核有分歧的帧去精标。第一轮标注量控制在 3000 到 5000 张投入产出比最高目标是小模型先把误报压到每天个位数再逐步扩大样本。直接拿公共数据集来做石化巡检效果通常很差滴漏的油往往只有一小片反光区域公共数据集里根本没有这种负样本。模型在装置现场认识到的是经过现场光照、角度和背景调制过的“专有视觉词汇”不能指望一次预训练覆盖。3. 用 OpenCV YOLO 搭建石化巡检最小原型从 RTSP 流到事件告警3.1 硬件选型与部署位置边缘盒子和后端服务器怎么分石化现场的摄像头普遍支持 RTSP 和 GB28181取流本身不是难点难在算力放哪。防爆区里不允许随便放计算设备常见做法是摄像头画面统一回到装置区外的机柜间边缘盒子或 GPU 服务器部署在机柜间如果需要无人值守响应就在边缘盒子上直接完成推理只把事件和图片上传到中心平台。挂轨式巡检机器人、轮式机器人、无人机巡检平台广义上都是具身智能在工业场景里的落地形态它们的视频流最后也统一接入同一个事件引擎方便做时间对齐和联合复核。选型参考单路 1080p 视频抽帧检测一颗 Jetson Orin NX 或一块低功耗推理卡能扛 8 到 16 路如果包含仪表读数和复杂语义分割建议降到 4 到 8 路或者换成显存更大的推理卡。巡检机器人端通常用移动端推理框架把模型导出成 TensorRT 或 OpenVINO 的 IR 格式单帧推理延时控制在 80 毫秒以内。这里要特别注意边缘设备只做感知不直接发 DCS 联动指令告警进入确认队列由值班员在工单里确认后才执行下一步动作。3.2 用 OpenCV 读 RTSP 流抽帧、ROI 与预处理设备清单和取流地址确认后第一段代码就是“把视频流喂给检测模型”。建议先在本地把一段现场录像存成 mp4 调试稳定后再切到 RTSP 实时流。import cv2 # 先用 VLC 或 ffprobe 确认 RTSP 地址并把地址替换到这里 stream_url rtsp://user:pass192.168.1.50:554/Streaming/Channels/1 cap cv2.VideoCapture(stream_url) FRAME_INTERVAL 15 # 每 15 帧取 1 帧25fps 时约为每秒 1.6 次 frame_id 0 roi_mask cv2.imread(roi_mask.png, cv2.IMREAD_GRAYSCALE) # 和视频同尺寸目标区域为白 while True: ret, frame cap.read() if not ret: break frame_id 1 if frame_id % FRAME_INTERVAL ! 0: continue # 只保留 ROI 内的画面减少天空和通道对模型的干扰 if roi_mask is not None: frame cv2.bitwise_and(frame, frame, maskroi_mask) process_frame(frame) # 见 3.3 节抽帧间隔是石化项目里第一个要调的参数。间隔太大会漏掉瞬间冒烟或滴落的液滴太小会让算力浪费在大量重复帧上25fps 下取 10 到 30 之间比较常规。ROI 掩膜是最经济的规则前置把栏杆、天空、人行通道这些固定区域直接屏蔽模型只在一个相对干净的局部画面里做检测。掩膜要由现场安装人员手工在首帧上画画完之后跟工艺人员确认一次防止把真实的泄漏点位框在外面。3.3 用 YOLO 做目标检测参数怎么调模型建议用 YOLOv8n 或 YOLOv8s 起步权重用现场数据微调过。推理部分的代码很直接但参数有讲究。from ultralytics import YOLO TARGET_CLASSES {2: 滴漏, 7: 明火, 0: 人员} # 以模型实际类别 id 为准 ALARM_CONF 0.45 model YOLO(leak_yolo.pt) # 现场微调权重 def process_frame(frame): results model.predict( sourceframe, conf0.30, # 推理时阈值放低把更多疑似框留给规则层 iou0.5, imgsz640, verboseFalse, ) for box in results[0].boxes: cls_id int(box.cls[0]) score float(box.conf[0]) if cls_id in TARGET_CLASSES and score ALARM_CONF: x1, y1, x2, y2 [int(v) for v in box.xyxy[0]] push_event(cls_id, score, (x1, y1, x2, y2), frame)这里故意把模型推理的 conf 设置为 0.30比告警阈值 ALARM_CONF 的 0.45 低。模型只负责“把像的东西都框出来”告警与否由 3.4 的事件聚合层结合时序决定。iou 是 NMS 的非极大值抑制阈值石化监控里管线交叉、设备堆叠很常见建议 0.5太低会保留大量重叠框导致重复计数。imgsz 默认 640 对密集装置区可能不够若边缘设备显存允许提到 960 往往能让远处小目标漏检明显下降代价是推理耗时增加需要实测权衡。3.4 把单帧检测聚合为巡检事件滑动窗口与告警触发模型输出的是“单帧像不像”现场要的是“这个位置确实在持续漏”。聚合逻辑一般按时间窗代码比想象中简单。import time EVENT_WINDOW 8 # 时间窗单位秒 EVENT_THRESHOLD 3 # 窗口内至少 3 帧检出同一目标 _hits {} def anchor_id(box, grid32): # 把检测框按画面网格归组避免同一目标被多次计数 cx (box[0] box[2]) // 2 // grid cy (box[1] box[3]) // 2 // grid return (cx, cy) def push_event(cls_id, score, box, frame): now time.time() key (cls_id, anchor_id(box)) _hits.setdefault(key, []).append((now, score, box, frame)) recent [h for h in _hits[key] if now - h[0] EVENT_WINDOW] _hits[key] recent if len(recent) EVENT_THRESHOLD: create_alarm_workorder(key, recent) del _hits[key] # 已触发告警清空等待下一次anchor_id 把检测框中心投影到 32 像素的网格里同一目标的多次检出会落到同一格避免引入跟踪器。这是故意为之跟踪器在石化装置上容易被遮挡、振动和快速光照变化打断网格归并的容错性更好。时间窗 8 秒、阈值 3 帧是比较稳的起始参数一个短暂飘过的蒸汽团不会触发告警真正的滴漏往往能在窗口内累积出足够多的检测帧数。如果现场误报仍多把窗口拉长到 15 到 20 秒并要求检测框中心位移不超过框宽后再告警通常在蒸汽环境里能再压掉一半误报。提示事件级聚合和帧级检测是两个责任层级。检测模型回答“这帧像不像”聚合器回答“这是不是真在发生”。石化项目里调聚合窗口收益往往比换更大的检测模型更直接。4. 石化现场误报排查与模型迭代光线、蒸汽、抖动和对策4.1 白天、黑夜与防爆灯频闪人工智能偏见在光照场景里的表现如果训练样本主要来自白天晴天模型学到的其实是“白天光照下的滴漏”特征到夜班红外补光或清晨逆光时漏检率会突然升高。这不是模型坏了而是数据在大面积同质化光照下形成了人工智能偏见。规范做法是在样本构建时按时间段分层抽样白班、夜班、黄昏、雨天各占比例输入侧再对灰度分布做自适应拉伸降低光源差异带来的特征漂移。建议让采集程序记录每帧亮度均值并按小时把数据分桶样本不足的时段单独补拍。宁可白天样本少一些也要保证夜班和交接时段有可复现的误报样本。防爆灯的光强会周期性抖动如果摄像头曝光时间太短画面亮度会跟着电源频率跳变检测框也会闪烁出现。这类问题不要用算法硬扛先把摄像头的自动增益和曝光时间固定下来模型输入稳定后误报自然减少。4.2 蒸汽、雨水和冷凝液怎么区分真泄漏与假泄漏石化厂区里蒸汽疏水、雨水冲刷、冬季冷凝液滴落都是正常现象但它们和真正的滴漏在视觉上极其相似。这种目标背景复杂不能只靠检测模型“认样子”。固定摄像头的画面里我们常做背景建模或帧间差分找出灰度发生连续变化的局部区域再叠加检测框确认物体类型。真正的管壁渗漏通常位置固定、形状缓慢变化蒸汽和积水则位置漂移、空域范围变化大。具体参数上把聚合窗口从 8 秒拉长到 20 秒要求目标在同一个网格或相邻网格内至少出现 6 次且检测框中心位移不超过一个框宽。蒸汽大量出现时这个规则会明显压制误报。如果平台支持还可以在告警引擎里加一个“雾雨模式”把灵敏度整体降一档等天气恢复再切回正常档。这套联动规则写进方案里比单纯增加训练数据更能应对季节性天气变化。4.3 相机抖动与遮挡哪些“算法问题”其实是安装问题装置区钢结构和管廊会随设备运行产生持续微振动摄像机立杆如果用膨胀螺栓直接打在钢结构上画面会出现 1 到 2 像素的抖动。这种抖动对目标检测的影响不大但对仪表 OCR 和分割任务影响明显。处理顺序是先看机械安装立杆加装减震垫、摄像机支架改用抱箍式固定再用软件做电子稳像。也有人直接加大检测框 NMS 的容忍度那是掩盖问题不解决漂移带来的重复计数。遮挡问题更常见检修平台、脚手架、植物突然进入视野把原先标注过的目标区域盖住模型持续输出低置信度检测。这类场景要把“遮挡比例”纳入现场确认流程在运维管理界面里允许对某一路摄像机临时设置“检修模式”屏蔽指定区域避免大风天气里临时遮挡物反复触发告警。4.4 误报样本回收与增量训练现场需要“石化行业人工智能训练师”即使参数和规则都调过误报也不会归零方案里必须留一个样本回灌机制。常见做法是值班员在复核工单上点“属实 / 误报 / 无法确认”三个按钮误报截图自动按类别和时间保存到专门目录每周合成一批新训练集对模型做一轮增量微调。固定场景里小模型的迭代速度非常快一次增量训练控制在一小时以内。import time import cv2 def save_review_result(frame, workorder_no, verdict, cls_id): ts time.strftime(%Y%m%d_%H%M%S) path f/data/review/{verdict}_{ts}_{workorder_no}_{cls_id}.jpg cv2.imwrite(path, frame) with open(/data/review/review_meta.csv, a) as f: f.write(f{workorder_no},{ts},{cls_id},{verdict}\n)这段代码把复核结论和截图绑定在一起。人工复核在 Web 端完成截图像素就是模型当时的输入像素不会出现“模型看的是一个画面、复核看的是另一个画面”的偏差。这个角色在团队里可以由标注员或模型运营担任按人社体系的定义它就是人工智能训练师这个岗位在石化行业的投影——既要会标注工具也要知道什么是正常的工艺状态。误报来源典型表现处理对策回灌数据形态蒸汽 / 雨水位置漂移、面积变化快拉长聚合窗口、限制位移标记为“冷凝水负样本”光线突变晨昏或补光灯切换触发固定曝光与增益分时段建模标记为“光照干扰”相机振动检测框抖动、重复告警机械减震加电子稳像维修后重拍该点位临时遮挡检修架、植物、车辆短时挡画面检修模式屏蔽区域标记为“遮挡负样本”5. 事件级评估与灰度上线把巡检准确率说到点子上5.1 帧级准确率为什么是虚的在异常事件极其稀疏的场景里帧级准确率没有参考价值。某一路摄像头一天里 99.6% 的帧都是正常的模型只要“全都不报警”帧级准确率就有 99.6%但它对巡检没有任何帮助。石化项目验收时要谈的是事件级检出真实发生了多少次跑冒滴漏、模型报出了几次、漏了几次、误报了几次。一次“事件”对应一个时间窗不是一帧画面。5.2 用时间重叠计算事件级 precision / recall / F1人工复盘时记录每个真实事件的时间区间系统则记录每条预测事件的起止时间。两者通过在时间轴上的重叠程度匹配。def time_iou(a, b): inter max(0, min(a[1], b[1]) - max(a[0], b[0])) union max(a[1], b[1]) - min(a[0], b[0]) return inter / union if union 0 else 0.0 def event_f1(preds, gts, iou_thr0.5): used [] tp 0 for p in preds: g max(gts, keylambda x: time_iou(p, x)) if time_iou(p, g) iou_thr and g not in used: tp 1 used.append(g) fp len(preds) - tp fn len(gts) - len(used) precision tp / (tp fp) if tp fp else 0.0 recall tp / (tp fn) if tp fn else 0.0 f1 2 * precision * recall / (precision recall) if precision recall else 0.0 return precision, recall, f1时间 IoU 取 0.5 的意思是预测事件和真实事件有一半时间重叠就算命中。这个阈值偏向宽松适合第一天验收运行稳定后可以提高到 0.7逼着系统把事件起止时间报得更准。判断标准只有一个生产现场最关心的是漏报其次是误报准确率要把这两个数拆开来说合并成一个“正确率”会掩盖问题。5.3 灰度上线前用历史录像做回放验证上线前不接实时流把过去两周装置区录像按真实时间回放让系统在后台跑“离线巡检”把生成的报警时间和人工复盘的事件时间输入上面的函数跑出事件级指标。通过后再切单台装置的实时灰度并且告警只落到复核工单不动 DCS 联动由班组按“属实 / 误报”打分。打分数据每周导出和 4.4 的样本回灌流程接起来误报图片直接变成下一轮训练的负样本正样本则来自现场复核为“属实”的事件视频。把“误报样本自动写回数据集”做成每周定时任务下一轮增量训练会自动带上这个装置最新的环境变化这比一次性验收报表更能说明巡检系统是否真的在跟着装置一起进化。本文还有配套的精品资源点击获取