在智能網(wǎng)聯(lián)的話題里，總是離不開V2X這個字眼，而在V2X的測試需求中又總是離不開HIL，不知你是否也經(jīng)常聽到以上這些，今天小K就抽絲剝繭，為你講解V2X HIL測試的種種。

▼

目錄

? 什么是V2X？

? 什么是HIL測試？

? 為什么需要C-V2X HIL測試？

? C-V2X HIL測試系統(tǒng)長什么樣子？

? C-V2X HIL測試系統(tǒng)如何工作？

什么是V2X？

學一門學問要從概念開始，V2X的概念相信大家都不陌生，這里簡單說一下，V2X是Vehicle to Everything的縮寫，直譯過來的意思是車聯(lián)萬物，具體指的是V2V，V2I，V2P和V2N，這幾項可以在下方找到對應的解釋。

V2I：指的是車輛與道路設施之間進行通信，例如，當汽車接近交叉路口時，信號燈可以告訴汽車交通信號會在什么時候切換。

V2N：指的是車輛與蜂窩網(wǎng)絡交換數(shù)據(jù)，可以提供實時交通信息，比如施工區(qū)警告，通過 V2N 還可以提供 SOS 服務以及遠程診斷和維修。

V2P：指的是車輛與行人和非機動車之間進行通信，以便在駕駛員視線受到妨礙時也能保障這些人的安全。

V2V：指的是車輛與車輛之間的通信，主要是車輛之間的短時延通信，避免車輛碰撞等安全性問題。

那這項技術是做什么用的呢？舉個例子，當司機在開車時，需要手、眼、耳并用，隨時注意車身附近的情況，那么我們知道為了實現(xiàn)高級輔助駕駛功能，車本身要逐漸代替駕駛員的作用，所以車本身也應該清楚它本身附近的情況，所以傳感器技術正像是汽車本身的“眼睛”和“耳朵”，眼觀六路，耳聽八方，但這些就足夠了嗎？

傳感器本身都是有視野范圍的局限性，那些它們看不到的死角，或者是道路上有遮擋物又該怎么辦呢？這時就該V2X發(fā)揮作用了，通過V2X技術，車輛得以發(fā)送和接收到其他車輛、道路等參照物的通信信號，得知那些視野范圍外的路況信息，從而通知車輛本身，避免事故的發(fā)生。

關于V2X，此前我們還寫過一篇更詳細的文章，包括它的發(fā)展、競爭與優(yōu)勢，詳細可參照：關于C-V2X的那些事！

什么是HIL？

說完了V2X，我們再來說說HIL，HIL全程Hardware-in-the-loop，中文翻譯過來叫硬件在環(huán)。還有幾個和它名字很像的“兄弟”，MIL，SIL和PIL，相信搞工程的同學們對此都不陌生，所以這里不詳細解釋每個詞的含義，簡單來講，MIL和SIL只是在軟件層面（模型和代碼）進行測試，PIL在前兩者的基礎上引入了更貼近現(xiàn)實的編譯環(huán)境，而HIL測試則是在前面的基礎上引入真實的待測物進行測試。

那么為什么需要HIL測試呢？由于汽車本身的零部件繁雜，很多系統(tǒng)硬件和軟件也是在并行開發(fā)，HIL測試可以有效地對單個系統(tǒng)進行測試，避免集成后出現(xiàn)嚴重的bug，同時對于一些危險性比較高或者是極端的情況，也可以使用HIL來進行測試。在后續(xù)的文章中，我們也會為大家以V2X HIL系統(tǒng)為例，讓大家了解HIL測試系統(tǒng)的架構(gòu)。

為什么需要C-V2X HIL測試？

前面我們說過V2X的本質(zhì)在于通信，在V2X測試中，測試的對象往往是OBU/RSU（車載單元/路側(cè)單元），負責收發(fā)信號，怎樣測試它是否符合標準呢？

當然是車上帶著它在測試路段走一圈，針對不同場景來看看數(shù)據(jù)，但這說起來簡單，實際上非常費時費力，搭建真實場景不僅費時費力，重復測試和極端情況測試也很難，安全性無法保證，測試周期長，效率也很低。所以在真正的路測之前，先進行HIL測試，安全，準確可重復地對OBU/RSU測試就很有必要。下面我們就來看一下，如何來進行V2X HIL測試吧。

C-V2X HIL測試系統(tǒng)長什么樣子？

首先我們來看一下整個測試系統(tǒng)的架構(gòu)。下圖是由是德和懌星共同搭建的C-V2X HIL測試系統(tǒng)的方案架構(gòu)，我們以此圖為例，讓大家來看看V2X HIL測試包含哪些部分，該方案的DUT為OBU，所以在下方的文案中，我們也從OBU的角度進行解釋。

紅色部分：紅色部分是場景仿真軟件，前面我們講過，在路測之前，無法把OBU/RSU帶到真實的環(huán)境中進行測試，所以為了解決這一難題，通常使用場景仿真軟件來代替真實場景進行測試，常用的場景仿真平臺如圖中的PreScan，VTD和CarMaker等等。

典型的場景包括FCW（前向碰撞預警場景），DNPW（逆向超車提醒場景），LTA/ICW（左轉(zhuǎn)和交叉路口盲區(qū)提醒場景）等等，還有一些典型場景可以參考中國汽車工程學會發(fā)布的T/CSAE 53-2017標準，當然有時也有用戶自定義的一些場景，圖中所示的這套系統(tǒng)也可以進行支持。

CSAE第一期V2X場景

（圖片來源于中國汽車工程學會標準 T/CSAE 53-2017）

從場景中獲取的數(shù)據(jù)有三類：

?

RV/RSU數(shù)據(jù)：遠車，路側(cè)單元數(shù)據(jù)

?

HV CAN/ETH數(shù)據(jù)：主車運動消息

?

HV GNSS數(shù)據(jù)：GNSS定位和授時信號

下面就這三類數(shù)據(jù)各自的部分進行架構(gòu)的講解：

RV/RSU數(shù)據(jù)傳輸包括：

RV Simulator/RSU simulator：此部分主要是ITS協(xié)議棧，它會負責接收場景中的RV（Remote Vehicle即場景中仿真的遠車）以及RSU出數(shù)據(jù)，然后轉(zhuǎn)換成報文的形式，為傳遞給物理層做準備，常見的報文包括BSM，SPAT，MAP，RSI等等。

注：關于V2X測試還有另外的一種測試涉及到ITS協(xié)議棧，名為一致性測試，是德科技在以往也發(fā)布過相關測試方案，本文篇幅有限不再詳述，有興趣的可以參考：是德科技聯(lián)合中國信通院和東軟集團成功完成C-V2X協(xié)議一致性測試

Keysight C-V2X軟件和Keysight E7515B硬件：即是德科技的C-V2X測試平臺，在此系統(tǒng)中用于射頻信號測試，支持物理層的測試，E7515B單表是可以支持4G，5G信號的測試，在此系統(tǒng)中主要用于V2X的測試，在接收來自ITS協(xié)議棧的報文后，會通過PC5將信號傳輸?shù)紻UT。

HV CAN/ETH數(shù)據(jù)傳輸包括：

CAN卡/以太網(wǎng)卡：接收來自仿真場景中的車身運動信息，完成數(shù)據(jù)處理之后，發(fā)送給OBU。

HV GNSS數(shù)據(jù)傳輸包括：

GNSS模擬器平臺：在此系統(tǒng)中使用的是GSG設備，負責接收來自場景中的仿真的GNSS信號作為自身的動態(tài)輸入，在HIL系統(tǒng)中需要它來實現(xiàn)動態(tài)更新，GNSS模擬器在實際測試過程中與E7515B進行物理連接，完成時間的同步，然后發(fā)送射頻信號給OBU，再完成與OBU的時間同步。

了解了圖上的系統(tǒng)架構(gòu)以及基本概念之后，讓我們來看一下實際的測試系統(tǒng)長什么樣子？

簡要概括一下這套C-V2X HIL測試系統(tǒng)的特點：

整套系統(tǒng)由是德科技無線綜測儀，GNSS模擬器和V2X場景仿真平臺以及協(xié)議棧組成。

從物理層來講，是德科技的UXM支持4G，5G和C-V2X的測試，在該系統(tǒng)中充當射頻和接入層測試的主要設備，硬件計算資源強大，對于上層復雜場景如擁塞，多目標等都能輕松支持；接口開放，支持市面上成熟的C-V2X協(xié)議棧，滿足協(xié)議一致性測試需求。

從上層來講，整套系統(tǒng)支持各類成熟的商用仿真平臺，同時可以仿真CSAE標準場景和自定義場景；協(xié)議棧方面，支持國標各類報文，以及集成了可支持安全策略的擴展接口。