道闸抬杆的那一刹那大多数车主都不会去想真正控制这根闸杆的并不是旁边那台标着“AI车牌识别”的摄像头而是一台装在灰色铁箱里、看起来毫不起眼的PLC。我接触停车场收费系统好几年从最早跟着前辈布线、递工具开始到后来独立负责整套出入口改造项目一个很深的感受是外面宣传得天花乱坠的“智能智慧停车”落地到现场八九成就是“PLC 组态软件 车牌识别相机”这套经典组合。这篇文章不绕弯子把基于PLC和组态软件的智能停车场收费系统的架构、信号链路、PLC程序要点、组态软件计费逻辑、通信机制和现场排错经验全部摊开讲适合正在做停车场项目、想独立设计出入口控制系统的工程师也适合负责停车场运维、天天被现场故障折磨的朋友。1. 停车场“智能”标签下的真身为什么核心是PLC和组态软件很多人一听到“智能停车场”第一反应是车牌识别、扫码支付、云端管理这些花哨功能。但在设备箱里真正干活的那颗“心脏”绝大多数情况下是一台小型PLC外加一台运行组态软件的工控机。这不是技术落后反而是工业现场最务实的答案。1.1 单片机方案与工控机方案的取舍逻辑做停车场出入口控制摆在你面前有三条技术路线自己画板子做单片机控制板、用工业电脑跑软件直接控制继电器、用PLC加组态软件。我三种方案都见过说说各自的坑。单片机方案成本最低一块控制板可能几十块钱但问题也很明显现场各种浪涌、静电、电机启停干扰很容易把单片机板打死一旦出了问题普通电工不会修只能整板寄回厂家耽误的是整个停车场的进出。工控机方案灵活性最高想改逻辑就改代码可工业电脑的IO抗干扰能力、长时间运行的稳定性跟PLC这种专门为恶劣环境设计的控制器还是有差距而且直接用软件去操继电器容易出现开机瞬间误动作这种莫名其妙的问题。PLC方案看起来最“传统”却是三个方案里综合成本最低的。PLC的扫描周期是确定性的说100毫秒扫一遍就是100毫秒不会因为系统负载高就卡顿IO通道全带隔离和滤波地感信号、限位开关、急停按钮这些直接接进去很放心更关键的是维护门槛一个有点经验的电工就能看懂梯形图、能查到某个点位为什么没有信号这是单片机板没法比的。1.2 组态软件不只是“监控大屏”收费逻辑的最终落地点是它第二个常见误解是把组态软件当成一个好看的显示界面觉得它就是把道闸状态画在屏幕上给人看。实际在停车场系统里组态软件承担的是真正的“脑力活”它负责跟PLC通信、接收入场出场事件、连接数据库、计算停车费、跟扫码支付或POS机对接最后再把“允许放行”的信号写回PLC。打个比方PLC是人的手脚负责执行“抬杆”“落杆”这些物理动作组态软件是大脑负责判断“这辆车该不该放行、该收多少钱”。把计费逻辑放在软件层而不是PLC层是这套架构最聪明的地方——停车费率政策经常变今天免费十五分钟明天变成半小时如果这些写在PLC里改一次就要重新下载程序、重新调试放在组态软件里改一条配置、刷新一下策略就行PLC程序基本不用动。2. 整套系统的信号链路从入场到缴费出场每一步是谁说了算理解了分工接下来看整套系统怎么协同工作。一套标准的出入口收费系统硬件和信号流其实不复杂但每个环节的“顺序”和“边界”必须非常清楚否则现场就会出现各种幽灵故障。2.1 出入口的硬件组成与典型信号流向先说一个双向出入口入口、出口各一套设备的典型硬件清单设备作用信号类型接去哪里车牌识别相机带补光抓拍车牌、输出识别结果网络信号组态软件所在工控机触发地感线圈检测车辆到达道闸前干接点脉冲PLC输入防砸地感线圈检测车辆已在道闸下方干接点持续电平PLC输入道闸限位开关反馈道闸已全开或全关干接点PLC输入道闸电机控制线执行抬杆、落杆继电器输出PLC输出收费显示屏显示车牌、费用、缴费结果RS485/IO常由工控机直连或PLC中转收费终端出口扫码支付、现金收款、传“已缴费”信号网络信号干接点计费终端给PLC一个“已缴费”IO急停按钮紧急情况下强制切断道闸动作干接点PLC输入PLC集中采集信号、控制道闸输入/输出与工控机通过网口/串口通信工控机组态软件逻辑判断、计费、展示、存储网络信号数据库、云平台、收费终端信号流向非常清晰现场所有开关量都汇聚到PLCPLC再把“发生了一个事件”告诉组态软件组态软件查询数据库、算完费用、拿到支付结果再把“允许放行”或“禁止放行”回传给PLC。摄像头出来的车牌识别结果走网络不经过PLC。2.2 一次入场事件地感、相机、道闸的协作时序把一次成功的入场过程拉长来看时序大概是这样的车辆压到入口触发地感线圈地感控制器输出一个干接点脉冲PLC检测到上升沿立刻在寄存器里写一条“入口触发事件”。组态软件轮询读到这个事件触发车牌识别相机抓拍并识别识别出的车牌号写入数据库生成一条入场记录车牌号、入场时间、入口编号、抓拍图片路径。组态软件判断这辆车是否为月卡或白名单如果是就把“允许开闸”标志写到PLC的某个线圈如果所有车辆都允许入场则直接允许。PLC看到允许标志后输出继电器信号道闸电机执行抬杆。车辆往前开压过防砸地感线圈等到车辆完全通过防砸线圈信号从有变无PLC再延时一两秒输出落杆信号。整个过程从车辆停到触发线到道闸抬起一般不超过3秒。这里有个容易被忽略的细节PLC判断“车辆已通过”靠的是防砸线圈而不是靠延时猜。如果你的系统用“抬杆后固定延时几秒就落杆”那早晚要出事——万一车辆在道闸下方停住了或者倒车回来固定延时会把闸杆硬生生砸下去。防砸线圈才是落杆的唯一依据。2.3 出场缴费场景PLC和组态软件的边界到底划在哪出场比入场多了一个环节计费与缴费。车辆压到出口触发地感PLC上报事件组态软件让出口相机识别车牌然后用这个车牌去数据库里查入场记录算出应缴费用显示在收费屏上。车主扫码或投币缴费收费机确认收款成功后向PLC发一个“已缴费”的干接点信号也可能是通过组态软件将“已缴费”标志写到PLC寄存器。PLC确认有“已缴费”信号且无异常才执行抬杆。这套设计有一个非常重要的原则PLC永远不做金额计算。PLC只认“已缴费”这个开关量是真是假。金额算法、免费规则、费率表全在组态软件和数据库里。这样一旦费率政策调整只改软件一旦收费机故障PLC侧也能及时判断“没有收到已缴费信号不放行”或“按应急预案放行”。3. PLC程序里的三个关键设计I/O规划、防砸车、掉电复位PLC侧的程序其实不像很多人想的那么玄乎核心就是围绕输入输出做状态互锁。但正因为逻辑简单所以每个细节都必须较真现场出的怪问题几乎都藏在程序设计的小疏忽里。3.1 I/O点位规划双向出入口需要多少通道以一个入口加一个出口的双向通道为例我通常这样分配点位。输入信号侧入口触发地感1点、入口防砸地感1点、入口道闸全开限位1点、入口道闸全关限位1点、出口触发地感1点、出口防砸地感1点、出口道闸全开限位1点、出口道闸全关限位1点、收费机已缴费信号1点再算一个急停按钮1点一共10个数字量输入。输出信号侧入口抬杆1点、入口落杆1点、出口抬杆1点、出口落杆1点、蜂鸣器或报警灯1点一共5个数字量输出。算下来输入输出加起来15点选一台自带以太网口的30到40点小型PLC就绰绰有余还能留点备用点。这里我特别强调两点经验第一备用点至少留20%你永远不知道老板哪天让加一个“超时未出场报警灯”第二道闸电机如果本身有“遇阻反弹”功能它的控制线可能是交流接触器控制PLC输出端一定要加中间继电器隔离别让电机的大电流直接走PLC输出点烧输出点的钱省不得。3.2 防砸车逻辑地感信号和道闸动作怎么“互相锁死”防砸是停车场系统最重要的安全逻辑没有之一。我的做法是三条规则同时生效第一条道闸处于抬起状态时只要防砸地感一直检测到车辆就把道闸强制锁定在“保持抬起”不管组态软件发了什么指令。第二条道闸正在下落过程中防砸地感一旦从无信号变为有信号立即停止下落并反向抬杆。第三条防砸地感从有信号变为无信号后不能马上落杆必须再延时两秒左右防止车辆尾部还没完全离开、或者行人正好经过。有些人觉得有了道闸自带的遇阻反弹功能PLC这边就不用再写防砸逻辑了。我的建议是两层保护都要有道闸的遇阻反弹依赖电机电流检测反应相对粗糙如果车辆停得很慢、压上去的力度很小有概率不触发地感线圈是物理埋在地下的金属检测器只要车在感应范围内就会持续有信号把它作为第一道防线是最稳妥的方案。3.3 掉电复位逻辑最容易变成“黑匣子”的一个环节停车场最怕的情况是半夜断电更怕的是断电之后来电道闸不知道自己是开着还是关着系统从此进入“薛定谔的闸杆”状态。我的做法分三层第一层PLC程序里用掉电保持区存储道闸当前状态每次抬杆落杆都实时刷新这个变量第二层PLC上电初始化时直接读两个限位开关——如果全开限位有信号就知道闸杆是抬起的全关限位有信号就知道是落下的两个都没有说明闸杆卡在半空中此时必须进入故障模式鸣响报警灯禁止自动动作等人工确认和处理第三层组态软件启动后不要立刻接管道闸控制先跟PLC做一次握手确认状态避免软件重启瞬间发送错误指令。4. 组态软件侧计费算法、通信协议与数据对账PLC只是执行机构真正决定收费系统好不好用、能不能对账的是组态软件侧的设计。这一块现场最喜欢出错同时也是最考验经验的。4.1 PLC与上位机的通信寄存器映射要做到“门当户对”组态软件和PLC之间通信最常见的做法是Modbus协议组态软件作为主站轮询PLC的寄存器和线圈。通信点表必须事先设计好不能随便定义。我习惯用一套固定规则比如用保持寄存器区定义事件上报区——PLC检测到入场触发就写入“1”组态软件读走后写“0”相当于一次握手用线圈区定义控制命令区——组态软件把“允许抬杆”写到某个线圈PLC扫描到这个线圈为1就执行抬杆并清零。这里有一个很多人吃亏的细节轮询周期不能太快也不能太慢。太快网络拥堵时PLC通信模块容易超时报警太慢PLC侧短脉冲事件可能被漏掉。折中方案是轮询周期设200毫秒左右同时PLC侧对短脉冲事件做“锁存”——事件发生了就置位一个保持标志等组态软件读走并确认后才复位这样即使轮询稍微慢一点也不会丢事件。4.2 计费策略落地免费时长、阶梯费率和特殊车辆怎么配置计费逻辑看着简单真正写起来全是细节。以最常见的“首小时X元之后每小时Y元每日封顶Z元”为例在组态软件里要么写脚本要么用SQL对数据库记录做计算。我建议把计费核心逻辑放到SQL查询里维护方便也不容易把规则写散。一个典型的计费SQL思路是先查这张车牌是否有月卡或白名单标记有则费用为0然后取出入场时间用当前时间减入场时间算出停车分钟数如果分钟数小于免费时长费用为0否则按阶梯算每段的费用最后判断是否达到24小时封顶。这里面最容易糊涂的是跨天问题到了晚上12点是按“从入场起累计24小时”算封顶还是按“自然日”重置再算每个项目要求不一样但组态软件里这两者必须能配置很多收费纠纷就出在这个地方。特殊车辆也要考虑军警车、残障车、内部员工车、月卡超时车。月卡超时是个典型场景——月卡有效期内出场免费但月卡过期了还在停出场时就要按临时费率补缴。这个判断放在入场还是出场我建议放出场因为只有出场时才能确定有效期状态入场时判断只会制造更多麻烦。4.3 流水记录与对账比收钱本身更麻烦的事情停车场收费系统真正让人头疼的不是收费而是对账。现场总有无牌车、识别失败车、跟车闯关、出场记录丢失这些情况数据库里会出现大量“只有入场没有出场”的费单。我见过一个项目运行半年后未匹配入场记录超过两千条财务根本没法跟物业交代。所以组态软件侧一定要设计一个“异常流水处理”模块每笔入场和出场都存抓拍图片、时间、设备编号每天凌晨自动跑一次匹配任务把明显能对上时间的入场和出场撮合掉剩下的未知单提供一个人工审核界面运维员看一眼图片就能判断是不是漏识别。这套东西虽然在项目单上看不到什么亮点却是决定后续维护能不能睡安稳觉的关键。5. 上线维护期的真实排错记录三个反复出现的故障现场设备装完、程序写完真正的考验才开始。我每个项目上线后的前两周都高度紧张因为这阶段暴露的问题基本都集中在几个固定位置。下面这三个坑我几乎在每个停车场项目里都见到过。5.1 地感信号抖动导致闸杆乱起落症状是道闸没车经过也会偶发抬杆或落杆车主投诉“撞鬼了”。排查时不要急着怀疑PLC程序十有八九是地感线圈或地感控制器的物理问题。地感线圈的埋设要求其实很严格推荐切割尺寸约1米乘1米、深度5到8厘米、绕4到6圈线必须用专用的高温耐磨地感线两个线圈之间要保持两米以上距离避免串扰线圈引出线要双绞穿管后接入地感控制器屏蔽层单端接地。灵敏度拨码开关不要一下调到最高配合车辆停放位置逐步调整。我遇到过最诡异的一次是停车场地坪里有一段废旧钢筋网导致线圈检测范围严重失真最后把线圈位置平移了半米才解决。5.2 车牌识别与道闸放行的竞态问题另一种常见故障是车辆已经开到触发线圈上但相机识别结果迟迟没回来组态软件迟迟没有给出放行标志车主一着急直接倒车走了。这时PLC检测到车辆离开以为没有新的入场事件而组态软件刚好在车辆离开后收到了识别结果写入了允许放行闸杆在空无一车的情况下抬起来。这个问题的根因是“车辆已离开”和“识别结果到达”两个事件发生了竞态。我的解决措施是给入场事件加一个“放行窗口期”触发地感检测到车辆后组态软件必须在设定时间比如6秒内返回结果超时仍未识别就尝试再次抓拍如果连续三次失败转为默认放行或提示现场人员人工处理。同时组态软件只有在“车辆仍停在触发线圈上”时才允许写入开闸标志看到车辆离开就立刻撤销该标志宁可漏放也不空放。5.3 无人值守时段的系统自恢复能力还有一类问题集中在深夜组态软件所在的工控机半夜自动更新重启了或者数据库连接断了。天亮发现月卡客户出不去临时车也堵在出口。现场没有值班人员这种故障会被投诉到物业方。我的做法是双保险PLC侧写一个通信心跳检测超过设定时间没收到组态软件的“心跳”信号就自动进入应急模式——如果出口防砸地感检测到车辆延时后直接放行至少保证无人值守时段车辆出得去工控机侧设置BIOS定时开机和来电自启组态软件做成Windows服务并开启自动重连断线后每5秒尝试重连数据库恢复后自动补写流水。应急模式风险自负但它能避免最恶劣的“人车困在停车场”事件实际运营方都很认可。6. 这套方案的边界在哪里还能扩展出什么花样总有人说PLC组态软件这套方案太老气不如上云平台、全APP操作。我的看法是任何技术方案都有边界关键是知道边界在哪。PLC加组态软件的强项是可靠、确定、易维护适合对稳定性要求极高的出入口控制。它的弱项是复杂的会员体系、精确到分钟的动态定价、跨商场多停车场互联这些“重运营”需求硬塞给组态软件开发会非常痛苦。所以现实中的主流做法是“分层”现场控制层依旧是PLC收费运营层用组态软件加数据库跑再往上一层才是面向用户的APP、小程序、云平台通过接口对接而不是把所有东西都堆在现场这台工控机上。对一个中小型停车场项目PLC加组态软件已经能覆盖百分之九十以上的需求无牌车扫码入场、月卡自动识别、免费券抵扣、夜间包月、多出入口统一计费这些都能实现。真到需要突破的时候优先考虑给组态软件加接口做二次开发而不是推倒重来换一套系统。最后分享一个我个人的习惯每个项目验收之前我必然安排三轮以上的深夜无人值守测试重点做三件事——拔掉工控机网线看道闸会不会乱动作拉闸断电再上电看系统能不能自恢复模拟一次车牌识别失败看最终会不会误放行。能扛过这三关的系统才敢放心交给甲方的物业团队。一个停车场收费系统技术含量其实没有多高但正因为每辆车、每一天都在用它所以每一个细节都经不起将就。PLC和组态软件这对组合能在这个行业里活跃这么多年靠的就是把“稳”字做到了极致。