官方檔案下載方式及介紹情參見 Adaptive AUTOSAR 學習筆記 2 - 官方檔案下載及閱讀建議，

這是 Adaptive AUTOSAR 學習筆記的第 8 篇，學習筆記 3 - 7 翻譯了 Adaptive AUTOSAR 官方檔案 AUTOSAR_EXP_PlatformDesign.pdf 的前三個章節，繼續學習之前先做個總結回顧（沒有嚴格遵循原文內容，增加了些源自實際專案的理解）：

縮寫

AP：AUTOSAR Adaptive Platform
AA：Adaptive Application
ARA：AUTOSAR Runtime for Adaptive Applications
FC：Functional Cluster
EM：Execution Management
SM：State Management
CM：Communication Management

2 技術范圍和方法

傳統 CP 無法滿足新 ECU 的需求，AP 提供了：

高性能計算和通信機制
靈活的軟體配置，以支持 OTA 軟體升級

2.2 技術驅動

以太網：高帶寬，交換網路、傳輸效率高
處理器：眾核、異構計算（GPGPU、FPGA、硬體加速）的發展、電源效率的提升、高效的處理器間通信

2.3 AP 特征

C++
SOA 面向服務的架構
并行計算
利用現有標準
功能安全和資訊安全
計劃動態：限制某些動態配置(?)
敏捷開發

2.4 CP、AP 以及非 AUTOSAR ECU 的集成

AP 不是取代 CP 以及非 AUTOSAR 的 ECU，而是互相協作，

3 架構

3.1 邏輯視角

3.1.1 ARA

AA 運行于 ARA 之上，ARA 由 FC 提供的介面組成，FC 介面有兩種：

Foundation（也有資料稱之為 API）：提供 AP 基礎功能，AA 可直接呼叫 library 的 API
Service：提供 AP 平臺標準服務，通過 SOA（ara::com）提供服務介面

AA 也可以向其他 AA 提供服務，

FC 的介面，不論是 Foundation 還是 Service，在 AA 看來都是一些 C++ 介面（雖然 ARA 介面之下確有不同），注意：ARA 介面之下，包括 AA 鏈接的 ARA 庫，可以使用 ARA 之外的介面，

ara::diag 在 R19-11 之前是 Service，從 R19-11 開始，改為 Foundation，

3.1.2 語言系結，C++ 標準庫和 POSIX API

C++ 標準庫包含很多基于 POSIX 的介面，包括多執行緒 API，但是 C++ 標準庫沒有覆寫所有 PSE51 API，比如設定執行緒調度策略，

3.1.3 應用啟動關閉

應用的生命周期由 EM （Execution Management）控制，但 EM 本身不做決策，而是由 SM（State Management）決定什么時候啟動/停止應用，

OS 啟動 EM，EM 根據 Manifest 啟動其他 FC 以及應用，在 EM 看來所有其他的 FC 都是應用，

3.1.4 應用介面

PSE51 不含 IPC，AA 之間不能直接通信，只能通過 CM（Communication Management），CM 提供基于服務的通信，支持本機和跨機器通信（對應用來說是透明的），

3.1.5 非標介面

AA 和 FC 可以使用非標介面，只要不和標準 AP 功能沖突，除非是純本地的運行庫，盡量少用非標介面，以保證可移植性，

3.2 物理視角

3.2.1 作業系統，行程和執行緒

AA 都是一個或多個獨立的行程
FC 一般實作為一個或多個行程（言外之意可以是庫）
所有 Service 都是行程（包括 FC 提供的 Platform Service 和 AA 提供的 Non-PF Service）
所有行程可以是單執行緒，也可以是多執行緒
ARA 之上的 AA 只能使用 PSE51 系統 API；FC 可以使用任何系統 API
從系統看來，AP 和 AA 都是行程，AA 不能直接使用 IPC，只能通過 ARA 通信

3.2.2 基于庫或基于服務的 FC 實作

FC 可以是 Foundation 模塊，也可以是 Service，Foundation 和 Service 一般都是行程，如果要和 AA 行程通信，需要 IPC，有兩種替代設計：

基于庫：AA 鏈接 FC 的介面庫，FC 介面庫直接呼叫 IPC
基于服務：AA 鏈接服務 Proxy 庫，Proxy 庫呼叫 CM 的介面，間接實作行程間通信

如何選擇取決于 FC 實作：基于庫簡單、高效；基于服務支持跨 AP 實體服務呼叫，

注意：FC 可以只有庫，沒有行程！此時 FC 庫運行于 AA 的行程背景關系中，對 AA 來說，就是普通的函式呼叫，不涉及 IPC，

3.2.3 FC 之間的互動

FC 之間的互動不受限于 ARA 介面（如 PSE51）
FC 可以使用其他 FC 的 public ARA 介面
更常見的是 FC 使用其他 FC 的 protected 介面，相比 public 的 ARA 介面，多一些特權

3.2.4 機器/硬體

運行 AP 的硬體在 AP 中統稱為 Machine
可能是一個真實的物理機器，也可能是完全虛擬機、準虛擬系統或容器
一個 Machine 上只運行一個 AP 實體
一個 chip 上運行一個或多個 Machine（也可能多個 chip 組成一個 Machine）

3.3 方法論和 Manifest

AP 方法論包含兩部分：

ARXML（用于描述、配置的 Application Design、Execution Manifest、Service Instance Manifest 以及 Machine Manifest）的標準化
定義上述 ARXML 之間如何互動以交換設計資訊

方法論和開發流程：

大致步驟如下：

在 AP 工具鏈/平臺配置工具中配置平臺、目標硬體資訊，如處理器型號、核心數、機器 IP 地址、SOME/IP 埠等資訊，生成 Machine Manifest
在 AP 工具鏈/應用設計工具中定義服務，如資料型別、服務介面、組件等
a) AP 工具鏈自動生成 Application Design 的 ARXML 檔案
b) AP 工具鏈/代碼生成器基于 Application Design 的 ARXML 生成 Proxy 和 Skeleton 的 .h 和 .cpp 檔案
軟體開發
a) Service 應用實作 Skeleton 的介面
b) Client 應用通過 Proxy 類（經由 CM）間接呼叫 Service
c) 編譯生成可執行檔案
軟體集成：在 AP 工具鏈/可執行檔案配置工具中配置可執行檔案路徑、實體（行程）數、啟動引數、環境變數、調度策略、UID/GID 等資訊，生成 Execution Manifest
AP 工具鏈提取 Application Design 中的服務介面資訊，在服務實體配置工具中添加額外的 SOME/IP 配置，如 Service ID，Method ID，Event ID 等，生成 Service Instance Manifest
上述可執行檔案、Execution Manifest、Service Instance Manifest 作為一個 SW Package 上傳到目標硬體
a) 目標硬體中 SW Configuration Management 根據 Manifest 資訊部署、驗證、安裝應用
b) 根據 AP 平臺的實作，可以（不強制）預處理 Manifest 檔案，如匯入資料庫，以提高執行效率
c) EM 根據 Execution Manifest 的資訊呼叫 OS API 啟動、配置、關閉應用（FC 以及 AA）

3.4 Manifest

Manifest 代表了 AUTOSAR 模型描述，上傳到 AP，用于配置 AP，AP 中的 ARXML 不都是 Manifest，比如 Application Design，

3.5 Application Design

應用設計建模，定義資料型別、介面、組件等資訊，不需要部署到 AP 機器上，但組件、介面資訊會被 Execution Manifest 和 Service Instance Manifest 參考，

3.6 Execution Manifest

定義每個可執行檔案實體化幾個行程，每個行程的的啟動引數、環境變數、UID/GID、資源組、調度策略、何時啟動、停止等都可以獨立配置，

3.7 Service Instance Manifest

針對特定的傳輸協議（如 SOME/IP），進行面向服務通信的配置，如 Service ID，Method ID，Event ID，埠等，

3.8 Machine Manifest

描述運行 AUTOSAR AP 的機器，如硬體資源描述（RAM、處理器、核心數）、以太網 IP 地址（靜態分配或者 DHCP 動態分配），SOME/IP 埠、機器狀態定義（On/Off/Start/Restart/Shutdown...）等，處理器核心、機器狀態又會被 Execution Manifest 參考，

Adaptive AUTOSAR 學習筆記 8 - 干貨小結：背景、技術、特征、架構、方法論和 Manifest

縮寫