? ? ??

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

Part1Diagnostic in Adaptive AutoSAR概述

Adaptive AutoSAR將逐漸成為車輛高性能計(jì)算機(jī) (HPC) 的基礎(chǔ)，因?yàn)樗闪艘韵鹿δ埽?/p>

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

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

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

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

• 首先根據(jù)車輛識(shí)別號(hào) (VIN) 選擇要診斷的車輛
• 然后通過(guò)其診斷地址與各個(gè)ECU單元建立通信

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

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

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

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

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

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

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

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

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

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

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

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

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

如圖所示，E/E 開(kāi)發(fā)過(guò)程從車輛要滿足的Product需求開(kāi)始分析，及規(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è)計(jì)，并定義通信矩陣關(guān)系（“CAN 矩陣”）；

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

• 然后通過(guò)導(dǎo)出的 ODX 和 DEXT 文件進(jìn)行診斷開(kāi)發(fā)（Arxml）和診斷的測(cè)試驗(yàn)證（Diagnostic Ecu-Validation tool可以基于自動(dòng)生成測(cè)試序列以驗(yàn)證控制單元的診斷行為是否正確）

Part3診斷描述文件

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

ODX（Open Diagnostic Data Exchange）文件是一種開(kāi)放式的標(biāo)準(zhǔn)化診斷數(shù)據(jù)格式，用于整車生命周期中診斷數(shù)據(jù)的交換。PDX為所有ODX文件壓縮文件的格式。ODX是由ASAM制定的用來(lái)描述診斷規(guī)范的數(shù)據(jù)格式（MCD-2 D/ISO 22901-1），目前ODX診斷標(biāo)準(zhǔn)已在各大OEM全面施展開(kāi)來(lái)。但是后來(lái)DEXT開(kāi)始進(jìn)入市場(chǎng)，已經(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不僅描述通過(guò)各自協(xié)議傳輸?shù)臄?shù)據(jù)，還包括ECU應(yīng)用層軟件中的初始數(shù)據(jù)（數(shù)據(jù)的來(lái)源）。當(dāng)上述兩種數(shù)據(jù)的描述完整正確時(shí)，即可通過(guò)DEXT配置AUTOSAR診斷相關(guān)BSW。AUTOSAR標(biāo)準(zhǔn)沒(méi)有定義診斷協(xié)議、診斷服務(wù)和數(shù)據(jù)，而是直接使用了UDS和OBD-II的定義

2用例分析

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

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

• OEM或diagnostic requester；

• Application Developer或Application Developer；

• ECU-Supplier或integrator。

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

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

圖4 the ECU Development work-flow

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

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

3DEXT的應(yīng)用

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

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

4VisualODX 3.0版本

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

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

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

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

Part4AutoSAR 診斷管理 DM

1概覽

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

2軟件簇

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

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

3診斷通信子簇（DCM）

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

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

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

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

5專用/通用接口

DiagnosticPortInterface 有不同的抽象層級(jí)：

• RoutineControl 消息

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

• 專用接口：API 聲明包含所有請(qǐng)求（用于寫）和響應(yīng)（用于讀）的消息參數(shù)和原始數(shù)據(jù)類型。DM 負(fù)責(zé)序列化。

• 通用接口：請(qǐng)求/響應(yīng)消息的 API 聲明只包含一個(gè)字節(jié)數(shù)組（Byte-Vector）參數(shù)，應(yīng)用負(fù)責(zé)序列化。

• 獨(dú)立 DataElement：每個(gè)請(qǐng)求/響應(yīng)消息參數(shù)有自己的接口。這是最高級(jí)別的抽象，任何請(qǐng)求/響應(yīng)消息格式的改變都不會(huì)影響 API。不僅如此，一個(gè)診斷消息的參數(shù)可能來(lái)自/分發(fā)到不同的進(jìn)程。

6診斷會(huì)話

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

7事件存儲(chǔ)子簇（DEM）

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

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

DM 支持基于計(jì)數(shù)器或者基于時(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 存儲(chǔ)中擦除。DM 支持對(duì)啟用和存儲(chǔ)條件的全局處理。啟用條件可用于在特殊條件下控制 DTC 的更新，例如在欠壓條件下禁用所有與網(wǎng)絡(luò)相關(guān)的 DTC。

8術(shù)語(yǔ)縮寫

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