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

Zijian/TENG發表於2021-07-24

官方文件下載方式及介紹情參見 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 提供了：

高效能運算和通訊機制
靈活的軟體配置

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...）等。