Diagnostic in Adaptive AutoSAR

Diagnostic 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接口主动访问其他应用程序的其他接口进行深入分析。

诊断开发的流程

图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可以基于自动生成测试序列以验证控制单元的诊断行为是否正确）

诊断描述文件

ODX与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的定义

组件功能介绍
• ara::diag:基于 ISO 14229-1（UDS）、ISO 13400-2（DoIP）

  实现基于 IP 的诊断功能ISO 14229-5(UDSonIP)

♦ 通过诊断服务器，实现DEM诊断事件管理和DCM 诊断通信管理:
DEM 诊断事件管理主要提供诊断事件服务，处理诊断事件，记录操作循环状态，维护 DTC 状态和存储事件数据;
DCM 诊断通信管理主要提供诊断会话管理，诊断请求转发和UDS服务处理
♦ 支持配置多个诊断服务器，每个诊断服务器支持配置不同服务，且支持被多个Tester并行访问
♦ 实现传输协议管理:支持DOIP协议，后续可扩展和兼容其他传输层协议

用例分析

使用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实现的特定组合所需的事件。

DEXT的应用

DEXT可以满足AUTOSAR诊断模块的需求，主要应用于开发阶段的代码设计，支持AUTOSAR Classic以及Adaptive平台。

目前市场上，为了减少AUTOSAR配置的复杂性，会选择使用ODX或者CDD文件导出DEXT做AUTOSAR实现，虽然CDD(.cdd)、ODX(.odx或*.pdx)以及DEXT(*.arxml)都是描述诊断相关信息的数据库，但是它们并不能互相替代，侧重覆盖的应用场景也不一样。

如果使用ODX或者CDD做AUTOSAR实现，必然是需要补充ODX/CDD转DEXT所缺失的数据才能满足需求。

VisualODX 3.0版本

VisualODX 3.0版本通过EXCEL诊断问卷调查表扩展了DEXT定义所需支持的内容，新增了对服务及DID的Access Permission定义，和对事件（Event）数据的支持。

图4 EXCEL诊断问卷调查表Service页定义

该版本可以直接通过用户的诊断问卷调查表导出ODX/DEXT文件，不仅可以满足客户AUTOSAR架构中诊断模块软件实现的DEXT数据，而且能保证数据的同源，方便统一的维护。

图5 VisualODX软件ODX数据导出界面

诊断管理中的术语缩写

• 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

诊断管理DM

概览

诊断管理 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 广泛用于车辆的生产和售后维修。

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

*SoftwareClusters（SWCL）*管理原子可升级/可扩展部分。

SWCL 包含与部署/更新功能/应用相关的所有部分。

DM 支持为每个安装的 SWCL 分配独立的诊断地址。

SWCL 也和 UCM 的软件包耦合，所以 SWCL 可以被更新或者新安装的一台机器上。

诊断通信子簇（DCM）

诊断通信子簇实现了诊断服务（好比 CP 中的 DCM）。目前只支持有限的诊断服务，后续的 Release 将扩展支持更多的 UDS 服务。

除了 ISO 14229-1 中的伪并行客户端支持，DM 还进行了扩展，可以在默认会话下支持客户端的全并行处理。满足了现代汽车架构的需求：

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

自适应应用诊断

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

专用/通用接口

DiagnosticPortInterface 有不同的抽象层级：

• RoutineControl 消息
  • 专用接口：API 声明包含所有请求和响应消息参数和原始数据类型。DM 负责序列化。每个 RoutineControl 消息有自己的 API。
  • 通用接口：请求/响应消息的 API 声明只包含一个字节数组（Byte-Vector）参数，应用负责序列化。多个 RoutineControl 消息共用同一个 API。
• DataIdentifier 消息
  • 专用接口：API 声明包含所有请求（用于写）和响应（用于读）的消息参数和原始数据类型。DM 负责序列化。
  • 通用接口：请求/响应消息的 API 声明只包含一个字节数组（Byte-Vector）参数，应用负责序列化。
  • 独立 DataElement：每个请求/响应消息参数有自己的接口。这是最高级别的抽象，任何请求/响应消息格式的改变都不会影响 API。不仅如此，一个诊断消息的参数可能来自/分发到不同的进程。

adaptive autosar中DCM的主要功能和作用有以下几点¹：

• DCM是Diagnostic Communication Manager的缩写，它是一个基于ISO 14229-1标准的UDS（Unified Diagnostic Services）实现，用于提供诊断服务和通信管理。
• DCM可以通过标准的DoIP（Diagnostic over IP）或者自定义的传输层协议来控制和Client（诊断工具）之间的通信，支持多个Client同时连接到同一个Server（ECU）。
  支持动态诊断配置和更新，以适应不同的ECU模式和需求。
• DCM可以处理Client发送的诊断请求，并根据配置文件中定义的诊断服务和子功能来执行相应的操作，如读取或写入数据、执行测试或例程、控制ECU模式等。
• DCM可以与其他adaptive autosar服务和应用程序交互，如State Manager、Persistence Manager、Log and Trace等，以获取或设置相关的信息和状态。
• DCM可以

源: 与必应的对话， 6/1/2023
(1) Adaptive Platform AUTOSAR. https://www.autosar.org/standards/adaptive-platform/.
(2) Comparison of AUTOSAR Classic and Adaptive Platforms. https://www.mathworks.com/help/autosar/ug/autosar-platform-comparison.html.
(3) Adaptive AUTOSAR-Diagnostic Manager-概述和UDS传输层 - 知乎. https://zhuanlan.zhihu.com/p/259678095.
(4) Standards AUTOSAR. https://www.autosar.org/standards/.

诊断会话

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

根据我的搜索结果，adaptive autosar中DEM的主要功能和作用有以下几点¹：

• DEM是Diagnostic Event Manager的缩写，它是一个用于管理诊断事件的服务，诊断事件是指由应用程序或者平台服务检测到的异常或者错误情况。
• DEM可以接收来自应用程序或者平台服务的诊断事件报告，并根据配置文件中定义的诊断事件属性来处理这些报告，如记录、存储、清除、传输等。
• DEM可以与其他adaptive autosar服务和应用程序交互，如DCM、State Manager、Persistence Manager、Log and Trace等，以提供或获取相关的信息和状态。
• DEM可以支持动态诊断配置和更新，以适应不同的ECU模式和需求。

(1) Adaptive Platform AUTOSAR. https://www.autosar.org/standards/adaptive-platform/.
(2) Standards AUTOSAR. https://www.autosar.org/standards/.
(3) AUTOSAR Adaptive | Vector. https://www.vector.com/de/de/know-how/autosar/autosar-adaptive/.

事件存储子簇（DEM）

事件存储子簇负责 DTC（Diagnostics Trouble Code）的管理（好比 CP 中的 DEM）。Active DTC 表示一个检测到的问题（对产线和维修站很重要）。DM 管理 DTC 的存储、配置的 SnapshotRecords（当发生 DTC 时的一组环境数据）和/或 ExtendedDataRecords（属于 DTC 的统计数据，如重复发生次数）。

检测逻辑叫做 Diagnostic Monitor。Monitor 向 DM 的 DiagnosticEvent 报告最近的测试结果。UDS DTC 状态源自一个或多个 DiagnosticEvent。DTC 可以存储在主存储（通过 访问）或可配置的用户存储（通过1902/04/06访问）或可配置的用户存储（通过19 17/18/19 访问）。

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

• DTC 状态更改
• 监视 DiagnosticEvent 重新初始化的需要
• Snapshot 或 ExtendedDataRecord 是否更改

如果 DTC 在配置的操作循环数内都处于非 Active 状态，则 DTC 将从 DTC 存储中擦除。DM 支持对启用和存储条件的全局处理。启用条件可用于在特殊条件下控制 DTC 的更新，例如在欠压条件下禁用所有与网络相关的 DTC

1. 数据链路层与物理层 根据ISO-13400的要求，DoIP通信在物理层支持100BASE-TX (100 Mbit/s Ethernet) 和10BASE-T (10 Mbit/s Ethernet) 两种制式。
2. 传输层与网络层 DoIP设备的MAC地址也符合IEEE 802.3 的要求。 ISO-13400规定，DoIP通信在传输层上必须同时支持UDP和TCP，并将UDP和TCP的使用场合进行了定义，对所使用的端口号也进行了定义。 ISO-13400规定，DoIP通信在网络层上使用IPv6协议，但是为了后向兼容的原因，也支持IPv4。此外，对于IPv4来说，还要支持地址解析协议（ARP ），对于IPv6来说，还要支持邻居发现协议(NDP) ，这两个协议是用于在只知道IP地址的情况下获取MAC地址的。 ARP格式包

NDP数据包 可参考 https://blog.csdn.net/zhishenluo/article/details/103729512

1. DoIP数据帧格式 3.1 帧格式说明 以太网帧（具体参考网络帧）

• IP段
• TCP段
• UDP段
• DoIP段

3.2 DoIP-协议版本

0x00: reserved

0x01: DoIP ISO/DIS 13400-2:2010

0x02: DoIP ISO 13400-2:2012

0x03…0xFE: reserved by this part of ISO 13400 0xFF: default value for vehicle identifcation request messages

3.3 DoIP-Data Type

【0x0001至0x0004】用于汽车标识上报或请求，只能通过UDP报文来发送这种命令，主要用于在汽车和诊断仪进入网络之后、诊断连接建立之前的车辆发现过程。

【0x0005 和0x0006】标识的Routing activation request 和 response用于在socket建立之后，进行诊断通信的请求。

【0x0007和0x0008】用于Alive check，用于检查当前建立的诊断连接socket是否仍然在使用中，如果不再使用，则关闭socket释放资源。

【0x8001，0x8002，0x8003】，分别代表的含义分别是诊断消息、诊断消息正响应和诊断消息负响应。

3.4 DoIP-Data length

就是标识后面的user data的长度。 此外源地址和目标地址可以参考UDS中定义即可，用户数据即为诊断相关服务数据。

1. 诊断连接 4.1 连接状态

DoIP实体内管理着一个DoIP connection table ，用来记录和维护诊断通信的逻辑连接。上图就是这个表中的一个元素，即一个逻辑连接的状态机。上图中的方框就是连接所处的状态，[Step]是状态之间跳转时发生的事情。

[Step1] 当一个新的套接字建立，逻辑连接的状态就从“listen”跳转到“socket initialized”，同时启动一个定时器， initial inactivity timer。

[Step2] 当DoIP实体接收到tester发来的一个routing activation信息后，逻辑连接的状态就从“socket initialized”跳转到“Registered [Pending for Authentication]” ，此时 initial inactivity timer被停止，启动一个名为general inactivity timer的定时器。

[Step3] 在完成Authentication之后，逻辑连接的状态就从“Registered [Pending for Authentication]”跳转到“Registered [Pending for Confrmation]” 。

[Step4] 在完成Confrmation之后，逻辑连接的状态就从“Registered [Pending for Confrmation]”跳转到“Registered [Routing Active] ” 。

[Step5] 如果initial timer 或general inactivity timer 过期后仍没收到后续请求，或者authentication 和 confrmation 被拒绝了，又或者外部测试设备对alive check 消息没有响应，则逻辑连接进入“Finalize”状态。

[Step6]进入Finalize后，此时TCP套接字将被关闭，并重新回到“listen”状态。

4.2 建立连接和车辆发现

当DoIP实体和外部测试设备都连接到一个网络中时，它们会利用DHCP协议获得一个属于自己的IP地址。在网络中，路由器作为DHCP server，为新加入到该网络中的设备分配IP地址。在获取IP地址之后，有两种车辆发现的方法，如上图所示。一种方法是车辆主动上报自己的信息3次。如果测试设备没有收到车辆主动上报的信息，则会发送一个identification request，如果网络中有车辆的话，车辆对这个请求进行响应，测试设备便发现了被测车辆。

4.3 会话建立

在诊断仪发现车辆之后，会把车辆添加到自己的车辆列表中。当用户选择这个列表中的某辆车，如果连接建立成功，用户就可以对车辆进行诊断了。 接下来用户给汽车发出诊断信息，网关会根据信息接收对象把诊断信息转发给网络中相关的ECU，当得到ECU 的响应之后，网关再把最终的响应发送给诊断仪。当用户选择退出时，用于DoIP通信的这个套接字就被关闭了。

1. 诊断发送 5.1 请求DID F810读取

• byte 0：ISO13400 版本
• byte 1：ISO13400 版本逐比特取反
• byte 2~3：数据类型，0x8001，表明这是一个诊断信息的数据包
• byte 4~7：数据长度，在这个例子中的值是7，表示后面有7个字节的数据
• byte 8~9：源地址
• byte 10~11：目的地址
• byte 12~13：具体的诊断命令，SID是22，表示读取，DID是0xF810 其他诊断服务类似

Diagnostic in Adaptive AutoSAR - 知乎 (zhihu.com)