2. 诊断通信基础与MICROSAR实现
在整车电子电气架构中，诊断通信是ECU与诊断仪之间交换故障信息、执行例程、刷写软件的基础通道。理解UDS协议、传输层（DoIP/CAN TP）以及MICROSAR中Dcm与Dem模块的职责与交互，是完成诊断系统集成的前提。本节从协议栈分层出发，逐层说明数据如何从诊断仪的请求变成ECU内部的诊断服务调用，以及故障事件如何被记录和上报。
2.1 诊断协议栈的分层结构
诊断通信并非单一协议，而是一条自上而下的协议栈。以CAN总线为例，从应用层到物理层依次为：UDS（ISO 14229-1）定义诊断服务与数据格式；CAN TP（ISO 15765-2）负责将超过8字节的诊断报文分段传输；CAN数据链路层与物理层负责帧的收发。若走以太网，则传输层由DoIP（ISO 13400）替代CAN TP，底层为TCP/UDP与以太网。
这种分层的意义在于：UDS只关心“请求什么服务、返回什么结果”，不关心报文如何被拆包和重组；传输层只关心“如何把长报文可靠地送达对端”，不关心报文内容。MICROSAR正是按这一分层实现各模块，并通过标准化接口将它们串联起来。
2.2 UDS协议：诊断服务的语义层
UDS（Unified Diagnostic Services）是诊断仪与ECU之间的“语言”。它规定了服务标识符（SID）、请求参数、肯定响应（SID+0x40）和否定响应（0x7F + SID + NRC）的格式。实际集成中最常用的服务包括：
- 0x10 会话控制：切换默认会话、编程会话、扩展会话。不同会话下可用的服务集合不同，例如编程会话才允许0x34/0x36/0x37刷写序列。
- 0x22 按标识符读数据：读取DID对应的实时数据，如电压、温度、软件版本。
- 0x2E 按标识符写数据：写入配置参数，通常需要先通过0x27安全访问解锁。
- 0x19 读取DTC信息：读取故障码及其状态字节、冻结帧。
- 0x27 安全访问：通过种子-密钥机制防止未授权操作。
- 0x31 例程控制：启动/停止/请求例程结果，用于自检、标定、执行器测试。
否定响应码（NRC）是调试时的重要线索。例如0x13表示请求长度或格式错误，0x22表示条件不满足（如会话不对），0x31表示请求超出范围，0x33表示安全访问被拒绝，0x78表示响应挂起（ECU正在处理，稍后返回最终响应）。集成阶段若发现诊断仪收到0x7F，应首先根据NRC定位是会话、安全、长度还是条件问题。
2.3 传输层：DoIP与CAN TP的差异
UDS报文长度往往超过CAN单帧的8字节，因此需要传输层完成分段与重组。CAN TP（ISO 15765-2）定义了四种帧类型：单帧（SF）、首帧（FF）、连续帧（CF）和流控帧（FC）。发送方先发FF声明总长度，接收方回FC指示可以继续发送的块大小（BS）和最小间隔时间（STmin），发送方再按序发送CF。若某帧丢失，接收方通过FC的流控状态要求重发或等待。
DoIP（ISO 13400）则面向以太网，使用TCP承载诊断报文、UDP承载车辆发现与状态查询。DoIP报文头包含协议版本、载荷类型、载荷长度和源/目标地址。相比CAN TP，DoIP天然支持更大的报文和更高的带宽，适合刷写和大量数据读取。集成时需注意：DoIP需要正确的逻辑地址（如0x0E00为诊断仪，ECU地址由诊断规范分配），且TCP连接建立后需通过路由激活（Routing Activation）才能开始诊断。
2.4 Dcm与Dem的职责与交互
在MICROSAR中，Dcm（Diagnostic Communication Manager）是诊断服务的入口。它接收来自传输层的UDS请求，解析SID和参数，检查会话状态、安全等级、服务是否支持，然后分发到对应的服务处理函数。Dcm还负责响应组装、响应挂起（0x78）管理、协议超时监控（P2/P2*）以及多诊断连接的处理。
Dem（Diagnostic Event Manager）则负责故障事件的管理。应用软件通过Dem_SetEventStatus()上报事件状态（如预失败、已失败、已通过），Dem根据配置的去抖策略（计数器去抖或时间去抖）判断事件是否确认。确认后，Dem更新DTC状态字节（如testFailed、confirmedDTC、pendingDTC），并记录冻结帧（FreezeFrame）和扩展数据（ExtendedData）。当诊断仪发送0x19服务时，Dcm调用Dem的接口读取DTC信息，再封装成UDS响应返回。
两者的交互可以概括为：Dcm是“对外接口”，Dem是“对内仓库”。Dcm不直接判断故障，只负责把诊断仪的请求翻译成对Dem的查询或操作；Dem不关心诊断仪，只负责按AUTOSAR规范维护事件和DTC状态。集成时常见的配置项包括：Dcm的会话与安全等级映射、服务表、DID表；Dem的事件ID、去抖参数、DTC号、冻结帧数据元素、老化与自愈策略。
2.5 一次典型诊断请求的数据流
以诊断仪读取DTC为例：诊断仪发送19 02 FF（读取所有已确认DTC）。该请求经DoIP或CAN TP传输到ECU，Dcm解析后确认当前会话允许0x19，调用Dem接口获取DTC列表。Dem返回DTC号、状态字节和可用性掩码，Dcm按UDS格式组装肯定响应59 02 ...，再经传输层分段发回诊断仪。若当前会话不允许，Dcm直接返回7F 19 22（条件不满足），不会触达Dem。
理解这条数据流后，集成中的问题定位就有了清晰路径：先看传输层是否连通（DoIP路由激活、CAN TP流控），再看Dcm是否接受服务（会话、安全、长度），最后看Dem是否返回了正确数据（事件配置、DTC映射）。每一层都有对应的日志和调试手段，逐层排查比盲目修改配置更高效。