近年來，隨著汽車的智能化程度越來越高，處理器的性能要求也大大提高。通常是在CP Autosar端采用多核處理器移植相應(yīng)的軟件算法，對于高階自動駕駛來說其對處理能力的需求遠超多核。許多具有數(shù)十到數(shù)百個內(nèi)核的眾核處理器、GPGPU(GPU的通用用途)、FPGA和專用加速器正在出現(xiàn)，因為這些處理器提供的性能比傳統(tǒng) MCU高出一個數(shù)量級。

AP Autosar的架構(gòu)部署原理

隨著內(nèi)核數(shù)量的不斷增加，原本為單核 MCU 設(shè)計的 CP 雖然可以支持多核，但是效率卻極度降低。主要體現(xiàn)在隨著內(nèi)核數(shù)量增加，單核MCU所布局的CP計算能力已經(jīng)遠超其本身負荷。并且，隨著計算能力的不斷增長，在諸如數(shù)據(jù)中心、功耗效率、主頻率也已經(jīng)成為一個問題，對于如何布局各個ECU軟件模塊到各個性能核上就顯得尤為重要。同時，對于功率利用率來講，最佳性能指標是通過異構(gòu)計算來實現(xiàn)，也即混合不同的計算資源(如Many Core、協(xié)處理器、GPU、FPGA、加速器等)，強大的處理能力和快速的芯片內(nèi)通信速度，也促使開發(fā)者建立一種新的平臺，以適應(yīng)不斷增長的系統(tǒng)要求。

01 AP與CP之間的關(guān)系

首先我們需要從根源上講講AP和CP的關(guān)系實際上，AP Autosar是集成了CP Autosar和非Autosar ECU，AP 不會取代顯示端 IVI / COTS 中的 CP 平臺或 非AUTOSAR 平臺。而是與這些平臺和外部后端系統(tǒng)進行交互，形成集成系統(tǒng)。同時，除了基礎(chǔ)的以太網(wǎng)協(xié)議外，CP和AP都可以支持了SOA中的基礎(chǔ)服務(wù)協(xié)議Some/IP。

AP 定義了運行時系統(tǒng)架構(gòu)，構(gòu)成平臺，也定義了該平臺提供的功能和接口。它還定義了在此類系統(tǒng)的開發(fā)中使用的 Machine可讀模型。該規(guī)范應(yīng)提供有關(guān)使用平臺開發(fā)系統(tǒng)的必要信息，以及實現(xiàn)平臺本身需要滿足的條件。

AP在傳統(tǒng)CP基礎(chǔ)上增加了通信技術(shù)優(yōu)化設(shè)計，可以充分利用基于以太網(wǎng)的通信功能并從中受益。AP 主要提供高性能的計算和通信機制，并提供靈活的軟件配置，例如支持無線更新軟件。專門為 CP 定義的功能(例如訪問電信號和汽車專用總線系統(tǒng))可以集成到AP中。同時，對于功率節(jié)省來講，最佳的能效比則是通過混合不同的計算資源實現(xiàn)，比如多核、協(xié)處理器、GPU、FPGA和加速器的聯(lián)合運作實現(xiàn)。

02 AP Autosar的幾大關(guān)鍵模塊典型應(yīng)用原理

1)AP Autosar架構(gòu)方案

AP Autosar的邏輯視圖體現(xiàn)了其相應(yīng)的體系結(jié)構(gòu)，自適應(yīng)應(yīng)用程序(Adaptive Application，AA)通常運行在ARA(AUTOSAR Runtime for Adaptiveapplications，自適應(yīng)應(yīng)用程序的運行平臺)上，ARA由功能群集(FCs)提供的應(yīng)用程序接口組成，這些集群屬于Adaptive Platform Foundation或 Adaptive Platform Services，分別提供 AP 的基本功能和服務(wù)。屬于 Adaptive Platform Foundation的功能集群是“基于庫的”，而 AdaptivePlatform Services 是“基于服務(wù)的”。ARA通過隱形接口確保自適應(yīng)應(yīng)用程序之間可以有效進行交互。狀態(tài)管理使用標準ARA接口來維護不同AP堆棧實現(xiàn)之間的可移植性。應(yīng)用程序通信管理(CM，Communication Management)可以為機器內(nèi)提供面向服務(wù)的通信，并處理Service請求與應(yīng)答之間的路由，不必關(guān)系他們之間的拓撲部署。

同時，AA和FC之間的調(diào)用不是通過IPC的進程間通信進行，而是常規(guī)的庫函數(shù)調(diào)用進行的。在ARA接口下，包括在 AA上下文中調(diào)用的ARA 庫，可以使用 ARA以外的其他接口來實現(xiàn) AP 規(guī)范，這取決于 AP 實現(xiàn)的設(shè)計。

從操作系統(tǒng)的角度來看，AP 和 AA只是形成一組進程，每個進程包含一個或多個線程。盡管這些進程的實現(xiàn)取決于 AP 的實現(xiàn)方式，但它們之間沒有區(qū)別。這些進程通過進程間通信IPC 或任何其他可用的 OS 功能相互交互。這里需要注意，自適應(yīng)應(yīng)用程序進程可能不會直接使用 IPC，而只能通過 ARA進行通信。

ara :: com 和 ara :: rest 這兩個通信堆棧都可以在自適應(yīng)應(yīng)用程序之間建立通信路徑。ara:: rest 是一個 framework，用于在此類 API之上構(gòu)建 RESTful API以及特定服務(wù)。整個框架設(shè)計嚴格針對最大的資源控制?？梢試栏窨刂坪投ㄖ扑杏嬎愫头峙?，以適合應(yīng)用程序(部署)的確切需求。

2)應(yīng)用程序執(zhí)行控制管理

應(yīng)用程序的生命周期管理由執(zhí)行管理(EM，Execution Management)模塊進行程序加載/啟動的。但該模塊不決定應(yīng)用程序的啟動和終止時間，該啟動和終止時間由狀態(tài)管理SM進行特殊控制的，并且需要在系統(tǒng)集成/運行時進行適當?shù)呐渲貌拍軉映绦颉?/p>

實際上，從EM的角度來看，所有的功能集群都是應(yīng)用程序，除了EM本身外，他們也以相同的方式啟動。自適應(yīng)應(yīng)用程序AA和功能集群可以使用任何非標準接口，只要它們不與標準 AP 功能沖突，并且它們符合項目的安全性要求即可。

對于數(shù)據(jù)確定性，執(zhí)行管理提供了 DeterministicClient API，以支持對內(nèi)部流程的控制，確定性工作人員池，激活時間戳和隨機數(shù)。對于軟件鎖步，DeterministicClient 與可選的軟件鎖步框架進行交互，以確保冗余執(zhí)行的流程具有相同的行為。DeterministicClient 與 CommunicationManagement 進行交互，以使數(shù)據(jù)處理與周期激活同步。

3)運行機器Machine/Hardware

AP 將運行在其上的硬件視為一臺虛擬機Virtual Machine，多臺 Machine之間以及與其他傳感器之間的主要互連機制預(yù)計將基于以太網(wǎng)進行，其背后的原理是獲得一致的平臺視圖，而不考慮可能使用的任何虛擬化技術(shù)。對功能應(yīng)用程序的分布式，獨立和敏捷開發(fā)的支持需要一種標準化的開發(fā)方法。AUTOSAR 自適應(yīng)方法論涉及工作產(chǎn)品的標準化，用于描述諸如服務(wù)，應(yīng)用程序，Machine及其配置之類的工件。

4)狀態(tài)管理

狀態(tài)管理是一個獨特的功能集群(FC)，主要用于特定于 ECU開發(fā)項目，并且通常最終實現(xiàn)由系統(tǒng)集成商執(zhí)行。它負責(zé) AUTOSAR 自適應(yīng)平臺的運行狀態(tài)的所有方面，包括處理傳入事件，確定這些事件/請求的優(yōu)先級以設(shè)置相應(yīng)的內(nèi)部狀態(tài)。

狀態(tài)管理可以根據(jù)項目需求由一個或多個狀態(tài)機組成。狀態(tài)管理通過項目特定的 ara :: com Service Interface(由“Fields”組成)與自適應(yīng)應(yīng)用程序進行交互。狀態(tài)管理和其他功能集群之間的交互應(yīng)通過每個功能集群定義的標準化接口(IFC)來完成。

為了實現(xiàn)同步行為，在狀態(tài)管理中可提供已定義的消息和應(yīng)答消息，這些已定義的消息和應(yīng)答消息在 ara :: com 方法和字段在“通信管理”的“通信組”范圍內(nèi)生成。同時，網(wǎng)絡(luò)管理(NM)可以通過狀態(tài)管理進行控制，因為部分網(wǎng)絡(luò)的控制需要通過 SM 控制的 EM 的功能組狀態(tài)與相關(guān)應(yīng)用程序的集合進行協(xié)調(diào)，狀態(tài)管理則可通過項目特定的 ARA:: com Service Interface(由“Fields”組成)與自適應(yīng)應(yīng)用程序進行交互，執(zhí)行過程中可以實現(xiàn)包含設(shè)置功能組專用狀態(tài)、激活/取消部分網(wǎng)絡(luò)功能、關(guān)閉/重啟Machine等相關(guān)的過程狀態(tài)控制。

5)Manifest模型描述

Manifest僅僅作為AUTOSAR 一種模型描述，平臺軟件和應(yīng)用軟件的程序分別由執(zhí)行管理根據(jù) MachineManifest 和 Execution Manifest 信息確定。在開發(fā)項目中，大部分的ARXML會被自動視為Manifest。Manifest的描述是為了支持 AUTOSAR AP 產(chǎn)品的配置而創(chuàng)建的，并會搭載到 AUTOSAR AP 產(chǎn)品上，并可能與其他包含 Manifest 文件的可執(zhí)行代碼的工件(如二進制文件)結(jié)合使用。存在與Manifest 相關(guān)的模型元素，且這些元素在典型開發(fā)項目的不同階段都具有相關(guān)性。

總體上Manifest定義細分為如下幾個階段：

其中，執(zhí)行 Manifest 的目的是提供將應(yīng)用程序?qū)嶋H部署到 AUTOSAR AP 所需的信息(包括啟動配置應(yīng)用程序?qū)嵗唾Y源管理)?？傮w思路是保持應(yīng)用程序軟件代碼與部署方案盡可能獨立，以增加應(yīng)用程序軟件可以在不同部署方案中重用的幾率。最終，自適應(yīng)平臺實例會運行在特定硬件Machine上。該過程包括配置網(wǎng)絡(luò)連接并定義網(wǎng)絡(luò)技術(shù)基本憑證、Service 發(fā)現(xiàn)技術(shù)配置、Machine狀態(tài)定義等等。

6)通信網(wǎng)絡(luò)

車載網(wǎng)絡(luò)不斷增長的帶寬要求導(dǎo)致引入了以太網(wǎng)，該以太網(wǎng)提供更高的帶寬并具有交換網(wǎng)絡(luò)，與傳統(tǒng)的車載通信技術(shù)(例如 CAN)相比，它可以更有效地傳輸長消息、實現(xiàn)點對點通信等。

通信管理負責(zé)分布式實時嵌入式環(huán)境中應(yīng)用程序之間的所有通信，對于SOA的整個開發(fā)來說主要指面向服務(wù)的通信。通信管理軟件為機器內(nèi)通信以及機器間通信提供了使用此類服務(wù)的機制?？梢栽谠O(shè)計時、啟動時或運行時建立通信伙伴之間的通信路徑。該機制的重要組成部分是 Service Registry 中心，它充當中介實例為每個應(yīng)用程序注冊對應(yīng)的服務(wù)，通過查詢Service Registry來找到請求的服務(wù)，并且也是通信管理軟件的一部分。

當前，通信管理支持 SOME /IP，DDS，IPC(進程間通信或任何其他自定義綁定)和 Signal PDU(基于信號的網(wǎng)絡(luò)綁定)。

對于 ServiceMethods，Service Requester Proxies 提供了同步(阻止調(diào)用者直到服務(wù)器返回結(jié)果)和異步調(diào)用(被調(diào)用函數(shù)立即返回)的機制。

網(wǎng)絡(luò)管理(NM)旨在通過狀態(tài)管理進行控制，因為部分網(wǎng)絡(luò)的控制需要通過 SM 控制的 EM 的功能組狀態(tài)與相關(guān)應(yīng)用程序的集合進行協(xié)調(diào)。

7)其他方面

診斷——管理代表基礎(chǔ)層上 AdaptivePlatform 的功能集群。該配置基于經(jīng)典平臺的AUTOSAR 診斷提取模板(DEXT)。DoIP 是一種車輛發(fā)現(xiàn)協(xié)議，旨在與診斷基礎(chǔ)架構(gòu)(診斷客戶端，生產(chǎn)/車間測試儀)進行車外通信。車載或遠程診斷通常使用其他傳輸協(xié)議，因此提供了使用自定義傳輸層擴展平臺的API。

時間同步-——當需要跨分布式系統(tǒng)的不同事件之間的關(guān)聯(lián)時，不同應(yīng)用程序和/或 ECU 之間的時間同步(TS)至關(guān)重要，以便能夠及時跟蹤此類事件或在準確的時間點觸發(fā)它們。因此，為應(yīng)用程序提供了時間同步 API，因此它可以檢索與其他實體/ ECU 同步的時間信息。然后，通過不同的“Time Base Resources”(從現(xiàn)在開始稱為 TBR)提供時間同步功能，這些“Time Base Resources”通過預(yù)構(gòu)建配置存在于系統(tǒng)中。時間同步模塊包括考慮啟動行為、構(gòu)造函數(shù)行為(初始化)、正常操作、錯誤處理等幾個方面。

功能安全與信息安全驅(qū)動——AP 瞄準的系統(tǒng)通常需要某種級別的安全性，可能是最高級別。新概念和新技術(shù)的引入不應(yīng)破壞這些要求，盡管要實現(xiàn)它并非易事。為了應(yīng)對挑戰(zhàn)，AP 結(jié)合了架構(gòu)，功能和程序方法。該體系結(jié)構(gòu)基于 SOA的分布式計算，從而使每個組件固有地變得更加獨立且不受意外干擾;有助于實現(xiàn) Safety 和 Security 的專用功能。

車載軟件實時更新——新的車輛功能(例如高度自動駕駛)將在車輛中引入高度復(fù)雜且計算量大的軟件，并且必須滿足嚴格的完整性和安全性要求。這種軟件可實現(xiàn)諸如環(huán)境感知和行為計劃之類的功能，并將車輛集成到外部后端和基礎(chǔ)架構(gòu)系統(tǒng)中。由于不斷發(fā)展的外部系統(tǒng)或改進的功能，需要在車輛的生命周期內(nèi)更新車輛中的軟件。

03 Autosar AP 在SOA的開發(fā)流程

除了應(yīng)用程序設(shè)計和不同種類的Manifest 外，AUTOSAR 方法論還支持系統(tǒng)設(shè)計，它有可能在一個單一模型中描述將在系統(tǒng)中使用的兩個 AUTOSAR 平臺的軟件組件。不同的 AUTOSAR 平臺的軟件組件可以以面向服務(wù)的方式相互通信。但是也有可能描述信號到服務(wù)的映射，以在面向服務(wù)的通信與基于信號的通信之間建立橋梁。

在SOA環(huán)境中， Client 和服務(wù)的 provider通過 服務(wù)接口和行為連接在一起。在開發(fā)服務(wù)期間，服務(wù)接口或行為可能會隨時間而改變。因此，已引入服務(wù)合同 Contract Versioning 以區(qū)分服務(wù)的不同版本。AUTOSAR 自適應(yīng)平臺支持Contract 的 Versioning 設(shè)計，以用于服務(wù)的設(shè)計和部署階段。

04 總結(jié)

在中央計算單元中，使用APAUTOSAR 架構(gòu)可以滿足一些模塊化、動態(tài)化的需求。使用UCM(升級通信管理)功能集群，可以滿足一些OTA的功能要求。 可以使用AP AUTOSAR滿足運行時建立動態(tài)通信路徑的需求。也可以使用PHM(平臺健康管理)和Crypto(加密)滿足一些Safety和Security的需求。同時，AP Autosar也包含有智能ECU和相應(yīng)的技術(shù)驅(qū)動程序，且需要使用更多的計算能力。AP也支持應(yīng)用程序的增量部署，在其中動態(tài)管理資源和通信，以減少軟件開發(fā)和集成的工作量，從而縮短迭代周期，增量部署還支持探索性軟件開發(fā)階段。但是無論國內(nèi)還是國外，對于這塊研究的并不成熟，要真正應(yīng)用于工程化量產(chǎn)項目的開發(fā)還有很長的路要走。

審核編輯：湯梓紅