Diagnostic in Adaptive AutoSAR

時間：2021-10-22 15:29:20

關(guān)鍵字： SAR Diagnostic

手機(jī)看文章

掃描二維碼
隨時隨地手機(jī)看文章

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

? ? ??

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

Part1Diagnostic in Adaptive AutoSAR概述

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

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

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

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

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

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

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

圖 1 兩個軟件集群的自適應(yīng)ECU及外部診斷儀

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

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

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

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

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

圖 2 帶有自適應(yīng) Autosar 的車輛的擴(kuò)展診斷功能

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

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

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

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

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

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

將需求管理系統(tǒng)的規(guī)范數(shù)據(jù)(Spec)用Doors進(jìn)行管理；
然后把需求數(shù)據(jù)導(dǎo)入到黃色所示的Vehicle Editor中，進(jìn)行系統(tǒng)的架構(gòu)設(shè)計，并定義通信矩陣關(guān)系（“CAN 矩陣”）；
通過一個公共數(shù)據(jù)庫，Vehicle Editor導(dǎo)出特定的格式的診斷文件DEXT或ODX（參見診斷描述文件的區(qū)別一章）；如果后續(xù)需求有變化，只在公共數(shù)據(jù)庫中進(jìn)行更改（記住只在一個地方創(chuàng)建和管理定義很有必要），只需把原來的數(shù)據(jù)庫重新導(dǎo)入后進(jìn)行特定的修改后，導(dǎo)出回相應(yīng)的其他格式，這確保了 ODX 和 DEXT 數(shù)據(jù)的一致性
然后通過導(dǎo)出的 ODX 和 DEXT 文件進(jìn)行診斷開發(fā)（Arxml）和診斷的測試驗證（Diagnostic Ecu-Validation tool可以基于自動生成測試序列以驗證控制單元的診斷行為是否正確）

Part3診斷描述文件

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

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

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在標(biāo)準(zhǔn)UDS協(xié)議之外，增加了OBD-II、WWH-OBD、FIM和SAE J1939的相關(guān)擴(kuò)展內(nèi)容。DEXT不僅描述通過各自協(xié)議傳輸?shù)臄?shù)據(jù)，還包括ECU應(yīng)用層軟件中的初始數(shù)據(jù)（數(shù)據(jù)的來源）。當(dāng)上述兩種數(shù)據(jù)的描述完整正確時，即可通過DEXT配置AUTOSAR診斷相關(guān)BSW。AUTOSAR標(biāo)準(zhǔn)沒有定義診斷協(xié)議、診斷服務(wù)和數(shù)據(jù)，而是直接使用了UDS和OBD-II的定義

2用例分析

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

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

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

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

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

圖4 the ECU Development work-flow

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

定義DTCs的值；定義ECU支持的UDS服務(wù)或子服務(wù)；定義Application Developer實現(xiàn)的特定組合所需的事件。

3DEXT的應(yīng)用

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

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

4VisualODX 3.0版本

VisualODX 3.0版本通過EXCEL診斷問卷調(diào)查表擴(kuò)展了DEXT定義所需支持的內(nèi)容，新增了對服務(wù)及DID的Access Permission定義，和對事件（Event）數(shù)據(jù)的支持。

圖5 EXCEL診斷問卷調(diào)查表Service頁定義

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

圖6 VisualODX軟件ODX數(shù)據(jù)導(dǎo)出界面

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

2軟件簇

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

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

3診斷通信子簇（DCM）

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

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

4自適應(yīng)應(yīng)用診斷

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

5專用/通用接口

DiagnosticPortInterface 有不同的抽象層級：

RoutineControl 消息

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

DataIdentifier 消息

專用接口：API 聲明包含所有請求（用于寫）和響應(yīng)（用于讀）的消息參數(shù)和原始數(shù)據(jù)類型。DM 負(fù)責(zé)序列化。
通用接口：請求/響應(yīng)消息的 API 聲明只包含一個字節(jié)數(shù)組（Byte-Vector）參數(shù)，應(yīng)用負(fù)責(zé)序列化。
獨(dú)立 DataElement：每個請求/響應(yīng)消息參數(shù)有自己的接口。這是最高級別的抽象，任何請求/響應(yīng)消息格式的改變都不會影響 API。不僅如此，一個診斷消息的參數(shù)可能來自/分發(fā)到不同的進(jìn)程。

6診斷會話

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

7事件存儲子簇（DEM）

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

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

DM 支持基于計數(shù)器或者基于時間的消抖。此外，DM 提供有關(guān)內(nèi)部轉(zhuǎn)換的通知：

DTC 狀態(tài)更改
監(jiān)視 DiagnosticEvent 重新初始化的需要
Snapshot 或 ExtendedDataRecord 是否更改

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