蘇敬發(fā)，周 煒，高利斌，蔣金虎

（1.復(fù)旦大學(xué) 大數(shù)據(jù)研究院，上海 200082；2.國(guó)家并行工程技術(shù)中心，北京 100080）

0 引言

自動(dòng)駕駛仿真是計(jì)算機(jī)仿真技術(shù)在汽車自動(dòng)駕駛領(lǐng)域的應(yīng)用，它通過數(shù)學(xué)建模的形式將自動(dòng)駕駛的應(yīng)用場(chǎng)景進(jìn)行數(shù)字化還原，建立接近真實(shí)世界的系統(tǒng)模型[1-2]。通過仿真環(huán)境進(jìn)行分析和研究，便可在實(shí)際落地前對(duì)自動(dòng)駕駛算法及系統(tǒng)進(jìn)行測(cè)試驗(yàn)證。

目前大多數(shù)仿真平臺(tái)僅支持單點(diǎn)仿真[3]，單點(diǎn)仿真方式分散且獨(dú)立，實(shí)際部署和應(yīng)用面臨著資源忙閑不均、作業(yè)在節(jié)點(diǎn)間低效串行等問題，無法滿足自動(dòng)駕駛復(fù)雜場(chǎng)景仿真日益增長(zhǎng)的計(jì)算和處理需求，大規(guī)模節(jié)點(diǎn)統(tǒng)一管理和調(diào)度是自動(dòng)駕駛仿真的必然趨勢(shì)，在通用計(jì)算領(lǐng)域，云化是大規(guī)模節(jié)點(diǎn)便捷管理和高效調(diào)度的有效方式。不同于通用計(jì)算，面向自動(dòng)駕駛仿真應(yīng)用對(duì)異構(gòu)計(jì)算資源和現(xiàn)有協(xié)議棧有著強(qiáng)依賴性，構(gòu)建面向自動(dòng)駕駛的云化仿真平臺(tái)面臨著高效虛擬化、均衡調(diào)度、便捷端-云交互的挑戰(zhàn)。

本文針對(duì)自動(dòng)駕駛仿真平臺(tái)當(dāng)前的難點(diǎn)挑戰(zhàn)，基于輕量級(jí)虛擬化技術(shù)設(shè)計(jì)了面向自動(dòng)駕駛的高性能并行仿真平臺(tái)系統(tǒng)架構(gòu)，并設(shè)計(jì)和集成了細(xì)粒度資源均衡調(diào)度和低延時(shí)遠(yuǎn)程交互方法，構(gòu)建了ADsim 高性能并行仿真平臺(tái)，并在一汽自動(dòng)駕駛仿真業(yè)務(wù)中進(jìn)行了部署應(yīng)用。測(cè)試表明本系統(tǒng)通過ADsim 給容器應(yīng)用指定分配GPU，滿足了不同的策略需求，在實(shí)現(xiàn)更好的靈活性與均衡性的同時(shí)，其高效性和高響應(yīng)性也得到提升。

1 背景概述

自動(dòng)駕駛是人工智能(AI)技術(shù)與汽車行業(yè)深度融合的重要場(chǎng)景之一，尤其是近年來隨著AI 算力和數(shù)據(jù)驅(qū)動(dòng)能力的提升，自動(dòng)駕駛領(lǐng)域的技術(shù)突飛猛進(jìn)，大量科技巨頭和新創(chuàng)公司進(jìn)入到該領(lǐng)域。自動(dòng)駕駛進(jìn)入到公共出行、環(huán)衛(wèi)、零售、觀光、物流、農(nóng)業(yè)等多個(gè)領(lǐng)域，涵蓋客運(yùn)、貨運(yùn)和專項(xiàng)工作等多種復(fù)雜場(chǎng)景[4]，在人類活動(dòng)和社會(huì)生產(chǎn)中越來越重要。

在實(shí)際投入使用前，自動(dòng)駕駛汽車必須行駛數(shù)十億英里才能證明其可靠性。在真正的自動(dòng)駕駛車輛上測(cè)試自動(dòng)駕駛算法是非常昂貴的[5]，許多研究人員和開發(fā)人員無法負(fù)擔(dān)真正的汽車和相應(yīng)的傳感器。通過軟件模擬來發(fā)現(xiàn)和復(fù)現(xiàn)問題是降低成本和技術(shù)門檻的重要手段。通過仿真，開發(fā)人員可以在不駕駛真實(shí)車輛的情況下快速測(cè)試新算法，不需要真實(shí)的環(huán)境和硬件，可以極大地節(jié)省成本和時(shí)間。與真實(shí)道路測(cè)試相比，仿真測(cè)試更安全，尤其是現(xiàn)實(shí)世界中的危險(xiǎn)場(chǎng)景，如極端天氣，能夠準(zhǔn)確再現(xiàn)問題場(chǎng)景的所有因素。因此，自動(dòng)駕駛仿真是自動(dòng)駕駛中的關(guān)鍵支撐技術(shù)，是企業(yè)獲得低成本核心競(jìng)爭(zhēng)力的主要途徑。近年來，隨著自動(dòng)駕駛技術(shù)的蓬勃發(fā)展，大量互聯(lián)網(wǎng)企業(yè)和汽車廠商加大對(duì)自動(dòng)駕駛仿真的投入和創(chuàng)新，各種自動(dòng)駕駛仿真軟件層出不窮。

國(guó)外的自動(dòng)駕駛仿真軟件研制處于各大巨頭與創(chuàng)新公司百花齊放的階段。市場(chǎng)上的自動(dòng)駕駛仿真軟件有兩類：一類是以大企業(yè)為背景研發(fā)的，包括有Tesla 的FSD、Google 的Waymo Carcraft、NVIDIA Constellation、Microsoft AirSim、LG LGSVL 等；另外一類是由專注于自動(dòng)駕駛仿真的專業(yè)公司研發(fā)的，如Carsim、PTV VISSIM、TESS、SUMO、VIRES VTD、RESCAN、PreScan等大量各具特色的自動(dòng)駕駛仿真軟件。

國(guó)內(nèi)在自動(dòng)駕駛仿真領(lǐng)域的發(fā)展與國(guó)際基本同步，但受限于技術(shù)積累和投入的原因，目前主要有百度和騰訊兩家。百度與Unity 建立了合作關(guān)系，開發(fā)了基于Unity 的真實(shí)感虛擬環(huán)境仿真，為百度Apollo 提供系統(tǒng)仿真服務(wù)[6]；騰訊為自動(dòng)駕駛測(cè)試驗(yàn)證而專門設(shè)計(jì)研發(fā)了TAD Sim，側(cè)重自動(dòng)駕駛場(chǎng)景的數(shù)字孿生系統(tǒng)對(duì)自動(dòng)駕駛算法完備性提供仿真驗(yàn)證。

由于自動(dòng)駕駛仿真平臺(tái)涉及自動(dòng)駕駛核心關(guān)鍵技術(shù)，當(dāng)前各大公司都采取內(nèi)部構(gòu)建仿真平臺(tái)使用的方式。當(dāng)前市場(chǎng)盡管有多個(gè)開源的自動(dòng)駕駛軟件，如Autoware 和Apollo，但與它們一起協(xié)同使用的仿真模擬器的選擇卻有限，且多數(shù)僅支持單點(diǎn)工作，缺少大規(guī)模的協(xié)同運(yùn)作，性能也有待優(yōu)化[7]。因此，本研究意在搭建面向自動(dòng)駕駛的高性能并行仿真平臺(tái)，以容器化等技術(shù)突破當(dāng)前仿真面臨的瓶頸局面。構(gòu)建面向自動(dòng)駕駛高性能并行仿真平臺(tái)，當(dāng)前存在以下幾方面挑戰(zhàn)：

(1)設(shè)備耦合緊，虛擬化難：系統(tǒng)運(yùn)行仿真時(shí)需要大量計(jì)算資源，當(dāng)前仿真應(yīng)用與物理設(shè)備資源緊耦合，尤其是渲染部分，嚴(yán)重依賴物理顯卡。虛擬化是將仿真進(jìn)行云化的基礎(chǔ)[8]，傳統(tǒng)的方案以虛擬機(jī)方式為主，但開銷大，尤其是虛擬機(jī)中的GPU 虛擬化部分，會(huì)占用大量系統(tǒng)資源，需要一種更高效的虛擬化方式來滿足云化要求[9]。

(2)通用調(diào)度無法適應(yīng)新需求，靈活性差：自動(dòng)駕駛測(cè)試需仿真實(shí)例與自動(dòng)駕駛軟件實(shí)例交互配合，面對(duì)上層應(yīng)用需求的多樣化，整體調(diào)度需更具靈活性[10]。且不同種實(shí)例所需的底層資源也面臨差異，現(xiàn)有Kubernetes通用的調(diào)度策略無法感知自動(dòng)駕駛仿真組件間的關(guān)系，無法適應(yīng)自動(dòng)駕駛仿真調(diào)度需求[11]。

(3)遠(yuǎn)程操作延時(shí)大，交互不便：將仿真服務(wù)器進(jìn)行云化后，仿真運(yùn)行在云端服務(wù)器，交互操作需要通過網(wǎng)絡(luò)進(jìn)行，現(xiàn)有的遠(yuǎn)程交互基于遠(yuǎn)程桌面，性能開銷大、畫面反饋延時(shí)長(zhǎng)，導(dǎo)致了端-云間的交互不便，用戶體驗(yàn)差。

為解決上述問題，本研究設(shè)計(jì)了與Kubernetes 融合的系統(tǒng)架構(gòu)，并引入高效虛擬化、靈活均衡調(diào)度和便捷端-云交互等關(guān)鍵技術(shù)，實(shí)現(xiàn)了面向自動(dòng)駕駛的高性能并行仿真平臺(tái)ADsim，并在實(shí)際生產(chǎn)環(huán)境中進(jìn)行了測(cè)試驗(yàn)證和部署使用。

2 系統(tǒng)架構(gòu)

本文現(xiàn)有基礎(chǔ)支撐環(huán)境基于Kubernetes 進(jìn)行大規(guī)模節(jié)點(diǎn)部署和運(yùn)維。為了與現(xiàn)有平臺(tái)的融合統(tǒng)一，仿真平臺(tái)基于Kubernetes 框架進(jìn)行設(shè)計(jì)，利用Kubernetes CRD(Custom Resource Definition)機(jī)制增加仿真資源類型，主要由管理模塊與工作模塊組成，各個(gè)模塊以容器方式運(yùn)行，具體架構(gòu)如圖1 所示。

圖1 系統(tǒng)架構(gòu)圖

管理模塊負(fù)責(zé)整體的資源信息處理與分配工作，包含資源管理、用戶管理、實(shí)例映射、與Kubernetes 交互、與工作模塊通信的具體功能。管理模塊會(huì)在與Kubernetes 主節(jié)點(diǎn)交互的基礎(chǔ)上，綜合工作節(jié)點(diǎn)信息、工作模塊信息對(duì)不同用戶按策略進(jìn)行資源分配。工作模塊一方面負(fù)責(zé)對(duì)計(jì)算節(jié)點(diǎn)上所運(yùn)行實(shí)例的具體優(yōu)化，對(duì)不同的兩種實(shí)例Lg 節(jié)點(diǎn)與Apollo 節(jié)點(diǎn)，采用渲染加速、GPU分配策略等方案從底層進(jìn)行優(yōu)化。另一方面將運(yùn)作信息反饋給管理模塊，實(shí)時(shí)進(jìn)行資源的再規(guī)劃與再利用。

本系統(tǒng)總流程即管理模塊先收集資源信息進(jìn)行處理，再將實(shí)例與硬件資源進(jìn)行映射，然后通過工作模塊進(jìn)行性能優(yōu)化，開始仿真，并在工作過程結(jié)合Kubernetes、工作模塊的反饋信息來交互處理。

3 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

本節(jié)針對(duì)高效虛擬化、均衡度調(diào)度和端-云交互三個(gè)目標(biāo)進(jìn)行設(shè)計(jì)與實(shí)現(xiàn)。

3.1 高效虛擬化

虛擬化作為仿真云化的基礎(chǔ)，傳統(tǒng)方案以虛擬機(jī)方式為主，但性能開銷大，尤其是虛擬機(jī)中的GPU 虛擬化部分，會(huì)占用大量系統(tǒng)資源。在IBM 的一份針對(duì)裸機(jī)、容器與虛擬機(jī)運(yùn)行性能的研究報(bào)告顯示，在不同的配置情況下，Docker 的性能都等于或超過虛擬機(jī)方式。例如將廣泛應(yīng)用于云中的關(guān)系數(shù)據(jù)庫(kù)MySQL 部署在裸機(jī)、Docker 以及KVM 下，測(cè)試結(jié)果顯示Docker 具有與裸機(jī)相似的性能，在更高的并發(fā)性下差異漸近接近2%。而KVM 的開銷要高得多，在所有測(cè)量的情況下都高于40%[8]。因此本系統(tǒng)采用更輕量級(jí)的容器化方式進(jìn)行高效的虛擬化。

相比于虛擬機(jī)技術(shù)，容器的輕量級(jí)特性，使得開發(fā)、測(cè)試以及部署過程都可以節(jié)約大量時(shí)間。在同樣的硬件環(huán)境下，容器能運(yùn)行的鏡像數(shù)遠(yuǎn)多于虛擬機(jī)的數(shù)量，因此更便于對(duì)資源的精細(xì)分配，系統(tǒng)利用率高。而基于Kubernetes 的開源生態(tài)迅速發(fā)展，容器在可管理性、可觀察性、安全性、穩(wěn)定性等多方面也均優(yōu)于虛擬機(jī)，有大量組件提供保障。

自動(dòng)駕駛仿真與實(shí)際的物理資源耦合密切，需大量使用物理顯卡資源，尤其是渲染部分。而容器應(yīng)用對(duì)顯卡設(shè)備的控制度不足，僅可查看GPU 的使用信息等，而無法對(duì)其進(jìn)行具體分配調(diào)度等細(xì)粒度操作。因而本系統(tǒng)在仿真應(yīng)用與硬件資源的中間層，采取API 重定向的方式實(shí)現(xiàn)GPU 虛擬化。在應(yīng)用與驅(qū)動(dòng)之間，通過修改圖像渲染接口截獲處理硬件請(qǐng)求。API 重定向方式如圖2所示。

圖2 API 重定向方式

本系統(tǒng)首先針對(duì)仿真應(yīng)用進(jìn)行了容器化處理。仿真應(yīng)用本身不支持容器化，本系統(tǒng)針對(duì)服務(wù)器Linux 環(huán)境，從底層設(shè)計(jì)Dockerfile 文件，添加仿真所需依賴項(xiàng)libvulkan 等，并修改添加了vulkan-loader 層，使仿真容器能實(shí)現(xiàn)API 重定向的轉(zhuǎn)發(fā)方式。

在設(shè)計(jì)構(gòu)建好仿真鏡像后，依然面臨容器運(yùn)行報(bào)錯(cuò)的問題。本系統(tǒng)完成了對(duì)容器化多個(gè)難點(diǎn)問題的詳細(xì)定位與解決。如GPU 啟用失效，本系統(tǒng)通過修改驗(yàn)證容器依賴環(huán)境與GPU 版本配置的一致性，解決了仿真應(yīng)用與容器環(huán)境的不兼容問題，使容器化使用GPU 可行，并可進(jìn)一步地進(jìn)行GPU 虛擬化處理。

由于圖形化應(yīng)用對(duì)Linux 系統(tǒng)的兼容性不足，本系統(tǒng)還針對(duì)容器的顯示與渲染部分進(jìn)行了設(shè)計(jì)改造，通過修改Linux 系統(tǒng)配置與容器顯示權(quán)限問題，使得圖形化的仿真應(yīng)用可成功在遠(yuǎn)程端操作處理。并進(jìn)一步對(duì)仿真應(yīng)用的網(wǎng)絡(luò)服務(wù)進(jìn)行了優(yōu)化設(shè)計(jì)。當(dāng)在同臺(tái)機(jī)器啟動(dòng)多個(gè)容器時(shí)，仿真會(huì)面臨并行啟動(dòng)失敗的問題。本系統(tǒng)通過對(duì)容器網(wǎng)絡(luò)進(jìn)行設(shè)計(jì)，避免了端口沖突，分別以host 以及bridge 模式完成了對(duì)多個(gè)容器的端口分配與管理，實(shí)現(xiàn)了在遠(yuǎn)程端的Web 界面對(duì)多個(gè)容器應(yīng)用同時(shí)進(jìn)行模擬仿真的配置處理。

在虛擬化的具體處理上，系統(tǒng)工作模塊通過修改仿真應(yīng)用所使用的圖形渲染API Vulkan 來實(shí)現(xiàn)API 重定向。通過Vulkan 的Loader 機(jī)制，在Layer 層攔截函數(shù)，實(shí)現(xiàn)GPU 的分配處理：指定單個(gè)GPU 處理多個(gè)容器應(yīng)用、多個(gè)GPU 處理單個(gè)容器應(yīng)用以及多個(gè)GPU 處理多個(gè)容器應(yīng)用。

3.2 均衡調(diào)度

在調(diào)度問題上，由于自動(dòng)駕駛仿真不僅包括仿真環(huán)境，還需耦合自動(dòng)駕駛操作系統(tǒng)，因而要有靈活的調(diào)度管理，且不同情況下所需底層資源的差異性也要求調(diào)度具有靈活性、均衡性。

本系統(tǒng)優(yōu)化了仿真軟件與自動(dòng)駕駛操作系統(tǒng)軟件的交互調(diào)度。在實(shí)際應(yīng)用中，可能包含一個(gè)仿真場(chǎng)景，在此仿真場(chǎng)景下，又包含多個(gè)自動(dòng)駕駛操作系統(tǒng)來控制多輛汽車。此時(shí)仿真與操作系統(tǒng)即一對(duì)多關(guān)系。本系統(tǒng)在此基礎(chǔ)上，將對(duì)應(yīng)關(guān)系擴(kuò)展為多對(duì)多關(guān)系，根據(jù)不同應(yīng)用需求，可以同時(shí)部署一個(gè)或多個(gè)仿真環(huán)境，再由管理模塊統(tǒng)一管理多個(gè)仿真與操作系統(tǒng)實(shí)例，進(jìn)行統(tǒng)一調(diào)度與資源分配。

系統(tǒng)管理模塊會(huì)根據(jù)資源管理信息、用戶管理信息、通信信息，將請(qǐng)求的實(shí)例發(fā)放到具體的工作節(jié)點(diǎn)并分配硬件資源，進(jìn)行實(shí)例映射。管理模塊根據(jù)上層需求的不同，支持不同的調(diào)度策略，包括集中往一臺(tái)機(jī)器分配的低功耗策略，或是向多個(gè)節(jié)點(diǎn)同時(shí)發(fā)送請(qǐng)求的高性能并行策略。ADsim 仿真平臺(tái)調(diào)度方案如圖3 所示。

圖3 ADsim 仿真平臺(tái)調(diào)度方案

為進(jìn)一步提高實(shí)例映射效率，合理利用硬件資源，在接受到具體的實(shí)例運(yùn)行請(qǐng)求后，系統(tǒng)將根據(jù)實(shí)例類型進(jìn)行區(qū)分優(yōu)化，從而使調(diào)度更均衡。系統(tǒng)的實(shí)例包含模擬仿真實(shí)例Lg 節(jié)點(diǎn)和自動(dòng)駕駛系統(tǒng)實(shí)例Apollo 節(jié)點(diǎn)兩種。當(dāng)接受到仿真實(shí)例Lg 節(jié)點(diǎn)的請(qǐng)求后，系統(tǒng)工作模塊將在Vulkan 虛擬層對(duì)資源請(qǐng)求進(jìn)行處理。工作模塊支持在Vulkan 層指定分配GPU 的功能，從而達(dá)到更高效的底層映射效果。對(duì)于Apollo 節(jié)點(diǎn)實(shí)例，由于渲染計(jì)算不是必需的，工作模塊暫不提供對(duì)Apollo 節(jié)點(diǎn)的加速優(yōu)化。

3.3 端云交互

在使用服務(wù)器進(jìn)行仿真時(shí)，需要將遠(yuǎn)程服務(wù)器渲染后的畫面返回本地進(jìn)行交互。

傳統(tǒng)的解決方案采用遠(yuǎn)程顯示方法，如VNC 等策略，把被控制端的屏幕做成圖像，經(jīng)過壓縮后傳送到控制端，即等待應(yīng)用完成仿真渲染后再截取畫面進(jìn)行延時(shí)反饋。如圖4 所示，VNC 在遠(yuǎn)程服務(wù)器上運(yùn)行一個(gè)額外的X 服務(wù)器，然后通過 RFB 協(xié)議用將畫面顯示到本地。

圖4 VNC 顯示原理

但該方案對(duì)于自動(dòng)駕駛仿真的支持度并不理想，一是服務(wù)器端本身并不包含顯示畫面，二是此類方案會(huì)增加額外的系統(tǒng)開銷，且反饋延時(shí)長(zhǎng)易卡頓，反饋效果也不夠理想。

本系統(tǒng)選擇針對(duì)幀緩沖機(jī)制來完善端-云交互過程，如圖5 所示。幀緩沖(Framebuffer)是Linux 系統(tǒng)為顯示設(shè)備提供的接口，它把顯示緩沖區(qū)抽象化處理，屏蔽圖像硬件底層的差異，允許應(yīng)用直接對(duì)顯示緩沖區(qū)進(jìn)行讀寫操作。本系統(tǒng)首先將應(yīng)用實(shí)例所需的顯示和渲染請(qǐng)求分離，其渲染部分交予GPU 完成，再截取其顯示流，傳導(dǎo)到虛擬屏幕上，解決了服務(wù)器端顯示缺失的問題，同時(shí)也避免了計(jì)算資源的浪費(fèi)。即在Vulkan 層調(diào)用圖形庫(kù)時(shí)，將所需資源分流為顯示需求和渲染需求兩部分，并對(duì)不同分流進(jìn)行操作，將顯示流連接到虛擬屏幕，將渲染流攔截至渲染轉(zhuǎn)發(fā)器交付給GPU 計(jì)算后，再經(jīng)由幀緩沖區(qū)直接交付給虛擬屏幕，這樣同時(shí)也避免遠(yuǎn)程服務(wù)器與本地傳遞畫面的延遲問題，優(yōu)化了從實(shí)例到用戶的顯示過程，使得端-云交互效率更高。

圖5 ADsim 端-云交互原理

4 測(cè)試與評(píng)估

本節(jié)對(duì)實(shí)現(xiàn)的系統(tǒng)原型進(jìn)行實(shí)驗(yàn)測(cè)試，以評(píng)估面向自動(dòng)駕駛的高性能并行仿真平臺(tái)ADsim 的有效性。

4.1 均衡性

本系統(tǒng)將LGSVL 仿真應(yīng)用進(jìn)行了容器化的工作并將其成功部署到云平臺(tái)，進(jìn)而實(shí)現(xiàn)了對(duì)其的優(yōu)化與管理功能。系統(tǒng)通過遠(yuǎn)程命令在多個(gè)容器中啟動(dòng)LGSVL 仿真應(yīng)用并運(yùn)行成功。將本地端口號(hào)分配給多個(gè)LGSVL容器并成功映射到不同的IP 地址。

進(jìn)一步地，對(duì)結(jié)合LGSVL 仿真應(yīng)用和Apollo 的自動(dòng)駕駛系統(tǒng)，進(jìn)行測(cè)試驗(yàn)證。對(duì)資源負(fù)載的評(píng)價(jià)標(biāo)準(zhǔn)為：(1)利用率：指GPU 資源的使用情況；(2)均衡率：指所有GPU 利用率的方差。

本系統(tǒng)通過ADsim 給容器應(yīng)用指定分配GPU，相較之前，滿足了不同的策略需求，達(dá)成了多個(gè)容器使用多個(gè)GPU 的靈活性與均衡性。

測(cè)試1：多個(gè)容器使用單個(gè)GPU 與多個(gè)容器使用多個(gè)GPU 的效果。低功耗模式下，單個(gè)GPU 的利用率高，其余GPU 空閑，均衡率高。

測(cè)試2：?jiǎn)蝹€(gè)容器使用單個(gè)GPU 與單個(gè)容器使用多個(gè)GPU 的效果。高性能并行模式下，多個(gè)GPU 同時(shí)渲染一個(gè)容器應(yīng)用，每個(gè)GPU 的利用率都較低，且均衡率低。GPU 利用率對(duì)比如圖6 所示。

圖6 GPU 利用率對(duì)比

4.2 高效性

為了驗(yàn)證該平臺(tái)的高效性，本文通過測(cè)試其網(wǎng)絡(luò)延遲的情況，在系統(tǒng)集群中使用sample-webapp Benchmark進(jìn)行網(wǎng)絡(luò)測(cè)試，對(duì)比該容器平臺(tái)和原虛擬機(jī)仿真平臺(tái)在訪問GPU 資源時(shí)的網(wǎng)絡(luò)延遲。通過十組測(cè)試的幾何平均值來進(jìn)行比較，以此說明容器仿真平臺(tái)具備高效性。網(wǎng)絡(luò)延遲對(duì)比如圖7 所示。

圖7 網(wǎng)絡(luò)延遲對(duì)比

在圖7 的對(duì)比中發(fā)現(xiàn)，本文對(duì)容器仿真平臺(tái)的重構(gòu)設(shè)計(jì)消除了虛擬機(jī)相關(guān)開銷帶來的網(wǎng)絡(luò)延遲，進(jìn)而使得容器仿真平臺(tái)獲得了更好的性能。

4.3 高響應(yīng)

為了驗(yàn)證本文對(duì)端云交互優(yōu)化的有效性，本節(jié)通過對(duì)比在本文優(yōu)化設(shè)計(jì)與原生設(shè)計(jì)基礎(chǔ)上的響應(yīng)時(shí)間來進(jìn)行測(cè)試。在測(cè)試方法上，本節(jié)設(shè)置十組實(shí)驗(yàn)，對(duì)兩個(gè)系統(tǒng)設(shè)置相同的容器測(cè)試負(fù)載，然后觀察平臺(tái)響應(yīng)時(shí)間，即從操作提交到執(zhí)行結(jié)束后可以被正常訪問的總時(shí)間，并對(duì)比十組響應(yīng)時(shí)間測(cè)試的幾何平均值來進(jìn)行說明。網(wǎng)響應(yīng)時(shí)間結(jié)果對(duì)比如圖8 所示。

圖8 網(wǎng)響應(yīng)時(shí)間結(jié)果對(duì)比

從圖8 可以看出，優(yōu)化設(shè)計(jì)后的端云交互系統(tǒng)將應(yīng)用實(shí)例所需的顯示和渲染請(qǐng)求分離，并對(duì)不同分流進(jìn)行對(duì)應(yīng)操作，避免了遠(yuǎn)程服務(wù)器與本地傳遞畫面的延遲問題，優(yōu)化了從實(shí)例到用戶的顯示過程，響應(yīng)時(shí)間的幾何均值相比原生設(shè)計(jì)的系統(tǒng)得到了進(jìn)一步的提升，使得端-云交互效率更高。

5 結(jié)論

本文對(duì)自動(dòng)駕駛仿真平臺(tái)面臨的挑戰(zhàn)進(jìn)行了分析，并設(shè)計(jì)和實(shí)現(xiàn)了面向自動(dòng)駕駛的ADsim 高性能并行仿真平臺(tái)，支持了高效虛擬化、均衡調(diào)度、便捷端-云交互特性。當(dāng)前工作主要從計(jì)算資源的虛擬化和調(diào)度上進(jìn)行了設(shè)計(jì)和優(yōu)化，未來需要結(jié)合數(shù)據(jù)訪問等方面對(duì)自動(dòng)駕駛仿真平臺(tái)進(jìn)行進(jìn)一步優(yōu)化，對(duì)仿真應(yīng)用的計(jì)算和數(shù)據(jù)進(jìn)行區(qū)分，根據(jù)不通仿真場(chǎng)景的計(jì)算和數(shù)據(jù)需求來分配資源，并優(yōu)化現(xiàn)有調(diào)度，提升仿真平臺(tái)效率。