本系列學習筆記基於 AUTOSAR Adaptive Platform 官方文件 R20-11 版本 AUTOSAR_EXP_PlatformDesign.pdf。作者：Zijian/TENG
原文地址（獲取最新更新）：https://www.cnblogs.com/tengzijian/p/15135074.html
縮寫
- DM：Diagnostics Management
- UDS：Unified Diagnostic Services
- DoIP：Diagnostic communication over Internet Protocol
- ISO：International Organization for Standardization
- AP：AUTOSAR Adaptive Platform
- CP：AUTOSAR Classic Platform
- FC：Functional Cluster
- DEXT：Diagnostic Extract Template
- SWCL：Software Clusters
- AA：Adaptive Application
- UCM：Update and Configuration Management
- DCM：Diagnostic Communication Mannger
- DEM：Diagnostic Event Mannger
- DTC：Diagnostics Trouble Code
9 診斷
9.1 概覽
診斷管理 DM 實現了 ISO 14229-5（UDSonIP）。ISO 14229-5 基於 14229-1（UDS）和 ISO 13400-2（DoIP）。DM 是 AP Foundation 層上的 Functional Cluster（FC）。DM 的配置基於傳統 CP 的 AUTOSAR Diagnostic Extract Template（DEXT）。DM 支援 DoIP 作為傳輸層協議。DoIP 是一個車輛發現協議，用於和診斷基礎設施（診斷儀、工廠/售後測試儀）的 off-board 通訊。車載或遠端診斷一般會使用其他傳輸層協議，為此 AP 提供了擴充套件自定義傳輸層的 API。UDS 廣泛用於車輛的生產和售後維修。
9.2 軟體簇
The atomic updateable/extendable parts are managed by SoftwareClusters(SWCL)
SoftwareClusters（SWCL）管理原子可升級/可擴充套件部分。SWCL 包含與部署/更新功能/應用相關的所有部分。DM 支援為每個安裝的 SWCL 分配獨立的診斷地址。SWCL 也和 UCM 的軟體包耦合，所以 SWCL 可以被更新或者新安裝的一臺機器上。
9.3 診斷通訊子簇（DCM）
診斷通訊子簇實現了診斷服務（好比 CP 中的 DCM）。目前只支援有限的診斷服務，後續的 Release 將擴充套件支援更多的 UDS 服務。除了 ISO 14229-1 中的偽並行客戶端支援，DM 還進行了擴充套件，可以在預設會話下支援客戶端的全並行處理。滿足了現代汽車架構的需求：
- 多診斷客戶端/測試儀的資料採集
- 後臺訪問
- 傳統維修車間和產線使用場景
9.4 自適應應用診斷
DM 作為診斷服務端，分發診斷請求（比如 Routine Control 和 DID 服務）到 AA 所對映的 Providing Port。AA 需要提供專門的 DiagnosticPortInterface。
9.5 專用/通用介面
DiagnosticPortInterface 有不同的抽象層級：
- RoutineControl 訊息
- 專用介面：API 宣告包含所有請求和響應訊息引數和原始資料型別。DM 負責序列化。每個 RoutineControl 訊息有自己的 API。
- 通用介面：請求/響應訊息的 API 宣告只包含一個位元組陣列（Byte-Vector）引數，應用負責序列化。多個 RoutineControl 訊息共用同一個 API。
- DataIdentifier 訊息
- 專用介面：API 宣告包含所有請求（用於寫）和響應（用於讀）的訊息引數和原始資料型別。DM 負責序列化。
- 通用介面：請求/響應訊息的 API 宣告只包含一個位元組陣列（Byte-Vector）引數，應用負責序列化。
- 獨立 DataElement：每個請求/響應訊息引數有自己的介面。這是最高階別的抽象，任何請求/響應訊息格式的改變都不會影響 API。不僅如此，一個診斷訊息的引數可能來自/分發到不同的程式。
9.6 診斷會話
DM 要求支援偽並行，診斷會話要能反應不同的診斷客戶端和服務端的會話。診斷服務端是通過 UDS 請求中的 Target Address 來確定，且在 AP 中執行時動態分配。
9.7 事件儲存子簇（DEM）
事件儲存子簇負責 DTC（Diagnostics Trouble Code）的管理（好比 CP 中的 DEM）。Active DTC 表示一個檢測到的問題（對產線和維修站很重要）。DM 管理 DTC 的儲存、配置的 SnapshotRecords（當發生 DTC 時的一組環境資料）和/或 ExtendedDataRecords（屬於 DTC 的統計資料，如重複發生次數）。
檢測邏輯叫做 Diagnostic Monitor。Monitor 向 DM 的 DiagnosticEvent 報告最近的測試結果。UDS DTC 狀態源自一個或多個 DiagnosticEvent。DTC 可以儲存在主儲存（通過 $19 02/04/06 訪問）或可配置的使用者儲存（通過 $19 17/18/19 訪問）。
DM 支援基於計數器或者基於時間的消抖。此外，DM 提供有關內部轉換的通知：
- DTC 狀態更改
- 監視 DiagnosticEvent 重新初始化的需要
- Snapshot 或 ExtendedDataRecord 是否更改
如果 DTC 在配置的操作迴圈數內都處於非 Active 狀態，則 DTC 將從 DTC 儲存中擦除。DM 支援對啟用和儲存條件的全域性處理。啟用條件可用於在特殊條件下控制 DTC 的更新，例如在欠壓條件下禁用所有與網路相關的 DTC。