日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機(jī)站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

從功能場景到邏輯場景：基于關(guān)鍵字的場景描述細(xì)化方法

2020-09-01 23:12:44·  來源：同濟(jì)智能汽車研究所  
　
編者按：智能駕駛汽車在開發(fā)和測試中用到的場景主要有三種類型：功能場景（Functional scenarios）、邏輯場景（Logical scenarios）和具體場景（Concrete scenar
編者按：智能駕駛汽車在開發(fā)和測試中用到的場景主要有三種類型：功能場景（Functional scenarios）、邏輯場景（Logical scenarios）和具體場景（Concrete scenarios）。功能場景在概念階段可用于項目定義、危險分析和風(fēng)險評估，邏輯場景是基于狀態(tài)空間變量對功能場景的進(jìn)一步詳細(xì)描述。在測試過程中，往往需要將功能場景轉(zhuǎn)換為邏輯場景，并轉(zhuǎn)換為可用于相應(yīng)仿真環(huán)境的數(shù)據(jù)格式（如VTD中的OpenDRIVE和OpenSCENARIO），本文主要介紹了一種在模擬環(huán)境中自動描述基于關(guān)鍵字的場景描述方法，并為測試用例生成提供了依據(jù)。
 
摘要：基于場景的開發(fā)和測試過程是驗證自動駕駛功能的一種很有前途的方法。為此，必須在開發(fā)過程中以可跟蹤的方式生成場景。在開發(fā)的早期階段，將要開發(fā)的項目的操作場景通常以抽象的語言方式描述。在輔助模擬測試過程的范圍內(nèi)，這些語言描述的場景必須轉(zhuǎn)換為狀態(tài)空間表示，并轉(zhuǎn)換為可用于相應(yīng)仿真環(huán)境的數(shù)據(jù)格式。目前，詳細(xì)描述場景的這一步需要大量的手動操作。此外，由于多個作者以及場景參數(shù)之間的許多約束，無法保證語言描述場景的標(biāo)準(zhǔn)化解釋和數(shù)據(jù)格式的一致轉(zhuǎn)換。本文提出了一種在模擬環(huán)境中自動描述基于關(guān)鍵字的場景描述方法，并為測試用例生成提供了依據(jù)。首先，將基于關(guān)鍵字的描述轉(zhuǎn)換為參數(shù)空間表示。同時，關(guān)于參數(shù)值的選擇和組合的約束被記錄在下面的過程步驟中（例如進(jìn)化或隨機(jī)測試方法）。第二步，將參數(shù)空間表示轉(zhuǎn)換為仿真環(huán)境所需的數(shù)據(jù)格式。以德國高速公路為例，將其轉(zhuǎn)換為OpenDRIVE（道路描述）和OpenSCENARIO（交通參與者和環(huán)境條件描述）兩種數(shù)據(jù)格式，在模擬環(huán)境虛擬試駕中執(zhí)行。

1 前言

在引入自動駕駛功能之前，必須保證特定的安全級別，駕駛員輔助系統(tǒng)一般通過基于距離的方法進(jìn)行測試。對于自動化程度更高的系統(tǒng)，Wachenfeld和Winner[1]提出了66.2億公里的測試?yán)锍?，以假設(shè)（50%的可能性）證明這些系統(tǒng)的性能是人類駕駛員的兩倍。因此，Wachenfeld和Winner得出結(jié)論，對于更高級別自動化系統(tǒng)的發(fā)布，基于距離的方法在經(jīng)濟(jì)上是不可接受的。因此，Schuldt[2]提出了一種基于場景的方法作為一種有前途的替代方法。

在基于場景的方法中，場景生成是安全論證的敏感步驟，對于系統(tǒng)的發(fā)布至關(guān)重要，因此必須系統(tǒng)地導(dǎo)出和記錄這些場景，而且它們必須沿著開發(fā)過程進(jìn)行跟蹤。為此，Menzel等[3]提出了場景表示的三個抽象層次：功能場景、邏輯場景和具體場景。功能場景以語言方式描述，這樣專家就可以在開發(fā)過程開始時討論場景；邏輯場景指定場景的參數(shù)并定義參數(shù)范圍；具體場景為每個參數(shù)指定一個具體值，是可重復(fù)測試用例的基礎(chǔ)。因此，這些抽象層次支持概念階段的活動、系統(tǒng)開發(fā)以及基于V模型的開發(fā)過程的測試活動，并為開發(fā)過程中場景的結(jié)構(gòu)化生成和使用奠定基礎(chǔ)，如圖1所示。
從功能場景到邏輯場景：基于關(guān)鍵字的場景描述細(xì)化方法
圖1 V模型開發(fā)過程中的場景[4]；HARA：危害分析和風(fēng)險評估

為了自動生成功能場景，Bagschik等[5]提出基于知識的方法，生成的場景使用定義的詞匯表和語法進(jìn)行描述，每個場景由起始場景和結(jié)束場景組成。對于從功能場景到邏輯場景的轉(zhuǎn)換，基于關(guān)鍵字的表示必須在參數(shù)空間表示中進(jìn)行詳細(xì)說明，并轉(zhuǎn)換為仿真環(huán)境的格式。在模擬順序控制的范圍內(nèi)，該步驟還包括起始場景和結(jié)束場景之間的交通參與者交互的說明。為了根據(jù)數(shù)據(jù)格式一致地模擬道路和交通參與者之間的交互作用，必須考慮參數(shù)和參數(shù)值之間的關(guān)系和依賴關(guān)系。

目前，場景細(xì)化和場景轉(zhuǎn)換的步驟需要大量的人工操作，特別是在多作者的情況下，無法確保語言場景的標(biāo)準(zhǔn)化解釋和符合模擬環(huán)境數(shù)據(jù)格式的一致表示。本文以德國高速公路場景為例，提出了一種從基于關(guān)鍵字的場景描述到參數(shù)空間表示的自動轉(zhuǎn)換方法，并將其轉(zhuǎn)換為仿真環(huán)境的格式。在參數(shù)空間表示中，對場景中元素和參數(shù)之間的關(guān)系和依賴關(guān)系進(jìn)行了建模，這是為了確保交通參與者的交互根據(jù)各自功能場景的規(guī)范進(jìn)行解析，并確保場景的實現(xiàn)與數(shù)據(jù)格式一致。對于道路網(wǎng)的表示，采用OpenDRIVE的數(shù)據(jù)格式；對于交通參與者和環(huán)境的表示，采用OpenSCENARIO的數(shù)據(jù)格式。

本文基于早期的德語版本[6]，結(jié)構(gòu)如下：第二節(jié)提供了基于知識的場景生成和基于所選相關(guān)工作的場景細(xì)化的背景；第三節(jié)介紹了一種方法，詳細(xì)描述用于在模擬環(huán)境中執(zhí)行的基于關(guān)鍵字的場景，并作為生成測試用例的基礎(chǔ)。在第四節(jié)中，評估了用于詳細(xì)描述場景的工具。最后，第五節(jié)指出了該方法的局限性，并給出了一個簡短的結(jié)論。

2 概率邏輯推理綜述

Schuldt等[7]提出一個基于場景的測試方法以及一個用于構(gòu)建場景的4層模型。Ulbrich等[8]提供了術(shù)語scene、situation和scenario的定義。Menzel等[3]使用這些定義作為基礎(chǔ)，并使用ISO 26262標(biāo)準(zhǔn)的例子，使用不同的符號來表示開發(fā)過程中的場景。因此，Menzel等[3]提出場景的三個抽象層次：功能場景、邏輯場景和具體場景。在本文中，術(shù)語參照Ulbrich等[8]和Menzel等[3]使用的定義。

目前，生成場景的過程有兩種方法——數(shù)據(jù)驅(qū)動和知識驅(qū)動，使用Menzel等[3]的術(shù)語，可以比較兩種方法，如圖2所示。

圖2 知識驅(qū)動和數(shù)據(jù)驅(qū)動的場景生成方法比較

數(shù)據(jù)驅(qū)動方法的主要思想是收集測量數(shù)據(jù)并識別和分類發(fā)生的場景。De Gelder等[10]提出了一種為虛擬測試（如硬件在環(huán)測試）生成真實測試用例的方法。為此，De Gelder等[10]收集真實場景，將這些場景參數(shù)化并存儲在數(shù)據(jù)庫中。對于現(xiàn)實生活中的場景，假設(shè)它們可以完全由感官和外部信息（如數(shù)字地圖和天氣數(shù)據(jù)）構(gòu)建，并舉例說明了參數(shù)化方法，但表示各自場景所需的參數(shù)沒有詳細(xì)描述。在將參數(shù)化的場景存儲到數(shù)據(jù)庫中之后，數(shù)據(jù)分布適合對場景參數(shù)進(jìn)行建模。這個表示描述了要測試的參數(shù)空間，包括每個參數(shù)的概率密度函數(shù)。遵循Menzel[3]等人的術(shù)語，這個表示相當(dāng)于一個邏輯場景。根據(jù)邏輯場景建模中的分布，de Gelder等[10]對新的（具體的）場景進(jìn)行采樣，并在模擬環(huán)境中執(zhí)行它們，這種抽樣構(gòu)成了蒙特卡羅模擬的基礎(chǔ)。然而，De Gelder等[10]的方法和類似的方法被歸類為數(shù)據(jù)驅(qū)動流程，因為所有生成的場景都是基于真實場景的，并且不會執(zhí)行場景的語義變化。

Pütz等[11]提出了一種類似的方法，該方法描述了工具鏈的概念，用于收集數(shù)據(jù)（例如測量數(shù)據(jù)和交通模擬數(shù)據(jù)），計算用于描述場景的指標(biāo)，并將其作為邏輯場景進(jìn)行聚類，提供這些邏輯場景作為生成測試用例的基礎(chǔ)。

Waymo LLC[12]提出了一種測試方法，其中記錄的部分試駕可以在模擬中再現(xiàn)，其中的參數(shù)如描述交通參與者的參數(shù)可以改變，這種方法需要試駕的測量數(shù)據(jù)以及高精度數(shù)字地圖。第一步，該方法將測量數(shù)據(jù)轉(zhuǎn)換為可在仿真環(huán)境中執(zhí)行的基于場景的表示；第二步，這些場景被泛化為后續(xù)參數(shù)變化的邏輯場景，用于生成具體場景的各個測試用例。

這三種方法來自于De Gelder[10]和Pütz等[11]，Waymo LLC[12]遵循虛擬測試范圍內(nèi)數(shù)據(jù)驅(qū)動測試過程的理念，對基于形式化知識的合成道路或場景的生成不進(jìn)行描述。對于那些純數(shù)據(jù)驅(qū)動的方法，有幾個挑戰(zhàn)。首先，測量數(shù)據(jù)并不能描述場景的所有方面，與De Gelder等[10]根據(jù)感官和外部數(shù)據(jù)構(gòu)建完整場景的假設(shè)相反，場景中會有一些被測量車輛的傳感器感知不到的元素（例如，由于距離限制）。此外，當(dāng)將基于場景的表示歸納為邏輯場景時，必須進(jìn)一步考慮知識來指定參數(shù)依賴關(guān)系。例如，在超車情況下，可以選擇不同的車輛速度，但超車車輛的速度必須始終高于被超越車輛的速度。在測試用例生成中，基于邏輯場景生成具體場景時，必須考慮這些約束。最后但并非最不重要的是，到目前為止，數(shù)據(jù)驅(qū)動方法沒有提供操作設(shè)計領(lǐng)域遇到的問題的信息，這些方法只對測試車輛遇到的情況進(jìn)行分組，并改變參數(shù)值。根據(jù)操作設(shè)計領(lǐng)域，沒有給出對所有可能的集群（語義變化）的引用。因此，這些基于數(shù)據(jù)的方法沒有提供關(guān)于情景多樣性的信息。

為了彌補上述問題，可以將數(shù)據(jù)驅(qū)動方法與知識驅(qū)動方法相結(jié)合，其主要思想是根據(jù)現(xiàn)有知識生成場景，如監(jiān)管建議，然后使用從測量數(shù)據(jù)中收集的信息來擴(kuò)展這些合成場景。作為生成功能場景的第一步，可用知識必須是結(jié)構(gòu)化的，用語言描述的，在語義層次上變化的。因此，Bagschik等[13]提出了一種基于知識的本體生成起始場景的方法。為了構(gòu)建本體中所表示的知識，Bagschik等人基于Schuldt等[7]的4層模型提出了5層模型。在后來的文章中，Bagschik等人擴(kuò)展了基于知識生成起始場景的概念，并以德國高速公路為例實現(xiàn)了基于知識的運行場景生成，每個操作場景包括起始場景和結(jié)束場景，在語義層（功能場景）上進(jìn)行語言描述，并使用Web本體語言（OWL）表示。為了將這些場景作為在虛擬測試范圍內(nèi)生成具體場景的基礎(chǔ)，Bagschik等人生成的功能場景必須轉(zhuǎn)換成可在模擬環(huán)境中執(zhí)行的符號。

對于自動駕駛功能的模擬測試，可提供多種模擬環(huán)境，例如dSPACE GmbH的ASM Traffic、IPG Automotive GmbH的Automotive或VIRES Simulationstechnologie GmbH的虛擬試駕（VTD）。這些仿真環(huán)境使用不同的數(shù)據(jù)格式來描述場景。

本文提出的工具將功能場景轉(zhuǎn)換為仿真環(huán)境虛擬試駕（VTD）的數(shù)據(jù)格式。對于道路網(wǎng)絡(luò)的描述，VTD要求數(shù)據(jù)格式為OpenDRIVE；對于交通參與者和環(huán)境的描述，VTD驅(qū)動使用基于事件的數(shù)據(jù)格式OpenSCENARIO。

有些文章描述了基于事件的場景表示。Bach等[14]描述了概念和原型實現(xiàn)，用于抽象表示具體場景，特別是交通參與者之間的交互，這個概念是基于將每個場景劃分為多個行為和事件，實現(xiàn)了與數(shù)據(jù)格式OpenSCENARIO類似的交通參與者交互結(jié)構(gòu)。Xiong[15]提出了一種模擬環(huán)境中基于知識庫的場景編排，在本體的幫助下表示場景中動作和事件的序列，本體詳細(xì)描述了道路網(wǎng)絡(luò)的要素和交通參與者之間的交互作用以及要使用的模型（例如駕駛員模型），如有必要可根據(jù)駕駛環(huán)境的功能和順序調(diào)整駕駛場景，該方法明確定義了被測車輛，使用本體來控制其他交通參與者完成場景中定義的場景。因此，Bach和Xiong為具體的場景和測試用例提供了基于事件的記法，但沒有描述將基于關(guān)鍵字的場景描述自動細(xì)化到基于事件的場景描述作為測試用例生成的基礎(chǔ)的方法，然而，這兩篇文章都有助于虛擬測試范圍內(nèi)邏輯場景的結(jié)構(gòu)化和建模。本文介紹的概念和實現(xiàn)使用了Bagschik等生成的功能場景作為場景細(xì)化和轉(zhuǎn)換為OpenDRIVE和OpenSCENARIO數(shù)據(jù)格式的起點。

3 細(xì)化在模擬環(huán)境中執(zhí)行的基于關(guān)鍵字的場景描述

從基于關(guān)鍵字的場景描述到用于在仿真環(huán)境中執(zhí)行的格式的轉(zhuǎn)換分兩步實現(xiàn)，如圖3所示。流程的起點是使用功能場景，每個功能場景都是基于關(guān)鍵字的語義描述，并使用Web本體語言（OWL）進(jìn)行建模。Bagschik等[5]描述了功能場景的生成。
圖3 場景轉(zhuǎn)換過程概述，矩形代表工作產(chǎn)品，圓角代表過程步驟

在細(xì)化中，功能場景被導(dǎo)入并轉(zhuǎn)換為參數(shù)空間表示，各個功能場景的每個術(shù)語（如“車”或“跟”）通過參數(shù)詳細(xì)指定，通過檢查哪些參數(shù)必須在模擬的數(shù)據(jù)格式中定義來表示相應(yīng)的元素，從而推導(dǎo)出參數(shù)。此外，還對參數(shù)之間的依賴關(guān)系以及參數(shù)值選擇的約束進(jìn)行了建模。這些依賴和約束產(chǎn)生于功能場景中指定的參數(shù)和交互作用的物理關(guān)系，以及模擬數(shù)據(jù)格式的要求。

在格式轉(zhuǎn)換中，對于每種數(shù)據(jù)格式，需要從參數(shù)空間表示中提取所需的信息，并轉(zhuǎn)換成相應(yīng)數(shù)據(jù)格式指定的語法。此外，選擇參數(shù)值的約束被記錄為附加文件中的一組規(guī)則，給接下來的過程步驟（例如測試用例生成）提供生成有效參數(shù)值組合的基礎(chǔ)。然后，對于每個參數(shù)，根據(jù)定義的規(guī)則集選擇一個默認(rèn)值。轉(zhuǎn)換后的場景確定要更改的參數(shù)，形式化它們在模擬環(huán)境中執(zhí)行的意義，并為每個參數(shù)定義一個符合規(guī)則的有效的默認(rèn)值。因此，根據(jù)Menzel等[3]的定義，提取的場景為邏輯場景奠定了基礎(chǔ)。本文沒有介紹根據(jù)定義的測試概念為每個邏輯場景生成具體場景的代表性樣本。

A. 場景細(xì)化

語義場景表示是場景細(xì)化的基礎(chǔ)，采用OWL數(shù)據(jù)格式進(jìn)行建模。功能場景利用定義的詞匯以及詞匯之間的語義關(guān)系來描述道路等級、交通基礎(chǔ)設(shè)施、可移動物體和環(huán)境條件，道路等級和交通基礎(chǔ)設(shè)施的詞匯由Bagschik等人[5]定義，參考德國標(biāo)準(zhǔn)《如何修建高速公路》[16]。對于交通參與者之間的相互作用的描述，Bagschik等人[5]使用Reschka[17]基于Tölle[18]和Nagel and Enkelmann[19]定義的策略。

細(xì)化的第一步是根據(jù)5層模型[13]構(gòu)造用于場景描述的術(shù)語，每一項都用參數(shù)來擴(kuò)充，這些參數(shù)詳細(xì)地指定了相應(yīng)的元素，如圖4所示。描述每個元素所需的參數(shù)取決于仿真環(huán)境的數(shù)據(jù)格式。因此，在本文的研究范圍內(nèi)，參數(shù)是從仿真環(huán)境VTD所使用的OpenDRIVE和OpenSCENARIO的數(shù)據(jù)格式規(guī)范中得來的。數(shù)據(jù)格式OpenDRIVE描述了道路網(wǎng)絡(luò)，從而描述了5層模型的前三層。數(shù)據(jù)格式OpenSCENARIO描述了交通參與者之間的交互作用以及環(huán)境條件，從而描述了5層模型的第4層和第5層。
圖4 Bagschik等[13]基于Schuldt[2]提出的5層模型到結(jié)構(gòu)場景，藍(lán)框表示功能場景中的關(guān)鍵字，Y形方框根據(jù)模擬的數(shù)據(jù)格式表示參數(shù)。

在OpenSCENARIO中，交通參與者的軌跡通過動作（策略和模擬控制的進(jìn)一步命令）和觸發(fā)這些動作的事件來描述。在功能場景中，每輛車的運動通過其在起始和結(jié)束場景中與其他交通參與者的相對位置以及要執(zhí)行的策略來描述。為了借助OpenSCENARIO中的參數(shù)來表示功能場景中定義的策略，必須將交通參與者的交互轉(zhuǎn)換為基于事件的表示，如圖5所示。因此，在功能場景中定義的策略是通過附加的設(shè)計元素（如動作和事件）來詳細(xì)說明的。

圖5 通過基于事件的表示法對交通參與者之間交互的時間順序的規(guī)范

細(xì)化的第二步是建立元素之間的關(guān)系和約束以及元素的參數(shù)，已經(jīng)確定了三類關(guān)系，用于場景描述：排列關(guān)系、對象依賴和參數(shù)依賴。這三種關(guān)系相互獨立，關(guān)注場景的不同方面。

排列關(guān)系描述了元素之間的相對位置。為此，場景的所有對象都表示為圖表結(jié)構(gòu)中的節(jié)點。在圖表里邊的幫助下，相鄰或相互作用的對象被設(shè)置成關(guān)系。其中，排列關(guān)系包括從車道到路段的映射、路段內(nèi)車道的排列、交通參與者在道路上的位置以及交通參與者之間的相對位置。Bagschik [5]提出的功能場景詞匯已經(jīng)描述了排列關(guān)系，以便可以直接進(jìn)行轉(zhuǎn)換。

對象依賴關(guān)系描述了每個場景的對象之間的依賴關(guān)系。每個對象依賴關(guān)系都包含一組規(guī)則，這些規(guī)則描述了鏈接對象的參數(shù)之間要滿足的約束，要求滿足功能場景的條件或滿足仿真環(huán)境的數(shù)據(jù)格式的要求。例如，在Bagschik等[5]描述的功能場景中，借助策略在語義層面上描述了交通參與者之間的交互作用。為了在參數(shù)水平上實施策略，超車車輛的速度必須高于前方車輛的速度。另外，在OpenDRIVE中，多條車道被構(gòu)造為路段，并組合在一起形成道路網(wǎng)。由于這種結(jié)構(gòu)，連續(xù)車道在其連接點處必須具有相同的車道寬度。

參數(shù)依賴關(guān)系描述一個對象的參數(shù)之間的依賴關(guān)系，故一個參數(shù)可以受同一對象的一個或多個參數(shù)的影響。參數(shù)依賴性描述了在選擇和組合參數(shù)值時要滿足的條件，這些條件是由標(biāo)準(zhǔn)或物理關(guān)系決定的。例如，在Bagschik[5]等描述的功能場景中，道路的立面輪廓采用德國標(biāo)準(zhǔn)《如何修建高速公路》[16]中的設(shè)計模式進(jìn)行建模，如平面、凹形曲線或凸形曲線，波峰曲線的長度不能獨立于初始和最終傾斜，而是必須根據(jù)施工標(biāo)準(zhǔn)進(jìn)行計算，如圖6所示。因此，參數(shù)依賴性有助于根據(jù)管理準(zhǔn)則和物理依賴性選擇單個對象的參數(shù)值。

圖6 用排列關(guān)系以及對象和參數(shù)依賴關(guān)系擴(kuò)充參數(shù)空間，波峰的切線長度T必須根據(jù)半徑R以及初始傾斜s1和最終傾斜s2進(jìn)行計算

B.格式轉(zhuǎn)換

格式轉(zhuǎn)換是指將參數(shù)空間表示中建模的信息轉(zhuǎn)換為OpenDRIVE和OpenSCENARIO的數(shù)據(jù)格式。第一步，利用OpenDRIVE生成道路表示，將5層模型的第1層到第3層的元素轉(zhuǎn)換為OpenDRIVE格式的語法。同時，將根據(jù)參數(shù)空間表示中模型約束計算出有效默認(rèn)值分配給每個參數(shù)。

第二步，生成OpenSCENARIO中交通參與者和環(huán)境條件的表示，將5層模型的第四層和第五層的元素轉(zhuǎn)換成OpenSCENARIO格式的語法，并賦予參數(shù)有效的初始值。因此，將先前生成的OpenDRIVE文件作為道路表示的參考。此外，用于計算每個參數(shù)的默認(rèn)值的規(guī)則集記錄在另一個文件中。通過這種方式，可以在以下過程步驟中使用規(guī)則集來生成有效的參數(shù)值組合，例如作為測試用例生成的一部分。

4 評價

在本節(jié)中，將檢查生成的OpenDRIVE和OpenSCENARIO文件。由于缺少設(shè)備和測試的度量以及一組聯(lián)合場景，此檢查形式上不是評估，而是提示場景是否正確轉(zhuǎn)換。為此，根據(jù)Bagschik等[5]提出的基于知識的方法生成功能場景，然后利用本文提出的工具，將生成的場景自動轉(zhuǎn)換為參數(shù)空間表示，并轉(zhuǎn)換為OpenDRIVE和OpenSCENARIO格式，對于這兩種格式，分別選擇和評估測試場景。

A. OpenDRIVE

為了描述道路網(wǎng)絡(luò)，功能場景的詞匯表包括立面輪廓（如傾斜或下降）、線形（如直線或曲線）和車道類型（如硬路肩或行車車道）的多種變化。此外，還描述了交通基礎(chǔ)設(shè)施的各種要素（如交通標(biāo)志或護(hù)欄），這些要素的不同組合可以生成大量不同的路段。在Bagschik等[5]的基于知識的場景生成中，每個功能場景的路網(wǎng)僅由一個路段組成，目前尚未將連續(xù)路段與較長道路相結(jié)合，因此限制了用于評估的輸入數(shù)據(jù)的多樣性。

在OpenDRIVE格式中，只有連續(xù)的路段和車道之間存在依賴關(guān)系，道路橫斷面的設(shè)計元素（如立面輪廓和道路幾何圖形）可以獨立指定。由于生成的功能場景的每個路網(wǎng)僅由一個路段組成，因此并非所有可能的組合都必須進(jìn)行測試。對于評估，只需測試道路描述的每個單字是否正確映射（根據(jù)OpenDRIVE格式中所需的類和屬性）到OpenDRIVE數(shù)據(jù)格式。因此，為了進(jìn)行評估，我們選擇了所有五個場景中的所有場景，這些場景利用了完整的道路描述詞匯。

OpenDRIVE文件分兩步評估。第一步，根據(jù)指定的功能場景檢查生成的道路的執(zhí)行情況，以及參數(shù)化是否符合標(biāo)準(zhǔn)。例如，在OpenDRIVE查看器的幫助下，通過檢查坐標(biāo)方向來評估幾何體（線形和立面輪廓）（見圖7a）。第二步，將道路描述加載到VTD中（見圖7b），并檢查是否顯示了所有三維圖形，以及是否正確連接了所有車道。因此，定義了一個虛擬車輛沿模型路線行駛，通過該程序，道路描述的參數(shù)空間是根據(jù)各自的功能場景和給定的標(biāo)準(zhǔn)生成的，并被正確地轉(zhuǎn)換成OpenDRIVE數(shù)據(jù)格式。

(a) OpenDRIVE查看器中顯示的OpenDRIVE軌跡 

(b) VTD中顯示的OpenDRIVE軌跡
圖7 在OpenDRIVE Viewer和VTD中顯示了彎道三車道高速公路的下坡、限速和護(hù)欄

B.OpenSCENARIO

描述交通參與者的功能場景詞匯包括各種車輛類型（如汽車或卡車）和策略（如變道或超車），利用車道相對位置網(wǎng)格將車輛的位置相互關(guān)聯(lián)。此外，還根據(jù)不同的天氣條件（如雨或晴天）和一天中的不同時間（如上午或中午）描述了不同的環(huán)境特征。

OpenSCENARIO文件也分兩步進(jìn)行評估。第一步，生成的OpenSCENARIO文件在靜態(tài)測試中與模式文件進(jìn)行檢查，將每個OpenSCENARIO文件的語法與OpenSCENARIO數(shù)據(jù)格式的格式規(guī)范進(jìn)行比較，這樣可以識別缺失的元素和屬性。對于使用模式文件的靜態(tài)測試，選擇了六個場景，其中包括實現(xiàn)Bagschik等[5]生成的功能場景詞匯表所需的所有OpenSCENARIO設(shè)計元素。檢查表明，根據(jù)數(shù)據(jù)格式規(guī)范，功能場景被轉(zhuǎn)換為OpenSCENARIO文件；然而，這樣的靜態(tài)測試并不能揭示功能場景中定義的所有元素是否都在相應(yīng)的OpenSCENARIO文件中實現(xiàn)并使用有效的默認(rèn)值初始化。

因此，第二步是在模擬環(huán)境中加載和執(zhí)行OpenSCENARIO文件，檢查每個生成的OpenSCENARIO文件是否根據(jù)各自的功能場景在模擬中執(zhí)行。在本次測試中，主要問題有：

·  所有車輛是否在起始場景中定義的位置啟動？

·  每輛車的行為是否符合起始場景中定義的策略？

·  所有策略是否在正確的時間點開始和結(jié)束，以便不會造成碰撞？

·  所有車輛在完成策略后是否都在結(jié)束場景中定義的位置結(jié)束？

為了為測試創(chuàng)建輸入數(shù)據(jù)，作者使用Bagschik等[5]描述的方法生成了10000多個功能場景，大量的場景無法手動評估，因此作者定義了9個測試目標(biāo)，并基于這9個目標(biāo)選擇了要測試的相關(guān)場景，每個測試目標(biāo)都描述了細(xì)化和轉(zhuǎn)換場景的程序的一部分（例如計算交通參與者的起始速度），這是應(yīng)該被明確檢查的。此外，每個測試目標(biāo)都定義了一個測試草圖，它描述了可用于檢查各個測試目標(biāo)的粗略結(jié)構(gòu)和場景提要。根據(jù)測試目標(biāo)，總共選擇了30個場景，并在仿真環(huán)境中正確執(zhí)行（按照各自功能場景中指定的）。
 
5 結(jié)論與展望

本文提出了一種將基于關(guān)鍵字的場景描述轉(zhuǎn)換為仿真格式的方法，每個基于關(guān)鍵字的場景被轉(zhuǎn)換為參數(shù)空間表示，然后轉(zhuǎn)換為OpenDRIVE和OpenSCENARIO的數(shù)據(jù)格式，自動生成的場景根據(jù)指定的功能場景在仿真中進(jìn)行了評估和執(zhí)行。

Bagschik等[5]提出的基于知識的場景生成實現(xiàn)了場景的語義變化，為邏輯場景的建立奠定了基礎(chǔ)。與數(shù)據(jù)驅(qū)動方法相結(jié)合，這些邏輯場景可以作為從測量數(shù)據(jù)中聚類場景的基礎(chǔ)。此外，這些邏輯場景可以為場景的多樣性建立一個參考，從而確保場景的語義變化很廣泛。

然而，所提出的方法有一些局限性。首先，在功能場景和為仿真生成的數(shù)據(jù)文件中，只定義了通過仿真控制的車輛，未來必須增加通過自動駕駛功能控制的車輛標(biāo)準(zhǔn)。由于被測系統(tǒng)的未定義行為而產(chǎn)生的自由度可能會導(dǎo)致不必要的策略和交互順序，在模擬的順序控制中必須考慮這些可能的行動方案，因此必須在模擬的數(shù)據(jù)文件中加以描述。

此外，在當(dāng)前的執(zhí)行中，將關(guān)鍵字細(xì)化到參數(shù)空間和從關(guān)鍵字中導(dǎo)出約束的知識直接在源代碼中建模。在開發(fā)過程中可跟蹤的場景生成的范圍內(nèi)，這些知識應(yīng)該顯式地建模，例如作為一個本體；當(dāng)場景變得更加復(fù)雜（關(guān)系和約束的數(shù)量不斷增加）時，這一點變得更加重要。如上所述，當(dāng)定義測試中的系統(tǒng)或在更復(fù)雜的領(lǐng)域（如城市地區(qū)）中指定場景時，就是這種情況。

另一個可能的局限是對約束的定義，它確保生成的場景在物理上是合理的，必須仔細(xì)選擇這些約束條件，以確保只排除不相關(guān)的場景。

參考文獻(xiàn)：
 
 
END
 
 
分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25