摘要

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

I.簡介

ADAS系統是協助司機駕駛車輛的電子系統。ADAS系統可以直接影響汽車的一些部件，目的是為了從完成更安全和更舒適的駕駛的角度開發各種有用的功能：從自動點火燈和交通標志識別到與智能手機的整合。ADAS通信系統運行的一個關鍵因素是其組件之間的通信。利用該傳感器，汽車的計算機系統接收有關汽車周邊環境的信息，即感知環境。這些傳感器是激光雷達、雷達、照相機和超聲波傳感器等。傳感器提供的信息由適當的算法處理，并獲得所需的輸出：自動剎車、根據檢測到的限速標志對車輛進行減速、司機監控、交通線檢測和警告司機越線，等等。由于ADAS系統本身會對交通、車輛和駕駛者本身產生重大影響，它們必須經過詳細的測試并適應嚴格的標準。在 ADAS 中實施的軟件系統必須結構穩健且能夠適應變化，具有標準化的代碼慣例，最重要的是，其測量和結果必須保持一致。

需要對標準化的通信進行測試，最好是在系統內開發測試代碼，以測試AUTOSAR的通信模型。AUTOSAR是一個由汽車公司組成的國際伙伴關系，其目的是在汽車開發環境中的軟件和硬件架構創建中引入標準化。該測試環境允許在汽車計算機系統上工作的工程師能夠實現流程和程序的自動化，否則由于物流和時間的限制，這些流程和程序是不可能人工完成的。它還允許他們對系統進行壓力測試，而不必使用實際的組件并冒著失敗的風險。一個高質量的測試環境是至關重要的，因為不正確的汽車部件模擬或不正確的數據處理會導致代碼在實際執行中出現災難性的故障。因此，模擬測試環境是一個細致和耗時的過程，但對于開發ADAS系統是必不可少的。

本文對測試ADAS系統的軟件解決方案進行了升級，重點是通信。所提出的解決方案使用創建的發生器和測試環境來測試汽車中或 ECU 的 CPU 內部的控制單元之間的通信。所提出的解決方案是基于加速現有的測試環境生成過程的方法，主要是在多個計算機進程中同時分配程序工作，但也可以使用在多個程序運行中消除冗余的解決方案。因此，增強的程序允許在現代多核處理器上對程序的整體運行進行多重加速，并能夠跳過部分程序以節省時間。

本文由五部分組成。第 2 節介紹了現有的測試環境生成器 (TEG) 及其實現方法。第 3 節中給出了對現有 TEG 的改進建議的詳細信息。第 4 節介紹了使用改進后的 TEG 獲得的結果，并附有討論。最后給出了結論和對未來工作的建議。

II.測試環境生成器

用于汽車測試的測試環境生成器是基于AUTOSAR環境，有助于測試汽車系統和部件之間的通信。AUTOSAR采用三層架構：

基礎軟件：一套標準化的軟件模塊，包含操作頂層、應用層所需的服務。

RTE：用于交換信息的中間層，即基礎層和應用層之間的通信。

應用層：與 RTE 通信的應用軟件組件。

TEG位于AUTOSAR通信的中間層。輸入端的 TEG 收集特定 ECU 的信號數據，并以此為基礎在輸出端生成通信環境模型。本節更詳細地描述了 TEG 的工作。更確切地說，本節分析了一個具體的現有解決方案，并在隨后的章節中提出了修改意見。

A. 基于AUTOSAR的通信

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

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

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

B. 測試環境發生器的工作原理

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

C. 現有解決方案的架構

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

1) 解析器

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

當所有來自ARXML的相關數據被傳輸到TOM Root時，解析器的操作就被認為是完成了，然后TOM Root被存儲在RAM中供將來參考。

2) 數據存儲

從.arxml文件解析出來的數據被儲存起來，以便在出現錯誤或調整時進一步檢查輸入數據的有效性，并作為備份。收集的數據代表了TEG的生成器組件進一步運行所需的所有數據。

TEG的現有解決方案依賴于用于序列化存儲的標準Python模塊--Pickle。存儲函數在解析器函數之后啟動，并接收TOM Root和所需的.pickle文件的存儲位置作為參數。有了這個功能，整個TOM Root被序列化為上述文件，即使在執行程序后，該文件仍被永久存儲在輸出目錄中。

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

3) 代碼生成器

從.arxml文檔中解析出來的數據被注入到模板和軟件組件中實現的C代碼的特定切口中，同時還有變量的相應值。

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

發電機操作是迄今為止要求最高的TEG組件，其運行時間取決于輸入文件的大小。生成器還被設計為在組裝模型組件時按順序使用RegEx，因為輸入量增加，這對程序性能(就時間而言)產生了負面影響。

III.測試環境生成器的改進

本文的基本目的是加速現有的TEG。隨著輸入數據的增加，整個程序的執行時間會明顯增加，這是一個實際問題。此外，目標是創造一種更穩定的數據庫存儲形式，而不是將數據序列化作為一種存儲方法。具體來說，對升級版的TEG的要求是：

加速現有的TEG，使其在解析和生成輸出文件方面花費更少的時間。

利用更穩定和透明的存儲方法。

擬議的解決方案是通過對現有解決方案實施代碼更改來實現的。

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

A. 加速

由于ARXML文件的結構和底層對象的TOM結構，如果不徹底重組整個現有的解決方案，就不可能對解析器的操作進行重大改變以加速它。然而，開發了一種加速整個TEG運行的方法--更具體地說，就是完全避免運行解析器，以節省整個程序運行時間的形式。

加速是通過驗證新版本TEG的結構與寫入數據庫文件的最后一個結構來實現的，這允許程序跳過冗余解析操作。為此使用了一個標準的 Python hashlib 模塊。

還有一個問題是，生成器內部的累積操作會大大降低TEG的執行速度，特別是在數據量增加的情況下。顯然，加速進程的最直接方法是將現有的算法進程劃分給更多的處理器核心，從而利用現代硬件架構。通過使用多個進程，預計TEG的執行速度將大大加快，因為生成器是TEG中最耗時的部分。

因此，實現了Python的多進程模塊，它將一個或多個函數的操作分解成多個進程。該解決方案將每個SWC分離成多個并發的進程。SWC根據計算機上可用的核心總數來分配計算機核心。來自主C文檔的片段或模板使用正則表達式作為組件并行輸入，然后與特定 ECU 相關的值也輸入到預先批準的位置。

B. 儲存

數據序列化被關系數據庫所取代。關系數據庫是基于關系數據模型的。在關系數據模型中，數據被表示為N對分組的表，即關系。因此，關系數據模型中的每一個n對實際上是一個表中的一行，有一定數量的命名列，代表了存儲在表中的對象的屬性名稱。管理關系型數據庫的系統被稱為RDBMS(Relational Data BaseManagement System)。本文采用SQLite作為關系數據庫。SQLite允許我們使用Python命令來創建、寫入、交互和刪除SQL數據庫。存儲在SQLite文件中的數據庫很容易被移動，因為它只是一個文件，通常非常小，并且獨立于其他外部庫和程序。此外，SQLite很容易獲得(開放源碼)，而且非常流行，這意味著強大的軟件支持。

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

在ARXML標準中，組件名稱經常重復。由于這個原因，在創建表名時，由于SQL的特殊性，不允許兩個表有相同的名字，因此在每個表上都加了一個數字前綴，以避免由于表名相同而產生的錯誤。在每次創建新表時，通過移動整數類型變量可以獲得前綴，對于TOMRoot表來說，是從零開始的。哈希字符串也被存儲在數據庫中，以避免遞歸運行TEG時的冗余。對數據庫的寫入是與生成器的操作同時進行的。

IV.成果與討論

根據本文框架內的變化或改進，包括多處理的邏輯、處理現有功能的邏輯、覆蓋程序中的現有步驟以及過渡到存儲相同數據的不同形式，有必要以下列方式檢查改進：

驗證在SQLite數據庫中傳輸的數據記錄是否正確，以及

測量改進后的的TEG的性能速度，并與現有的解決方案進行比較。

對現有的和升級后的測試環境發生器的所有測試都是在同一數據集上進行的，其執行形式是兩個5.2和5.6MB的.arxml文件，同時進行處理。

測試是在一臺運行Windows 10、Python 2.7版本的計算機上進行的，硬件規格見表1。

表I. 測試計算機硬件規格

A. 使用的測試描述

對SQLite數據庫中傳輸數據的正確性的驗證是通過手動比較從數據庫傳輸到生成器的兩個測試可用的值，可以對SQLite數據庫中傳輸數據的正確性進行驗證。生成器代碼輸入臨時函數，打印它在一個單獨的日志文件中所傳遞的所有數值，用于現有和新的解決方案，然后進行比較以確定有效性。

TEG加速性能的驗證是通過一個單獨的Python模塊完成的，該模塊在Windows命令行中列出了TEG各個部分(解析器、基礎程序、生成器)的執行時間和總運行時間。時間以hss.ss的格式表示。使用一個標準的Python時間模塊來處理測量。

B. 有效性測試的結果

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

通過測試，發現現有的解決方案需要大量的時間(超過6小時)，并進一步解釋了為什么本文的任務完全集中在時間性能上。

C. SQL數據庫設置排列的效果測量

在制作SQLite數據庫時，可以采取一定的安全措施來影響速度，但也可以影響他們所做的數據庫的寫入或讀出的質量。在SQLite Python模塊中，可以使用獨特的PRAGMA語句來影響這些措施。PRAGMA作為關鍵詞被調用，緊隨其后的是要改變的數據庫設置，然后是新的數值。以下測量有三種排列方式：

標準SQL數據庫設置

同步查詢寫入數據庫(SYNCHRONOUS)

在數據庫中保存記錄的日志(JOURNAL_MODE)

1) 標準設置

使用激活同步寫入和日志記錄的標準設置進行第一次測量。一個完全優化的SQLite數據庫的標準設置將TEG的執行時間增加至11分鐘到12分鐘，而使用Pickle序列化的現有解決方案，其性能只持續了幾秒鐘(與程序的生成器部分并行工作)。

2) 同步關閉

在接下來的實驗中，禁用對數據庫的同步寫入要求，寫入工作由操作系統負責。這種方法極大地提高了每秒查詢的速度，但可能會發生數據日志錯誤，影響數據庫的穩定性。誠然，在測試過程中沒有觀察到記錄中的錯誤，或改變這個度量的負面后果，至少在這種規模的測試數據中沒有觀察到。

經測量，TEG的平均運行時間為2分8秒。通過將控制權移交給操作系統，來加速對數據庫的寫入。這一措施將運行時間降低到與Pickle模塊的并行TEG性能的時間差不多。這也是除標準配置外最穩定的方法。

3) 內存日志模式

最后，修改了將日志記錄寫入數據庫的設置。這個設置可以有更多的值。標準值是一個日志條目，與數據庫中的記錄平行，位于與文檔相同的目錄中。本測試中使用的值將日志設置從ON改為MEMORY。MEMORY設置將運行和日志記錄轉移到計算機的工作存儲器中，當數據庫完成后，它將被刪除。

這一措施還顯著增加了每秒的查詢數量，但更改此設置會影響創建和編寫SQL數據庫的安全性，因為在發生重大計算機故障(電源故障、手動程序中斷等)時，可能會發生數據庫完全丟失。

在采用了架構改進和實現了修正的JOURNAL_MODE設置SQL數據庫的情況下，可以計算出TEG的平均運行時間為兩分四十八秒。將日志保存在計算機的工作內存中的數據庫中(而不保存到磁盤)，這一方法會導致性能略慢于上一種方法，但它也是標準之外最安全的方法。

D. 加速工作測量

第一個測量是在現有生成器上使用標準多處理Python模塊的TEG的性能。與之前的6個小時相比，本示例的處理時間大約為1分30秒。從比較中可以了解到，由于使用了多處理模塊，生成數據的TEG部分在時間方面顯著減少。

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

E. 討論

寫入一個新的數據庫，即不使用序列化，而是使用SQLite數據庫，產生了的結果與現有解決方案類似(更準確地說，整個程序的最終執行是不可察覺的)。因此，不能說數據存儲過程本身加快了，但如果配置得當，它的時間性能可以與現有解決方案相當，還能增加數據庫的安全性、穩定性和透明度。此外，由于數據是在生成器運行的同時寫入數據庫的，這將花費更長的時間，所以優化配置的基庫不會對TEG的整體時間產生很大影響。

根據執行記錄獲得的測量結果，即在TEG中的數據存儲和它們的平均前置時間，推薦第三種方案，即改變計算機工作內存中的日志存儲(保持SYNCHRONOUS測量開啟)。由于增強型TEG的性能極短，相對于其他措施可能帶來的錯誤記錄數據的問題，重復性能的時間損失可以忽略不計。

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

V.結論及未來的工作

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

圖1 TEG平均運行時間(分鐘)

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

如果不需要解析器的話，解析器可以通過一個哈希字符串來加速，該字符串將新的TEG的結構與舊的TEG進行比較，從而繞過解析器。數據存儲的加速還沒有實現，但可以認為可以與現有的解決方案相媲美。擁有一個更穩定、更安全、可讀性更強的基庫所帶來的額外好處是非常重要的，特別是由于基庫與明顯更長的發電機壽命并排存放，所以不會影響整個TEG的執行時間。工作生成器的特點是快速引入了單個SWC組件的并行處理，最初生成的SWC列表被劃分為獨立的計算過程。根據所有的測量和示例，很明顯，本文開始時設定的目標已經成功實現，因為執行時間已經減少了大約180倍。

TEG未來可能的改進包括重新設計進入TEG的ARXML文件，使之成為較小的7arxml文件，每個文件代表一個SWC組件，以及重新設計底層對象的TOM結構，使之可以同時在多個進程中工作。為了降低處理時間，可以考慮將整個TEG移植到C語言中。

審核編輯：湯梓紅