铁路施工安全监测：基于YOLO的安全帽与反光衣识别实践

1. 项目整体思路与场景需求拆解1.1 铁路施工安全监测为什么需要图像识别每天清晨成千上万名铁路工人沿着轨道线进入作业区段。他们有的在路基上检修有的在高架桥下清理有的在隧道口附近搬运物料。铁路施工环境和其他工地最大的不同在于作业范围是一条狭长的线性区域人员分散、战线长、环境光线变化剧烈而且常常需要在列车运行间隙进行紧张的天窗作业。正因为这种特殊的作业模式传统的人工盯防和安全员巡检很难做到全时段、全覆盖的监管漏掉一个人没有穿反光衣或者没戴安全帽在高速列车通过的线路上就是极大的安全隐患。过去的做法是安全员每隔一段时间巡查一遍或者靠班组长口头提醒。我听一些一线管理者说过最怕的就是作业人员觉得“就一会儿不戴没事”或者天气热的时候把安全帽摘了透透气。等到安全员走过来发现的时候可能已经过了十几分钟这期间一旦有列车接近后果不堪设想。所以这几年行业里开始想用视频监控加算法自动识别的方式把人工盯防变成机器盯防。这个项目做的就是铁路沿线作业场景下的智能安全监测核心技术路线是在工人佩戴的头盔或者现场布设的摄像头中运行深度学习目标检测模型实时识别三类关键防护要素——安全帽、反光衣、人员本身。一旦发现有人未佩戴安全帽或未穿反光衣立即告警并联动现场广播或管理后台推送。说得直白一点就是教会摄像头“看懂”谁做好了防护、谁在裸奔。1.2 方案选型端侧识别与平台识别的取舍做这个方向的技术验证时第一件要决定的事就是算法跑在哪里。市面上有几种做法各有利弊。第一种是纯平台识别。摄像头把视频流传到机房GPU服务器由服务器上的深度学习模型做推理。好处是算力充足模型可以用大网络精度上限高坏处是铁路沿线的网络条件常常不理想很多施工区段在山区甚至隧道里无线传输延迟高、带宽不稳定有时候视频传不上去识别就变成空转。第二种是端侧识别。把模型直接部署在工人佩戴的头盔或布设现场的边缘计算设备上视频流在本地完成推理只把告警结果上传。好处是实时性强断网也能工作坏处是边缘设备的算力有限模型要压缩、要量化精度会有所牺牲。这个项目最终采用的是端云结合的方式现场前端设备运行轻量化模型做第一道识别同时把关键帧上传到服务器端的更强大模型做复核。这样做的好处是常规场景下前端就能把绝大多数问题识别出来遇到光线复杂、遮挡严重的边缘情况时平台端的模型可以用更大更准的网络重新判断一次降低漏报和误报。用通俗的话讲前端设备是“哨兵”负责第一时间发现问题、及时喊话服务器是“值班长”哨兵拿不准的画面值班长再仔细看一遍。两层配合下来效果一般会比任何一个单层方案稳定不少。2. 模型选型与检测算法核心解析2.1 目标检测模型怎么选从YOLO系列谈起目标检测这个领域这几年几乎被YOLO系列统治了。从最早的YOLOv3开始到后来的YOLOv5、YOLOv7、YOLOv8再到最新的YOLO11也有叫YOLOv11的每一代都在精度和速度上交替升级。铁路施工安全监测这个场景最大的优势是检测目标非常固定——人、安全帽、反光衣类别少形态相对统一最大的难点是环境变化剧烈——逆光、夜间、雨天、灰尘、远距离小目标干扰因素非常多。我自己的经验是做这类固定小类别的场景不需要一上来就追求最大的模型。很多人有个误区觉得模型越大越准在实际工程里不是这么回事。大模型确实mAP会高一些但推理速度慢、部署困难尤其要放到边缘盒子或者头盔端参数一大就根本跑不动。做工程选型要在“够用”的前提下挑最小的模型把精度优化留给数据和训练策略。以YOLO系列为例YOLOv8n/V8s是轻量级的代表参数量分别只有约310万和1110万在边缘设备上可以跑到实时帧率。如果追求更高精度YOLOv8m或者YOLO11m会更好一些。做铁路施工识别这类目标不算特别小的场景人员通常在画面中占比中等YOLOv8s起步是合理的如果现场测试发现小目标漏检多再升级到YOLOv8m。选型的时候核心要对比三类指标参数量决定能不能塞进边缘设备推理耗时决定能不能实时响应单帧处理时间要小于视频帧间隔mAP50和mAP50-95决定检测精度是否达标我习惯的做法是先用同一批测试集跑三个候选模型对比它们的精度和速度曲线选出那个“性价比最高”的。如果精度差不到2个点但速度快60%那几乎不用犹豫选快的那个。2.2 精度评估指标别只看mAP工业场景要盯着PR曲线做算法评估时很多人习惯只看mAP一个数。但在安全监测这种场景mAP会“骗人”。原因很简单mAP是全体类别精度的平均如果安全帽、反光衣、人这三类中的某一类做得特别差但其他两类做得不错mAP可能还是很好看实际使用中那一类却在持续漏报。所以我在做项目复盘时格外看重每一类的单独精度和召回率。尤其是反光衣识别这一类的特征和背景差异非常大反光条会在光线下呈现亮银色如果模型训练不到位很容易把白色反光条误判成别的什么东西或者把穿白色衣服的人当成穿了反光衣。每个类别的PR曲线是判断这类问题最直观的工具——曲线左下角偏厚说明低置信度时误报多曲线右上角不够饱满说明高阈值时漏报明显。另一个容易被忽略的指标是F1-score随置信度阈值的变化曲线。实际部署时你需要选定一个置信度阈值比如检测到安全帽的概率超过0.5就判定为“佩戴”。阈值设低了误报多工人们会被无意义的告警搞烦阈值设高了漏报多安全风险滋生。F1曲线能帮你找到那个平衡点。根据我做类似项目的经验安全帽识别阈值设在0.45到0.6之间反光衣识别阈值设在0.5到0.7之间是比较合理的范围但具体要基于测试集的PR曲线来定不能拍脑袋。2.3 训练数据策略反光衣识别比安全帽难在哪反光衣识别是这个项目里最有挑战性的部分。安全帽的形状相对固定无论从哪个角度看轮廓都像个半圆或椭圆模型学起来比较容易。反光衣就不一样了——它是一个“柔性物体”穿在人身上会褶皱、变形而且从背后看反光衣的视觉效果和从侧面看完全不同再加上反光条在不同光线下的表现差异极大白天太阳直射时反光条几乎看不出反光效果夜间被车灯照到又亮得刺眼。解决这个问题的核心思路是数据多样性。我训练反光衣识别模型时刻意从多个时段、多个角度、多种姿态下采集样本。比如工人正面、背面、侧面的反光衣样本各占一定比例晴天、阴天、雨天、清晨、傍晚、夜间不同光照条件的样本都要有蹲姿、弯腰、抬手、行走等不同姿态的样本不能缺反光衣穿在棉衣外面、单衣外面等不同厚度的样本也要覆盖数据比例上我建议一个比较保守的策略反光衣样本数量至少是安全帽样本的1.5到2倍。这不是因为反光衣更难检测就暴力加数据而是因为反光衣的类内差异确实比安全帽大模型需要更多样本才能学到稳定的特征表达。另外还有一个细节容易被忽略——负样本。很多人训练安全帽检测只收集“戴了帽子”的正样本和“没戴帽子”的负样本忘了收集“手里拿着帽子”“帽子挂在一旁”这类干扰样本。结果部署后发现有人把帽子拿在手里经过摄像头时模型会反复报警“未佩戴安全帽”。这是典型的上下文理解缺失。适当加入这些“模糊状态”样本并且标注为对应状态能显著降低误报率。3. 核心实现环节数据集构建与标注规范3.1 数据集怎么采集现场实拍为主网络补充为辅我见过不少团队沿着“网上找公开数据集”的思路起步结果训练出来的模型一到真实铁路环境就“翻车”原因很简单——公开数据集里的施工场景以建筑工地为主光线、背景、人员着装和铁路沿线作业差异非常大。铁路沿线有铁轨、道砟、接触网支柱、信号机等特有元素这些背景特征会影响模型的注意力分配。所以这个项目的数据集必须现场实拍打底。具体操作流程是这样的在多个不同施工区段布设临时摄像头连续录制一周不同时段的视频从视频中按时间间隔抽帧每三秒抽一帧得到基础图像集对基础图像进行筛选去除完全重复、严重模糊、大面积遮挡的帧再用网络公开的施工场景图片补充多样性重点是补充不同地区、不同季节的穿着差异抽样时不能随机抽要刻意控制帧的分布。比如夜间样本如果只占比2%训练出来的模型夜间的表现大概率不达标。我在项目中通常会把全天候样本按时段分成五类——清晨、白天、傍晚、夜间、光线转换期每一类在训练集里不少于8%。还有个实操中特别好用的技巧同一段视频里连续帧的图像非常相似如果抽出来的训练帧太“连续”模型会在相似的样本上过拟合。我在抽帧时会每隔几秒跳一次并且从多条视频里交叉抽样确保同一个人的同一姿态不要出现太多次。3.2 标注规范的三个关键坑标注质量直接决定模型上限。这个项目涉及的标注有三个容易出问题的点。第一个坑是遮挡时的标法。铁路工人经常互相遮挡或者被工具车、物料堆挡住半边身体。有人习惯把被遮挡的目标也画完整框这会让模型学到“被遮挡的物体长这样”的错误特征。我建议按可视区域标注只有超过一半可见且人能明显判断类别的目标才标注严重遮挡的目标跳过不标。这样模型学的特征更干净。第二个坑是反光衣的标注边界。很多标注人员会把反光衣的荧光面料和反光条一起框进去甚至把衣服下摆之外的空隙也框进去。我要求标注时框出反光衣主体的外轮廓——以穿着后的视觉轮廓为准尽量贴合身体不包含过多背景。这个细节对检测框的回归精度影响很大框太松会让IOU计算偏低影响NMS后的检出率。第三个坑是安全帽类型的多样性。铁路施工的安全帽有普通安全帽、带面罩的安全帽、带耳罩的防寒安全帽等多种类型。不同颜色、不同品牌、不同新旧程度的帽子反光特性完全不一样。标注时不能只打“helmet”这一个标签建议按子类和颜色做统计确保各类别样本数量接近避免模型只认识黄色安全帽而漏掉白色安全帽。标注完成后我还会做一次人工复审随机抽20%的标注框对比原图检查框的贴合度和类别错误。如果一次训练的验证集mAP明显偏低先不急着调模型参数回头检查标注问题往往会有惊喜。3.3 数据增强的取舍翻转要注意反光衣文字深度学习训练中数据增强是提升泛化能力的利器。在头盔、反光衣识别的场景里最常用的增强手段包括随机亮度调整、对比度调整、高斯模糊、HSV颜色抖动、随机裁剪等。但有一个增强手段需要特别注意——水平翻转。原因很反直觉反光衣上通常印着“铁路工务”或“施工安全”等文字水平翻转后文字变成了镜像虽然模型学的是纹理特征不是语义但翻转后的文字区域会产生一种“伪纹理”如果翻转样本比例过高模型会将镜像文字和反光衣关联反而干扰特征学习。我的做法是水平翻转的样本控制在20%以内甚至可以关掉水平翻转改用轻微角度旋转来增强视角多样性。另一个容易踩坑的是夜间场景的增强处理。铁路施工现场夜间往往只有应急灯和头灯光源画面整体偏暗、噪点多。直接套用白天数据的亮度增强策略会让模型把“黑暗环境的复杂纹理”学成“夜间场景的典型特征”导致白天误报增多。我建议夜间数据单独处理——对夜间样本使用专门的亮度调节策略加高斯噪声模拟传感器噪点而白天样本用常规增强。混合训练时对夜间样本做小幅过采样一般按1.2到1.5倍的采样倍率这样可以保持夜间识别能力不被压制。4. 部署架构与推理优化实战4.1 边缘端推理框架的选择模型训练完成后面临的下一个问题是部署到哪、用什么框架跑。当前主流的边缘推理框架有NVIDIA的TensorRT、OpenCV的DNN模块、ONNXRuntime以及各家芯片厂商的自研框架。我目前最常用的组合是训练用PyTorch导出ONNX再根据需要转成TensorRT或直接跑ONNXRuntime。TensorRT在NVIDIA显卡上确实能跑出极致的推理速度量化后小模型提速明显。但如果前端设备是Jetson Nano或者Jetson Orin这样的嵌入式平台用TensorRT是正路。如果前端是普通的ARM盒子或者x86工控机且没有N卡那ONNXRuntime配CPU推理反而是最省事的方案。这里插一句硬件选型的体会。我做过的类似项目里对头盔端的设备要求是功耗低于8瓦、支持硬件解码、推理延迟低于150毫秒。市面上的边缘计算盒子五花八门实际筛选时我建议用三步法跑通ONNX模型看CPU推理延迟延迟在150毫秒以上的直接排除实测连续运行8小时以上看是否会过热降频接入摄像头实测视频流处理看端到端延迟从画面出现到告警弹出现场传输的实时性远比很多人想象的重要。铁路天窗作业时间非常宝贵如果告警延迟超过10秒等管理人员看完消息冲到现场工人可能已经开始下一轮作业了。低延迟是安全监测系统的生命线。4.2 模型压缩量化前后精度对比端侧设备的算力通常是数百GFLOPs而YOLOv8s模型在FP16精度下大约需要几十GFLOPs看起来能跑动但实际部署时还要同时运行视频解码、图像预处理、追踪逻辑等多个任务计算资源非常紧张。所以模型压缩是这个项目的必修课。最常用的压缩手段是INT8量化。把模型的权重和激活值从FP32压缩到INT8模型体积缩小约四倍推理速度可以提升1.5到3倍。但量化是有代价的——精度会掉。尤其对反光衣识别这种依赖精细纹理特征的任务量化后反光条的弱特征可能被量化噪声淹没导致召回率下降。我推荐的量化策略是“管线式量化校准”用现场采集的500到1000张代表性图片作为校准集运行模型并统计各层的激活值分布再确定量化参数。通用的量化工具默认校准集可能来自COCO等通用数据集现场特征分布完全不同校准效果很差。用现场数据校准后量化精度损失通常可以控制在1到2个mAP点以内。如果量化后反光衣类别掉点明显还有一个补救方案混合量化。把模型中对反光衣特征敏感的层保持FP16精度其余层用INT8。TensorRT支持按层指定精度实际操作中定位敏感层需要一点点试我一般先用量化前后的逐层精度对比脚本找出哪些层的输出差异最大锁定后混合量化往往能挽回一半以上的精度损失。关于推理速度我提供一个本地的实测参考数据YOLOv8s模型在Jetson Orin Nano上FP16推理约15到25毫秒每帧INT8约8到12毫秒每帧在Jetson Nano上INT8约30到45毫秒每帧。如果使用CPU推理一般的ARM盒子跑YOLOv8s大约在100到200毫秒每帧之间。帧率低于10FPS时运动中的行人在相邻帧之间位移较大追踪算法容易跟丢所以要尽量保证至少15FPS的处理能力。5. 全过程实操记录从训练到上线的完整流程5.1 模型训练的关键参数与训练技巧我用YOLOv8系列为例给出一个经过验证的训练配置模板。数据集类别设置为三个person、helmet、safety_vest。如果你还会顺带识别安全帽颜色或者反光衣穿戴状态可以在标注时扩展标签体系。核心训练参数建议这样配输入分辨率1280x1280或640x640。320到640之间的分辨率对小目标检测影响显著640起步若目标在画面中占比很小再升到1280训练批次16到32之间小批次在数量少的数据上有更好的泛化但不建议低于16初始学习率0.01配合余弦退火策略训练轮数150到300轮之间数据集5000张以下时先试150轮看loss曲线是否过拟合优化器SGD或AdamW小数据集用AdamW更容易收敛早停和模型保存策略也很重要。建议不仅保存最优模型还要按训练轮数每隔25轮保存一个检查点。有时候全局mAP最优的模型反而在夜间或遮挡样本上表现不佳这时候回退到较早的轮次可能更均衡。我用过一个调优技巧训练结束后用验证集按类别跑逐类mAP对表现较差的类别适当延长训练或做针对性数据增强重新微调几个轮次效果往往比重新完整训练更好。这里也提一下数据规模参考。我在做类似项目时最终训练集在8000到12000张图的规模安全帽正样本约8000个实例反光衣正样本约10000个实例人员约15000个实例。这个规模下训练出来的模型在真实环境中的mAP50一般在0.85以上基本够用。5.2 告警联动设计识别到问题之后怎么办模型识别出未戴安全帽或者未穿反光衣只是整个系统的第一步。告警如何触达现场人员和管理人员直接决定系统的价值。我在项目中设计了三级联动第一级是现场声光报警。边缘设备检测到违规后通过继电器控制现场的声光报警器同时通过喇叭自动播报预录好的语音比如“请注意某号作业区有人未穿反光衣”。这一步的延迟要求最严所以我把它放在边缘端完成不依赖平台。第二级是管理后台推送。在平台端检测到违规后自动截图标注违规类别和位置信息通过App、短信或Webhook推送给当班安全员和值班管理人员。第三级是统计报表。日终自动生成各工区、各班组的安全告警统计包括违规类型分布、高发时段、高发位置便于管理者做针对性的安全教育和整改。联动逻辑的细节也很多。比如防抖逻辑同一目标连续三帧都判定为“未佩戴”才告警避免单帧误判导致告警轰炸去重逻辑同一目标在告警后的30秒内不重复告警除非目标离开画面后重新出现分级逻辑夜间或列车接近时段告警优先级自动提高。这些工程细节加起来才是一套能真正在生产环境中稳定运行的系统。一个比较具体的踩坑经历早期某次部署中光线一变化系统就疯狂报警后来排查发现是模型把远距离穿深色衣服的人员误判成了未穿反光衣。调低反光衣检测的阈值看似能解决问题实际上损失了真实违规场景的识别率。后来通过增加“穿深色衣服的人”负样本和调整夜间亮度增强参数误报率才降下来。这类问题在实验室阶段很难暴露必须在真实场景中反复调试才能磨合好。5.3 运行监控模型上线不是结束模型上线只是开始。安全监测系统最怕的不是模型不准而是模型“偷偷退化”而没人发现——比如某个工区新换了照明灯画面亮度变了模型精度悄然下降管理人员看到的告警数量每天在减少还以为安全状况变好了。为此我在项目中配置了“漂移预警机制”每天统计告警数量、检测置信度均值、各时段告警分布当某个指标偏离前7日均值超过一定幅度时自动通知算法工程师介入复盘。置信度均值下降通常意味着模型对当前画面特征开始“不自信”这就是漂移的早期信号。另外现场收集的误报/漏报截图要定期回流入训练集。我建议每周从后台导出一批被人工标记为误报的检测样本归入负样本配合两周一次的小规模微调确保模型能持续适应现场的变化。6. 常见问题与排查技巧实录6.1 高频故障速查表我在这个项目以及类似的施工安全识别项目上踩过不少坑整理成一张速查表按“现象-原因-解决方案”的格式列出方便后续直接排查。现象可能原因排查与解决方案夜间反光衣识别率骤降夜间反光条因人工光源过曝反白纹理细节消失增加夜间样本改用HDR模式摄像头在增亮后做对比度增强雨天误报增多雨水在镜头表面形成水痕产生类似反光条的高亮纹理加装疏水涂层模型训练时叠加雨天噪声和条纹增强安全帽被漏检但人检正常安全帽样本中缺少目标俯视视角增加俯拍角度摄像头在训练集中补充俯视安全帽样本户外强光下安全帽泛白白平衡过曝导致帽体纹理丢失调低摄像头曝光训练时提高白天样本的亮度方差多人密集场景重复告警检测框抖动导致同一目标触发多次告警引入IOU追踪器按检测框轨迹判断目标ID同一目标30秒内去重检测正常但告警延迟大平台端复核链路过长将告警判定逻辑移入边缘端提升服务器间网络带宽模型量化后误报多校验集代表性不足用现场采集的500张图覆盖各个时段作为量化校验集重新量化某一时期误报暴增施工现场新增设备或车辆背景特征变化收集新背景样本加入训练集做增量微调6.2 三个印象深刻的排障实战第一个是夜间干扰光源问题。某次在现场测试时夜间画面中明明没有工人系统却频繁报警说检测到“未穿反光衣”。查看原始画面发现远处高架桥上驶过的汽车灯光在轨道路面上拉出一道长长的光带光带的形状和颜色与反光衣非常相似。后来在模型中增加了一个“光照超亮区域过滤”的前处理规则凡是画面中像素值超过一定阈值的连通域面积超过安全帽或反光衣正常尺寸三倍以上就自动忽略误报立刻降了下来。第二个是安全帽“戴一半”的边界状态。铁路工人有时候会把安全帽戴得很靠后露出额头从正前方摄像头看帽檐投影和脸部重叠模型难以判断是否佩戴。针对这个情况我在标注规范中增加了“半佩戴”类别并专门收集了这类样本作为单独的负类进行训练。同时调整了判定逻辑只有检测到安全帽类别且置信度超过阈值才判定为“已佩戴”未检测到则一律进入告警流程不设中间态。第三个是反光衣反射率异常问题。部分老旧反光衣的反光条已经老化在夜间灯光下的反射强度远低于新衣服模型经常把它们当作没有穿反光衣。排查后发现是训练集中的夜间样本大多来自新反光衣的高反射状态模型在夜间严重依赖“高亮反光条”这一特征。后来专门收集了一批老旧反光衣的样本并在夜间样本中加入了不同褪色程度的图像模型泛化能力明显提升。6.3 设备层面的两个高频问题硬件层面我遇到过的两个典型问题分享出来。一个是网络波动导致视频流断连。铁路沿线的4G/5G信号不是每个位置都稳定尤其是隧道内的作业区段。后来在边缘设备上加了“断网缓存”机制——本地检测结果先写进一块循环缓冲区网络恢复后再补传同时告警不依赖平台现场声光提示始终在线。这样断网只影响后台统计不影响现场安全响应。另一个是电源稳定性问题。边缘设备的适配器在工地环境中容易松动或受电压波动影响设备随即重启。经过排查后统一改用宽压电源模块并加装防脱扣设备运行稳定性从“频繁掉线”提升到了“全天在线”。这些硬件层面的“笨功夫”在项目落地时往往是决定成败的隐形因素。7. 从单点识别到系统化安全管理的延伸思考这个项目做完之后我最大的感受是深度学习模型只是这套系统的一部分真正的价值在于如何把它嵌入到现有的安全管理流程中。目前系统解决的是“有没有佩戴”的问题但铁路施工安全的很多细节还没有被完全覆盖。比如反光衣是否完整拉上拉链拉链敞开时从侧面看反光效果和穿着完整差别很大、安全帽的下颚带是否系紧帽带悬空时安全帽在坠落冲击中起不到保护作用、工人在列车接近时是否及时下道避车这需要把列车定位信息与人员位置信息结合起来判断。这些需求完全可以在现有的目标检测基础上通过加入姿态估计、时序行为识别等技术来扩展。还有一点值得思考的是算法和人的分工。模型识别再准也不能替代安全管理员的判断力和威慑力。这个系统的价值不是“用AI替代人”而是把一线管理人员从“反复盯屏幕”的低效劳动中解放出来让他们有更多精力做安全教育和现场协调。系统负责发现“有没有”人负责处理“为什么”和“怎么改”。我在实际部署中反复调整过告警消息的措辞后来发现一个有意思的现象告警越频繁工人越麻木告警越精准工人越重视。把系统从“满头警报”调教到“有稀有准”反而让工人养成了主动穿戴防护装备的习惯。如果后续要继续迭代这个项目我建议优先做两件事一是把人员身份识别加进去简单说就是“知道是谁没戴帽子”而不是“有个人没戴帽子”这需要人脸识别或工牌识别配合能极大提升管理的针对性二是把检测结果和施工计划联动比如通过后台导入当天的作业计划、人员名册和区段安排算法自动匹配“这个区段这个时间应该有几个人、谁负责什么岗位”一旦识别到人员数量或防护状态与计划不符就告警就能做到施工安全的全要素闭环管理。回到最开始的那个问题为什么铁路施工安全监测比想象中更需要深度学习因为铁路沿线的安全风险是流动的、分散的、瞬时的人工盯防赶不上风险变化的速度而摄像头加上一个跑得动的检测模型可以做到“每一秒都在盯”。这条技术路线在高危行业里的复制性很强电力巡检、矿山作业、港口码头等场景只需要把类别标签换成对应行业的防护装备和作业规范整套思路几乎可以平移复用。项目的价值也恰恰在这里——一旦跑通改变的不仅是一条线路的安全管理方式更是一整类边缘场景的作业监管逻辑。