《電子技術應用》
您所在的位置:首頁 > 通信與網絡 > 設計應用 > 車路協同的云管邊端架構及服務研究
車路協同的云管邊端架構及服務研究
2019年電子技術應用第8期
熊小敏1,楊 鑫1,劉兆璘2,朱雪田1
1.中國電信股份有限公司研究院,北京102209;2.北京郵電大學,北京100035
摘要: 對智能交通業務的發展趨勢、車路協同技術及系統要求以及國內外發展現狀進行了介紹;同時重點闡述了智能網聯交通體系之車路協同云管邊端架構方案,介紹了中心云、交通專網/電信網絡、邊緣云、車載/路側終端協同的“云-管-邊-端”統一架構,同時提出了基于云管邊端架構的車路協同多源數據融合信息服務能力開放框架,并對其具體功能要求、API調用方式進行了詳細論述。
中圖分類號: TN919.5;TP39;U495
文獻標識碼: A
DOI:10.16157/j.issn.0258-7998.190709
中文引用格式: 熊小敏,楊鑫,劉兆璘,等. 車路協同的云管邊端架構及服務研究[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.
Research on cloud-network-edge-terminal architecture and service of vehicle-road collaboration
Xiong Xiaomin1,Yang Xin1,Liu Zhaolin2,Zhu Xuetian1
1.Beijing Research Institute of China Telecom Corporation Limited,Beijing 102209,China; 2.Beijing University of Posts and Telecommunications,Beijing 100035,China
Abstract: In this paper, the development trend of intelligent transport system(ITS) and the state art of vehicle-road collaboration are introduced. This paper focuses on the cloud-network-edge-terminal architecture of vehicle-road collaboration, includes central cloud, transport private network/telecommunication network, edge cloud, vehicle/road-side terminal and their collaborations.The open framework of information service capability of multi-source data fusion based on cloud-network-edge-terminal architecture for vehicle-road collaboration is presented. The specific functional requirements, API invocation methods and protocols are discussed in detail.
Key words : vehicle-road collaboration;V2X;edge computing;MEC;multi-source data fusion

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可以看出,系統通過各類無線通信技術,把車與車之間、車與路之間、近端與遠端車之間(通過邊云)、甚至人進行連接。其中車載設備、人手持設備、路側設備構成新的交通結構,新結構功能要求具備如下特點:設備性能要求多模兼容、環境感知具備協同感知、信息交互須為可信交互、控制機制能夠動態分層、計算由邊緣云端協同來實現、系統功能具備升級延展性等。

5g4-t1.gif

    通過車路協同系統可以知道任何時間、任何斷面交通情況,任何車輛信息都可以獲取。車輛與道路全面感知后的大量交通信息對處理的實時性、可靠性提出高要求,系統結構也隨之發生變化,在這個情況下采用云管邊端的車路協同架構也就成為必然。

    車路協同系統涉及道路基礎設施、通信網絡以及汽車三個方面的升級改造。車路協同平臺通過與車載計算節點以及道路側邊緣計算節點之間的交互,對車輛密度、速度等的感知,來引導道路上的車輛規避擁堵路段,實現交通的高效調度。在交叉路口,道路邊緣計算節點收集附近道路的信息,通過大數據算法,下發合理的道路交通調度指令,通過控制信號燈的狀態、為駕駛員提供擁堵預警等手段,實現道路的最大利用率,減少不必要的停留,從而減少道路擁塞,降低燃油損耗。

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一般基于電信運營商的移動網絡和基站進行通信。邊則包括眾多邊緣計算節點,一般在道路側或者運營商的邊緣機房,采用適應邊緣物理部署環境的定制服務器硬件部署。端則包括各種車、路上的多種視頻、事件監測、信息、計算終端及傳感器等。

5g4-t2.gif

    在上述架構中,邊緣計算節點將發揮關鍵作用,目前電信業討論較多的是引入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調用流程進行詳細描述。不同應用可根據業務特點選擇適合的通信機制。

5g4-t3.gif

4.1 基于MQTT協議的廣播/訂閱類消息API調用方式

    MQTT是一種發布/訂閱傳輸協議,基本原理和實現[8]如下,如圖4所示。

5g4-t4.gif

    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所示。

5g4-t5.gif

    (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所示。

5g4-t6.gif

    XMPP中定義了三個角色,即客戶端(Client)、服務器(Server)、網關(Gateway)。通信能夠在這三者的任意兩個之間雙向發生。服務器同時承擔了客戶端信息記錄,連接管理和信息的路由功能。網關承擔著與異構即時通信系統的互聯互通。基本的網絡形式是單客戶端通過TCP/IP連接到單服務器,然后在之上傳輸XML。

    XMPP服務器部署在MEC server上,路側的本地計算設備作為客戶端將感知結果(結構化數據)通過服務器發送到部署在MEC上的應用或其他設備的客戶端。或者,MEC上用于數據感知融合分析的邊緣應用作為客戶端,將融合分析結果通過服務器發送到其他應用的客戶端上。

4.4 XMPP協議調用流程

    路側感知設備將數據源發送到MEC server的消息請求/響應具體流程如下,如圖7所示。

5g4-t7.gif

    (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)

重庆时时是合法的吗