符润展--基于5G-V2X的车路协同方案研究

Posted 2022-08-29 爱是与世界平行

1. 绪论

1.1 课题背景与研究意义

随着中国经济的快速发展，居民的收入水平大幅增长，我国机动车保有量在急剧上升。

根据交通管理局统计调查，截止 2019 年底，国内机动车数量已达到 3.48 亿辆，其中汽车数量已经突破 2.6 亿辆；机动车驾驶人数为 4.35 亿人，其中汽车驾驶人 3.97 亿人[1]。图1-1 显示了中国的汽车数量的变化态势。随着汽车保有量的增加，在给人们带来便利的同时，也产生了交通事故频发、道路严重拥堵、能耗迅速增加等各方面的问题[2]。尽管随着科技的进步，传统的汽车通过配备了高性能的信息终端及高精度的车载传感系统，使得交通事故发生率趋于平稳并且略有下降。但是我国交通事故所导致的死亡率依然较高，大约是发达国家的 4 至 8 倍，说明我国道路交通状况仍需要完善。而作为未来智慧城市不可或缺的部分，旨在改善交通管理效率和提高道路安全的 V2X 通信技术，得到了业界广泛的研究[3]。

V2X(Vehicle-to-Everything)是物联网面向应用的一个概念延伸，是对 D2D(Device to Device)技术的深入研究过程。它指的是车辆跟其周边环境进行信息交互，并根据收集的信息进行分析、决策的一项技术。

通信的周边环境包括交通设施（Vehicle-to-Infrastructure，V2I）、车（Vehicle-to-Vehicle，V2V）、设备（Vehicle-to-Device，V2D）、人（Vehicle-to-Pedestrian，V2P）、网络（Vehicle-to-Network，V2N）[3]。V2X 通信通过高效的无线资源分配以及动态信息的快速交换，将“车辆、路、云”等交通参与要素有机地联系在一起[4]，使得车辆能够克服视觉死角的不足，突破传感器探测范围的局限，获得比单车感知更多的信息，如行人信息、实时路况等一系列交通信息。

同时可以和周边车辆及设施实时共享状态信息，有利于加快智能交通体系的构建，对节省资源、提高驾驶安全性、提高交通效率[5]、改善交通具有重要意义。V2X 要实现与周边环境的信息交互、高效协同以及能源高效利用，需要网络支撑其极低时延和超高速大带宽的需求[6]。

伴随着加速到来的 5G 时代，结合 5G 大容量、高可靠、低时延的特点，5G-V2X 将可以带来新的功能需求和技术革新，在更多领域大展身手。

5G-V2X 的通信模式特点有：一是支持单播、组播和广播工作；二是支持亚米级的高精度定位；三是支持高密度场景下的有效连接和资源分配；四是支持不同的覆盖范围和复杂网络类型，五是可以根据场景需求自适应控制通信的覆盖范围[7]。

因此，对 5G-V2X 环境下相应的车路协同行驶策略的研究与开发，可有效提高交通效率、降低能耗、改善驾驶安全等问题。

1.2 国内外研究现状

1.2.1 车路协同系统发展状况

车路协同系统（Cooperative Vehicle Infrastructure System, CVIS）主要采用互联网技术和无线通信技术获取交通信息, 通过车与路、车与车的通信进行信息共享, 实现车与基础设施、车与车之间的协同, 从而缓解交通拥堵、提高道路交通安全、优化系统资源[8]。近年来，智能交通系统（Intelligent Traffic System，ITS）已成为交通运输领域的前沿，而作为其子系统的 CVIS，随着无线通信技术和电子信息的发展，已然成为日美及欧盟等国家推动的重点，是各国争相研究与应用的热点。

（1）国外车路协同发展状况

美国是最早开展研究的，以 VII(Vehicle Infrastructure Integration)为基础，建立了IntelliDriveSM 项目来深化研究车路协同系统[8]，同时专门分配 5.9GHz 的通信频段用于车路协同通信；日本政府联合企业共同发起 Smartway 计划，用于促进先进安全汽车、基础设施、土地、运输和旅游的发展[9]；欧盟国家主要提出 eSafety[8]，加速交通安全支持系统的开发和集成，推动综合交通运输系统与安全技术的实用化。

（2）国内车路协同发展状况

相较于国外，直至 1980 年，我国才开始加大科技发展交通系统的投入力度。“十一五”期间，国内在车辆自组织网络、车载导航设备汽车安全辅助驾驶等方面进行大量研究，为智能车路协同的研究奠定了基础。2010 年确定车联网为“十二五”发展的国家重大专项；2011 年，“车路协同系统关键技术”项目通过“863 计划”立项，并于 2014 年 2 月验收。在智能交通系统发展中，目前我国战略目标是建立一个基本适应现代交通发展需求的系统，在跨区域，大规模的范围内建立关键技术体系，标准体系和产业集成智能交通应用，协同运营方式[10]。直至今日，车路协同系统的研究已成为中国缓解交通拥堵、建设交通强国的重要抓手。

1.2.2 V2X 技术研究现状

V2X 概念被提出之后，相比较搭载摄像头、雷达等传感设备，应用 V2X 技术有着成本较低、应用场景广泛多样的特点[11]。因此，国内外各家车厂、终端设备供应商都针对该技术进行了大量研究。其发展也历经了两个阶段，有不同的组织对其进行标准制定。目前，支持 V2X 的通信标准主要有两种，包括专用短距离通信（Dedicated Short Range Communication，DSRC）和基于蜂窝网技术的车联网（Cellular-V2X，C-V2X）通信技术[12]。

DSRC 是一种基于 802.11P 标准的高效无线通信技术，可以将道路和车辆有机连接从而进行双向通信，实现数据的实时传输。美国从 1992 年开始发展 DSRC 技术。2010 年，美国确定了底层协议为 IEEE 802.11p 的 DSRC 通信标准[13]。经过 10 年的研发测试，美国交通部已经将 DSRC 确认为 V2V 标准。另外，日本的 V2X 和欧盟的协同式交通系统也是基于 DSRC 技术[14]。因此，国际上形成了美日欧三大 DSRC 标准阵营：美国 ASTM/IEEE、日本 ISO/TC204、欧洲 CEN/TC278[10]。鉴于 DSRC 的发展与应用，我国交通部于 1998 年提出 DSRC 技术领域的专有频段分配为 5.8GHz。DSRC 主要用于短程的车载无线通信，它是 802.11 的扩展和延伸，支持车辆之间以及车辆与路边基础设施之间点对点的传输，具有高传输速率、低时延等特点[16]。然而，DSRC 技术也有其不足之处，系统可靠性和最大传输时延会随着用户数增加愈发不可控，系统容量急剧下降，导致安全架构需全新部署[17]。

除此之外，DSRC 传输距离短，信号容易被建筑物遮挡，需要建设很多信号发射器，而且商业盈利模式不清晰[18]，这也导致了其难以实现大规模商用。对于车辆在非道路环境下获取服务的应用场景，DSRC 很难发挥优势。种种原因，导致 DSRC 技术这么多年以来无法大规模商用，这也使得一直力推 DSRC 技术的美国开始重新分配 5.9 GHz 频段的 75MHz频谱，分配一部分用于 C-V2X 技术，推动 C-V2X 实现商用。

C-V2X 技术是基于蜂窝网通信技术并逐渐演变而来的无线通信技术，支持车、人、路中间进行短距离直接通信以及终端和基站之间进行通信。包含 LTE-V2X 和 5G-V2X 两部分，其中 LTE-V2X 可以实现逐步演进为 5G-V2X。2015 年，3GPP 开始发展 C-V2X 标准，并分别于 2016 年 9 月完成基础 V2X 需求的核心部分，于 2017 年 3 月完成增强 V2X 的需求[19]。

同时，为了面向未来自动驾驶阶段的需求，3GPP 于 2016 年开始启动关于 5G V2X的标准工作，并于 2017 年 6 月完成了需求标准[20]。2018 年 6 月 RAN 启动了“基于 5G 新空口的 V2X（Rel-16）”的研究工作。2017 年 4 月，国际通过了中国提出的 C-V2X 标准立项申请，开始确定 C-V2X 作为候选技术应用于 ISO ITS 系统。同时，我国企业主导制定了 3GPP 中部分 C-V2X 标准及后续演进技术的研究，如华为、中兴、大唐都向 3GPP 提出了大量的提案，在 V2X 领域占据一定的优势。在国家强有力的政策下，C-V2X 技术具有很好的发展前景。

1.2.3 V2X 结合 5G 技术优势

5G 是是未来信息基础设施的重要组成部分，新一代移动通信技术的主要发展方向。与4G 相比，5G 具有“超大连接、超低时延、超高速率”的技术特点[21]，不仅可以为移动终端加速传输速度，提升用户的网络体验，同时还将赋予万物在线连接的能力，实现万物互联。

4G 时代，LTE-V2X 可以通过 V2X 来传输交通数据，而 5G 的到来，让视频以及大数据量可以实时传输，这对于 V2X 而言意义非凡。5G 的应用场景包括“移动宽带增强”、 “低功率海量连接”和“低延时高可靠”。“移动宽带增强”可以为 V2X 提供高速的数据传输率，满足大流量密度需求；“低功率海量连接”支持超千亿数据连接，还可以保证终端的超低成本和超低功耗；“低延时高可靠”可以将端到端时延降至毫秒级，保证了信息的实时性。

1.3 本文的主要研究内容

本文的主要工作首先是设计了一个基于 Apollo 系统的具备自动驾驶功能的汽车，接着在分析了不同 V2X 车路协同方案优劣后设计出一个基于 5G-V2X 的车路协同方案框架，在此框架下，原运行于 V2X 路侧设备的运算任务可卸载到计算能力及存储能力更强的 V2X服务器中。实验证明了此方法可在保证车路协同通信的实时性和准确性的同时，还有效地减少了车载终端资源的开销和方案推广的成本，本文内容安排如下：

第一章主要介绍了本课题的研究背景及意义，陈列当前国内外车路协同系统的研究现状及 V2X 技术的研究进展，同时分析了当 V2X 技术与 5G 两者相结合时凸显的优势。

第二章主要介绍了 Apollo 自动驾驶系统的技术框架，分别包括线控车辆平台、参考硬件平台、软件开放平台以及云端服务平台四部分，同时基于 Apollo 系统设计实现了可以循迹导航的自动驾驶车。

第三章首先分析了现有的不同车路协同框架的优劣，并提出基于 5G-V2X 的车路协同架构的实现，然后主要详细阐述了所提方案的软硬件架构、系统平台及通信机制。

第四章首先介绍了车路协同的部分典型应用场景，然后对典型应用场景的设计进行了详细的分析。最后测试了第三章提出的车路协同框架在典型应用场景下的性能和效率。

第五章是对全文的工作总结以及本课题的未来展望与研究方向。

2. 基于 Apollo 的自动驾驶系统的实现

Apollo 在 2018 年发布了基于视觉、L2 级、限定区域的高速自动驾驶[22]平台架构，如图 2-1 所示。主要包括四个部分:线控车辆平台、参考硬件平台、软件开放平台以及云端服务平台。

2.1 线控车辆平台

线控车辆平台（Vehicle Reference Platform）即对车辆的控制。对于自动驾驶车辆而言，车辆的控制都是线控执行的，即由一系列命令而执行，而不是物理的操作进行执行的。线控执行需要实现对车辆的油门、刹车、转向线性控制以及能够通过 CAN 总线协议发送指令。对于 Apollo 系统而言，需要获取与普通车辆相关的底盘控制协议，从而获取底盘反馈数据，从而将普通车辆改造成自动驾驶测试用车，可以接收并运行 Apollo 自动驾驶系统生成的指令，比如换挡、加减速、转向，并完成对应的操作。

2.2 参考硬件平台

参考硬件平台（Hardware Reference Platform）又称传感器层。主要是集成各种传感器感知汽车周围环境，包括 GPS、IMU、相机、毫米波雷达、激光雷达等。图 2-2 展示了 Apollo参考硬件。

（1）计算单元（Computing Unit）

自动驾驶系统对算力的要求非常高，自动驾驶车上搭载高性能工控机（IPC），用于Apollo 系统的计算工作。工控机作为增强型计算机，采用全钢化工业机箱和模块化设计技术，增强了抗电磁干扰能力，可以作为工业控制器可靠运行在工业环境中。工控机CPU 及其他功能模块均采用插板式结构，提高了抗振动、抗冲击能力[23]。相比于嵌入式设备更稳定、可靠，社区支持及配套的软件也更丰富。

（2）CAN 卡

工控机需要 CAN（Controller-Area-Network）通信语言与汽车底盘进行交互。对于自动驾驶系统而言，CAN 通信作为通信机制，具有高性能、高可靠性的优点。一方面，从 CAN总线上传的底盘数据如当前车速，需要 CAN 卡根-据 CAN 协议解析才能传输至自动驾驶系统；另一方面，自动驾驶系统获取到传感器数据后，也是由 CAN 卡通过 CAN 协议将其转码后发送至底盘。

（3）全球定位系统（GPS）/惯性测量单元（IMU）

GPS 是当前行车定位不可或缺的技术，在自动驾驶定位中也担负起相当重要的职责。

GPS 系统包括由 1 个主控站、5 个监测站和 3 个数据注入站组成的地面控制端，32 颗 GPS卫星组成的卫星端，以及 GPS 接收机组成的用户端[24]。最少只需其中 3 颗卫星，就能迅速确定用户端具体位置，包括经纬度及海拔高度。GNSS 板卡通过天线接收到 RTK 和 GPS 卫星的信号后，进行解译和计算，得到自身的空间位置。在高耸楼群间或隧道里车辆信号容易受遮挡，无法实施电子导航，这时需要依靠 IMU 信息。IMU 可以在 RTK 和 GPS 信号消失之后，依旧提供亚米级定位并持续若干秒，为自动驾驶车处理异常争取时间。同样，在相对定位失效时，IMU 也可以对其结果进行航迹推演，保持一段时间相对定位的精度。当GPS 和 IMU 两者组合之后，能达到更好的定位测姿性能。

（4）感知传感器

摄像头主要用于车道线、交通标示牌、红绿灯以及车辆、行人检测，价格便宜、检测信息全面，但会受到光照和雨雪天气的影响。激光雷达主要用来感知车辆周围环境，使用飞行时间法（Time-of-Flight，TOF）技术，通过获取光线遇到障碍的折返时间来计算距离。

激光雷达不光用于感知，在高精度地图的测绘和定位方面也不可或缺，是自动驾驶必不可少的传感器。毫米波雷达主要用于远距离的跟车、障碍物的检测等。优点是检测不易受到天气影响、速度快且准确，但无法检测车道线交通标志等。

2.3 软件开放平台

软件开放平台（Software Open Platform）包括实时操作系统（Real Time Operating System，RTOS）、运行时框架（Runtime Framework）和应用程序模块层。

（1）RTOS

Apollo RTOS 是 Ubuntu 操作系统结合 Apollo 内核的成果。原始 Ubuntu 系统通过加入Apollo 内核，可以使其成为一个实时操作系统。RTOS 根据传感器测量的数据信息，在给定时间内进行计算和分析并执行相应的操作。“实时”是指操作系统通过车载传感器收集到外界数据后，能够及时进行分析计算处理等操作。实时性能是确保系统稳定性和驾驶安全性的重要。

（2）Runtime Framework

机器人操作系统（Robot Operating System，ROS）是业内通用的机器人编程框架，同时也是学术界通用的框架，它具有三大特性：计算调度模型灵活、调试工具丰富、开发工具包完整，能够统一提供底层通信、配置管理、部署运行等功能，让开发者将精力更多放在研发算法功能上，快速构建系统原型，验证算法和功能[25]。而 Runtime Framework 作为Apollo 系统的操作环境，相较于 ROS 有以下改进：

1）通信性能优化：共享内存

自动驾驶系统为了感知复杂的道路场景并完成自动驾驶任务，需要多种传感器协同工作，以覆盖不同路况和不同场景的需求。而主流的多传感器融合方案基本都会包含激光雷达和相机，庞大的数据量对通信的性能有很大的挑战。Apollo 系统采用的解决方案是共享内存。

一对一传输场景下原生的 ROS 通信和改进后的 ROS 通信如图 2-3 所示。左侧是原生的 ROS 通信，右侧是共享内存通信。对比两者可发现，一对一的传输场景下，同一机器上通过 socket 实现 ROS 节点的进程间通信，中间存在多次内核空间和用户空间的数据拷贝，造成了很多资源占用和性能损耗。而使用共享内存的方式来替代进程间 socket 通信的方式，减少不必要的内存拷贝，降低了系统的传输延时和资源占用，提升了传输效率。

一对多传输场景下原生的 ROS 通信和改进后的 ROS 通信如图 2-4 所示。左侧是原生的 ROS 通信，右侧是共享内存通信。对比两者可发现，一对多的消息传输场景下，实际上是多个 ROS 节点点对点的连接，当要发送一份数据给四个节点时，相同的数据会传输四次，造成了很大的资源浪费。共享内存的传输过程，支持一次写入，多次读取的功能，对于一对多的传输场景，多个使用者可以同时读取，相同的数据包只需要写入一次即可，成倍地提高了传输的效率。

2）网络拓扑去中心化：使用 RTPS 服务发现协议每个 ROS 网络中都有一个中心节点（ROS Master）,因此 ROS 并非完全的分布式框架。 节点在初始化时会向 Master 注册拓扑信息并获取其他节点的信息，如图 2-5 所示。

这种方式带来了比较强的容错性，当出现算法异常崩溃时，不会影响整体，为局部异常处理提供便利。但也有很明显的缺点：一方面，整个系统非常依赖 Master，一旦 Master 异常，节点与节点之间将无法相互发现，系统将无法正常工作；另一方面，一旦 Master 发生异常奔溃，将无法自动恢复。Apollo 系统采用的解决方案是 ROS 的框架中添加 RTPS 服务协议。

使用 RTPS 协议实现的 P2P 网络拓扑，如图 2-6 所示。通过这种方式，整个网络拓扑通过域（Domain）进行划分，而不是以 Master 为中心构建。通过 RTPS 协议来代替 Master的信息交换功能，当新节点加入域内网络时，可以向其他节点发送广播信息，其他节点也可以与新节点共享服务信息。使得 ROS 网络不再依赖 Master，大大提高了系统的鲁棒性。

同时该修改完全兼容 ROS 底层，无需对此功能有额外的代码适配工作。

3）数据兼容性扩展：使用 Protobuf 传递消息ROS 系统通过对 Message 定义做 MD5 校验来保证收发双方的消息格式一致。但是当接口升级后，不同的模块之间无法通信，增加了耦合，因此模块版本之间兼容性差。Apollo系统采用的解决方案是使用 Protobuf 语言来代替 Message 来作为消息定义的格式。

Protobuf 是一种类似于 XML 的数据描述语言，可以将结构化数据序列化，用于通信协议、数据存储等方面。同时 Protobuf 可扩展性强，不依赖于语言和平台，可以包含 Message中所有数据类型。

（3）应用程序模块层

Apollo 软件平台具有不同功能的模块，包括地图引擎（Map Engine）、感知（Perception）、自主规划（Planning）、控制（Control）、定位（Localization）以及人机接口（Human Machine Interface，HMI）。如图 2-7 为各个模块之间的关系图。由图可见，高精度地图和定位是Apollo 系统整个软件体系的基石，而使用高精度地图的数据就需要用到 Map Engine 模块。

1）Map Engine 模块

Map Engine 模块从高精度地图里面提取相关元素，使得其他功能模块可以获取高精度地图的相关数据。它的结构框图如图 2-8 所示。Map Engine 可以通过 ID 去检索元素，比如 KD-Tree 算法或 Hash 算法；也可以通过空间位置查找元素，比如知道一个点和半径时，可以获取该范围内所有交通灯的位置信息。

2）Localization 模块

Apollo 系统除了 RTK-based 定位，还有多传感器融合定位。如图 2-9 所示。

① RTK-based 定位：

传统的定位方式 GPS+IMU，基于 GPS 和 IMU 融合后的信息再进行 RTK 校准，可以得到厘米级精度的定位信息，定位信息包含加速度、速度、航向角、经纬度等等。如图 2-10 所示，左侧信息为 GPS 和 IMU 获取到的定位数据，当姿态初始化和位置初始化状态均为绿灯时表示成功获取数据，右侧为实时获取的 GPS 数据信息。

② 多传感器融合定位：

GPS、IMU 和 Lidar 三者配合使用。一方面通过基本的 GPS 和 IMU 定位，输出汽车位置和速度信息；另一方面比对激光雷达采集的点云数据和预先存在的高精度地图，得到激光雷达的定位结果，即汽车在高精度地图上的行驶方向和全球位置。然后通过卡尔曼滤波将两个定位结果进行融合定位。

3）Perception 模块

Perception 模块包括红绿灯检测和障碍物识别两部分。具体感知架构如图 2-11 所示。

红绿灯检测模块是将车辆位置与高精度地图进行匹配，从而输出红绿灯具体位置；同时采集视频图像，将两种相机焦距下的图像数据输入 CNN 神经网络检测识别，输出当前交通灯状态信息。障碍物识别模块分别输入毫米波雷达以及激光雷达的点云数据，经过神经网络处理，将两种传感器识别障碍物的融合结果输出，包括障碍物的类别、位置、形状、速度等信息。正常启动激光雷达，可在可视化软件 rviz 上看到三维激光点云图，如图 2-12 所示，彩色点为可视化界面上显示的激光雷达检测到的障碍物边界。

4）Planning 模块

Planning 模块的作用是根据当前的车辆信息（位置，速度，加速度，底盘）、路况和感知预测的结果规划出一条安全和舒适的轨迹，这个轨迹会交给 Control 模块，由 Control 模块控制车辆按照规划的轨迹运行。

Planning 模块的轨迹是车辆短期内行驶的轨迹。自动驾驶车会根据 Planning 模块生成的导航轨迹以及当前交通路况，沿着规划的轨迹行驶前往目的地。就好比开车根据导航行 驶，当前面遇到障碍物我们会减速或者变道等，这就是短期轨迹。

Apollo 系统规划车道有两种方式：RTK 重播规划器（RTK replay planner）和最大期望规划器（Expectation Maximization planner，EM planner）。两种方式的输入输出如图 2-13 所示。对于 RTK replay planner，通过人工驾驶方式录制测试道路上的行驶轨迹，然后根据当前系统时间和车辆位置输出对应的轨迹片段。在 EM planner 中，驾驶决策和驾驶轨迹将基于地图，路线和障碍物来计算。首先使用动态规划（Dynamic Programming，DP）算法确定原始路径和速度曲线，然后使用二次规划（Quadratic Programming，QP）算法进一步优化路径和速度曲线以获得平滑的轨迹。

5）Control 模块

Control 模块的作用是根据 Planning 模块生成的轨迹，计算出汽车的方向盘、刹车、油门信号，控制汽车按照轨迹行驶。根据汽车运动学和动力学知识，对汽车进行建模，实现对汽车的控制。Apollo 系统主要用到了 2 种控制方式：PID 控制和模型控制。Control 模块的执行流程如图 2-14 所示。

可以看到 Control 模块输入是车辆状态信息、位置信息以及 Planning 模块规划的轨迹；经过控制器处理，输出控制指令（ControlCommand），如油门，刹车，方向盘。Control 模块内置了三个控制器：纵向控制器（LonController）、横向控制器（LatController）、模型预测控制控制器（MPCController）。

① LonController 主要通过控制汽车的刹车和油门来控制汽车的速度。它主要由一个级联控制器和一个标定表构成。级联控制器包括速度和位置两种 PID 闭环控制器；标定表是指刹车/油门-加速度-速度命令标定表。具体工作原理框图如图 2-15 所示。

② 不同于 LonController，LatController 主要是控制方向。车的行驶路径会随着方向盘的角度而改变，因此汽车的横向控制主要是通过控制方向盘的转角来控制汽车行驶的角度。

横向控制器的核心是 LQR（Linear Quadratic Regulator）模型与车辆动力学模型。具体工作原理框图如图 2-16 所示。

③ MPCController 是一类特殊的控制。和传统使用预先计算控制律方法的主要区在于MPC 控制是求解一个开环最优控制问题，并获得开环优化序列。如图 2-17 所示为经典 MPC控制流程图。预测模型为根据历史信息、当前输入预测未来输出，滚动优化为反复在线优化以达到某一性能指标最优，反馈校正为基于测量对模型预测进行修正。

6）HMI 模块

Apollo 系统以 Web UI 的方式输出可视化信息，向用户提供了无人车本身状态的全局信息以及实时路况。如图 2-18 为 Web 应用程序 DreamView 可视化界面。

2.4 云端服务平台

云端服务平台提供了高精度地图服务（HD Map）、模拟仿真（Simulation）、数据平台（Data Platform）、安全（Security）、空中软件升级（OTA）、智能语音系统（DuerOS）等。

其中最为主要的是 HD Map。

和平常的导航地图不同，高精度地图专门应用于自动驾驶领域。它拥有丰富的道路元素数据和厘米级精度的位置信息，包含交通信号、交叉路口、车道规则等用于汽车导航的元素。高精度地图不仅可以降低计算成本，还能为汽车预知路面状况，如汽车航向、路面坡度等，更好地规避风险。

高精度地图和其他模块紧密相关。既可以为 Localization 模块的视觉定位/点云定位提供视觉数据和点云数据，用于辅助定位；也可以为 Perception 模块的感知算法提供辅助信息，避免传感器识别障碍物的能力受恶劣天气的限制；还可以为 Planning 模块提供先验知识，帮助车辆规划器确定合适的行车路线。

2.5 基于 Apollo 系统的循迹导航功能实现

基于 Apollo 系统的自动驾驶整体流程如图 2-19 所示。首先根据起点和终点规划出全局路径，在行驶过程中通过传感器识别当前环境得到感知信息如车辆行人路况标志等，并预测下一步发展；然后把感知信息传入 Planning 模块，规划出之后的轨道；Control 模块将轨道数据进行转换，得到对车辆的控制信号，并将信号传输至汽车交互模块（Canbus），实现对汽车的控制。

录制好车辆行驶轨迹，通过处理得到平滑的行驶轨迹，在可视化界面 Dreamview 中切换到自动驾驶模式，然后打开导航功能模块，可以看到循迹导航界面如图 2-20 所示，图中蓝色曲线为自动驾驶车辆实时生成的路径，车辆将依据这条路径行驶。当自动驾驶车进入自动驾驶模式后，Dreamview 界面中绿色立体区域代表了激光雷达检测到的障碍物。在前进的过程中，若自动驾驶车遇到行人等障碍物，则自动减速停车，待障碍物离开再行驶。

2.6 本章小结

本章主要介绍了 Apollo 自动驾驶系统的核心技术框架，包括车辆平台、硬件平台、软件平台、云端数据服务四大部分。同时本章以基于 Apollo 系统自主调试研发的自动驾驶车辆 Terra 为实验平台，测试了自动驾驶循迹导航模式。实验结果表明，Terra 自动驾驶车可以在 Apollo 系统下完成加减速、避障、循迹驾驶等功能。

3. 车路协同框架的设计与实现

3.1 车路协同框架及相关技术介绍

主流的 CVIS 系统核心主要有智能车载系统、通信平台及智能路侧系统三部分，即车端、通信端与路侧端+云端所形成的闭环组合。如图 3-1 所示。这也意味着，车路协同框架基本围绕这三个部分实现。其中，智能车载系统负责车载端的数据处理，包括多传感器数据融合以及海量数据实时处理，保证车辆的安全稳定行驶；智能路侧系统负责交通路况等信息的搜集与边缘侧计算，实现数字化感知交通路况和云端算力部署路侧端；通信平台负责提供车与路、车与车之间的实时信息传输管道，通过快速接入、高可靠、低延时的网络环境，保障实时共享车端与路侧端的信息。

因此，车路协同框架实现大致根据三个核心组成部分可概括分类如下：

（1） 基于车载系统的框架

车辆需搭载能够实时处理海量高并发数据并决策的处理系统，保证真实交通场景下的任务调度效率。如今大部分自动驾驶车均能满足这种需求。当前主流的自动驾驶处理系统有百度的 Apollo 系统、谷歌的 Waymo 系统、特斯拉的自动驾驶系统等。

（2） 基于路侧系统的框架

道路的智能化改造使得路侧系统需要运算处理大量的交通路况数据。当前可分为三类计算框架：路侧设备计算、云计算、边缘云+云计算。三种框架都有利弊，其技术特点如表3-1 所示:

（3） 基于通信平台的框架

车路协同技术中，车与车、车与路之间的无线通讯技术是实现车路协同的核心技术及基础，目前无线通讯发展比较成熟的技术有 Wi-Fi、ZigBee、DSRC、LTE-V 这 4 种。表 3- 2 为上述四种无线通讯技术对比。

Wi-Fi 技术作为以无线方式传输以太网的一种形式，理论上在可通讯范围内各连接用户都可以以 54Mbps 的速度进行数据收发，但实际应用中，随着接入用户的增加，其连接及共享速度下降极为明显。ZigBee 技术一种低功耗、低成本、低复杂度的短程无线通讯技术，其基本通讯速率为 250kbps，但此通讯速率下传输范围极低。DSRC 技术和 LTE-V 技术同属于 V2X 技术，工作频段基本一致，5.9GHz 为两者的专属频段，没有任何其他通讯方式的干扰。而且两种技术在兼顾低延迟及数据传输速率的同时，还可以根据车路协同场景中的功能要求，加密传输数据，确保数据的安全性。和 DSRC 相比，LTE-V 技术有效通信距离更大，可提供的刹车反应时间更长；而且 LTE-V 技术支持并发用户数更多，用户间干扰更小。这两项通信技术各有千秋，DSRC 是已经形成统一标准的、可靠稳定的技术; 而在感知距离、短时延、覆盖范围、承接数量上，LTE-V 更胜一筹。

3.2 基于 5G-V2X 的车路协同方案实现

当前市面上大多车路协同框架计算核心在路侧设备上，一方面对路侧设备有很高的运算存储要求，另一方面也增加了开发成本，不利于大范围的系统部署。根据现有车路协同框架的一个优劣特性，本文提出一个基于 Docker 的车路协同框架，主要核心为 5G 低时延、高可靠、容量大的特性以及 C-V2X 的高效通信能力。将路侧设备的运算要求卸载到边缘云端，在保证系统性能和效率的同时，降低了开发成本。其总体系统架构如图 3-2 所示。

由图 3-2 可见，本文提出的车路协同框架主要有四大模块：路侧设备模块、车载设备模块、边缘云服务器模块以及远程服务器模块，总体硬件框架如图 3-3 所示。

路侧设备包括摄像头、激光雷达等路侧传感器，实时观测道路上车辆、行人等交通参与者的状态信息以及监测各种交通违章事件。主要实时推送该路段的交通信号灯、交通标牌、道路危险状况等交通状况信息。

车载设备主要实现车辆 GPS 位置数据、车辆姿态数据获取，以及通过车载传感器识别周围交通环境，包括周围车辆、障碍物、行人，然后通过 5G 移动蜂窝通信将数据上传给边缘云服务器。

边缘云服务器是整个系统框架的核心部分。一方面实现对路侧设备及车载设备获取数据的处理、识别与存储，另一方面实现交通状况、调度预警等信息的实时推送，提高驾驶安全和交通效率。其中，边缘云接收两方面的数据，一是路侧设备上传路口的车流、道路、行人状态以及交通异常状况，二是车载设备上传车辆周边环境感知信息及其运动状态。由边缘云融合处理两方面的数据，获得交通道路上各个车辆周边信息及风险预警信息。根据融合处理的信息，实现对特定车辆的各种预警、报警和交通诱导信息的发布。当车辆处于自动驾驶模式下，边缘云服务器通过 5G 移动蜂窝通信推送车辆周边信息至特定车辆，包括障碍物信息、周边车辆状态信息等交通信息，以供自动驾驶车辆决策规划行驶路径；当车辆处于辅助驾驶模式下，边缘云服务器将推送车辆预警信息至驾驶员，包括前方障碍物提醒等预警信息，以留有充足的时间供驾驶员判断当前交通状况并控制车辆安全行驶。

远程服务器主要实现对边缘云服务器的数据存储。

3.3 本章小结

本章主要介绍了目前车路协同系统常见的几种实现框架，包括基于车载系统、路侧系统、通信平台三种划分框架，通过横向比较技术、传输延迟、计算成本等方面的优缺点。接着介绍了本文提出的基于 5G-V2X 的车路协同框架。该框架主要包括了路侧设备、车载设备、边缘云服务器以及远程服务器四大模块，将原运行于 V2X 路侧设备的计算任务卸载到计算能力及存储能力更强的边缘云服务器上，减少路侧设备开发实施的成本、车载终端资源的开销和方案推广的成本，保证车路协同通信的实时性和准确性。

4. 测试与验证

本章将对本文提出的车路协同系统做场景验证测试，目的在于验证本文设计实现的车路协同框架在典型应用场景下的可行性及消息分发传递的有效性。

4.1 车路协同典型应用场景

4.1.1 前向碰撞预警

主车在车道上行驶，同一车道正前方有远车在行驶，当两车存在追尾碰撞危险时，前向碰撞预警（FCW）应用将预警提醒主车驾驶员。本应用适用于高速公路或普通道路等发生车辆追尾碰撞场景的预警。FCW 应用为驾驶员避免前向碰撞起到提醒辅助作用，提高道路行驶安全。包括以下主要场景：

（1）主车正常行驶，远车停止在主车同一车道的正前方。如图 4-1 所示。主车在行驶过程中，与远车即将发生碰撞时，FCW 应用开始提醒主车驾驶员，预警可能会与位于正前方的远车车辆发生碰撞。

（2）主车正常行驶，远车停止在主车相邻车道前方。如图 4-2 所示。由于主车在行驶过程中不会与远车发生碰撞，因此 FCW 不会提醒主车驾驶员预警信。

（3）主车正常行驶，远车慢速或减速行驶在主车所在车道正前方。如图 4-3 所示。主车在行驶过程中即将与远车发生碰撞时，FCW 应用发出预警，提醒驾驶员可能会与位于正前方的车辆远车发生碰撞。

4.1.2 逆向超车预警

逆向超车预警（DNPW）是指主车在道路上受到前车阻碍，要借用相邻车道实现超车，主车与相邻车道上逆向行驶的远车存在碰撞危险时，DNPW 应用对主车驾驶员进行预警。

本应用适用于道路超车变道所产生碰撞危险的预警。在超车过程中 DNPW 应用将提醒驾驶员避免发生碰撞，保证逆向超车驾驶安全。

主要场景如图 4-4 所示。主车跟随远车 1 行驶并准备超车，远车 2 从相邻逆向车道上逆向行驶而来，主车的视线可能被远车 1 遮挡。当主车打开变道转向灯并准备进入逆向行车道时，DNPW 应用对这车驾驶员发出预警，提醒驾驶员与逆向来车远车 2 存在碰撞危险。

4.2 测试平台搭建

本课题测试平台包括路侧设备、车载设备、边缘云服务器、远程服务器以及 5G 基站。

路侧设备选择海康威视公司的雷视融合感知一体机，包括毫米波雷达和高清摄像机。路侧设备硬件实物如图 4-5 所示。车载设备为自主设计的自动驾驶车，线控底盘采用广汽 GE3新能源汽车，配备操作系统为 Ubuntu18.04 LTS、自动驾驶框架为 Apollo 系统的工业级 GPU嵌入式工控机 Nuvo-6108GC，装载 GNSS 组合惯导以及 Velodyne-16 线激光雷达。车载设备实物如图 4-6 所示。边缘云服务器采用 H310M S2 主板作为硬件基础，CPU 型号为 i7-8700（主频 3.20GHz），内存 16G， Linux 作为底层操作系统，开发环境采用 Ubuntu18.04 LTS 64 位版本。远程服务器使用了一台配有 4G 内存，

CPU 型号 i7-9700（主频 3.00GHz） 的台式主机，并搭配 Ubuntu18.04 LTS 操作系统。表 4-1 为测试平台具体软硬件信息。

4.3 车路协同系统功能测试与验证

实验以深圳市人工智能研究院自动驾驶项目的实施场地作为测试场地，其真实环境图如图 4-7 所示。实验将分为三部分进行。实验一为测试自动驾驶前向碰撞预警场景，实验二为测试辅助驾驶逆向超车预警场景，实验三为车路协同系统实时性测试。

4.3.1 自动驾驶前向碰撞预警测试

具体步骤如下：

（1）安全员坐在自动驾驶车中，开启自动驾驶功能。此处的自动驾驶驱动程序功能包括正确上报车辆实时位置信息、车载传感器感知周边信息并接收边缘云服务器实时的预警推送，提供边缘云服务器数据供自动驾驶系统参考处理。

（2）启动边缘云服务器，实时处理路侧设备及车载设备上报的信息。

（3）自动驾驶车所在车道前方出现一辆静止的汽车，观察自动驾驶车运动情况及车载屏幕显示的预警信息。

如图 4-8 所示为自动驾驶前向碰撞预警外场测试图以及车载屏幕显示的预警信息。

由上图我们可知，在自动驾驶前向碰撞预警场景中，车路协同框架可以正确预测自动驾驶车前方由障碍物，并将前向碰撞预警信息实时推送至车载屏幕上，车路协同框架的核心功能得以验证。

4.3.2 辅助驾驶逆向超车预警测试

具体步骤如下：

（1）驾驶员手动驾驶自动驾驶车，不开启自动驾驶功能。此处的辅助驾驶驱动程序功能包括正确上报车辆实时位置信息并接收边缘云服务器实时的预警推送，辅助驾驶员行驶。

（2）启动边缘云服务器，实时处理路侧设备及车载设备上报的信息。

（3）一辆行驶缓慢的汽车出现在自动驾驶车所在车道前方，驾驶员打开变左转向灯将要变道超车。

（4）与此同时，一辆汽车在左侧逆向车道上逆向行驶而来。

（5）观察自动驾驶车语音播报的告警信息以及车载屏幕显示的预警信息。

如图 4-9 所示为辅助驾驶逆向超车预警外场测试图以及车载屏幕显示的预警信息。

由上图我们可知，在辅助驾驶逆向超车预警场景中，车路协同框架可以正确预测辅助驾驶车逆向超车车道有障碍物，并将逆向超车碰撞预警信息实时推送至车载屏幕上，车路协同框架的核心功能得以验证。

4.3.3 车路协同系统实时性测试

具体步骤如下：

分别记录车路协同系统 V2X 通信和数据采集/处理的时延，同时比较车路协同系统分别在 4G 和 5G 两个通信环境中的通信时延。

下表 4-2 为 V2X 通信以及系统对数据采集和处理的时延数据。由表 4-2 可以发现，该系统包括 V2X 通信和数据采集处理的时延为 70-90ms，满足《合作式智能运输系统车用通信系统应用层及应用数据交互标准》中系统时延小于 100ms 的要求[26]，符合各场景的系统时延要求。

车路协同系统分别在 4G 和 5G 两个通信环境中的网络时延比较如下图 4-10 所示。由图可知，5G 平均网络时延在 10ms 附近，而 4G 网络时延在 50ms 左右，可见 5G 时延仅为4G 的五分之一。从数据分析我们可以知道，在 5G 的支持下，超低时延在车路协同系统通信中的优势非常明显，一旦前方发生危险，系统可以快速响应，避免交通事故的发生。除此之外，5G 的超大带宽使得通信网络可以传输更多的车路数据，为车路协同数据处理带来更大的便捷。

4.3 本章小结

本章通过三个实验进行测试验证。实验一和实验二为验证车路协同框架在真实场景中的可行性，通过前向碰撞预警场景和逆向超车预警场景，实验结果显示本文提出的车路协同框架可正常完成两个场景的测试。实验三分别记录了车路协同系统 V2X 通信和数据采集/处理的时延，数据表明该系统满足系统时延小于 100ms 的要求，保证了车路协同系统中的高效性。同时实验三记录了车路协同系统分别在 4G 和 5G 两个通信环境中的通信时延，显示了相较于 4G，5G 在低时延方面更加适合车路协同系统。三个测试实验验证了本文提出的车路协同框架的可行性及高效性。

5. 总结与展望

5.1 全文工作总结

本文总结研究了当前国内外车路协同系统和 V2X 技术的应用现状，针对当前车路协同框架运算任务主要集中于路侧设备所造成的运算负担及使用成本过大的问题，提出基于5G-V2X 的车路协同架构的实现，并以自主研究开发的自动驾驶车作为实验车辆，测试了车路协同下的前向碰撞预警场景和逆向超车预警场景，以及验证了车路协同的实时性和将路侧设备计算任务移植到边缘云端的方案的可行性。本文所述的主要工作如下：

（1）Apollo 系统框架下自动驾驶车 Terra 的设计于开发：Terra 为自主设计研发的一款自动驾驶车，采用广汽 GE3 线控底盘，搭载 Apollo 自动驾驶系统框架，装载 GNSS 组合惯导以及激光雷达。实验证明 Terra 自动驾驶车可以在 Apollo 系统下完成加减速、避障、循迹驾驶等任务。

（2）提出基于 5G-V2X 的车路协同架构的实现，主要核心为 5G 低时延、高可靠、容量大的特性以及 C-V2X 的高效通信能力。将路侧设备的运算要求移植到边缘云端，在保证车路系统实时性和高效性的同时，降低了部署开发成本。从商业角度来看，部署车路协同系统不需要再购买昂贵的路侧产品，减少了开支。

（3）验证了本文提出的车路协同系统框架的可行性以及分析了该系统满足系统时延小于 100ms 的要求。本文通过实验验证了在车路协同系统框架下，Terra 自动驾驶车与边缘云端、路侧端形成了互联，实时共享周边信息，同时也可实时获取边缘云端发送的预警信息。

5.2 未来研究展望与方向

由于车路协同及 V2X 本身是一个比较庞大复杂的系统，若想完整实现需要较大的工作量。因此，基于本文的研究结果，目前仍然存在的问题及今后研究工作主要方向包括：

（1）测试场景复杂化。当前测试场景仅仅考虑了碰撞预警单一场景，实际交通道路上会发生各种各样的交通状况。选择的交通场景仅仅考虑了简单的预警状况，没有考虑多车同时预警或更为复杂的交通状况。下一步需要测试更为复杂的场景。

（2）车路协同方案优化。当前本文所提车路协同框架适用范围仍然有限，跨地域的车路数据处理问题有待考虑。解决方法是进一步优化车路协同方案，将边缘云部署于各个地域，负责各地域的计算任务，地域之间通信统一由核心服务器分配，负责地域交接之间的数据融合于处理，进一步提高地域普适性。

（3）开发系统优化。目前所有开发测试均基于 Linux 系统，需要进一步优化，适配其他操作系统以方便移植。