本系列學習筆記基于 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 實作，
更多關于 Adaptive AUTOSAR 文章
https://www.cnblogs.com/tengzijian/category/1995263.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/296148.html
標籤：其他
上一篇：第九章 集群