概述

  • DM模块基于ISO 14229-1(UDS)以及ISO 13400-2(DoIP)实现了ISO 14229-5(UDSonIP)协议
  • DM是AP中foundation层的一个功能组

  • DM的配置是基于CP中的AUTOSAR Diagnostic Extract Template(DEXT)

  • DM支持的传输层协议是DoIP，DoIP是一个车辆发现协议，被设计用来和诊断设备之间进行机外通信

  • 车内或远程诊断，经常使用其他的传输层协议，因此提供了可拓展的自定义传输层的API

  • UDS通常在车辆量产过程中和修理过程中使用

    软件集群

  • 原子层面上可升级、可拓展的部分叫做软件集群（SWCL）

    原子层面上可单独升级，代表着跟我们平时在手机上使用的APP一样，这就是SWCL

  • 在AP上进行诊断，每个SWCL都有自己的诊断地址，对于DoIP来说，就是节点ID

  • SWCL和UCM的软件包的概念是耦合的，所以SWCL可以升级或新增到机器上

    诊断通信子模块

  • 诊断通信子模块类似于CP上的DCM模块，实现诊断服务，当前支持的服务有限，未来会拓展

  • 除了ISO 14229-1中伪并行的客户端处理之外，DM还进行了拓展，支持了对不同客户端默认会话下的全并行处理，由于满足现代汽车的需求，包括多个诊断仪收集数据、从后端访问以及经典的修理店和生产用例

    Adaptive Application中的诊断

    DM作为诊断服务器将传入的诊断请求分发到经过映射的对应AA的P-PORT上，为了实现这个目标，AA需要提供一个专门的DiagnosticPortInterface

特化接口与泛型接口

对于DiagnosticPortInterface有不同的抽象等级可用：

  • 一个例程控制消息可以作为一个：
    • 特化接口

API签名包括了所有的请求、响应消息的参数以及它们的原始类型，DM负责序列化
这个API用于特定的例程控制消息

  • 泛型接口

API签名只包括了请求和响应消息的字节数组，APP负责进行消息序列化
这样，同一个API就可以用于多种例程控制消息

  • 一个DID消息可以作为一个：
    • 特化接口

API签名包括了所有请求（用于写入）和响应（用于读取）参数和它们的原始类型，DM负责序列化

  • 泛型接口

API签名只包括请求和响应的字节数组，APP负责序列化

  • 单独的数据元素

每一个请求和响应消息参数都有自己的接口
这是最高等级的抽象，比如说，任何请求和响应消息结构上的变化，都不会对API造成影响
此外，同一个诊断消息的参数，可以有不同的处理

诊断会话

  • 由于DM需要以上提到的伪并行处理，所以它支持诊断会话来区分客户端和服务端之间的会话

  • 一个诊断服务端由UDS请求的目标地址来识别，并且是在运行时由AP平台动态分配的

    事件存储子模块

  • 事件存储子模块负责诊断故障码(DTC)的管理，类似于CP中的DEM

  • 一个激活的DTC代表了一个车辆上检测到的问题（通常在生产和修理时非常重要）
  • DM管理了DTC的存储、DTC的快照数据（快照数据就是事件发生时的一系列环境数据，比如车速，电压，网络状态等）以及DTC的拓展数据（拓展数据就是DTC的统计数据，比如发生次数）

  • 事件的检测逻辑被称为诊断监测，这个监测逻辑会将最近的测试结果报告给DM中的一个诊断事件，而UDS DTC状态则由一个或多个诊断事件派生而来

    比如说，有一个DTC 代表了车辆网络故障，在APP运行过程中，有两个事件代表这个DTC，Event0-网络丢帧，Event1-网络校验错误 APP会定期监测这两个事件，向DM报告测试结果，假如其中一个事件测试失败，再经过某些debounce策略之后，DTC就会处于确认状态

  • DTC可以分配给基础内存(可以通过UDS服务19 02/04/06来访问)，或者配置为用户内存(可以通过19 17/18/19访问）

  • 支持基于计数或时间的去抖动，除此之外，DM还提供了内部状态转移的通知，比如DTC状态字的改变，快照改变等
  • 支持DTC老化机制（比如以前某个DTC激活过，但很久都没出现了，这个DTC可能就变成未激活状态）
  • DM支持通用的存储和使能条件，使能条件可以用来控制某些条件下的DTC更新，比如说在低电压状态下，禁止激活网络相关的DTC