凌晨两点半港口中控室的值班员打了个哈欠。屏幕上突然弹出一条红色报警三号翻车机下方输送带疑似纵向撕裂置信度91%。他看了一眼右侧的实时视频画面一条黑色输送带正在匀速运转画面上用红框标出的位置确实有一道十几厘米长的口子。他按下确认键用对讲机通知现场巡检员过去复核。三分钟后巡检员回话是皮带接头处的硫化胶边缘开了个缝不算撕裂但确实需要记录在案。这段场景就是熵奕信息这个项目上线之后最常见的日常。作为给某沿海散货港口做设备智能巡检的项目代号熵奕信息核心只做一件事用视觉AI识别算法让港口带式输送机这条“大动脉”真正实现24小时受控。散货港口的作业模式是卸船机把矿石、煤炭从船舱抓起来放到皮带输送机上一路送到堆场或装车楼一条流程线动辄两三公里。中间的皮带要是出问题整条流程都会停摆损失以小时计算。这篇文章不打算写成产品宣传稿而是把这个项目里的实际经历拆开讲检测目标是怎么定义成算法任务的视觉方案怎么设计和部署数据集怎么采集标注现场调试踩了哪些坑最后效果怎么评估。如果你也在做工业视觉、设备状态监测或者智慧港口相关的东西希望这些细节能帮你少走几步弯路。1. 为什么港口皮带需要“24小时守护”一个价值百万的运维场景1.1 输送带不是一根带子而是一条连续产线先讲清楚一个概念港口散货作业的核心运输方式是带式输送机。传统印象里港口就是桥吊、集装箱但实际上煤炭、铁矿石、粮食这类大宗散货几乎全靠皮带机在码头前沿、堆场和装车楼之间来回倒。输送带本身看起来就是“一根橡胶带子”但它的工况远比想象中复杂。一条皮带往往绵延数公里由硫化接头把多段带体连接起来下面每隔一米五左右有一个托辊支撑。物料从受料点落到带面上经过转载站改变方向中间还可能经过清扫器、除铁器、缓冲托辊等设备。带面承受着数万吨级的累计载荷带速通常在每秒四到六米全天候运行。任何一个环节出问题后果都是连锁的跑偏导致带边磨损撕裂撕裂后带体强度骤降可能瞬间断带托辊卡死不转摩擦发热可能引燃皮带物料在转载站堆积堵住溜槽整条流程被迫停机。这类故障一旦发生修复时间以十小时甚至数天计而且直接冲击装卸船计划。我把常见故障类型整理过一张简表方便理解为什么皮带值得专门做一套AI检测故障类型发生后直接后果高频原因可观测特征皮带跑偏带边撕裂、刮伤、洒料料流偏载、滚筒粘料、机架变形皮带边缘偏离滚筒中心线纵向撕裂整条带体报废甚至断带异物刺穿、接刀口、夹料带面出现纵向切口或裂口托辊卡死局部摩擦发热严重时冒烟起火轴承损坏、积料抱死托辊不转动或外观异常转载站堵料流程停机清理耗时极长料流冲击堆料、溜槽设计不合理溜槽口物料溢出、堆积异常接头损伤硫化接头开裂接头强度下降硫化工艺不佳、长期弯曲应力接头处出现裂缝、凸起、开胶当初做完这张表之后最大的感受是皮带检测根本不是一个“简单目标检测”问题而是要同时覆盖多种故障类型、多种工况条件、多种现场干扰。它更像一个针对特定工业场景的视觉健康监护系统而不是模型训练比赛里的某个经典数据集任务。1.2 人工巡检为什么跟不上节奏在AI方案之前港口皮带主要靠人工巡检。巡检员沿着皮带走廊定时巡查耳朵听托辊声音、眼睛看皮带跑偏、鼻子闻有没有烧焦味。老师傅确实能干不少事但这种模式的物理上限撑不住超大规模皮带流程。首先是时间差。一条两三公里的流程线巡检员完整走一圈要一个小时。带速每秒五米一小时皮带已经走了十八公里。很多故障在几分钟内就会从小口子发展成灾难性破坏比如纵向撕裂从发现到扩大可能就在一两个托辊间距的几十秒内人根本赶不到现场。其次是覆盖盲区。转载站、机头机尾往往是故障高发区但也是噪声最大、粉尘最重、环境最差的地方。夜里两点手电筒加煤粉飞扬肉眼根本看不清细小的撕裂口或托辊状态。人的注意力还有天然的衰减曲线半夜值班的疲劳状态谁也逃不掉。还有记录问题。人工巡检的痕迹依赖交接班日志问题经常是滞后一两天才被分析很难形成统一的设备健康趋势。说白了人工巡检是“点检”不是“在线监测”。港口设备管理想要的是能在故障“将发未发”的时候给出提示的能力。1.3 为什么停机检修不是解决思路有人会问定期停机检修把皮带拆下来彻底查一遍不好吗这个问题在港口业务模型下基本行不通。核心是港口生产的连续性要求。船舶靠泊是按小时计费的装卸流程一旦中断影响的是船期、堆场周转和后续疏运计划。停机检修的时间窗口非常有限根本不存在“想停就停”的可能很多皮带故障恰恰发生在两次检修之间的高峰期。因此港口需要的不是“定期体检”而是“24小时心电监护”——在不中断生产的前提下持续感知皮带状态在故障刚出现时给出报警。这正是AI检测识别算法能发挥作用的地方也是整个项目立项时的出发点。明白了这一层后面的技术选型和部署策略才算有了根。2. 先定义清楚“检测什么”报警目标与场景约束2.1 从业务需求到算法任务的拆解项目启动后最容易犯的错就是马上找模型、找数据。其实最先该做的是和现场的设备工程师、工艺工程师坐下来把“要检测什么”翻译成算法能理解的任务。拿跑偏来说业务上关心的是皮带边缘离开滚筒中心线的距离是否超标。这是一个量化指标算法不一定要输出“跑偏/正常”的离散类别更合理的做法是利用图像中的直线检测拟合皮带边缘线位置再判断偏移量是否超过阈值。这个思路比单纯分类更稳因为它保留了连续变化的物理量还能直接输出一个毫米级的偏移值给中控室看趋势。像撕裂、托辊卡死这类问题则更适合走目标检测和运动分析但要先定义清楚边界纵向撕裂在图像中表现为长条形裂口可能被带面上残留的物料部分遮盖属于干扰大、样本稀缺的目标。托辊卡死正常托辊有圆形外轮廓卡死后外观变化不一定明显但运动状态下很可能不再旋转。单帧静态图像很难判断必须结合连续帧运动分析。堵料堆积转载站溜槽口物料超出正常高度、侧面飞溅更适合考虑语义分割或区域分类而不是画目标框。2.2 场景约束比想象中多光照、粉尘、运动模糊模型结构不是这个项目的难点场景约束才是。工业现场的视觉环境远比论文数据集苛刻。一个是光照。港口皮带有露天段、有廊道段白天阳光直射、晚上靠补光灯夏季太阳角度变化大雨雾天气能见度低。如果只用普通可见光相机白天和晚上的图像特征差别太大一个白天训练的模型到晚上很容易失效。你不可能要求现场像实验室一样保持恒定的照明条件必须在成像端就把光照变化压到最小。另一个是粉尘。煤和矿石在转载、下料过程中产生大量粉尘经常悬浮在镜头和皮带之间。成片粉尘在图像里形成白色、灰色雾状干扰如果恰好位于待测目标前面会完全遮挡目标区域。这不是增强对比度能解决的必须从成像端和算法端同时想办法后面部署章节会详细说。还有运动模糊。皮带带速每秒四到六米相机快门速度不够的话图像会拉出一道运动模糊。撕裂口和托辊上的细小纹路在模糊之后几乎不可辨识这个我们早期测试吃过亏后来用高速快门配合补光才算解决。2.3 算法选型逻辑为什么不是简单套一个目标检测最终选型走的是“多模型组合 边缘部署”路线而不是一个通用检测模型解决所有问题。原因有三条第一不同故障的视觉特征差异太大。撕裂是面状结构上的线状缺陷跑偏是位置偏移托辊是运动状态强行用一个网络统一优化成本高、效果还不一定好。模块化拆分反而让每个任务都可以单独调参。第二现场误报率容忍度极低。港口中控室如果一天弹两百条报警值班员很快就会把系统当摆设。为了把误报控制住模型不能只看单帧必须有时间序列的确认机制这对模型输出结构有额外要求。第三算力是硬约束。每个点位如果都配一台高算力服务器成本直接爆炸。我们选择边缘计算盒子需要把模型压缩到几十瓦功耗内还能跑出实时帧率这意味着部署时要考虑量化、剪枝等工程手段而不是只盯着算法的理论精度。每个故障最终落到哪个算法模块可以用一张表说明故障类型视觉任务模型路线关键关注点跑偏皮带边缘线拟合轻量分割或边缘检测偏移像素数换算毫米撕裂目标检测轻量检测器最小可检出长度、召回率托辊卡死运动状态分类帧间差分或小光流模型静止托辊识别率转载站堵料区域语义分割轻量分割网络溢出面积占比这样设计的好处是每个模块的调参边界清楚不同故障不会因为误报互相污染。实际运行时多个模块并行输出由上层决策逻辑汇总成最终报警等级。3. 从实验室到码头现场相机部署与边缘算力方案3.1 摄像头点位设计机头、机尾、中段各有分工第一版方案的想法很简单每隔一段距离放一台相机覆盖全程。到现场一看太天真了。一台工业相机、防护罩、安装支架、补光、布线整体成本不低一条两公里的皮带要装几十个点位不是钱的问题是维护量巨大。后来我们把“全覆盖”改成了“关键点位重点覆盖”。具体来说皮带流程的风险点集中在三处机尾受料点物料刚从漏斗落到带面上最容易带偏、夹料、堆积。这里重点看跑偏和堵料。机头卸料点皮带转向、卸料容易发生撕裂、清扫器卡堵、带面残留。这里也是撕裂高发区域。中段高张力区皮带走直线主要看托辊状态、带面撕裂、洒料。每个转载段之间的直线段选几个重点断面安装相机即可。相机安装角度也有讲究。垂直俯瞰能最完整看到带面但安装支架往往没有足够空间侧面斜视容易受粉尘干扰而且透视变形大。我们在受料点采用大角度斜视兼顾带面宽度和来料方向中段则尽量压低角度让画面正对带面减少投影变形对尺寸判断的影响。3.2 成像端方案快门、补光、防尘一个都不能少成像端直接影响算法上限这部分直接说结论工业相机快门时间不低于1/1000秒定焦手动光圈镜头视角按覆盖一米二到两米的带面宽度选。皮带速度越快快门要求越短否则就是前面说的运动模糊。光照方案最终选了红外补光加滤镜组合。红外光在夜间不会打扰现场人员对粉尘的穿透能力比可见光好一些。白天阳光很强时把红外补光增益调低晚上调高保证白天黑夜图像的整体亮度接近。加偏振片可以减轻带面反光尤其是雨天带面有水的场景不然高光斑块正好把撕裂口盖住模型会彻底瞎掉。防护上吃过亏必须多说一句。码头环境盐雾重、粉尘多相机外壳要用气密防护罩镜头前加石英玻璃视窗再配小型气路吹扫装置定时吹掉视窗上的积尘。沿海码头那种粉尘环境一天不清灰画面就开始朦胧。另一个容易忽略的是防爆要求煤码头有粉尘防爆分区普通工业相机不一定符合我们后来选了隔爆型防护罩加本安型补光灯采购周期比普通设备长不少要提前下单。3.3 边缘算力与模型压缩在受限功耗内跑出实时检测现场点位多不可能每个点都回传原始视频到中心服务器带宽和存储都会爆。方案是“边缘推理 中心汇总”每个点位一个边缘计算盒子负责跑模型、输出报警结果只回传报警截图和视频片段中心平台只做告警展示和数据处理。边缘盒子我们对比过几款平台算力功耗范围实测帧率轻量检测模型INT8Jetson Orin Nano约20 TOPS7-25W15-20 FPSJetson Orin NX约100 TOPS10-25W40-60 FPS国产低功耗NPU盒子视型号而定5-15W10-25 FPS最终选了Orin NX这个级别。单路1080P视频跑轻量化检测模型配合TensorRT做INT8量化实测能到40到60帧每秒。实际业务只需要每100毫秒处理一帧所以算力余量很充足还能同时跑语义分割和运动分析模块。模型压缩的流程是PyTorch训练FP32模型导出ONNX再用TensorRT构建INT8引擎。量化校准集直接从现场采集几万张典型图片覆盖白天、黑夜、晴雨、粉尘浓度高低各种工况。这一步非常关键校准集选不好INT8量化后精度掉得非常多。我们用现场校准集前后对比过量化后mAP掉点控制在1%以内如果是盲选几张图做自适应量化掉5%都不奇怪。另外工业现场视频流中断、算力卡死这类问题比想象中常见。边缘盒子程序必须做成看门狗自恢复上线初期发生过一次内存泄漏导致检测进程挂掉值班员那边屏幕全黑后来加了进程守护和心跳上报才算彻底解决。4. 数据是算法的口粮采集、标注与样本缺口4.1 现场数据采集要覆盖哪些“隐藏工况”训练数据直接决定现场能不能用。我们投入了大量时间做数据采集总量不算夸张大约五万张有效图像但覆盖维度非常全时间维度凌晨、正午、黄昏、夜间每个班次都要均匀分配。天气维度晴天、雨天、雾天、大风扬尘天。运行状态正常重载运行、空载运行、启停瞬间。物料类型不同矿种、不同湿度、不同粒度。故障状态检修窗口期采集或故障初发时抢采。其中最难的是故障状态数据。港口不可能为了让AI练手故意让皮带走坏很多故障样本只能在检修窗口期或者故障初发但尚未停产时抢着采集。我们后来摸索出一个和机修班组联动的办法在换下的旧皮带上用刀具刻出不同类型的撕裂口、划痕、边缘破损再平铺到正常运行区域周围利用检修间隙模拟拍摄。虽然和真实运行状态有纹理差异但至少让模型先理解“撕裂长什么样”后面拿少量真实故障样本做微调学习速度明显加快。4.2 标注规范里最容易出问题的三个点标注是数据质量的重灾区。第一次外包标注了一批回来后模型精度一直上不去排查后发现问题集中在三个地方一是撕裂框标注得太大。标注员习惯把整个破损区域包进去模型学到的是“大片黑色区域”一旦物料阴影也是大片黑色就会误报。正确做法是框住实际裂口本身宁可小而准不能大而滥。二是托辊标注混乱。画面里托辊一个挨一个标注员经常漏标、错标甚至把支架当托辊。最后规定每个托辊用外接矩形标注目标边界处留2到3像素余量避免相邻边框互相覆盖。三是遮挡目标处理规则不一致。撕裂口在粉尘或物料后面若隐若现时标注员要么忽略要么强行标注。我们规定可见面积超过50%的缺陷必须标注低于30%的不参与训练中间地带单独标记由人工复核。为了降低标注错误率还做了一个小工具把同一段视频的关键帧连起来播放标注员可以在动态画面里看到托辊是否转动、撕裂口是否真实存在。标注质量因此提升了一个档次这个工具成本不高效果却非常明显。4.3 样本不平衡与数据增强五万张图里真撕裂只有两百张数据量听起来不少但分布极端不平衡。五万张图像里正常运行画面占绝大多数真撕裂样本可能只有两百多张。直接训练模型会把“正常”学得很好对撕裂几乎没有感知。处理不平衡的思路分两条腿。一条在损失层面训练时对不同类别加权少样本类别提高权重同时用focal loss抑制大量易分类负样本的梯度另一条在数据层面复制粘贴式合成撕裂样本把真实撕裂区域剪切出来随机旋转、缩放、改变亮度后粘贴到正常带面图像上再叠加光照偏移和粉尘噪声。坦白讲合成样本和真实样本之间永远有域差异不能只靠合成数据。我们的做法是先用合成数据让模型学会大致特征再用少量真实故障样本做微调。最后效果比较明显真实样本只有两百多张的情况下撕裂召回率也能做到95%以上。这个思路对工业场景普遍适用——故障样本永远稀缺但合成数据少量真实数据组合的性价比很高。5. 现场调试踩坑全记录从“一天两百条报警”到“一周零误报”5.1 误报源头排查正常硫化接头被当成撕裂上线第一天系统在中控室屏幕上弹报警弹到手软。统计下来一天超过两百条误报值班员差点要求把系统关掉。逐条看报警截图发现最大一类误报来自硫化接头。皮带硫化接头在带面上是一道接缝边缘有规则凸起或色差。在模型眼里这道接缝的形状特征和撕裂口确实相似尤其在光线不佳、接缝处有残留物料的时候模型直接给出高置信度输出。这个坑表面是模型识别问题本质是业务知识没有进入算法。我们去现场确认了皮带接头的位置接头在整条皮带上循环出现通过编码器可以记录位置。然后在后处理逻辑里加了“接头区域排除区”报警位置落在已知接头区间内的先降级处理再人工复核。更通用的做法是把固定结构件也作为先验知识。机架边缘、皮带滚筒、清扫器等位置基本固定推理阶段用目标掩码过滤掉这些区域。这一步落地后误报数量直接下降了七八成。5.2 粉尘遮挡导致的漏检连续帧投票机制误报压下去后漏检开始暴露。初期最担心的就是“有撕裂但没报”排查发现大量漏检集中在两个时间点物料下料瞬间和粉尘浓度高的时候。撕裂口本来在带面上清晰可见突然一堆物料砸下来或者一股粉尘飘过目标区域顿时变成模糊一片。单帧模型在这一帧的置信度会掉到阈值以下于是漏检。解决思路不是提升单帧模型的鲁棒性而是引入时间维度。设计了一个“连续帧投票确认”机制模型对每一帧输出候选目标和置信度后处理维护一个目标轨迹跟踪状态只有同一个疑似目标在连续N帧中持续出现且置信度超过低阈值才触发报警。N取值要按带速和帧率换算带速五米每秒、帧率十帧每秒一秒钟目标移动五米如果撕裂口长度三十厘米目标在画面中只停留数帧N不能设太大否则真目标会被过滤。最后调到连续三帧或累计五帧效果比较平衡。这个机制还有一个附带好处对偶发反光、飞鸟、飘落的杂物等单帧干扰有很强的抑制作用相当于用时间一致性过滤了大量噪声。5.3 告警逻辑与值班联动先报警还是先停机这里必须想清楚AI检测到什么程度才允许触发停机制动。从纯技术角度检测到持续撕裂且目标越来越大完全可以通过PLC联动直接拉停皮带避免更大损失。但从港口运营角度看一次误停机同样打断生产流程代价不小。所以和现场达成了一套分级机制P1级一般异常疑似洒料、轻微跑偏、托辊异常。只生成记录系统自动截图存档。P2级明确异常接头裂缝、跑偏量超标、堵料趋势明显。中控室弹窗报警提示值班员确认。P3级紧急故障连续多帧识别到纵向撕裂、带面破损扩大、严重堵料溢料。此时才联动PLC触发急停。分级逻辑写进规则引擎后值班员从“每条都看”变成“只看P2和P3”处理压力小很多。实际反馈也表明分级机制比“机器说停就停”更容易被现场接受。给中控界面加了“确认”“误报”“已整改”三个按钮也很关键这直接形成算法迭代闭环。值班员点“误报”的样本自动进入待复核数据集算法团队定期拉取分析变成下一轮训练数据。没有这个设计模型就永远是“上线时的样子”很难变聪明。6. 效果评估与模型迭代闭环从“检测工具”到“设备管家”6.1 线下指标和线上指标是两码事很多汇报会提mAP、F1这些学术指标但港口现场更关心另外三个数每小时误报数FPPH决定值班员会不会把系统当摆设。故障召回率决定系统能不能守住大动脉。报警确认平均耗时决定异常处置快不快。上线后一个月的统计数字大概是这样指标实测水平说明撕裂类故障召回率95%以上仿真测试与现场记录综合值每小时误报数低于0.2次多数班次可以做到零误报托辊识别精度92%左右受粉尘天气影响有一定波动单点单路平均延迟小于200毫秒从画面采集到报警上屏线下测试再好也要经线上运行检验。我们坚持每周做一次线上数据切片分析把过去七天所有报警截图逐一回看判断真伪再统计不同工况下的行为分布。只有这样才能发现“中控室已确认但系统没报”这类线下测试根本不会暴露的问题。6.2 模型迭代闭环现场样本回流与周更模型不是上线就完事这个项目里最大的体会是算法团队和港口现场要形成一个持续的反馈回环。流程大致是现场报警数据每天自动入库标注工具按规则挑出高置信和低置信样本算法工程师每周复盘把人工复核结果加入训练集增量训练发布新模型到边缘盒子灰度验证没问题再全量推送。一次迭代周期的速度决定了系统适应现场变化的能力。后来把整个流程做成半自动从数据回流到新模型发布一周内可以完成。港口物料特性、季节环境变化都会影响模型表现夏季暴雨天和冬季干冷天的图像特征完全不同不持续迭代模型会悄悄退化。6.3 下一步皮带只是一根线业务覆盖是一个面做完皮带检测后视角从“一条皮带的保护”扩展到了“全流程设备健康管理”。同一套边缘AI架构底层换数据集、换模型就能复用到斗轮机、堆料机、装船机等大型设备的视觉监测上。皮带检测是整个港口视觉中台的第一根线也是经验最丰富的一条线。比如翻车机区域可以识别料斗堵煤和洒煤堆料机悬臂处可以监控料流均匀性装船机机身可以检测溜筒磨损和料流跑偏。这些任务在算法架构上高度相似真正需要投入的还是数据侧和现场侧。如果所在企业准备做类似的事最真诚的建议是不要急着上服务器、上平台。先找一条风险最高的皮带装一台相机、一个边缘盒子把“检测准确率误报控制”这个最小闭环跑通。数据积累和运维流程跑顺之后再横向扩展比一开始就铺大平台稳妥得多。就像开头说的皮带AI检测识别算法表面看是机器学习问题实际上是一个业务理解、工程落地、运营闭环的综合问题。最后能把它变成港口大动脉的24小时守护神靠的并不是某个模型结构多先进而是把现场业务规则、数据采集规范、告警分级机制、模型迭代流程这些看起来“不性感”的东西一点点磨扎实了。这个项目之后我自己做工业视觉项目的方式也变了先看现场一周再谈算法。