自动驾驶示范区建设核心：路侧感知与云控平台全链路解析

简介：北京市高级别自动驾驶示范区建设发展报告（2022年度）系统梳理了示范区从设立到2.0阶段的建设历程，围绕车路云一体化技术路线、智能网联汽车政策创新、路侧基础设施与云控平台部署等关键内容展开，帮助读者全面了解高级别自动驾驶示范区的建设模式与政策体系，适合智能网联汽车从业者、政策研究人员及自动驾驶技术开发者阅读参考。整个资源为单一PDF文档，约6.36MB，内容涵盖前言、五大部分及大事记附件，结构完整，便于全文检索与对照学习。报告详细呈现了60平方公里内329个智能路口实现车路云一体化功能覆盖的实践成果，并介绍了“2+5+N”政策体系、OBU车载终端应用以及自动驾驶出租车、无人配送等落地场景。已有128人学习下载，对于理解中国高级别自动驾驶“北京经验”和车路云协同路径具有较高参考价值。

1. 北京市高级别自动驾驶示范区：年度报告背后藏着的路侧工程坐标系

把自动驾驶落地到城市开放道路，最先卡脖子的往往不是算法而是路口怎么改。北京市高级别自动驾驶示范区的年度建设发展报告，通篇在讲一件事：把车、路、云、网、图拉成一张可运营的网。2023年5月发布的这份2022年报告，对自动驾驶从业者、路侧设备厂商、测试工程师和云控平台开发者来说，是一套难得的工程坐标系，它把路侧感知如何选型、边缘节点如何部署、云控平台如何承接数据、测试监管如何闭环这些环节，从概念落到了具体建设路径。下面不转述报告原文，只按一线工程师做方案的习惯，把这个示范区建设链路里最值得复用的工程细节逐层拆开。

2. 示范区路侧感知设施建设：路口改造的选型逻辑与边缘部署

路侧感知是示范区建设中投入最大、也最容易被低估的一环。很多团队在一开始把精力放在车端算法上，等进入示范区才发现，路口全息感知的数据质量直接决定了车路协同的上限。这一章从设备选型、数据融合、边缘模型部署三个层面，把路口从物理改造到感知能力落地的完整过程讲清楚。

2.1 路口设备选型：激光雷达、毫米波雷达与摄像头的分工表

示范区的路口改造不是摄像头越多越好，而是按“覆盖、冗余、可标定”三个原则来配设备。覆盖是指无死角看到整个路口的交通参与者；冗余是指单一传感器失效时其他传感器还能维持基础感知；可标定是指所有传感器共享同一个路口坐标系，否则后融合只是纸上谈兵。

选型时有两条容易被忽略的规则。第一条，激光雷达不要只盯线数，更要看垂直视场角能不能覆盖近处低矮的非机动车。第二条，毫米波雷达在路口场景下不能作为唯一感知源，它对静止目标的检测经常不稳定，必须用摄像头或激光雷达做交叉验证。示范区的路口改造通常会按“一杆一柜一箱”的物理格局铺设备，即一根灯杆、一个边缘计算柜、一个信号控制箱，感知设备全部上杆，算力下沉到杆旁机柜。

2.2 从点云到结构化信息：路侧融合感知的工程链路

路侧感知的目标不是保存原始点云和视频，而是把多路传感器数据融合成“结构化目标列表”，再通过RSU广播给周围车辆，同时上报云控平台。工程链路通常分为四步：时间同步、空间标定、目标级融合、轨迹追踪。时间同步以PTP或GPS授时为主，空间标定依赖路面标记点和标定杆完成。

下面是一段路侧感知节点输出结构化目标的Python数据结构示例，它定义了融合后每个交通参与者的最小信息集：

# 路侧融合感知节点：将多传感器结果合并为统一目标结构 import json import time from dataclasses import dataclass, asdict @dataclass class TrackTarget: track_id: int # 全局轨迹ID，同一目标跨帧保持一致 x: float # 相对路口中心点的东向偏移，单位m y: float # 相对路口中心点的北向偏移，单位m vx: float # 东向速度分量，单位m/s vy: float # 北向速度分量，单位m/s heading: float # 航向角，单位rad obj_type: str # 目标类型：car / bike / pedestrian / truck confidence: float # 融合置信度，取值0.0~1.0 ts: int # 微秒级时间戳，用于云控平台时间对齐 def build_target_message(raw_objs, origin_x, origin_y): """把多传感器原始结果转换到路口坐标系并生成消息列表""" targets = [] for raw in raw_objs: t = TrackTarget( track_id=raw["track_id"], x=raw["x"] - origin_x, y=raw["y"] - origin_y, vx=raw["vx"], vy=raw["vy"], heading=raw["heading"], obj_type=raw["obj_type"], confidence=raw["confidence"], ts=int(time.time() * 1_000_000) ) targets.append(asdict(t)) return json.dumps({"targets": targets, "count": len(targets)})

这段代码的关键在坐标系转换。origin_x和origin_y是路口中心点在全局坐标系下的位置，所有设备标定完成后，原始坐标都要减去这个原点，让下游订阅方拿到的是以路口为中心的局部坐标，而不是依赖经纬度的全球坐标。ts字段必须用微秒级而不是毫秒级，因为云控平台做多路口数据回放时，毫秒级时间戳在高速场景下会产生明显的插值误差。

2.3 自动驾驶语义分割模型在边缘节点上的部署参数

路侧边缘节点和车端不同，它的优势是算力更大、供电稳定、联网带宽有保障，但劣势是散热受限、机柜空间小、现场维护成本高。因此路侧感知模型的分工通常是：检测与追踪用轻量级目标检测网络，可行驶区域、停止线、车道线识别则交给自动驾驶语义分割模型，两个模型并行跑在同一颗边缘计算芯片上。

模型部署我一般采用TensorRT做推理加速，把训练好的ONNX语义分割模型转成TensorRT引擎。以下命令是部署时的典型做法，动态batch按路口实际车流密度设置：

# 将语义分割模型转换为TensorRT引擎，并在边缘节点上验证优化效果 trtexec --onnx=freespace.onnx \ --saveEngine=freespace.engine \ --fp16 \ --minShapes=input:1x3x960x1280 \ --optShapes=input:4x3x960x1280 \ --maxShapes=input:8x3x960x1280 \ --workspace=2048

--fp16开启半精度推理，语义分割对精度损失不敏感，但推理速度能提升近一倍。三个shape参数分别对应最小、最优、最大batch，optShapes应该按路口高峰时段的实际并发帧数来设置，而不是越大越好，过大的batch反而会让显存分配失衡。--workspace控制网络层融合时能使用的显存上限，边缘卡显存通常只有8GB到16GB，给到2GB是一个比较保险的起步值。

提示：边缘节点上尽量不要把检测和分割两个模型串行加载，冷启动时间会拖慢整个感知链路。正确做法是进程常驻，模型常驻显存，通过共享内存接收相机帧。

3. 车路云一体化与云控平台：数据怎么变成自动驾驶数据集

路侧感知设备解决了“看得见”的问题，但示范区真正有价值的是“看得全”。车路云一体化的核心不在路侧，而在云端能不能把上千个路口的感知数据、信号灯状态、车辆轨迹汇聚成统一的数据底座。这一章从协议选型、数据对齐、数据集构建三个环节，还原云控平台的建设逻辑。

3.1 路侧消息协议：MAP、SPAT、RSM的订阅关系表

示范区车路协同的消息交互在工程实现上有相对固定的消息集。RSU按固定频率对外广播信号灯状态、地图和感知目标，云控平台和车端各自订阅自己关心的消息。常见做法是在RSU和云平台之间建立两条独立数据通道，一条走标准V2X消息集，一条走业务自定义的增强感知消息。

RSM消息的频率最值得关注。10Hz是路口场景的基本下限，低于这个频率，车端做轨迹预测时目标位置插值误差会超过半米；示范区核心路口一般会开到20Hz，代价是边缘节点上行带宽和云控平台入库压力翻倍。工程上通常采用分级订阅策略：所有路口以10Hz向区域汇聚节点上报，只有重点路口或事件触发时段提升到20Hz。

3.2 数据对齐与清洗：云控平台的第一道工序

云控平台接收的数据来自多个异构源，时间戳来自不同设备的本地时钟、坐标来自不同路口中心点，直接入库查询会产生大量数据“幻觉”。数据对齐是数据链路的第一步，也是后续判断数据质量的基准。

以下是一个典型的多路口感知数据对齐脚本片段，使用Pandas的滑动窗口近似匹配：

# 多路口RSM数据与SPAT信号灯数据的时间对齐 import pandas as pd def align_intersection_data(rsm_df: pd.DataFrame, spat_df: pd.DataFrame): # 将微秒时间戳按100ms窗口取整，实现粗略对齐 rsm_df["ts_bucket"] = (rsm_df["ts"] // 100_000) * 100_000 spat_df["ts_bucket"] = (spat_df["ts"] // 100_000) * 100_000 # 使用merge_asof匹配最近一条信号灯状态记录 aligned = pd.merge_asof( rsm_df.sort_values("ts_bucket"), spat_df.sort_values("ts_bucket"), on="ts_bucket", direction="nearest", tolerance=100_000 ) return aligned

为什么用merge_asof而不是普通merge，因为RSM和SPAT的发布时间天然不同步，普通等值连接会产生大量空值。ts_bucket取100ms窗口，对应RSM 10Hz的上报间隔；tolerance=100_000表示微秒单位下的100毫秒容忍度，超过这个窗口的消息会被丢弃。实际生产环境里，这个对齐过程通常不是用Pandas跑，而是写入Flink或Spark Streaming等流处理框架，但窗口和容差的设置逻辑完全一致。

3.3 自动驾驶数据集构建：事件切片与困难样本挖掘

示范区云控平台经过一段时间运行，会积累海量轨迹数据，这些数据经过清洗和标注，就变成了自动驾驶数据集。构建数据集不是简单地从原始库里抽样，而是要有明确场景导向，特别是从监管事件里挖掘困难样本。

下面这段Shell命令用来从原始数据流中抽取“接管事件”前后各10秒的感知片段，作为训练集负样本：

# 从事故/接管事件表中读取时间点，批量切分原始感知流 EVENT_CSV=regulatory_events.csv RAW_ROOT=/data/raw/2022-09-01 OUT_ROOT=/data/dataset/negative while IFS=, read -r event_id ts location; do # 事件前后各10秒，转换成微秒时间戳 start=$((ts - 10 * 1000000)) end=$((ts + 10 * 1000000)) # 调用切片工具，按路口和时间范围抽取RSM/SPAT消息 segment_extract \ --input "$RAW_ROOT" \ --output "${OUT_ROOT}/${event_id}" \ --start "$start" \ --end "$end" \ --location "$location" done < "$EVENT_CSV"

这个切片流程有三个参数值得注意。ts是事件触发时的Unix微秒时间戳，不同来源的事件表可能混用秒和毫秒，脚本执行前必须统一单位；location用于定位到具体路口，避免把全城数据都切进来造成存储浪费；10 * 1000000这个窗口长度不是拍脑袋定的，接管事件前后的数据至少要覆盖目标从出现到消失的完整过程，10秒对应高速场景下目标行驶约200米。自动驾驶数据集的负样本占比通常要高于正样本，因为长尾场景才是路测中真正见不到、但模型必须要扛住的部分。

4. 自动驾驶测试与监管闭环：仿真、开放道路与远程监控

示范区的价值不全在建设和运营，还在于它形成了一套可复制的测试监管方法。这一章聊仿真测试与实车测试的分工、联合仿真环境搭建，以及监管平台的核心规则设计。

4.1 仿真测试与开放道路测试的分工边界

示范区里的自动驾驶车辆测试不是一上来就跑开放道路，而是先仿真、再三环、后开放。仿真负责跑回归和极端场景，开放道路负责验证真实交互。两者不是替代关系，而是接力关系。

仿真测试的规模通常比实车测试大两个数量级。一个示范区测试牌照申请团队，每天跑2万公里仿真里程很常见，但开放道路一天只能跑几百公里。所以仿真测试的价值不在“模拟得像”，而在“场景覆盖全”——把极端天气、非机动车切入、前车急刹这些实车难复现的场景全部前置到仿真阶段。

4.2 联合仿真环境搭建：carsim、NI与VTD的接口约定

在自动驾驶仿真领域，车辆动力学模型、实时仿真机和场景引擎的联合使用频率非常高。VTD负责生成场景和传感器仿真，CarSim负责输出车辆动力学响应，NI实时机箱负责把两者在确定性时间下连接起来。这个组合经常被拆成“课题一”：让CarSim车辆模型跑在NI实时机上，同时接收VTD场景里给出的道路和交通流输入。

以下是一个典型的联合仿真步长配置片段，用于说明三者之间的时序关系：

# 联合仿真课题一时间配置：VTD场景刷新与CarSim动力学步长解耦 simulation: scenario_engine: VTD dynamics: CarSim realtime_target: NI PXI carsim: step_size: 0.001 # 动力学积分步长，单位秒 decimation: 10 # 每10个动力学步向VTD输出一次状态 vtd: frame_rate: 20 # 场景刷新率，单位Hz sensor_update: 50 # 传感器仿真更新率，单位Hz ni_rt: scheduling: "TC3" # 定时循环任务，优先级高于普通线程

CarSim的积分步长取0.001秒是为了保证轮胎力和悬架计算的数值稳定性，但场景引擎不需要这么高的刷新率，所以通过decimation每10步向外发布一次车辆状态。sensor_update和frame_rate的差异是故意为之，摄像头仿真不需要每帧都重算物理，50Hz已经接近真实相机帧率上限。

注意：联合仿真最常见的故障是实时任务超时。如果NI机箱报“错过同步信号”错误，优先检查CarSim步长是否被改大、decimation是否设置过分频，而不是怀疑VTD场景加载慢。

4.3 远程监管平台：接管事件与异常行为的规则引擎

监管平台的建设目标是“看得见、管得住、可追溯”。它不仅采集车辆位置和速度，还要记录每一次接管、急刹和碰撞预警，并触发相应的告警和取证。监管规则的实现一般用流式计算引擎加规则表，规则表直接决定告警灵敏度。

以下是一条典型的监管规则SQL示例，用于检测路口超速行为：

-- 监管平台规则引擎：连续3秒平均速度超过路口限速即触发告警 SELECT vehicle_id, road_id, window_end, AVG(speed) AS avg_speed, COUNT(*) AS sample_count FROM vehicle_state_stream WHERE road_id IN (SELECT road_id FROM speed_limit_table WHERE limit_speed <= 40) GROUP BY vehicle_id, road_id, TUMBLE(ts, INTERVAL '3' SECOND) HAVING AVG(speed) > 40 AND COUNT(*) >= 15;

TUMBLE(ts, INTERVAL '3' SECOND)表示每3秒滚动一次窗口，COUNT(*) >= 15用来过滤数据稀疏的路段，避免因定位丢帧导致的误判。限速条件放在子查询里而不是直接写死，是因为示范区每个路口的限速值并不一致。监管规则的核心原则是“宁可漏报不可错报”——误报会淹没监控人员的注意力，错报则会直接降低监管数据的可信度。

5. 用公开报告反推工程量：一个可复核的算力与存储估算脚本

示范区年度报告里最容易读到的数据是“改造路口数”“累计测试里程”和“云端数据规模”。这些数据对普通读者只是成绩单，但对做方案的人来说，可以用来反向验证自己的工程量估算是否合理。下面给出一个简单的估算脚本，输入报告里的公开数据，输出路侧存储与算力量级，用于在方案评审阶段快速对数量级。

# 根据公开报告中的路口改造数据，反推路侧算力与存储需求 # 输入参数据实填写，示例值用于演示量级关系 N = 100 # 从报告“设施建设”章节摘录的路口改造数 M = 256 # 单路口同时跟踪目标数上限 F = 10 # 路侧感知融合帧率，单位Hz payload = 600 # 单条结构化目标消息约600字节 active_ratio = 0.7 # 高峰时段占比70%，其余时段降频 day_gb = N * M * F * payload * 86400 * active_ratio / 1e9 print(f"单日新增结构化数据约 {day_gb:.1f} GB") print(f"按90天滚动存储计算，需要 {day_gb * 90 / 1024:.1f} TB 存储") # 边缘算力估算 edge_tops = 60 # 单张边缘推理卡的INT8算力，单位TOPS cards_per_road = 2 # 单路口按2张推理卡设计，主备冗余 total_tops = N * cards_per_road * edge_tops print(f"路侧边缘总算力约 {total_tops / 1000:.2f} POPS")

估算时有两个参数要重点审视。active_ratio设为0.7是考虑夜间低车流时段路侧感知可以降频到2Hz，这个值要看示范区是否要求全天候全要素感知，如果要求24小时连续采集，应改为接近1.0；payload=600字节是结构化目标的保守估计，如果目标列表里还带轨迹预测和识别分类的扩展字段，单目标可能突破1KB，存储量会成倍增加。用报告公开数据做反推时，把每一项假设写进脚本注释，评审时才能快速把数字对回来，而不是用一套黑盒计算糊弄过去。

本文还有配套的精品资源，点击获取