公共交通的车路协同这词在圈子里喊了很多年可真正能拿出整套方案、覆盖从路口设备到云端平台全链路的交付案例并不多。我今天想拆解的这套iTSTech方案是2026年初我参与评估的一版公共交通车路协同整体解决方案。它要解决的问题很实在公交车到路口怎么尽可能少吃红灯驾驶员视野盲区里突然窜出的电动车和行人怎么提前预警车队调度怎么从经验判断变成数据驱动。跟单点测试不同这套方案把车端、路端、通信网和云控平台整个串在一起更适合公交公司、交管部门和做车联网集成的团队拿来参考前端运营的人也能从中理解车路协同到底能给自己带来什么。1. 公共交通车路协同为什么值得单独做一套方案1.1 公交运营里绕不开的三座大山先聊痛点。公交车和私家车最大的区别在于它是一条固定线路、固定班次、固定站点的“透明运载工具”运营方对它的要求不只是安全还有准点、高效和舒适。但在实际路面上它面临的问题比普通车辆更复杂。第一是路口延误。一个城市公交线路平均要经过十几个信号控制路口信号配时方案基本是按照社会车流量来设计的不会专门照顾公交车。公交车车体大、加速慢经常遇到绿灯末尾没法通过的情况一趟跑下来在路口累计损失几十秒非常常见。高峰期一圈多跑二十分钟对乘客体验和发班准点率都是直接打击。第二是安全盲区。公交车右转时右前侧存在大面积视野盲区车身越高盲区越远进出站时行人和电动车经常贴着车身穿行。这类事故在城市交通事故里占比不低一旦发生就是大事故很多公交司机靠的是“脚刹心理”提前减速但这让运营效率进一步下降。第三是调度滞后。很多公交的调度系统还是“被动式”的调度员看地图、打电话、问司机发车间隔靠经验拍脑袋。出现突发拥堵、临时加车、乘客滞留时调整响应速度慢。乘客那边只能看到“车辆已到站”或“预计N分钟”准确率并不高。这三座大山指向同一个问题公交缺少和路口、和道路信息互动的能力。车路协同解决的就是这个“互动”问题。1.2 iTSTech的方案思路让灯能读、让车会说、让云能算iTSTech这套方案在设计上没有追求“常见的堆硬件”它的整体思路是三层联动车端可感知、路端可协同、云端可决策。车端做的事情是读懂自己——通过车载终端OBU、定位模块和车辆总线数据实时知道自己在哪里、速度多快、下一步要左转还是右转、是不是满载、是否晚点。路端做的事情是告诉车“路口的情况”——信号灯还有几秒、路口哪块区域有障碍物、有没有行人和非机动车穿行。云端做的事情则是把这些零散的信息汇总成决策比如对某条线路的公交优先级别做动态调整或者把多车轨迹数据沉淀成调度建议。这里有个很关键的设计原则单点设备不解决系统问题。一辆公交车即使看得再远如果路口不知道它来了信号灯不会让它优先一个路口即使感知设备再强如果信息没有传到车端司机该看不见还是看不见。iTSTech是把“车-路-云”之间的信息链路打开让每个环节的数据能闭环流动。1.3 通信方式选型为什么不是4G/5G蜂窝就够用很多做传统车联网的人会问现在5G网络覆盖已经不错了为什么还要专门做V2X直连通信这需要回到时延这个指标上来。车辆之间、车辆和路侧设备的紧急信息交互对时延的要求是毫秒级。尤其是在盲区预警、前碰撞预警这类安全场景里如果数据从车载终端发到基站、再到路侧平台、再转发回车端经过多级网络转发后延迟会到几十毫秒甚至更高对高速移动场景来说这几十毫秒可能就是事故和安全的差距。而C-V2X的PC5直连通信可以理解为让车辆直接和附近设备“对话”不依赖基站转发端到端时延能控制在20毫秒以内。iTSTech采用的双模策略是PC5直连负责低时延关键消息5G蜂窝网络负责大带宽非实时数据。安全告警、信号灯状态这类消息走直连视频流、运营报表、地图更新这类非实时数据走蜂窝网络。这个选型思路可以避免两个极端纯直连会受限于路侧设备覆盖密度纯蜂窝满足不了安全场景的时延要求。实际跑下来混合模式最稳。2. iTSTech整体架构拆解车端、路端、云端怎么串起来2.1 车端OBU不是简单的“定位盒子”车载终端OBU是整个车路协同的数据源头但很多人把它理解成“带通信功能的GPS盒子”这是误区。iTSTech方案里的OBU至少集成了四类能力一是高精度定位。普通GPS在城市高楼密集区漂移可能达到几十米这不满足车道级判断需求。iTSTech的方案里OBU支持RTK差分定位配合地基增强站稳定情况下定位精度可以到厘米级。即使RTK信号丢失还会利用车载IMU惯性传感器做航位推算保证短时间内的定位延续性。二是车辆状态读取。通过连接公交车的CAN总线OBU能读到车速、档位、刹车状态、转向灯状态、车门开关状态。这组数据对判断“公交车在路口是否准备右转”至关重要如果只靠位置轨迹去猜转弯意图经常会误判。三是通信能力。OBU内部同时集成PC5直接通信模块和5G/4G蜂窝模块能够把车辆数据实时广播给路侧设备也能接收来自路侧、来自云端的指令。四是车载人机交互。司机侧会有一个显示屏或平板显示前方路口的信号倒计时、碰撞预警提醒、超速提示。语音播报也很重要视觉画面再清晰高速场景下司机第一反应还是要靠语音定向。2.2 路端RSU、感知设备和信号机之间的配合路侧部分是整套方案里投资占比最大的也是实施复杂度最高的。每个路口基本要部署三类东西RSU路侧单元负责与车上OBU通信覆盖范围300到500米安卓群体。RSU安装高度和角度的调整非常讲究装低了车身遮挡严重装高了信号垂直波束覆盖不到。iTSTech项目里RSU一般装在信号灯横臂上或者专用立杆上高度6到8米天线朝向路口来车方向。路侧感知设备主要包括高清摄像头和毫米波雷达。摄像头负责结构化识别——行人、非机动车、机动车检测还能识别车牌和车身颜色雷达负责测距测速雨雾天气、夜间光线较差时雷达依然能稳定输出目标信息。两套传感器的数据在路侧边缘计算节点做融合输出统一的“路口目标列表”再经RSU广播给车辆。信号机对接路口信号灯的状态数据需要从信号机取出来。这里要特别注意iTSTech不是直接控制信号机而是从信号机控制器里“读”当前灯色和剩余时间再通过RSU广播给车辆。是否允许对信号机发送优先请求需要和交管部门确认开放协议接口。这种“只读感知、按需请求”的设计最大限度保障了信号系统的安全和稳定。路侧的边缘计算节点是常常被忽略的重点它承担了数据汇聚、传感器融合、目标跟踪和预警决策算法。有了边缘节点路侧不需要把所有视频流都传回中心减少了回传带宽压力也大幅降低了决策时延。2.3 云端平台不是为了“看个地图”做的系统很多车路协同项目做完了云端平台只剩一张大屏展示看几个动效就完事。iTSTech在这块的设计会务实很多。云端平台在项目里的核心职责有三个资产台账管理、数据汇聚分析、运营策略下发。资产台账管理就是所有OBU、RSU、信号机对接单元、边缘节点的注册、状态监控、固件升级哪个设备掉线、哪个传感器离线平台上一目了然。数据汇聚分析是实时接收车端和路侧上报的所有事件数据包括车辆轨迹、预警事件、信号优先请求记录、乘客流量统计沉淀到数据仓库里做离线分析。运营策略下发则是把调整后的算法参数、线路信息、优先策略通过云平台推送到端侧设备。对于公交公司的调度员来说平台给出的是真正可用的信息所有在线公交车的实时位置、预计到站时间、驾驶员险情预警统计、信号优先成功率指标。这些数据可以和大屏幕、票务系统、排班系统做对接。2.4 数据安全边界别等项目上线再补车路协同是典型的CPS系统数据涉及运营安全和用户隐私安全设计不能后面补。iTSTech在通信层做了双向认证和加密OBU与RSU之间通过车联网通信证书做身份校验防止伪造节点混入网络。数据在传输链路端到端加密云端存储做了分级权限管理。实践中发生过“有人拿着假信号机数据广播造成车辆误判”的问题这在方案设计阶段很难预想到但证书认证可以直接杜绝这类伪造消息。通信安全的选择标准就一句话低时延下也能保证认证。PC5直连消息通常是周期性广播的单包认证耗时不能太高否则算力开销影响消息频率。iTSTech的做法是采用轻量级认证算法关键消息全程带数字签名在车载终端侧用硬件安全模块存储密钥防止软件层窃取。3. 核心场景拆解与参数配置实操3.1 公交信号优先不是“一路绿灯”而是“按需延长”公交信号优先是公共交通车路协同最能直观体现运营价值的场景也是技术团队最容易做砸的场景。很多人的第一反应是“公交车来了就给我变绿灯”真这么干路口其他方向的交通就瘫痪了。iTSTech的信号优先策略分为三级被动优先、主动优先、动态优先。被动优先是信号配时方案在设定时考虑公交线路高峰流量有倾向性地调整绿信比。主动优先是公交车辆到达时通过车路协同请求信号机延长绿灯或提前结束红灯。动态优先则是结合车辆是否满载、是否晚点、等待时间等因素动态计算优先级。一个实际参数配置案例某线路公交车接近路口时车速约36公里每小时即10米每秒距离停止线还有80米预计8秒后到停止线。此时路口绿灯剩余5秒按正常情况车辆到达时刚好变红灯司机只能急刹车等待。假如这辆车满载且晚点2分钟系统判定为高优先级向信号机发送绿灯延长请求延长5秒。公交车正常通过道口横向交通只多等了5秒对整体通行影响很小。配置信号优先有两个关键参数必须调准请求触发距离和优先等级门限。请求触发距离设太远每辆车过路口都发请求站点会反复打断正常配时设太近车队到达时无法预留足够时间。一般来说触发距离设置在120到200米之间配合车速动态计算到达时间窗口。优先等级门限则是结合公交满载率、准点率、车型轻重来打分只有分数超过预设阈值才允许发请求。把这两组参数调平衡项目才算真正从“演示”变成“实用”。3.2 安全预警从“看到危险”到“预警送到眼前”安全类应用是车路协同方案验收时最复杂的部分因为涉及到人、车、路三方状态的综合判断。以公交车右转盲区预警为例公交车准备右转时驾驶员的右侧盲区非常大经常看不见贴着车身右侧行驶的电动车和行人。iTSTech的路侧感知系统能实时检测路口区域内所有交通参与者的位置和速度。当公交车开启右转向灯并进入路口时RSU把盲区内检测到的异常接近目标信息发送给OBU车端屏幕显示目标方位和距离同时语音播报“右侧有非机动车靠近”。实现这个场景有两个容易踩的坑。第一是目标识别的误报率路侧摄像头容易把路边的栏杆、树影识别成障碍物系统刚上线时会疯狂报警司机几趟跑下来就会选择关闭语音。处理办法是加入毫米波雷达的测距信息做交叉验证只有摄像头和雷达都确认存在目标时才触发警报。第二是预警的过早和过晚预警太早司机注意力分散预警太晚留给司机的反应时间不够。iTSTech项目里至少保证在目标进入危险区域前2.5秒发出预警具体阈值还要根据不同公交车车速动态调整。分级预警逻辑也值得分享。车辆正常驾驶时前方有行人但不影响通过系统一般不做提示避免声音干扰。只有当行人可能穿越车辆行驶轨迹、非机动车出现在盲区范围内、前方车辆异常急刹时系统才触发声光报警。分级意味着“少而准”这个思路在整个方案设计里贯穿始终。3.3 到站预测与车内拥挤度乘客体验的加分项精准到站预测是公交乘客感知最明显的功能也是运营方最容易忽略的功能。普通电子站牌大多基于“按时刻表推算”实际运行中一堵车预计到站时间就完全失真。iTSTech在到站预测上采用了多源数据融合不是简单看GPS位置而是把车辆历史到站时间、当前路段拥堵状态、路口信号优先请求的结果、上下客时间统计一起纳入计算。比如某班车从起点站出发系统看到前方三个路口的信号优先请求都成功了中间路段平均车速达到每小时30公里它就能较准确推算到达下一站的时间误差控制在一分钟以内。这个准确度对乘客换乘决策很有价值。车内拥挤度则是结合公交车载重传感数据和站台视频客流统计来估算。车载数据每几秒上报一次开关门次数和上下客流量的值经过云端处理后把“拥挤度”分成舒适、一般、拥挤三档。乘客通过手机App看到下一班车拥挤度可以选择等下一辆还是改乘其他线路。从运营角度看拥挤度数据还能辅助调度员判断是否需要在高峰期临时加车。3.4 调度优化从“经验驾驶”到“数据驾驶”调度优化是车路协同项目里收益最长期的一项但它见效不如信号优先和预警那么直观往往被放在最后一期实施。iTSTech把线路上的所有公交车实时轨迹、每个站台客流预测、每辆车的准点情况汇总后提供给调度中心一个“线路全景视图”。调度员可以清晰地看到哪辆车正在晚点、哪辆车乘客积压严重、哪个路段出现异常拥堵。系统还会自动给出建议比如让后一班车跳站、让前车途中加速、或者调整发车间隔。这里一个比较有用的功能是“串联优先”。当同一线路连续两辆公交车都接近同一个路口时如果第一辆车已经请求了信号优先第二辆车在后方300米内也跟着到达系统会合并请求避免信号机被重复打断。合并逻辑并不复杂但在实际运营中能明显减少对其他方向交通的影响。4. 从图纸到运营车路协同方案落地五步走4.1 第一步现场勘察与点位规划再好的方案落不了地等于零。车路协同项目实施的第一步永远不是“装设备”而是现场勘察。勘察阶段需要确认的信息很多路口几何尺寸、信号机的品牌和型号、信号灯控制柜的位置、路口取电条件和光纤/4G网络回传条件。同时还要评估遮挡情况比如路侧树木是否遮挡RSU天线、高楼是否影响卫星定位信号、是否有大型广告牌影响摄像头视野。RSU的点位选择一般遵循一个原则安装在来车方向的迎车面让天线发射面正对车辆行驶方向。两个RSU之间如果间距过大中间会出现通信盲区间距过小又会造成频率干扰。在iTSTech项目里RSU覆盖半径按250米设计十字路口四个方向各部署一台路口区域基本无缝覆盖。4.2 第二步设备安装与接线安装环节最耽误时间的往往不是打孔立杆而是跟信号机厂家协调。信号机对接一般有两种方式直接通过信号机的SDK接口读取数据或者通过信号机控制器的RS485/网络接口做协议转换。第二种方式兼容性最好因为不需要信号机厂家开放全部内部协议只需提供外部通信接口。在这个环节设备上电后先不急着联网逐个测试本地通信是否正常。RSU安装高度建议不低于6米避免公交车车身高大挡住信号。车载OBU天线装在车顶时注意避开空调外机和金属行李架这些金属物体对天线信号有屏蔽效应。实测中天线和金属物体保持30厘米以上间距通信成功率能有明显提升。4.3 第三步平台配置与地图编辑设备装完进入平台配置。这个阶段最容易出的问题是“设备上线了但数据不对”。平台配置的第一步是建台账把每一台OBU和RSU的ID、位置、关联线路都录入系统。第二步是地图编辑这步最容易被低估。车路协同用的地图不是普通导航地图需要标定路口停止线、车道中心线、公交停车位、信号灯对应关系。如果停止线坐标偏差一米前文提到的信号优先触发判断就会出错。在地图编辑过程中建议安排专人用RTK设备在现场采集关键点坐标不要直接拿卫星影像图去目测打点。之后是算法参数配置。每个路口的优先触发距离、预警区域边界、限速阈值放到参数表里。不同路口参数可以完全不同这也是为什么需要平台端做动态下发。4.4 第四步联调联试按场景表格逐项过联调阶段要把所有功能场景跑一遍并记录每个场景的触发条件和预期结果形成一张验收表。以信号优先为例至少测试这几类情况公交车正常行驶时请求优先、公交车临时变道不触发优先、满载车辆的优先请求是否正常、优先请求连续触发时信号机是否能正确避让其他方向。以预警场景为例至少测试行人横穿且公交车减速、非机动车进入盲区且公交车开启转向灯、机动车逆行闯入等等。联调中最值钱的一步是时间同步。OBU、RSU、边缘计算节点的时间如果不同步预警消息的时间戳就没有意义数据用来做轨迹分析时误差也很大。iTSTech项目里统一采用NTP时间同步同步精度做到20毫秒以内。这个细节如果施工队不熟悉后期查数据会很痛苦。4.5 第五步试运行与持续运维项目上线不是终点而是数据迭代的起点。试运行期间要盯几个指标设备在线率、消息下发成功率、预警误报率、漏报率、信号优先请求成功率。其中漏报率是最致命的。如果碰撞预警系统漏了一个真正的危险目标哪怕只漏一次驾驶员对整个系统的信任就会崩塌。一旦养成了“车路协同预警不可靠”的认知后续再好的功能也推不下去。运维团队需要准备一套异常处置手册设备离线时检查什么、网络延迟升高时检查什么、算法结果异常时如何快速回退到保守策略。车路协同系统是城市运行的基础设施它在服务运营时如果出了Bug不止影响一辆车而是影响一条线路。5. 实际踩过的坑问题排查与避坑经验5.1 定位漂移车子动不动“走”进绿化带项目试运行初期定位漂移是反馈最多的问题。公交车经过高楼密集区、立交桥下、隧道口时GPS信号被遮挡严重坐标点经常在路侧漂出十几米表现在地图上就是车辆轨迹“甩尾”。排查思路是按照问题时间段去回溯OBU的定位模式。RTK定位有“固定解”和“浮点解”两种状态固定解精度高浮点解精度下降明显。当卫星信号遮挡严重时固定解会降级成浮点解定位误差就从厘米级涨到半米级甚至更大。解决这个问题不能只靠加大滤波平滑那会掩盖真实轨迹。iTSTech的做法是主用RTK固定解副用IMU航位推算当定位解算结果和上一帧轨迹偏差超过阈值时用惯性传感器做中间插值。同时配合地图道路约束把所有定位点吸附到公交行驶路线上。三步下来车辆轨迹才稳定下来信号优先的判断逻辑也不会再出现“车子还没到路口就提前触发请求”的现象。5.2 通信时延抖动和连接中断在开放路面上RSU和OBU之间的连接会受到很多因素干扰。测试过程中发现公交车和RSU之间偶尔出现“消息丢失”板卡之间串口通信不稳定。后来排查发现PC5直连在受环境电磁干扰时数据链路的丢包率会上升。排查过程建议做三件事检查OBU天线是否被车辆金属部件遮挡检查RSU附近是否新增了高功率无线设备检查通信频点的干扰信号。如果周围环境频点冲突严重可以考虑调整通信信道配置。运行时延抖动的问题则要在车辆终端侧做QoS优先级让预警类消息始终排在普通消息前面。网络侧还有一个容易忽略的坑V2X数据走蜂窝网络回传时需要使用专用APN通道如果项目配置错用了普通公共APN高峰时段数据会被拥堵的高优先级业务挤掉。这个配置要在项目启动前就跟运营商确定好否则中途变更非常耗时。5.3 数据不一致同一辆车在路侧和云端看到的位置对不上车路协同系统涉及车端、路端、云端三份数据三边各有自己的时间基准和坐标系出现不一致并不奇怪但如果差得太大就说明数据链路有问题。有一次排查信号优先成功率偏低发现同一辆公交车在车端上报的位置和路侧视觉识别的位置相差很大。原因是车端上报的轨迹经过了地图匹配处理落在道路上而路侧视觉识别输出的目标坐标是像素坐标转换过来的两套坐标没有做统一对齐。最后通过标定把路侧坐标转换到同一套参考坐标系里数据才对齐。排查这类问题有个通用技巧把同一时间内车端轨迹、路侧目标列表、云端记录拉出来做对比用时间戳找异常点优先怀疑时间同步和坐标变换这两种问题占比最高。5.4 项目推进层面的四条经验最后说点项目管理上的心得这些往往比技术问题更容易拖垮项目。第一条经验先做闭环试点再谈规模推广。不要一口气铺十个路口、一百辆车。最优做法是先选一个典型路口、两条线路、十辆公交车把从车端、路端到云端的链路完全跑通把参数调优到能稳定复现再扩。试点范围内的场景验证数据后续说服决策者的时候会非常有力。第二条经验跟信号机厂商的接口协调要尽早启动。信号机接口的开放程度决定了信号优先功能能实现多少这是整个项目里不确定性最高的一环。项目初期就要把第三方接入方式以书面形式确认好不要等到施工队进场了才发现接口还没谈成。第三条经验别迷信厂家默认参数。很多设备出厂设置的预警阈值、灵敏度、扫描频率都是基于普通机动车场景不一定适配大型公交车。比如普通车辆发生碰撞的安全时距可能1.5秒就够公交车因为惯性大、刹车距离长预警时距要适当加大。这些参数必须在现场用真实车辆跑出数据后调优。第四条经验项目汇报要给决策者讲“公交彻底改善了哪些”而不是讲“上了多少台设备”。公交集团领导关心准点率提升、安全预警有效覆盖率交通管理者关心路口拥堵指数变化。把业务数据和业务指标做关联分析比罗列技术参数更能推动项目持续投入。结尾把车路协同当成长期运营的伙伴我现在回头看这套iTSTech方案最大的感触是车路协同不是一个“装完就结束”的工程项目更像一个需要长期喂养的“数据伙伴”。刚上线时的预警准确率、信号优先成功率都只能算“及格”随着真实运行数据不断回流参数不断调优效果才会一天天变好。我个人在项目里得到的一条最实用的建议是先把预警的“漏报率”和“误报率”两个指标调到让司机愿意打开系统的程度再谈其他功能。如果司机上车第一件事是关掉提示音那这套系统做得再花哨也白搭。从单路口跑通开始往全线路推进每一次扩展都带着上一阶段的问题清单才能把车路协同从演示方案做成公交运营中真正离不开的基础设施。