简介一份面向智能交通与高速公路收费系统设计人员的ETC电子不停车收费解决方案资料。文档以射频识别技术为核心系统梳理了ETC的应用背景、无源射频卡电子标签相比传统磁卡的非接触性、响应速度快、安全保密性好等优势并拆解了自动识别控制、数据采集、车辆检测、闭路电视、信号控制等六个子系统的构成与分工附有射频读写器的工作频率、输出功率、读写距离、读写速度、安全机制等关键参数。资料为单个PDF文件压缩包大小438KB内容精炼。目前已有69人浏览学习适合作为ETC系统选型、方案设计、技术入门或课程参考资料。借助该文档可快速建立对不停车收费系统整体框架的认知其中的具体技术指标也可直接应用于实际工程配置与方案报告撰写。1. ETC 解决方案到底要解决什么问题“ETC 解决方案”听起来像一张扣费流程图真正拿到现场才知道这套东西 70% 的工程量在通信链路和账务一致性上。一个典型问题是车已经过去了车道工控机没有收到 OBU 的交易确认后台却已经按上一笔流水扣了费。要解释这个现象就得把 RSU、OBU、PSAM 密钥、车道控制器和清分系统放在同一个方案里看而不是按照“设备采购 软件部署”两份文档分开做。ETC 的核心场景区分两类一类是高速路网的开放式计费车在龙门架下完成交易一类是收费站车道需要和栏杆机、地感线圈、车牌相机联动。两类场景的共性是“读卡不是目的扣费且记账才算完成”。本文面向负责 ETC 车道系统的集成工程师、收费软件研发和方案评审人员按照选型、联调、参数调优、上线验证的顺序把可复现的命令和参数写出来。2. 选型与数据流ETC 解决方案的核心组成2.1 RSU 与 OBU 的关键参数先定通信边界ETC 解决方案的第一步不是选后台而是把 5.8GHz DSRC 链路的能力边界定下来。RSU路侧单元和 OBU车载单元通过 GB/T 20851 系列协议交互交易数据在空中只占很短的时隙但天线功率、接收灵敏度、唤醒距离三者必须匹配。很多项目出现“能唤醒但交易失败”问题往往出在 OBU 接收灵敏度差而不是 RSU 功率不够。单纯加大发射功率会让旁瓣变宽反而增加邻道误读率。表 2-1 是我在方案评审时常用的核对表指标不追求顶配只求在真实车流环境里可复现参数常见取值选型理由RSU 发射功率EIRP15 dBm 20 dBm覆盖单车道 5-10m 唤醒区超过 20 dBm 后邻道抑制难做OBU 唤醒灵敏度-50 dBm -60 dBm灵敏度过低会出现在低温下唤醒距离缩短交易唤醒距离1.5m 8m低于 1.5m 时车速稍快就来不及交易邻道抑制优于 30 dB防止隔壁车道天线误读本车道 OBU天线波束单车道窄波束波束过宽是邻道串扰的主因PSAM 接口符合 PBOC/金融密钥标准认证过程依赖 PSAM 产生随机数和分散因子参数不是孤立存在的。比如天线安装在龙门架上的高度、俯仰角会直接改变波束落在行车道的形状。同一个 RSU 在 5.5m 安装高度和 6.5m 高度下唤醒区前后移动可能超过 2m这是现场最容易忽略的边界。做选型表时我会把“安装高度 5m 到 7m 内的波束包络”作为必测项而不是只看厂商给的理想最大唤醒距离。2.2 交易数据流从天线到清分系统的路径选型定了第二步是把数据流串起来。RSU 通过串口或以太网连接到车道工控机工控机在收到 OBU 的完整交易记录后组装成一条交易报文再通过收费专网上传给站级服务器和省级清分中心。这里的常见错误是只保证“ETC 扣费成功”没有留出交易流水号映射的字段导致对账时无法把 RSU 原报文和后台扣费记录对应上。我一般会在方案里规定一条统一的交易记录前端各个厂商的设备报文先转换成这个格式再入库避免每个天线厂商自己定义一套字段。样例报文如下{ toll_id: G2-004-05, lane_id: ETC-03, txn_no: T20241120081233000123, txn_time: 2024-11-20T08:12:3308:00, obm_no: 12345678901234567890, plate_no: 京A12345, vehicle_type: 1, amount: 15.00, psam_no: PSAM00000001, result: 1 }逻辑说明txn_no必须全局唯一由车道工控机生成清分系统直接把它作为主键obm_no是 OBU 内置编号一辆车可能换牌不换卡只靠它识别车辆会出错plate_no来自车牌识别相机用于和 OBU 信息交叉验证result为 0/1 表示失败/成功失败交易不能直接从数据库删除而是进入待对账表否则少收款查不出原因。实际部署时我还会在表里加上tariff_version费率版本号。因为费率表升级不是瞬时的全省车道可能在不同时间点切到新费率如果对账时发现金额不一致先看tariff_version就能判断是费率切换导致而不是设备故障。2.3 车道控制器与后台的接口约定数据流里最容易断的是天线原始报文的时效性。RSU 通过串口上报时如果工控机上的采集程序用阻塞式读取某条大报文解析耗时过长后续 OBU 的交易请求就会排队。常见的做法是把天线数据接收和交易报文组装拆成两个线程接收线程只入队列组装线程按批次消费。这样做的好处是即便后台接口响应变慢天线的无线链路也不会立刻阻塞。接口约定上要强调两个机制第一后台接口必须幂等车道重复提交同一txn_no时后台返回原处理结果而不是新建一笔第二车道侧要有“本地队列 失败重传”的落盘设计网络抖动时交易先写本地文件按顺序补传。只依赖实时 HTTP 调用的方案在网络中断时会直接丢流水这在 ETC 车道是绝对不能接受的。3. 本地联调跑通ETC 解决方案的最小命令集3.1 先把天线和工控机之间的串口抓通拿到 RSU 后第一件事不是接网线而是确认串口参数。RSU 的调试口多数是 RS-232 或 RS-485常见波特率 1152008 个数据位1 个停止位无校验。下面这组命令用来查看串口是否正常回应stty -F /dev/ttyS0 115200 cs8 -cstopb -parenb raw timeout 2 cat /dev/ttyS0 | od -Ax -tx1z这段命令的意思第一行把/dev/ttyS0配置成 115200 波特率、8 数据位、禁止奇偶校验并关闭硬件流控第二行用timeout 2限制读取两秒把串口收到的原始字节用十六进制打印出来。正常时RSU 在通电后会主动输出一帧设备信息例如53 54 01 00 02 ...如果没有输出先检查接线 RXD/TXD 是否交叉再用 USB 转串口模块逐个排除。不要一开始就上协议栈先用十六进制确认物理层通再做协议解析。这样定位问题最快。很多联调卡在“程序连不上天线”结果最后发现是地线没共地、串口电平不匹配这类问题用od看十六进制能立刻暴露。3.2 用本地 HTTP 接口模拟一次完整扣费联调时不可能每次都用真车跑一遍我一般会在车道工控机上起一个模拟 OBU 的服务把天线控制程序收到的帧放进队列然后直接调用车道引擎的交易接口。用 curl 提交一条交易是最快的验证方式curl -s -X POST http://127.0.0.1:8080/api/v1/transactions \ -H Content-Type: application/json \ -d {txn_no:TEST001,obm_no:12345678,plate_no:京A12345,amount:15.00}返回{code:0,txn_no:TEST001}表示车道引擎接受这笔流水如果返回超时先用ping检查本机回环再用ss -lntp看服务端口是否在监听。这里的-d是 POST 请求体-H指定 JSON 格式注意obm_no在测试阶段可以随意填但正式联调必须使用 PSAM 认证后的真实 OBU 编号否则后端对账数据没法用。联调时我还会额外测试一条伪造的重复流水把上面的TEST001原样再提交一次。车道服务如果返回已有的成功结果而不是报错说明幂等逻辑生效。这一步能提前暴露数据库唯一索引缺失或查重逻辑不严谨的问题。3.3 日志里最常见的三类失败与排查表联调阶段的日志通常集中在/var/log/lane/下。我一般用下面这条命令快速过滤三类关键字grep -E TXN_TIMEOUT|OBU_AUTH_FAIL|DUPLICATE_TXN /var/log/lane/app.log | tail -n 100TXN_TIMEOUT表示天线到工控机链路延迟高优先查串口丢包率和工控机 CPU 占用OBU_AUTH_FAIL表示 PSAM 认证失败优先查密钥分散参数和 PSAM 卡座接触DUPLICATE_TXN表示同一笔交易收到两次上报说明 RSU 重发帧没有被正确处理。这个命令把三类问题压缩到一条管道里适合在工控机资源有限的环境下快速定位。日志关键字常见原因先查什么TXN_TIMEOUT天线到工控机链路延迟高串口丢包率、工控机 CPUOBU_AUTH_FAILPSAM 密钥分散参数不一致PSAM 卡槽接触、密钥分区DUPLICATE_TXN同一笔交易收到两次上报幂等表、txn_no唯一索引日志里的 DUPLICATE_TXN 是最值得提前处理的。RSU 在收不到确认时会自动重发同一笔交易车道服务如果只按obm_no或txn_time查重很容易把重发当作新交易。正确做法是在数据库中给txn_no建唯一索引插入冲突时直接返回上一次的处理结果保证幂等。这个坑在联调阶段不暴露上线后一旦出现网络抖动就会批量产生重复扣费工单。4. 交易一致性ETC 解决方案的 3 个关键参数调优4.1 PSAM 认证超时与重试次数PSAM收费安全认证模块是 ETC 交易中容易被低估的环节。OBU 和 RSU 握手完成后车道工控机要通过 PSAM 完成双向认证每次认证需要读随机数、分散密钥、加密、回写四步都必须在几百毫秒内完成。超时参数设得太短会出现在线圈触发后读卡成功、认证却失败的边界问题。表 4-1 是常用的参数建议参数建议值调优要点PSAM 操作超时500ms 1000ms低于 300ms 时旧 PSAM 卡容易超时认证重试次数2 次超过 3 次会造成天线排队积压密钥分散版本与发行方保持一致新旧版本混用会出现偶发失败我一般不会第一轮就把超时调到 1000ms因为过长的超时会让倒车重试的司机在车道里等得更久。先看 85 分位耗时再把超时设为该值的 1.5 倍比随意定参更稳妥。统计耗时的命令如下grep PSAM_COST /var/log/lane/app.log | \ sed s/.*cost// | \ awk {a[NR]$1; s$1} END {print avg, s/NR; na[NR]; print p85, a[int(NR*0.85)]}逻辑说明grep只取包含PSAM_COST的日志行sed把前面的时间戳和日志级别去掉只留cost后面的毫秒数awk数组存全部耗时结束时计算平均值和 85 分位值。这个统计值比厂商给的理论时延更可信因为它是一线真实串口链路的测量结果。如果 p85 已经到 600ms把超时设成 900ms 比设成 500ms 更稳妥。4.2 天线交易窗口和邻道抑制的取舍天线交易窗口指 RSU 从收到 OBU 应答到结束交易的允许时间。窗口太短交易未完成就被中断窗口太长车速过快时下一辆车又会被同一 RSU 重复触发。常见配置如下tx_window_ms 450 tx_power_db 18 max_retry 2tx_window_ms控制单次交易的最长处理时间450ms 适合小客车为主的城市路段货车占比高的路段OBU 数据量更大我会调到 500ms 以上。tx_power_db是天线发射功率18 dBm 是单车道窄波束的折中值功率太高旁瓣会照到邻道。max_retry是 OBU 无应答时的重试次数2 次足够再高会拖住后续车辆。在调参上有个常见误区把天线重试次数提高到 5 次以上来保证成功率。实际效果是第一次交易已经记账成功第二次重试时 OBU 上报的是上一笔交易流水车道系统会先查重查重后返回成功后司机看到的是扣费成功但系统如果没处理重发帧就会记成两笔。因此重试次数和幂等表必须同时设计单独调参只会把问题从“失败”变成“重复扣费”。4.3 车牌识别与 OBU 信息的绑定策略混合车道中车牌相机可能晚于 ETC 交易完成识别直接丢弃未匹配的 OBU 交易会导致逃费。常见做法交易流水的plate_no字段先留空给车牌识别结果一个 500ms 的匹配窗口如果窗口内出现置信度高于 0.9 的车牌且与交易时间差值小于 800ms则绑定。绑定失败时把交易标记为“待人工确认”而不是自动拒绝。这个策略的关键参数是“时间差值阈值”。太紧会漏掉识别慢的相机太松会把前一辆车的车牌绑到后一辆车的交易上。我一般用下面这条命令统计实际车牌识别时延分布再决定阈值grep PLATE_DELAY /var/log/lane/app.log | \ sed s/.*delay// | \ sort -n | \ tail -n 5tail -5取的是全量样本里最大的 5 个值如果普通时段最高在 600ms 左右阈值放到 800ms 就有余量如果发现大量 1s 以上的延迟先解决相机识别策略而不是无脑放宽阈值。把交易和车牌绑定后必须重新生成txn_no否则同一个txn_no先被工控机落库、再被清分系统入库会造成主键冲突。5. 上线前验证压测脚本和异常恢复检查清单5.1 用 curl 循环模拟车道压力上线前压测不需要复杂工具用 bash 循环就能发现串口数据堆积、数据库连接池不足等问题。下面这个脚本向交易服务连续提交 100 笔不同流水号统计 HTTP 状态码分布for i in $(seq 1 100); do curl -s -o /dev/null -w %{http_code}\n \ -X POST http://127.0.0.1:8080/api/v1/transactions \ -H Content-Type: application/json \ -d {\txn_no\:\STRESS-$i\,\obm_no\:\OBU$i\,\amount\:15.00} done | sort | uniq -c预期输出中200占多数如果出现500或503检查车道数据库连接池和清分接口的吞吐阈值。这个压测维度是“并发不高但持续不断”更接近真实收费车道的间歇性高峰。跑完后要确认日志里没有DUPLICATE_TXN因为循环中流水号没有重复只要出现重复记录说明服务内部自己生成了重复流水。5.2 上线检查清单检查项通过标准验证方式天线驻波比 1.5用驻波比表测馈线观测 1 分钟稳定值串口丢包率 0.1%抓 1000 条原始帧统计 CRC 错误交易成功率 99.5%按照压测结果计算黑名单同步时延 30 秒从后台发布黑名单到车道生效的时间戳对账差异0用txn_no全量比对车道流水和清分文件最后一步我会手动断开一次车道到后台的网络模拟“主备链路同时故障”的场景。恢复网络后观察本地落盘队列是否按时间顺序把断网期间的交易补传完毕补传后txn_no不能发生任何变化。跑完这些验证再把黑名单同步间隔从 60s 临时改成 1s观察 5 分钟确认拦截生效后再改回去。本文还有配套的精品资源点击获取