我们在十几个城市落地路侧停车收费系统后，谈视觉算法与部署的实话
这两年我们团队作为软件系统供应商，陆续交付了十几个城市的路内停车智能化项目。外界看马路边停车收费，总觉得不就是装个摄像头识个车牌嘛，但真从工程化角度去啃，才发现开放道路场景下的视觉系统远比封闭停车场要棘手得多。今天撇开商务层面的东西，单纯从我们写代码、调模型、跑现场的实施视角，聊聊这类系统的视觉识别算法核心与部署时那些容易翻车的要点。
先说视觉识别算法这部分。很多甲方初期需求文档里只写“车牌识别率99%”，这指标在车库里容易达成，在路边高位相机下基本是拍脑袋。我们实际用的架构是“检测 跟踪 识别”三段式。检测模型早先试过Faster R-CNN，速度跟不上，后来切到YOLO系列，现在主力跑的是YOLOv8改进版，针对斜列、平行车位做了锚框重设。但这里头真正的难点不是车本身，而是车位状态判定。相机架在挑杆上，俯角大，车辆部分被绿化带、公交遮挡是常态。我们自己的标注库里，特意塞进了大量半遮挡样本，并且引入了实例分割去抠车框，避免传统框检测把旁边车道车辆误判占位。
车牌识别（LPR）模块，我们没直接用开源，而是自研了基于注意力机制的轻量网络，因为边缘设备算力吃紧。顺带提一句，新能源绿牌、武警牌照、以及临时纸质牌，在初期版本漏识严重，后来靠人工回流标注才压下去。还有光照，北方午后逆光、南方回南天镜头起雾，我们不得不在相机端加了主动补光和算法层面的低光照增强，这部分其实一半是硬件适配一半是软件算法。
跟踪算法反而容易被忽视。路侧系统是按泊位计时收费的，一辆车停入某个画车位，如果跟踪ID跳了，就会生成两条记录导致重复计费或者逃费。我们结合DeepSORT和泊位拓扑逻辑做了约束，简单说就是车辆运动轨迹必须符合画定的虚拟停入线，脱离了就用业务逻辑纠偏。这个交叉验证机制，是我们在某旅游城市项目被投诉后痛定思痛加上的。
再聊部署要点，这是体现软件系统公司工程能力的真战场。路边没有恒温机房，早期我们用x86工控机挂GPU卡，结果夏天高温掉卡，后来全面转向ARM架构的NPU边缘盒子，搭配TensorRT或CANN量化成INT8，推理延时从原来的300ms降到80ms以内。一个标准十字路口要管6到10个相机，码流拉满本地处理，我们采用RTSP取流后抽帧，不是每帧都跑模型，而是用光流法筛动态帧，省了不少算力。
网络传输方面，很多二三线城市路边只有4G信号，强行传视频回云中心不现实。我们的策略是边缘盒子上完成所有识别，只上传JSON结构体和两张抓拍图（入和出），带宽占用压到每秒几KB。不过政府类项目对数据私密性要求高，我们全部做私有化部署，K8s容器打包，交付时给客户一套自研的运维面板，他们自己能看设备在线率。
还有个坑是时钟同步。收费系统对时间戳极度敏感，边缘盒子如果没接GPS或NTP，重启后时间漂移，结算就乱套。我们现在出厂强制绑定北斗校时模块。
最后说运维，算法上线只是开始。长尾场景永远收敛不完，比如去年某城搞马拉松，路边停满保障车，我们的模型一度把印着Logo的厢式货车误判为特殊免征车辆，后来连夜热更新模型。所以软件系统公司得提供远程灰度升级能力，把边缘节点纳入统一的模型仓库管理。
回头看，马路边停车收费智能系统，表面是AI视觉，底子是扎实的嵌入式软件和系统工程。我们作为开发商，越来越觉得比拼的不是论文指标，而是谁在真实泥泞的路边踩的坑多、填的坑快。这行没有银弹，只有一行行适配场景的代码。
微信号：18581869297