? ? ??

如有侵權，聯系刪除；編輯整理：糖果Autosar

Part1Diagnostic in Adaptive AutoSAR概述

Adaptive AutoSAR將逐漸成為車輛高性能計算機 (HPC) 的基礎，因為它集成了以下功能：

• 對多處理器系統的支持
• 并行處理
• 資源和更新的動態(tài)配置管理
• 面向服務的通信 (SOC)

高性能計算機要求OnBoard 和 OffBoard 診斷必須能適應車輛及其環(huán)境中逐漸增加的軟件復雜性，其支持的傳輸層是DoIP。

為了能實現和 Adaptive AutoSAR的交互， A D-PDU API will have an additional protocol module for Diagnostics over IP （車載或遠程診斷通常使用其他傳輸協議，因此提供了使用自定義傳輸層擴展平臺的API，見下圖） ；此外，UDS 和 ISO 規(guī)范也將被擴展以包含一些新功能「including：ISO 14229-1（UDS）；ISO 13400-2（DoIP）；ISO 14229-5（UDSonIP）」。

DoIP是一種車輛發(fā)現協議，診斷的流程如下：

• 首先根據車輛識別號 (VIN) 選擇要診斷的車輛
• 然后通過其診斷地址與各個ECU單元建立通信

注意：每個自適應ECU可以同時擁有多個診斷地址（Diagositic Address），每個軟件集群 (SWC) 有一個診斷地址以及相關聯的診斷管理器。自適應ECU通常會有 5 到 10 個軟件集群。

圖 1 兩個軟件集群的自適應ECU及外部診斷儀

如圖所示， ECAS 「ECAS （Electronically Controlled Air Suspension ）意為車輛空氣懸掛的電子控制系統」包含兩個（診斷）應用程序。

• 第一個是降低車輛以方便乘客上車（即ECAS.KNEELING）
• 第二個是傾斜功能，以防止巴士翻車

這兩個應用程序不必同時處于活動狀態(tài)。它們可以在ECAS ECU運行期間根據需要來動態(tài)啟動和停止。根據車型配置的版本高低，應用程序也可以有需要的進行裁剪（根據軟件配置永久打開或關閉特定功能）。例如，在上面的例子中，并線輔助（ADAS.LCA）功能是一種收費功能，默認情況下關閉該車輛功能，通過額外的付費來定制和激活該功能。

綜上所屬，具有診斷功能的應用程序可能不是同時可用的，甚至某些功能可能在車輛中永久被停用。因此，測試人員必須熟悉并能夠使用 VIN「Vehicle Identification Number」 管理相關車輛數據。（不能假設ECU診斷管理器中的所有 DTC 信息都是最新的或可用的）

兩個軟件集群，每個都有自己的診斷地址，也需要兩個 ODX文件（參見診斷描述文件的區(qū)別一章）來管理診斷數據。當有診斷請求時，Autosar 診斷協議棧將基于診斷請求PDU的地址來分發(fā)給相應軟件集群的診斷管理器。

圖 2 帶有自適應 Autosar 的車輛的擴展診斷功能

目前，Classic Autosar 診斷協議棧循環(huán)檢查Ecu特定的硬件模塊（如電壓，電流）是否有錯誤，發(fā)現的任何錯誤都存儲在診斷管理中，并執(zhí)行特定的錯誤reaction「通過FMEA（即失效模式和影響分析 ）進行分析所采取的錯誤應對（reaction），通常是通過備份設計來保障正常功能的執(zhí)行；例如飛機姿態(tài)傳感器有四個，其中一個主傳感器出現故障時，切換到組件中的其他三個備份傳感器」。

某些子系統故障將不可避免地對其所集成的系統產生影響。為了確保正確考慮這些故障的影響，Autosar 配備了事件概念，可用于通知其他應用程序已發(fā)生的模式更改。例如，某個姿態(tài)傳感器故障時，受影響的飛機平衡功能模塊也將在收到相應的故障事件（組件系統級別）。

車載診斷測試儀通過 DoIP 收集錯誤事件，然后決定如何處理錯誤故障（當然診斷DoIP也可用于獲取車輛模塊即乘客行為的數據，用于提升下一代產品更加人性化的服務）。在此過程中，OnBoard Tester不僅可以訪問原始UDS診斷信息，而且作為自適應Autosar應用程序，它還可以通過ARA::COM接口主動訪問其他應用程序的其他接口進行深入分析。

Part2診斷開發(fā)的流程

圖3 診斷與控制單元軟件聯合開發(fā)流程

如圖所示，E/E 開發(fā)過程從車輛要滿足的Product需求開始分析，及規(guī)劃的Product變體（Product Variablity）。隨著數據的復雜性及規(guī)模龐大性，現有的方案如下：

• 將需求管理系統的規(guī)范數據(Spec)用Doors進行管理；

• 然后把需求數據導入到黃色所示的Vehicle Editor中，進行系統的架構設計，并定義通信矩陣關系（“CAN 矩陣”）；

• 通過一個公共數據庫，Vehicle Editor導出特定的格式的診斷文件DEXT或ODX（參見診斷描述文件的區(qū)別一章）；如果后續(xù)需求有變化，只在公共數據庫中進行更改（記住只在一個地方創(chuàng)建和管理定義很有必要），只需把原來的數據庫重新導入后進行特定的修改后，導出回相應的其他格式，這確保了 ODX 和 DEXT 數據的一致性

• 然后通過導出的 ODX 和 DEXT 文件進行診斷開發(fā)（Arxml）和診斷的測試驗證（Diagnostic Ecu-Validation tool可以基于自動生成測試序列以驗證控制單元的診斷行為是否正確）

Part3診斷描述文件

1ODX與DEXT診斷描述文件的區(qū)別

ODX（Open Diagnostic Data Exchange）文件是一種開放式的標準化診斷數據格式，用于整車生命周期中診斷數據的交換。PDX為所有ODX文件壓縮文件的格式。ODX是由ASAM制定的用來描述診斷規(guī)范的數據格式（MCD-2 D/ISO 22901-1），目前ODX診斷標準已在各大OEM全面施展開來。但是后來DEXT開始進入市場，已經被多家OEM和供應商使用并提供支持。

DEXT（Diagnostic Extract Template）是AUTOSAR定義的診斷提取模板，用于DCM（Diagnostics Communication Manager）、DEM（Diagnostics Event Manager）以及FIM（Function Inhibition Manager）的需求及配置定義。DEXT最初發(fā)布在AUTOSAR 4.2.1中。AUTOSAR 4.3.0在標準UDS協議之外，增加了OBD-II、WWH-OBD、FIM和SAE J1939的相關擴展內容。DEXT不僅描述通過各自協議傳輸的數據，還包括ECU應用層軟件中的初始數據（數據的來源）。當上述兩種數據的描述完整正確時，即可通過DEXT配置AUTOSAR診斷相關BSW。AUTOSAR標準沒有定義診斷協議、診斷服務和數據，而是直接使用了UDS和OBD-II的定義

2用例分析

使用DEXT，不僅可以描述相應協議傳輸的數據，還可以描述ECU應用軟件中數據的來源。當且僅當兩種類型的信息均可用時，才可以完全配置基礎診斷軟件。

AUTOSAR協議中定義了兩種通用用例的診斷的配置過程。此過程涉及以下三方：

• OEM或diagnostic requester；

• Application Developer或Application Developer；

• ECU-Supplier或integrator。

在用例1中，一些軟件組件由OEM（或OEM的供應商）實現，并且Diagnostic Extract數據的首次合并由OEM執(zhí)行。

在用例2中，OEM通過Diagnostic Extract提供診斷需求，多個Application Developer提供與其實施相關的信息，合并完全由ECU-Supplier執(zhí)行。此外，用例1和用例2也可以結合使用。ECU供應商也可以實施軟件的某些部分，包括其相應的Diagnostic Extract。

圖4 the ECU Development work-flow

對OEM而言，OEM或diagnostic requester使用Diagnostic Extract來定義一個或多個ECU診斷接口。它還可能會將一些Internal Behavior定義為ECU-Supplier或Application Developer的需求，例如：

定義DTCs的值；定義ECU支持的UDS服務或子服務；定義Application Developer實現的特定組合所需的事件。

3DEXT的應用

DEXT可以滿足AUTOSAR診斷模塊的需求，主要應用于開發(fā)階段的代碼設計，支持AUTOSAR Classic以及Adaptive平臺。

目前市場上，為了減少AUTOSAR配置的復雜性，會選擇使用ODX或者CDD文件導出DEXT做AUTOSAR實現，雖然CDD(.cdd)、ODX(.odx或*.pdx)以及DEXT(*.arxml)都是描述診斷相關信息的數據庫，但是它們并不能互相替代，側重覆蓋的應用場景也不一樣。如果使用ODX或者CDD做AUTOSAR實現，必然是需要補充ODX/CDD轉DEXT所缺失的數據才能滿足需求。

4VisualODX 3.0版本

VisualODX 3.0版本通過EXCEL診斷問卷調查表擴展了DEXT定義所需支持的內容，新增了對服務及DID的Access Permission定義，和對事件（Event）數據的支持。

圖5 EXCEL診斷問卷調查表Service頁定義

該版本可以直接通過用戶的診斷問卷調查表導出ODX/DEXT文件，不僅可以滿足客戶AUTOSAR架構中診斷模塊軟件實現的DEXT數據，而且能保證數據的同源，方便統一的維護。

圖6 VisualODX軟件ODX數據導出界面

Part4AutoSAR 診斷管理 DM

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 是一個車輛發(fā)現協議，用于和診斷基礎設施（診斷儀、工廠/售后測試儀）的 off-board 通信。車載或遠程診斷一般會使用其他傳輸層協議，為此 AP 提供了擴展自定義傳輸層的 API。UDS 廣泛用于車輛的生產和售后維修。

2軟件簇

The atomic updateable/extendable parts are managed by SoftwareClusters(SWCL)

SoftwareClusters（SWCL）管理原子可升級/可擴展部分。SWCL 包含與部署/更新功能/應用相關的所有部分。DM 支持為每個安裝的 SWCL 分配獨立的診斷地址。SWCL 也和 UCM 的軟件包耦合，所以 SWCL 可以被更新或者新安裝的一臺機器上。

3診斷通信子簇（DCM）

診斷通信子簇實現了診斷服務（好比 CP 中的 DCM）。目前只支持有限的診斷服務，后續(xù)的 Release 將擴展支持更多的 UDS 服務。除了 ISO 14229-1 中的偽并行客戶端支持，DM 還進行了擴展，可以在默認會話下支持客戶端的全并行處理。滿足了現代汽車架構的需求：

• 多診斷客戶端/測試儀的數據采集
• 后臺訪問
• 傳統維修車間和產線使用場景

4自適應應用診斷

DM 作為診斷服務端，分發(fā)診斷請求（比如 Routine Control 和 DID 服務）到 AA 所映射的 Providing Port。AA 需要提供專門的 DiagnosticPortInterface。

5專用/通用接口

DiagnosticPortInterface 有不同的抽象層級：

• RoutineControl 消息

• 專用接口：API 聲明包含所有請求和響應消息參數和原始數據類型。DM 負責序列化。每個 RoutineControl 消息有自己的 API。
• 通用接口：請求/響應消息的 API 聲明只包含一個字節(jié)數組（Byte-Vector）參數，應用負責序列化。多個 RoutineControl 消息共用同一個 API。
• DataIdentifier 消息

• 專用接口：API 聲明包含所有請求（用于寫）和響應（用于讀）的消息參數和原始數據類型。DM 負責序列化。

• 通用接口：請求/響應消息的 API 聲明只包含一個字節(jié)數組（Byte-Vector）參數，應用負責序列化。

• 獨立 DataElement：每個請求/響應消息參數有自己的接口。這是最高級別的抽象，任何請求/響應消息格式的改變都不會影響 API。不僅如此，一個診斷消息的參數可能來自/分發(fā)到不同的進程。

6診斷會話

DM 要求支持偽并行，診斷會話要能反應不同的診斷客戶端和服務端的會話。診斷服務端是通過 UDS 請求中的 Target Address 來確定，且在 AP 中運行時動態(tài)分配。

7事件存儲子簇（DEM）

事件存儲子簇負責 DTC（Diagnostics Trouble Code）的管理（好比 CP 中的 DEM）。Active DTC 表示一個檢測到的問題（對產線和維修站很重要）。DM 管理 DTC 的存儲、配置的 SnapshotRecords（當發(fā)生 DTC 時的一組環(huán)境數據）和/或 ExtendedDataRecords（屬于 DTC 的統計數據，如重復發(fā)生次數）。

檢測邏輯叫做 Diagnostic Monitor。Monitor 向 DM 的 DiagnosticEvent 報告最近的測試結果。UDS DTC 狀態(tài)源自一個或多個 DiagnosticEvent。DTC 可以存儲在主存儲（通過 19 17/18/19 訪問）。

DM 支持基于計數器或者基于時間的消抖。此外，DM 提供有關內部轉換的通知：

• DTC 狀態(tài)更改

• 監(jiān)視 DiagnosticEvent 重新初始化的需要

• Snapshot 或 ExtendedDataRecord 是否更改

如果 DTC 在配置的操作循環(huán)數內都處于非 Active 狀態(tài)，則 DTC 將從 DTC 存儲中擦除。DM 支持對啟用和存儲條件的全局處理。啟用條件可用于在特殊條件下控制 DTC 的更新，例如在欠壓條件下禁用所有與網絡相關的 DTC。

8術語縮寫

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