Adaptive AUTOSAR 學習筆記 5 - 架構 - 物理檢視
本系列學習筆記基於 AUTOSAR Adaptive Platform 官方文件 R20-11 版本 AUTOSAR_EXP_PlatformDesign.pdf
縮寫
AP：AUTOSAR Adaptive Platform
AA：Adaptive Application
ARA：AUTOSAR Runtime for Adaptive Applications
FC：Functional Cluster
CM：Communication Management
RS：Requirement Specification
SWS：Software Specification
3.2 物理檢視
本節內容僅為解釋說明，不能替代正式需求規範，AP 內部仍由實現決定。更多關於 AP 內部架構細節，請參考 EXP_SWArchiteture。
3.2.1 系統、程序和執行緒
AP 作業系統必須提供 POSIX 多程序支援：
- 每個 AA 都是一個獨立的程序，有獨立的邏輯記憶體地址空間和名稱空間
- 注意：一個 AA 可以有多個程序，可以部署在一個 AP 例項或分佈在多個 AP 例項上
- 從模組組織的角度來看，每個程序都是 OS 從可執行檔案例項化出來的
- 多個程序可以由一個可執行檔案例項化
- AA 也可以由多個可執行檔案組成
FC 一般實現為程序：
- 一個 FC 可以實現為單程序或多程序
- AP Service 或 非平臺 Service（由 AA 提供的服務）都實現為程序
以上程序都可以是單執行緒/多執行緒。他們能用的 OS API 根據他們所在的邏輯層而不同：
- ARA 之上的 AA 只能用 PSE51
- 如果一個程序是 FC，能使用所有的 OS 介面
總結：在 OS 看來，AP 和 AA 都是一系列的程序，每個程序包括一個或多個執行緒，這些程序之間沒有區別。儘管 AP 實現可以進行某種劃分。程序之間通過 IPC 或其他系統功能（ara::com）互動。注意：AA 程序之間不能直接 IPC 程序間通訊，只能通過 ARA 通訊。
3.2.2 基於庫或服務的 FC 實現
如圖 3-1 AP 架構邏輯檢視所示，一個 FC 可以是 Foundation 也可以是 Service。兩者通常都是程序。他們如果想要和 AA（也是程序）通訊，需要通過程序間通訊。除此之外，還有兩種方式：
- 基於庫的設計：FC 提供介面庫，連結到 AA，直接呼叫 IPC；
- 基於服務的設計：程序通過 CM 通訊，AA 連結服務代理庫。代理庫呼叫 CM 的介面，處理 AA 和 Server 程序的通訊。注意：AA 是否只和 CM 直接程序間通訊還是混合代理庫和 Server 通訊是由實現決定的。
一般來說，如果 FC 只適用於本地 AP 例項，基於庫的設計更合適，簡單、高效。如果是分散式的場景，用於其他 AP 例項，建議使用基於服務的設計。因為 CM 可以封裝差異，忽略 AA 和 Service 的位置，提供統一的通訊方式。AP Foundation 的 FC 都是基於庫的，AP Service 的 FC 都是基於服務的。正如他們的名字所指代的。
最後要注意，只要滿足 FC 的 RS 和 SWS，FC 的實現可以只有庫，沒有程序，執行在 AA 的上下文。這種情況下，AA 和 FC 的互動就是普通的函式呼叫，而不是上面描述的 IPC。
3.2.3 FC 之間的互動
FC 之間可以按照實現特有的方式互動，因為他們不受限於 ARA 介面。比如 ARA 的 PSE51 介面限制，限制了 IPC。他們可以使用其他 FC 的 ARA public 介面。FC 之間典型的互動模型是使用 FC 的 protected 介面，提供一些特權，以實現特定的 FC 功能。
此外，從 AP R18-03 開始，引入了新的概念 IFC（Inter-Functional-Cluster）介面，描述了 FC 向其他 FC 提供的介面。注意，這不是 ARA 的一部分，也不是 AP 實現的正式規範。只是通過澄清 FC 之間的互動來幫助開發 AP 規範，並且向 AP 規範的使用者提供了更好的架構視角。這些介面在各個 FC 的 SWS 附錄中有介紹。
3.2.4 機器/硬體
AP 把執行它的硬體叫做機器（Machine），背後的原因是想有個統一的平臺，不論底層使用了什麼虛擬化技術。機器可以是真實的物理機器、完全虛擬化的機器、準虛擬化的系統、系統級虛擬化的容器或其他任意虛擬環境。
硬體（一般假定只有單一晶片）之上可以有一個或多個機器，一個機器上只能有一個 AP 例項。只要 AP 的實現支援，也可以多個晶片共同組成一個機器。