自駕車整合感測、通訊、定位與控制等技術已蔚為風潮,其中自駕車結合車聯網通訊技術與應用亦成為各大車廠積極研發的方向之一,目前車聯網短距無線通訊 (Dedicated Short Range Communication, DSRC)技術的推動者大多來自美國與歐洲,他們在DSRC研發上進行了大量投資,也一直積極推動立法要求汽車產業使用DSRC技術;而蜂巢式通訊技術(Cellular Vehicle-to-Everything, C-V2X)和產業的製造與研發重心則是在歐洲、美國、中國、日本與韓國。以中國市場為例,不管政府還是企業,皆看好C-V2X,規劃2020至2025年就能看到C-V2X實現在量產智能汽車中的商用部署;美國政府的態度則是保持技術中立,讓車廠在DSRC和C-V2X之間自由選擇技術。

工研院資通所 徐志偉、趙永晟

自駕車整合感測、通訊、定位與控制等技術已蔚為風潮,其中自駕車結合車聯網通訊技術與應用亦成為各大車廠積極研發的方向之一,目前車聯網短距無線通訊 (Dedicated Short Range Communication, DSRC)技術的推動者大多來自美國與歐洲,他們在DSRC研發上進行了大量投資,也一直積極推動立法要求汽車產業使用DSRC技術;而蜂巢式通訊技術(Cellular Vehicle-to-Everything, C-V2X)和產業的製造與研發重心則是在歐洲、美國、中國、日本與韓國。以中國市場為例,不管政府還是企業,皆看好C-V2X,規劃2020至2025年就能看到C-V2X實現在量產智能汽車中的商用部署;美國政府的態度則是保持技術中立,讓車廠在DSRC和C-V2X之間自由選擇技術。

本文將剖析工研院自駕車運用車聯網與號誌編解碼技術,其中包括DSRC和C-V2X這2種通訊技術與協定。此外,將闡述工研院自駕車落實車聯網技術之應用驗證場域,如位於臺南沙崙之臺灣智駕測試實驗室。未來,自駕車可透過電信營運商把路側單元(Roadside Unit, RSU)整合到基地台來提供公共服務,而車廠傾向於在車輛中整合C-V2X直接通訊能力和V2N(Vehicle-to-Network)網路通訊能力,因為這樣可以利用傳統電信營運商提供的網路能力、規模化的成本效益以及其能夠幫助建立的認證能力,亦可帶動整個自駕車與車聯網產業的發展。

精彩內容

1. 工研院自駕車整合車聯網通訊技術

2. 工研院自駕車整合號誌編解碼技術

3. 工研院自駕車驗證場域

4. 未來自駕車技術發展

工研院自駕車整合車聯網通訊技術

自駕車通訊技術,即採用車聯網V2X通訊,使自駕車具有對外連網能力,該技術可區分為兩大類,分別為短距無線通訊DSRC與蜂巢式通訊C-V2X,DSRC通訊頻段為5.9GHz,反應時間為0.002sec,通訊距離為1km,通訊技術由美國ASTM(American Society for Testing and Materials)於1992年主要針對ETC(Electronic Toll Collection)技術,採用915MHz頻段發展至今,已進入成熟期,通訊標準分美規802.11p、IEEE 1609、歐規ETSI ITS、日規ARIB STD-T75,DSRC售後市場零組件供應商,採用如Autotalks、Qualcomm(2016年收購NXP)晶片的裝置。

而5G C-V2X基於蜂巢式通訊的V2X技術,它包含基於LTE(Long Term Evolution)以及未來6G的V2X系統,支援兩種通訊介面,即蜂巢式通訊介面(Uu)和直連通訊介面(PC5),目前全球的領先企業成立了5G汽車通訊技術聯盟(5G Automotive Association, 5GAA),共同推動5G工業標準的制定。自駕車結合車聯網V2X通訊發展出多種應用類型,如車對車(V2V, Vehicle-to-Vehicle)、車對人(V2P, Vehicle-to-Pedestrian)、車對電信網路(V2N, Vehicle-to-Network)與車對路(V2I, Vehicle-to-Infrastructure)。

工研院所開發的自駕車系統亦整合車聯網技術,其系統架構如圖1所示,其中包含V2X車聯網通訊次系統、感知次系統、決策次系統與控制次系統。感知次系統、決策次系統與控制次系統透過先進的感測器(光達、雷達、攝影機與定位設備)與機器學習軟體演算法的處理,可以讓車輛電控單元完整模擬甚至超越人類在駕駛車輛時所使用各種擬人化的感官能力(如觸覺、視覺與方向感),實現同步即時的全方位環周感測能力,並針對感測結果進行控制決策的判斷。V2X車聯網通訊次系統提供感官中聽覺能力並著重提供自駕車對外通訊並傳送對外所接收到的訊息給決策次系統,使自駕車具備行車安全防護、接收路側設備所推播前方交通壅塞與接收路口號誌時相資訊做為自駕車均勻車速控制的應用。


圖1 工研院自駕車系統結合車聯網通訊技術之運作

無論是DSRC或C-V2X,兩項標準相互融合是未來發展方向,因為各有其優劣勢之分,如在有網路、有基地台狀況下,採用C-V2X會更有效率,同時C-V2X具備技術前瞻性,有逐漸升級可能,如歐洲標準化委員會(European Committee for Standardization, CEN)與ETSI於2014年2月ETSI ITS Workshop宣布協同式智慧型運輸系統(Cooperative Intelligent Transport Systems, C-ITS)第一版標準正式發布,其主要依據2009年歐盟指令(Mandate M/453),希望滿足不同製造商所生產之設備能彼此與道路系統通訊之需求,達到day-one application布建之成熟度,而目前ETSI目前正著手制定第二版標準,主要涵蓋更多使用案例,包括自動跟車、協同式可適應性巡航控制(Cooperative Adaptive Cruise Control, C-ACC),以及弱勢道路使用者(Vulnerable Road User, VRU)等。

歐盟各國亦積極投入C-ITS大規模布建,其中C-ITS Corridor計畫為荷蘭、德國與奧地利政府自2015年合作啟動,於橫跨3國之高速公路布建C-ITS服務,包括道路障礙警示(Roadworks Warning, RWW)與探偵車輛資料蒐集(Probe Vehicle Data, PVD)。相對而言,DSRC目前標準亦已成熟,其優勢是系統的穩定,與隨時可進入量產階段的能力。綜合這2項技術的各種面向,預期2種通訊未來將採取相互融合發展趨勢前進。如圖2所示,DSRC跟C-V2X兩大車聯網通訊技術於標準制定上雖底層(L1~L3)不同,但兩大標準的上層(App)可共用,亦可透過Gateway連接與串聯兩大系統,形成車聯網通訊技術單一整合之解決方案。


圖2 DSRC與C-V2X通訊協定架構

工研院自駕車整合號誌編解碼技術

自駕車整合號誌編解碼技術包含SAE J2735 SPaT(Signal Phase and Timing)/MAP訊息的封裝,在SPaT格式裡,會定義路段編號(Lane ID),不同的方向及不同的線道都由這個獨特的路段編號來區分,其中進入路口的稱為ingress lane,離開路口的為egress lane。而在MAP封包中,也有跟SPaT封包對應的號誌編號(Signal Group ID)供不同方向的來車使用的號誌資訊,如圖3所示。


圖3 自駕車運用號誌編解碼技術於十字路口示意圖

自駕車於號誌編解碼技術所應用之情境,MAP的作用在於描述路口地理特徵等資訊,包含路口中心點經緯度以及停止線經緯度跟路段起點經緯度。在自駕車車機端(On-board Unit)接收到此MAP封包後,解譯計算各個線道的道路向量對應路段編號及此線道的起終點座標,而SPaT封包的作用在於描述場域路口狀態及各線道剩餘秒數資訊,包含各線道之時態起始與結束時間。在車機接收到SPaT封包後,取出對應MAP封包中的Signal Group ID,藉此了解各線道的時相狀態(Movement Phase State),車機通訊單元藉此即可了解此組配對的SPaT/MAP封包所描述的路口時相狀態跟剩餘秒數。

自駕車運用車聯網與號誌編解碼技術由路側號誌端、聯網通訊端(DSRC/C-V2X)與自駕車控端3個各自獨立運作的系統組成,如圖4所示。


圖4工研院自駕車運用車聯網與號誌編解碼技術之系統架構圖

路側號誌端包含路口號誌控制器設備、介接號控訊息之工業電腦(Industrial PC, IPC)以及路側通訊單元(RSU)。工業電腦IPC負責解譯與各家不同廠牌的號誌控制器介接,並把結果以JSON字串提供給路側通訊單元,IPC主要工作如下:

  • 接收號誌控制器所發送之號誌封包
  • 解析與解譯號誌封包
  • 發送解譯後JSON字串到路側通訊單元

當IPC正確取得來自號誌控制器的號控封包,如5F03協定後,進行一系列的時相週期學習機制,如圖5流程圖所示,當IPC接收完一輪時相後,在確認下一輪號控封包接收比對無誤後,開始每秒更新號誌狀態及剩餘秒數給路側端通訊設備,運作流程圖如圖6所示。

若是號誌控制器發生異常,工業電腦IPC將於signalControlerStatus欄位填入號誌控制器目前狀態,定義如下:

  • -1:號誌控制器停止發送步階轉換訊息
  • 1:正在重新學習新的時制計畫
  • 2:學習完畢,正常倒數

路側通訊單元(RSU)負責接收來自工業電腦IPC解譯號誌封包後的JSON字串並編碼成SAE J2735 SPaT/MAP格式的封包,以廣播的方式讓自駕車車機通訊單元(OBU)接收,RSU主要工作如下:

  • 解析與解譯號誌JSON資訊
  • 編譯號誌資訊成SAE J2735 SPaT格式封包
  • 根據路口資訊,封裝SAE J2735 MAP格式封包
  • 廣播給周遭車機通訊單元
  • 場域號誌資訊回後台

車機通訊單元(OBU)負責接收來自路側通訊單元(RSU)SAE J2735標準格式封包,並把結果以CAN的格式封裝提供給自駕車控端,OBU主要工作如下:

  • 接收自駕車控端即時GPS資訊
  • 解譯SAE J2735 SPaT/MAP格式封包
  • 將即時號誌資訊轉成CAN格式供自駕車控端運用
  • 車端即時號誌資訊回後台

工研院自駕車驗證場域

工研院在實際場域驗證中觀察到,自駕車的運行路線,只要和人流有交會,運行路段就必須布建交通安全保護系統。除此之外,相關路側感測器(如光達、雷達與攝影機)與交通號誌時相(如綠燈與紅燈秒數)也應該要能夠即時傳遞給自駕車。例如,當自駕車收到路段壅塞、道路速限與交通號誌資訊時,即可動態調整車速,以達順暢運行之效果。工研院於自駕車結合車聯網之安全性應用,導入基隆、台北、新北、新竹、台中與高雄場域所運行之iRoadSafe系統,具備十字路口防碰撞警示(Intersection Movement Assist, IMA)、左轉防碰撞警示 (Left Turn Assist, LTA)、電子煞車燈警示(Extended Electronic Brake Light, EEBL)與前車碰撞警示(Forwarding Collision Warning, FCW)等4種安全應用,上述DSRC安全應用皆符合美國交通部USDOT標準與應用規範。

工研院於臺灣智駕測試實驗室運用車聯網與號誌編解碼技術於號誌時相推播應用,該應用已於2020年3月完成試煉與測試,為了驗證系統與應用的正確性與功能性,測試過程包含號誌編解碼技術與車聯網通訊設備通訊品質(於工研院中興院區)兩大測試項目。圖7為臺灣智駕測試實驗室測試場域,該場域包含4個十字路口(編號1、2、4與5)、4個T字路口(編號3、6、7與8)與2個模擬鐵路平交道(編號9與10),透過場域可驗證車聯網安全警示與號誌時相推播應用。


圖7臺灣智駕測試實驗室場域示意圖

為了驗證號誌編解碼技術的正確性,車機通訊單元依據自駕車控提供的GPS資訊及來自RSU場域所有號誌資訊後,將即將進入的路口號誌資訊以CAN的訊息提供給自駕車,CAN訊息包含當下時間、車機即將進入的路口的號誌狀態、剩餘秒數以及車控模式。整個封包總共8 Bytes,由時間戳記4 Byte,號誌時態1 Byte,剩餘秒數2 Byte和號控模式1 Byte組成,以下將說明CAN訊息格式內容。

  • 時間戳記(4 Byte):即時時間戳記(範例:1527046147)
  • 號誌時態(1 Byte):以8 bit代表號誌狀態(Bit map)
  • 剩餘秒數(2 Byte):以數字代表剩餘秒數x10的值(343表示34.3秒)
  • 號控模式(1 Byte):以8 bit代表號控模式(Bit map)

號誌時態用一個位元組表示燈態,從左到右依序是:車輛紅、車輛黃、車輛圓綠、車輛左綠、車輛直綠、車輛右綠、行人綠、行人紅。例如,當號誌狀態是車輛紅燈和右綠且行人綠,則此位元組為10000110。

號控模式用一個位元組表示號控狀態,定義如下:

  • 00000010代表「號誌異常」
  • 00000001代表「號誌重新計算模式」
  • 00000000代表「正常模式」

自駕車車控端必須確保號控狀態在正常模式下,才可以通過路口。

為了驗證車聯網通訊技術的正確性,於工研院中興院區透過自駕車運行路線進行通訊品質測試,將路側設備(RSU)放置於14館與22館交界處,配備通訊設備(OBU)從東大門往西大門行駛,如圖8與圖9所示,當行經58館即可接收成功封包,於250公尺通訊範圍內、最大接收訊號強度指示RSSI(Received Signal Strength Indicator)值為-75dB,其封包接收率為99%。


未來自駕車技術發展

在V2X車聯網通訊技術(如,DSRC、5G C-V2X)、前端感測元件(如,LiDAR、Radar、Camera與定位設備)、定位技術與操控技術的發展下,帶動自駕車結合車聯網通訊與號誌編解碼技術相關的應用與發展。且針對自駕車安全性的應用,需整合包含車載機與路側通訊設備等,以提供即時的通訊能力。有鑒於Google和UBER所發生無人車的事故層出不窮,自駕車開發商亦開始重視透過V2X車聯網通訊技術提升自駕車的安全性與便捷性,未來自駕車如結合遇障礙物煞停等相關應用與號誌時相推播應用,將成為通訊技術發展的機會所在。

參考文獻

[1] 3GPP Specification TR 22.185

[2] 3GPP TR 22.885 Study on LTE support for Vehicle to Everything (V2X) services, 2016

[3] 3GPP TR 23.785 Study on architecture enhancements for LTE support of V2X services, 2016

[4] SAE J2945/1 On-Board System Requirements for V2V Safety Communications, MAR 2016

[5] https://www.elektrobit.com