本文給大家分享一下在 AP AUTOSAR 里面我們怎么樣去做一個設計，整個 AP 的設計思想及原理。AP 比較抽象，如果不是針對一個具體問題來講 AP 的一些設計的話，會比較難以理解，所以本期我們盡量地去闡述在 AP 下面，它有些什么功能，一般我們在 AP 下面去做設計的話，它會涉及到哪些東西，以這個方向帶大家一步步進入，后期帶大家回顧下可能會更有感覺些。首先看下 AP 的一個設計思想，它的中心的點是什么？其實就 AP 來說，它是一種通用的系統性的一個方法論，它描述了在 POSIX 這個系統下面怎么樣去做應用的一個開發。
相信很多人都已經做過類似的開發，其實我們在做應用開發的過程中避不開的討論就是：其實上述問題對應用開發來說，都是要去考量的一些問題。如果只是做自己的開發，相對比較簡單。但是，應用最大的問題就是怎么跟別人去做交互，交互問題在應用開發中是一個比較窄的點，所以就 AP AUTOSAR 而言，它的一個設計思想更多的是一種服務的思想。比如說我們在做自己的一個應用，那這個應用肯定不是一個孤立存在的，你肯定會調用別人的東西。同時如果我們把自己定位成一個服務的話，肯定會開放一些東西給到別人去使用，讓別人去 Call 我們的一些服務，所以 AP AUTOSAR 要解決一個問題就是要做一個Adaptive Application（簡稱 AA）應用。那么在 AP AUTOSAR 中如何來描述我們的 AA 呢，需要從以下幾個方面進行描述：- 描述 AA 的運行環境，如 Machine（Virtue ECU)及CPU Core ID
- 描述 AA 的加載及通信端口，應用如果要存在的話，首先要解決的就是通信的問題。當我們在做通信時，我們需要知道，通信端口是什么、ID 是什么？所以我們需要明確自己的通信方式跟 ID。
- 描述 AA 的 Log Trace 的方式、配置及打印級別，因為我們需要做 Debug
- 描述 CP 及 AP 之間通信的方式、端口及接口定義
- 當我們把 AA 定義為一個服務時，我們需要描述 Service AA 的身份標識，可提供的物理連接端口及其及接口定義。對于接口定義的?"消息通知"?來說，當然也包括我們的"Event ID"以及 Event 所攜帶的 Data Type 等。當我們在描述文件中對我們的服務接口進行詳細描述后，對方獲取我們的接口后，就知道如何來對接了。
- 描述 Proxy AA 的身份標識，及通過何種物理端口與 Service AA 進行連接并完成接口定義的 "消息通知" 及 "方法" 調用。
需要注意的是，上述描述性的東西，其實就是我們建模的東西。輸出產物為 ARXML文件。這個 ARXML 后期會生成 ".json" 文件。我們可以通過創建模型或者修改我們的".json" 文件來完成對我們想要的應用的描述。因為只有有了這些描述，執行管理（EM）才能知道如何來加載我們的應用。在通信（如使用SOME/IP）的時候，別人才能找到我們以及我們才能知道怎么發現別人。總而言之，AP AUTOSAR 的設計思想就是一個方法論，它通過描述一個應用的具體行為，通過中間件的方式，讓其被系統加載起來。以及描述服務消費者和服務提供者之間如何對接的問題。
下面我們看一些更具體一點的，這里涉及到了 Machine Manifest 的定義。
那么 Machine 是什么？我們的應用都是運行一個 Machine 上面的，其實我們現在的 SOC 都是很強大的，可以在我們的一個 SoC 上面去掛多個 Machine，Machine1、Machine2、Machine3。然后我們可以把某些應用運行在 Machine1、Machine2 或者 Machine3 里面，所以 Machine 它是在硬件的基礎上的一個虛擬的概念，它映射的是用于描述 CPU/內存/物理單元的一個硬件資源。無論怎么樣，我們的應用一定是運行在某個 Machine 上，Machine 可能用到了當前的這個 SoC 里面其中某一個 Core，比如說我們有八個 A72 的 Core，把前面兩個 Core 配置成 Machine1，中間的兩個 Core 配置 Machine2，通過這種方式可以讓你的應用把它歸屬到某個具體的一個 Machine 上面，那具體的 Machine 上就綁定了具體它跑在哪個 Core 上面。同樣的話，這種用法的還有一種叫虛擬機的用法。也就是說在我們的 SoC 之上再去掛 Hypervisor，在 Hypervisor 上再掛 Guest OS，在 Guest OS 上面再掛接 Machine。
實際上這就實現了對 Soc 分層次的虛擬的一個用法。對一個應用來說，它一定要把自己掛接在某個 Machine 上的。
那么 Machine 的定義是什么？是用于描述如 CPU/內存/物理連接等硬件資源，包括：ECU的 Resource 描述，如 CPU 可用的 Processor 類型及數量
Machine 定義了所有可用的物理通信 Connector，比如 EthernetConnector ，及其對應通信端口 NetworkEndpoint 的描述（IPAddress or Domain & Port)
ServiceDiscovery Configs 描述通過可用物理通信端口監聽來自 Multicast 地址信息定義的 SOME/IP?Protocol報文
定義 Machine 的狀態機，應用能不能工作都是跟著 Machine 狀態機走的。
配置 AP AUTOSAR 的 OS（當前很多供應商都還沒實現）
對于 AA 來說，需要綁定某個配置好的 Machine，設置 AA 可以工作或禁止工作在哪個或哪些 CPU Processor 上，并指定其使用 Machine 定義的哪個通信Connector。
Application Manifest 用于描述實例化運行在 Machine 之上的可執行的Process：
我們一般從以下幾個方面對應用清單進行描述。
配置 Executable 啟動選項，包括以下內容
- 配置進程所在的功能組（Function Groups）
- 配置進程工作/不工作在哪個或哪幾個 Processor 上
配置 Executable 的 Provided/RequiredPort 及 Port 所綁定的 Service Interface
?
每個 Process 都對應有一個專屬的 Manifest 配置
同一個 Executable 可以被實例化到多個 Process 對應的 Manifest，也就是說，一個 Process 至少要包含一個 Executable，一個 Executable 可以被多個 Process 引用。總的來說，這里面最重要的就是 Executable 啟動選項的配置。
Service Interface（服務接口）是什么？服務接口定義了 Skeleton/Proxy 之間的接口關系，主要包括以下交互方式：
- Notify: 定義消息 event_id 及對應的消息所攜帶的數據結構
- Method Call：定義方法調用供 Proxy 使用，需定義所有輸入參數的數據結構，及返回值的數據結構；Skeleton 在完成 Method Call 調用執行后，Skeleton 會發送執行結果的返回值給 Proxy
- Fire & Forget：定義方法調用供 Proxy 使用，需定義所有輸入參數的數據結構，無返回值；Skeleton 在完成 Method Call 調用執行后，不會 Response 給Proxy
- Field: 為所定義的數據結構可以同時提供 Service Notifier，及 Proxy? Getter/Setter 的 Method Call 功能
Service Interface Deployment 描述了如何部署 Service Interface
我們在做服務設計時，很重要的一步就是如何定義服務接口。
定義和配置服務實例的元模型如下：
服務實例相關的設計主要包括以下內容。
創建Service Instance：
為 Provided Service 綁定對應的 Service?Interface，配置發送 Offer Service報文的周期，分配 Instance Id
為 Required Service 綁定對應的 Service Interface，配置發送 Find Service報文的周期，分配 Instance Id
Instance ID：Proxy 引用的 Required Instance Id 一定要與對應的 Skeleton提供的 Provided Instance Id 保持一致
Mapping Service InstanceTo Machine：
Mapping Service Instance To Provided/Required Port：
- 為 Provided/Required Service Instance 配置使用哪個 Excutable 定義的Provided/Required Port，即把該 Service Instance 掛在哪個進程，綁定哪個Port 而執行
在我們建模完之后，會生成以下產物。
生成 Skeleton/Proxy 通信框架的基類源代碼，供 Application 開發者繼承基類使用以直接獲取通信能力：
- 生成 Notification/Field/Method?Call 所關聯 datatype 的數據結構，及對應數據結構 payload 的基于 Someip Protocol 的 Serialize/Deserialize 實現
- 生成 Skeleton/Proxy的Event，Method 及 Field 的函數接口及對應的Message Builder 的 Serialize/Deserialize 實現
- Skeleton/Proxy Pattern 生成所有 Provided/Required Service Instance 及SOMEIP/IPC binding 等初始化實現，以及 Offer/Find Serviced 的具體實現
啟動配置 JSON 文件描述，供 Execution Manager 啟動加載應用時使用：
- 進程的調度策略及線程優先級§進程所屬的功能組及其 Machine 狀態機的所有可用狀態
SOME/IP JSON 配置文件，供 SOME IP_Daemon 使用：
- 配置進程所有用到 Services 的屬性：Service Name, Service Id,Service Version，Methods(name/id),Events(name/id)
- 配置了進程的 Provided Service Instance：關聯的 ServiceId，InstanceId，Service Discovery 的參數屬性，映射到 Machine 的參數屬性(NetworkIP Address, Tcp/Udp PortNumber)
- 配置了進 程的 Required Service Instance：關聯的 ServiceId，InstanceId，Service Discovery 的參數屬性，映射到 Machine 的參數屬性(NetworkIP Address, Tcp/Udp PortNumber)
模型生成產物如何被 Middleware?Platform 模塊使用
下圖就是上述模型生成的最主要幾個產物，這些產物會被如何使用我們會在之后的內容中進行分享。
下圖為 AP AUTOSAR 的核心組件，也叫功能集群，簡稱 FC。
上圖中，Execution Manager、Communication Middleware 是這些組件里最核心的組件，IAM是做權限管控的，Diagnostic Manager是做診斷，Network Manager 是做網絡管理，Update Manager 是做升級，Log Manager 是做Log的一些管理，Health Manager 是做健康狀態監控的。
下面對上述核心組件的功能進行一個簡單的描述。
Execution Manager：負責對進程的生命周期進行管理
搜尋指定路徑下所有可用的 Executables 并加入進程列表中，啟動階段按進程依賴順序加載所有配置在默認功能組的進程
當發生功能組狀態切換時，終止未定義在新功能組的進程，并按照進程加載依賴順序重新加載新功能組的所有進程
當功能組內的狀態發生遷移時，驅動所有被加載的進程往相應的狀態遷移
IAM：為應用訪問及控制Autosar資源提供身份鑒權
Platform Health Manager：管理被監控運行實體的健康狀態
- 當檢測到異常狀態時，按照定義執行 RecoveryAction
- 管理各個被監控進程報告的健康狀況，并報告 PHM 的監控及狀態切換結果給到用戶 Application，以便用戶執行最終如 Watchdog 等自定義的決策
Log Manager：提供Log前臺打印API及后臺Log存儲服務
Communication Manager：提供SOME IP Protocol的通信功能支持以 SOME IP/IPC binding 模式為 Offer Service 及 Find Service 提供發送及接收 Service Discovery Message 的能力
管理著所有 Provided Services及Required Services，并為每個 Service Interface 定義的 Event/Method/Field建立映射列表
作為所有基于 SOME IP Protocol Message(Communication & Service Discovery)的 Broker，為 sender 和 receiver 提供 router 服務
Diagnostics Manager：提供診斷服務處理及內存地址管理功能UCM：負責對AdaptiveApplication的安裝、更新和刪除
