天车这东西行业里也叫行车、桥式起重机是钢厂、重装车间、造纸厂、物流仓储里最离不开的设备。我以前跟不少搞设备管理的朋友聊大家提到天车安全第一反应都是“装个限位开关、挂个警示牌、定个操作规程”真到出事儿的时候才发现传统手段根本防不住人。近几年基于AI视觉识别的天车智能监测服务系统落地很快评价区里也有人问“到底怎么实现的”“装了值不值”今天就把这类项目从设计思路、算法训练到现场部署、报警联动整个链路拆开讲一遍。这套东西看着是“摄像头加算法”实际从选型、部署到调优每一步都有讲究踩过的坑比想象中多得多。文章适合正在做天车安全管理方案的人、搞工业视觉落地的工程师以及准备上这套系统的企业管理人员参考。1. 项目整体设计与方案选型1.1 天车场景的安全痛点先讲清楚天车作业的危险性在于它“高、大、动、重”。大车沿厂房轨道来回跑小车在梁上横向移动吊钩带着几十吨的负载上下起落整个工作范围横跨整个车间。地面人员、物流车辆、堆料区都在它的覆盖半径内任何一个误判都可能造成严重后果。传统手段的问题在于“测不到人”。限位开关只能管设备自身的行程极限雷达或红外对射只能检测到移动物体分不清是人还是叉车更分不清是佩戴安全帽的合规人员还是闯入吊装区的无关人员。钢丝绳、挂钩的状态监测主要靠人工点检频次低、覆盖不全等到钢丝绳断丝、钩口变形被发现往往已经接近失效边缘。天车本身是移动设备供电方式特殊想要在上面加装大量传感设备施工难度和成本都很高。真正促使企业下决心上AI视觉方案的是三件事一是安全监管要求越来越严出了事故不仅要停产整改管理人员的责任追究力度也在加大二是人工巡检成本逐年上升但覆盖率和及时性依然不足三是事后调查经常缺视频证据责任认定说不清楚。这三个痛点叠在一起传统方案只能解决其中一个侧面AI视觉恰好能一次性覆盖人员行为、设备状态、作业过程记录这三块需求。1.2 为什么最终选AI视觉而不是传统传感器方案我在多个项目里比较过超声波雷达、激光扫描、红外对射、AI视觉四条路线结论比较明确针对“人”的安全监测AI视觉是唯一靠谱的选择。超声波和激光雷达测距精度可以做到很高但只能给出“某个距离上有物体”无法判断物体类型和身份。红外对射能实现区域入侵检测但下雨、扬尘、光束遮挡都会造成误报警而且安装对射支架在大跨度厂房里非常麻烦。激光扫描成本很高单套覆盖范围有限对镜头脏污和振动敏感维护压力大。AI视觉的核心优势是它能做语义理解。同一路画面里算法能区分人是戴着安全帽正常作业还是违章闯入能识别出吊钩有没有挂好、防脱钩装置是否到位能判断作业人员是否停留在吊物下方。这种“理解现场”的能力是任何测距类传感器都不具备的。视觉方案还能把整个作业过程录像留存事后追溯有据可查。现在边缘算力成本下降很快一路高清视频的实时分析已不再需要昂贵服务器一块轻量级边缘板卡就能跑多路模型项目总成本可控。当然视觉也有短板怕遮挡、怕强光、怕镜头脏污。所以在设计上必须配套多种避让策略。我的经验是不要指望单路相机解决一个问题而是用多机位覆盖加算法冗余把视觉的短板用系统设计补上。1.3 系统整体架构设计思路整套系统分为四层这个分层结构在多个项目里验证过基本能应对大部分厂房环境。感知层负责画面采集在厂房顶部、天车本体、操作室、吊具周边部署多路工业相机覆盖大车运行区域、小车吊装区域、人员通道和操作室内部。相机选型要适应车间的高温、粉尘和振动环境防护等级至少IP65起步。分析层是核心部署边缘计算设备运行目标检测、人员跟踪、安全帽识别、电子围栏判定等算法模型对画面进行实时推理输出结构化事件比如“人员闯入吊装区”“未佩戴安全帽”“吊钩未闭合”。边缘计算方案比纯服务器方案更适合天车场景因为天车本体上的画面如果在车内做推理再上传结果对网络依赖小断网也能本地独立报警。平台层负责数据汇聚和业务呈现包括实时监控大屏、报警中心、视频回放、设备台账、统计报表。平台层可以部署在厂区机房也可以跨厂区做集中管控按项目规模灵活伸缩。联动层是天车监测区别于普通视频监控的关键通过继电器模组或工业网关与天车控制系统对接能实现分级预警一级报警现场声光提示二级报警天车自动降速三级报警切断动作并锁定天车。联动逻辑必须设计成可配置、可旁路避免因算法误报导致设备频繁停机。2. 核心识别算法与数据工作流2.1 监测目标清单与判定逻辑动手训练模型之前第一件事是把监测目标列全。我在一次项目评审会上见过漏项翻车的案例前期的检测项只做了人员入侵上线后管理部门又提出要监测挂钩状态结果全部流程返工。这里我建议按“人-机-环”三个维度来梳理。监测维度监测项算法类型核心判定逻辑人员未佩戴安全帽目标检测分类头肩检测框内是否存在安全帽类别人员吊装区域入侵目标检测多目标跟踪人员轨迹与电子围栏区域交叉且持续超时人员操作室离岗人体检测操作室内连续N秒无人设备吊钩未闭合状态识别钩口区域开放/闭合二分类设备钢丝绳偏摆异常语义分割绳体相对滑轮槽的偏移角度超阈值环境吊物下方有人检测深度关系推理吊物框与人体框的二维交并比超阈值这里的难点是“联动判定”。比如吊物下方站人不能只看人有没有出现在画面里而是要判断这个人是否处于吊物的投影范围且吊物是否正在运动。二维画面里没有深度信息就需要利用天车的运行状态信号做一个逻辑开关天车不动作时下方站人不报警天车开始起吊或移动时才触发报警。这类业务规则要和算法输出结合在一起才能把误报率压下来。2.2 现场数据采集与标注的三条铁律算法能不能在现场跑出效果数据是头号因素。我见过不少团队在公共数据集上把模型调得很好一进车间就失灵问题往往出在数据分布和真实场景差距太大。第一条铁律是必须在真实现场采集数据而且要覆盖全天候时段。车间里白天有阳光直射、夜间只有昏暗照明冬天有雾气、夏天有热浪扰动这些都会显著改变图像特征。我经历过一个项目白天模型检测安全帽的准确率能到95%到了晚上直接掉到70%就是因为夜视条件下安全帽的颜色和纹理信息大量丢失。数据采集合集至少要覆盖早、中、晚、夜四个时段每种光照条件单独成集。第二条铁律是负样本数量必须充足。很多团队只标注“戴了安全帽”的正样本忽略了“帽子拿在手里”“帽子放在桌上”“安全帽和普通工帽长得像”这些容易混淆的情况。模型看到手拿帽子时会误判为未佩戴看到安全帽悬挂在墙上又会误判为人员。后来我在标注规范里增加了“手持帽”“背景帽”“假人帽”三个属性标签误报率降低非常明显。第三条铁律是标注框的边界规矩要定死。天车场景里很多目标是远距离小目标一个工人站在地面上在1080P画面里可能只有几十个像素高标注框稍微偏一点对模型训练的干扰就很大。建议统一采用贴合目标边缘的标注策略对遮挡超过50%的目标也要标注并打上“遮挡”属性让模型学会在有遮挡时依然能检出。2.3 模型选型与边缘推理优化检测模型方面YOLO系列依然是工业落地的主力。新出的YOLOv8、RT-DETR我也测试过RT-DETR在精度上确实有优势但部署体积和推理延迟对边缘设备不太友好YOLO系列在小目标和实时性上更均衡。针对天车场景我通常会在主干网络里加入注意力机制模块强化对远距离小目标的特征提取。训练参数上输入分辨率尽量不低于960×960虽然这会增加推理耗时但对小目标的检出提升非常显著。一个常见误区是为了算力妥协降低分辨率结果小目标全丢后面再怎么调都救不回来。数据增强方面重点加光照扰动、噪声扰动和雨天模拟车间环境里最怕的是亮斑和粉尘造成的假目标。部署优化是工程落地的重头戏。模型导出后用TensorRT做FP16推理在边缘板上能把单路延迟压在50毫秒以内。INT8量化能进一步提速但精度损失需要评估我建议先在现场录制的测试集上验证mAP掉点超过2个点就别硬上。蒸馏和小模型剪枝也值得做把大模型教出来的知识迁移到轻量模型上性能和功耗都会好看很多。3. 摄像头、算力与现场部署3.1 摄像头怎么摆视角决定算法上限算法再强看不清画面一切都是空谈。摄像机安装位置直接决定检测效果的上限这一步没有做好后面所有调优都是事倍功半。大车运行方向的监测相机我建议装在厂房立柱或天车端梁上视角斜向下覆盖整个地面作业区域这样既能看清人员的位置也能看到吊物的投影范围。吊具状态的监测相机要装在小车架下方正对吊钩和钢丝绳尽量避开吊具自身的遮挡。操作室内的相机装在对角线位置能覆盖整个操作台和座椅区域。安装时要重点确认三件事目标在画面中的像素尺寸是否足够大是否有阳光直射或逆光问题是否有厂房结构遮挡。像素尺寸我的经验是人员目标高度不要低于画面高度的5%否则算法再强也难识别。逆光问题优先选带宽动态功能的相机并调整安装角度避免镜头正对窗户或厂房采光带。遮挡问题要靠多机位补盲天车运行到不同位置时总会有某些区域被钢柱或堆料挡住只有两个方向以上的相机形成交叉覆盖才能保证全程监控无死角。相机的选型也有讲究定焦镜头可靠性高变焦镜头灵活性好但工业厂房振动大自动变焦机构容易出故障我建议除非有特殊需要否则尽量用定焦或手动变焦。防护罩要选带视窗加热和雨刷功能的否则冬季结雾和粉尘附着会让你非常头疼。3.2 边缘算力选型与画面拉流那些事算力选型直接关系到项目预算和运行稳定性。我按路数给过几档方案单路到四路视频分析用轻量级边缘板卡就能带得动实测在25到35帧每秒之间浮动满足实时性要求。六到八路视频需要上更高算力的边缘模组或工控机加GPU成本会上去一截但多路并行处理更从容。选型时要关注的参数不只是算力还有工作温度范围和抗震能力。车间里夏天温度经常超过40度边缘盒子如果散热设计不好推理延迟会随着降频直线上升。安装位置尽量选在厂房通风处或空调电柜内电源也要用宽压工业电源避免天车启停造成的电压波动导致设备重启。画面接入方面天车本体上的相机布线要特别注意随行电缆的走向和固定不能影响天车自身的运行机构。网络协议一般走RTSP或GB28181主码流用于算法分析子码流用于平台预览两者分开避免相互抢占带宽。断线自动重连机制必须做天车运行环境的无线网络稳定性有限画面一断就报故障并不可取要做到秒级自动恢复且补传关键片段。3.3 现场部署的施工组织细节部署施工经常是整个项目最容易被低估的环节。高空作业的脚手架搭设、停机窗口的协调、线缆桥架的走向规划每一项都需要提前排计划。我吃过亏的地方是没有提前核对厂房的建筑图结果到了现场发现吊车梁下方根本没有留线缆通道只能临时在安全通道上方走明管工期延了一周。施工顺序建议分四步走先把相机支架和防护罩装好再布线和接通电源然后逐路调试网络和画面质量最后再启动算法模型做现场验证。每一步都要有书面记录尤其是相机安装角度和画面截图的留档后面对着记录排查问题会省很多事。4. 报警规则、平台服务与设备联动4.1 报警规则引擎别把报警做成“狼来了”很多项目上线初期都会被投诉“乱报警”本质上是报警规则设计不合理。真实车间里人员走动频繁、堆料状态变化快如果规则太敏感一天能弹上千次报警管理人员很快就麻木了真正的事故风险反而被淹没。报警规则引擎要支持组合条件判定。一个有效报警至少包含三个要素检测目标类型、所在区域、持续时长。举个例子“未佩戴安全帽”这个报警必须限定在作业区域且人员逗留超过3秒才触发只是路过就路过不至于反复响。吊装区入侵的规则更严格要结合天车的运行状态天车静止时人员进入吊装区可能是在做挂钩准备不报警天车起吊动作一开始区域内还存在人员立刻触发高等级预警。报警分级也要定清楚。第一级是提示性报警平台记录、大屏显示不打扰现场作业第二级是预警现场声光提醒平台推送通知天车自动降低运行速度第三级是紧急报警现场高音广播加红色警示灯天车锁定动作必须人工确认后才能复位。分级与联动配置要做到页面化、可调整企业安全管理人员能根据现场实际灵活修改参数而不是每一次调整都找算法工程师。配置示例我经常用JSON格式来描述读起来直观也方便版本化管理{ alarm_rule: { scene: hoisting_area, target_type: person, event: intrusion_while_crane_moving, min_duration_s: 2, min_confidence: 0.85, action: level3_lock_crane, locks: { sound_light: true, notify_manager: true, crane_speed: 0 } } }4.2 与天车控制系统的安全联动AI视觉系统本质是辅助监测联动动作必须安全可控。我反复强调一个原则AI报警触发的联动只能降低天车运行风险和限制动作绝不能替代原有的安全保护机制。工业标准里安全回路的设计要遵循独立冗余的原则算法系统失效时原有限位、超载保护等机制依然能发挥作用。联动方式上推荐通过工业网关以Modbus TCP或OPC UA协议与天车PLC通讯。边缘计算设备把报警等级写成寄存器状态PLC扫描到状态变化后执行降速或锁定程序。这里要注意通讯超时和故障的默认处理策略我建议设置一个心跳信号边缘设备如果连续几秒没有更新心跳PLC要判定系统离线并解除联动控制让天车恢复到人工操作的原始状态避免因AI系统故障导致设备瘫痪。复位机制是另一个容易忽视的细节。天车被锁定后必须由现场安全员到指定位置确认情况再通过物理按钮或管理平台发起复位指令不能只在软件里点一下就解锁。这个“人证合一”的过程能防止误报锁定后作业人员自行复位带来的二次风险。4.3 平台功能与服务交付形态平台层是面向管理人员的窗口功能要从使用者的日常工作流出发。实时监控页面要有多宫格画面报警事件在对应画面上叠加醒目框和状态标签点进去能查看报警前后的视频片段。历史回放要支持按时间、区域、报警类型多维度检索最好能一键导出取证视频和截图方便事故分析和安全培训。统计报表是平台价值的一个重要体现系统要自动统计每日各类报警次数、整改完成率、区域安全评分等指标。我在实施中经常会根据企业需求定制一套“安全指数”综合违章次数、响应及时性、整改闭环率等维度给车间打分让安全管理工作可视化管理者一眼就能看出哪个区域问题最多。从交付形态看天车智能监测服务系统有两种主流做法。一种是纯私有化部署算法、平台全部运行在企业机房数据不出厂区适合数据敏感的大型制造企业另一种是“底座在云、边缘在现场”的混合模式边缘设备本地完成分析和报警平台端汇总多厂区数据做集中管理适合集团型多基地企业。选择服务形态要从企业现有信息化水平和安全管理组织架构来考虑没有标准答案。5. 常见问题与排查技巧实录5.1 强光与背光引起的误检厂房采光带和窗户造成的直射光在天车移动时会在画面上形成大面积亮斑人脸和身体变成剪影安全帽的颜色特征丢失这是误检率最高的场景之一。我的处理思路是软硬结合。硬件上优先选择宽动态和高动态范围的相机软件上在预处理阶段加入自适应曝光和局部直方图均衡保证目标区域在过曝和欠曝中都能保留基本轮廓。算法层面在数据集中加入大量逆光样本做针对性训练模型会学会用轮廓特征而不是颜色特征来识别目标。实测下来逆光场景的安全帽漏检率能从三成降到一成左右。5.2 粉尘、水雾与镜头脏污车间里的金属粉尘、油雾、水汽会对镜头造成持续污染镜头脏了画面模模糊糊算法性能整体退化而且这种退化是缓慢的不容易被运维人员察觉。解决这个问题一是靠防护罩的视窗加热和雨刷装置自动维护二是在系统里增加画面清晰度评估模块定时计算图像对比度或拉普拉斯梯度值指标持续偏低时自动触发清洁工单。现场运维也要把镜头清洁纳入日常巡检频率按车间洁净程度调整粉尘重的车间至少一周清洁一次。5.3 目标粘连与多目标跟踪切换错误多个工人站在一起或者工人与设备在画面中重叠时检测框会发生粘连跟踪算法把A的轨迹错配到B身上导致“吊物下方有人”这类联动判定出错。这里我的经验是用ByteTrack这类跟踪框架并针对天车场景调整参数加大外观特征在匹配时的权重。同时把跟踪结果按区域做分组后处理同一区域内多个目标的轨迹各自独立维护对重叠目标按面积占比分配检测框归属。如果某个区域频繁出现粘连问题优先调整相机角度或加一路近景补拍相机来拆分目标。5.4 报警风暴与夜间“幽灵报警”系统上线初期最容易出报警风暴深夜时段尤其多。我排查过很多次发现夜间误报多半来自两类原因一是飞虫、飘落的纸屑在画面中形成了“伪人员目标”二是远处车辆灯光在地面形成的投影被误判为人形。针对飞虫和飘落物可以通过帧差分析和目标运动特征筛除这类目标运动轨迹呈抖动状态且面积变化异常与人体运动模式差异明显。灯影误判则要靠规则改善灯光投影通常具有高亮且边缘模糊的特征且运动速度异常可单独训练一个“地面灯光”负样本类别也可以限定人员检测区域排除地面投影带。报警风暴还需要配置去重抑制策略同一区域同一类型的报警触发后自动进入静默期几十分钟内不再重复推送直到新的目标出现。5.5 一些长期运维的额外心得系统上线只是开始长期稳定运行靠的是持续的模型迭代和运维机制。我在项目中会建议企业建立一个简单的“报警数据定期回看”流程每周抽看一定比例的报警快照把误报和漏报样本收集起来用于后续模型更新训练。这比一次性卖完系统走人的做法对企业更有价值。模型更新也不是重新训练一版就推上去要保证现场系统可灰度切换。边缘设备上保留新旧两个模型新模型先在旁路模式运行一段时间输出结果只记录不联动确认误报率达标后再切换到正式模式这个流程能避免不少生产环境中不可预知的翻车。最后说点我个人体会做这类项目算法只是其中一半另一半是对现场作业的理解和对安全管理的尊重。装之前最好跟天车司机、地面指挥员、安全员都聊一圈他们嘴里描述的那些“平时都这么干”的习惯才是算法规则设计的真实依据。技术最终是服务于人的把现场的人伺候舒服了系统才能真正落地生根。