您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。[是德科技]:模擬功能全力助攻,ADAS 和 AV 測試再進化 - 发现报告

模擬功能全力助攻,ADAS 和 AV 測試再進化

AI智能总结
查看更多
模擬功能全力助攻,ADAS 和 AV 測試再進化

新一代精準雷達感測器:ADAS/AV系統快速演進的關鍵 建構安全可靠的自動駕駛(AD)系統是項極其複雜的任務。汽車製造商必須克服眼前的種種挑戰,以實現自動駕駛交通的未來願景。 自動駕駛汽車(AV)內部具有數百個感測器,所有感測器都需與車內和其他智慧汽車內的感測器協同運作。目前有許多支援自動駕駛功能的軟體演算法,它們可合成從感測器收集到的所有資訊,確保自動駕駛汽車能作出適當的回應。這些演算法需要在涵蓋各種駕駛情境的數百萬個複雜場景中進行測試。如此一來,汽車製造商才能信心十足地開發並推出新的先進駕駛輔助系統(ADAS)和AV功能。 想要進一步提高自動汽車駕駛等級,有賴於各式各樣的創新,以及相關技術的進步。比方說,持續投資於雷達、光達和攝影機等感測器技術,可提升環境掃描的準確度。每種類型的感測器,各有其優缺點,它們需彼此相輔相成,確保在物體偵測過程中能發揮內建備援能力的效用。 了解複雜的雷達感測器測試 在結合並傳輸大量高解析度感測器資料時,包括車聯網通訊資料,強大的軟體演算法必不可缺。機器學習常被用來訓練可自我改進的演算法。藉由使用這些演算法,汽車原始設備製造商(OEM)可改善AV在複雜交通狀況下作出正確決策的能力。 為此,他們需要在實驗室中,以可重複且可控的方法,使用逼真的激發來驗證這些演算法,藉以提高演算法的準確性,並增進道路駕駛安全性。汽車設計和測試工程師可將需要進行測試的情境,從3D模擬環境轉為真實的雷達信號輸入,然後用於進行道路測試。 利用從汽車感測器收集到的資料,來準確繪製並持續更新3D地圖,並且傳送給電子控制單元,是實現自動駕駛的關鍵步驟。雷達是行之有年的技術,但新一 代雷達感測器的前端正快速演進,同時也變得更複雜。它們具有以下特性: •從76至77 GHz提高到77至81 GHz的寬頻寬•藉由使用多個發射和接收天線,多輸入多輸出(MIMO)技術可善用多路徑傳播,以便進一步提高準確度•解析度更高的4D成像雷達 舊式的2D和3D雷達因功能有限,而且缺乏大規模MIMO,因此無法感知高度尺寸。新一代雷達感測器採用大規模MIMO結構,具有寬天線孔徑,可解鎖第四個感測維度–高度。這些雷達感測器提供更出色的感知能力,並將解析度和頻寬提高到4 GHz。因此,汽車測試解決方案必須大舉超越現有的感測技術,並提供更出色的功能,避免量測設備成為阻礙測試的絆腳石。 在實驗室中以可重複且可控的方法,使用逼真的激發來驗證這些演算法,有助於提高演算法的準確性並增進道路駕駛安全性。 此外,在感測器背後運作的偵測演算法也變得越來越複雜,使得對偵測演算法進行測試和驗證的要求也日趨嚴格。 如欲有效訓練這些感測器,業者需要的不只是單點目標(point target)。在真實道路上,雷達感測器必須能夠分辨目標是汽車、卡車、自行車,還是行人。雷達感測器識別並區分不同物體的能力至關重要,因為這關係到AV的反應能力,以及乘客的人身安全。然而,在實驗室內執行解決方案無法做到這一點。僅對最多8個移動目標(每個目標只有一個點)進行自動化測試,並不足以提供充分的細節,以協助AV學習如何辨識並區分不同的目標。 制定顛覆性測試策略 研發工程師習慣使用DevOps(開發與維運)模型,來推展整個應用軟體開發週期(從開發、測試到部署,再 回到 開 發)。透 過 這個 反覆循環 的 過 程,研 發工 程 師 可持 續收 集回 饋,並在每 次 迭 代中改 進 產 品。DevOps模型是軟體產業慣用的模式。現今,隨著汽車的軟體化程度不斷升高,汽車製造商也開始採用此流程。下面我們將DevOps模型分解為不同的迭代過程:環境模擬、特性模擬,以及部署。 環境模擬(Simulation) 透過模擬器,業者可建立模擬實際裝置之特性和配置所需的環境。汽車製造商會花費很多時間開發感測器和控制模組,然後透過軟體迴路測試來模擬環境。之後,汽車開發工程師會重新整合、調整並重複執行這些測試,如圖1所示。 特性模擬(Emulation) 在完全 使 用軟 體 進行模 擬後,下一步就 是 加入硬 體,讓 模 擬器能 夠複製真實裝 置的硬 體和軟 體 特性。在建構複雜的機具時,一個極其重要的步驟是,在實驗室中使用硬體迴路配置中的真實元件重建系統部件,以確保機具的安全性與可靠性。這個步驟可讓實驗室模擬順利跨到真實道路測試,以節省時間和成本。隨著演算法複雜度不斷升高,這個步驟攸關AD和ADAS系統開發的成敗。 在開放道路上進行測試 在使用成車(complete vehicle)在道路或測試道上進行測試之前,開發人員需在原型車或可上路的汽車中部署整合式系統。透過這項測試,OEM製造商可在推出市售車之前,對其進行驗證。路測或測試道駕駛非常危險,而且成本高昂。設計工程師雖有機會更新軟體,但更新系統級設計並非易事,而且重新進行紙上設計作業,開發時間會拖得更長。 改變思考模式 圖3顯示,開發人員會先依據環境模擬(simulation)結果進行特性模擬(emulation),然後再使用它進行道路測試。因此,每一次的模擬或測試,都奠基於前一次執行完畢的結果。透過此測試流程,設計和測試工程師可用模擬零件,來替代煞車或方向盤子系統等基本元件。過去,想在雷達系統上執行這項測試,困難度相當高。如果可取得的資訊太少,雷達演算法就無法進行學習,因而無法模擬逼近真實的情境,以便為道路測試做好準備。對於簡單的情境來說,這個問題不大,但對於無法在真實道路上進行測試的極端情境來說,問題將變得非常棘手。 假如業者的目標是實現Level 3+1級自動駕駛,那麼AD系統不僅須確保駕駛、乘客和行人的安全,同時還須監控汽車在道路上的每一個動作,以避開任何可能的法律刑責。 因此,汽車OEM製造商必須小心謹慎地開發駕駛功能,特別是全自動駕駛功能。現在開發人員可使用真實的雷達感測器和信號,在實驗室中模擬真實的場景,徹底顛覆了ADAS和AV測試的風貌。 實現AV成功願景 汽車產業的前瞻性發展,例如自動駕駛和電子化,有賴於軟體技術的大幅進展。正因如此,汽車開發的重點也逐漸從硬體轉移到軟體。ADAS Level 3或更高層級的自動駕駛汽車,需針對不斷變動的情境和周圍環境,進行全面的測試和驗證。除了測試數量增加,測試複雜度也會隨之升高。 例如,有了主動車距巡航控制系統,您只需關注前車的動向即可。然而,今天的系統級測試還需一併考慮各種類型的道路使用者。高速公路是個很好的例子。除了跟隨前車並保持安全距離外,在執行測試時,開發人員還需考慮自動操控,例如離開車道、超車和重新進入車道。而都市道路駕駛的複雜性更高,路上有行人、自行車和電動滑板車,而且有十字路口和左右轉等情境。單靠真實路測,無法呈現這麼多變又複雜的情境。如前所述,開發和驗證AV系統時,模擬成了攸關成敗的步驟。 NCAP可提供標準化情境 新車評鑑計畫(NCAP)測試最初的目標只是針對駕駛、乘客和第三方廠商,提供一套共通的安全標準。然而,這個自發性的安全評級系統立刻大受歡迎,並成為消費者公認的標竿測試機制。OEM製造商則將它當作便利但略具挑戰性的行銷策略。一般而言,汽車OEM製造商會在受控環境中使用假人進行碰撞測試。他們力求達到5星安全標準,以利品牌推廣和行銷訊息傳播。 隨著汽車自主性不斷升高,碰撞測試的複雜度也節節攀升。過去,這類測試只需要一個預束式安全帶、一個側面頭部安全氣囊,或是一個兒童限制系統就夠了。但是現在,進行道路測試時,工程師必須確認汽車是否能夠在一定距離內偵測到道路上的物體,無論是行人、自行車騎士等易受傷害的用路者(VRU),或是正以低速切入的另一輛車,並且能夠自動剎車。 表1列出道 路測試需涵蓋的可能情境,包括NCAP和美國國家公路交 通安全管理 局(NHTSA)2的測試案例,一直到基於雷達的ADAS/AD特性與功能。然而,這份清單不夠完整與詳盡;到底有多少情境需要測試這個問題,都可以另外撰寫一份白皮書了。 自動駕駛人工智慧(AI)開發人員正在進行一場思想實驗,也就是在發生碰撞時,應該先拯救汽車乘客,還是先拯救行人。麻省理工學院研究人員進行了廣泛的倫理研究,以確定開發人員是否將人類的偏見納入AI演算法中。其目標是讓AV比人類更快、更理性,並根據更多資訊,在這類情境中做出抉擇。 由於需要準確地 重現 場 景,NCAP情 境非常適合用於 實驗 室測試。在 加速 推出新產品的壓力下,汽 車OEM製造商必須在設計階段初期就開始進行測試。 他們意識到,在整個設計週期中,及早使用NCAP情境來進行實驗室測試,可以節省可觀的時間和金錢。透過場景模擬,汽車OEM製造商可在實驗室中及早驗證其雷達整合能力,以便為整合階段的開放道路測試或經認證的測試道測試做好準備。此流程有助於大幅降低未通過測試的風險。 NCAP情境1:自動緊急煞車 讓我們來看一個NCAP情境,即自動緊急煞車(AEB)。根據歐洲NCAP網站的資料,追撞事故是開放道路上最常見的碰撞事故。一旦後方車輛的駕駛分心,沒有注意到前車已經減速或停車,就會直接撞上去,因而發生追撞事故。 工程師需針對各種速度、汽車和交通狀況,進行AEB車對車系統測試。 FCW和AEB系統的設計,就是為了預防或減輕潛在的損害。這類系統會將前方的危險狀況吿知後車駕駛,假如駕駛還是沒有看到危險,則會自動剎車。由於潛在危險具有緊急特性,加上道路障礙物的接近性,直視(LOS)感測器最適合用來偵測這些情況。汽車製造商可單獨或協同使用攝影機、光達或雷達感測器(感測器融合),以因應不同的情況並提供不同的效能。 在實驗室中模擬感測器,至少需要一個目標——就是前方的汽車。現今的雷達目標模擬器可輕而易舉地做到這一點。然而,這只能測試 理想情境,而非真實情境,因為真實道 路中會有護欄、標誌牌的反射,另外還會有其他汽車。如果雷達無法正確判斷這些物體怎麼辦? AEB情境實驗 AVSimulation的SCANeR具 有NCAP情 境 庫, 可 提 供AEB前 方 車 輛 移 動(CCRm)的NCAP情 境。其視角來自於本車(ego vehicle)或是具有待測雷達的汽車。 圖6和圖7為SCANeR模 擬 所描 繪的道 路XY水平面俯瞰圖。此 工 具包含預 期 和偵 測到的雷達目標,並可讓使用者即時驗證基於雷達之ADAS/AD演算法對情境的反應能力。其中的紅色錐形體代表長距離雷達,藍色錐形體則代表短距離雷達。請注意圖像的相似性,包括護欄。 今天,您只需一個簡單的RTS系統,就可以模擬由2輛車組成的情境。然而,添加護欄的反射,有助於產生真實的場景,以確保更準確的AV系統驗證。 NCAP情境2:易受傷害的用路人 NCAP呼籲另一個亟需測試的關鍵領域是VRU。除了評估汽車保護乘客的能力外,NCAP測試還需評估汽車保護VRU(行人和自行車騎士)的能力,他們有可能與汽車相撞。和上述的AEB一樣,其目的是通知汽車駕駛即將發生碰撞,並在駕駛反應不夠快時,提供自動煞車機制。 汽車OEM製造商可透過這些測試,評估受傷風險。重點是,在駕駛和乘客之外,汽車能否保護行人和自行車騎士。和所有的NCAP測試一樣,這類測試有個評分系統。性能良好的汽車,如果配備可識別行人和自行車騎士的AEB系統,還可以再加分。 圖7顯示可模擬AEB系統測試的雙物體情境。然而,要是某個行人或自行車騎士突然從停著不動的汽車之間冒出來的話呢?又或者,如果有幾個行人正在過馬路,或在馬路上來回奔跑呢?這些情境指出了許多目標模擬系統的弱點:無法模擬靠近汽車和待測雷達的目標。 這些情境非常重要,因為在許多類似情境下,解析度和近距離是攸關生死的關鍵要素。請設想以下的情境:一輛測試汽車接近十字路口,在確實檢查過沒有行人和對向來車後,準備右轉(該地區紅燈右轉是合法的)。等到這輛車緩緩駛近時,其攝影機、長距離雷達和光達感測器幾乎無法發揮作用。因此,它必須使用橫向短距離雷達。這種雷達具有寬廣的視野和高解析度,以便偵測非常靠近車輛的物體。 假設穿越馬路的行人,恰好是一位推著嬰兒車的母親