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

AP Autosar的架構部署原理

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

01 AP與CP之間的關系

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

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

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

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

1)AP Autosar架構方案

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

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

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

ara :: com 和 ara :: rest 這兩個通信堆棧都可以在自適應應用程序之間建立通信路徑。ara:: rest 是一個 framework，用于在此類 API之上構建 RESTful API以及特定服務。整個框架設計嚴格針對最大的資源控制。可以嚴格控制和定制所有計算和分配，以適合應用程序(部署)的確切需求。

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

應用程序的生命周期管理由執行管理(EM，Execution Management)模塊進行程序加載/啟動的。但該模塊不決定應用程序的啟動和終止時間，該啟動和終止時間由狀態管理SM進行特殊控制的，并且需要在系統集成/運行時進行適當的配置才能啟動程序。

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

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

3)運行機器Machine/Hardware

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

4)狀態管理

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

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

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

5)Manifest模型描述

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

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

其中，執行 Manifest 的目的是提供將應用程序實際部署到 AUTOSAR AP 所需的信息(包括啟動配置應用程序實例和資源管理)。總體思路是保持應用程序軟件代碼與部署方案盡可能獨立，以增加應用程序軟件可以在不同部署方案中重用的幾率。最終，自適應平臺實例會運行在特定硬件Machine上。該過程包括配置網絡連接并定義網絡技術基本憑證、Service 發現技術配置、Machine狀態定義等等。

6)通信網絡

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

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

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

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

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

7)其他方面

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

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

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

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

03 Autosar AP 在SOA的開發流程

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

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

04 總結

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

審核編輯：湯梓紅