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