凌晨两点半，港口中控室的值班员打了个哈欠。屏幕上突然弹出一条红色报警：三号翻车机下方输送带疑似纵向撕裂，置信度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 边缘算力与模型压缩：在受限功耗内跑出实时检测
现场点位多，不可能每个点都回传原始视频到中心服务器，带宽和存储都会爆。方案是“边缘推理 + 中心汇总”：每个点位一个边缘计算盒子，负责跑模型、输出报警结果，只回传报警截图和视频片段；中心平台只做告警展示和数据处理。
边缘盒子我们对比过几款：
| 平台 | 算力 | 功耗范围 | 实测帧率（轻量检测模型INT8） |
|---|---|---|---|
| Jetson Orin Nano | 约20 TOPS | 7-25W | 15-20 FPS |
| Jetson Orin NX | 约100 TOPS | 10-25W | 40-60 FPS |
| 国产低功耗NPU盒子 | 视型号而定 | 5-15W | 10-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小时守护神，靠的并不是某个模型结构多先进，而是把现场业务规则、数据采集规范、告警分级机制、模型迭代流程这些看起来“不性感”的东西一点点磨扎实了。这个项目之后，我自己做工业视觉项目的方式也变了：先看现场一周，再谈算法。
