ADAS軟件測(cè)試的代碼生成器

摘要

現(xiàn)代汽車使用先進(jìn)的電子系統(tǒng)來(lái)幫助駕駛員完成駕駛過(guò)程，即所謂的高級(jí)駕駛員輔助系統(tǒng) (ADAS)。ADAS系統(tǒng)用于自動(dòng)化、定制和改進(jìn)車輛內(nèi)的系統(tǒng)，以實(shí)現(xiàn)更高的安全性和更好的駕駛體驗(yàn)。由于ADAS系統(tǒng)本身會(huì)對(duì)駕駛過(guò)程、車輛和駕駛員產(chǎn)生重大影響，因此必須在許多行業(yè)標(biāo)準(zhǔn)范圍內(nèi)對(duì)其進(jìn)行徹底測(cè)試和開(kāi)發(fā)。他們工作的關(guān)鍵因素是各個(gè)系統(tǒng)組件之間的通信。這種標(biāo)準(zhǔn)化的通信是測(cè)試所必需的，通常通過(guò)開(kāi)發(fā)汽車開(kāi)放系統(tǒng)架構(gòu) (AUTOSAR) 通信測(cè)試來(lái)執(zhí)行。由于ADAS測(cè)試可能是一個(gè)相當(dāng)復(fù)雜和耗時(shí)的過(guò)程，因此自動(dòng)測(cè)試是在一個(gè)適當(dāng)?shù)臏y(cè)試環(huán)境中進(jìn)行的。本文介紹了現(xiàn)有的ADAS環(huán)境測(cè)試系統(tǒng)，它為AUTOSAR架構(gòu)的中間層(Middleware)中的通信仿真生成了一個(gè)測(cè)試環(huán)境。測(cè)試環(huán)境生成器(TEG)是一個(gè)用于處理ARXML測(cè)試文件的Python程序，在此基礎(chǔ)上，它以C編程語(yǔ)言的獨(dú)立組件的形式生成測(cè)試環(huán)境模型。該程序包括輸入數(shù)據(jù)解析、解析數(shù)據(jù)存儲(chǔ)和構(gòu)建測(cè)試環(huán)境的組件生成。根據(jù)檢測(cè)到的現(xiàn)有TEG的缺點(diǎn)，提出了一些修改意見(jiàn)，以加快其執(zhí)行時(shí)間，并以數(shù)據(jù)庫(kù)的形式引入更強(qiáng)大和穩(wěn)定的數(shù)據(jù)存儲(chǔ)方法。

I.簡(jiǎn)介

ADAS系統(tǒng)是協(xié)助司機(jī)駕駛車輛的電子系統(tǒng)。ADAS系統(tǒng)可以直接影響汽車的一些部件，目的是為了從完成更安全和更舒適的駕駛的角度開(kāi)發(fā)各種有用的功能：從自動(dòng)點(diǎn)火燈和交通標(biāo)志識(shí)別到與智能手機(jī)的整合。ADAS通信系統(tǒng)運(yùn)行的一個(gè)關(guān)鍵因素是其組件之間的通信。利用該傳感器，汽車的計(jì)算機(jī)系統(tǒng)接收有關(guān)汽車周邊環(huán)境的信息，即感知環(huán)境。這些傳感器是激光雷達(dá)、雷達(dá)、照相機(jī)和超聲波傳感器等。傳感器提供的信息由適當(dāng)?shù)?a target="_blank">算法處理，并獲得所需的輸出：自動(dòng)剎車、根據(jù)檢測(cè)到的限速標(biāo)志對(duì)車輛進(jìn)行減速、司機(jī)監(jiān)控、交通線檢測(cè)和警告司機(jī)越線，等等。由于ADAS系統(tǒng)本身會(huì)對(duì)交通、車輛和駕駛者本身產(chǎn)生重大影響，它們必須經(jīng)過(guò)詳細(xì)的測(cè)試并適應(yīng)嚴(yán)格的標(biāo)準(zhǔn)。在 ADAS 中實(shí)施的軟件系統(tǒng)必須結(jié)構(gòu)穩(wěn)健且能夠適應(yīng)變化，具有標(biāo)準(zhǔn)化的代碼慣例，最重要的是，其測(cè)量和結(jié)果必須保持一致。

需要對(duì)標(biāo)準(zhǔn)化的通信進(jìn)行測(cè)試，最好是在系統(tǒng)內(nèi)開(kāi)發(fā)測(cè)試代碼，以測(cè)試AUTOSAR的通信模型。AUTOSAR是一個(gè)由汽車公司組成的國(guó)際伙伴關(guān)系，其目的是在汽車開(kāi)發(fā)環(huán)境中的軟件和硬件架構(gòu)創(chuàng)建中引入標(biāo)準(zhǔn)化。該測(cè)試環(huán)境允許在汽車計(jì)算機(jī)系統(tǒng)上工作的工程師能夠?qū)崿F(xiàn)流程和程序的自動(dòng)化，否則由于物流和時(shí)間的限制，這些流程和程序是不可能人工完成的。它還允許他們對(duì)系統(tǒng)進(jìn)行壓力測(cè)試，而不必使用實(shí)際的組件并冒著失敗的風(fēng)險(xiǎn)。一個(gè)高質(zhì)量的測(cè)試環(huán)境是至關(guān)重要的，因?yàn)椴徽_的汽車部件模擬或不正確的數(shù)據(jù)處理會(huì)導(dǎo)致代碼在實(shí)際執(zhí)行中出現(xiàn)災(zāi)難性的故障。因此，模擬測(cè)試環(huán)境是一個(gè)細(xì)致和耗時(shí)的過(guò)程，但對(duì)于開(kāi)發(fā)ADAS系統(tǒng)是必不可少的。

本文對(duì)測(cè)試ADAS系統(tǒng)的軟件解決方案進(jìn)行了升級(jí)，重點(diǎn)是通信。所提出的解決方案使用創(chuàng)建的發(fā)生器和測(cè)試環(huán)境來(lái)測(cè)試汽車中或 ECU 的 CPU 內(nèi)部的控制單元之間的通信。所提出的解決方案是基于加速現(xiàn)有的測(cè)試環(huán)境生成過(guò)程的方法，主要是在多個(gè)計(jì)算機(jī)進(jìn)程中同時(shí)分配程序工作，但也可以使用在多個(gè)程序運(yùn)行中消除冗余的解決方案。因此，增強(qiáng)的程序允許在現(xiàn)代多核處理器上對(duì)程序的整體運(yùn)行進(jìn)行多重加速，并能夠跳過(guò)部分程序以節(jié)省時(shí)間。

本文由五部分組成。第 2 節(jié)介紹了現(xiàn)有的測(cè)試環(huán)境生成器 (TEG) 及其實(shí)現(xiàn)方法。第 3 節(jié)中給出了對(duì)現(xiàn)有 TEG 的改進(jìn)建議的詳細(xì)信息。第 4 節(jié)介紹了使用改進(jìn)后的 TEG 獲得的結(jié)果，并附有討論。最后給出了結(jié)論和對(duì)未來(lái)工作的建議。

II.測(cè)試環(huán)境生成器

用于汽車測(cè)試的測(cè)試環(huán)境生成器是基于AUTOSAR環(huán)境，有助于測(cè)試汽車系統(tǒng)和部件之間的通信。AUTOSAR采用三層架構(gòu)：

基礎(chǔ)軟件：一套標(biāo)準(zhǔn)化的軟件模塊，包含操作頂層、應(yīng)用層所需的服務(wù)。

RTE：用于交換信息的中間層，即基礎(chǔ)層和應(yīng)用層之間的通信。

應(yīng)用層：與 RTE 通信的應(yīng)用軟件組件。

TEG位于AUTOSAR通信的中間層。輸入端的 TEG 收集特定 ECU 的信號(hào)數(shù)據(jù)，并以此為基礎(chǔ)在輸出端生成通信環(huán)境模型。本節(jié)更詳細(xì)地描述了 TEG 的工作。更確切地說(shuō)，本節(jié)分析了一個(gè)具體的現(xiàn)有解決方案，并在隨后的章節(jié)中提出了修改意見(jiàn)。

A. 基于AUTOSAR的通信

ARXML(AUTOSAR XML)是一種特殊類型的XML文件，專門用于汽車開(kāi)發(fā)環(huán)境，用于存儲(chǔ)有關(guān)所使用的通信輸入和輸出的數(shù)據(jù)、發(fā)送的數(shù)據(jù)包和處理這些數(shù)據(jù)的軟件組件。ARXML模式是XML數(shù)據(jù)語(yǔ)言的特殊定義，用于交換AUTOSAR通信模型，其中包含信號(hào)類型、組件和輸入輸出端口信息。它是一個(gè)W3C矩陣，定義了AUTOSAR模型交換的語(yǔ)言。該矩陣源于AUTOSAR的主要描述性模型，并定義了AUTOSAR的數(shù)據(jù)交換格式。

ARXML 文檔表示單個(gè) ECU 的配置，該ECU解釋了它使用的原始數(shù)據(jù)類型。它代表了每個(gè)ECU在兩個(gè)或多個(gè)ECU之間通信時(shí)使用的特定端口、軟件組件和信號(hào)。因此，ARXML定義了特定ECU通信所需的所有數(shù)據(jù)類型，從基本類型(int, float, string)到更復(fù)雜的類型(list, objects)。使用基本類型，ARXML以信號(hào)和發(fā)送這些信號(hào)的相關(guān)端口的形式建立了一個(gè)通信的數(shù)據(jù)模型。它還包含了進(jìn)一步處理數(shù)據(jù)所需的軟件組件清單。

ECU ARXML 文件是深度 XML 文件，其大小可能因 ECU 和應(yīng)用程序而異，從幾千字節(jié)到幾百兆字節(jié)不等。這些文件中的數(shù)據(jù)從原始數(shù)據(jù)類型開(kāi)始描述,然后ARXML 中的所有其他數(shù)據(jù)定義都引用到這些原始數(shù)據(jù)類型。

B. 測(cè)試環(huán)境發(fā)生器的工作原理

為了使用從ECU收集的信息來(lái)測(cè)試ECU模型，有必要將信號(hào)和通信分解成有意義的單元和軟件組件(SWC)之間的關(guān)系，在此基礎(chǔ)上可以生成一個(gè)測(cè)試環(huán)境。這就是 TEG 的任務(wù)。來(lái)自ARXML的分類數(shù)據(jù)首先被收集在一個(gè)復(fù)雜的數(shù)據(jù)結(jié)構(gòu)中，該結(jié)構(gòu)是在程序環(huán)境中創(chuàng)建的。所創(chuàng)建的結(jié)構(gòu)比.arxml文件的訪問(wèn)速度更快，它形成了一個(gè)內(nèi)部數(shù)據(jù)源，需要識(shí)別特定的代碼，這些代碼需要注入到共同構(gòu)成模型的軟件組件(SWC)的特定和預(yù)先確定的代碼片段中。在TEG的輸入文件中，有一個(gè)包含模板的.c文件，這些模板被輸送到由特定ECU配置預(yù)定義的SWCs中 。根據(jù)從ARXML文件中收集的數(shù)據(jù)，確定必要的模板(具體到每個(gè)SWC)，然后將變量和值添加到SWC的模板中。

C. 現(xiàn)有解決方案的架構(gòu)

現(xiàn)有的測(cè)試環(huán)境生成器有一個(gè)解析的文件結(jié)構(gòu)，程序代碼與生成的數(shù)據(jù)、數(shù)據(jù)庫(kù)和輸入分開(kāi)。每次TEG運(yùn)行時(shí)，它都會(huì)檢查相應(yīng)的.ini文件中配置的文件結(jié)構(gòu)的布局。生成器代碼本身被分成幾個(gè)相關(guān)的函數(shù)，構(gòu)成了前面提到的實(shí)體，并以Python編程語(yǔ)言實(shí)現(xiàn)。ython 2.7 版與其標(biāo)準(zhǔn)庫(kù)一起使用，并帶有一個(gè)用于解析 XML 和結(jié)構(gòu)相似的文件類型的附加模塊 - LXML。解析后的數(shù)據(jù)存儲(chǔ)是通過(guò)Python的標(biāo)準(zhǔn)Pickle模塊完成的，隨同生成的XML用于對(duì)解析后的數(shù)據(jù)的修訂。程序生成器的組件使用存儲(chǔ)的數(shù)據(jù)將代碼片段放置在的用 C 編程語(yǔ)言編寫的主 .c 文件中的模板中指定位置 (較小的C類文件，代表構(gòu)成模型的組件)。然后，同樣的代碼被TEG再次傳遞過(guò)去，特定的變量或數(shù)值被放入片段中。因此，TEG被分為三個(gè)主要部分：

1) 解析器

解析器的目的是提取特定ECU的配置數(shù)據(jù)，在此基礎(chǔ)上生成模型。解析器接收.arxml文件形式的數(shù)據(jù)，瀏覽其結(jié)構(gòu)，并將解析后的數(shù)據(jù)以復(fù)雜的數(shù)據(jù)結(jié)構(gòu)形式存儲(chǔ)，并在整個(gè)TEG中進(jìn)一步使用?，F(xiàn)有的TEG的核心組件是一個(gè)高度復(fù)雜的Python對(duì)象，它由結(jié)構(gòu)化的預(yù)定義類的模板初始化，這些模板都相互引用并形成底層對(duì)象，即所謂TOM。TOM反映了ARXML的層次結(jié)構(gòu)，它從層次結(jié)構(gòu)中最高的對(duì)象開(kāi)始，稱為根--TOM根。TOM根，連同ARXML文件的位置，被作為參數(shù)傳遞給解析函數(shù)，該函數(shù)迭代地通過(guò)ARXML中的所有數(shù)據(jù)，并通過(guò)邏輯分支將它們存儲(chǔ)在TOM子對(duì)象中。TOM的架構(gòu)與ARXML的架構(gòu)密切相關(guān)，它限制了解析器在XML格式中的順序傳遞，使其速度變慢，因?yàn)锳RXML架構(gòu)需要由Python架構(gòu)紀(jì)實(shí)地表示出來(lái)，而且隨著ARXML文件越來(lái)越大，這一任務(wù)會(huì)成倍增加。

當(dāng)所有來(lái)自ARXML的相關(guān)數(shù)據(jù)被傳輸?shù)絋OM Root時(shí)，解析器的操作就被認(rèn)為是完成了，然后TOM Root被存儲(chǔ)在RAM中供將來(lái)參考。

2) 數(shù)據(jù)存儲(chǔ)

從.arxml文件解析出來(lái)的數(shù)據(jù)被儲(chǔ)存起來(lái)，以便在出現(xiàn)錯(cuò)誤或調(diào)整時(shí)進(jìn)一步檢查輸入數(shù)據(jù)的有效性，并作為備份。收集的數(shù)據(jù)代表了TEG的生成器組件進(jìn)一步運(yùn)行所需的所有數(shù)據(jù)。

TEG的現(xiàn)有解決方案依賴于用于序列化存儲(chǔ)的標(biāo)準(zhǔn)Python模塊--Pickle。存儲(chǔ)函數(shù)在解析器函數(shù)之后啟動(dòng)，并接收TOM Root和所需的.pickle文件的存儲(chǔ)位置作為參數(shù)。有了這個(gè)功能，整個(gè)TOM Root被序列化為上述文件，即使在執(zhí)行程序后，該文件仍被永久存儲(chǔ)在輸出目錄中。

除了pickle功能外，TOM Root還以復(fù)雜的XML格式存儲(chǔ)，作為一個(gè)次要的、更容易被人閱讀的來(lái)源。這樣做的目的是為了更容易調(diào)整程序，也更容易排除潛在的錯(cuò)誤。XML存儲(chǔ)功能，很像一個(gè)解析器，使用邏輯分支和遞歸，將TOM內(nèi)容解析為鏈接的XML部分。XML文件也是用LXML模塊生成的。

3) 代碼生成器

從.arxml文檔中解析出來(lái)的數(shù)據(jù)被注入到模板和軟件組件中實(shí)現(xiàn)的C代碼的特定切口中，同時(shí)還有變量的相應(yīng)值。

測(cè)試代碼生成函數(shù)接收 TOM Root 和主 .c 文件的位置作為參數(shù)，其中包含模板和所需的 SWC 組件，也是 .c 文件的形式。它使用正則表達(dá)式(RegEx)方法將TOM數(shù)據(jù)邏輯地過(guò)濾成上述模板，即代碼片斷。然后將模板插入到SWC .c文件中預(yù)定義的位置。

發(fā)電機(jī)操作是迄今為止要求最高的TEG組件，其運(yùn)行時(shí)間取決于輸入文件的大小。生成器還被設(shè)計(jì)為在組裝模型組件時(shí)按順序使用RegEx，因?yàn)檩斎肓吭黾?，這對(duì)程序性能(就時(shí)間而言)產(chǎn)生了負(fù)面影響。

III.測(cè)試環(huán)境生成器的改進(jìn)

本文的基本目的是加速現(xiàn)有的TEG。隨著輸入數(shù)據(jù)的增加，整個(gè)程序的執(zhí)行時(shí)間會(huì)明顯增加，這是一個(gè)實(shí)際問(wèn)題。此外，目標(biāo)是創(chuàng)造一種更穩(wěn)定的數(shù)據(jù)庫(kù)存儲(chǔ)形式，而不是將數(shù)據(jù)序列化作為一種存儲(chǔ)方法。具體來(lái)說(shuō)，對(duì)升級(jí)版的TEG的要求是：

加速現(xiàn)有的TEG，使其在解析和生成輸出文件方面花費(fèi)更少的時(shí)間。

利用更穩(wěn)定和透明的存儲(chǔ)方法。

擬議的解決方案是通過(guò)對(duì)現(xiàn)有解決方案實(shí)施代碼更改來(lái)實(shí)現(xiàn)的。

這些變化是針對(duì)程序的每一部分的，但其結(jié)構(gòu)和執(zhí)行順序保持不變。因此，提議的解決方案使用Python 2.7。TEG在啟動(dòng)時(shí)檢查.ini配置文件，該文件包含一個(gè)獨(dú)特的哈希字符串，代表其中的文件結(jié)構(gòu)。TEG的主要組件，即解析器，以同樣的方式運(yùn)行--通過(guò)ARXML的可選Python LXML解析器模塊。ARXML被解析成一個(gè)初始化的TOM--底層對(duì)象。然后Python多處理模塊同時(shí)將TOM發(fā)送給生成器，并使用Python SQLite模塊存儲(chǔ)在SQL數(shù)據(jù)庫(kù)中。生成器收到TOM后，通過(guò)一個(gè)新的多進(jìn)程實(shí)例，在多個(gè)進(jìn)程中同時(shí)生成SWC。當(dāng)在一個(gè)相同的數(shù)據(jù)集上遞歸運(yùn)行TEG時(shí)，TEG有能力跳過(guò)解析過(guò)程以節(jié)省時(shí)間。

A. 加速

由于ARXML文件的結(jié)構(gòu)和底層對(duì)象的TOM結(jié)構(gòu)，如果不徹底重組整個(gè)現(xiàn)有的解決方案，就不可能對(duì)解析器的操作進(jìn)行重大改變以加速它。然而，開(kāi)發(fā)了一種加速整個(gè)TEG運(yùn)行的方法--更具體地說(shuō)，就是完全避免運(yùn)行解析器，以節(jié)省整個(gè)程序運(yùn)行時(shí)間的形式。

加速是通過(guò)驗(yàn)證新版本TEG的結(jié)構(gòu)與寫入數(shù)據(jù)庫(kù)文件的最后一個(gè)結(jié)構(gòu)來(lái)實(shí)現(xiàn)的，這允許程序跳過(guò)冗余解析操作。為此使用了一個(gè)標(biāo)準(zhǔn)的 Python hashlib 模塊。

還有一個(gè)問(wèn)題是，生成器內(nèi)部的累積操作會(huì)大大降低TEG的執(zhí)行速度，特別是在數(shù)據(jù)量增加的情況下。顯然，加速進(jìn)程的最直接方法是將現(xiàn)有的算法進(jìn)程劃分給更多的處理器核心，從而利用現(xiàn)代硬件架構(gòu)。通過(guò)使用多個(gè)進(jìn)程，預(yù)計(jì)TEG的執(zhí)行速度將大大加快，因?yàn)樯善魇荰EG中最耗時(shí)的部分。

因此，實(shí)現(xiàn)了Python的多進(jìn)程模塊，它將一個(gè)或多個(gè)函數(shù)的操作分解成多個(gè)進(jìn)程。該解決方案將每個(gè)SWC分離成多個(gè)并發(fā)的進(jìn)程。SWC根據(jù)計(jì)算機(jī)上可用的核心總數(shù)來(lái)分配計(jì)算機(jī)核心。來(lái)自主C文檔的片段或模板使用正則表達(dá)式作為組件并行輸入，然后與特定 ECU 相關(guān)的值也輸入到預(yù)先批準(zhǔn)的位置。

B. 儲(chǔ)存

數(shù)據(jù)序列化被關(guān)系數(shù)據(jù)庫(kù)所取代。關(guān)系數(shù)據(jù)庫(kù)是基于關(guān)系數(shù)據(jù)模型的。在關(guān)系數(shù)據(jù)模型中，數(shù)據(jù)被表示為N對(duì)分組的表，即關(guān)系。因此，關(guān)系數(shù)據(jù)模型中的每一個(gè)n對(duì)實(shí)際上是一個(gè)表中的一行，有一定數(shù)量的命名列，代表了存儲(chǔ)在表中的對(duì)象的屬性名稱。管理關(guān)系型數(shù)據(jù)庫(kù)的系統(tǒng)被稱為RDBMS(Relational Data BaseManagement System)。本文采用SQLite作為關(guān)系數(shù)據(jù)庫(kù)。SQLite允許我們使用Python命令來(lái)創(chuàng)建、寫入、交互和刪除SQL數(shù)據(jù)庫(kù)。存儲(chǔ)在SQLite文件中的數(shù)據(jù)庫(kù)很容易被移動(dòng)，因?yàn)樗皇且粋€(gè)文件，通常非常小，并且獨(dú)立于其他外部庫(kù)和程序。此外，SQLite很容易獲得(開(kāi)放源碼)，而且非常流行，這意味著強(qiáng)大的軟件支持。

在運(yùn)行SQLite數(shù)據(jù)庫(kù)的存儲(chǔ)函數(shù)之前，現(xiàn)有TEG解決方案的父數(shù)據(jù)庫(kù)功能用代表TOM Root的初始表創(chuàng)建了數(shù)據(jù)庫(kù)的基礎(chǔ)。數(shù)據(jù)存儲(chǔ)函數(shù)接收參數(shù)Tom Root、初始表和文件系統(tǒng)中的數(shù)據(jù)庫(kù)位置。該函數(shù)依次通過(guò)TOM中的每個(gè)對(duì)象，分別驗(yàn)證每個(gè)單獨(dú)的屬性。最初，每個(gè)屬性通過(guò)一個(gè)邏輯過(guò)濾器來(lái)檢測(cè)拋出的錯(cuò)誤(錯(cuò)誤的數(shù)據(jù)類型、語(yǔ)法錯(cuò)誤、空白數(shù)據(jù))。然后，通過(guò)邏輯分支，確定它們是否是基本數(shù)據(jù)類型(整數(shù)、浮點(diǎn)數(shù)、字符串、長(zhǎng))、不可變的n元組列表、數(shù)據(jù)集還是嵌套對(duì)象。在第一種情況下，當(dāng)前表中的數(shù)據(jù)庫(kù)(與對(duì)象共享名稱)會(huì)創(chuàng)建一個(gè)新的列(如果當(dāng)前不存在此列)。對(duì)于數(shù)據(jù)集、列表和嵌套對(duì)象，則啟動(dòng)一個(gè)遞歸函數(shù)，在一個(gè)單獨(dú)的循環(huán)中存儲(chǔ)數(shù)據(jù)。然后，該函數(shù)接收要進(jìn)入遞歸的對(duì)象、它的表以及它將通過(guò)外鍵引用的父對(duì)象的表，作為參數(shù)。因此，數(shù)據(jù)存儲(chǔ)函數(shù)遞歸地遍歷整個(gè)TOM，并將其內(nèi)容存儲(chǔ)在一個(gè)復(fù)雜的關(guān)系數(shù)據(jù)庫(kù)中。

在ARXML標(biāo)準(zhǔn)中，組件名稱經(jīng)常重復(fù)。由于這個(gè)原因，在創(chuàng)建表名時(shí)，由于SQL的特殊性，不允許兩個(gè)表有相同的名字，因此在每個(gè)表上都加了一個(gè)數(shù)字前綴，以避免由于表名相同而產(chǎn)生的錯(cuò)誤。在每次創(chuàng)建新表時(shí)，通過(guò)移動(dòng)整數(shù)類型變量可以獲得前綴，對(duì)于TOMRoot表來(lái)說(shuō)，是從零開(kāi)始的。哈希字符串也被存儲(chǔ)在數(shù)據(jù)庫(kù)中，以避免遞歸運(yùn)行TEG時(shí)的冗余。對(duì)數(shù)據(jù)庫(kù)的寫入是與生成器的操作同時(shí)進(jìn)行的。

IV.成果與討論

根據(jù)本文框架內(nèi)的變化或改進(jìn)，包括多處理的邏輯、處理現(xiàn)有功能的邏輯、覆蓋程序中的現(xiàn)有步驟以及過(guò)渡到存儲(chǔ)相同數(shù)據(jù)的不同形式，有必要以下列方式檢查改進(jìn)：

驗(yàn)證在SQLite數(shù)據(jù)庫(kù)中傳輸?shù)臄?shù)據(jù)記錄是否正確，以及

測(cè)量改進(jìn)后的的TEG的性能速度，并與現(xiàn)有的解決方案進(jìn)行比較。

對(duì)現(xiàn)有的和升級(jí)后的測(cè)試環(huán)境發(fā)生器的所有測(cè)試都是在同一數(shù)據(jù)集上進(jìn)行的，其執(zhí)行形式是兩個(gè)5.2和5.6MB的.arxml文件，同時(shí)進(jìn)行處理。

測(cè)試是在一臺(tái)運(yùn)行Windows 10、Python 2.7版本的計(jì)算機(jī)上進(jìn)行的，硬件規(guī)格見(jiàn)表1。

表I. 測(cè)試計(jì)算機(jī)硬件規(guī)格

A. 使用的測(cè)試描述

對(duì)SQLite數(shù)據(jù)庫(kù)中傳輸數(shù)據(jù)的正確性的驗(yàn)證是通過(guò)手動(dòng)比較從數(shù)據(jù)庫(kù)傳輸?shù)缴善鞯膬蓚€(gè)測(cè)試可用的值，可以對(duì)SQLite數(shù)據(jù)庫(kù)中傳輸數(shù)據(jù)的正確性進(jìn)行驗(yàn)證。生成器代碼輸入臨時(shí)函數(shù)，打印它在一個(gè)單獨(dú)的日志文件中所傳遞的所有數(shù)值，用于現(xiàn)有和新的解決方案，然后進(jìn)行比較以確定有效性。

TEG加速性能的驗(yàn)證是通過(guò)一個(gè)單獨(dú)的Python模塊完成的，該模塊在Windows命令行中列出了TEG各個(gè)部分(解析器、基礎(chǔ)程序、生成器)的執(zhí)行時(shí)間和總運(yùn)行時(shí)間。時(shí)間以hss.ss的格式表示。使用一個(gè)標(biāo)準(zhǔn)的Python時(shí)間模塊來(lái)處理測(cè)量。

B. 有效性測(cè)試的結(jié)果

由于SQLite數(shù)據(jù)庫(kù)由填滿數(shù)據(jù)的表和列組成，而Pickle數(shù)據(jù)只是TOM代碼的序列化形式，因此不可能直接比較兩種解決方案的內(nèi)容。因此，需要在TEG操作的下一步中進(jìn)行比較，在不同的TEG版本之間匹配隨機(jī)選擇的存儲(chǔ)數(shù)據(jù)。

通過(guò)測(cè)試，發(fā)現(xiàn)現(xiàn)有的解決方案需要大量的時(shí)間(超過(guò)6小時(shí))，并進(jìn)一步解釋了為什么本文的任務(wù)完全集中在時(shí)間性能上。

C. SQL數(shù)據(jù)庫(kù)設(shè)置排列的效果測(cè)量

在制作SQLite數(shù)據(jù)庫(kù)時(shí)，可以采取一定的安全措施來(lái)影響速度，但也可以影響他們所做的數(shù)據(jù)庫(kù)的寫入或讀出的質(zhì)量。在SQLite Python模塊中，可以使用獨(dú)特的PRAGMA語(yǔ)句來(lái)影響這些措施。PRAGMA作為關(guān)鍵詞被調(diào)用，緊隨其后的是要改變的數(shù)據(jù)庫(kù)設(shè)置，然后是新的數(shù)值。以下測(cè)量有三種排列方式：

標(biāo)準(zhǔn)SQL數(shù)據(jù)庫(kù)設(shè)置

同步查詢寫入數(shù)據(jù)庫(kù)(SYNCHRONOUS)

在數(shù)據(jù)庫(kù)中保存記錄的日志(JOURNAL_MODE)

1) 標(biāo)準(zhǔn)設(shè)置

使用激活同步寫入和日志記錄的標(biāo)準(zhǔn)設(shè)置進(jìn)行第一次測(cè)量。一個(gè)完全優(yōu)化的SQLite數(shù)據(jù)庫(kù)的標(biāo)準(zhǔn)設(shè)置將TEG的執(zhí)行時(shí)間增加至11分鐘到12分鐘，而使用Pickle序列化的現(xiàn)有解決方案，其性能只持續(xù)了幾秒鐘(與程序的生成器部分并行工作)。

2) 同步關(guān)閉

在接下來(lái)的實(shí)驗(yàn)中，禁用對(duì)數(shù)據(jù)庫(kù)的同步寫入要求，寫入工作由操作系統(tǒng)負(fù)責(zé)。這種方法極大地提高了每秒查詢的速度，但可能會(huì)發(fā)生數(shù)據(jù)日志錯(cuò)誤，影響數(shù)據(jù)庫(kù)的穩(wěn)定性。誠(chéng)然，在測(cè)試過(guò)程中沒(méi)有觀察到記錄中的錯(cuò)誤，或改變這個(gè)度量的負(fù)面后果，至少在這種規(guī)模的測(cè)試數(shù)據(jù)中沒(méi)有觀察到。

經(jīng)測(cè)量，TEG的平均運(yùn)行時(shí)間為2分8秒。通過(guò)將控制權(quán)移交給操作系統(tǒng)，來(lái)加速對(duì)數(shù)據(jù)庫(kù)的寫入。這一措施將運(yùn)行時(shí)間降低到與Pickle模塊的并行TEG性能的時(shí)間差不多。這也是除標(biāo)準(zhǔn)配置外最穩(wěn)定的方法。

3) 內(nèi)存日志模式

最后，修改了將日志記錄寫入數(shù)據(jù)庫(kù)的設(shè)置。這個(gè)設(shè)置可以有更多的值。標(biāo)準(zhǔn)值是一個(gè)日志條目，與數(shù)據(jù)庫(kù)中的記錄平行，位于與文檔相同的目錄中。本測(cè)試中使用的值將日志設(shè)置從ON改為MEMORY。MEMORY設(shè)置將運(yùn)行和日志記錄轉(zhuǎn)移到計(jì)算機(jī)的工作存儲(chǔ)器中，當(dāng)數(shù)據(jù)庫(kù)完成后，它將被刪除。

這一措施還顯著增加了每秒的查詢數(shù)量，但更改此設(shè)置會(huì)影響創(chuàng)建和編寫SQL數(shù)據(jù)庫(kù)的安全性，因?yàn)樵诎l(fā)生重大計(jì)算機(jī)故障(電源故障、手動(dòng)程序中斷等)時(shí)，可能會(huì)發(fā)生數(shù)據(jù)庫(kù)完全丟失。

在采用了架構(gòu)改進(jìn)和實(shí)現(xiàn)了修正的JOURNAL_MODE設(shè)置SQL數(shù)據(jù)庫(kù)的情況下，可以計(jì)算出TEG的平均運(yùn)行時(shí)間為兩分四十八秒。將日志保存在計(jì)算機(jī)的工作內(nèi)存中的數(shù)據(jù)庫(kù)中(而不保存到磁盤)，這一方法會(huì)導(dǎo)致性能略慢于上一種方法，但它也是標(biāo)準(zhǔn)之外最安全的方法。

D. 加速工作測(cè)量

第一個(gè)測(cè)量是在現(xiàn)有生成器上使用標(biāo)準(zhǔn)多處理Python模塊的TEG的性能。與之前的6個(gè)小時(shí)相比，本示例的處理時(shí)間大約為1分30秒。從比較中可以了解到，由于使用了多處理模塊，生成數(shù)據(jù)的TEG部分在時(shí)間方面顯著減少。

TEG的平均持續(xù)時(shí)間約為1分31秒，比現(xiàn)有解決方案約少180倍。然后，使用采用的哈希字符串在生成器上執(zhí)行測(cè)量，該哈希字符串允許程序跳過(guò)主組件——解析器的執(zhí)行。引入哈希字符串后，TEG的運(yùn)行時(shí)間減少了10%。使用多處理模塊和能成功得識(shí)別哈希字符串的TEG平均運(yùn)行時(shí)間為1分22秒。

E. 討論

寫入一個(gè)新的數(shù)據(jù)庫(kù)，即不使用序列化，而是使用SQLite數(shù)據(jù)庫(kù)，產(chǎn)生了的結(jié)果與現(xiàn)有解決方案類似(更準(zhǔn)確地說(shuō)，整個(gè)程序的最終執(zhí)行是不可察覺(jué)的)。因此，不能說(shuō)數(shù)據(jù)存儲(chǔ)過(guò)程本身加快了，但如果配置得當(dāng)，它的時(shí)間性能可以與現(xiàn)有解決方案相當(dāng)，還能增加數(shù)據(jù)庫(kù)的安全性、穩(wěn)定性和透明度。此外，由于數(shù)據(jù)是在生成器運(yùn)行的同時(shí)寫入數(shù)據(jù)庫(kù)的，這將花費(fèi)更長(zhǎng)的時(shí)間，所以優(yōu)化配置的基庫(kù)不會(huì)對(duì)TEG的整體時(shí)間產(chǎn)生很大影響。

根據(jù)執(zhí)行記錄獲得的測(cè)量結(jié)果，即在TEG中的數(shù)據(jù)存儲(chǔ)和它們的平均前置時(shí)間，推薦第三種方案，即改變計(jì)算機(jī)工作內(nèi)存中的日志存儲(chǔ)(保持SYNCHRONOUS測(cè)量開(kāi)啟)。由于增強(qiáng)型TEG的性能極短，相對(duì)于其他措施可能帶來(lái)的錯(cuò)誤記錄數(shù)據(jù)的問(wèn)題，重復(fù)性能的時(shí)間損失可以忽略不計(jì)。

然而，使用多處理和哈希模塊極大地減少了總運(yùn)行時(shí)間，而且沒(méi)有不必要的副作用。然而，該模塊的有效性取決于運(yùn)行該程序的所使用的硬件。從圖1中可以看出提議的pickle(帶多處理)方案(E1)、提議的SQL安全優(yōu)化(帶多處理)方案(E2)和現(xiàn)有方案(E3)的性能差異。

V.結(jié)論及未來(lái)的工作

要測(cè)試汽車計(jì)算機(jī)硬件和軟件之間的中間件層，需要使用測(cè)試環(huán)境生成器(TEG)。通過(guò)使用不同的TEG配置，可以進(jìn)行多次測(cè)試和模擬，從而定性地檢查ADAS系統(tǒng)的性能。TEG在ECU上獲取通信數(shù)據(jù)，并在其測(cè)試環(huán)境中生成通信模擬，以驗(yàn)證ADAS系統(tǒng)是否正常工作。

圖1 TEG平均運(yùn)行時(shí)間(分鐘)

TEG有三個(gè)主要組件:解析器、數(shù)據(jù)存儲(chǔ)和生成器。本文的目的是提高各個(gè)組件的執(zhí)行速度和穩(wěn)定性。這種改進(jìn)可以是基于算法和架構(gòu)方面的，主要目標(biāo)是縮短TEG的總執(zhí)行時(shí)間，并引入更穩(wěn)定、更安全的數(shù)據(jù)存儲(chǔ)。TEG的核心組件是一個(gè)復(fù)雜的Python對(duì)象(TOM)，它被設(shè)計(jì)用來(lái)跟蹤解析它的ARXML文件的結(jié)構(gòu)。TOM作為主要參數(shù)提交給代表TEG三個(gè)主要組件的三個(gè)主要函數(shù)，因此如果沒(méi)有更充足的時(shí)間來(lái)了解現(xiàn)有解決方案，是不可能重新設(shè)計(jì)它的，而且可能超出一篇論文的范圍?，F(xiàn)有解析器的工作與通過(guò)ARXML并初始化和寫入TOM的一個(gè)循環(huán)有關(guān)。需要做兩次數(shù)據(jù)存儲(chǔ)：用一個(gè)單獨(dú)的XML文件進(jìn)行數(shù)據(jù)解析以及Pickle序列化。生成器還迭代瀏覽了.c 代碼模板，并將它們按順序放入SWC組件。

如果不需要解析器的話，解析器可以通過(guò)一個(gè)哈希字符串來(lái)加速，該字符串將新的TEG的結(jié)構(gòu)與舊的TEG進(jìn)行比較，從而繞過(guò)解析器。數(shù)據(jù)存儲(chǔ)的加速還沒(méi)有實(shí)現(xiàn)，但可以認(rèn)為可以與現(xiàn)有的解決方案相媲美。擁有一個(gè)更穩(wěn)定、更安全、可讀性更強(qiáng)的基庫(kù)所帶來(lái)的額外好處是非常重要的，特別是由于基庫(kù)與明顯更長(zhǎng)的發(fā)電機(jī)壽命并排存放，所以不會(huì)影響整個(gè)TEG的執(zhí)行時(shí)間。工作生成器的特點(diǎn)是快速引入了單個(gè)SWC組件的并行處理，最初生成的SWC列表被劃分為獨(dú)立的計(jì)算過(guò)程。根據(jù)所有的測(cè)量和示例，很明顯，本文開(kāi)始時(shí)設(shè)定的目標(biāo)已經(jīng)成功實(shí)現(xiàn)，因?yàn)閳?zhí)行時(shí)間已經(jīng)減少了大約180倍。

TEG未來(lái)可能的改進(jìn)包括重新設(shè)計(jì)進(jìn)入TEG的ARXML文件，使之成為較小的7arxml文件，每個(gè)文件代表一個(gè)SWC組件，以及重新設(shè)計(jì)底層對(duì)象的TOM結(jié)構(gòu)，使之可以同時(shí)在多個(gè)進(jìn)程中工作。為了降低處理時(shí)間，可以考慮將整個(gè)TEG移植到C語(yǔ)言中。

審核編輯：湯梓紅