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

  • 手機站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

首頁 > 汽車技術 > 正文

高級駕駛輔助系統(tǒng)下的AUTOSAR通信棧的優(yōu)化方法

2022-01-12 08:50:30·  來源：智能汽車開發(fā)者平臺 ，作者shuqi  
　
1 簡介目前，汽車行業(yè)的技術發(fā)展正在加速增長。諸如自動駕駛和Car2X等新趨勢要求對交互環(huán)境有詳細的了解。因此，車輛之間以及與周圍環(huán)境之間的聯(lián)系越來越緊密。
1 簡介
目前，汽車行業(yè)的技術發(fā)展正在加速增長。諸如自動駕駛和Car2X等新趨勢要求對交互環(huán)境有詳細的了解。因此，車輛之間以及與周圍環(huán)境之間的聯(lián)系越來越緊密。它們的功能通過智能軟件模塊得到增強，有助于增加車輛的性能。在自動駕駛的情況下，需要專門的傳感器，以便有效實現(xiàn)整個車輛360°環(huán)境識別。鑒于操作條件的復雜性，高級駕駛輔助系統(tǒng)（ADAS）出現(xiàn)了，可以用以減少運作期間可能出現(xiàn)的危及生命的情況。
高級駕駛輔助系統(tǒng)是一個基于車輛的智能安全系統(tǒng)，在道路和交通安全方面為駕駛員提供支持。該模塊通過部分和完全取代駕駛員的行為來監(jiān)控、警告甚至控制車輛。雖然ADAS的形式多種多樣，但它們都有一個共同的目的: 使駕駛體驗更安全、更舒適。ADAS市場的構建考慮到了組件類型及其使用區(qū)域。第一類包括系統(tǒng)和傳感器類型。系統(tǒng)類型細分為盲點物體檢測系統(tǒng)、胎壓監(jiān)測系統(tǒng)、睡意監(jiān)測系統(tǒng)、自適應巡航控制系統(tǒng)、自適應前照燈系統(tǒng)、智能停車輔助系統(tǒng)、夜視系統(tǒng)、車道偏離警告系統(tǒng)和駕駛員監(jiān)控系統(tǒng)。
傳感器類型類別包括雷達、圖像傳感器、超聲波傳感器、LiDAR傳感器、紅外傳感器和激光。先進的駕駛輔助系統(tǒng)應用，如車道偏離警告系統(tǒng)和自適應巡航控制、夜視或盲點探測系統(tǒng)的實施，大大減少了汽車事故的數(shù)量。根據(jù)新車碰撞測試（NCAP）的政策現(xiàn)代汽車必須證明達到特定的安全等級，以鼓勵在最先進的汽車設計中進行重大安全改進。關注道路安全的政府機構在這方面提供了額外的支持。所有這些工業(yè)、社會和公共方向都有望在未來催生高級駕駛輔助系統(tǒng)市場的增長，這需要優(yōu)化的通信實現(xiàn)。
現(xiàn)代化的傳感器，如超聲波和激光傳感器（LiDAR 傳感器），當然還有環(huán)視攝像頭，可確保安全距離識別，此外還可以識別駕駛環(huán)境。（中央）控制單元處理數(shù)據(jù)并將其轉(zhuǎn)換為信號、視覺信息，甚至主動反應。如今，這些行動通常以數(shù)字方式發(fā)生，并在幾分之一秒的時間內(nèi)完成。由于現(xiàn)有系統(tǒng)的多樣性和不同制造商提供的所有單獨解決方案，不可能就哪種傳感器系統(tǒng)或傳感器系列適合用于任何特定的應用做出一般性聲明。汽車制造商在所有不同車型中都使用了最多樣化的駕駛員輔助系統(tǒng)、實用組合和新技術。傳統(tǒng)上，電子控制單元（ECUs）是以硬件相關的范例開發(fā)的，考慮到了硬件設置的具體架構組件。這種方法需要為每次硬件升級創(chuàng)建新軟件。多年來，由于硬件限制，汽車行業(yè)的新產(chǎn)品開發(fā)周期一直在放緩。此外，這降低了軟件的可靠性和可重用性。因此，幾家德國汽車原始設備制造商（OEMs）啟動了機動車開放系統(tǒng)和電子技術（OSEK）和汽車開放系統(tǒng)架構（AUTOSAR）計劃，以制定 "汽車分布式電子控制單元的開放式架構的行業(yè)標準"。AUTOSAR 旨在通過提供獨立于硬件的應用軟件來提供標準接口，這些應用軟件可以通過運行時環(huán)境層分布在車輛 ECU 的各個組件中。
隨著汽車行業(yè)向智能系統(tǒng)和自動駕駛的快速發(fā)展，AUTOSAR 平臺是克服可擴展性和互操作性挑戰(zhàn)的解決方案之一。自動駕駛需要大量的傳感器，因此增加了網(wǎng)絡參與者的數(shù)量和需要處理的關鍵數(shù)據(jù)。這就是為什么通信流量變得更加復雜的原因 ，也是因此才需要研究應用于 AUTOSAR 層面的優(yōu)化方法。我們研究了在 AUTOSAR 層面上優(yōu)化大數(shù)據(jù)傳輸?shù)目赡苄?。根?jù)我們查閱的文獻綜述，這種特殊的方法尚未在科學文獻中有詳細討論。在之前的工作中, 我們嘗試探索類似解決方案的設計和實現(xiàn)。當前提案的發(fā)現(xiàn)和結果側(cè)重于通過描述所使用的方法、技術硬件和軟件實現(xiàn)、測試程序、經(jīng)驗教訓和局限性，為具有類似特征的進一步項目提供新的科學見解。
面對Covid-19爆發(fā)的全球危機，汽車行業(yè)正在為嵌入式系統(tǒng)應用引入新的測試程序，如遠程測試。在這種情況下，特定的設備形成了復雜的測試實驗室，可以在任何距離和任何時間訪問這些實驗室。我們的研究是基于想在處理雷達傳感器時提供這種解決方案。
基于上述觀察，本文的研究問題表述如下：(RQ1) 構建AUTOSAR通信優(yōu)化所需的解決方案; (RQ2) 構建遠程測試架構和環(huán)境，用以訪問和測試 AUTOSAR 級別的優(yōu)化; (RQ3) 在性能和運行時間測量方面分析我們的系統(tǒng)，以便就我們的解決方案提供明確的科學結果，使研究人員在未來具有類似特征的工作中受益。
本文的其他部分：第2節(jié)介紹了AUTOSAR的基礎知識，隨后的第3節(jié)包含了AUTOSAR和雷達傳感器優(yōu)化以及AUTOSAR測試的文獻回顧。接下來，在第4節(jié)中介紹了系統(tǒng)結構和三個主要特點：AUTOSAR優(yōu)化解決方案，以遠程方式訪問雷達傳感器，以及性能測試模塊的實現(xiàn)。本文的下一部分，即第5節(jié)，介紹了我們進行的實驗和獲得的結果，而第6節(jié)則是我們的研究的結論。

2 AUTOSAR的基本概念
汽車開放系統(tǒng)架構（AUTOSAR）成立于2003年，是一個由汽車制造商組成的全球開發(fā)合作聯(lián)盟。該聯(lián)盟的目標是為汽車ECU創(chuàng)建和建立一個開放、穩(wěn)健和標準化的軟件架構。這種設計包括對各種車輛和平臺變體的可擴展性和軟件的可移植性，一切以可用性、可靠性和安全要求為基礎。它還旨在維護基于預定義的“產(chǎn)品生命周期”的開發(fā)過程。
AUTOSAR的開發(fā)過程 (圖 1) 是在以下軟件層中實現(xiàn)的。MCAL（微控制器抽象層）、基本軟件層（BSW）、運行時環(huán)境（RTE）和應用層。運行時環(huán)境（RTE）的作用是將網(wǎng)絡與應用程序的軟件組件（SWC）解耦，并以基本軟件（BSW）的形式提供統(tǒng)一服務，如系統(tǒng)和診斷服務、總線通信、IO訪問和內(nèi)存管理。BSW通信棧由服務層、ECU抽象層和微控制器抽象層（MCAL）組成。AUTOSAR通信棧 (圖 2) 為BSW模塊以及應用層提供通信服務。


圖 1 AUTOSAR 架構


圖 2 總線通信棧
通信（COM）模塊位于RTE和PDU路由器之間，負責提供對應用層所需信號的訪問。它還提供獨立于所使用協(xié)議的對較低層的PDU級別訪問。在發(fā)射器端，它將把所有的信號打包成一個PDU，而在應用端將把收到的PDU解包，以便為應用提供信號電平訪問。
協(xié)議數(shù)據(jù)單元路由器（PduR）模塊是服務層的一部分，將把PDU路由到特定的總線接口模塊。它為以下模塊的PDU路由提供服務: 傳輸協(xié)議模塊；通信接口模塊；診斷通信管理器（DCM）和傳輸協(xié)議模塊；COM和通信接口模塊或I-PDU復用器；IPDU-復用器；和通信接口模塊。
通過總線傳輸協(xié)議（TP）模塊可獲得的基本服務是：對那些有效載荷超過8字節(jié)的信息進行分段，在流控制下傳輸信息，并在接收器處重新組裝分段信息?？偩€狀態(tài)管理器(SM)模塊將為相應的總線實現(xiàn)控制流?？偩€網(wǎng)絡管理器(NM)模塊的目的是管理網(wǎng)絡的正常運行模式和總線休眠模式之間的轉(zhuǎn)換。總線接口模塊是ECU抽象層的一部分，作為硬件抽象層（最低層）和服務層（總線接口模塊以上）之間的接口。外部總線驅(qū)動程序為上層服務提供總線特定的收發(fā)器訪問。
由于現(xiàn)代ECUs中存在各種復雜的模塊化嵌入式軟件組件，在實現(xiàn)軟件功能時，必須達到不同的汽車安全完整性等級(ASIL)。ASIL是由ISO 26262-道路車輛-功能安全標準定義的，作為軟件功能實現(xiàn)的屬性，例如，在嵌入式系統(tǒng)中。ASIL被提出，作為對開發(fā)中的產(chǎn)品進行威脅分析和風險評估的結果，表明軟件功能必須實現(xiàn)的質(zhì)量等級。ECU軟件可以由安全相關和非安全相關的組件組成；因此，必須考慮到不同的ASIL等級。在這種情況下，ISO 26262標準規(guī)定，要么在開發(fā)階段必須遵循最高的ASIL等級，要么具有較低ASIL等級的軟件組件必須與具有較高ASIL等級的組件實現(xiàn)接口自由。
為了確保各種軟件組件之間所需的接口自由度，已實施AUTOSAR功能安全機制，以防止、檢測和減輕可能出現(xiàn)的軟件和硬件故障。ISO 26262 標準定義了諸如內(nèi)存、時序、信息交換和執(zhí)行等故障組。例如，通過將操作系統(tǒng)應用程序存儲在不同的內(nèi)存區(qū)域，AUTOSAR OS系統(tǒng)允許為內(nèi)存故障提供接口自由。因此，在代碼執(zhí)行過程中，內(nèi)存分區(qū)可以保護操作系統(tǒng)應用程序免受其他應用程序的影響。除了功能安全機制外，AUTOSAR的其他各種功能安全措施也支持安全相關軟件的開發(fā)。
在與質(zhì)量相關的相同背景下，汽車軟件過程改進和能力確定（ASPICE）旨在評估一個組織的軟件開發(fā)過程性能，并強調(diào)軟件開發(fā)的基礎實踐。也就是說，ASPICE被定義為汽車OEM應用的框架，用于確定和評估汽車行業(yè)的軟件開發(fā)過程。在不考慮安全方面的情況下，ASPICE可以確定一個組織的軟件產(chǎn)品交付能力。然而，為了確保安全相關的要求，該組織必須證明其符合ASPICE和ISO 26262。ASPICE 涵蓋了整個開發(fā)過程，提供了實現(xiàn)功能安全標準ISO 26262所需的框架。為了更好地理解兩者之間的聯(lián)系，ISO 26262可以被看作是ASPICE從功能安全角度定義的軟件開發(fā)的延伸。即使ASPICE和ISO 26262標準在許多方面是不同的，但在工作產(chǎn)品的可追溯性和變更管理等方面仍然可以找到相似之處。

3 前期工作
本節(jié)介紹了有關我們論文的主要議題、AUTOSAR通信和優(yōu)化以及AUTOSAR測試的最新文獻。
3.1 AUTOSAR 通信
在Anna Arestova等人的工作中，他們解決了通信挑戰(zhàn)，并提出了AUTOSAR自適應平臺、名為開放平臺通信統(tǒng)一架構（OPC UA）的機器對機器通信技術和時間敏感網(wǎng)絡（TN）的整合方法。通過結合使用TSN和OPC UA，通信開銷大大減少，實現(xiàn)了各種設備之間的靈活通信。
然而，只有當數(shù)據(jù)流是安全的，通信優(yōu)化才是可靠的。Cinzia Bernardeschi等人提出了一種方法來檢查帶安全注釋的AUTOSAR模型中的數(shù)據(jù)安全流。這種方法是基于對信息流的分析和抽象的解釋。他們的研究工作旨在提高汽車通信的安全性，因為最近的研究認為，入侵者可以破壞現(xiàn)代汽車電子系統(tǒng)的可操作性。他們定義了解決網(wǎng)絡安全相關要求的AUTOSAR建模擴展，同時開發(fā)了一個代碼生成工具，該工具綜合了要使用的適當服務。事實證明，這些自動生成的安全組件極大地減少了開發(fā)階段的常見錯誤。遵循相同網(wǎng)絡安全路徑， Pietro Biondi 等人提出了TOUCAN協(xié)議的概念驗證。該安全協(xié)議遵循AUTOSAR標準，旨在確?？刂破鲄^(qū)域網(wǎng)絡通信的安全。因此，該協(xié)議的目標是建立CAN幀的安全通信。該團隊學者認為，TOUCAN為CAN通信增加了安全性，同時對運行時間的影響可以忽略不計。在專業(yè)的汽車環(huán)境外測試該協(xié)議，進一步證明了TOUCAN協(xié)議的易用性。Haichun Zhang等人的另一項研究強調(diào)了CAN總線協(xié)議的脆弱性。為了評估安全風險，我們提出了一個模擬惡意攻擊的車載CAN安全評估工具--CANsec。此外，即使在沒有提供車輛制造商信息的情況下，作者也證明了CANsec的作用。
汽車行業(yè)電子控制單元對計算能力的高需求催生了一種新的解決方案，以取代廣泛使用的單核處理器。因為具有更高的計算能力和能源效率，多核電子控制單元的使用迅速增加。因此，很多研究提出了基于AUTOSAR標準的優(yōu)化方法。為了最小化通信成本，Priyanshi Gupta等人提出了一種算法，用于在多核汽車嵌入式系統(tǒng)中高效映射AUTOSAR 可運行項。該解決方案旨在解決AUTOSAR定期運行項和任務的數(shù)據(jù)依賴所產(chǎn)生的通信開銷，試圖將可運行項從單核映射到多核。該算法是同質(zhì)多核系統(tǒng)的一個可能解。針對多核電子控制單元可運行到任務映射的優(yōu)化問題，Thomas Wilhelm和Raphael Weber提出了一個解決方案自動化兩個流程步驟，其中優(yōu)化了可運行任務映射的初始步驟和AUTOSAR平臺中的優(yōu)化步驟。通過使用約束編程，可以自動化平衡核心利用率，同時作者使用了進化算法來優(yōu)化已經(jīng)存在的配置。該論文還展示了AUTOSAR的隱性設計約束如何影響進化算法的建模。為了減少AUTOSAR中的繁忙等待，Robert Hottger等人提出了一個基于任務-釋放-Delta的可運行重新排序(TDRR)的概念。為了減少任務響應時間，提高并行效率，改善時序可預測性，對一些AUTOSAR可運行項進行重新排序。他們的工作通過使用TDRR來執(zhí)行具有不同離線計算可運行順序的任務，成功地完全應用于AMALTHEA模型。此外，工業(yè)用例的實驗證明了該解決方案能夠通過減少任務響應時間來提高系統(tǒng)性能。在此基礎上, Sebastian Kehr 等人提出了一種延遲感知的并行化技術Parcus，它結合了可運行項和任務級并行。該技術被用于AUTOSAR遺留應用程序的進行穩(wěn)健和具有能源感知的并行。此外，還提出了一種進化算法，以探索大量的調(diào)度可能性?？紤]到延遲和處理器頻率，并行調(diào)度質(zhì)量指標對并行化的成功與否進行了量化。作者用一個真實的柴油發(fā)動機管理系統(tǒng)證明了Parcus技術的適用性。

優(yōu)化機會可以出現(xiàn)在任何方向，Qingling Zhao等人證明了這一點，在他們的論文中，優(yōu)化了具有混合臨界調(diào)度和搶占閾值的AUTOSAR模型的設計。由于混合臨界嵌入式系統(tǒng)的可調(diào)度性分析的發(fā)展，他們提出了兩種算法，PA-DMMPT 和 HeuPADMMPT。這兩種算法旨在以最小化系統(tǒng)堆棧內(nèi)存使用量的方式分配調(diào)度參數(shù)。使用隨機生成的混合臨界可運行集進行性能評估，結果表明該方法可以顯著降低系統(tǒng)內(nèi)存堆棧的使用。針對符合AUTOSAR標準的相同系統(tǒng)，Nesredin Mahmud等人的目標是優(yōu)化容錯嵌入式軟件應用程序的分配。他們所提出的優(yōu)化基于一個整數(shù)線性編程模型，該模型在考慮到強加的時序和可靠性要求的情況下，使系統(tǒng)的總功耗最小。合成汽車應用程序評價結果表明，該優(yōu)化方法可有效地應用于中小型分布式容錯應用，但不適用于復雜應用。
為了實現(xiàn)對車載故障診斷系統(tǒng)的離線分析，Shilpa Raju等人提出了一種機制，用于建立車輛上記錄的故障數(shù)據(jù)的時間關系。由于車輛網(wǎng)絡由異構的ECU組成，每個ECU都有自己的本地時間，因此故障數(shù)據(jù)的關聯(lián)會導致不一致的結果。作者提出了一個同步的全局時間基準，為整個車輛網(wǎng)絡的公共時間戳提供了一個解決方案。在一個實際的硬件設置上進行的測試成功的實現(xiàn)了時間從站和時間主站之間的時間同步。
3.2 AUTOSAR 測試
隨著現(xiàn)代汽車上安裝的軟件組件數(shù)量的增加，軟件故障導致嚴重后果的概率也在增加。這些組件由數(shù)百萬行需要充分測試的代碼組成。為了測試AUTOSAR架構中的這些軟件組件，測試人員采用了硬件在環(huán)模擬。然而，這些模擬有其自身的局限性，因為軟件組件不能在早期階段進行測試。針對汽車行業(yè)的功能安全，Jihyun Park和Byoungju Choi強調(diào)了基于AUTOSAR的軟件故障注入測試的重要性。這兩位學者提出了一種故障注入的方法，并定義了可能發(fā)生的軟件故障類型。這些故障可能是由于不同AUTOSAR層之間的調(diào)用關系而引起的。該方法應用軟件開發(fā)過程中，可以注入基于AUTOSAR的汽車軟件的各種故障。此外，該解決方案是作為ASFIT實現(xiàn)的，并與現(xiàn)有的故障注入方法進行了比較。一家韓國汽車公司進行了一項實證研究，證實了該方法的卓越性。Kazuto Shigihara等人指出AUTOSAR實時操作系統(tǒng)模塊的測試面臨不同的挑戰(zhàn)，并引入了測試程序生成器來解決這些問題。測試AUTOSAR操作系統(tǒng)的面臨挑戰(zhàn)之一是需要大量的測試案例，從而導致的執(zhí)行耗時。在他們的研究中，闡明了更深層的挑戰(zhàn)，并引入了一種新的測試程序生成器。此外，為了解決非信任操作系統(tǒng)應用程序的約束，他們開發(fā)了一個測試庫。通過對AUTOSAR操作系統(tǒng)的商業(yè)實現(xiàn)進行的測試，證明了該方法的有效性。

針對 AUTOSAR 中軟件在環(huán)的測試技術的差距，Sooyong Jeong 和 Woo Jin Lee提出了一種自動化測試技術。由于涉及到閉環(huán)控制和反饋機制，所以還沒有使用SiL模擬測試AUTOSAR組件的自動化技術，因而手動測試盛行。為了使用作為現(xiàn)有SiL模擬器集成的自動測試模塊，可以通過測試用例轉(zhuǎn)換方法，將包括閉環(huán)的測試用例轉(zhuǎn)換為時間形式。通過實例分析，驗證了他們所提出的自動化測試方法的效率和效果。按照類似的方法，Andrija Mihalj等人提出了一個現(xiàn)有的高級駕駛輔助系統(tǒng)環(huán)境測試系統(tǒng)，該系統(tǒng)在AUTOSAR架構的中間層為通信模擬創(chuàng)建了一個測試環(huán)境。該系統(tǒng)創(chuàng)建的生成器和測試環(huán)境被用來測試控制單元之間的通信。測試環(huán)境發(fā)生器實際上是一個基于Python的程序，用于處理ARXML。此外，通過使用不同的測試環(huán)境發(fā)生器配置，可以對ADAS系統(tǒng)的性能進行定性檢查。擬議的測試環(huán)境生成器由解析器、數(shù)據(jù)存儲器和生成器組成。然而，他們所進行的這些測試強調(diào)了未來工作的重要性，即需要加快執(zhí)行時間并引入穩(wěn)定的數(shù)據(jù)存儲方法。
3.3 AUTOSAR遠程測試
現(xiàn)代汽車日益增強的連接性可以被視為汽車工業(yè)最令人矚目的方面之一。同時，通信技術的發(fā)展為物聯(lián)網(wǎng)的發(fā)展提供了巨大的潛力。AUTOSAR的存在結合將這兩個機遇結合到一起，提供了將現(xiàn)有物聯(lián)網(wǎng)技術整合到現(xiàn)代汽車的機會。Marko Dragojevic′ 等人提出了一種利用物聯(lián)網(wǎng)技術遠程診斷現(xiàn)代車輛的方法。他們使用已經(jīng)存在的物聯(lián)網(wǎng)技術來加強汽車中間件--自適應AUTOSAR，以實現(xiàn)遠程診斷和監(jiān)測。該團隊所提出的架構演示了如何利用簡化的功能，將物聯(lián)網(wǎng)輕松集成到自適應AUTOSAR中。該研究的結論是，他們的解決方案會產(chǎn)生一定的開銷。然而，他們研究的目的是為了說明當前物聯(lián)網(wǎng)技術在汽車行業(yè)的可行性。為了升級基于物聯(lián)網(wǎng)解決方案的軟件， Stevan Stevic′ 等人介紹了他們將物聯(lián)網(wǎng)技術與自適應 AUTOSAR 平臺結合的解決方案。該解決方案包括軟件架構升級、基于物聯(lián)網(wǎng)技術的云連接以及自適應AUTOSAR堆棧的擴展。他們所選擇的物聯(lián)網(wǎng)技術是OBLO，用作系統(tǒng)的后端部分，其允許對現(xiàn)代車輛進行空中更新(OTA)。新的自適應AUTOSAR平臺與OBLO結合，針對解決有關更新昂貴和更新緩慢的問題。

隨著越來越多的雷達解決方案被引入到汽車應用中，我們需要驗證這些方案符合標準，并確保性能。在Carlos Junio Rocha等人的論文中，他們提出了一種自動化的方法，可以在各種雷達裝置的生產(chǎn)單位進行空中測試和驗證。該方法不僅涵蓋了通過/失敗條件，而且還可用于確定雷達天線陣輻射圖。他們所展示的研究結果說明了在清潔和屏蔽的消聲環(huán)境中進行測試的重要性。Patrick Pelland等人提出了汽車測試環(huán)境中遇到的一些獨特挑戰(zhàn)。該團隊學者指出，傳統(tǒng)的空中技術不足以測試復雜的系統(tǒng)，如現(xiàn)代汽車。他們的論文結語表示，下一代汽車天線測量系統(tǒng)將用于空中測試和天線模式測量。未來，這些設施將配備定位系統(tǒng)，適用于帶有 OTA 測試設備的車輛，以幫助與相關的無線系統(tǒng)進行通信。Philipp Berlt等人強調(diào)了開發(fā)新的測試程序的重要性，因為如果射頻端口無法訪問，現(xiàn)有的測試程序就無法執(zhí)行。無線信息和車輛運行狀態(tài)之間的關系也突出了這一點。
Sreehari Buddappagari 等人在他們的論文中介紹了一個基于空中方法的完整測試系統(tǒng)，用于汽車雷達系統(tǒng)的安裝性能評估。由于雷達系統(tǒng)是自主和互聯(lián)駕駛技術的最重要的部分之一，其功能性能必須得到徹底驗證。但這種方法消耗資源較多，相關風險較大。這項工作利用了一個示范性的交通場景，以驗證整個實施系統(tǒng)的性能。進行的測試取得了良好的效果，其模擬結果與預期結果相似。同樣，Sreehari Buddappagari和hJayapal Gowdu等人將77GHz雷達視為自動駕駛的關鍵驅(qū)動力，并進一步強調(diào)了傳統(tǒng)測試的資源消耗，因為傳統(tǒng)測試必須由真實的測試駕駛員駕駛覆蓋數(shù)百萬公里的路程。該團隊所提出的解決方案旨在通過使用硬件在環(huán)模擬虛擬雷達環(huán)境來增強真實的現(xiàn)場測試。該解決方案允許在車輛上安裝待測雷達的情況下，模擬車輛各互聯(lián)子系統(tǒng)的響應行為?？罩蟹椒ㄔ试S在無需修改的情況下操作雷達傳感器，而虛擬環(huán)境有助于測試同一雷達傳感器的正確操作。該團隊成功地創(chuàng)建了一個整體的、可重復的、可靠的、可擴展的端到端測試概念。Michael Gadringer等人撰寫的文章模擬器的開發(fā)過程，該模擬器負責生成虛擬雷達目標，以測試雷達傳感器。正如之前的文章中所述，強調(diào)了廣泛使用的道路測試的風險及其他相關風險和資源消耗。雷達目標模擬器和負責生成模擬器輸入?yún)?shù)的軟件已經(jīng)被開發(fā)出來。該測試臺用于車輛在環(huán)測試，以模擬其在道路上的測試公里數(shù)。雷達目標模擬器的性能在實驗室和滾筒試驗臺上都得到了驗證。此外，這些學者對雷達傳感器潛在的未來發(fā)展進行了概述，指出這些趨勢將對他們研究的雷達目標模擬器系統(tǒng)產(chǎn)生巨大影響。
另一方面，Nils Hirsenkorn 及其團隊討論了模擬精度和虛擬傳感器的真實性的重要作用。他們的論文描述了一個汽車雷達傳感器的模擬方法，從波的傳輸開始，一直到中頻信號。為了獲得高保真度，天線功率圖、反射和光線發(fā)散都有考慮在內(nèi)。最后，該模型被部署在虛擬試駕中，這是一個詳細的駕駛模擬器，能夠呈現(xiàn)與現(xiàn)實測試類似的結果。為了給空中雷達傳感器測試提供低雜波環(huán)境，Muhammad Ehtisham Asghar等人經(jīng)過初步分析，提出了一種最佳吸收器配置。為了檢測測試設施中的雜波和不需要的散射，該學者利用了可編程的雷達手冊和具有熟知的參考雷達傳感器。通過對不需要的反射進行出色的檢測，證明了所提方法的效率。
3.4 雷達優(yōu)化

由于雷達傳感器在安全駕駛體驗中發(fā)揮重要作用，快速發(fā)展的汽車行業(yè)利用這些傳感器，來提高對移動目標的檢測能力。然而，高分辨率的雷達傳感器和LiDAR導致了一個擴展的目標跟蹤問題。Karl Granstrom 等人強調(diào)了當每個被跟蹤目標有多個檢測時面臨的問題。他們在論文中提出了一種隨機優(yōu)化方法，在一個步驟中解決了這個問題，并使所需的可能性最大化?；诓蓸拥姆椒ㄔ谟肰elodyne數(shù)據(jù)進行的實驗中得到了證實，表明所提出的過濾器優(yōu)于以前的任何其他方法。此外，該解決方案不依賴多種算法，而是直接輸出所需的可能性。Ali Walid Daher等人也專注于優(yōu)化移動目標的分類，他們提出了一種應用機器學習的解決方案。通過使用Raspberry Pi進行培訓和測試，物聯(lián)網(wǎng)被引入他們的工作中。Rulex是一個高性能的機器學習包，已被移植到客戶端/服務器設置中的電路板上。實驗證明，人類的準確率為100%，車輛的準確率為96.67%。為了改善移動目標的成像并提高角度分辨率，Shahzad Gishkori等人用前視汽車雷達傳感器擴展了前攝合成孔徑雷達方法。為了區(qū)分運動目標和靜止目標，他們將非參數(shù)矩陣分解方法應用于前向掃描合成孔徑雷達。在工作過程中，采用乘法器迭代法中的交替方向法解決優(yōu)化問題。最后，通過模擬數(shù)據(jù)和實際數(shù)據(jù)驗證了該方法的有效性。

4 方法
本文介紹的系統(tǒng)為雷達傳感器上實現(xiàn)的AUTOSAR通信提供了一個優(yōu)化解決方案。該傳感器可以通過一個從頭開始實施的Arduino接口進行遠程訪問。本方法的研究步驟如下：
  1. 分析文獻綜述，以了解AUTOSAR優(yōu)化和遠程雷達傳感器的現(xiàn)有方法（第3節(jié)）；
  2. 構建兼顧通信優(yōu)化、遠程測試、雷達應用測試的系統(tǒng)架構 （第4節(jié)）；
  3. 實施私有數(shù)據(jù)適配器(PDA) 優(yōu)化方案 （第4.1節(jié)）；
  4. 構建雷達傳感器遠程測試樣機 （第4.2節(jié)）；
  5. 通過構建雷達生產(chǎn)模式（RPM）模塊來實施性能測試 （第4.3節(jié)）；
  6. 對已實施的性能測試進行分析 （第5.1節(jié)和第5.2節(jié)）；
  7. 確定并討論使用擬議優(yōu)化方案的優(yōu)勢和劣勢 （第5.23節(jié))。
該系統(tǒng)結構如圖3所示，主要分為三個部分。應用程序安裝在機器上時，它是在傳感器內(nèi)運行的軟件組件。該模塊表示通信軟件模塊，即私有數(shù)據(jù)適配器（PDA）的實現(xiàn)，該模塊用于專用通信系統(tǒng)（傳感器到傳感器的通信），并集成在AUTOSAR通信中。


圖 3 系統(tǒng)架構
該系統(tǒng)的設計是為了滿足遠程測試的要求（如RQ2中提出的），這意味著在正常的現(xiàn)場實驗室之外，在特定條件下工作的開發(fā)者將能夠訪問雷達傳感器的應用程序。開發(fā)人員或測試人員通過互聯(lián)網(wǎng)連接到Arduino接口，而雷達傳感器連接到公司實驗室內(nèi)部定義的接口。隨著第五代雷達傳感器的發(fā)展，需要有一種軟件能夠測試傳感器是否正確組裝，并為其商業(yè)使用做準備。雷達生產(chǎn)模式（RPM）是一個軟件組件，能對雷達傳感器及其應用程序進行各種測試和處理，如內(nèi)存使用和運行時間測試。這些測試是基于在CAN總線上收到的命令執(zhí)行的。因此，RPM是一個按照需求-響應原則工作的組件，唯一自動完成的活動是初始化它所需要的各種驅(qū)動器，以實現(xiàn)其目的。這個模塊負責讀取各種電壓、溫度、信號和內(nèi)存部分。此外，RPM提供的另一項服務是在其所在項目的現(xiàn)有通信通道上發(fā)送固定結構報文。這些可以是CAN或以太網(wǎng)總線。發(fā)送的報文的結構將由其接收器檢查，以確認傳感器通信是否按預期工作。
當前生成的RPM是與其他軟件組件一起加載到傳感器的ROM內(nèi)存中的。上傳則是通過微控制器內(nèi)存上的閃存完成的。一般來說，每個軟件組件在初始化時都會配置傳感器的硬件組件，但由于這個步驟已從RPM中刪除，它是基于之前運行的組件，即Flash Bootloader (FBL)所做的配置。這個限制意味著對FBL配置所做的任何改變都會對RPM的功能產(chǎn)生負面影響。
雷達生產(chǎn)模式（RPM）與閃存加載程序進行通信，這是傳感器開啟后運行的第一個組件。該組件負責檢查傳感器內(nèi)存中其他軟件組件的完整性。這種檢查是通過計算每個組件的循環(huán)冗余校驗（CRC）來完成的，并將結果與組件加載到內(nèi)存時附加在其上的驗證值進行比較。此外，F(xiàn)BL可以分析哪些軟件組件在傳感器啟動時存在，并根據(jù)優(yōu)先級決定將啟動哪個經(jīng)過驗證且無錯誤的組件。有兩個組件可以由FBL啟動，即傳感器應用程序和測試軟件管理器，其優(yōu)先于應用程序。
測試軟件管理器（TSM）的工作原理與RPM類似，都是基于需求-響應原則。這個組件等待一個請求，以報文的形式在CAN總線上發(fā)送，在處理請求后，它決定哪個測試組件將檢查并啟動它。在RPM的場景中，它將比較RPM中發(fā)現(xiàn)的有效性模型和TSM中包含的有效性模型模型。有效性模型是一個預先確定的數(shù)值序列（圖4），分別寫在傳感器內(nèi)存以及RPM和TSM的儲存部分中。如果有效性模型相同，TSM將開啟RPM的啟動過程，包括將其從ROM復制到RAM并從RAM啟動。測試過程結束時，RPM將從傳感器內(nèi)存中刪除TSM。
圖 4 RPM中的有效性模型
另一個可以由TSM啟動的組件是生產(chǎn)校準（PC）。它可以處理傳感器雷達天線的校準，它從傳感器的存儲器中的刪除也是由RPM執(zhí)行的。
4.1 私有數(shù)據(jù)適配器模塊
77Ghz雷達傳感器的通信系統(tǒng)是由一種特定的通信類型劃分的。它是由ECU和傳感器之間的特定車輛通信形成的。此外，在每兩個雷達傳感器之間建立專用通信。OEM的要求描述了雷達傳感器使用的通信類型。這可以在CAN總線、以太網(wǎng)或這兩者的組合上進行。鑒于車輛最多可配備16個雷達傳感器，在車輛的專用信道上可以有8對此類傳感器發(fā)起通信。在給定的時間，作為原始目標的數(shù)據(jù)在兩個雷達傳感器之間通過專用通信信道進行交換。這些數(shù)據(jù)是從環(huán)境中收集的，而私有通信的結果將在車輛通信信道內(nèi)創(chuàng)建和傳輸目標和警告。汽車傳感器的編號從汽車的前部開始。在這方面，標識為 S0 的傳感器將在專用通道上與傳感器S1建立通信；傳感器S2將與傳感器S3建立通信，依此類推?？紤]到在某個時間t0只有兩個傳感器可以在一個專用通道上進行通信，為了簡化軟件，一個位于左邊的傳感器（用偶數(shù)標識符-S0-S14命名）將發(fā)送名稱以"_S0 "結尾的報文。同時，一個右側(cè)位置的傳感器（用奇數(shù)標識符--S1-S15命名）將發(fā)送名稱以"_S1 "結尾的信息?？紤]到將在專用通道上傳輸?shù)臄?shù)據(jù)量較大，可以在以太網(wǎng)或CAN FD上發(fā)起通信。CAN FD的配置的仲裁速率是1Mb/s，配置的數(shù)據(jù)速率是2Mb/s。此外，以太網(wǎng)的總線速度配置為100Mb/s。
我們提出的解決方案稱之為私有數(shù)據(jù)適配器（PDA），它將成為77Ghz雷達傳感器軟件的一部分，在AUTOSAR層面上實施。此解決方案可以分為兩個部分，即軟件組件（SWC）和AUTOSAR復雜設備驅(qū)動器（CDD），如圖5所示。這兩個組件有助于在專用通道上進行通信。該實現(xiàn)以1:n的方式促進了報文的轉(zhuǎn)發(fā)，但同時它也存儲大量的數(shù)據(jù)，直到這些數(shù)據(jù)被處理。私有數(shù)據(jù)適配器SWC負責在其他SWC和Pdu 路由器之間交換數(shù)據(jù)。私有數(shù)據(jù)適配器CDD代表通信棧中的AUTOSAR上層，并實現(xiàn)私有數(shù)據(jù)適配器SWC傳輸或接收的所有私有報文。
圖 5 私有數(shù)據(jù)適配器模塊設計
PDA（圖6）使用專用軟件緩沖器來傳輸/接收每個報文，并以每60毫秒一次的速度循環(huán)運行。同時，它執(zhí)行報文的發(fā)送和接收，并通過RTE與其他SWC（如算法模塊）進行通信，或者直接與Pdu路由器進行通信。
圖 6 AUTOSAR開發(fā)流程中的PDA模塊
PDA SWC的結構是基于幾個子模塊實現(xiàn)的，如每個報文的傳輸、每個報文的接收和PDA的具體功能。除了報文的傳輸和接收，PDA模塊還負責以下工作：
  • 信號計算，這意味著對信號應用一個因子和/或一個偏移量，以便在CAN/以太網(wǎng)上傳輸原始值，并在接收端去除它，以獲得其他swc所需的物理值；
  • 范圍檢查，根據(jù)DBC中定義的范圍，和超出范圍的信號的默認值分配（最小值/最大值）；
  • 對收到的報文進行端到端（E2E）保護，通過驗證數(shù)據(jù)完整性的CRC信號，和檢查報文是否丟失的計數(shù)器信號檢來完成。
為了避免CAN FD總線沖突，AUTOSAR通信棧使用了后期構建可選變體，這些變體是為每個傳感器標識符定義的。在所有偶數(shù)變體（S0、S2等）上，報文命名以"_S0 "結尾。在所有其他變體上，報文的名稱以"_S1 "結尾。一個CAN總線上只連接兩個傳感器，因此每個報文只需要兩個不同的標識符。PDA負責讀取傳感器ID，并以相應的Pdu句柄ID將報文傳送到Pdu路由器。由于以太網(wǎng)不依賴于報文的ID，在通信棧中只定義了"_S0 "報文，PDA發(fā)送它時不依賴于傳感器標識符。例如，當傳感器ID = S0時，CAN幀信息為<報文名稱>_S0，而當傳感器ID = S1時，CAN幀信息是<報文名稱>_S1，等等。對于以太網(wǎng)幀，所有ID的格式將是相同的，即<報文名稱>_S0。
PDA模塊實現(xiàn)了兩種類型的報文：簡單的報文（最多64字節(jié)）和頭-數(shù)據(jù)-掛拖類型的復雜報文，可以在一個周期內(nèi)發(fā)送、接收多個數(shù)據(jù)報文。在報文大小超過CAN FD上規(guī)定的64字節(jié)時，可以定義為第二種類型的報文。發(fā)送和接收的報文中的最后三個字節(jié)專門用于端到端（E2E）保護：循環(huán)冗余檢查（CRC）信號和計數(shù)器信號。頭-數(shù)據(jù)-掛拖類型的復雜報文允許數(shù)據(jù)報文在一個周期內(nèi)被多次傳輸。對于每個定義的信號，都實現(xiàn)了一個設置（set）和獲取(get)函數(shù)，以便將信號寫入/讀出軟件緩沖區(qū)，也可以計算信號。例如，如果MessageTwoData報文的某個信號One_u8的系數(shù)為0.01，則定義了一個20的偏移量，以及一個范圍[20.5,20.5]。圖7 a,b中介紹了將信號設置到軟件緩沖區(qū)，以及從軟件緩沖區(qū)中獲取這些信號的操作。

圖 7 (a) 將信號設置到軟件緩沖區(qū)。(b) 從軟件緩沖區(qū)獲取信號。
4.1.1 PDA 傳輸
在DBC（CAN FD）或arxml（以太網(wǎng)）文件中的每個報文都有一個相應的發(fā)送信號子模塊。通常情況下，在兩個通道上以1:n的方式實現(xiàn)報文的傳輸。但是，也有僅在單個信道上實現(xiàn)和傳輸報文的情況。
所有報文的傳輸是以循環(huán)方式進行的，每60ms循環(huán)一次。如果傳輸被初始化并且被啟用，數(shù)據(jù)將在通道上傳輸。否則，數(shù)據(jù)將在CH0或CH1上傳輸，這取決于其可用性。該過程在圖8中描述。


圖 8 傳輸配置圖
報文傳輸?shù)牟襟E如圖9所示。此處，應傳輸?shù)臄?shù)據(jù)通過RTE接口從SWC讀取，然后逐個信號映射到PDA軟件緩沖區(qū)。除了從SWC讀取的信號外，軟件緩沖區(qū)還可能包含另外兩個專門用于端對端保護的信號（只有當報文將被其他傳感器接收時）。軟件緩沖器信息被復制到一個Pdu路由數(shù)據(jù)類型中，通過調(diào)用PduR_PdaTransmit函數(shù)和相應的Pdu句柄ID來完成其向通信棧的傳輸。


圖 9 報文傳輸圖
頭-數(shù)據(jù)-掛拖報文的傳輸包含三個不同的函數(shù)，每個報文包含一個函數(shù)，這就是為什么PduR_PdaTransmit會被多次調(diào)用，以傳輸多數(shù)據(jù)報文。
4.1.2 私有數(shù)據(jù)適配器（PDA）接收
報文的接收分兩步實現(xiàn)。第一步，假設當Pda_RxIndication回調(diào)函數(shù)被調(diào)用時，將從總線上收到的數(shù)據(jù)復制到PDA的軟件緩沖區(qū)（接收模式在通信棧中作為中斷實現(xiàn)）。在這個函數(shù)中，更新位被設置為“TRUE”，以表示收到了一條新報文（圖10）。此外，每個收到的報文都有一個相應的更新位。如果收到更多的消息，并且自上次報文處理之后沒有再接收報文，更新位將只設置一次，緩沖區(qū)將包含可供處理的最新數(shù)據(jù)。



圖 10 通過Pda RxIndication函數(shù)接收PDA圖解
報文接收不取決于傳感器標識符，因為AUTOSAR通信棧在其所有變體中對報文的是相同的Pdu句柄ID。PDA接收表與Pdule一致 ，它也不依賴于傳感器標識符。如果在Pdu 路由器中MessageOne_S0和MessageOne_S1報文有一個Pdu句柄ID為 "0"，那么將在接收端設置Pda_RxIndication()調(diào)用。在這種情況下，如果數(shù)據(jù)可用，它將被復制到緩沖區(qū)。如果更新位表已初始化，則設置更新位。
第二步，數(shù)據(jù)處理，這意味著每個信號被解壓并復制到SWC數(shù)據(jù)格式類型中。在處理數(shù)據(jù)之前，首先應清除更新位（設置為 "FALSE"）。之后，新數(shù)據(jù)通過RTE傳輸?shù)絊WC中。這個步驟是循環(huán)進行的。如果在一個周期內(nèi)多次收到相同的報文，數(shù)據(jù)將被重新處理（按規(guī)定的次數(shù)），這意味著 "最后的總是最好的“。報文接收的處理部分每60毫秒循環(huán)執(zhí)行一次。頭-數(shù)據(jù)-掛拖報文的接收與上面介紹的類似，只是在這種情況下，為每個報文（頭、數(shù)據(jù)、掛拖）都實現(xiàn)一個執(zhí)行函數(shù)。在Pda_RxIndication（圖11）中，每個消息的更新位都被設置。




圖 11 處理接收的數(shù)據(jù)
4.2 遠程訪問和測試
由于目前需要從公司的物理邊界以外的地方訪問雷達傳感器應用程序，因此形成了遠程測試功能。該傳感器與Arduino接口相連，如圖12所示。
Arduino的引腳與繼電器控制引腳、JTAG連接器（用于調(diào)試器）、DB25（用于傳感器）、DE9（用于連接到CAN）和調(diào)試器電源線相連。Arduino的數(shù)字引腳3與繼電器控制引腳相連。GND中斷線與NC（常閉）引腳相連，這意味著調(diào)試器將正常供電。為了安全起見，使用了一個二極管，放置在連接Arduino和繼電器的電線上，以便在發(fā)生短路時保護電路板。
為了實現(xiàn)調(diào)試器的條帶功能，調(diào)試器通過一個10引腳的條帶連接到JTAG端口。為了在傳感器上閃現(xiàn)新實現(xiàn)的代碼，這種連接是必需的。如果在代碼中出現(xiàn)了任何問題或錯誤，雷達傳感器將會重置。如果雷達傳感器連接到條帶，這種行為就不能被觀察到，因為調(diào)試器不允許傳感器復位。因此，測試必須在不連接條帶的情況下進行。


圖 12 雷達傳感器與Arduino的連接
10-引腳條帶需要10個具有單個觸點的繼電器來切斷電源。我們選擇了一個由五個繼電器組成的解決方案，每個繼電器有兩個觸點。Arduino產(chǎn)生的電流的最大電壓為5V，這個電壓太低，無法同時關閉所有五個繼電器。我們引入了第六個繼電器，并與Arduino連接，由處于常開狀態(tài)的外部電源供電。在這個繼電器的幫助下，可以控制其他5個并聯(lián)的繼電器，這樣施加在每個繼電器上的電壓是相同的。第一個繼電器將連接調(diào)試器的條帶，該條帶的10個引腳仍然與繼電器相連，這樣就有可能中斷電流。第二個繼電器的引腳將連接到繼電器的輸出端，并將一個與傳感器連接的條帶連接到它。
通過DB25連接器，為傳感器提供電流，更確切地說，是通過1號引腳。為了重置傳感器，必須中斷電源。
為了實現(xiàn)總線關閉功能，需要三個繼電器，其連接方式如下。CAN H到GND；CAN L到VCC；以及SHORT H到L。為了實現(xiàn)過載（圖13），需要兩個繼電器，CAN H和CAN L。為了確定傳感器在特殊情況下的反應，需要建立特定的連接，如CAN H到VCC、CAN L到GND。雷達傳感器接口模塊如圖14所示。

圖 13 總線關閉和過載功能
圖 14 雷達接口模塊
4.3 測試傳感器的應用程序
在我們的系統(tǒng)中，雷達生產(chǎn)模式（RPM）負責對雷達應用程序進行必要的測試，以衡量私有數(shù)據(jù)適配器模塊的性能。從RPM的角度來看，這些測試被視為服務。
第一次調(diào)用RPM模塊時，它會調(diào)用其他模塊初始化，但AUTOSAR中的BSW模塊除外。此外，它記錄執(zhí)行服務所需的所有任務，然后配置所有必要的引腳和寄存器。在成功完成所有這些步驟后，它在CAN總線上觸發(fā)一個信息，表示RPM已經(jīng)準備好接收一個請求報文。
有兩種類型的請求：單幀請求，這是簡單的請求，其數(shù)據(jù)包含在一個CAN報文的8個字節(jié)中；多幀請求，它需要幾個報文才能傳輸所有需要的數(shù)據(jù)。在多幀請求的情況下，第一個報文被發(fā)送，接著是一個來自RPM的報文。這個報文被稱為 "流控制"，表明RPM已經(jīng)準備好接收其余的報文。當在CAN總線上收到報文時，CAN模塊通過Rx Indication函數(shù)將報文內(nèi)容發(fā)送給模塊。這個功能根據(jù)RPM的狀態(tài)，確定收到的是什么類型的報文。然后對其進行處理，并將其內(nèi)容保存在一個內(nèi)部緩沖區(qū)中（圖15）。
圖 15 Rx Indication 函數(shù)
其中一個任務每毫秒被調(diào)用一次，叫做服務發(fā)現(xiàn)。它解析報文的內(nèi)容并檢查其結構和數(shù)據(jù)是否有效。緊接著，它檢查RPM的狀態(tài)。如果RPM已經(jīng)準備好執(zhí)行服務，它將繼續(xù)向下運行。如果需要額外的數(shù)據(jù)來幫助執(zhí)行服務，就會觸發(fā)一條報文發(fā)出信號。如果RPM還沒有準備好執(zhí)行服務，它將等待，直到狀態(tài)改變。一旦RPM準備好并繼續(xù)執(zhí)行，它就會確定所請求的服務屬于哪個組，報文內(nèi)容被發(fā)送到該服務組的過濾功能區(qū)。此步驟可見圖16的活動圖。
圖 16服務發(fā)現(xiàn)函數(shù)
請求的服務所屬的組的過濾功能將接收報文的內(nèi)容，然后檢查請求的服務是否存在。如果服務存在，則調(diào)用該服務，并在適當?shù)臅r候，將從報文中提取的執(zhí)行參數(shù)發(fā)送給該服務。例如，這些執(zhí)行參數(shù)可以是由寫入服務寫入的值，或者是報文之間的時間間隔，以及所選通信通道的測試服務所要暫存的報文數(shù)量。根據(jù)其復雜性和可配置性，也有一些服務具有自己的過濾功能。
如果在處理請求的過程中，該請求確定是無效的，無論是由于報文內(nèi)容的結構還是由于其不正確的值，處理都會停止，并通過發(fā)送一個否定報文包含來表明該請求是無效的，該否定報文包含與請求消息中遇到的錯誤相關的錯誤代碼。一旦被調(diào)用，該服務就試圖滿足請求。在成功的情況下，它將觸發(fā)發(fā)送一個包含服務結果的肯定報文。如果無法滿足請求，它就會觸發(fā)一個否定報文，其中包含與它無法滿足請求的原因有關的錯誤代碼。
5 成果
本節(jié)實現(xiàn)了第4節(jié)中提出的研究方法的第6步和第7步。首先，通過雷達生產(chǎn)模式下的服務，調(diào)查了內(nèi)存使用和運行時間測量。此外，對通過Pdu 路由器實現(xiàn)PDA的解決方案和完全AUTOSAR解決方案進行了分析，并比較了這兩種解決方案的優(yōu)缺點。
5.1 內(nèi)存使用情況
實驗中使用的測試裝置是由該大學和當?shù)匾患移嚬竞献鲃?chuàng)建的。將77Ghz雷達傳感器連接到公司總部的Arduino接口。因此，軟件開發(fā)人員或測試人員可以通過互聯(lián)網(wǎng)遠程連接到Arduino接口?；贏UTOSAR方法實現(xiàn)了三種不同報文（不同類型）的傳輸，并與基于Pda通過Pdu 路由器方法實現(xiàn)相同報文的傳輸進行了比較：
  • 一個簡單報文；
  • 一個復雜報文（頭部-數(shù)據(jù)-拖掛）；
  • 多路復用信息（假設在AUTOSAR方法軟件中引入IpuM AUTOSAR模塊）。
簡單消息被命名為MessageOne，其長度為64字節(jié)。復雜消息被命名為MessageTwo，MessageTwo數(shù)據(jù)在一個周期內(nèi)最多可以發(fā)送40次。MessageTwo頭部報文的長度為24字節(jié)；MessageTwo數(shù)據(jù)報文的長度為64字節(jié)，而MessageTwo拖掛報文的長度為3字節(jié)。多路復用報文，命名為MessageThree，有四種不同的布局，每一種布局都是根據(jù)一個選擇器字段（復用器）來區(qū)分和傳輸?shù)?。其長度為20字節(jié)。
所有其他的報文都通過Pdu路由器模塊在PDA中實現(xiàn)。這兩種方法的區(qū)別在于以下文件中：

  • Pda_Send_MessageOne_Exec.c;
  • Pda_Send_MessageTwo_Exec.c;
  • Pda_Send_MessageThree_Exec.c.
我們調(diào)查了RAM（EMEM）和ROM（程序閃存）的內(nèi)存使用情況，并對兩種解決方案進行了運行時測量。如第4.3節(jié)所述，RPM通過使用專用服務來進行這些測量。
表 1 列出了優(yōu)化解決方案（即通過 Pdu路由器實現(xiàn) PDA）的模塊使用結果，并與使用傳統(tǒng) AUTOSAR 解決方案（沒有實施優(yōu)化解決方案）的結果進行了比較。可以注意到，在采用通過Pdu路由器實現(xiàn)PDA情況下，Pda_Send的內(nèi)存用量低于完全 AUTOSAR 的情況。EMEM和程序閃存塊方面，也是同樣的結果。

通過Pdu路由器實現(xiàn)PDA解決方案的對象內(nèi)存使用結果與完全 AUTOSAR方案的對象內(nèi)存使用結果進行了比較，見表 2。可以注意到，在復雜的頭-數(shù)據(jù)-拖掛報文中取得了最大的改進，而在簡單報文和多路報文的情況下，通過Pdu優(yōu)化實現(xiàn)的PDA方案，ROM內(nèi)存的使用率得到了改善。
5.2 運行時間測量
在調(diào)試環(huán)境下，使用系統(tǒng)定時寄存器0（STM0）對每個報文傳輸連續(xù)三次（從啟動開始）的執(zhí)行運行時測量，具體如下：
  • 起始點：對于通過Pdu路由器實現(xiàn)Pda的解決方案，起點是PduR_PdaTransmit()。Full AUTOSAR 解決方案的起始點是Rte_Write_<MessageName>()。
  • 結束點：在這兩種情況下，結束點都是CanIf_TxConfirmation() 。
在表3和表4中可以注意到，從運行時測量結果來看,PDA通過Pdu路由器的優(yōu)化方案對每個測試報文都有改進。此外，在執(zhí)行的每一次活動中，改進最明顯的是多路復用報文。


5.3 討論情況
本文的（RQ3）旨在從性能方面分析擬議的AUTOSAR通信優(yōu)化解決方案的收益。以往關于AUTOSAR雷達傳感器優(yōu)化的工作沒有解決本文提出的AUTOSAR層面的通信問題；因此，從文獻綜述中，我們參考了旨在衡量性能的評價方法。從之前的實驗中可以看出，通過Pdu路由器實現(xiàn)PDA的解決方案，其最大優(yōu)勢在于數(shù)據(jù)傳輸?shù)膱?zhí)行時間。事實證明，它比完全AUTOSAR解決方案要快得多。圖17中總結了結果，對于每種報文類型（X軸），給出了相應的測量值（Y軸）。
圖 17 運行時測量結果比較
在ROM內(nèi)存消耗方面，與完全AUTOSAR解決方案相比，通過Pdu路由器實現(xiàn)PDA優(yōu)化方案使用的內(nèi)存資源更少。完全AUTOSAR解決方案使用的內(nèi)存資源幾乎是后者的2倍。在圖18中，通過強調(diào)報文類型（X軸）和區(qū)段長度（Y軸）來展示這些結果。傳統(tǒng)AUTOSAR另一個可能的缺點是它對DBC布局的依賴性。隨著每次報文布局的變化（例如增加/刪除一個信號），必須更新相應的軟件緩沖區(qū)。
圖 18 關于程序閃存的對象內(nèi)存使用情況的比較
僅通過RTE與其他SWC和Com模塊的交互，代表了PDA SWC的抽象性，突出了完全AUTOSAR解決方案的主要優(yōu)勢。因此，這種通信方法以允許獨立于PDU手柄ID。此外，由于AUTOSAR通信棧代碼的維護只需要更少的努力，因此強調(diào)了完全AUTOSAR解決方案的另一個優(yōu)勢。如果通信棧需要改變，基于當前的DBC，模塊會通過一個自動執(zhí)行的配置更新過程進行更新。當一個新的報文被添加到DBC時，通過Pdu路由器實現(xiàn)PDA的解決方法意味著從Com模塊中刪除PDU，并在導入報文后添加一個到PDA CDD的新路由。如果使用完全 AUTOSAR 方法，在 DBC 導入之后，不需要進行額外的更改。然而，在采用通過Pdu路由器實現(xiàn)PDA方法時，RAM內(nèi)存的占用量較低。
6 結論
本文提出了一個優(yōu)化AUTOSAR通信的解決方案，作為對我們（RQ1）的回應。這種方法假定兩個連接的雷達傳感器始終是同步的。在不同步的情況下（例如，由意外復位引起），PDA的行為將直接受到影響。為了解決(RQ2)問題，我們構建了一個基于Arduino的接口，其中附加了雷達傳感器，允許從任何位置進行遠程訪問。這個接口提供了基于AUTOSAR應用直接訪問雷達傳感器可能性，即使在目前Covid-19限制期間在家庭辦公室訪問。對于（RQ3），我們實施了一個單獨的軟件模塊，該模塊能夠進行性能測試，以確定我們的解決方案能提供哪些優(yōu)勢。根據(jù)前一章的結果，通過Pdu路由器的PDA解決方案在內(nèi)存使用和運行時間測量方面比完全AUTOSAR更有優(yōu)勢。PDA模塊能夠以靈活的方式傳輸和接收大量數(shù)據(jù)，因為它能夠處理事件和時間觸發(fā)報文。
分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25