如有侵权，联系删除；编辑整理：糖果Autosar

Part1Diagnostic in Adaptive AutoSAR概述

Adaptive AutoSAR将逐渐成为车辆高性能计算机 (HPC) 的基础，因为它集成了以下功能：

• 对多处理器系统的支持
• 并行处理
• 资源和更新的动态配置管理
• 面向服务的通信 (SOC)

高性能计算机要求OnBoard 和 OffBoard 诊断必须能适应车辆及其环境中逐渐增加的软件复杂性，其支持的传输层是DoIP。

为了能实现和 Adaptive AutoSAR的交互， A D-PDU API will have an additional protocol module for Diagnostics over IP （车载或远程诊断通常使用其他传输协议，因此提供了使用自定义传输层扩展平台的API，见下图） ；此外，UDS 和 ISO 规范也将被扩展以包含一些新功能「including：ISO 14229-1（UDS）；ISO 13400-2（DoIP）；ISO 14229-5（UDSonIP）」。

DoIP是一种车辆发现协议，诊断的流程如下：

• 首先根据车辆识别号 (VIN) 选择要诊断的车辆
• 然后通过其诊断地址与各个ECU单元建立通信

注意：每个自适应ECU可以同时拥有多个诊断地址（Diagositic Address），每个软件集群 (SWC) 有一个诊断地址以及相关联的诊断管理器。自适应ECU通常会有 5 到 10 个软件集群。

图 1 两个软件集群的自适应ECU及外部诊断仪

如图所示， ECAS 「ECAS （Electronically Controlled Air Suspension ）意为车辆空气悬挂的电子控制系统」包含两个（诊断）应用程序。

• 第一个是降低车辆以方便乘客上车（即ECAS.KNEELING）
• 第二个是倾斜功能，以防止巴士翻车

这两个应用程序不必同时处于活动状态。它们可以在ECAS ECU运行期间根据需要来动态启动和停止。根据车型配置的版本高低，应用程序也可以有需要的进行裁剪（根据软件配置永久打开或关闭特定功能）。例如，在上面的例子中，并线辅助（ADAS.LCA）功能是一种收费功能，默认情况下关闭该车辆功能，通过额外的付费来定制和激活该功能。

综上所属，具有诊断功能的应用程序可能不是同时可用的，甚至某些功能可能在车辆中永久被停用。因此，测试人员必须熟悉并能够使用 VIN「Vehicle Identification Number」 管理相关车辆数据。（不能假设ECU诊断管理器中的所有 DTC 信息都是最新的或可用的）

两个软件集群，每个都有自己的诊断地址，也需要两个 ODX文件（参见诊断描述文件的区别一章）来管理诊断数据。当有诊断请求时，Autosar 诊断协议栈将基于诊断请求PDU的地址来分发给相应软件集群的诊断管理器。

图 2 带有自适应 Autosar 的车辆的扩展诊断功能

目前，Classic Autosar 诊断协议栈循环检查Ecu特定的硬件模块（如电压，电流）是否有错误，发现的任何错误都存储在诊断管理中，并执行特定的错误reaction「通过FMEA（即失效模式和影响分析 ）进行分析所采取的错误应对（reaction），通常是通过备份设计来保障正常功能的执行；例如飞机姿态传感器有四个，其中一个主传感器出现故障时，切换到组件中的其他三个备份传感器」。

某些子系统故障将不可避免地对其所集成的系统产生影响。为了确保正确考虑这些故障的影响，Autosar 配备了事件概念，可用于通知其他应用程序已发生的模式更改。例如，某个姿态传感器故障时，受影响的飞机平衡功能模块也将在收到相应的故障事件（组件系统级别）。

车载诊断测试仪通过 DoIP 收集错误事件，然后决定如何处理错误故障（当然诊断DoIP也可用于获取车辆模块即乘客行为的数据，用于提升下一代产品更加人性化的服务）。在此过程中，OnBoard Tester不仅可以访问原始UDS诊断信息，而且作为自适应Autosar应用程序，它还可以通过ARA::COM接口主动访问其他应用程序的其他接口进行深入分析。

Part2诊断开发的流程

图3 诊断与控制单元软件联合开发流程

如图所示，E/E 开发过程从车辆要满足的Product需求开始分析，及规划的Product变体（Product Variablity）。随着数据的复杂性及规模庞大性，现有的方案如下：

• 将需求管理系统的规范数据(Spec)用Doors进行管理；

• 然后把需求数据导入到黄色所示的Vehicle Editor中，进行系统的架构设计，并定义通信矩阵关系（“CAN 矩阵”）；

• 通过一个公共数据库，Vehicle Editor导出特定的格式的诊断文件DEXT或ODX（参见诊断描述文件的区别一章）；如果后续需求有变化，只在公共数据库中进行更改（记住只在一个地方创建和管理定义很有必要），只需把原来的数据库重新导入后进行特定的修改后，导出回相应的其他格式，这确保了 ODX 和 DEXT 数据的一致性

• 然后通过导出的 ODX 和 DEXT 文件进行诊断开发（Arxml）和诊断的测试验证（Diagnostic Ecu-Validation tool可以基于自动生成测试序列以验证控制单元的诊断行为是否正确）

Part3诊断描述文件

1ODX与DEXT诊断描述文件的区别

ODX（Open Diagnostic Data Exchange）文件是一种开放式的标准化诊断数据格式，用于整车生命周期中诊断数据的交换。PDX为所有ODX文件压缩文件的格式。ODX是由ASAM制定的用来描述诊断规范的数据格式（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最初发布在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执行。

在用例2中，OEM通过Diagnostic Extract提供诊断需求，多个Application Developer提供与其实施相关的信息，合并完全由ECU-Supplier执行。此外，用例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诊断模块的需求，主要应用于开发阶段的代码设计，支持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 是一个车辆发现协议，用于和诊断基础设施（诊断仪、工厂/售后测试仪）的 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）。目前只支持有限的诊断服务，后续的 Release 将扩展支持更多的 UDS 服务。除了 ISO 14229-1 中的伪并行客户端支持，DM 还进行了扩展，可以在默认会话下支持客户端的全并行处理。满足了现代汽车架构的需求：

• 多诊断客户端/测试仪的数据采集
• 后台访问
• 传统维修车间和产线使用场景

4自适应应用诊断

DM 作为诊断服务端，分发诊断请求（比如 Routine Control 和 DID 服务）到 AA 所映射的 Providing Port。AA 需要提供专门的 DiagnosticPortInterface。

5专用/通用接口

DiagnosticPortInterface 有不同的抽象层级：

• RoutineControl 消息

• 专用接口：API 声明包含所有请求和响应消息参数和原始数据类型。DM 负责序列化。每个 RoutineControl 消息有自己的 API。
• 通用接口：请求/响应消息的 API 声明只包含一个字节数组（Byte-Vector）参数，应用负责序列化。多个 RoutineControl 消息共用同一个 API。
• DataIdentifier 消息

• 专用接口：API 声明包含所有请求（用于写）和响应（用于读）的消息参数和原始数据类型。DM 负责序列化。

• 通用接口：请求/响应消息的 API 声明只包含一个字节数组（Byte-Vector）参数，应用负责序列化。

• 独立 DataElement：每个请求/响应消息参数有自己的接口。这是最高级别的抽象，任何请求/响应消息格式的改变都不会影响 API。不仅如此，一个诊断消息的参数可能来自/分发到不同的进程。

6诊断会话

DM 要求支持伪并行，诊断会话要能反应不同的诊断客户端和服务端的会话。诊断服务端是通过 UDS 请求中的 Target Address 来确定，且在 AP 中运行时动态分配。

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 17/18/19 访问）。

DM 支持基于计数器或者基于时间的消抖。此外，DM 提供有关内部转换的通知：

• DTC 状态更改

• 监视 DiagnosticEvent 重新初始化的需要

• Snapshot 或 ExtendedDataRecord 是否更改

如果 DTC 在配置的操作循环数内都处于非 Active 状态，则 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