自動駕駛系統(tǒng)中視覺感知模塊的安全測試

吳 昊 王 浩 蘇 醒 李明昊 許封元 仲 盛

(計算機軟件新技術國家重點實驗室(南京大學) 南京 210023)

車聯(lián)網(wǎng)領域隨著物聯(lián)網(wǎng)與交通運輸領域的深度融合蓬勃發(fā)展.深度學習的進步使車聯(lián)網(wǎng)領域的自動駕駛技術得到了突破性的發(fā)展，并有演化成一場新的汽車工業(yè)革命的趨勢[1-4].無論是特斯拉、蔚來等新型車企，還是福特、寶馬等傳統(tǒng)車企都陸續(xù)拿到了自動駕駛路測牌照，著眼于研發(fā)深度自動駕駛技術.迅猛發(fā)展的深度自動駕駛技術正逐漸成為車聯(lián)網(wǎng)領域的主要支撐技術之一，正在改變未來的交通和出行方式.

視覺感知模塊是自動駕駛進行環(huán)境感知的重要組件，也是車輛進行智能決策的重要基礎[5].自動駕駛領域的重要企業(yè)特斯拉更是將視覺感知模塊作為其駕駛系統(tǒng)的唯一環(huán)境感知模塊.因此，自動駕駛系統(tǒng)視覺感知模塊的安全性是自動駕駛系統(tǒng)正常工作的關鍵.雖然視覺感知模塊的表現(xiàn)隨著深度視覺技術的發(fā)展穩(wěn)步提升，但是其從駕駛環(huán)境中感知到的特征語義難被理解、決策過程無法解釋.如何對自動駕駛系統(tǒng)視覺感知模塊的安全性進行充分測試，已經(jīng)成了一個迫在眉睫、亟待解決的問題[6].

誠然，圍繞深度學習可解釋性方面的工作有了一定的突破，但是距離分析清楚自動駕駛視覺感知模塊的錯誤傳導機理還有較遠的距離.近年來，神經(jīng)網(wǎng)絡的黑盒攻擊方法[7-8]的進步，啟發(fā)大家提出了一些基于場景搜索的自動駕駛視覺感知模塊安全性測試技術.這些場景驅(qū)動的測試方法利用黑盒測試的思路，為駕駛系統(tǒng)提供盡可能多的駕駛場景數(shù)據(jù)，觀察自動駕駛系統(tǒng)的輸出與測試預言(test oracle)之間的差異，進而分析自動駕駛系統(tǒng)視覺感知模塊的安全性.

我們認為場景驅(qū)動的黑盒安全測試是在弄清深度學習可解釋性之前，對于視覺感知模塊安全性最為重要的測試手段.但目前對于將生成場景應用于視覺感知模塊的測試，仍面臨著3個挑戰(zhàn)：

1) 平衡場景描述的真實性與豐富度.場景生成規(guī)則是場景驅(qū)動的測試系統(tǒng)的重要基礎.保守的規(guī)則設計會造成場景覆蓋能力不足；而過于靈活的規(guī)則設計又會破壞物體相對關系，傷害場景真實性.探究一個能同時兼顧場景真實性和豐富度[9-10]的場景生成規(guī)則極具挑戰(zhàn)性.

2) 保證搜索算法的高效性和穩(wěn)定性.單個物體的屬性(如顏色、形狀)與物體間的相互關系(如位置、方向)組合十分復雜.為了能夠高效穩(wěn)定地測試系統(tǒng)安全性缺陷，需要：①動態(tài)地針對不同自動駕駛系統(tǒng)視覺感知模塊產(chǎn)生個性化的場景搜索方案，以保證搜索過程的步驟較少；②盡可能縮短單步搜索的時間.

3) 解釋測試結果的精確性與自動化.以往測試系統(tǒng)需要人工介入分析缺陷原因.若想做到自動化地分析測試結果，系統(tǒng)需要能夠精細地操縱場景中每個元素來定位系統(tǒng)安全性缺陷的成因.

圍繞場景驅(qū)動的視覺感知模塊的黑盒安全測試，學術界已經(jīng)有了初步探索.在場景測試方法當中，基于實時渲染引擎的一系列測試方法由于其場景生成的靈活性受到了廣泛關注.最初，基于實時渲染引擎的場景驅(qū)動安全測試系統(tǒng)采用預定場景的測試思路.其中的代表性工作是CARLA 0.8.X[11]，該工作使用Unreal Engine創(chuàng)建用以測試系統(tǒng)的固定駕駛線路.接著，Scenic[12]提出了一種場景生成的編程接口，以使此類測試程序更加系統(tǒng)化，奠定了靜態(tài)的基于場景測試的基礎.然而，其模擬環(huán)境較為固定，缺乏動態(tài)行為，同時對于非實體對象(如天氣)的描述缺少自由度.基于實時渲染引擎的場景驅(qū)動的安全測試的最新工作，Paracosm[13]在Scenic的基礎上，提出了基于隨機搜索的動態(tài)場景生成方法來進行視覺感知模塊的安全測試.由于該動態(tài)場景搜索方法相對簡單，對待測試視覺感知模塊的適應性不足，因此，安全問題的搜索過程不夠高效.本文在前述工作的基礎上，提出了一種基于結果反饋的動態(tài)場景搜索算法，從而提高了自動駕駛系統(tǒng)中視覺感知模塊的安全問題測試效率.更多細節(jié)將在1.5節(jié)詳細介紹.

本文工作中，類比深度學習黑盒攻擊策略，借助實時渲染引擎的開放度，設計并提出了一套可靠且具有可解釋性的自動駕駛視覺感知模塊安全性測試系統(tǒng).本文主要的貢獻有3個方面：

1) 針對車聯(lián)網(wǎng)場景下自動駕駛系統(tǒng)感知模塊的安全問題，提出并設計了一套場景驅(qū)動的黑盒安全性測試系統(tǒng).與現(xiàn)有工作相比，該系統(tǒng)引入基于結果反饋的動態(tài)化測試策略，通過自適應機制在循環(huán)中不斷調(diào)整輸入數(shù)據(jù)的生成，實現(xiàn)對感知模塊高效、穩(wěn)定的非入侵式安全測試.

2) 面向自動駕駛視覺感知模塊的動態(tài)測試新需求，設計了細粒度場景描述方法、適應性動態(tài)搜索算法和自動化系統(tǒng)缺陷分析的動態(tài)測試技術，從測試粒度、反饋自適和可解釋性3個方面對提出的黑盒安全性測試系統(tǒng)進行了優(yōu)化.

3) 以2個具有代表性的開源自動駕駛系統(tǒng)為對象開展了測試系統(tǒng)的驗證，分別動態(tài)生成了3 000個場景，并各自找到了1 939個和1 671個故障場景，平均每16.86 s可發(fā)現(xiàn)一個故障場景.實驗表明，得益于動態(tài)自適的場景搜索方法，本文工作的安全問題發(fā)現(xiàn)率是現(xiàn)有基于實時渲染引擎的場景驅(qū)動的動態(tài)測試方向中最好工作的1.4倍.

1 相關工作

1.1 基于神經(jīng)元覆蓋的自動駕駛測試

神經(jīng)元覆蓋是類比傳統(tǒng)程序的分支覆蓋而設計的.此類工作定義當測試輸入經(jīng)過神經(jīng)元使神經(jīng)元輸出滿足某種狀態(tài)時，該神經(jīng)元則稱被測試樣例覆蓋(激活)了.此類工作以最大化神經(jīng)元覆蓋為優(yōu)化目標，來尋找輸入樣例.自DeepXplore[14]引入神經(jīng)元覆蓋的概念并成功應用于基于視覺的深度自動駕駛領域后，已有大量關于神經(jīng)元覆蓋的工作出現(xiàn)，提出了各式各樣的覆蓋標準，并成功使傳統(tǒng)軟件測試方法如蛻變測試、模糊測試、符號測試等遷移到深度學習測試任務中[15-22].然而，這種類比屬于一種機械類比，神經(jīng)元輸出值的狀態(tài)與傳統(tǒng)軟件測試中的分支是完全不同的概念，因而這種類比方法的有效性始終受到人們的質(zhì)疑[23].并且，基于神經(jīng)元覆蓋的設計也難以給出基于語義的測試樣例故障原因，不利于自動駕駛系統(tǒng)安全性的進一步提升.

1.2 基于錯誤注入的自動駕駛測試

Avfi[24]使用軟件故障注入模擬自動駕駛系統(tǒng)的硬件故障，以測試系統(tǒng)的容錯性.隨后DriveFI[25]使用Apollo和DriveAV在CARLA模擬器和DriveSim上進行實驗，利用貝葉斯網(wǎng)絡模擬自動駕駛系統(tǒng)加速錯誤注入后的驗證過程，能最大限度地挖掘出影響自動駕駛系統(tǒng)的故障.Kayotee[26]在Avfi和DriveFI工作的基礎上，添加了描述誤差傳播的能力，并且能直接注入CPU和GPU的位翻轉.這些工作是從容錯性的角度考察自動駕駛系統(tǒng)的特性的，而且實際考察的是自動駕駛系統(tǒng)的硬件故障.這類工作與本文工作討論的場景和問題是正交的，本文工作研究的是自動駕駛系統(tǒng)軟件，特別是其視覺感知模塊的安全性.

1.3 基于搜索的自動駕駛安全性測試

基于搜索的自動駕駛安全性測試的核心思路是在Avfi和DriveFI工作的基礎上：給定待測自動駕駛系統(tǒng)的輸入空間，定義待測系統(tǒng)的特殊輸入狀態(tài)，通過在輸入空間搜索，確定哪些輸入會造成系統(tǒng)輸出特殊狀態(tài)，從而實現(xiàn)對輸入空間的劃分.Abdessalem等人利用搜索算法在輸入空間給輸入打上標簽，同時利用標簽數(shù)據(jù)訓練分類器，對輸入空間進行了決策邊界的劃分[27-28].隨后，他把對少體問題的狀態(tài)空間的搜索過程擴展到多體問題狀態(tài)空間中的搜索，提出了FITEST搜索測試方法[29].這種方法的局限性在于，分類器的引入隱含假定了輸入空間是局部連續(xù)線性的，例如使用決策樹進行劃分時，潛在認為2個正例狀態(tài)之間也是正例狀態(tài)[21].對于 AEB系統(tǒng)這種問題定義在線性域下的系統(tǒng)，分類器的設計是合理的，但是對于具有高度非線性系統(tǒng)的深度學習系統(tǒng)，這樣的方法顯然是不適用的.除此之外，Wicker利用兩者博弈的想法[30]，通過操縱圖片上的像素點，利用蒙特卡洛樹搜索博弈的漸近最優(yōu)策略，來尋找造成模型出錯的反例.這種搜索策略的搜索空間是像素級的，搜索結果不具備在現(xiàn)實中的真實性.

1.4 基于真實數(shù)據(jù)的測試方法

基于真實數(shù)據(jù)的測試方法主要分為2種：1)通過收集大量的用戶駕駛數(shù)據(jù)來改善其自動駕駛系統(tǒng)的質(zhì)量，如Tesla[31]；2)實景測試[32]，在真實的公路環(huán)境下使用原型車輛進行測試，考慮到安全因素，該方法的測試條件比較嚴格[33].這些方法除數(shù)據(jù)收集的成本較高外，收集到的數(shù)據(jù)分布也十分有限，這使得測試系統(tǒng)無法檢測出自動駕駛系統(tǒng)在新環(huán)境中的安全性；同時過度收集的駕駛數(shù)據(jù)也存在侵犯用戶隱私的問題.

1.5 基于生成數(shù)據(jù)的測試方法

基于生成數(shù)據(jù)的測試方法主要分為2種：1)基于生成式對抗網(wǎng)絡(generative adversarial network, GAN)[34-39].在DeepRoad[34]中，考慮將正常天氣的道路場景變換到雨雪天氣下，從而測試系統(tǒng)在雨雪天氣下的安全性，但其生成方法的場景豐富度存在不足，也無法實現(xiàn)場景內(nèi)容的靈活控制.2)基于實時渲染引擎創(chuàng)建測試場景.Richer利用游戲GTA-V來創(chuàng)建自動駕駛數(shù)據(jù)集[40-41],Sythia[42]使用 Unity引擎合成數(shù)據(jù)集，CARLA 0.8.X[11]使用Unreal Engine創(chuàng)建用于測試系統(tǒng)的駕駛線路.這些工作的問題在于，測試的場景是預先定義好的，不能或只能很有限地對場景進行調(diào)整，這樣的工作沒有充分利用實時渲染可以動態(tài)調(diào)整場景的特點.特別是，使用固定的駕駛場景進行測試，很難對所有可能的場景進行覆蓋.

Scenic[12]設計了一種場景描述語言，可以根據(jù)預定義規(guī)則生成一些場景用于自動駕駛視覺感知模塊的安全性測試.這種描述語言盡管有很高的自由度，但對場景中非實體的對象刻畫，如天氣和太陽，比較困難，并且難以應用到場景變換的情況.最新的工作Paracosm[13]提出了一種可編程的自動駕駛測試場景生成方法.該工作通過將場景中的物體和環(huán)境參數(shù)化并提供了一套編程接口用于測試場景生成，該方法基于隨機搜索的方式進行場景生成并對自動駕駛中的視覺感知模塊進行測試.但是考慮到可搜索的參數(shù)空間規(guī)模十分巨大，因此，很難通過隨機搜索高效地找到感知模塊的安全問題.對此我們在4.1節(jié)進行了詳細的比較和評估.

本文工作延續(xù)了基于生成數(shù)據(jù)的測試方法的研究思路，基于實時渲染引擎生成真實度高的場景來進行系統(tǒng)的安全性測試.相比于以往的工作，我們有2個顯著改進：1)采用了更加靈活豐富的場景描述方式，相比于Scenic方法，本文工作增添了對非實體對象的描述，使自動駕駛視覺感知模塊在不同天氣下的安全性也得到充分測試.2)提出了一套適應性場景搜索算法，相比于Paracosm方法，本文工作可以實現(xiàn)適應性的動態(tài)故障場景搜索，使得自動駕駛視覺感知模塊的安全問題發(fā)現(xiàn)效率有了顯著提升.

2 系統(tǒng)設計

本節(jié)將介紹針對自動駕駛視覺感知模塊的安全測試系統(tǒng)的具體設計，包括：安全性測試系統(tǒng)的形式化描述、工作流程、場景描述方法、動態(tài)場景生成器以及缺陷分析方法.表1中匯總了本文所用的一些關鍵變量.

Table 1 Summary of Notations in Our Approach

2.1 安全性測試系統(tǒng)的形式化描述

自動駕駛系統(tǒng)本質(zhì)上是一個策略π，在給定環(huán)境信息序列O的情況下映射到控制指令A上，即π:O→A.其中輸入的環(huán)境信息包含相機圖像I和當前車速V；輸出控制指令包含剎車、油門和轉向角，其中剎車可以被看成反向油門，這樣輸出的控制指令可表示為(s,t).

(1)

來確定模型當前輸出的動作a是否會造成出錯.

定義場景搜索算法L∈L，其能夠基于一個預定的場景w，以令δ=1為目標，生成一個場景w′.對于一個確定的待測試模型m，把L(m,·)簡記成Lm(·).可以使用算法L度量自動駕駛系統(tǒng)m的故障率：

(2)

也可稱為模型m在算法L的δ測試表現(xiàn)，Err(m;L;δ).

2.2 安全性測試系統(tǒng)的工作流程

測試系統(tǒng)的架構設計如圖1所示.為了能夠精確控制場景生成，本文設計了一組屬性配置方案，分別用于控制場景中單個對象的屬性和相互關系(2.3節(jié)).1)動態(tài)場景生成器(2.4節(jié))首先讀取配置文件，得到場景中對象的分布函數(shù)，并隨機采樣出一個初始場景描述.2)實時渲染引擎(如Unreal Engine)會根據(jù)場景描述渲染出一個可供系統(tǒng)測試的駕駛場景.3)待測試駕駛模型讀取場景.4)輸出決策至缺陷分析器進行分析.5)缺陷分析器(2.5節(jié))會根據(jù)模型輸出生成約束，適應性地指導動態(tài)場景生成器產(chǎn)生新的場景描述，進行下一輪測試.6)若缺陷分析器發(fā)現(xiàn)待測試系統(tǒng)的安全問題，會自動生成缺陷報告，以供后續(xù)的自動駕駛系統(tǒng)改進.

Fig. 1 The workflow of the testing system圖1 測試系統(tǒng)的工作流程

2.3 豐富且真實的場景描述

為了實現(xiàn)豐富且真實的場景描述，我們設計了對象屬性描述文件和環(huán)境配置方案，用于描述實時渲染引擎所需要的資產(chǎn)(assets)屬性、屬性分布和添加新地圖；同時對場景中的全部對象進行了參數(shù)化描述，以便進行缺陷場景的自動化搜索.

2.3.1 對象描述與環(huán)境配置

本系統(tǒng)將場景中出現(xiàn)的對象分為5類：

1) 環(huán)境E是用于場景生成的預設的基礎道路環(huán)境.一個道路環(huán)境應該至少包含道路與路邊建筑.為了保證所描述場景的真實性如限定對象出現(xiàn)的合理位置，我們對環(huán)境進行了區(qū)域劃分.一個典型的環(huán)境包含的區(qū)域有路外非駕駛區(qū)域、人行道、左右車道、十字路口.

2) 天氣W包括太陽高度角、降雨量、霧濃度等，其值是連續(xù)變化的.一個基本天氣表示為在某個范圍內(nèi)的概率分布密度函數(shù).天氣之間可能會有相互作用，帶來聯(lián)合概率分布.因此，需要為單個場景設置多個天氣分布，并使用聯(lián)合概率分布函數(shù)進行抽樣.

天氣分布與環(huán)境配置相關性很低，若考慮天氣分布與環(huán)境的相關性，則直接改變天氣分布更合理，例如干旱地區(qū)下大雨的概率比潮濕地區(qū)小很多；而車輛、行人和靜態(tài)物體的分布是依賴環(huán)境的.

3) 車輛V是環(huán)境中進行碰撞模擬和重力模擬的載具，包括汽車、自行車、摩托車，特別地，從現(xiàn)實角度考慮，自行車、摩托車會額外在載具上加入一個駕駛員.車輛在環(huán)境中不同區(qū)域出現(xiàn)的概率是不同的，我們也為車輛設置了正常和異常2種狀態(tài)，并約束在不同的模式下車輛在各個區(qū)域的概率分布.例如，正常情況下車輛無論如何不會出現(xiàn)在人行道或是逆行車道上.

4) 行人P的描述與車輛相似，設計上的差異在于行人之間不存在類別差別，只有衣服、身材、相貌差別.

5) 靜態(tài)物品G是沒有使用碰撞模擬和物理模擬的實體對象.如果不考慮相互作用直接采樣得到初始分布，很有可能產(chǎn)生穿模的問題，因此，我們使用了基于幾何體計算的定向包圍盒(oriented bounding box, OBB)碰撞檢測算法，其思路是將空間中的每個實體對象用OBB包圍起來，通過計算不同實體對象之間的OBB是否重疊來判斷是否發(fā)生了碰撞[43].

具體來說，先將物品投影到地面上，使用OBB代替三維物體進行相交性檢查.同時，為了彌補三維物品在垂直地面的維度上的層次丟失，引入如圖2所示的圖層的概念，每個圖層上均存在物體的OBB投影，做碰撞檢測時需針對物品的多個圖層同時進行.在場景生成時，會隨機選擇靜態(tài)物品，并依次添加到環(huán)境當中，若新物體與老物體未發(fā)生碰撞，則物品生成有效.

Fig. 2 Multi-layer projection OBB圖2 多圖層投影OBB

2.3.2 參數(shù)化描述

為了能夠便捷地進行場景搜索以及保持系統(tǒng)多個模塊之間概念的一致性，對場景設計了參數(shù)化描述方案.WE(Q,D)用來表示場景的參數(shù)：E為環(huán)境的參數(shù)表示，其在一次測試過程中是一個定值；Q為天氣的參數(shù)表示；D為實體對象的參數(shù)表示.

天氣Q可以被表示為一個長度為n的具名元組，元組中的每一項為從W選擇的天氣與其對應的強度.Q={q1:x1,q2:x2,…,qn:xn}，其中qi是天氣的名字，xi是天氣的具體取值，且處于定義的天氣要求的范圍內(nèi).

實體對象D包括車輛V、行人P和靜態(tài)物品G，這些對象無須區(qū)分，可被統(tǒng)一化處理.對于一個場景，本系統(tǒng)挑選共計m個實體對象進行創(chuàng)建，使用一個大小為m×8的矩陣表示實體狀態(tài)

(3)

其中，ni表示挑選的實體對象的名字，ai表示這個實體對象所取屬性離散值在屬性集合中的索引.坐標(x,y,z)是物體在實時渲染引擎創(chuàng)建的空間中的坐標；方向角(r,p,q)是物體語義正面法向量在渲染引擎坐標系下的歐拉角.

對于相同的實體對象，由于其在矩陣D所處行不同，故而自然就區(qū)分開了.換言之，多個重復對象在我們的表示中用多行表示.

2.4 動態(tài)場景生成器

為了能夠適應性地對測試系統(tǒng)進行安全測試，我們設計了一個動態(tài)場景生成器.生成器的使用分為2個階段：1)場景初始化階段.在每輪測試開始前，動態(tài)場景生成器會根據(jù)環(huán)境配置和對象描述，按照天氣、車輛、行人、靜態(tài)物體的順序進行一次抽樣，合成對象的分布函數(shù)，生成場景描述.2)使用階段.動態(tài)場景生成器可以根據(jù)缺陷分析器的輸出動態(tài)地生成下一個用于測試的場景.動態(tài)場景生成器的核心是一個適應性的場景搜索算法，該算法可以針對不同的待測系統(tǒng)生成不同的搜索方法，使得測試系統(tǒng)能夠快速穩(wěn)定地找到待測系統(tǒng)缺陷.

2.4.1 基于蛻變測試的評估方法

測試預言用于判斷測試中待測系統(tǒng)輸出是否正確.對于自動駕駛系統(tǒng)而言，在某個具體場景下，正確的輸出是難以定義的.這是因為，對于自動駕駛系統(tǒng)，在某個范圍內(nèi)的輸出都不會造成駕駛錯誤.另外，由于自動駕駛系統(tǒng)控制的車輛本身是物理連續(xù)的，單次系統(tǒng)錯誤輸出可能不會造成嚴重的安全后果.因此，采用某個具體值作為測試預言是不合理的.沿用先前的工作[11]，我們采用蛻變測試并且予以松弛的方式作為測試預言.由于不同的測試場景需要的測試預言是不同的，使用我們的測試系統(tǒng)時，可以根據(jù)經(jīng)驗設計不同的預言規(guī)則.這里我們給出了2種測試預言：通常深度自動駕駛測試中關注的是輸出轉向角的正確性，因為轉向角往往決定了系統(tǒng)是否會造成危險后果，預言1使用了這樣的設計；但當測試車輛前有車輛，卻因為變換場景造成沒有剎車，此時也應判定自動駕駛系統(tǒng)出了錯，預言2使用了該設計.

2.4.2 適應性場景搜索算法

本搜索算法有3個設計需求：1)搜索算法應該是場景合理的，不能超出環(huán)境配置和對象描述所定義的合理狀態(tài)；2)搜索到的相鄰2個場景應該是駕駛語義不變的；3)搜索算法應該是高效的，單次搜索耗時不能太長.

一是做好頂層設計。將節(jié)水優(yōu)先全面落實到規(guī)劃、取水許可、計劃用水、水量分配、延續(xù)取水、定額管理等水資源管理全過程；編制流域節(jié)水行動方案并全面實施，助推流域形成節(jié)約資源的空間格局、產(chǎn)業(yè)結構、生產(chǎn)方式、生活方式，加快推進集約用水的方式轉變，提高用水效率，減少廢污水排放，全面推進節(jié)水減污型社會建設。

我們通過拒絕采樣的方式保證搜索到的場景的合理性，即每次變換場景后，都要驗證場景的合理性，如果不符合原本對象屬性文件中定義的分布，則重新變換.駕駛語義不變性是通過控制相機所處車輛前一定距離的對象的位置不變保證的.例如，在自動駕駛車輛前有一輛車將造成車輛的剎車行為，那么在搜索過程中就不應變換這輛車的空間位置，僅可改變方向角和車輛顏色.最后，算法的高效性是通過改變步長的隨機搜索設計保證的，在搜索過程中，步長預算是根據(jù)上次搜索過程是否被接納選擇進行調(diào)整的.算法的細節(jié)描述見算法1.

算法1.適應性場景搜索算法.

輸入：初始場景描述w、搜索步長ε、變化維數(shù)Nd、迭代輪數(shù)預算Nt、示性函數(shù)δ、接口封裝好的自動駕駛系統(tǒng)m、在實際渲染引擎中創(chuàng)建的傳感器φ；

輸出：搜索到的新場景wf.

/*初始化場景、控制以及搜索輪數(shù)*/

② for each iterationi≤Nt

④RVQ←randomWeather(n)；

⑤RVD←randomEntity(Nd-n)；/*生成

一個符合分布的Nd維隨機向量*/

/*控制搜索步長為ε*/

⑦RVQ,RVD←RVQ×scale,RVD×scale；

⑧Q′,D′←將RVQ,RVD附加到Q,D上；

⑨w′←(E,Q′,D′)；/*生成新的場景，如果天氣等參數(shù)超出閾值或者未通過碰撞檢測，重新生成*/

⑩a←m(φ(w′))；

圖3是測試系統(tǒng)進行的一次場景搜索過程示意圖.圖中，紅線框框出的是動態(tài)生成的車輛，藍線框是動態(tài)生成的行人，綠線框是動態(tài)生成的靜態(tài)網(wǎng)格體對象，天氣影響了全局的渲染效果，如圖3中的建筑物陰影和樹木的陰影、樹葉的擺動角度等.測試系統(tǒng)通過動態(tài)調(diào)整這些物體空間位置及其內(nèi)部屬性，改變渲染畫面，尋找造成故障的場景.

Fig. 3 Schematic diagram of the scene search圖3 一次場景搜索示意圖

2.5 精確且自動的缺陷分析

對于造成示性函數(shù)取值為1的場景，缺陷分析器會分析、解釋哪些物體或?qū)傩砸l(fā)了系統(tǒng)異常.需要說明的是，造成模型輸出異常的緣故是搜索過程的一整條路徑，而非某次具體的迭代過程；對于帶有高度非線性深度學習模塊的系統(tǒng)而言，單純分析路徑很難判斷究竟是什么原因造成了系統(tǒng)異常.

我們通過依次將天氣置零和移除場景中的實體對象來尋找造成自動駕駛系統(tǒng)出現(xiàn)問題的緣由.造成自動駕駛出錯的原因可能是相互耦合的，例如，對面行駛來的車輛由于霧天被識別錯誤造成車輛停止.為了找到造成出錯的一組物體，采取迭代貪心搜索的策略，以δ=0為停止標志進行場景搜索.算法細節(jié)見算法2.

算法2.自動化缺陷分析算法.

輸出：造成故障的天氣或?qū)嶓w對象R.

①w←wf,a←m(φ(w));

/*初始化場景以及控制*/

③weights←[]；

④ forobjectinw

⑤ if 移除object會影響駕駛語義

⑥ continue；

⑦ end if

⑧w′←w-object；

/*將天氣置0或移除實體對象*/

⑨a′←m(φ(w′))；

3 系統(tǒng)實現(xiàn)

3.1 待測系統(tǒng)

選取目前最佳的條件自動駕駛系統(tǒng)CILRS[44]作為測試對象，其使用ResNet-34作為圖像特征提取的卷積神經(jīng)網(wǎng)絡，權重參數(shù)為使用CARLA的NoCrash數(shù)據(jù)集訓練得到的預訓練模型.同時，為了顯示出測試系統(tǒng)在不同自動駕駛系統(tǒng)上的能力，還選擇了基礎的條件自動駕駛系統(tǒng)CIL[45]作為對比的基線.最后，對CIL和CILRS分別進行了封裝，部署到測試系統(tǒng)中.

3.2 測試平臺

從預制資產(chǎn)豐富程度和API使用的靈活度的角度出發(fā)，本文選擇了CARLA 0.9.11作為測試系統(tǒng)開發(fā)平臺.出于便捷導入靜態(tài)資產(chǎn)和地圖的目的，我們從源碼編譯Unreal Engine 4.24引擎和CARLA 0.9.11，部署于Windows平臺.運行時，從Unreal Engine編輯器中啟動CARLA以快速迭代構建環(huán)境，驗證場景生成算法的正確性.

3.3 場景搭建

受限于深度學習模型推導效率，通常部署于深度自動駕駛中的CNN網(wǎng)絡的輸入圖像分辨率不會特別高，需要對相機捕獲的數(shù)據(jù)進行預處理，裁剪出感興趣區(qū)域(region of interest，ROI).在這種情況下，場景中相對路面比較遠的其他部分不會被捕獲到相機畫面中來.但是，比較高或者比較低的道路兩側的建筑的高度實際會影響到道路的光照效果，一定會對自動駕駛系統(tǒng)的預測產(chǎn)生影響.為了測試這種影響，我們設計了3種環(huán)境，分別為曠野、鄉(xiāng)村、城市，具有不同的環(huán)境物體高度，通過Unreal Engine編輯器創(chuàng)建，如圖4所示:

Fig. 4 Three environments圖4 3種環(huán)境

選取CARLA 0.9.11默認提供的10種天氣參數(shù)(太陽方位角、太陽高度角、云量、降雨量、積雨量、風強度、空氣濕度、霧濃度、霧距、霧密度)作為測試系統(tǒng)可以調(diào)節(jié)的天氣參數(shù).在不同場景中，太陽方位角和太陽高度角是必須存在的天氣參數(shù).霧濃度、霧距、霧密度三者之間具有相關性，必須同時存在.

我們對CARLA提供的89種可有效生成的靜態(tài)物體、28種車輛、26種行人進行了對象屬性測算.28種車輛的差異體現(xiàn)在型號帶來的大小、形狀和顏色的差異.26種行人則包含男性、女性2種性別，年齡分成幼年、青年、老年3個年齡段.在89種靜態(tài)物體中，有一些重復的內(nèi)容，例如盒子包含6種，但有明顯差異的只有2種，而且有一些物體在我們設計的場景下不應作為可以動態(tài)生成在道路和人行道上的內(nèi)容，例如秋千.最終，選擇全部的28種車輛、26種行人以及15種具有代表性的靜態(tài)物體，將測算的數(shù)據(jù)按照格式要求寫在對象屬性文件中.

實時渲染引擎中需要一個用以控制自動駕駛的車輛和一個捕獲當前場景圖像的相機傳感器，由于CARLA中車輛的物理模擬使用了相同的藍圖作為實現(xiàn)，所以在該平臺上選擇哪種車輛作為控制車輛是無關緊要的.選取28種車輛中的Tesla Model 3作為控制車輛，傳感器選擇普通RGB單眼傳感器，位于相對車輛中心前方1.6 m處，相對地面高1.4 m，F(xiàn)OV取為100，畫面分辨率為800×600，幀率為25 Hz.相機捕獲的場景畫面如圖5所示:

Fig.5 The image captured by the on-board camera in the country environment圖5 鄉(xiāng)村環(huán)境中車載相機捕獲的畫面

4 實驗評估

4.1 安全問題檢測能力對比分析

我們對最新的自動駕駛測試系統(tǒng)Paracosm進行了復現(xiàn)，并使用復現(xiàn)的Paracosm與我們的工作同時對自動駕駛系統(tǒng)CILRS和CIL進行安全性測試.我們選取了CARLA 0.9.11作為Paracosm和本系統(tǒng)的場景生成平臺.Paracosm未考慮如何設置具體的安全性問題檢出標準，其在未來工作部分討論了與本文類似的測試預言生成思路，但是并未設計具體的方法和參數(shù)選擇.故在本節(jié)的實驗中，為了實驗的公平性，復現(xiàn)的Paracosm系統(tǒng)和本文一樣，選取了蛻變測試作為測試預言機制，將場景變換前自動駕駛系統(tǒng)輸出的結果視為正確輸出，詳細的設計見2.4節(jié).

我們選取了3種類型的環(huán)境，即曠野、鄉(xiāng)村和城市，對CILRS系統(tǒng)和CIL系統(tǒng)分別進行了安全性測試.請注意，3種環(huán)境的主要區(qū)別在于道路兩側的建筑物高度不同，從而影響自動駕駛車輛上相機中的ROI的光照.將車輛生成于場景中的直道部分，設定車輛的駕駛分支為沿路行駛開始測試.讓這2個測試系統(tǒng)分別在不同類型的環(huán)境下動態(tài)搜索300個場景.表2中展示了本文工作與Paracosm系統(tǒng)的安全問題檢出率，檢出率的計算方法如式(2)所示.

Table 2 The Discovery Rate of Security Issues Between This Work and the Paracosm System

上述實驗結果表明，本文工作在曠野、鄉(xiāng)村和城市3個代表性環(huán)境的300次場景搜索中，安全問題發(fā)現(xiàn)能力均優(yōu)于自動駕駛測試系統(tǒng)Paracosm.整體來看，本文工作在2個系統(tǒng)上的安全問題檢出率皆是Paracosm的1.4倍.實驗表明，本系統(tǒng)面向測試對象的適應性搜索算法設計相比于非適應性算法更加高效.

4.2 安全問題檢測能力具體分析

為排除其他因素造成的影響，選擇設計的3個環(huán)境中的曠野環(huán)境作為測試環(huán)境.其實驗參數(shù)與4.1節(jié)相同.基于該設定分別對CIL和CILRS進行實驗，并針對每個系統(tǒng)進行了1 000輪場景搜索.使用式(2)計算故障率，并將結果列于表3中.

Table 3 Failure Rate of Autonomous Driving System

從表3中可以看出，存在實體對象時，場景變換造成的故障率較只有天氣的情況更高.并且在考慮天氣和所有實體對象的情況下，我們對CILRS的故障發(fā)現(xiàn)率達到了58.4%.

比較CILRS與CIL的實驗結果，可以發(fā)現(xiàn)兩者在只包含天氣的情況下表現(xiàn)相近，而在擁有表示場景擁擠程度的實體對象的情況下，CIL故障發(fā)生率高于CILRS.CILRS是在CARLA100數(shù)據(jù)集下訓練的，著重解決擁擠場景下駕駛系統(tǒng)的正確性預測問題.實驗結果印證了CILRS確實緩解了擁擠場景下自動駕駛系統(tǒng)故障率高的問題.換言之，CILRS的安全性優(yōu)于CIL.

4.3 蛻變測試的松弛限

在2.4節(jié)的測試預言定義中，使用松弛的蛻變測試來避免采取固定真值測試時，自動駕駛系統(tǒng)測試可能會出現(xiàn)大量假陽性的問題.在4.1節(jié)中，使用ε=0.17對不包含實體對象的天氣場景進行實驗，使用ε1=0.17，ε2=0.2對包含實體對象的場景進行實驗.這2個值的選取是經(jīng)驗選取的.本節(jié)通過調(diào)整ε進行實驗，從而分析松弛限的取值對實驗結果的影響.

選取CILRS系統(tǒng)的沿路行駛模式，在直道上進行測試，測試系統(tǒng)擁有生成全部實體對象的能力.分別固定ε1=0.17和固定ε2=0.2，每次固定進行100次實驗，將故障發(fā)現(xiàn)率繪在圖6中.

Fig. 6 The relationship between failure discovery rate and slack limit using metamorphosis test圖6 使用蛻變測試故障發(fā)現(xiàn)率與松弛限的關系

圖6中，折線ε1是固定ε2=0.2時，ε1取值[0,0.5]，故障發(fā)現(xiàn)率與松弛限的關系.折線ε2是固定ε1=0.17時，ε2取值[0,0.5]，故障發(fā)現(xiàn)率與松弛限的關系.注意當ε=0時，故障發(fā)現(xiàn)率并不為100%，這是由于ε1與ε2并非同時取0帶來的.

從圖6中可以觀察到，隨著松弛限逐漸變大，故障發(fā)現(xiàn)率不斷下降.如果松弛率比較小，那么系統(tǒng)就會報出大量的假陽性.如果松弛率比較大，那么系統(tǒng)又會忽略可能的危險錯誤.正如前面解釋設計自動駕駛測試預言的困難性，如何折中松弛率是一個很復雜的問題，在DeepTest[15]中使用統(tǒng)計標準差作為松弛限，DeepRoad[34]直接使用經(jīng)驗取值.根據(jù)圖6，ε在0～0.1區(qū)間內(nèi)，隨自身增加，故障發(fā)現(xiàn)率下降速度比較快，推測排除了大量的假陽性，而松弛限在0.1～0.22比較平滑，可以看作一個比較合理的取值范圍.另外，對自動駕駛任務而言，略高的假陽性能夠避免故障場景的錯誤排除，對實際任務并非不可接受.這是自動駕駛任務故障的危害性程度帶來的.

4.4 場景覆蓋分析

本節(jié)從不同的環(huán)境、不同的駕駛模式對深度自動駕駛系統(tǒng)進行測試，驗證測試系統(tǒng)的覆蓋能力.

4.4.1 環(huán)境測試

我們提供的3種測試場景(曠野、鄉(xiāng)村和城市)的主要區(qū)別在于道路兩側的建筑物高度不同，從而影響自動駕駛車輛上相機中的ROI的光照不同.在地圖中的直道區(qū)域，分別對CIL和CILRS進行測試，結果列于表4中.

Table 4 Testing Results of Autonomous Driving Systems in Different Environments

從表4得到2個結論：

1) 在曠野、鄉(xiāng)村、城市3個不同的環(huán)境下進行測試，故障發(fā)現(xiàn)率是比較接近的，一方面說明了環(huán)境對故障發(fā)現(xiàn)率的影響比較小，另一方面印證了我們設計不同環(huán)境的依據(jù)——自動駕駛中的ROI設計使得自動駕駛系統(tǒng)更關注路面而非道路兩側的環(huán)境.

2) 有趣的是，在我們的設想中，低光照環(huán)境下的城市，故障發(fā)現(xiàn)率應該高于正常光照或者高光照情況下的曠野和鄉(xiāng)村條件，因為按照直覺，夜間駕駛相對白天駕駛更容易出現(xiàn)問題.然而表4的數(shù)據(jù)與我們預料的結果相反，低光照情況下的故障搜索效率反而低了.通過觀察實驗結果，我們推測在正常光照條件下，自動駕駛車輛的轉向角一方面依賴實體對象，另一方面依賴道路中心的雙黃線.一旦雙黃線部分被遮蔽后，就很有可能造成駕駛輸出故障.在低光照情況下，雙黃線始終被遮蔽，這就使得駕駛輸出主要依賴場景中的其他實體對象.由2.4節(jié)可知，我們設計的駕駛語義保持的方式使得決定駕駛語義變化區(qū)域的實體對象沒有改變，這樣反而使得故障的搜索能力減弱了.

4.4.2 駕駛模式測試

在條件自動駕駛系統(tǒng)中，除車載相機拍到的圖像外，高層的控制指令決定了當前駕駛動作應采取的分支動作.而自動駕駛系統(tǒng)有4個駕駛模式，即沿路行駛、向左、向右和直行.我們在不同的場景中分別選擇了直路來測試沿路行駛模式，選擇十字路口分別測試向左、向右和直行3種指令.注意，在地圖的不同位置進行測試時，場景初始化器需要根據(jù)區(qū)域配置重新合成對象分布進行抽樣以適應車載相機實際的FOV.測試結果如表5所示.可以看到，在不同分支的情況下，CILRS的安全性均優(yōu)于CIL.

Table 5 Testing Results of the Autonomous Driving System in Different Branches

4.5 CILRS駕駛系統(tǒng)脆弱性分析

本節(jié)中，將以CILRS系統(tǒng)為例，通過回答3個問題來展示測試系統(tǒng)的自動化測試能力.

問題1.哪些天氣更容易造成CILRS系統(tǒng)出現(xiàn)故障？

使用缺陷分析器將擁有所有對象控制能力的實驗中的天氣逐個置零，確定哪些天氣更容易造成自動駕駛系統(tǒng)發(fā)生故障.由于不同天氣是通過采樣得到的，采樣得到的數(shù)量不同，故而使用造成故障的天氣相對該天氣出現(xiàn)次數(shù)的比值作為對比值，將結果顯示在圖7中，注意，天氣可能只是造成故障的原因之一，不一定是決定因素.

缺陷分析器給出的造成故障的原因可能是多個對象，故而該圖中總和大于100%.從圖7中可以看出，造成路面信息模糊(特別是道路標識模糊)的積雨最容易造成自動駕駛系統(tǒng)的不穩(wěn)定.隨后是干擾了相機傳感器畫面的降雨.風的強度主要影響到了降雨的雨水飄落的傾斜程度和道路兩側樹葉的吹動，后者屬于環(huán)境內(nèi)容，根據(jù)表4，其對自動駕駛系統(tǒng)的影響并不突出.可見CILRS系統(tǒng)在這些天氣條件中，最易受到降雨環(huán)境的干擾.

Fig. 7 Proportion of CILRS system failure caused by the weather圖7 天氣造成CILRS系統(tǒng)故障的比例

問題2.哪些區(qū)域是CILRS駕駛系統(tǒng)的關鍵區(qū)域？

將深度自動駕駛的關鍵區(qū)域定義為，當這個區(qū)域出現(xiàn)實體對象時，自動駕駛的輸出更容易出現(xiàn)不穩(wěn)定性.對先前在直道上進行測試，存在實體對象的實驗結果進行分析.首先，搜索到的造成故障的場景和原始場景會一并交給缺陷分析器進行處理，分析出造成故障的物體.接著，把故障物體的區(qū)域繪在圖8中，橫坐標是在沿道路方向的x軸，縱坐標是道路切向方向的y軸.在我們的設置中，自動駕駛車輛的坐標為(0,-2.27).圖8的統(tǒng)計結果顯示CILRS系統(tǒng)的敏感區(qū)域在道路兩側的人行道上.

Fig. 8 The key area of the CILRS driving system圖8 CILRS駕駛系統(tǒng)的關鍵區(qū)域

問題3.哪些物體更容易造成CILRS系統(tǒng)出現(xiàn)故障？

將造成系統(tǒng)故障的物體相對其采樣次數(shù)的比值用作比較物體造成CILRS系統(tǒng)故障的概率的標準.去除重復物體，取錯誤率最高的5個實體對象，將對象及其故障率列在表6中.

通過圖8和表6，可以發(fā)現(xiàn)2點：

1) 位于道路上的車輛可能不是造成不穩(wěn)定性的主要原因，相反，處于道路兩側人行道上的物體可能更容易造成自動駕駛系統(tǒng)的不穩(wěn)定.觀察CARLA100數(shù)據(jù)集，發(fā)現(xiàn)自動駕駛系統(tǒng)針對復雜道路條件進行了訓練，忽略了人行道上物體的復雜性.

2) 黃色與紅色是CILRS系統(tǒng)的敏感顏色.這是很自然的，因為交通信號燈的顏色恰好是黃色和紅色，當人行道上出現(xiàn)黃色或者紅色物體時，CILRS很有可能將其誤判成信號燈.

Table 6 The Entity Objects and Failure Rate

測試系統(tǒng)發(fā)現(xiàn)的CILRS的脆弱性正是CILRS優(yōu)化的方向，可以使用本文測試系統(tǒng)在網(wǎng)絡訓練后校驗系統(tǒng)的安全性.網(wǎng)絡優(yōu)化方案可以是數(shù)據(jù)增強、結構優(yōu)化等，優(yōu)化后再次使用測試系統(tǒng)進行校驗可以確定深度網(wǎng)絡是否滿足了安全性需求.例如對CILRS系統(tǒng)，建議增加雨天天氣、更豐富的道路兩側場景的訓練數(shù)據(jù)，以提高系統(tǒng)的穩(wěn)定性，設計雙保險機制緩解對黃色、紅色物體的敏感性.

4.6 特征分析與啟發(fā)

為了進一步分析造成CILRS系統(tǒng)故障的原因，我們打開了CILRS系統(tǒng)，觀察ResNet的特征提取層.我們發(fā)現(xiàn)，大多數(shù)情況下搜索到的故障場景和原場景的特征提取結果雖然有所差異，但差異不是特別明顯，在一系列分析過程中，發(fā)現(xiàn)了一個有趣的樣例，即身穿紅色衣服的行人在人行道上行走.

如圖9所示，設置環(huán)境在曠野上，車輛位于直行道路區(qū)域上，使用沿路行駛模式進行測試，此時車速為4(歸一化數(shù)值)，一個身穿紅色衣服的行人在右側人行道的中央位置沿著人行道向前走.自動駕駛車輛停留在初始位置，根據(jù)行人所處的不同位置，可以得到CILRS系統(tǒng)預測輸出的變化，如圖10所示.

Fig. 9 Failure analysis example: Pedestrian in red walking on the side of the road圖9 故障分析樣例：身穿紅色衣服的行人在道路旁行走

Fig. 10 CILRS system output with pedestrian position changes圖10 CILRS系統(tǒng)輸出隨行人位置的變化

根據(jù)圖10可以看到，行人出現(xiàn)前，CILRS系統(tǒng)輸出比較穩(wěn)定.而在行人開始出現(xiàn)時，CILRS系統(tǒng)受到了影響并產(chǎn)生波動，然而始終處于故障范圍之外.大約在車輛中心位置前7.5 m處，預測輸出變?yōu)槊筒葎x車(剎車效應優(yōu)先于轉向效應).隨后自動駕駛系統(tǒng)的輸出仍處于波動狀態(tài)，直到行人遠離后車輛輸出才趨向穩(wěn)定(bias<0.1).這樣的表現(xiàn)顯然是不正常的，當行人距離車比較近的時候，如果CILRS判定此時應剎車，則應立即輸出剎車，不應該在行人繼續(xù)向前走之后才輸出剎車.將沒有行人和行人在相對車輛中心位置前面7.5 m處時的相機輸入及CILRS卷積層前3層輸出的結果繪在圖11中.作為對比，將一張長椅放在位于人行道上造成自動駕駛系統(tǒng)輸出變化最大的位置，此時自動駕駛輸出相對不存在任何物體時的偏移steer_bias=0.030<0.17，throttle_bias=0.05<0.2，不會被判定為系統(tǒng)故障.

圖11中，有長椅的場景第3層卷積輸出的結果與不存在任何物體的場景的卷積輸出結果比較相似，而行人所出現(xiàn)的場景卷積輸出和不存在任何物體的場景的卷積輸出有明顯差異.

圖11中，前2列在原始畫面和特征提取前2層畫面有明顯差異，然而在第3層卻比較相近.第1列和第3列原始畫面與前3層都有很大的差異.這說明盡管畫面中相同位置都出現(xiàn)了物體，但特征提取出來的內(nèi)容是不同的.這啟發(fā)我們或許可以在某一或某些特征層設置監(jiān)控器，通過監(jiān)控器的變化分析提前預警系統(tǒng)是否會發(fā)生故障.

Fig. 11 Input and convolutional layer output of CILRS圖11 CILRS輸入及卷積層輸出

4.7 系統(tǒng)運行效率分析

本節(jié)對測試系統(tǒng)的運行效率進行分析.部署測試系統(tǒng)的硬件平臺為AMD R5 3600X+RTX 3070，使用的軟件平臺為Windows 10+Unreal Engine 4.24.3+CARLA 0.9.11+Python 3.9.1.

將動態(tài)場景生成器根據(jù)初始場景搜索到一個造成自動駕駛系統(tǒng)出錯的場景或是超出迭代預算的用時定義為一次測試用時.在考慮所有實體對象，對象數(shù)量根據(jù)正態(tài)分布采樣得到，包含渲染過程的情況下，一次實驗的平均用時為16.86 s.排除渲染過程，采用分模塊測試取平均值的方式，對每個模塊及其內(nèi)部細節(jié)進行效率的測試，結果見表7.

Table 7 Average Time Consumption of Each Module of the Testing System

與十幾秒的單次實驗耗時相比，各個模塊內(nèi)部耗時是很短的，系統(tǒng)主要的性能瓶頸在渲染效率上.

5 結 論

為了保障車聯(lián)網(wǎng)場景下的自動駕駛系統(tǒng)安全性，本文設計并實現(xiàn)了一套場景驅(qū)動的針對自動駕駛視覺感知模塊的安全測試系統(tǒng).該系統(tǒng)構建了一套真實且豐富的場景描述方法，極大地拓展了測試系統(tǒng)的數(shù)據(jù)分布；本系統(tǒng)可以動態(tài)地為不同自動駕駛模型產(chǎn)生安全測試方案，可以實現(xiàn)高效、穩(wěn)定地發(fā)現(xiàn)安全缺陷；最后本系統(tǒng)設計了一套精細的自動化安全問題分析工具，該工具可以幫助自動駕駛開發(fā)人員快速定位系統(tǒng)的安全性問題.我們相信，本文工作將啟發(fā)更多的自動駕駛感知模塊的測試方案，會為車聯(lián)網(wǎng)場景下的自動駕駛領域提供重要的安全基礎.

作者貢獻聲明：吳昊負責論文撰寫和解決方案設計；王浩負責系統(tǒng)設計和實現(xiàn)；蘇醒負責系統(tǒng)實現(xiàn)和實驗；李明昊負責實驗和結果分析；許封元負責定義問題及修改論文；仲盛負責把控研究方向和修改論文.