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

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

隨著內(nèi)核數(shù)量的不斷增加，原本為單核 MCU 設計的 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ā)者建立一種新的平臺，以適應不斷增長的系統(tǒng)要求。

01 AP與CP之間的關系

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

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

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

02 AP Autosar的幾大關鍵模塊典型應用原理

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

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

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

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

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

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

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

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

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

3)運行機器Machine/Hardware

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

4)狀態(tài)管理

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

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

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

5)Manifest模型描述

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

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

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

6)通信網(wǎng)絡

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

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

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

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

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

7)其他方面

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

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

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

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

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

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

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

04 總結(jié)

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

審核編輯：湯梓紅