1. 程式人生 > 其它 >Adaptive AUTOSAR 學習筆記 4 - 架構

Adaptive AUTOSAR 學習筆記 4 - 架構

本系列學習筆記基於 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 介面之下,包括執行在 AA 上下文中的 ARA 庫,可能用 ARA 之外的介面去實現 AP,這是由 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