3. 车路云协同体系架构

车路云协同不是把摄像头、雷达和服务器简单堆在一起,而是把“感知—计算—决策—控制”这条链路按实时性、覆盖范围和可靠性重新分配到车端、路侧与云端三个层级。理解这套体系架构,是后续做交通预测、信号优化和协同预警的工程前提。本节从角色划分、通信链路、计算分工和协同机制四个角度展开,并给出可直接对照的部署清单。

一、三层角色的核心定位

车端是“移动感知与执行终端”。它具备最强的实时控制闭环能力,典型设备包括车载摄像头、毫米波雷达、激光雷达、GNSS/IMU、车载计算单元(如 Orin、MDC)和 V2X 通信模块(OBU)。车端负责本车周围 360° 感知、轨迹预测、紧急制动与转向决策,其优势是低时延、直接控制,劣势是视距受限、易被遮挡、单车算力有限。

路侧是“固定视角的感知与边缘计算节点”。典型设备包括路侧摄像头、毫米波雷达、激光雷达、路侧计算单元(RSU/MEC)和路侧通信单元。路侧设备架设在路口或路段高处,能获得俯视视角,弥补车端被遮挡的盲区,同时可对多车进行统一感知与冲突分析。路侧的核心价值在于“上帝视角”和区域协同。

云端是“全局数据汇聚、模型训练与宏观调度中心”。云端接入多路口、多路段、多车辆的历史与实时数据,承担交通流预测、全局路径诱导、信号配时优化、模型迭代和高精地图更新。云端算力强、存储大、覆盖广,但通信时延和带宽是其主要约束。

一句话概括:车端管“本车实时控制”,路侧管“区域协同感知”,云端管“全局预测与优化”。三者不是替代关系,而是按时间尺度和空间尺度分层协作。

二、通信链路:谁和谁说话,用什么说

车路云体系中的通信链路可分为四类:车—路(V2I)、车—车(V2V)、车—云(V2N)、路—云(RSU—云)。V2I 和 V2V 通常基于 PC5 直连通信(C-V2X),时延可做到 10~20 ms,适合碰撞预警、盲区提醒等安全类业务;V2N 和路—云通常走 Uu 蜂窝链路,时延 50~200 ms,适合交通流预测、路径诱导等非紧急业务。

工程上常把消息分为两类:一类是高频、小体积、强实时的 BSM(基本安全消息)和 RSI(路侧信息),走直连链路;另一类是低频、大体积、弱实时的交通流统计、预测结果和地图更新,走蜂窝链路。链路选择错误,会导致安全业务时延超标或带宽浪费。

云端平台 交通流预测 · 信号优化 · 模型训练 全局路径诱导 · 高精地图更新 时延 50~200 ms · 大带宽 · 强算力 路侧边缘节点 路侧摄像头 / 毫米波雷达 / 激光雷达 RSU / MEC 边缘计算单元 区域融合感知 · 冲突分析 · 信号控制 时延 10~50 ms · 固定视角 · 覆盖路口 车端智能终端 车载摄像头 / 毫米波雷达 / 激光雷达 GNSS/IMU · 车载计算单元 · OBU 本车感知 · 轨迹预测 · 紧急控制 时延 <10 ms · 移动视角 · 直接执行 车—车 V2V(PC5 直连) BSM 广播 · 碰撞预警 · 编队协同 路→云:交通流统计 / 事件上报 云→路:预测结果 / 配时方案 车→云:轨迹 / 请求 / 状态 云→车:路径诱导 / 预警 / OTA 路→车:RSI 路侧信息 / 信号相位 车→路:BSM 车辆状态 / 感知共享 PC5 直连 链路选择原则 安全类业务(<20 ms)走 PC5 直连;预测与优化类业务(50~200 ms)走 Uu 蜂窝链路。

三、计算分工:什么算在车上,什么算在路边,什么算在云上

计算分工的核心依据是“时延敏感度”和“数据覆盖范围”。车端负责毫秒级闭环:AEB 自动紧急制动、车道保持、本车轨迹预测,这些任务不能依赖外部链路,必须在本地完成。路侧负责十毫秒到百毫秒级区域任务:多目标融合感知、路口冲突点识别、信号相位建议、盲区预警。云端负责秒级到分钟级全局任务:短时交通流预测、区域信号协调、路径诱导、模型训练与下发。

层级 典型计算任务 时延要求 算力位置 失效影响
车端 本车感知、轨迹预测、AEB、车道保持 <10 ms 车载计算单元 直接影响行车安全
路侧 多目标融合、冲突分析、信号建议、盲区预警 10~50 ms RSU / MEC 区域协同能力下降
云端 交通流预测、信号优化、路径诱导、模型训练 50~200 ms 或更高 云数据中心 全局优化失效,局部仍可运行

四、协同机制:三层如何形成闭环

协同机制可以概括为“感知共享—融合预测—协同决策—执行反馈”四步闭环。第一步,车端和路侧分别感知,车端通过 BSM 广播本车位置、速度、航向角,路侧通过 RSI 广播路口信号相位、排队长度和事件信息。第二步,路侧 MEC 将多车 BSM 与自身感知结果融合,形成区域交通态势;云端汇聚多路口态势,运行预测模型。第三步,云端输出未来 5~15 分钟交通流预测和信号配时建议,路侧结合实时车流做微调,车端根据路侧和云端信息调整路径或速度。第四步,执行结果通过 BSM 和状态上报回流,形成闭环修正。

协同机制的关键不是“谁替代谁”,而是“谁在什么时间尺度上负责什么”。车端保证安全底线,路侧保证区域协同,云端保证全局最优。任何一层失效,其他层应能降级运行。

五、典型场景:十字路口盲区预警

以城市十字路口为例:一辆车准备左转,对向直行车辆被大型车辆遮挡,车端摄像头和雷达无法看到。此时路侧摄像头和雷达从高处感知到对向直行车辆,RSU 在 20 ms 内计算出冲突风险,通过 PC5 向左转车辆发送 RSI 预警。车端收到预警后,在 HMI 上提示驾驶员或触发减速。同时,路侧将路口排队长度和流量上传云端,云端更新区域交通流预测,并在下一个周期调整信号配时。这个场景中,车端、路侧、云端各自承担了不可替代的角色。

六、常见误区与复盘

  • 误区一:把所有计算都放到云端。安全类业务时延要求低于 20 ms,云端链路无法稳定满足,必须由车端和路侧兜底。
  • 误区二:路侧只做通信不做计算。如果 RSU 只转发数据,区域融合和冲突分析仍由云端完成,时延和带宽都会成为瓶颈。
  • 误区三:忽视时间同步。车端、路侧、云端的时间戳必须统一到同一时钟源,否则融合感知会出现“鬼影”和误判。
  • 误区四:没有降级策略。一旦 V2X 链路中断,车端应能依靠本地感知继续行驶,路侧应能独立完成信号控制。
# 车路云协同配置示例(简化)
vehicle:
  obu_id: "OBU-京A12345"
  v2x_mode: "PC5+Uu"
  local_compute: "AEB, lane_keep, trajectory_predict"
  report_interval_ms: 100

rsu:
  rsu_id: "RSU-路口-001"
  sensors: ["camera", "radar", "lidar"]
  edge_compute: "fusion, conflict_analysis, signal_advice"
  broadcast_interval_ms: 50

cloud:
  endpoint: "https://cloud.traffic.example.com"
  tasks: ["flow_predict", "signal_optimize", "model_train"]
  predict_horizon_min: 15
  update_interval_s: 30

总结来看,车路云协同体系架构的本质是“分层解耦、按需分配、闭环协同”。车端解决“最后一米”的安全控制,路侧解决“最后一百米”的区域协同,云端解决“全局最优”的预测与调度。只有把角色、链路、算力和协同机制四件事同时设计清楚,后续的交通预测工程才有稳定的运行基础。