Adaptive AUTOSAR 学习笔记 14 - 车辆诊断
本系列学习笔记基于 AUTOSAR Adaptive Platform 官方文档 R20-11 版本 AUTOSAR_EXP_PlatformDesign.pdf。作者：Zijian/TENG
原文地址（获取最新更新）：https://www.cnblogs.com/tengzijian/p/15135074.html
缩写
- 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
9 诊断
9.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 广泛用于车辆的生产和售后维修。
9.2 软件簇
The atomic updateable/extendable parts are managed by SoftwareClusters(SWCL)
SoftwareClusters（SWCL）管理原子可升级/可扩展部分。SWCL 包含与部署/更新功能/应用相关的所有部分。DM 支持为每个安装的 SWCL 分配独立的诊断地址。SWCL 也和 UCM 的软件包耦合，所以 SWCL 可以被更新或者新安装的一台机器上。
9.3 诊断通信子簇（DCM）
诊断通信子簇实现了诊断服务（好比 CP 中的 DCM）。目前只支持有限的诊断服务，后续的 Release 将扩展支持更多的 UDS 服务。除了 ISO 14229-1 中的伪并行客户端支持，DM 还进行了扩展，可以在默认会话下支持客户端的全并行处理。满足了现代汽车架构的需求：
- 多诊断客户端/测试仪的数据采集
- 后台访问
- 传统维修车间和产线使用场景
9.4 自适应应用诊断
DM 作为诊断服务端，分发诊断请求（比如 Routine Control 和 DID 服务）到 AA 所映射的 Providing Port。AA 需要提供专门的 DiagnosticPortInterface。
9.5 专用/通用接口
DiagnosticPortInterface 有不同的抽象层级：
-
RoutineControl 消息
- 专用接口：API 声明包含所有请求和响应消息参数和原始数据类型。DM 负责序列化。每个 RoutineControl 消息有自己的 API。
- 通用接口：请求/响应消息的 API 声明只包含一个字节数组（Byte-Vector）参数，应用负责序列化。多个 RoutineControl 消息共用同一个 API。
-
DataIdentifier 消息
- 专用接口：API 声明包含所有请求（用于写）和响应（用于读）的消息参数和原始数据类型。DM 负责序列化。
- 通用接口：请求/响应消息的 API 声明只包含一个字节数组（Byte-Vector）参数，应用负责序列化。
- 独立 DataElement：每个请求/响应消息参数有自己的接口。这是最高级别的抽象，任何请求/响应消息格式的改变都不会影响 API。不仅如此，一个诊断消息的参数可能来自/分发到不同的进程。
9.6 诊断会话
DM 要求支持伪并行，诊断会话要能反应不同的诊断客户端和服务端的会话。诊断服务端是通过 UDS 请求中的 Target Address 来确定，且在 AP 中运行时动态分配。
9.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 02/04/06 访问）或可配置的用户存储（通过 $19 17/18/19 访问）。
DM 支持基于计数器或者基于时间的消抖。此外，DM 提供有关内部转换的通知：
- DTC 状态更改
- 监视 DiagnosticEvent 重新初始化的需要
- Snapshot 或 ExtendedDataRecord 是否更改
如果 DTC 在配置的操作循环数内都处于非 Active 状态，则 DTC 将从 DTC 存储中擦除。DM 支持对启用和存储条件的全局处理。启用条件可用于在特殊条件下控制 DTC 的更新，例如在欠压条件下禁用所有与网络相关的 DTC。