Adaptive AUTOSAR 學習筆記 14 - 車輛診斷

Zijian/TENG 發表於 2021-08-14

本系列學習筆記基於 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。

更多關於 Adaptive AUTOSAR 文章

https://www.cnblogs.com/tengzijian/category/1995263.html