本系列學習筆記基於 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
3 架構
3.1 邏輯檢視
3.1.1 ARA
下圖是 AP 架構的邏輯檢視。
- AA 執行在 ARA 之上
- ARA 由 FC 提供的介面組成
- FC 有兩種介面
- AP Foundation（API）：提供 AP 的基礎功能
- AP Service：提供平臺標準服務
- AA 也可以向其他 AA 提供服務（圖中的 Non-PF Service）
AA 不關心 FC 的介面是 Foundation 還是 Service，對 AA 來說都是 C++ 的介面，儘管底層確有不同。注意：ARA 介面之下，包括 ARA 庫（執行在 AA 上下文），可能用到了 ARA 之外的介面，這是由 AP 實現決定。
上圖的一些 FC 不在當前 Release 中，只是為了有個更好的 overall 架構。新的 FC 也可能會在之後的 Release 中加進來。
3.1.2 語言繫結，C++ 標準庫和 POSIX API
API 的語言繫結基於 C++，C++ 標準庫是 ARA 的一部分。系統 API 中，ARA 只包括 POSIX 的 PSE51子集（單程式 profile）的介面。
C++ 標準庫有很多基於 POSIX 的介面，包括多執行緒 API。但是，不要把 C++ 標準庫的執行緒介面和 PSE51 的執行緒介面混為一談。C++ 標準庫並沒有覆蓋所有 PSE51 的功能，比如設定執行緒排程策略。這時就不得不同時使用兩種介面。
3.1.3 應用啟動關閉
應用程式的生命週期是由 EM（Execution Management）管理的。啟動應用程式需要在系統整合或執行時進行配置。所有的 FC 在 EM 看來都是應用程式，都是由相同的方式啟動，除了 EM 自身（由 OS 啟動）。下圖是 AP 上不同的應用程式分類。
注意：什麼時候啟動/停止哪個應用不是 EM 決定的，而是另一個特殊的 FC，SM（State Management）決定的。SM 根據系統設計來控制 EM，切換系統狀態，進而控制著整個系統行為。這裡系統指的是整個 AP 和上面執行的應用程式，不同專案有不同的行為和具體實現。SM 也和其他 FC 互動，協調整個機器的行為。SM 應該只使用 ARA 定義的介面，以保證在不同 AP 實現上的可移植性。
3.1.4 應用程式介面
由於 PSE51 不含 IPC 介面，所以 AA 之間沒有直接的互動。Communication Management（CM）是唯一的途徑。CM 也提供面向服務的通訊，支援同主機或跨主機通訊（這部分差異對應用程式來說是不可知的）。CM 負責路由轉發“請求/回覆”，無論 Service 應用和 Client 應用的部署拓撲是怎樣的。有的 ARA 介面可能觸發 AA 之間的互動，但這不屬於通訊介面，只是 ARA 介面的副作用罷了。
3.1.5 非標介面
AA 和 FC 可以使用非標介面，只要不和標準 AP 功能衝突，並且遵守專案的 safety 和 security 要求即可。除非是純本地的執行時庫，應當儘量少用非標介面，以免影響移植到其他 AP 實現。