3. 车路云系统总体架构

车路云协同感知系统不是把摄像头、雷达和服务器简单堆在一起，而是按照“车端—路侧—云端”三层职责划分，通过多类通信链路把分散的感知、计算与决策能力组织成一张动态协同网络。理解总体架构的关键，是同时看清三件事：每层承担什么计算任务、层与层之间用什么链路连接、数据沿什么方向流动并在哪里被融合。只有这三者对齐，系统才能在时延、带宽、算力和安全之间取得平衡。

3.1 三层架构的职责边界

车端是移动感知与执行主体，通常部署车载摄像头、毫米波雷达、激光雷达、GNSS/IMU 和高算力域控制器。车端计算节点强调低时延、高可靠、功能安全，负责本车目标检测、跟踪、定位、局部地图构建和决策控制。它的优势是视角贴近驾驶行为，劣势是视距受限、易被遮挡，且算力与功耗受车规约束。

路侧是固定部署的“上帝视角”补盲节点，由路侧摄像头、毫米波雷达、激光雷达、路侧计算单元（RSU/边缘计算节点）和路侧通信单元组成。路侧计算节点通常具备比车端更强的持续供电与散热条件，可完成多传感器融合、目标结构化、事件检测和局部区域态势生成。它解决的是遮挡、超视距、盲区问题，并把感知结果以轻量化消息广播给周边车辆。

云端是全局调度、数据汇聚与模型进化中心，部署在区域或中心机房，承担全局地图管理、交通态势预测、多路口协同优化、模型训练与OTA下发、日志回传与仿真验证。云端算力最强但链路时延最大，因此它不直接参与毫秒级控制，而是提供秒级到分钟级的全局优化与长期迭代能力。

3.2 通信链路：三类连接与关键参数

三层之间并非单一链路，而是由车—路（V2I）、车—车（V2V）、路—云（R2C）三类链路共同构成。车—路链路常用C-V2X PC5直连或5G Uu，承载路侧感知结果、信号相位、事件预警；车—车链路用于邻近车辆间的意图与轨迹共享；路—云链路通常走光纤或5G回传，承载原始/结构化数据上传与云端策略下发。链路选择的核心矛盾是时延、带宽、覆盖与可靠性的权衡。

从图中可以看出，上行数据流是车端与路侧把感知结果、车辆状态、事件信息逐级汇聚到云端，用于全局态势与模型迭代；下行数据流是云端把策略、模型、地图和调度指令下发到路侧，再由路侧以低时延广播给车端。车端与路侧之间还存在双向的V2I交互，形成局部闭环。

3.3 计算节点的分工与数据流向

三层架构中，计算节点按“近端实时、边缘准实时、云端非实时”分工。车端计算节点完成毫秒级感知与控制；路侧计算节点完成十毫秒到百毫秒级的融合与事件检测；云端完成秒级以上的全局优化与训练。数据流向遵循“原始数据尽量在近端处理，结构化结果向上汇聚，控制指令向下直达”的原则，避免把海量原始视频全部回传造成带宽浪费。

3.4 典型场景：十字路口盲区协同

以城市十字路口为例：路侧激光雷达与摄像头检测到被建筑物遮挡的横向来车，RSCU在80毫秒内完成融合并生成目标结构化消息，经RSU以PC5广播给本车；本车OBU收到后与自身感知结果做时空对齐，若本车传感器尚未看到该目标，则提前触发预警或减速。与此同时，路侧把该事件上传云端，云端统计该路口高频冲突方向，优化信号配时并下发新的相位策略。整个过程体现了车端实时、路侧补盲、云端优化的协同闭环。

3.5 常见误区与复盘

• 误区一：把所有原始数据都传云端。原始视频和点云数据量巨大，回传会挤占带宽并推高时延，正确做法是近端处理、结构化上传。
• 误区二：认为云端算力强就让云端做实时控制。云端链路时延不可控，实时控制必须留在车端或路侧。
• 误区三：忽视链路不对称性。上行带宽与下行带宽、覆盖范围与可靠性往往不同，架构设计要按最弱链路留余量。
• 误区四：路侧只做转发不做计算。路侧若只当“二传手”，就浪费了边缘算力，也无法解决遮挡与盲区问题。

# 典型路侧结构化消息字段（示意）
{
  "msgType": "rsu_perception",
  "timestamp": 1710000000123,
  "rsuId": "RSU-1024",
  "objects": [
    {"id": "obj-7", "type": "car", "x": 12.4, "y": -3.2,
     "vx": 8.1, "vy": 0.2, "confidence": 0.93}
  ],
  "event": "blind_spot_vehicle",
  "ttl": 200
}

复盘来看，车路云总体架构的本质是用分层分工换取系统整体最优：车端保实时，路侧补视角，云端做全局。通信链路决定协同上限，计算节点决定处理能力，数据流向决定系统效率。三者匹配得当，才能让协同感知从“能看见”走向“看得准、传得快、用得好”。