摘要：近年來,基于深度學習的視覺感知技術的發展極大地促進了車聯網領域中自動駕駛的繁榮,然而自動駕駛系統的安全問題頻出引發了人們對自動駕駛未來的擔憂．由于深度學習系統的行為缺乏可解釋性,測試基于深度學習的自動駕駛系統的安全性極具挑戰性．目前已有針對自動駕駛場景的安全性測試工作被提出,但這些方法在測試場景生成、安全問題檢測和安全問題解釋等方面仍存在不足之處．針對基于視覺感知的自動駕駛系統,設計開發了一種場景驅動的、可解釋強的、運行高效的安全性測試系統．提出了一種能夠平衡真實性與豐富度的場景描述方法,并利用實時渲染引擎生成可以用于駕駛系統安全性測試的場景;設計了一種高效的針對非線性系統的場景搜索算法,其可以針對不同的待測試系統動態調整搜索方案;同時,還設計了一個故障分析器,自動化分析定位待測試系統的安全性缺陷成因．復現了現有基于實時渲染引擎的動態自動駕駛測試系統,并同時使用本系統和復現系統對CILRS系統和CIL系統進行安全測試,實驗結果表明相同時間下本工作的安全問題發現率是復現的場景驅動的動態測試方法的１.４倍．進一步的實驗表明,可以分別為具有代表性的深度學習自動駕駛系統CIL和CILRS,從曠野、鄉村與城市的３類環境中動態生成的共３０００個場景中,搜索到１９３９和１６７１個造成故障的場景,并且每個故障場景的搜索時間平均為１６.８６s．分析器從統計的角度判斷出CILRS系統容易造成故障的區域在道路兩側,雨天和紅色或黃色物體更易造成該自動駕駛系統發生故障．
車聯網領域隨著物聯網與交通運輸領域的深度融合蓬勃發展．隨著深度學習的進步,車聯網領域的自動駕駛技術得到了突破性的發展,并有演化成一場新的汽車工業革命的趨勢．無論是特斯拉、蔚來等新型車企,還是福特、寶馬等傳統車企都陸續拿到了自動駕駛路測牌照,著眼于研發深度自動駕駛技術．迅猛發展的深度自動駕駛技術正逐漸成為車聯網領域的主要支撐技術之一,正在改變未來的交通和出行方式．
視覺感知模塊是自動駕駛進行環境感知的重要組件,也是車輛進行智能決策的重要基礎．自動駕駛領域的重要企業特斯拉更是將視覺感知模塊作為其駕駛系統的唯一環境感知模塊．因此,自動駕駛系統視覺感知模塊的安全性是自動駕駛系統正常工作的關鍵．雖然視覺感知模塊的表現隨著深度視覺技術的發展穩步提升,但是其從駕駛環境中感知到的特征語義難被理解、決策過程無法解釋．如何對自動駕駛系統視覺感知模塊的安全性進行充分測試,已經成為了一個迫在眉睫、亟待解決的問題．
誠然,圍繞深度學習可解釋性方面的工作有了一定的突破,但是距離分析清楚自動駕駛視覺感知模塊的錯誤傳導機理還有較遠的距離．近年來,神經網絡的黑盒攻擊方法的進步,啟發大家提出了一些基于場景搜索的自動駕駛視覺感知模塊安全性測試技術．這些場景驅動的測試方法利用黑盒測試的思路,為駕駛系統提供盡可能多的駕駛場景數據,觀察自動駕駛系統的輸出與測試預言(TestOracle)之間的差異,進而分析自動駕駛系統視覺感知模塊的安全性．
我們認為場景驅動的黑盒安全測試是在弄清深度學習可解釋性之前,對于視覺感知模塊安全性最 為重要的測試手段．但目前對于將生成場景應用于視覺感知模塊的測試,我們仍面臨著３個挑戰 :
１) 平衡場景描述的真實性與豐富度．場景生成 規則是場景驅動的測試系統的重要基礎．保守的規則設計會造成場景覆蓋能力不足; 而過于靈活的規則設計又會破壞物體相對關系,傷害場景真實性．探究一個能同時兼顧場景真實性和豐富度的場景生成規則極具挑戰性．
２) 保證搜索算法的高效性和穩定性．單個物體的屬性(如顏色、形狀)與物體間的相互關系(如位置、方向)組合十分復雜．為了能夠高效穩定地測試系統安全性缺陷,需要:動態地針對不同自動駕駛系統視覺感知模塊產生個性化的場景搜索方案,以保證搜索過程的步驟較少;同時盡可能縮短單步搜索的時間．
３) 解釋測試結果的精確性與自動化．以往測試系統需要介入人工分析缺陷原因．若想做到自動化地分析測試結果,系統需要能夠精細地操縱場景中每個元素來定位系統安全性缺陷的成因．
圍繞場景驅動的視覺感知模塊的黑盒安全測試,學術界已經有了初步探索．在場景測試方法當中,基于實時渲染引擎的一系列測試方法由于其場景生成的靈活性受到了廣泛關注．最初,基于實時渲染引擎的場景驅動的安全測試采用的是基于預定場景的測試思路．其中的代表性工作是CARLA０．８．X,該工作使用UnrealEngine創建用以測試系統的固定駕駛線路．接著,Scenic等人提出了一種場景生成的編程接口,以使此類測試程序更加系統化,奠定了靜態的基于場景測試的基礎．然而,其模擬環境較為固定,缺乏動態行為,同時對于非實體對象(如天氣)的描述缺少自由度．基于實時渲染引擎的場景驅動的安全測試的最新工作,Paracosm在Scenic的基礎上,提出了基于隨機搜索的動態場景生成方法來進行視覺感知模塊的安全測試．由于該動態場景搜索方法相對簡單,對待測試視覺感知模塊的適應性不足,因此,安全問題的搜索過程不夠高效．本文在前述工作的基礎上,提出了一種基于結果反饋的動態場景搜索算法,從而提高了自動駕駛系統中視覺感知模塊的安全問題測試效率．更多細節將在１．５節進行詳細介紹．
本工作中,類比深度學習黑盒攻擊策略,借助實時渲染引擎的開放度,設計并提出了一套可靠且具有可解釋性的自動駕駛視覺感知模塊安全性測試系統．主要的貢獻有３方面:
１) 本工作針對車聯網場景下自動駕駛系統感知模塊的安全問題,提出并設計了一套場景驅動的黑盒安全性測試系統．與現有工作相比,該系統引入基于結果反饋的動態化測試策略,通過自適應機制在循環中不斷調整輸入數據的生成,實現對感知模塊高效、穩定的非入侵式安全測試．
２) 面向自動駕駛視覺感知模塊的動態測試新需求,本工作設計了細粒度場景描述方法、適應性動態搜索算法和自動化系統缺陷分析的動態測試技術,從測試粒度、反饋自適和可解釋性３個方面對提出的黑盒安全性測試系統進行了優化．
３) 本工作以２個代表性的開源自動駕駛系統為對象開展了測試系統的驗證,分別動態生成了３０００個場景,并各自找到了１９３９和１６７１個故障場景,平均每１６.８６s可發現一個故障場景．實驗表明,得益于動態自適的場景搜索方法,本工作的安全問題發現率是現有基于實時渲染引擎的場景驅動的動態測試方向中最好工作的１.４倍．
1、相關工作
１.１ 基于神經元覆蓋的自動駕駛測試
神經元覆蓋是類比傳統程序的分支覆蓋而設計的．此類工作定義當測試輸入經過神經元使神經元輸出滿足某種狀態時,該神經元則稱被測試樣例覆蓋(激活)了．此類工作,以最大化神經元覆蓋為優化目標,來尋找輸入樣例．自DepXplore引入神經元覆蓋的概念并成功應用于基于視覺的深度自動駕駛領域后,已有大量關于神經元覆蓋的工作出現,提出了各式各樣的覆蓋標準,并成功使傳統軟件測試方法如蛻變測試、模糊測試、符號測試等遷移到深度學習測試任務中．然而,這種類比屬于一種機械類比,神經元的輸出值的狀態與傳統軟件測試中的分支是完全不同的概念,因而這種類比方法的有效性始終受到人們質疑．并且,基于神經元覆蓋的設計也難以給出基于語義的測試樣例故障原因,不利于自動駕駛系統安全性的進一步提升．
１.２ 基于錯誤注入的自動駕駛測試
AVFI使用軟件故障注入模擬自動駕駛系統的硬件故障,以測試系統的容錯性．隨后DriveFI使用Apollo和DriveAV在CARLA模擬器和DriveSim上進行實驗,利用貝葉斯網絡模擬自動駕駛系統加速錯誤注入后的驗證過程,能最大限度地挖掘出影響自動駕駛系統的故障．Kayote在上述工作的基礎上,添加了描述誤差傳播的能力,并且能直接注入CPU和GPU的位翻轉．這些工作是從容錯性的角度考察自動駕駛系統的特性的,而且實際考察的是自動駕駛系統的硬件故障．這類工作與本工作討論的場景和問題是正交的,本工作研究的是自動駕駛系統軟件,特別是其視覺感知模塊的安全性．
１.３ 基于搜索的自動駕駛測試
基于搜索的自動駕駛安全性測試的核心思路如下:給定待測自動駕駛系統的輸入空間,定義待測系統的特殊輸入狀態,通過在輸入空間搜索,確定哪些輸入會造成系統輸出特殊狀態,從而實現對輸入空間的劃分．Abdessalem利用搜索算法在輸入空間給輸入打上標簽,同時利用標簽數據訓練分類器,對輸入空間進行了決策邊界的劃分．隨后,他把對少體問題的狀態空間的搜索過程擴展到多體問題狀態空間中的搜索,提出了FITEST搜索測試方法．這樣的方法的局限性在于,分類器的引入隱含假定了輸入空間是局部連續線性的,例如使用決策樹進行劃分時,潛在認為了２個正例狀態之間也是正例狀態．對于AEB系統這樣問題定義在線性域下的系統,分類器的設計是合理的,但是對于具有高度非線性系統的深度學習系統,這樣的方法顯然是不適用的．除此之外,Wicker利用兩者博弈的想法,通過操縱圖片上的像素點,利用蒙特卡洛樹搜索博弈的漸進最優策略,來尋找造成模型出錯的反例．這樣的搜索策略的搜索空間是像素級的,搜索結果不具備在現實中的真實性．
１.４ 基于真實數據的測試方法
基于真實數據的測試方法主要分為２種:１)通過收集大量的用戶駕駛數據來改善其自動駕駛系統的質量,如Tesla;２)實景測試,在真實的公路環境下使用原型車輛進行測試,考慮到安全因素,該方法的測試條件比較嚴格．這些方法除了數據收集的成本較高外,收集到的數據分布也十分有限,這使得測試系統無法檢測出自動駕駛系統在新環境中的安全性;同時過度收集的駕駛數據也存在侵犯用戶隱私的問題．
１.５ 基于生成數據的測試方法
基于生成數據的測試方法主要分為２種:１)基于生成式對抗網絡(generativeadversarialnetworks,GAN),在DepRoad中,考慮將正常天氣的道路場景變換到雨雪天氣下,從而測試系統在雨雪天氣下的安全性,但其生成方法的場景豐富度存在不足,也無法實現場景內容的靈活控制;２)基于實時渲染引擎創建測試場景．Richer利用游戲GTAＧV來創建自動駕駛數據集,Sythia使用Unity引擎合成數據集,CARLA０．８．X使用UnrealEngine創建用于測試系統的駕駛線路．這些工作的問題在于,測試的場景是預先定義好的,不能或只能很有限地對場景進行調整,這樣的工作沒有充分利用實時渲染可以動態調整場景的特點．特別是,使用固定的駕駛場景進行測試,很難對所有可能的場景進行覆蓋．
Scenic設計了一種場景描述語言,可以根據預定義規則生成一些場景用于自動駕駛視覺感知模塊的安全性測試．這種描述語言盡管有很高的自由度,但對場景中非實體的對象刻畫,如天氣和太陽,比較困難,并且難以應用到場景變換的情況．最新的工作是Paracosm提出了一種可編程的自動駕駛測試場景生成方法．該工作通過將場景中的物體和環境參數化并提供了一套編程接口用于測試場景生成,該方法基于隨機搜索的方式進行場景生成并對自動駕駛中視覺感知模塊進行測試．但是考慮到可搜索的參數空間規模十分巨大,因此,很難通過隨機搜索高效地找到感知模塊的安全問題．對此我們在４.１節進行了詳細的比較和評估．
進是采用了更加靈活豐富的場景描述方式,相比于Scenic方法,本方法增添了對非實體對象的描述,使得自動駕駛視覺感知模塊在不同天氣下的安全性也得到充分測試．第２個改進是提出了一套適應性場景搜索算法,相比于Paracosm方法,本文可以實現適應性的動態故障場景搜索,使得自動駕駛視覺感知模塊的安全問題發現效率有了顯著提升．
2、系統設計
本節將介紹針對自動駕駛視覺感知模塊的安全測試系統的具體設計,其中包括安全性測試系統的形式化描述、工作流程、場景描述方法、動態場景生成器以及缺陷分析方法．在此之前,我們在表１中匯總了本文所用的一些關鍵變量．
２.１ 安全性測試系統的形式化描述
自動駕駛系統本質上是一個策略π,在給定環境信息序列O的情況下映射到控制指令A上,即π:OA．其中輸入的環境信息包含相機圖像I和當前車速V;輸出控制指令包含剎車、油門和轉向角,其中剎車可以被看成反向油門,這樣輸出的控制指令可表示為(s,t)．
基于場景搜索的測試系統首先會生成一個具體的場景w∈W,該場景所表示的環境信息為o＝ (w)∈O．給定自動駕駛模型m＝M可以得到車輛
２.２ 安全性測試系統的工作流程
測試系統的架構設計如圖１所示．為了能夠精確控制場景生成,本文設計了一組屬性配置方案,分別用于控制場景中單個對象的屬性和相互關系(２.３節)．１) 動態場景生成器(２.４節)首先讀取配置文件,得到場景中對象的分布函數,并隨機采樣出一個初始場景描述．２) 實時渲染引擎(如UnrealEngine)會根據場景描述渲染出一個可供系統測試的駕駛場景．３) 待測試駕駛模型讀取場景．４) 輸出決策至缺陷分析器進行分析．５) 缺陷分析器(２.５節)會根據模型輸出生成約束,適應性地指導動態場景生成器產生新的場景描述,進行下一輪測試．６) 若缺陷分析器發現待測試系統的安全問題,會自動生成缺陷報告,以供后續的自動駕駛系統改進．下面將對系統中的核心技術和組件進行介紹．
圖1 測試系統的工作流程
２.３ 豐富且真實的場景描述
為了實現豐富且真實的場景描述,我們設計了對象屬性描述文件和環境配置方案,以用于描述實時渲染引擎所需要的資產(asets)屬性、屬性分布和添加新地圖;同時我們對場景中的全部對象進行了參數化描述,以便進行缺陷場景的自動化搜索．
２.３.１對象描述與環境配置
本系統將場景中出現的對象分為５類:
１) 環境E是用于場景生成的預設的基礎道路環境．一個道路環境應該至少包含道路與路邊建筑．為了保證所描述場景的真實性如限定對象出現的合理位置,我們對環境進行了區域劃分．一個典型的環境包含的區域有路外非駕駛區域、行人道、左右車道、十字路口．
２) 天氣W包括太陽高度角、降雨量、霧濃度等,其值是連續變化的．一個基本天氣表示為在某個范圍上的概率分布密度函數．天氣之間可能會有相互作用,帶來聯合概率分布．因此,我們需要為單個場景設置多個天氣分布,并使用聯合概率分布函數進行抽樣．
天氣分布與環境配置相關性很低,若考慮天氣分布與環境的相關性,則直接改變天氣分布更合理,例如干旱地區大雨的概率比潮濕地區小很多;而車輛、行人和靜態物體的分布是依賴環境的．
３) 車輛V是環境中進行碰撞模擬和重力模擬的載具,包括汽車、自行車、摩托車,特別地,從現實角度考慮,自行車、摩托車會額外在載具上加入一個駕駛員．車輛在環境中不同區域出現的概率是不同的;我們也為車輛設置了正常和異常２種狀態,并約束在不同的模式下車輛在各個區域的概率分布．例如,正常情況下車輛無論如何不會出現在人行道或是逆行車道上．
４) 行人P的描述與車輛相似,設計上的差異在于:行人之間不存在類別差別,只有衣服、身材、相貌差別．
５) 靜態物品G是沒有使用碰撞模擬和物理模擬的實體對象．如果不考慮相互作用直接采樣得到初始分布,很有可能產生穿模的問題,因此,我們使用了基于幾何體計算的定向包圍盒(oriented bounding box,OBB)碰撞檢測算法,其思路是將空間中的每個實體對象用OBB包圍起來,通過計算不同實體對象之間的OBB是否重疊來判斷是否發生了碰撞．
具體來說,先將物品投影到地面上,使用OBB代替三維物體進行相交性檢查．同時為了彌補三維物品在垂直地面的維度上的層次丟失,引入圖層的概念(圖２),每個圖層上均存在物體的OBB投影,碰撞檢測時需針對物品的多個圖層同時進行．在場景生成時,會隨機選擇靜態物品,并依次添加到環境當中,若新物體與老物體未發生碰撞,則物品生成有效．
圖2 多圖層投影 OBB
２.３.２ 參數化描述
對于相同的實體對象,由于其在矩陣D所處行不同,故而自然就區分開了．換言之,多個重復對象在我們的表示中用多行表示．
２.４ 動態場景生成器
為了能夠適應性地對測試系統進行安全測試,我們設計了一個動態場景生成器．生成器的使用分為２個階段:１) 場景初始化階段．在每輪測試開始前,動態場景生成器會根據環境配置和對象描述,按照天氣、車輛、行人、靜態物體的順序進行一次抽樣,合成對象的分布函數,生成場景描述．２) 使用階段．動態場景生成器可以根據缺陷分析器的輸出動態地生成下一個用于測試的場景．動態場景生成器的核心是一個適應性的場景搜索算法,該算法可以針對不同的待測系統生成不同的搜索方法,使得測試系統能夠快速穩定地找到待測系統缺陷．
２.４.１ 基于蛻變測試的評估方法
測試預言用于判斷測試中待測系統輸出是否正確．對于自動駕駛系統而言,在某個具體場景下,正確的輸出是難以定義的．這是因為,對于自動駕駛系統,在某個范圍內的輸出都不會造成駕駛錯誤．另外,由于自動駕駛系統控制的車輛本身是物理連續的,單次系統錯誤輸出可能不會造成嚴重的安全后果．因此,采取某個具體值作為測試預言是不合理的．沿用先前的工作,我們采取蛻變測試并且予以松弛的方式作為測試預言．由于不同的測試場景需要的測試預言是不同的,使用我們的測試系統時,可以根據經驗設計不同的預言規則．這里我們給出了２種測試預言:通常深度自動駕駛測試中關注的是輸出轉向角的正確性,因為轉向角往往決定了系統是否會造成危險后果,預言１使用了這樣的設計;但當測試車輛前有車輛,卻因為變換場景造成沒有剎車,此時也應判定自動駕駛系統出了錯,預言２使用了該設計．
２.４.２ 適應性場景搜索算法
本搜索算法有３個設計需求:１) 搜索算法應該是場景合理的,不能超出環境配置和對象描述所定義的合理狀態．２) 搜索到的相鄰２個場景應該是駕駛語義不變的．３) 搜索算法應該是高效的,單次搜索耗時不能太長．
我們通過拒絕采樣的方式保證搜索到的場景的合理性．即,每次變換場景后,都要驗證場景的合理性,如果不符合原本對象屬性文件中定義的分布,則重新變換．駕駛語義不變性是通過控制相機所處車輛前一定距離的對象的位置不變保證的．例如,在自動駕駛車輛前有一輛車將造成車輛的剎車行為,那么在搜索過程中就不應變換這輛車的空間位置,僅可改變方向角和車輛顏色．最后,算法的高效性是通過變步長的隨機搜索設計保證的,在搜索過程中,步長預算是根據上次搜索過程是否被接納選擇進行調整的．算法的細節描述見算法１．
圖３是測試系統進行的一次場景搜索過程示意圖．圖中,紅線框框出的是動態生成的車輛,藍線框是動態生成的行人,綠線框是動態生成的靜態網格體對象,天氣影響了全局的渲染效果,如圖３中的建筑物陰影和樹木的陰影、樹葉的擺動角度等．測試系統通過動態調整這些物體空間位置及其內部屬性,改變渲染畫面,尋找造成故障的場景．
圖3 一次場景搜索示意圖
２.５ 精確且自動的缺陷分析
對于造成示性函數取值為１的場景,缺陷分析器會分析、解釋哪些物體或屬性引發了系統異常．需要說明的是,造成模型輸出異常的緣故是搜索過程的一整條路徑,而非某次具體的迭代過程;對于帶有高度非線性深度學習模塊的系統而言,單純分析路徑很難判斷究竟是什么原因造成了系統異常．
我們通過依次將天氣置零和移除場景中的實體對象來尋找造成自動駕駛系統出現問題的緣由．造成自動駕駛出錯的原因可能是相互耦合的,例如,對面行駛來的車輛由于霧天被識別錯誤造成車輛停止．為了找到造成出錯的一組物體,采取迭代貪心搜索的策略,以δ０為停止標志進行場景搜索．算法細節見算法２．
3、系統實現
３.１待測系統
選取目前最佳的條件自動駕駛系統CILRS作為測試對象,其使用ResNetＧ３４作為圖像特征提取的卷積神經網絡,權重參數為使用CARLA的NoCrash數據集訓練得到的預訓練模型．同時,為了顯示出測試系統在不同自動駕駛系統上的能力,還選擇了基礎的條件自動駕駛系統CIL作為對比的基線．最后,對CIL和CILRS分別進行了封裝,部署到測試系統中．
３.２測試平臺
從預制資產豐富程度和API使用的靈活度的角度出發,本文選擇了CARLA０．９．１１作為測試系統開發平臺．出于便捷導入靜態資產和地圖的目的,我們從源碼編譯Unreal Engine４．２４引擎和CARLA０．９．１１,部署于Windows平臺．運行時,從Unreal Engine編輯器中啟動CARLA以快速迭代構建環境,驗證場景生成算法的正確性．
３.３ 場景搭建
受限于深度學習模型推導效率,通常部署于深度自動駕駛中的CNN網絡的輸入圖像分辨率不會特別高,需要對相機捕獲的數據進行預處理,裁剪出感興趣區域(region of interest,ROI)．在這種情況下,場景中相對路面比較遠的其他部分不會被捕獲到相機畫面中來．但是,比較高或者比較低的道路兩側的建筑的高度實際會影響到道路的光照效果,一定會對自動駕駛系統的預測產生影響．為了測試這種影響,我們設計了３種環境,分別為曠野、鄉村、城市,具有不同的環境物體高度,通過Unreal Engine編輯器創建,如圖４所示:
圖4 ３種環境
選取CARLA０．９．１１默認提供的１０種天氣參數(太陽方位角、太陽高度角、云量、降雨量、積雨量、風強度、空氣濕度、霧濃度、霧距、霧密度)作為測試系統可以調節的天氣參數．其中在不同場景中,太陽方位角和太陽高度角是必須存在的天氣參數．霧濃度、霧距離、霧密度三者之間具有相關性,必須同時存在．
我們對CARLA提供的８９種可有效生成的靜態物體、２８種車輛、２６種行人進行了對象屬性測算．２８種車輛的差異體現在型號帶來的大小、形狀和顏色的差異．２６種行人則包含男性、女性２種性別,年齡分成幼年、青年、老年３個年齡段．在８９種靜態物體中,有一些重復的內容,例如盒子包含６種,但有明顯差異的只有２種,而且有一些物體在我們設計的場景下不應作為可以動態生成在道路和人行道上的內容,例如秋千．最終,選擇全部的２８種車輛和２６種行人以及１５種具有代表性的靜態物體,將測算的數據按照格式要求寫在對象屬性文件中．
實時渲染引擎中需要一個用以控制自動駕駛的車輛和一個捕獲當前場景圖像的相機傳感器,由于CARLA中車輛的物理模擬使用了相同的藍圖作為實現,所以在該平臺上選擇哪種車輛作為控制車輛是無關緊要的．選?。玻阜N車輛中的Tesla Model３作為控制車輛,傳感器選擇普通RGB單眼傳感器,位于相對車輛中心前方１．６m處,相對地面高１．４m,FOV取為１００,畫面分辨率為８００×６００,幀率為２５Hz．相機捕獲的場景畫面如圖５所示:
圖5 鄉村環境中車載相機捕獲的畫面
4、實驗評估
４.１ 安全問題檢測能力對比分析
我們對最新的自動駕駛測試系統Paracosm進行了復現,并使用復現的Paracosm與我們的工作同時對自動駕駛系統CILRS和CIL進行安全性測試．我們選取了CARLA０．９．１１作為Paracosm和本系統的場景生成平臺．考慮到,Paracosm未指定如何設置具體的安全性問題檢出標準,其在未來工作部分討論了與本文類似的測試預言生成思路,但是并未指定具體的方法和參數選擇．故在本節的實驗中,為了實驗的公平性,復現的Paracosm系統和本文一樣,選取了蛻變測試作為測試預言機制,將場景變換前自動駕駛系統輸出的結果視為正確輸出,詳細的設計見３．４節．
對于參數選擇部分,若搜索場景中僅發生了天氣變換,系統會選取預言１作為故障判斷的依據,同時取ε=０．１７,即當車輛相對原始輸出偏轉角超過１５°時認為出現了故障;對包含實體對象的變換情況,系統選取預言２作為故障判斷的依據,在有實體對象的情況下,是否妥善剎車應是故障判斷的標準,同時取ε１=０．１７,取ε２=０．２．對于場景存在實體對象的情況,采用正態分布對實體數量進行抽樣:
我們選取了３種類型的環境,即曠野、鄉村和城市,對CILRS系統和CIL系統分別進行了安全性測試．請注意,３種環境的主要區別在于道路兩側的建筑物高度不同,從而影響自動駕駛車輛上相機中的ROI的光照．將車輛生成于場景中的直道部分,設定車輛的駕駛分支為沿路行駛開始測試．讓這２個測試系統分別在不同類型的環境下動態搜索３００個場景．我們在表２中展示了本工作與Paracosm系統的安全問題檢出率,檢出率的計算方法如式(２)所示．
３個代表性環境的３００次場景搜索中,安全問題發現能力均要優于自動駕駛測試系統Paracosm．整體來看,本工作在２個系統上的安全問題檢出率皆是Paracosm的１．４倍．實驗表明,本系統面向測試對象的適應性搜索算法設計相比于非適應性算法更加高效．
４.２ 安全問題檢測能力具體分析
本節會對本文設計的系統進行詳細的分析．為排除其他因素造成的影響,選擇設計的３個環境中的曠野環境作為測試環境．其實驗參數與４.１節相同．基于該設定分別對CIL和CILRS進行實驗,并針對每個系統進行了１０００輪場景搜索．使用式(２)計算故障率,并將結果列于表３中．
從表３中可以看出,存在實體對象時,場景變換造成的故障率較只有天氣的情況更高．并且在考慮天氣和所有實體對象情況下,我們對CILRS的故障發現率達到了５８.４％．
比較CILRS的實驗結果與CIL的實驗結果,可以發現兩者在只包含天氣的情況下表現相近,而在擁有表示場景擁擠程度的實體對象的情況下,CIL故障發生率高于CILRS．CILRS是在CARLA１００數據集下訓練的,著重解決擁擠場景情況下駕駛系統的正確性預測問題．實驗結果印證了CILRS確實緩解了擁擠場景下自動駕駛系統故障率高的問題．換言之,CILRS的安全性優于CIL．
４.３ 蛻變測試的松弛限
在３.４節的測試預言定義中,使用松弛的蛻變測試來避免采取固定真值測試時,自動駕駛系統測試可能會出現大量假陽性的問題．在５.２節中,使用ε＝０.１７對不包含實體對象的天氣場景進行實驗,使用ε１＝０.１７,ε２＝０.２對包含實體對象的場景進行實驗．這２個值的選取是經驗選取的．本小節通過調整ε進行實驗,從而分析松弛限的取值對實驗結果的影響．
選取CILRS系統的沿路行駛模式,在直道上進行測試,測試系統擁有生成全部實體對象的能力．分別固定ε１＝０.１７和固定ε２＝０.２,每次固定進行１００次實驗,將故障發現率繪在圖６中．
圖6 使用蛻變測試故障發現率與松弛限的關系
圖６中,折線ε１是固定ε２＝０.２時,ε１取值[０,０.５],故障發現率與松弛限的關系．折線ε２是固定ε１＝０.１７時,ε２取值[０,０.５],故障發現率與松弛限的關系．注意當ε＝０時,故障發現率并不為１００％,這是由于ε１與ε２并非同時?。皫淼模?
從圖６中,可以觀察到隨著松弛限逐漸變大,故障發現率不斷下降．如果松弛率比較小,那么系統就會報出大量的假陽性．如果松弛率比較大,那么系統又會忽略可能的危險錯誤．正如前面解釋設計自動駕駛測試預言的困難性,如何折中松弛率是一個很復雜的問題,在DeepTest中使用統計標準差作為松弛限,DeepRoad直接使用經驗取值．根據此圖,ε在０~０.１區間內,隨自身增加,故障發現率下降速度比較快,推測排除了大量的假陽性,而松弛限在０.１~０.２２比較平滑,可以看作一個比較合理的取值范圍．另外,對自動駕駛任務而言,略高的假陽性能夠避免故障場景的錯誤排除,對實際任務并非不可接受．這是自動駕駛任務故障的危害性程度帶來的．
４.４ 場景覆蓋分析
本節從不同的環境、不同的駕駛模式對深度自動駕駛系統進行測試,驗證測試系統的覆蓋能力．
４.４.１ 環境測試
我們提供的３種測試場景,曠野、鄉村和城市的主要區別在于道路兩側的建筑物高度不同,從而影響自動駕駛車輛上相機中的ROI的光照不同．在地圖中的直道區域,分別對CIL和CILRS進行測試,結果列于表４中．
從表４可以得到２個結論:
１) 在曠野、鄉村、城市３個不同的環境下進行測試,故障發現率是比較接近的,這在一方面說明了環境對故障發現率的影響比較小,另一方面印證了我們設計不同環境的依據—自動駕駛中的ROI設計使得自動駕駛系統更關注路面而非道路兩側的環境．
２) 有趣的是,在我們的設想中,低光照環境下的城市,故障發現率應該高于正常光照或者高光照情況下的曠野和鄉村條件,因為按照直覺,夜間駕駛相對白天駕駛更容易出現問題．然而表４的數據與我們預料的結果相反,低光照情況下的故障搜索效率反而低了．通過觀察實驗結果,我們推測在正常光照條件下,自動駕駛車輛的轉向角一方面依賴實體對象,另一方面依賴道路中心的雙黃線．一旦雙黃線部分被遮蔽后,就很有可能造成駕駛輸出故障．在低光照情況下,雙黃線始終被遮蔽,這就使得駕駛輸出主要依賴場景中的其他實體對象．由前文可知,我們設計的駕駛語義保持的方式使得決定駕駛語義變化區域的實體對象沒有改變,這樣反而使得故障的搜索能力減弱了．
４.４.２駕駛模式測試
在條件自動駕駛系統中,除車載相機拍到的圖像外,高層的控制指令決定了當前駕駛動作應采取的分支動作．而自動駕駛系統有４個駕駛模式,即沿路行駛、向左、向右和直行．我們在不同的場景中分別選擇了直路來測試沿路行駛模式,選擇十字路口分別測試向左、向右和直行３種指令．注意,在地圖的不同位置進行測試時,場景初始化器需要根據區域配置重新合成對象分布進行抽樣以適應車載相機實際的FOV．測試結果見表５．可以看到,在不同分支的情況下,CILRS的安全性均優于CIL．
４.５ CILRS駕駛系統脆弱性分析
２.５節介紹了如何對測試系統發現的安全性問題進行進一步解釋．本節中,將以CILRS系統為例,通過回答如下問題來展示測試系統的自動化測試能力．
問題１．哪些天氣更容易造成CILRS系統出現故障?
使用缺陷分析器將擁有所有對象控制能力的實驗中的天氣逐個置零,確定哪些天氣更容易造成自動駕駛系統發生故障．由于不同天氣是通過采樣得到的,采樣得到的數量不同,故而使用造成故障的天氣相對該天氣出現次數的比值作為對比值,將結果顯示在圖７中,注意,天氣可能只是造成故障的原因之一,不一定是決定因素．
圖7 天氣造成 CILRS系統故障的比例
缺陷分析器給出的造成故障的原因可能是多個對象,故而該圖中總和大于１００％．從圖７中可以看出,造成路面信息模糊(特別是道路標志模糊)的積雨最容易造成自動駕駛系統的不穩定．隨之是干擾了相機傳感器畫面的降雨．風的強度主要影響到了降雨的雨水飄落的傾斜程度和道路兩側樹葉的吹動,后者屬于環境內容,根據在表４給出的結果,其對自動駕駛系統的影響并不突出．可見CILRS系統在這些天氣條件中,最易受到降雨環境的干擾．
問題２．哪些區域是CILRS駕駛系統的關鍵區域?
將深度自動駕駛的關鍵區域定義為,當這個區域出現實體對象時,自動駕駛的輸出更容易出現不穩定性．對先前在直道上進行測試,存在實體對象的實驗結果進行分析．首先,搜索到的造成故障的場景和原始場景會一并交給缺陷分析器進行處理,分析出造成故障的物體．接著,把故障物體的區域繪在圖８中,橫坐標是在沿道路方向的x軸,縱坐標是道路切向方向的y軸．在我們的設置中,自動駕駛車輛的坐標為(０,－２.２７)．圖８的統計結果顯示CILRS系統的敏感區域在道路兩側的人行道上．
圖8 CILRS駕駛系統的關鍵區域
問題３．哪些物體更容易造成CILRS系統出現故障?
將造成系統故障的物體相對其采樣次數的比值用作比較物體造成CILRS系統故障的概率的標準．去除重復物體,取錯誤率最高的５個實體對象,將對象及其故障率列在表６中．
通過圖８和表６,可以發現２點:
１) 位于道路上的車輛可能不是造成不穩定性的主要原因,相反,處于道路兩側人行道上的物體可能更容易造成自動駕駛系統的不穩定．觀察CARLA１００數據集,我們發現自動駕駛系統針對復雜道路條件進行了訓練,忽略了人行道上物體的復雜性．
２) 黃色與紅色是CILRS系統的敏感顏色．這是很自然的,因為交通信號燈的顏色恰好是黃色和紅色,當人行道上出現黃色或者紅色物體時,CILRS很有可能將其誤判成信號燈．
測試系統發現的CILRS的脆弱性正是CILRS優化的方向,可以使用本文測試系統在網絡訓練后校驗系統的安全性．網絡優化方案可以是數據增強、結構優化等,優化后再次使用測試系統進行校驗可以確定深度網絡是否滿足了安全性需求．例如對CILRS系統,建議增加雨天天氣、更豐富的道路兩側場景的訓練數據以,提高系統的穩定性,設計雙保險機制緩解對黃色、紅色物體的敏感性．
４.６ 特征分析與啟發
為了進一步分析造成CILRS系統故障的原因,我們打開了CILRS系統,觀察ResNet的特征提取層．我們發現,大多數情況下搜索到的故障場景和原場景的特征提取結果雖然有所差異,但差異不是特別明顯,在一系列分析過程中,我們發現了一個有趣的樣例,即身穿紅色衣服的行人在人行道上行走．
如圖９所示,設置環境在曠野上,車輛位于直行道路區域上,使用沿路行駛模式進行測試,此時車速為４(歸一化數值),一個身穿紅色衣服的行人在右側人行道的中央位置沿著人行道向前走．自動駕駛車輛停留在初始位置,根據行人所處的不同位置,可以得到CILRS系統預測的輸出的變化,將其畫在圖１０中．
圖9 故障分析樣例:身穿紅色衣服的行人在道路旁行走
圖10 CILRS系統輸出隨行人位置的變化
根據圖１０可以看到,行人出現前,CILRS系統輸出比較穩定．而在行人開始出現時,CILRS系統受到了影響和波動,然而始終處于故障范圍之外．大約在車輛中心位置前７.５m處,預測輸出變為猛踩剎車(剎車效應優先于轉向效應)．隨后自動駕駛系統的輸出仍處于波動狀態,直到行人遠離后車輛輸出才趨向穩定(bias＜０．１)．這樣的表現顯然是不正常的,當行人距離車比較近的時候,如果CILRS判定此時應剎車,則應立即輸出剎車,不應該在行人繼續向前走之后才輸出剎車．將沒有行人和行人在相對車輛中心位置前面７.５m處時的相機輸入及CILRS卷積層前３層輸出的繪在圖１１中．作為對比,將一張長椅放在位于人行道上造成自動駕駛系統輸出變化最大的位置,此時自動駕駛輸出相對不存在任何物體時的偏移ster_bias＝０.０３０＜０.１７,throtle_bias＝０.０５＜０.２,不會被判定為系統故障．圖１１中,有長椅的場景第３層卷積輸出的結果與不存在任何物體的場景的卷積輸出的結果比較相似,而行人所出現的場景卷積輸出和不存在任何物體的場景的卷積輸出有明顯差異．
圖１１中,前２列在原始畫面和特征提取前２層畫面有明顯差異,然而在第３層卻比較相近．第１列和第３列原始畫面和前３層都有很大的差異．這說明盡管畫面中相同位置都出現了物體,但特征提取出來的內容是不同的．這啟發我們或許可以在某一或某些特征層設置監控器,通過監控器的變化分析提前預警系統是否會發生故障．
圖11 CILRS輸入及卷積層輸出
４.７ 系統運行效率分析
本小節對測試系統的運行效率進行分析．部署測試系統的硬件平臺為AMDR５３６００X＋RTX３０７０,使用的軟件平臺為Windows１０＋Unreal Engine４.２４.３＋CARLA０.９.１１＋Python３.９.１．
將動態場景生成器根據初始場景搜索到一個造成自動駕駛系統出錯的場景或是超出迭代預算的用時定義為一次測試用時．在考慮所有實體對象,對象數量根據正態分布采樣得到,包含渲染過程的情況下,一次實驗的平均用時為１６.８６s．排除渲染過程,采用分模塊測試取平均值的方式,對每個模塊及其內部細節進行效率的測試,結果見表７．
與十幾秒的單次實驗耗時相比,各個模塊內部耗時是很低的,系統主要的性能瓶頸在渲染效率上．
5、結論
為了保障車聯網場景下的自動駕駛系統安全性,本文設計并實現了一套場景驅動的針對自動駕駛視覺感知模塊的安全測試系統．該系統構建了一套真實且豐富的場景描述方法,極大地拓展了測試系統的數據分布;本系統可以動態地為不同自動駕駛模型產生安全測試方案,可以實現高效、穩定地發現安全缺陷;最后本系統設計了一套精細的自動化安全問題分析工具,該工具可以幫助自動駕駛開發人員快速定位系統的安全性問題．我們相信,本工作將啟發更多的自動駕駛感知模塊的測試方案,會為車聯網場景下的自動駕駛領域提供重要的安全基礎．
來源：智能汽車開發者平臺 作者：吳昊，王浩，蘇醒，李明昊，許封元，仲盛
作者貢獻聲明：吳昊負責論文撰寫和解決方案設計;王浩負責系統設計和實現;蘇醒負責系統實現和實驗;李明昊負責實驗和結果分析;許封元定義問題及修改論文;仲盛負責把控研究方向和修改論文．
