第3章 车路协同系统架构：系统总体架构、端-边-云三层架构、路侧单元(RSU)与车载单元(OBU)

各位同学，今天我们来聊聊车路协同系统的骨架——系统架构。说实话，我入行那会儿，大家还在争论"单车智能"和"车路协同"谁才是未来。现在回头看，这根本就不是二选一的问题。车路协同，说白了就是给车装上"千里眼"和"顺风耳"，让路也学会"说话"。

3.1 系统总体架构：一张大网怎么织

先看整体。车路协同系统不是单个设备，而是一张覆盖"车-路-云-人"的通信大网。我个人习惯把这张网分成三个维度：

• 时间维度：毫秒级的实时控制，秒级的交通诱导，分钟级的路况更新
• 空间维度：车周围50米的感知，路口200米的协同，城市级的路网调度
• 层级维度：端侧执行、边缘计算、云端大脑

我在项目中遇到过最头疼的问题，就是大家各搞各的——做车的只管车端协议，做路的只管RSU部署，结果联调时发现数据格式都对不上。所以，架构设计的第一步，不是画框图，而是定好"通信语言"。

3.2 端-边-云三层架构：谁该干什么活

为什么非要分三层？你想想看，如果所有数据都往云端送，等服务器算完再下发，车早就开过三个路口了。所以，必须分层处理。

3.2.1 端侧：最靠近车轮的那层

端侧包括OBU（车载单元）、RSU（路侧单元）、以及各类传感器。这一层的核心任务就两个：采集和响应。

• 采集：GPS位置、车速、转向角、红绿灯状态、行人检测结果
• 响应：碰撞预警、绿波车速引导、紧急制动指令

嗯，这里要注意，端侧的计算资源非常有限。我见过有人试图在OBU上跑深度学习模型，结果发热量能把设备烤熟。端侧只做"轻量级"处理，复杂计算交给边缘。

3.2.2 边缘层：路口的"小脑"

边缘层通常部署在路侧机柜或MEC（多接入边缘计算）服务器上。它的定位是：处理一个路口或连续几个路段的协同问题。

举个例子，当两辆车同时接近无信号灯路口，边缘层需要：

1. 接收两车的BSM（基本安全消息）
2. 计算碰撞风险
3. 在10ms内生成协同决策
4. 通过RSU下发到对应车辆

我曾经在项目里踩过一个坑：边缘层的时钟同步没做好，导致两辆车收到的预警时间差了50ms。结果测试车差点真撞上。从那以后，我要求所有边缘节点必须支持IEEE 1588精确时间同步协议。

3.2.3 云端：全局调度的"大脑"

云端负责的是"大尺度"任务：

• 全域交通态势感知
• 历史数据挖掘与模型训练
• 跨区域协同策略生成
• OTA升级管理

说白了，云端不参与实时控制，它只做"慢决策"。比如，根据过去一周的交通数据，优化某个路口的信号灯配时方案，然后下发到边缘层执行。

层级	时延要求	计算能力	典型设备	主要协议
端侧	<10ms	低（MCU级）	OBU、RSU、摄像头	DSRC、C-V2X PC5
边缘层	<50ms	中（ARM/x86）	MEC服务器、路侧工控机	Uu接口、光纤
云端	>100ms	高（GPU集群）	云服务器、大数据平台	HTTP/2、MQTT

3.3 路侧单元(RSU)：路的"嘴巴和耳朵"

RSU是路侧单元，它干的事很简单：把路况信息"翻译"成车能听懂的消息。

一个标准的RSU包含：

• 通信模块：C-V2X PC5（直连通信） + Uu（蜂窝通信）双模
• 定位模块：支持RTK厘米级定位
• 感知接口：可接入摄像头、雷达、气象传感器
• 计算模块：用于消息封装和本地决策

我建议大家在选型RSU时，重点关注两个指标：发射功率和天线增益。发射功率决定了覆盖范围，天线增益决定了通信质量。别只看参数表，一定要做现场路测。我记得有一次，参数表上写着覆盖500米，实际测试时因为路边树木遮挡，有效距离只有200米。

3.4 车载单元(OBU)：车的"翻译官"

OBU是车载单元，它负责：

• 采集车辆状态（速度、位置、转向、刹车）
• 封装成BSM消息并广播
• 接收RSU下发的RSI（路侧信息）和RSM（路侧安全消息）
• 与车载CAN总线交互，触发预警或辅助驾驶

OBU的安装位置也有讲究。我建议放在前挡风玻璃内侧后视镜附近，这样GPS信号好，天线也容易对准路侧RSU。别放在手套箱里，金属屏蔽会让你怀疑人生。

这里给个简单的OBU消息处理伪代码：

// OBU主循环伪代码
while (vehicle_powered) {
    // 1. 采集车辆状态
    speed = read_CAN_bus(0x0A);  // 车速
    yaw_rate = read_CAN_bus(0x0B); // 横摆角速度
    gps_pos = read_GPS_module();   // 经纬度
    
    // 2. 封装BSM消息
    bsm_msg = pack_BSM(vehicle_id, gps_pos, speed, yaw_rate);
    
    // 3. 广播BSM（每100ms一次）
    send_V2X_message(bsm_msg, PC5_BROADCAST);
    
    // 4. 监听RSU消息
    rsu_msg = listen_V2X_message(PC5_LISTEN);
    if (rsu_msg.type == RSI) {
        // 解析路侧信息，比如红绿灯状态
        traffic_light = parse_RSI(rsu_msg);
        // 计算绿波车速建议
        speed_advice = calc_green_wave(gps_pos, traffic_light);
        // 显示给驾驶员
        show_HMI(speed_advice);
    }
    
    sleep(10ms); // 10ms循环周期
}

这段代码看着简单，但实际工程中坑不少。比如CAN总线读取的时序问题，我曾经遇到过车速信号和横摆角速度不同步，导致碰撞预警误报。解决方案是加一个时间戳对齐模块。

3.5 三层架构的协同工作流

最后，我们用一个典型场景串起来：绿波车速引导。

1. 端侧（OBU）：车辆A以60km/h接近路口，OBU广播BSM消息
2. 边缘层（MEC）：收到BSM后，结合路口信号灯相位，计算出建议车速50km/h可不停车通过
3. 端侧（RSU）：将建议车速封装成RSI消息，通过PC5广播
4. 端侧（OBU）：接收RSI，解析后显示在仪表盘上
5. 云端：记录本次引导数据，用于后续优化信号灯配时

整个过程从车辆进入通信范围到收到建议，要求控制在100ms以内。我实测过，在理想条件下（无遮挡、无干扰），端到端时延能做到50ms左右。