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

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

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

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

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

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

AP在傳統(tǒng)CP基礎(chǔ)上增加了通信技術(shù)優(yōu)化設(shè)計(jì)，可以充分利用基于以太網(wǎng)的通信功能并從中受益。AP 主要提供高性能的計(jì)算和通信機(jī)制，并提供靈活的軟件配置，例如支持無線更新軟件。專門為 CP 定義的功能(例如訪問電信號(hào)和汽車專用總線系統(tǒng))可以集成到AP中。同時(shí)，對(duì)于功率節(jié)省來講，最佳的能效比則是通過混合不同的計(jì)算資源實(shí)現(xiàn)，比如多核、協(xié)處理器、GPU、FPGA和加速器的聯(lián)合運(yùn)作實(shí)現(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)通常運(yùn)行在ARA(AUTOSAR Runtime for Adaptiveapplications，自適應(yīng)應(yīng)用程序的運(yùn)行平臺(tái))上，ARA由功能群集(FCs)提供的應(yīng)用程序接口組成，這些集群屬于Adaptive Platform Foundation或 Adaptive Platform Services，分別提供 AP 的基本功能和服務(wù)。屬于 Adaptive Platform Foundation的功能集群是“基于庫的”，而 AdaptivePlatform Services 是“基于服務(wù)的”。ARA通過隱形接口確保自適應(yīng)應(yīng)用程序之間可以有效進(jìn)行交互。狀態(tài)管理使用標(biāo)準(zhǔn)ARA接口來維護(hù)不同AP堆棧實(shí)現(xiàn)之間的可移植性。應(yīng)用程序通信管理(CM，Communication Management)可以為機(jī)器內(nèi)提供面向服務(wù)的通信，并處理Service請(qǐng)求與應(yīng)答之間的路由，不必關(guān)系他們之間的拓?fù)洳渴稹?/p>

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

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

ara :: com 和 ara :: rest 這兩個(gè)通信堆棧都可以在自適應(yīng)應(yīng)用程序之間建立通信路徑。ara:: rest 是一個(gè) framework，用于在此類 API之上構(gòu)建 RESTful API以及特定服務(wù)。整個(gè)框架設(shè)計(jì)嚴(yán)格針對(duì)最大的資源控制?？梢試?yán)格控制和定制所有計(jì)算和分配，以適合應(yīng)用程序(部署)的確切需求。

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

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

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

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

3)運(yùn)行機(jī)器Machine/Hardware

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

4)狀態(tài)管理

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

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

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

5)Manifest模型描述

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

總體上Manifest定義細(xì)分為如下幾個(gè)階段：

其中，執(zhí)行 Manifest 的目的是提供將應(yīng)用程序?qū)嶋H部署到 AUTOSAR AP 所需的信息(包括啟動(dòng)配置應(yīng)用程序?qū)嵗唾Y源管理)。總體思路是保持應(yīng)用程序軟件代碼與部署方案盡可能獨(dú)立，以增加應(yīng)用程序軟件可以在不同部署方案中重用的幾率。最終，自適應(yīng)平臺(tái)實(shí)例會(huì)運(yùn)行在特定硬件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)相比，它可以更有效地傳輸長消息、實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)通信等。

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

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

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

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

7)其他方面

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

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

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

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

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

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

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

04 總結(jié)

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

審核編輯：湯梓紅