本系列學習筆記基於 AUTOSAR Adaptive Platform 官方文件 R20-11 版本 AUTOSAR_EXP_PlatformDesign.pdf。作者 Zijian/TENG，原文地址（獲取最新更新）：https://www.cnblogs.com/tengzijian/p/15112262.html
縮寫
- CM：Communication Management
- SOME/IP：Scalable service-Oriented MiddlewarE over IP
- DDS：Data Distribution Service
- IPC：Inter-Process Communication
- PDU：Protocol Data Unit
- SOA：Service Oriented Architecture
- AP：AUTOSAR Adaptive Platform
7 通訊管理
7.1 概述
CM 負責分散式、實時、嵌入式環境下的應用間通訊。CM 從實現中抽象出一套發現、連線通訊物件的機制。這樣應用開發者就能專注於應用軟體本身的業務邏輯。
7.2 面向服務通訊
Service 即提供給應用的、基礎軟體之外的功能。CM 提供了 Service 消費者/提供者的機制，支援機器內和跨機器通訊。
服務由事件Event、方法Methods、欄位Fields的組合構成。通訊各方的通訊路徑可以在設計、啟動或者執行時建立。Service Registry 是 CM 軟體中的一個重要元件，起到中間人的作用。
每個提供服務的應用向 Service Registry 註冊服務。服務的客戶端應用先向 Service Registry 查詢（find）服務，這一過程叫做服務發現（Service Discovery）。
7.3 語言繫結和網路繫結
CM 標準化了：
- 服務如何呈現給應用實現者（上層，語言繫結）
- 服務資料如何在網路中表示（下層，網路繫結）
以上兩點保證了原始碼的可移植性和已編譯的服務在不同平臺實現的相容性。
語言繫結定義了：如何將服務的 methods，events，fields 翻譯成目標語言中可直接訪問的識別符號。效能和型別安全（只要目標語言支援）是首要目標。因此，語言繫結一般實現為以服務介面定義為輸入的程式碼生成器。
型別安全：編譯時驗證型別
網路繫結定義了：服務資料如何序列化以及如何繫結到特定網路。可以實現為基於 CM 的配置（AUTOSAR 元模型介面定義）實現：或通過解釋（生成的）服務 recipe，或直接生成序列化程式碼。
目前 CM 支援 SOME/IP，DDS，IPC 以及 Signal PDU（基於訊號的網路繫結）。
本地 Service Registry 也是網路繫結的一部分。
注意：語言繫結和網路繫結之間的介面應當視為 CM 內部的 private 介面。儘管如此，平臺供應商應當儘量為其軟體定義獨立的介面，以便在平臺內實現除 C++ 之外的語言繫結。
7.4 C++ 語言繫結 Proxies 和 Skeletons 程式碼生成
C++ 語言繫結的上層介面提供了（定義在AUTOSAR 元模型介面描述中的）服務的物件導向對映。生成器是部署工具的一部分，用於為 CM 生成包含各個 Service 的 fields、events 和 methods 的型別安全表示的 C++ 類。
在服務實現側，生成的類叫 Service Provider Skeletons；在客戶端側，叫 Service Requester Proxies。對於服務方法，服務請求代理提供同步（呼叫者阻塞，直到 Server 返回結果）和非同步（被調函式立即返回）呼叫機制。呼叫者可以並行執行其他任務，當服務端返回結果時，通過 Core Type 的 ara::core::future 接收結果。平臺可以配置生成器生成 mockup 類，當服務尚未開發完成時，便於開發客戶端功能，也可用於客戶端的單元測試。
客戶端可以直接使用代理類，而 Service Provider Skeletons 只是抽象基類，服務實現需要繼承自生成的抽象基類，實現相應的功能。
ara::com 介面可以為 proxies 和 skeletons 提供安全相關、受 E2E 保護的通訊。這些介面旨在確保與應用程式的相容性，無論是否開啟 E2E 保護。
7.5 靜態、動態配置
通訊路徑的配置可能發生在設計、啟動或者執行時。因此配置可以是靜態或者動態的：
- 全靜態配置
完全不需要服務發現，服務端知道所有的客戶端，客戶端也知道服務端。 - 客戶應用無需發現
客戶端知道服務端，但服務端不知道客戶端。應用中唯一的動態通訊方式就是事件訂閱。 - 全服務發現
配置時不知道通訊路徑。服務發現 API 允許應用程式碼在執行時選擇服務例項。
7.6 服務合同版本控制
SOA（Service Oriented Architecture）環境下，服務的客戶端和提供端依賴覆蓋服務介面和行為的合同。服務開發過程中，服務的介面和行為會改變。因此，引入服務合同版本控制來區分不同版本的服務。AP 支援設計、部署階段的服務合同版本控制。不僅如此，客戶端的服務發現可配置為向後相容，即如果服務版本向後相容客戶端請求的服務版本，客戶端可以連線到一個不同於其請求版本的服務。
7.7 原始資料流介面
除了面向服務的通訊，CM 還提供了用於處理外部 ECU（如 ADAS 系統中的感測器）原始二進位制資料流的獨立、靜態 API。
- 為客戶端應用實現了：建立到服務端的通訊通道的功能
- 為服務端應用實現了：等待客戶端連線的功能
- 為客戶端和服務端提供了：銷燬通訊通道以及通過通道讀寫原始資料流的功能
原始資料流通道可以由整合配置其部署資訊，包括網路端點資訊、協議等。目前傳輸層使用 TCP/IP 套接字，但今後可能增加其他替代方式。原始資料流介面定義在 ara::com::raw 名稱空間中。