
做拌合楼管理系统以来车辆进出这一块一直是业务方盯得最紧的环节。以前靠门卫拿本子记车牌、记时间、记装料方量车一多就乱回头对账经常扯皮。老板催着上自动化说白了就是要一套能自动记录车辆进出的方案。我这次负责的是海康威视车牌识别摄像头的安装调试加上和拌合楼管理软件的数据对接折腾了差不多一周总算是把整条链路跑通了。这篇文章就把这个过程完整记录下来包括我为什么这么选型、安装时踩了哪些坑、回调数据怎么解析、又如何跟现有业务系统关联希望能给正在做类似项目的朋友一些参考。这套方案适用的人群其实挺广的不管你是做搅拌站、物流园、停车场还是厂区门禁只要是“车进来要登记、出去要核对、最好还能自动匹配业务单据”的场景都可以参考。下面我按几个阶段来讲从整体设计思路开始再到硬件选型和安装然后是软件对接和调试最后是问题排查完整还原整个实施过程。1. 整体设计与方案选型为什么选择海康车牌识别相机加HTTP回调1.1 拌合楼场景的核心需求拌合楼的生产流程大概是这样的混凝土罐车从搅拌站出发去工地回来之后要重新装料运输车运来沙石、水泥、粉煤灰等原材料也要进场过磅。在这些环节里车辆身份确认是第一步而且直接关系到后续的计量、结算和生产调度。项目组经过和业务方几轮沟通把需求归纳成了三条车辆进场时自动识别车牌系统记录进场时间、车牌号、抓拍照片。车辆出厂时再次识别判断是否需要称重、核对装料任务。识别结果必须实时推送到管理软件由软件决定抬杆还是拦截、生成记录还是告警。这三条看着简单但实际落地时涉及硬件选型、网络规划、软件接口设计、异常处理等一堆细节任何一个环节掉链子都会导致整个流程卡住。1.2 两条技术路线我为什么最终选了HTTP回调海康的车牌识别摄像头对接路线基本可以分成两种一种是利用相机自身的智能分析能力将识别结果通过HTTP回调推送到指定服务器另一种是通过海康SDK主动拉取视频流、图片或报警信息。我这边最终选了第一种原因比较实际SDK方式需要自己在服务端起一个常驻进程来处理设备连接还要处理断线重连、多设备并发开发量和维护成本都更高。HTTP回调方式下相机识别到车牌后直接把结构化数据POST到服务器我只需要写一个接收接口就行开发量小了很多。相机端已经完成了车牌识别的算法处理识别准确率和速度都比自己用OpenCV从零搞靠谱而且完全不影响抓拍速度。两种方案的对比如下对比维度HTTP回调方案SDK主动拉取方案接口复杂度只需写一个接收HTTP POST的接口需要处理SDK初始化、登录、报警监听等开发工作量低约1-2天可完成核心对接高需要投入更多时间做底层封装实时性相机主动推送识别后毫秒级送达需要轮询或监听做到实时也不难稳定性依赖网络和回调接口稳定性依赖SDK长连接遇到弱网容易断线扩展性多台相机只需配置不同回调地址需要管理多路SDK连接稍显笨重从我们拌合楼的现场情况来看一般只有一个主入口和一个出口相机数量不多HTTP回调方案的简洁性优势非常明显。而且海康的文档和网上的参考资料也比较多就算对接过程中遇到问题排查起来也方便。2. 设备选型与硬件安装调试2.1 设备选型与关键参数理解海康的车牌识别相机型号比较多常见的有枪机形态的也有带补光灯和防护罩的一体机。我这次选的是自带LED补光灯的网络一体化车牌识别相机这种机器对环境适应性比较好白天晚上都能用而且体积小方便在门卫室旁边立杆安装。选型的时候有几个参数一定要确认清楚不然买回来可能跟现场对不上传感器尺寸决定了成像质量尤其夜间暗光环境下的表现。焦距决定了识别距离和视野宽度安装距离固定后要按这个参数推算。识别距离海康相机产品页会标一个最佳识别距离范围比如3米到10米安装时让车牌处于这个范围内。补光灯类型和亮度LED补光灯在白光模式下如果太亮容易造成车牌反光太暗晚上又看不清一般建议装好之后根据实际图像再调。防护等级室外安装必须选择IP66或以上的机器防雨防尘才有保障。刚开始我不太清楚焦距怎么选现场尺子量了一下安装位置到车牌通行位置大约6米然后找了一台6mm焦距的机器实测下来车牌在画面中的宽度占比刚好合适识别率很稳。这个参数如果不确定宁可选焦距小一点让视野大一些也别选太长的焦距导致车牌出框。2.2 安装高度、角度与补光灯的调整安装位置直接决定识别效果这一块我前前后后调了三次才达到稳定状态。第一次装的时候图省事相机直接固定在门卫室墙上高度大约2米往下斜着拍。结果发现车一开进来车头高度各不相同小车拍得到罐车车头高车牌经常超出画面上边缘。后来把安装高度调整到3米左右角度往下压了一些视野宽度也重新覆盖到车道中部问题才算解决。角度方面有一个经验值相机光轴与车牌平面之间的夹角尽量控制在20度以内夹角太大时车牌字符会产生透视角变形识别率会明显下降。实际测试中我用手持方式模拟了几个安装角度确认了20度是个分界线超过这个角度以后识别结果里的字母和数字开始出错。补光灯的角度也很关键。LED补光灯本身是发散光如果调得太朝下路面反光会影响识别太朝上则起不到补光效果。最后我按说明书把补光灯调到和相机镜头大致平行的方向稍微偏下两三度夜间拍摄的亮度就自然了。安装过程中还有几个细节容易忽略相机电源线和网线要留有余量避免接头处的胶布老化后进水引起短路。尽量使用防水网线接头或者给网口做防水处理不然下雨天网络会频繁断开。如果现场有雷电天气较多的可能需要做好接地或者在弱电箱里加装网络防雷器别省这个钱。2.3 网络规划与设备基本配置车牌识别相机本质上是网络设备安装调试前最好先规划好网络。我们现场的实际情况是门卫室有一台交换机通过光纤和办公楼机房连起来。相机接在门卫室交换机上服务端程序跑在机房的服务器上两边在同一个局域网内这给调试省了不少麻烦。如果你那边现场是独立网段记得让网络管理员做好路由确保相机和服务端能互相访问。相机开机后第一件事就是改IP。海康相机默认IP是我用了笔记本直连相机先把IP改到现场网段再接入实际网络。这里有一点容易犯迷糊改完IP之后要确认掩码和网关都设置正确否则设备能ping通但数据包出不了网段。配置方面主要做了这么几项设置相机时间并开启NTP校时和服务器保持时间同步否则抓拍记录的时间会偏。调整OSD叠加把时间、车牌号叠加到抓拍图片上这样现场查图时一目了然。开启“智能分析”里的车牌识别功能设置触发方式为“视频触发”或“线圈触发”。我们门口没有地感线圈所以选了视频触发。在真正开始软件对接之前我习惯先用设备的Web管理页面做一次基本验证通过浏览器登录相机查看实况画面确认车牌识别区域画框正常、车牌字符识别正确。这一步过了才说明相机侧的工作基本完成后面进入软件对接环节。这里要提一个很烦的问题新版浏览器访问海康Web管理页面经常加载不出插件或者画面黑屏。我最后用了一台旧电脑装Win7和IE11兼容模式才把配置页面稳定打开。如果你要远程配置也可以看看设备是否有配套的客户端软件我试下来觉得客户端反而更稳定。3. 软件集成从抓拍到入库的完整链路实现3.1 数据链路设计与相机端回调配置整条数据链路可以简单概括为车辆进入识别区域 → 相机抓拍并完成车牌识别 → 相机向服务器发送HTTP POST请求 → 服务器解析数据 → 业务判断 → 写入数据库 → 前端页面展示。这个设计里我比较关注的是回调链路是否稳定。相机只负责推送识别结果后续业务操作全部交给服务端服务端挂了最多丢记录不会影响抓拍和识别。从实际运行来看相机端的识别独立性比我想象的要好即使服务器短暂不可用恢复后重新触发识别仍能正常推送新数据。相机端的回调地址配置在Web管理页面里一般在“事件管理”或“智能分析”相关菜单下需要填写服务器IP、端口和路径。我这边填的是http://:8080/api/plate/receive端口要保证防火墙放行。我第一次配置完之后一直收不到数据排查了半天最后发现是服务器防火墙没有放行8080端口放行之后马上就有数据进来了。这种低级坑大家提前留意。另外海康的HTTP回调地址支持基本鉴权但我在测试中发现不开启鉴权也能正常推送。考虑到内网部署环境的安全级别我没有启用鉴权如果你部署在公网环境强烈建议还是开启用户名密码验证。3.2 服务端接收回调与车牌数据解析服务端我用的是Python的Flask框架简单、好调试、文档也多。写一个接收POST请求的接口把相机推送过来的JSON数据解析出来关键字段提取之后做下一步处理。海康相机的回调数据格式相对固定核心字段包括{ ipaddress: , timeval: 2024-05-20 14:32:18, chanID: 1, carInfo: { plateNo: 京A12345, plateColor: 蓝, vehicleType: 小型车 }, imageUrl: http:///ISAPI/Streaming/channels/101/picture, snapshotTime: 2024-05-20 14:32:18 }下面是简化后的接口代码from flask import Flask, request, jsonify import datetime, json app Flask(__name__) (/api/plate/receive, methods[POST]) def receive_plate(): try: data request.get_json(forceTrue) ip data.get(ipaddress) plate_no data.get(carInfo, {}).get(plateNo) plate_color data.get(carInfo, {}).get(plateColor) vehicle_type data.get(carInfo, {}).get(vehicleType) image_url data.get(imageUrl) trigger_time data.get(timeval) # 在这里做业务处理比如查询白名单、判断车辆类型 save_plate_record(plate_no, plate_color, vehicle_type, image_url, trigger_time) return jsonify({code: 0, message: ok}) except Exception as e: print(parse error:, e) return jsonify({code: 1, message: fail}) if __name__ __main__: app.run(host, port8080)这里有一个细节值得单独说一说海康回调返回的“plateNo”字段里车牌汉字是GBK编码的不是常规的UTF-8。如果你的服务端没有做正确的字符集转换收到的会是一串乱码。我当时第一次解析时就遇到了后来在请求头里看到返回的是GBK编码转换一下就好了。字符集问题在工业设备对接中非常典型。很多设备厂商的固件为了兼容国内项目默认字符串编码都是GBK而我们的服务端框架默认按UTF-8处理两者不统一就会出问题。处理方法是在接收数据时先按二进制读入用GBK解码再统一转成UTF-8存库。3.3 业务联动白名单、过车记录与数据库入库解析出车牌号之后就要和拌合楼管理软件的业务逻辑连起来了。我设计了三层判断第一层判断车牌是否在白名单内。白名单里存的是搅拌站常用车辆比如自有罐车、长期合作的物流公司车辆这些车辆进出场时直接放行并自动生成记录。第二层判断车辆是否关联了生产任务。罐车来装料往往对应着一个任务单号车牌识别通过后系统自动在任务列表里检索有没有待执行的装料任务有则匹配并更新状态无则提示人工介入。第三层判断车辆类型。运输原材料的货车和混凝土罐车的业务逻辑不同货车可能要引导去过磅称重罐车则直接去装料口所以车辆类型字段也要一并处理。数据库这一块我建了这样一张过车记录表字段名类型说明idbigint主键自增plate_novarchar车牌号码plate_colorvarchar车牌颜色vehicle_typevarchar车辆类型image_urlvarchar抓拍图片地址pass_timedatetime过车时间directionint进场/出场matched_taskvarchar关联任务单号数据库入库的逻辑也比较直接但有一个点我想强调一下并发问题。拌合楼门口经常出现两辆车同时进出相机会先后推送两条回调如果入库接口不加锁或者数据库表没有唯一约束可能出现重复记录。我这边给车牌加了一个“车牌号过车时间”的唯一索引尽量避免脏数据。前端展示这块不多说了主要就是把过车记录列表、图片预览、白名单管理、任务匹配状态做成页面。后台管理界面我用了现成的Vue模板调了几个接口大概两天搞定。如果没有特殊要求这一部分其实不难。4. 常见问题与排查技巧实录整个调试过程中我记录了不少问题挑几个典型的写出来希望能帮你少走弯路。4.1 收不到回调十有八九是这三类原因回调收不到是这类项目里遇到最多的故障。我自己排查下来原因基本集中在三类网络不通相机到服务器之间ping不通或者服务器端口未开放。用“telnet IP 端口”就能验证端口是否可达。配置没生效海康相机的Web管理页面有些设置项保存后需要重启设备才生效。我一开始改完回调地址没重启结果过了一个多小时都没数据。协议不匹配有些相机支持HTTP和HTTPS两种回调方式如果填了带https的地址而服务端只开了HTTP端口就收不到。确认服务端协议类型与配置一致即可。排查时最快的办法是先在服务端打印所有请求的日志看看有没有相机IP发来的POST请求。如果连日志都没有就说明请求根本没到服务端问题大概率出在网络或者相机配置上。4.2 车牌汉字乱码与图片访问失败车牌汉字乱码问题上面讲过了是字符集不一致导致的用GBK解码转换就能解决。但这里要提醒一点不是所有车牌都是纯汉字开头的有些新能源车牌第二位是字母有些特种车辆可能有“使”“领”等特殊字符解析时要做通用处理不要把车牌号字段写死成“一个汉字一个字母五个数字”的格式。图片访问失败的问题也很常见。相机推送的imageUrl字段通常是相机本身提供的HTTP图片地址浏览器或服务端可以直接访问。但如果服务器和相机不在同一个子网或者相机开启了IP白名单限制图片地址就可能打不开。我处理这个问题的方案是服务端主动去下载图片存到本地文件服务器然后在数据库里只保存本地路径。这样前端展示时不再依赖相机的HTTP服务同时也能避免相机侧带宽占用过高导致视频卡顿。4.3 设备离线、抓拍漏拍与夜间识别率低海康相机的Web管理页面有一个设备在线状态监控但被动等它报警不如主动做好预防。我写了一个简单的巡检脚本每隔5分钟ping一次相机IP连续不通就推送告警到运维群。这样就算相机出问题也能第一时间知道而不是等现场司机来投诉说闸机不抬杆了。抓拍漏拍的问题大概率出在安装角度和触发区域上。视频触发模式下相机画面里会有一个虚拟线圈区域车牌只有进入这个区域才会触发识别。如果线圈画得太后车头刚进入画面时离得远识别率会降低如果画得太靠前又可能漏掉慢速车辆的第二次触发。所以安装好后一定要实际开几辆车测试根据抓拍位置调整线圈位置。夜间识别率低首先要排除补光灯太暗或者角度不对的问题。我测试时发现夜间识别率低很多时候是因为车灯直射镜头导致车牌过曝。解决办法是安装遮光罩或者在相机的图像参数里把宽动态功能打开能明显改善逆光时的成像效果。下面是我整理的常见问题速查表方便你对照排查现象可能原因处理方式收不到回调网络不通/端口未放行/配置未生效ping、telnet验证重启相机车牌乱码字符集编码不一致按GBK解码后转UTF-8图片打不开跨网段/IP白名单限制服务端主动下载图片到本地抓拍漏拍触发区域设置不当实际测试车辆调整线圈位置夜间识别率低车灯直射/补光灯角度不对开宽动态、加遮光罩、调补光灯设备频繁离线网络不稳定或供电异常检查网线、交换机端口、电源适配器回调数据重复相机重复推送或接口重复处理数据库加唯一索引接口做幂等4.4 调试过程中踩过的一些“小坑”除了上面这些主要问题还有几个小坑也想提一下。海康相机Web管理页面的默认端口是80但有时候因为现场有其他设备占用或者需要远程映射端口会把HTTP端口改掉。如果改了端口回调配置里的地址也要同步更新不然一直指向旧端口。另外相机的时间同步非常关键。拌合楼管理软件里的过车记录需要和生产任务、称重记录关联时间不准会导致整个业务流程错乱。我这边直接让相机和服务器做了NTP同步每周检查一次时间偏差发现超过30秒就手动校准一次。还有一个小经验是回调接口一定要做幂等处理。海康的相机有时候因为网络抖动同一条消息会推送多次。我的做法是在接口里先查询有没有相同车牌号、相同时间戳的记录有就直接返回成功不再重复入库。这样即使收到重复消息也不会产生脏数据。5. 后续扩展思路这套车牌识别方案跑通后我又想了想它可以怎么扩展。目前只是完成了“车辆进出自动记录”这一层其实结合拌合楼的生产场景还能做不少事情。比较实用的是一个方向是把车牌识别和称重系统联动。货车进厂后自动识别车牌然后引导到地磅称毛重装完料到出场地磅称皮重系统自动算出净重并关联到车牌号。整个过程不用人工录车牌和称重数据能省不少事也减少人为录入错误。另一个方向是和调度系统对接。罐车进场时识别车牌后系统自动根据当前生产任务、排队情况给司机分配装料口或者等候区大屏上显示“请到2号装料口等待”。这样可以减少现场调度人员的工作量也能让装料过程更紧凑。数据报表方面也比较有价值。按日统计进出场车辆类型、数量、平均停留时间等指标可以帮助搅拌站了解原材料运输车辆是否积压、罐车周转效率如何对运营管理有实际参考意义。这些都是我接下来计划要做的事主体框架已经跑通后面的工作其实就是在这个基础上不断叠加业务逻辑模块。如果有朋友做了类似方向的扩展也欢迎一起交流。最后再分享一点个人经验设备选型和网络规划是这类项目中最容易埋雷的地方宁可前期多花点时间确认现场情况也不要拿到设备就直接装。先把需求反复推敲清楚再动手实施后面基本不会出大问题。车牌识别这件事技术上并不神秘真正考验人的是对业务流程的理解和现场应对各种突发状况的能力。