當前位置：首頁 > > 糖果Autosar

[導讀]????如有侵權，聯(lián)系刪除；編輯整理：糖果AutosarPart1DiagnosticinAdaptiveAutoSAR概述AdaptiveAutoSAR將逐漸成為車輛高性能計算機(HPC)的基礎，因為它集成了以下功能：對多處理器系統(tǒng)的支持并行處理資源和更新的動態(tài)配置管理面向服務...

? ? ??

如有侵權，聯(lián)系刪除；編輯整理：糖果Autosar

Part1Diagnostic in Adaptive AutoSAR概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

將需求管理系統(tǒng)的規(guī)范數據(Spec)用Doors進行管理；
然后把需求數據導入到黃色所示的Vehicle Editor中，進行系統(tǒng)的架構設計，并定義通信矩陣關系（“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協(xié)議之外，增加了OBD-II、WWH-OBD、FIM和SAE J1939的相關擴展內容。DEXT不僅描述通過各自協(xié)議傳輸的數據，還包括ECU應用層軟件中的初始數據（數據的來源）。當上述兩種數據的描述完整正確時，即可通過DEXT配置AUTOSAR診斷相關BSW。AUTOSAR標準沒有定義診斷協(xié)議、診斷服務和數據，而是直接使用了UDS和OBD-II的定義

2用例分析

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

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

OEM或diagnostic requester；
Application Developer或Application Developer；
ECU-Supplier或integrator。

在用例1中，一些軟件組件由OEM（或OEM的供應商）實現(xiàn)，并且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實現(xiàn)的特定組合所需的事件。

3DEXT的應用

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

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

4VisualODX 3.0版本

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

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

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

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

Part4AutoSAR 診斷管理 DM

1概覽

診斷管理 DM 實現(xiàn)了 ISO 14229-5（UDSonIP）。ISO 14229-5 基于 14229-1（UDS）和 ISO 13400-2（DoIP）。DM 是 AP Foundation 層上的 Functional Cluster（FC）。DM 的配置基于傳統(tǒng) CP 的 AUTOSAR Diagnostic Extract Template（DEXT）。DM 支持 DoIP 作為傳輸層協(xié)議。DoIP 是一個車輛發(fā)現(xiàn)協(xié)議，用于和診斷基礎設施（診斷儀、工廠/售后測試儀）的 off-board 通信。車載或遠程診斷一般會使用其他傳輸層協(xié)議，為此 AP 提供了擴展自定義傳輸層的 API。UDS 廣泛用于車輛的生產和售后維修。

2軟件簇

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

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

3診斷通信子簇（DCM）

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

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

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 的統(tǒng)計數據，如重復發(fā)生次數）。