實現篇：

在理論篇，我們介紹了理論上車輛模擬仿真的情況，那么為了實現車載擁塞場景的仿真，我們需要一些相應的測試儀表、仿真平臺和測試用例來實現擁塞場景的模擬工作，整個平臺的邏輯示意圖如圖1所示，有如下幾個部分組成和相應的功能模塊。

V2X仿真平臺CMW500

1. 多車環境接入層模擬

2. PC5 ITS消息的收發，并且控制不同車輛的功率以及物理層資源調度

3. 物理層基帶信號衰落模擬

實時衛星模擬器SMBV100B

1. PC5時序同步

2. 產生并實現OBU的路點信息

Canoe.Car2x仿真平臺

1. 交通場景編輯以及場景運行，測試結果分析統計

2. V2X傳輸層以及應用層協議實現

3. 通過CAN/Ethernet實現DUT的HIL測試

車載待測件OBU

1. 測試結果狀態分析以及統計

2. ECU HIL監控- Optional

圖1. 擁塞測試邏輯框架

基于上述的仿真方案，我們以一個150輛車的仿真實例來看一下如何進行大規模車輛仿真實測。首先我們需要配置Canoe.Car2x跟CMW500的接口進行配置。Canoe.Car2x將通過R&S公司和Vector公司定義的KAA550接口發送UDP數據將上層協議數據通過CMW500發送出去。下圖即KAA550的適配接口。

圖2. 儀表接口以及連接配置

在Sidelink PC5界面，我們可以對物理層參數以及Fading進行配置。

圖3. 儀表接口部分物理層配置

Canoe.Car2x測試平臺

在完成了Canoe.Car2x，CMW500，SMBV100B的配置之后，就可以在Canoe中進行軟件相關配置，場景編輯，場景開發以及測試運行了。如下窗口顯示了相關配置信息：

圖4. Canoe.Car2x運行界面

消息發送統計：

消息發送分析，這里我們可以在圖五中看到消息發送是以100ms為周期進行的，即每100ms會完成150輛車的消息發送。在圖六中我們可以看到 8.523時刻時，發送150輛車到21次，第21次中，發送到id的值為34。

由此計算8.523時刻時共發送了：20 × 150 + (34 + 1) = 3035次BSM消息。

圖5. Graphics窗口 時間 vs 車輛ID發送

圖6. Graphics窗口記錄BSM消息發送的個數

DUT端的HIL分析

我們可以同時在OBU的操作軟件中同步分析OBU收到的ITS消息的情況，這里記錄了在同樣的狀態下，待測OBU收到了150輛車發送的消息。

圖7. OBU打印log數據

總結

本文介紹的仿真方案和平臺可以提供多種功能，例如針對V2X不僅可以實現共計30個基本的DAY1，DAY2的交通模擬場景，也可以支持自定義的場景來進行算法驗證，同樣也可以穩定支持我們在未來面臨擁塞場景的測試挑戰。

關于羅德與施瓦茨

羅德與施瓦茨是測試與測量、系統與方案、網絡與網絡安全領域的領先供應商。公司成立已超過85年，總部設在德國慕尼黑，在全球70多個國家設有子公司。作為一家獨立的科技集團，羅德與施瓦茨創新性的產品和解決方案為全球工業及政府客戶提供了一個更安全與互聯的世界。截至2021年6月30日，羅德與施瓦茨公司在全球擁有約13000名員工。

原文標題：聊聊C-V2X擁塞測試的那些事兒之：從理論到現實

文章出處：【微信公眾號：羅德與施瓦茨中國】歡迎添加關注!文章轉載請注明出處。

審核編輯：湯梓紅