云管边端架构图_【学术论文】车路协同的云管边端架构及服务研究

导读：车联网作为5G的重点业务之一，正在逐步构建以人、车、路协同的辅助驾驶、自动驾驶为核心的智能交通系统，新场景、新需求的引入对数据通信与计算提出了更高的要求，也推进车联网从支持车载信息服务(Telematics)向支持车联一切(V2X)服务的下一代车联网发展。为了促进5G通信的技术交流，推动我国5G通信技术的发展，《电子技术应用》杂志2019年第8期和第9期推出“5G与车联网”主题专栏，论文内容涵盖5G车联网关键技术与发展现状、5G车联网标准进展、5G车路协同解决方案和5G车联网应用方案与实践案例等，期待为5G时代的车联网技术和应用部署提供有益的借鉴。

特约主编：朱雪田，北京邮电大学工学博士，教授级高级工程师，中关村国家自主创新示范区高端领军人才，北京邮电大学通信与信息专业工程硕士导师，现就职于中国电信智能网络与终端研究院。长期从事4G/5G移动通信和互联网技术创新与研发工作，作为项目组长先后负责多个4G/5G领域的移动通信国家重大项目，发表学术论文超过50篇，发明专利100余篇，个人专著3本。摘要：对智能交通业务的发展趋势、车路协同技术及系统要求以及国内外发展现状进行了介绍； 同时重点阐述了智能网联交通体系之车路协同云管边端架构方案，介绍了中心云、交通专网/电信网络、边缘云、车载/路侧终端协同的“云-管-边-端”统一架构，同时提出了基于云管边端架构的车路协同多源数据融合信息服务能力开放框架，并对其具体功能要求、API调用方式进行了详细论述。中文引用格式：熊小敏，杨鑫，刘兆璘，等. 车路协同的云管边端架构及服务研究[J].电子技术应用，2019，45(8)： 14-18，31.英文引用格式：Xiong Xiaomin，Yang Xin，Liu Zhaolin，et al. Research on cloud-network-edge-terminal architecture and service of vehicle-road collaboration[J]. Application of Electronic Technique，2019，45(8)： 14-18，31.

0 引言

车路协同是智慧交通的重要发展方向之一，传统智能交通的车路协同系统是建立在中心云服务基础上的，在前端实现实时采集数据的情况下，数据上传至云端，在云端上实现计算，并将结果发布至路口信号机和移动终端上，实现云端的信号灯系统控制和路口协调控制。随着车路协同系统的推进，需要处理海量实时数据，车辆行驶安全服务需要在毫秒级延时的情况下通知驾驶人或控制车辆采取措施，原来的中心计算方式无法保证车路协同的时效性。边缘计算可以将云端的计算下沉到边缘层，在边缘计算节点完成绝大部分的计算，满足车路协同的超低时延需求。本文重点讨论车路协同的云管边端架构以及多源数据融合处理服务等。

1 智能交通业务发展趋势

智能交通是未来交通系统的发展方向，它是将先进的信息技术、数据通信传输技术、电子传感技术、控制技术及计算机技术等有效地集成运用于整个地面交通管理系统而建立的一种在大范围内全方位发挥作用的实时、准确、高效的综合交通运输管理系统 [1]。 目前，我国智能交通主要分为三个领域：城市智能交通、高速公路智能交通和其他领域智能交通。在高速公路方面，高速公路自动收费系统、公路抓拍监控系统、公路治超以及隧道监控是目前的主流业务。依托于高速公路交通大数据综合管理平台，将高速公路信息(道路状况、车辆状况、天气状况等)进行收集、处理、分析，从而协调统筹高速公路上的车辆、道路运行状况，监管高速公路上的违法事件、突发事件 [2]，是高速公路智能化的发展方向。城市交通因其道路的复杂性、车辆种类的多样性、人群的密集性，也是智能交通发展不容忽视的重要一环。智能交通已成为我国智慧城市建设的重要领域。在城市智能交通管理方面，我国已研制出交通信号配时系统、视频监控、交通诱导、路面检测、停车管理、公交管理以及汽车电子标识等智能化业务系统，并已得到广泛应用 [3]，未来将在车路协同、城市交通大脑等方面进一步发展。 智能交通业务的发展正在从信号灯控制、电子警察、道路监控等传统建设内容，过渡到基于交通基础设施建设之上的采集、感知、传输、归集、分析、控管、预警、评估、运维、管理等更为丰富的智能业务应用 [4]，其中车路协同是近年来智能交通界关注的重要方向，将车辆与道路设施协同化管理，全面构筑“人-车-路”全域数据感知的智能路网，推动智能交通建设迈向新的阶段。

2 车路协同技术及系统

2.1 车路协同技术及系统要求

车路协同系统采用了先进的无线通信和新一代互联网等技术，全方位实施车车、车路、人车和车与边云协同动态实时信息交互，在全时空动态交通信息采集与融合的基础上，开展车辆协同安全和道路协同控制，充分实现人车路的有效协同，保证交通安全，提高通行效率，从而形成安全、高效和环保的道路交通系统 [5]。 车路协同系统的核心技术与功能包括：任何时间任何地点车辆互联；全时空动态交通信息采集与融合；人车路的有效协同，包括协同安全(分为主动安全和被动安全)、协同控制(分为主动控制和被动控制)。车路协同所需的V2X(Vehicle to Everything)通信技术是系统的重要技术之一，从通信场景上V2X可以细分为车-车通信的V2V、车-基础设施通信的V2I、车-行人通信的V2P、车-网络通信的V2N等，从通信技术实现选择上V2X分为基于IEEE802.11标准的专用短程通信DSRC(Dedicated Short RangeCommunication)技术和基于蜂窝移动通信系统的C-V2X(Cellular Vehicle to Everything)技术(包括4G网络下的LTE-V2X和5G网络下的5G NR-V2X)。 从图1可以看出，系统通过各类无线通信技术，把车与车之间、车与路之间、近端与远端车之间(通过边云)、甚至人进行连接。其中车载设备、人手持设备、路侧设备构成新的交通结构，新结构功能要求具备如下特点：设备性能要求多模兼容、环境感知具备协同感知、信息交互须为可信交互、控制机制能够动态分层、计算由边缘云端协同来实现、系统功能具备升级延展性等。

通过车路协同系统可以知道任何时间、任何断面交通情况，任何车辆信息都可以获取。车辆与道路全面感知后的大量交通信息对处理的实时性、可靠性提出高要求，系统结构也随之发生变化，在这个情况下采用云管边端的车路协同架构也就成为必然。 车路协同系统涉及道路基础设施、通信网络以及汽车三个方面的升级改造。车路协同平台通过与车载计算节点以及道路侧边缘计算节点之间的交互，对车辆密度、速度等的感知，来引导道路上的车辆规避拥堵路段，实现交通的高效调度。在交叉路口，道路边缘计算节点收集附近道路的信息，通过大数据算法，下发合理的道路交通调度指令，通过控制信号灯的状态、为驾驶员提供拥堵预警等手段，实现道路的最大利用率，减少不必要的停留，从而减少道路拥塞，降低燃油损耗。

2.2 车路协同国内外发展现状

车路协同技术由于其对通信技术要求高，且实践周期较长，在国内外的起步时间跨度较大。但各行业新兴技术的涌现对车路协同技术发展起到了持续的创新推动作用，产生了各国各具特色的车路协同技术应用。 美国、欧盟均于2003 年起开始车路协同系统计划及建设，旨在提升交通安全性、环保度和实现调度优化。其中，美国的IntelliDrive项目偏向于向驾驶者提供安全辅助控制或全自动控制支持，通过开发和集成各种车载和路侧设备以及通信技术，使得驾驶者在驾驶中能够做出更好和更安全的决策。其发展重点包括车路协同的安全辅助应用、实时交通管理系统和“下一代”的电子支付系统。欧盟启动的eSafety计划考虑了车-路协调合作方式，即通过车-车以及车-路通信技术获取道路环境信息，从而更有效地评估潜在危险并优化车载安全系统功能。欧洲的研究重点是将道路、车辆、卫星和计算机利用通信系统进行集成，将各国独立的系统逐步转变为车与车、车与路、车与X的合作系统，实现人和物的移动信息互操作。日本也于2007 年开始建设Smart Way，其研究重点主要有两方面：一是依托各种先进的通信系统和车载系统，集成现有的应用系统，为出行者提供更加安全和便利的服务；二是通过车路协调改善道路安全 [6]。 我国的车路协同技术起步较晚，但发展迅速，目前主要以智能互联示范区的模式推进。上海、北京、重庆、武汉、无锡等城市开展了基于移动网络的智能汽车与智慧交通应用示范，在推动我国车流干预、行人预警、智能城市系统等车路协同技术发展和应用方面积累了一定经验[7]。同时，BAT等国内科技企业也纷纷推出其在车路协同领域的技术解决方案。在DSRC和C-V2X技术选择上，由于C-V2X相比DSRC本身的技术优势以及中国在C-V2X产业链上核心技术掌控的优势，中国正积极推动C-V2X车路协同的发展。 阿里云推出智能高速公路解决方案，致力于车路协同生态构建。由车向路延展，利用车路协同技术打造全新的“智能高速公路”。百度Apollo发布车路协同开源方案，在软硬件层以及云服务层对车路协同相关模块进行开发。华为推出基于移动蜂窝网络的C-V2X智慧车路协同解决方案，全方位使能高速公路的智能化、网联化建设，其研发的首款支持Uu+PC5并发的RSU路侧产品将进一步加快车路协同业务的发展。腾讯的5G车路协同开源平台则聚焦基于边缘计算的车路协同领域，通过人、车、路、云互联助力5G时代智能网联汽车应用快速落地。

3 车路协同的云管边端架构

车路协同的云管边端架构如图2所示，其中云平台包括V2X应用服务、V2X管理服务、平台服务和基础服务。管包括交通专网和电信网络，其中交通专网是指交通运营自建或合作建设的专有网络，并且与电信网络进行互联，从而利用电信运营商的移动网络、宽带网络和物联网等服务，特别是C-V2X一般基于电信运营商的移动网络和基站进行通信。边则包括众多边缘计算节点，一般在道路侧或者运营商的边缘机房，采用适应边缘物理部署环境的定制服务器硬件部署。端则包括各种车、路上的多种视频、事件监测、信息、计算终端及传感器等。

在上述架构中，边缘计算节点将发挥关键作用，目前电信业讨论较多的是引入MEC [7]提供车路协同的边缘计算服务。MEC是一种云网融合的边缘计算平台，即作为移动核心网下沉的用户面网元，同时又是边缘的云平台，提供边缘计算应用环境，支持边缘应用服务。具体来说，基于MEC的边缘云主要解决的问题和提供的服务包括： (1)智能交通道路不断增加部署的高清摄像头形成视频为主的交通道路感知，信息全部上传到云端存储和分析处理，网络传输与云端处理均难以承受成本，MEC边缘云提供本地计算存储，降低中心云平台性能处理与带宽要求； (2)车路协同方案从感知分析到反馈控制趋向实时化，真正动态感知和优化交通道路出行，对网络和计算要求超级低时延，MEC一般部署在接入局所或者城域网边缘机房，主要时延是无线接入网空口时延以及MEC边缘处理时延，基于5G空口可以满足10 ms级的实时感知分析处理反馈要求。 (3)传统的道路交通车路协同计算设备以工控机为主，系统较封闭，软硬件及应用开发部署由各厂家把控，MEC采用电信NFV云平台架构，并一般针对边缘计算提供虚拟机与容器应用执行环境以及轻量级管理、MEC服务化架构与开放能力服务，有利于边缘应用的生态创新与开放。

4 基于云管边端架构的车路协同多源融合信息服务

车路协同的典型场景主要分为安全、效率、协作、信息类等服务。对应于各类场景，除了本地信息分发等MEC基础能力外，按照信息来源数量划分，如“单一信息来源接口”的动态高精度地图、车辆在线诊断等场景，需要协同地图厂商、整车厂商定义统一API规范接入；对于“多信息源融合接口”，如智慧交叉路口功能等以视频为核心的多源数据融合场景，需要通过信号处理、视频识别、激光雷达信号识别、信息综合等应用功能来对交叉路口周边内的车辆、行人等位置、速度、方向角度等进行分析和预测。应针对不同场景下的信息输入输出格式，对应的信息交互内容、交互协议能力以及开放API提供标准输出。 图3为车路协同多源融合信息服务能力开放框架，定义了北向接口为外部应用提供服务能力接口，用于交换命令、控制信号等，以支持相关应用场景；南向接口为适配各大厂商的设备以及能力级应用的接入。实际各应用开发单位可以参考此架构图针对不同应用场景详细分析其应用场景需求、基本交互及数据流程、数据集需求、通信方式需求、API接口等，进而进行相应开发。其中针对数据集的标准化一般分为3个层级，第一层级是传感器原始基础数据的标准化，第二层级是融合感知计算结果标准化，第三层就是与车辆的数据接口。不同应用的通信方式、API调用方式与协议会有差异，本文将针对广播/订阅类消息API和事件触发响应类API调用流程进行详细描述。不同应用可根据业务特点选择适合的通信机制。

4.1 基于MQTT协议的广播/订阅类消息API调用方式

MQTT是一种发布/订阅传输协议，基本原理和实现 [8]如下，如图4所示。

MQTT协议需要客户端和服务端，而协议中主要有3种身份：发布者(Publisher)、代理(Broker，服务器)、订阅者(Subscriber)。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，而消息发布者可以同时是订阅者，实现了生产者与消费者的脱耦。 MQTT服务器部署在MEC server上，路侧的本地计算设备作为客户端将感知结果(结构化数据)发布到服务器，部署在MEC上的应用或其他设备作为客户端，可以向服务器订阅感知结果消息。或者，MEC上用于数据感知融合分析的边缘应用A作为客户端，将融合分析结果发布到服务器，其他应用作为客户端，可以向服务器订阅结果。 MQTT协议支持3种消息发布服务质量： (1)至多一次：消息发布完全依赖底层TCP/IP网络。这一级别会发生消息丢失或重复，可用于如下情况：丢失一次读记录无所谓，因为不久后还会有第二次发送。 (2)至少一次：确保消息到达，但消息重复可能会发生。 (3)只有一次：确保消息到达一次。在一些要求比较严格的计费系统中可以使用此级别。在计费系统中，消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通信类的APP的推送，确保用户收到且只会收到一次 [9]。 以十字路口感知预警结果为例，每100 ms会发送一次，为了保证实时性，本应用采用至多一次方式，没收到的数据将被丢弃，保证始终接收最新的消息内容。

4.2 MQTT协议调用流程

消息订阅/发布具体流程如下，如图5所示。

(1)路侧感知结果发布者(Publisher)通过访问MECserver的IP地址和特定MQTT服务端口号与MEC server上的MQTT server建立连接，将感知结果以topic主题名为“/crossroad_perception“的消息发布到Server端，发布频率为10 Hz。 (2)云端应用订阅者(Subscriber)通过访问MECserver的IP地址和端口号与MECserver建立连接，订阅名称为/crossroad_perception的topic。 (3)MECServer作为代理，将数据中转给Subscriber。如果Publisher发布的topic没有订阅者，消息内容将被丢弃。

4.3 基于XMPP协议的请求/应答类消息API调用方式

可扩展消息与存在协议(Extensible Messageing and Presence Protocol，XMPP)是目前主流的即时消息(Instant Messaging，IM)协议之一。XMPP包括核心的XML流传输协议和基于XML流传输的即时通信扩展应用，XMPP的核心XML流传输协议的定义使得XMPP能够在一个比以往网络通信协议更规范的平台上。其基本原理和实现 [10]如下，如图6所示。

XMPP中定义了三个角色，即客户端(Client)、服务器(Server)、网关(Gateway)。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。 XMPP服务器部署在MEC server上，路侧的本地计算设备作为客户端将感知结果(结构化数据)通过服务器发送到部署在MEC上的应用或其他设备的客户端。或者，MEC上用于数据感知融合分析的边缘应用作为客户端，将融合分析结果通过服务器发送到其他应用的客户端上。

4.4 XMPP协议调用流程

路侧感知设备将数据源发送到MEC server的消息请求/响应具体流程如下，如图7所示。

(1)路侧感知客户端(client1)通过访问MEC server的IP地址和特定XMPP服务端口号与MEC server上的XMPP server建立连接，服务器利用本地目录系统中的证书对其认证。 (2)client1指定MEC server客户端(client2)地址，让服务器告知目标状态。 (3)服务器对Client2进行查找、连接并进行相互认证。 (4)Client1和Client2之间进行数据交互，数据交互内容为“/slag car data resource”。 以上是分别针对广播/订阅类消息API和事件触发响应类API调用流程进行的详细说明。 在这样一个多源融合信息服务框架之下，各大服务功能域能够更高效地协同运作，使得由 V2X技术收集来的数据能够被更好地利用、传递、处理，资源可以更好的调配，最终实现服务的最优化，一路畅通的梦想不再遥远。

5 结论

V2X车路协同将“人、车、路、云”等交通参与要素有机地联系在一起，不仅可以支撑车辆获得比单车感知更多的信息，促进自动驾驶技术创新和应用；还有利于构建一个智慧的交通体系，促进汽车和交通服务的新模式新业态发展，对提高交通效率、节省资源、减少污染、降低事故发生率、改善交通管理具有重要意义。 本文给出了车路协同的云管边端架构以及多源异构数据融合与能力开放服务架构方案，为车路协同系统建设、运营提供参考。

参考文献

[1] 魏玉.针对城市智能交通系统的研究[J].轻工科技，2019，35(4)：88-89.

[2] 段宗涛，康军，唐蕾，等.车联网大数据环境下的交通信息服务协同体系[J].长安大学学报(自然科学版)，2014，34(2)：108-114.

[3] 王世宝.基于5G技术车联网的发展趋势及应用前景分析[J].时代汽车，2018(6)：169-170.

[4] 杨小丽.车联网大数据下的交通信息服务研究[J].无线互联科技，2017(16)：35-36.

[5] 张毅.如何理解车路协同与智能协同[EB/OL].(2019-01-14)[2019-06-24].http：//www.cheyun.com/content/25742.

[6] 陈超，吕植勇，付姗姗，等.国内外车路协同系统发展现状综述[J].交通信息与安全，2011，29(1)：102-105，109.

[7] 欧洲电信标准化协会ETSI.Multi-access edge computing(MEC)[EB/OL].[2019-06-24].http：//www.etsi.org/technologies-clusters/technologies/multi-access-edge-computing.

[8] OASIS.MQTT version 5.0[EB/OL].(2019-03-07)[2019-06-24].http：//docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html.

[9] OASIS.MQTT version 3.1.1[EB/OL].(2014-10-29)[2019-06-24].http：//docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718029.

[10] XMPP.Spectifications[EB/OL].[2019-06-24].https：//xmpp.org/extensions/.

作者信息:

熊小敏1，杨 鑫1，刘兆璘2，朱雪田1

1.中国电信股份有限公司研究院，北京102209；

2.北京邮电大学，北京100035；