基于CarMaker的BSD系統(tǒng)加速測試研究

李衛(wèi)兵，李 娟，李東浩，孫 濤，吳賢靜

（安徽江淮汽車股份有限公司技術中心 汽車智能網聯(lián)技術安徽省重點實驗室，合肥 230091）

BSD系統(tǒng)是汽車主動安全技術之一，能夠監(jiān)測車輛行駛過程中盲區(qū)內是否有車輛超車經過，通過聲光報警提示駕駛員，以便有效地降低交通事故的發(fā)生。BSD系統(tǒng)通過安裝在車身尾部兩側的毫米波雷達來偵測汽車兩側的車流情況。近年來，BSD系統(tǒng)已在國內外各主機廠各車型中陸續(xù)應用，國外企業(yè)如大陸、德爾福等，國內企業(yè)如中電38所、中航54所等也已擁有24 GHz的毫米波雷達產品。但是由于中國道路的實際工況較為復雜（如城市快車道上仍可能有三輪車行駛的情形），BSD系統(tǒng)的邏輯、控制策略等的完善更具挑戰(zhàn)性，單純的實車道路耐久性試驗無法針對BSD系統(tǒng)的所有應用場景進行有效驗證，因此對BSD系統(tǒng)的測試場景及測試方法的研究，是完善BSD系統(tǒng)控制算法、提高其可靠性的核心之一。

測試場景、駕駛員模型和測試目標物是主動安全系統(tǒng)場地測試方法的三大要素。其中，測試場景必須與真實交通環(huán)境中存在的危險相對應[1]。當前，針對BSD系統(tǒng)的場地測試已發(fā)布的標準和規(guī)范 有 ISO 17387 Intelligent Transport Systems — Lane Change Decision Aid Systems（LCDAS）—Performance Requirements and Test Procedures（智能運輸系統(tǒng)——路線改變決定和輔助系統(tǒng)（LCDAS）——性能要求和試驗程序），SAE J3063 Active Safety Systems Terms and De fi nitions（主動安全系統(tǒng)術語和定義）等，國內針對不同主機廠配置的換道輔助系統(tǒng)已開展大量的場地測試，GB/T 20130072-T-469《車輛運行碰撞危險報警系統(tǒng)性能要求》已列入建標計劃中，但是從試驗成本和效率考慮，場地測試中的測試場景相對較小，不能很好地覆蓋到上文所提到的駕駛員多樣性駕駛工況，各主機廠在BSD系統(tǒng)場地測試合格的基礎上，更多的是對實車道路下的BSD系統(tǒng)進行整車級驗證，這必然投入大量的成本。

本文綜合考慮法規(guī)中的BSD系統(tǒng)場地測試場景要求，以及根據某平臺化BSD系統(tǒng)在某車型實際道路下采集得到的錯誤報警的負場景數據庫，通過篩選和分類，判別并提取影響毫米波雷達的典型特殊場景，將其進行權重劃分，最后利用CarMaker軟件進行負場景模型庫的搭建，設計一種等效實車路試100萬km的自動化加速驗證方法，利用硬件在環(huán)（Hardware-in-the-loop，HIL）進行仿真驗證，以完善BSD算法的開發(fā)。

1 BSD系統(tǒng)的工作原理

車載雷達屬于短程雷達（Short-range Radar，SRR），短程雷達一般工作在脈沖模式（脈沖和脈沖多普勒）或連續(xù)波模式（連續(xù)波、調頻連續(xù)波和頻移鍵控）。由于調頻連續(xù)波雷達（Frequency Modu-lated Continuous Wave，FMCW）具有較高的測量精度、較易實現小型化的結構等特點而普遍被汽車BSD系統(tǒng)采用[2]。

BSD系統(tǒng)主要由側后后視雷達、外倒后視鏡指示燈、系統(tǒng)功能開關三部分組成，側后后視雷達安裝在車輛后保杠的兩側，通過發(fā)射毫米波和對回波進行分析來探測本車道和相鄰車道內的車輛信息，當車輛出現在雷達的盲區(qū)范圍內時，通過CAN總線輸出報警信息。外倒后視鏡指示燈用于指示系統(tǒng)所處的狀態(tài)。系統(tǒng)功能開關用于雷達在啟動和禁止之間切換。本研究中某平臺化BSD系統(tǒng)功能邏輯示意框圖，如圖1所示。

圖1 某平臺化BSD系統(tǒng)功能邏輯示意框圖

通道1和通道2分別表示車輛左側與右側后方的探測雷達，通過上述雷達對本車的駕駛員盲區(qū)，即車輛兩側車道從外倒后視鏡處向后至車輛后方10 m范圍進行監(jiān)測，當有車輛出現在該區(qū)域且滿足報警條件時，將對駕駛員做出警告。

BSD系統(tǒng)的功能在路面彎道半徑不小于170 m且本車行駛速度不低于30 km/h時啟動，速度回落至25 km/h及以下時禁止。

2 BSD系統(tǒng)性能影響要素及潛在失效工況分析

2.1 系統(tǒng)性能影響要素

由雷達目標信息探測工作邏輯示意圖（圖1）可知， BSD系統(tǒng)集成了目標物的雷達探測、目標配對及報警等兩大主要功能模塊，因此，BSD系統(tǒng)最終表現的性能優(yōu)劣與上述兩大主要模塊的處理結果息息相關[3]。其主要影響因素可簡述為：雷達探測性能（對目標物的感知能力以及干擾源的抑制）和BSD系統(tǒng)的邏輯策略性能。具體見表1和表2。

表1 雷達性能

表2 邏輯控制策略

2.2 實車道路驗證故障場景分析及典型測試場景設計

2.2.1 實車道路驗證故障場景采集及分析

道路采集試驗，通過在試驗車上安裝4個攝像頭，分別用來拍攝儀表、后左車輪盲區(qū)、后右車輪盲區(qū)、車輛的后方區(qū)域；在車內安裝數據記錄單元，用以連續(xù)記錄所采集的視頻數據；利用ViCANdo對總線數據、攝像頭數據、GPS數據進行同步記錄分析。實車道路驗證故障場景如圖2所示。

圖2 實車道路驗證故障場景

根據某平臺車型BSD系統(tǒng)在3萬km實車道路驗證過程中實際發(fā)生的21例故障，對其進行分類，并分析各故障工況下的影響因素以及安全評價，見表3。

表3 故障分類

2.2.2 權重劃分及典型測試場景設計

根據表3中對實際故障的頻次以及安全評價分析，提出依據故障工況的重要度進行權重劃分，以及將典型測試場景與權重進行對應分類的方法，見表4。

因此，從法規(guī)符合性、駕乘舒適性以及某平臺車型BSD系統(tǒng)的實車道路驗證中突發(fā)的測試場景等角度，識別出13類典型要素，共計34個典型場景，并對上述各測試場景按表4對其權重做出以下分類，見表5。

表4 權重及定義

3 BSD系統(tǒng)加速測試設計

由表5可知，大部分典型場景是由某車型在經過3萬km實車道路驗證中實際發(fā)生的，但僅3萬km的實車道路驗證，不足以考察車輛各系統(tǒng)的耐久性和穩(wěn)定性，目前國內各主機廠往往在車輛上市前進行百萬公里的道路驗證[5]。由于BSD系統(tǒng)在實車道路驗證時，還需充分考慮上述場景，所以百萬公里實車道路驗證將花費巨大的成本。因此，提出一種利用CarMaker軟件建立負場景數據庫，并利用HIL臺架的自動化測試模式進行加速測試的方法。

表5 典型測試場景[4]

3.1 負場景數據庫設置

根據表4，設置BSD系統(tǒng)3萬km的實車道路驗證，則：

式中：A為場景總數；C為典型測試場景類別；N為測試場景數；W為權重；i為場景數。

那么，100萬km的實車道路驗證需運行的測試場景B為：

即利用HIL臺架所運行的測試場景總數為：

3.2 CarMaker中建模和仿真驗證

CarMaker是德國IPG公司開發(fā)的一款專門為智能汽車系統(tǒng)提供設計、驗證和評價環(huán)境的仿真軟件[3]，具有較好的人機交互界面。CarMaker作為乘用車的智能化仿真軟件，不但包括精準的車輛本體模型（發(fā)動機、底盤、懸架、傳動、轉向等），還可通過GUI生成道路（IPGRoad）、交通環(huán)境（IPGTraf fi c）、駕駛員（IPGDriver）以及車輛操作（IPGManeuver）等序列。此外，該軟件還可用于車道偏離警告系統(tǒng)、夜視系統(tǒng)、自適應巡航控制系統(tǒng)等高級駕駛輔助系統(tǒng)的開發(fā)和測試；提供復雜的交通環(huán)境標志以及不同類型傳感器的支持，并可設置復雜的測試腳本來進行難以通過路試實現的測試工況[6-7]。

3.2.1 道路環(huán)境建模

分析真實道路的相關參數，如車道數、車道寬度、車道標記線、彎曲半徑等。在仿真建模軟件的參數化路面界面，分別定義整條道路的寬度和摩擦因數、車輛在道路上開始的位置、整條道路的原點坐標和方向，并通過定義一系列子路段、所選各子路段的幾何屬性，如直線、圓弧等，定義當前子路段的寬度、摩擦因數等。設置完成后，生成的3D虛擬測試道路，如圖3所示。

3.2.2 傳感器建模

圖3 道路環(huán)境建模

從仿真軟件的傳感器元素庫中將毫米波雷達傳感器拖放到虛擬車輛的車身上，設置安裝在車身上的傳感器的坐標（Position x-y-z）、傳感器監(jiān)測角相對于z-y-x軸的旋轉角度（Rotation x-y-z）、偵測角水平角度和垂直高度（Horiz-Vert Aperture）、偵測波形的長度（Longitudinal Range）、雷達更新頻率和偏移量（Update Cycles Offset）等內容，實現傳感器參數化建模，如圖4所示。

3.2.3 自動化測試

利用VerSand將CarMaker與HIL的硬件設備進行耦合，通過IO板卡模擬BSD系統(tǒng)硬件輸入/輸出，CAN板卡對BSD系統(tǒng)的總線信號進行仿真與監(jiān)控，并將仿真軟件中的傳感器輸出信息進行目標注入。在CarMaker中，利用TestManager進行測試序列的搭建，首先，通過添加車輛配置改變選擇測試車型、輪胎、拖車、負載等車輛特性參數；其次，添加TestRun，用于添加預定義的仿真工況，并設置參數的類型和名稱。最后，添加特征值，計算某些特征值評價仿真結果，自動生成測試報告[8]，如圖5所示。

圖4 傳感器建模

圖5 自動化測試

由于涉及的測試場景較多，本文不再一一列舉，僅就典型場景1（法規(guī)測試工況一級報警測試）中驗證出的問題及其整改效果進行舉例說明，如圖6和圖7所示。

圖6 仿真設計的典型場景

圖7 整改后的驗證效果

圖6和圖7為照明條件良好時，目標車超本車，目標車為水泥車時的CarMaker模型。模型中本車速度為33 km/h，BSD系統(tǒng)開啟，轉向角速度為－1.8°；目標車與本車靠近，進入本車盲區(qū)內。根據表1中BSD系統(tǒng)的報警策略設計可知，此時目標車如在本車盲區(qū)內，本車需連續(xù)報警。根據HIL臺架驗證的結果，發(fā)現BSD系統(tǒng)存在以下問題：系統(tǒng)發(fā)生報警，持續(xù)一段時間后停止，后又發(fā)生報警并持續(xù)一段時間，如圖8所示。仿真驗證時多次出現此類問題。

通過對BSD系統(tǒng)的報警控制策略進行分析，做出以下整改策略：（1）優(yōu)化主車超目標車場景下報警邊界條件和動態(tài)變化范圍，提升邊緣場景下的報警連續(xù)性。（2）優(yōu)化主車超目標車場景過程報警開始和結束準則，減少誤報警現象。再次進行HIL驗證時，此類問題得以閉環(huán)。

圖8 實車回歸測試報警不連續(xù)問題

4 結論

提出基于CarMaker的盲點監(jiān)測系統(tǒng)加速測試方法設計，通過分析實際道路驗證的故障場景庫，實現了故障類別和權重的劃分，以及典型測試場景的設計。通過CarMaker仿真軟件實現了對典型測試場景的模型建設，以及加速測試的驗證實施，給產品開發(fā)和優(yōu)化提供了驗證數據及優(yōu)化方向，從而降低整體開發(fā)成本。