11.1 智慧交通与V2X通信
11.1.1 智慧交通体系框架
一座城市每天有数十万乃至数百万次出行，每一辆车、每一个人、每一个信号灯都在产生数据。交通治理的难点，不在于缺少数据，而在于这些数据散落在交警、公交、停车、气象等多个孤岛系统中，彼此之间的“语言”不通，时序不同，格式各异。解决问题需要一个共同的架构框架——智慧交通系统（Intelligent Transportation System, ITS）的分层模型。这个模型并非凭空创造，而是参考了ISO 14813等国际标准对交通信息与控制系统（Traffic Information and Control System, TICS）的定义，保证不同厂商的设备和软件能在统一的语义空间中对话。
ITS的目标不是把路修得更宽，而是把路“用得更聪明”。从物联网架构的视角看，智慧交通本质上是将感知、通信、计算和决策能力嵌入整个交通物理世界。下面的四层架构从下到上逐一展开，每一层承担明确的工程职责，层与层之间通过标准化接口解耦。
感知层回答“路上发生了什么”这个根本问题。设备包括地磁线圈、微波雷达、激光雷达（LiDAR）、摄像头、气象传感器以及车载通信单元（On-Board Unit, OBU，V2X 车载终端，常集成定位模块）。过去这些设备大多独立运行——摄像头只抓拍违法，线圈只统计车流量。在分层架构中，感知层必须做一件事：将物理世界的异构信号抽象为上层可理解的数据。同一路口可能装着不同供应商的传感器，输出的数据结构、采样频率、坐标系千差万别。工程中常用的做法是在路侧机柜里部署协议适配器，把所有通信接口转换为统一的JSON Schema或Protobuf格式。感知层还负责输出“数字车牌”信息——这是车-云安全认证和计费的依据。
网络层负责把感知数据从路边、车上传到后方处理中心。交通场景对网络有特殊要求：车辆驶过路侧单元（Roadside Unit, RSU）时相对速度极高，紧急制动预警需要毫秒级响应。主流方案有专用短程通信（Dedicated Short-Range Communication, DSRC）、蜂窝车联网（Cellular Vehicle-to-Everything, C-V2X），以及光纤或工业以太网用于路侧骨干连接。网络层还需解决异构协议互通：一个路口可能同时有串口通信的信号机、基于MQTT发布的路侧单元和通过CoAP上报的浮动车GPS数据。聚合网关部署在路侧机箱里，负责协议转换和本地缓存，确保数据不因瞬时网络抖动而丢失。
平台层是整个ITS的大脑。它在云端或边缘数据中心完成海量接入管理（管理百万级设备连接）、时序数据存储、实时流计算和历史数据归档分析。平台层容易被忽视的是数据治理：不同供应商的传感器使用不同坐标系、时间基准和数据格式，不做清洗对齐，上层分析无法落地。平台层还须输出标准API，供上游应用和第三方系统进行数据交换。这呼应了“通过一个开放平台连接所有系统……数据的交叉利用是取得成功必不可少的要素”这一实践原则。
应用层直接面对交通管理者、驾驶员和公众。典型应用有智慧信号灯控制、绿波带诱导、公交优先通行、可变车道管理和停车诱导。设计时不能只追求单点优化，好的应用系统必须建立在全局优化目标之上，依赖平台层提供区域范围的交通态势感知。应用层还需考虑过渡兼容：传统车辆和非网联车辆仍依赖物理信号灯，网联车辆则可获得数字化灯号和导航指引，两种模式并行。更进一步，应用层会融合共享汽车、公交、自行车等多种出行方式，提供“一次行程、一个界面”的联合运输服务——这正是MaaS（Mobility as a Service）的核心理念。
四层架构是纵向的“骨架”，但智慧交通还需要横向协同——即“车-路-云”闭环。车辆通过智能网联车载单元OBU上传实时位置与运动状态，路侧单元RSU同步信号灯、限速和事故信息，云端平台做全局调度与预测，再通过路侧网络下发给车端。智能网联汽车在这里扮演双重角色：既是数据源，也是执行器。理解分层架构与“车-路-云”协同，就为后续讨论V2X通信技术选型和路侧设备部署打下了基础。
11.1.2 V2X通信技术选型
如果车联网是一套神经系统，V2X（Vehicle-to-Everything，车联万物）通信就是神经纤维。车辆（V）、路侧基础设施（I）、行人（P）和云端网络（N）之间必须实时交换信息——前车急刹、信号灯即将变红、行人突然闯入视野——这些消息从“能否到达”到“何时到达”，取决于底层的通信技术。选错了，系统就形同虚设。
这一节拆解两条被广泛讨论的路线：DSRC和C-V2X（蜂窝车联网）。它们的设计理念、性能边界和产业生态差异明显，选型时需要在技术指标以外，统筹部署成本和未来演进路径。
DSRC：基于IEEE 802.11p的成熟体系
DSRC的标准化工作可追溯至20世纪90年代末美国联邦通信委员会为智能交通预留的5.9 GHz频段。它沿用Wi-Fi的CSMA/CA（载波侦听多路访问/冲突避免）机制，但针对高速移动场景做了物理层优化。核心标准IEEE 802.11p在车载环境下支持较高的相对速度，通信距离通常在数百米级，端到端时延控制在满足碰撞预警需要的级别。IEEE 1609系列（WAVE协议栈）定义了上层协议：1609.4规定多信道操作，车辆在不同信道间切换，既接收安全消息（如基本安全消息BSM），也处理非安全应用（如路测数据下载）；1609.2负责加密与签名，保证消息真实性和防篡改。
DSRC 是经过长期验证的技术栈，支持不经过 RSU 的直接 V2V 广播，也支持车辆与 RSU 之间的 V2I 通信。它采用竞争式接入，高密度车辆场景可能因信道竞争而增加碰撞和时延；这与“是否存在 RSU”是两个问题。不同国家和地区对 5.9 GHz 频段及技术路线的监管选择不同，美国频段调整也不能被写成全球统一的“DSRC 日落期”。新项目应先核对本地频谱许可、道路基础设施和车端生态，再比较 DSRC 与 C-V2X，而不是仅凭成熟度下结论。
C-V2X：从LTE到5G的蜂窝演进
C-V2X由3GPP在LTE时期首次定义，核心是PC5接口（侧行链路）。它利用LTE的OFDM帧结构，专门为车联网设计了调度机制，不需要经过基站中转就能实现车与车、车与路的直接通信。标准化过程中定义了两个互补模式：
- 模式3（Mode 3）：由蜂窝网络集中分配时频资源，适用于城区高密度场景。基站可以协调邻近车辆的发送时间，避免冲突。
- 模式4（Mode 4）：车辆自主选择资源。车辆在预定义资源池中通过侦听算法寻找空闲信道，即使离开基站覆盖也能维持V2V和V2I通信。模式4正是实现车与路直接通信的关键：路侧信息以广播形式直达车端，通信的建立不再以基站在场为前提。
模式4是C-V2X与DSRC的关键差异：DSRC的CSMA/CA要求车辆在发送前侦听信道，车辆密度增大时碰撞概率上升；模式4则通过资源池预分配和感知算法，在高密度下保持更稳定的时延和丢包率。
后续的5G NR版本在PC5接口上进一步降低了时延，支持更高的吞吐量，并加入更灵活的调度方式。LTE-V2X和NR-V2X的PC5接口可在5.9 GHz频段共存（双模终端可同时支持，但二者是不同的RAT，并非直接兼容），从而实现平滑演进。另需说明的是，5G RedCap（Reduced Capability，3GPP Rel-17定型，2023—2024年逐步商用）并非用于PC5直连通信，而是面向中速率、成本敏感的回传场景——如路侧摄像头视频回传、网关数据上传——可作为4G Cat.4模组与全规格5G模组之间的折中选择。
| 特性维度 | DSRC（IEEE 802.11p） | C-V2X（LTE-V2X / NR-V2X） |
|---|---|---|
| 物理层技术 | OFDM，基于Wi-Fi的CSMA/CA | OFDM，支持集中和分布式调度 |
| 标准组织 | IEEE（802.11p / 1609.x） | 3GPP |
| 通信模式 | V2V / V2I（广播为主） | V2V / V2I / V2N / V2P（单播/组播/广播） |
| 典型通信距离 | 数百米，覆盖单路口 | 与DSRC相当，开阔场景可更远 |
| 端到端时延 | 典型数十毫秒，满足BSM碰撞预警<100 ms预算 | LTE-V2X PC5直连典型20–50 ms（工程量级），NR-V2X目标更低 |
| 数据速率 | 中等速率，支撑安全消息 | LTE版本更高，NR版本可达百兆级 |
| 资源分配 | 竞争式（CSMA/CA） | 集中式（Mode 3）+分布式（Mode 4） |
| 基础设施依赖 | V2V 可直接通信；V2I 与广域覆盖需要 RSU 等设施 | PC5 侧行链路可脱离基站直连；V2N 仍依赖蜂窝网络 |
| 演进能力 | 存量生态成熟，新增部署受地区频谱政策和车端生态约束 | LTE-V2X 与 NR-V2X 持续演进，但代际并非天然互通 |
| 产业生态 | 欧美早期项目为主 | 国内明确主推方向，跨行业共识更强 |
表11-1 DSRC vs C-V2X对比表
注：表中时延为典型工程量级——碰撞预警类业务（如BSM消息）的端到端时延预算通常按100 ms计；LTE-V2X PC5直连典型为20–50 ms，NR-V2X的设计目标更低。
通信模式与典型场景
V2X的通信模式按交互对象分为四类：
- V2V（车-车）：交换碰撞预警、前车急刹、盲区警告等高实时安全消息。两台车需要在百毫秒内建立通信并协商碰撞避免。
- V2I（车-路）：车辆获取信号灯状态、限速提示、可变情报板内容。RSU将相位配时消息（SPAT，Signal Phase and Timing，信号相位与时序）周期性广播，车辆解码后推算剩余绿灯时间。
- V2N（车-网）：提供路况更新、天气预报、高精地图下载等较宽松时延需求的服务，通常通过4G/5G Uu接口而非PC5直接通信。
- V2P（车-行人）：通过手机或专用终端广播位置和运动状态，保护非机动车和行人——这对通信容量提出挑战，因为行人密度远超车辆。
示例场景：一辆车驶近十字路口。DSRC 网络中，RSU 可以周期广播 SPAT 消息；C-V2X 网络中，RSU 也可通过 PC5 广播路侧信息。换成没有 RSU 的郊区路段，两种路线都能支持车辆之间的直接安全消息：DSRC 依靠 802.11p 的竞争式接入，LTE-V2X Mode 4 依靠车辆自主选择侧行链路资源。差异应通过目标密度、信道负载、设备互通和实地测试判断，不能归因于 DSRC 必须经 RSU 中继。
工程选型决策路径
选型不是非此即彼的二选一。实际项目需要从以下维度评估：
- 频段可用性：5.9 GHz频段在不同国家分配方案不同。若本地已将该频段分配给C-V2X使用，部署DSRC会遇到干扰或合规障碍。过渡期的首要问题正是频段兼容：新旧两种制式在同一频段内并存时，必须通过清频退租和信道规划划定各自的保护带，否则同频干扰会让两类系统的可靠性同时受损。
- 基础设施依赖性：RSU 密度主要影响 V2I 服务覆盖，两种路线都存在不依赖 RSU 的直接 V2V 模式。选型应分别验证无基础设施时的 V2V 可靠性，以及部署 RSU 后的路侧服务、运维和证书体系。
- 业务演进预期：如果三年内需要支持高级自动驾驶（如编队行驶或远程遥控驾驶），NR-V2X的低时延和更高可靠性才有价值；若只做基础碰撞预警和信息服务，LTE-V2X足以胜任。
- 前装 vs 后装：车厂前装会选择C-V2X模组；后装市场有时出于成本沿用DSRC配件。工程上需要统一协议栈，避免混装导致互通性断裂。一种可行方案是采用多模模组，同时支持DSRC和C-V2X，实现过渡期的全兼容。
对比表和决策路径图是工具，真正的选型筹码在于业务目标与资源现实之间的匹配。过去十年，V2X市场存在两种理念的拉锯：欧美一度倾向DSRC，而中国和部分亚洲市场从2018年起快速转向C-V2X。随着NR-V2X获得全球主要通信设备商和车厂的研发投入，C-V2X已成为事实上的主流方向。但DSRC仍会在存量的L2级以下辅助驾驶方案中持续存在若干年。工程团队理解两者的差异，不仅为了选型，更为了面对一段“新旧系统过渡并存”的漫长道路。选型时，除了技术参数，还需要评估过渡策略、合规风险和生态生命周期，才能确保投资在五年内不会快速贬值。
11.1.3 路侧设备（RSU）与车载单元（OBU）部署实例
通信技术选型敲定之后，下一步是把协议栈跑在真实的硬件上。这一节用一个例子来交代RSU和OBU的硬件构成、安装方式以及它们与路口信号灯、路侧雷达的联动流程。为了避免与真实的城市项目混同，下面描述的方案并非指代任何一个具体工程，但其中的选型逻辑和组网思路在行业内具有典型性。
案例：示范段全长约15公里，双向六车道，覆盖出入匝道口、互通立交和隧道口。方案规划了24个RSU部署点位，各点位通过光纤回传。参与测试的OBU配置了约200套，分别安装在示范区内运行的公交车和出租车上。
RSU硬件配置与安装
一个典型的RSU由五个核心模块组成，每块的功能边界清楚：
- C-V2X通信模块：工作在5905～5925 MHz的ITS专用频段，通过PC5接口完成车-路直连；量产芯片与模组基于Rel-14 LTE-V2X（NR-V2X侧链尚未规模商用）。发射功率可调，默认配置下覆盖半径约500至800米区间。
- GNSS接收模块：支持多频段（L1/L5），可接入RTK差分修正信号，定位精度在理想条件下优于20厘米。
- 主控处理单元：负责运行V2X协议栈及上层应用逻辑。行业常见选择包括ARM Cortex-A72或同等性能的x86边缘计算模组。
- 回传通信接口：主通道为千兆光纤以太网；另保留4G/5G蜂窝模块作为链路备份，主要用于远程运维和数据补传。
- 天线与电源系统：V2X天线采用双极化定向天线，水平波束宽度约120度。支持POE供电或本地取电。
安装时，RSU通过抱箍固定在道路L型杆件或门架横梁上，离地高度6至8米。天线面朝向来车方向，俯仰角下倾5至10度，以保证视距通信质量，减少多路径干扰。
OBU集成方案与功能模块
OBU的硬件紧凑度远高于RSU，必须在振动、宽温、安装空间受限的环境下可靠工作。它涵盖以下几个关键子模块：
- C-V2X通信模组：提供PC5接口，支持低功耗接收模式，待机电流控制在较低水平。
- 车规级GNSS接收机：可与车辆原装导航系统共用天线，不需要额外开孔。
- 微控制单元（MCU）：负责事件触发的消息处理和本地决策逻辑。
- 车载以太网和CAN总线接口：OBU通过CAN 2.0B总线读取车速、转向角、制动状态等行驶数据，并通过以太网与车载信息娱乐系统或ADAS域控制器对接。
- 安全芯片：单独放置，存储数字证书，执行消息签名与验签。
OBU的电源取自车辆常电（12V或24V），设计有唤醒-待机两级功耗管理——引擎启动或CAN总线出现有效数据时自动唤醒，熄火后进入深度休眠。
与信号灯、雷达的联动流程
RSU与路口信号机之间的数据交互是智慧交通中最基础也最有价值的一类场景。联动流程大致分为六个步骤：
- 信号机控制器通过RS-232/485串口输出当前相位（红/黄/绿）及倒计时秒数，刷新周期固定。
- RSU以固定间隔轮询读取串口数据，并解析为约定的灯色状态码。
- RSU将灯色信息编码为标准SPAT消息，按照国标消息集格式填充。
- RSU通过PC5接口以广播方式发送SPAT消息，射频覆盖半径约500米。
- 车载OBU接收并解析SPAT消息后，结合自身GNSS位置和CAN总线上的车速数据，在驾驶员HMI上显示提示信息。
- 若车辆具备L3级以上的自动驾驶能力，OBU可直接将SPAT消息中的相位和计时信息送入路径规划模块，用于决定加速通过还是减速停车。
除此之外，RSU还能与路侧毫米波雷达或雷视一体机进行数据联动。雷达检测到前方障碍物或异常停车时，将目标位置和速度通过以太网发送给RSU，RSU随即生成RSI消息（Roadside Information），向后方来车广播。从雷达感知到RSU播发，端到端时延要求控制在百毫秒级。
上述时序关系的典型通信流程可概括为图11-2。
表11-2 RSU与OBU硬件配置清单
| 组件类别 | RSU | OBU |
|---|---|---|
| 主控芯片 | ARM Cortex-A72（4核，1.8 GHz）或同等x86处理器 | ARM Cortex-A53（2核，1.2 GHz） |
| V2X通信模组 | 支持PC5接口；标称发射功率23 dBm | 高度集成化PC5模组 |
| GNSS定位 | 多频点接收机，支持RTK差分 | 单频点车规级接收机，支持SBAS增强 |
| 回传接口 | 1×千兆光纤 + 1×4G/5G蜂窝模块（可选） | 无（仅通过PC5通信） |
| IO接口 | RS-232/485（接信号机）+ 1×千兆以太网（接雷达） | CAN 2.0B + 1×千兆以太网（接车载导航） |
| 工作温度 | -40°C ~ +85°C | -40°C ~ +85°C |
| 防护等级 | IP65 | IP67 |
| 典型功耗 | 15～25 W | 3～5 W（待机＜1 W） |
注：上表数据为案例所列典型值，不同厂商设备和不同部署环境下的参数可能有差异，实际项目中应以具体设备手册为准。
部署中的工程权衡
从例子的选型可以提炼出三条贯穿RSU/OBU部署始终的工程判断：
第一，回传链路的冗余设计决定可用性上限。 光纤主链路一旦中断，蜂窝备份能以较低带宽维持远程管理和关键告警，但无法承载完整的数据上行业务。部署时需要评估断纤概率和维护响应时间，决定是否保留本地存储以做断网续传。
第二，OBU的功耗管理直接制约实际续驶里程。 在新能源公交车上，OBU长期唤醒会消耗车内12V蓄电池电量，影响车辆休眠后的自启动。两级功耗管理的设计需要与整车电源策略做联调，确定唤醒阈值和总线信号特征。
第三，RSU覆盖半径不是越大越好。 增加发射功率确实能扩大覆盖范围，但同时会引入更严重的同频干扰和远距离多路径反射。实际部署中，相邻RSU之间通常保留一定重叠区域用于切换和冗余覆盖，而非追求单站最大辐射距离。
这三条判断并非例子独有——它们在大多数城市级车联网项目中都会出现，区别只在于具体的参数窗口和运维策略。
延伸思考
RSU与OBU的部署，本质上是把路侧基础设施的“固定物理世界”和随车移动的“动态信息空间”绑定在一起。这种绑定越牢固，上层应用（信号灯闯红灯预警、绿波车速推荐、无信号灯路口协同通行）的可靠性越高。但绑定本身也意味着运维复杂度：RSU的数量级从测试段的几十个跃升到城市级的数千个时，设备固件OTA、证书轮换、故障远程诊断等运维流程就需要从“人工驱动”转向“平台驱动”。这一转换涉及的系统设计，我们会在第11.5节工程实践中继续讨论。