3、诊断测试基础：车载诊断协议（UDS、OBD-II、DoIP）、诊断故障码（DTC）、诊断会话与服务的核心概念

在HIL（硬件在环）测试与诊断测试集成应用中，诊断测试基础是连接车辆电子控制单元（ECU）与测试系统的关键桥梁。无论是传统燃油车还是新能源智能网联汽车，诊断协议栈的稳定性、DTC（诊断故障码）的准确性以及诊断会话管理的规范性，直接决定了产线终检、售后维修和远程OTA（空中下载技术）升级的成败。本章将围绕三大核心主题展开：车载诊断协议（UDS、OBD-II、DoIP）、诊断故障码（DTC）的编码与状态机、诊断会话与服务的核心概念。我们将从协议分层、报文结构、服务调用流程、DTC状态位演变等维度，结合HIL测试中的实际工程场景，帮助读者建立从“协议字节”到“测试用例设计”的完整知识链路。

3.1 车载诊断协议分层架构与核心协议解析

3.1.1 核心原理：从物理信号到诊断语义的封装

车载诊断协议并非单一协议，而是遵循OSI七层模型的分层架构。在HIL测试中，我们最常接触的是CAN/CAN-FD总线上的UDS（统一诊断服务）协议，以及以太网环境下的DoIP（基于IP的诊断）协议。物理层决定了信号传输的电气特性，例如CAN总线采用差分电压传输，显性电平对应逻辑0，隐性电平对应逻辑1；而DoIP则基于100BASE-T1或1000BASE-T1车载以太网，使用单对双绞线传输。数据链路层负责报文封装与错误检测，CAN控制器内置CRC校验和位填充机制，确保数据完整性。网络层与传输层在CAN上由ISO-TP（ISO 15765-2）承担，它将超过8字节的UDS消息分段为多个CAN帧，并通过流控帧管理收发节奏；在DoIP中，TCP协议保证了可靠传输，UDP则用于车辆发现和诊断请求的广播。

应用层协议是测试工程师最需要关注的部分。UDS（ISO 14229-1）定义了统一的诊断服务标识符（SID），例如0x10（诊断会话控制）、0x22（按ID读取数据）、0x2E（按ID写入数据）、0x19（读取DTC信息）、0x14（清除DTC）等。OBD-II（ISO 15031）则面向排放相关诊断，其服务ID与UDS不同，例如0x01（请求当前动力总成数据）、0x03（请求排放相关DTC）、0x07（请求待定DTC）。在HIL测试中，我们通常需要同时支持UDS和OBD-II两套协议栈，因为整车厂下线检测（EOL）使用UDS，而环保检测和售后通用诊断仪则使用OBD-II。

3.1.2 判断方法：协议报文解析与测试要点

在HIL测试环境中，判断协议实现是否正确，需要从三个层面进行验证：物理层信号质量、数据链路层报文格式、应用层服务响应。物理层测试使用示波器测量CAN_H和CAN_L的差分电压，显性电平应在1.5V~3.5V之间，隐性电平应在1.5V~2.5V之间；对于CAN-FD，还需验证波特率切换（BRS）位和可变数据速率（如2Mbps）下的信号完整性。数据链路层测试使用CANoe或PCAN等工具捕获总线报文，检查帧ID、DLC（数据长度码）、CRC字段是否正确，以及是否存在错误帧。应用层测试则通过发送诊断请求并解析响应，验证SID、子功能、数据参数是否符合ISO 14229-1规范。

以下是一个典型的UDS诊断请求与响应报文对比表，用于HIL测试中的快速判断：

方向	CAN ID	数据场（Hex）	说明
请求	0x7E0	02 10 01 00 00 00 00 00	02表示后续2字节，SID=0x10，子功能=0x01（默认会话）
响应	0x7E8	06 50 01 00 32 01 F4 00	06表示后续6字节，SID=0x50（响应），P2=0x0032（50ms），P2*=0x01F4（500ms）
请求	0x7E0	03 22 F1 90 00 00 00 00	按ID读取数据，DID=0xF190（电池电压）
响应	0x7E8	05 62 F1 90 0E 10 00 00	0x62为响应SID，数据=0x0E10（3600mV）

在HIL测试中，我们通常使用故障注入单元（FIU）模拟总线短路、断路和干扰，验证ECU在异常物理条件下的诊断响应能力。例如，当CAN_H与CAN_L短路时，ECU应能检测到总线错误并进入Bus-Off状态，同时通过UDS报告内部错误DTC。

3.1.3 案例拆解：DoIP连接建立与路由激活的HIL验证

在某新能源车型的HIL测试项目中，需要验证车载以太网诊断接口的DoIP功能。测试环境包括：HIL机柜中的以太网板卡（支持100BASE-T1）、DUT（被测ECU）以及上位机诊断工具。初始现象是：诊断工具无法发现车辆，车辆发现阶段失败。通过抓取以太网报文，发现UDP广播报文（端口13400）未收到任何响应。分析判断过程如下：首先检查物理层连接，确认HIL板卡与ECU的以太网PHY芯片链路状态为UP；其次检查ECU的DoIP软件配置，发现逻辑地址未正确分配。实际操作步骤：通过诊断工具发送DoIP车辆识别请求（VIN），ECU应返回车辆信息；随后进行路由激活，ECU返回激活确认。结果对比：修复逻辑地址配置后，车辆发现和路由激活均成功，TCP连接建立，UDS请求响应正常。风险与代价：DoIP连接超时可能导致测试用例失败，需在HIL测试中设置合理的超时参数（通常为2秒）。复盘经验：DoIP测试必须验证TCP Keep-Alive机制，防止连接意外断开。

3.1.4 常见误区与总结复盘

3.2 诊断故障码（DTC）的编码规则与状态管理

3.2.1 核心原理：DTC编码结构与状态位机制

诊断故障码（DTC）是ECU内部故障的标准化标识。根据ISO 14229-1和ISO 15031-6，DTC由3个字节组成：高字节（High Byte）、中字节（Middle Byte）和低字节（Low Byte）。高字节的前两位表示故障所属系统，例如“00”表示动力总成（P），“01”表示底盘（C），“10”表示车身（B），“11”表示网络通信（U）。剩余6位和中字节、低字节共同组成具体的故障编号。例如，DTC P0100表示“质量或体积空气流量电路故障”，其编码为0x01 0x00 0x00。在UDS中，DTC以3字节形式存储，而在OBD-II中，DTC以2字节形式传输（高字节和中字节），低字节用于扩展信息。

DTC状态管理是诊断测试的核心难点。每个DTC关联一个状态字节（DTCStatusMask），包含8个状态位：bit0（testFailed）表示当前测试失败；bit1（testFailedThisOperationCycle）表示本次操作循环中测试失败；bit2（pendingDTC）表示待定DTC，即故障尚未确认；bit3（confirmedDTC）表示已确认DTC，故障连续发生多次；bit4（testNotCompletedSinceLastClear）表示自上次清除后测试未完成；bit5（testFailedSinceLastClear）表示自上次清除后测试失败；bit6（testNotCompletedThisOperationCycle）表示本次操作循环中测试未完成；bit7（warningIndicatorRequested）表示请求点亮故障指示灯（MIL）。

3.2.2 判断方法：DTC状态流转与老化计数器

在HIL测试中，验证DTC状态流转需要模拟故障发生、恢复和老化过程。以“传感器信号超范围”故障为例，测试步骤如下：

1. 故障注入：通过HIL的故障注入模块将传感器信号短路到GND，使ECU读取到超出合理范围的值（如电压低于0.5V）。
2. 首次检测：ECU运行诊断监测函数，检测到故障后，将DTC状态位置为testFailed（bit0=1）和pendingDTC（bit2=1）。
3. 确认过程：如果故障在连续两个驾驶循环中均被检测到，则confirmedDTC（bit3）置1，同时pendingDTC清除。
4. 故障恢复：移除故障注入，ECU在后续驾驶循环中检测到信号正常，testFailed位清零，但confirmedDTC仍保持。
5. 老化清除：ECU执行老化计数器（Aging Counter）逻辑，当连续40次（或制造商定义次数）无故障后，confirmedDTC清除。

以下是一个DTC状态位流转的测试用例表：

测试步骤	操作	预期DTC状态位	验证方法
1	注入故障（信号短路）	bit0=1, bit2=1	读取DTC状态，确认testFailed和pendingDTC置位
2	保持故障，完成一个驾驶循环	bit0=1, bit2=1, bit3=1	确认confirmedDTC置位
3	移除故障，完成一个驾驶循环	bit0=0, bit2=0, bit3=1	确认testFailed清除，confirmedDTC保持
4	连续40个无故障驾驶循环	bit3=0	确认confirmedDTC清除

3.2.3 案例拆解：电池管理系统（BMS）绝缘故障DTC的HIL验证

在某纯电动车型的BMS HIL测试中，需要验证绝缘电阻监测功能的DTC逻辑。测试目标：当绝缘电阻低于阈值（如100Ω/V）时，ECU应报出DTC P0AA6（混合动力电池组绝缘故障）。初始现象：在HIL中模拟绝缘电阻从500Ω/V缓慢下降至50Ω/V，但DTC未触发。分析判断过程：首先检查绝缘监测模块的采样周期，发现HIL模拟的电阻变化速率过快，超过了ECU的滤波时间常数；其次检查DTC确认条件，发现需要连续两次监测到故障。实际操作步骤：调整HIL模型，将绝缘电阻变化速率设置为10Ω/V/s，并保持故障状态超过2个监测周期。结果对比：DTC P0AA6正确触发，状态位bit0和bit3置位，同时冻结帧记录了故障发生时的电池电压、温度和SOC。风险与代价：绝缘故障DTC的误报可能导致车辆无法上高压，因此HIL测试必须精确模拟绝缘电阻的渐变过程。复盘经验：DTC触发条件不仅包括阈值判断，还包括时间持续条件和去抖（Debounce）逻辑，HIL测试用例必须覆盖这些边界条件。

3.2.4 常见误区与总结复盘

3.3 诊断会话与服务的核心概念

3.3.1 核心原理：诊断会话模式与安全访问机制

UDS协议定义了多种诊断会话模式，ECU在不同会话下提供不同的服务权限。最常见的会话包括：默认会话（Default Session，0x01）、编程会话（Programming Session，0x02）和扩展会话（Extended Session，0x03）。默认会话是ECU上电后的初始状态，仅允许读取DTC、读取数据等非安全操作；编程会话用于Flash Bootloader下载，允许写入内存和擦除Flash；扩展会话则允许写入参数、执行例程控制等高级操作。会话切换通过服务0x10（DiagnosticSessionControl）实现，ECU在响应中会返回P2（服务器响应时间）和P2*（增强响应时间）参数，用于告知客户端后续请求的超时设置。

安全访问（SecurityAccess，服务0x27）是保护敏感诊断操作的重要机制。ECU通过种子（Seed）和密钥（Key）的挑战-应答方式验证客户端权限。客户端发送请求种子（子功能0x01），ECU返回一个随机种子；客户端使用特定算法计算密钥，并通过发送密钥（子功能0x02）完成验证。在HIL测试中，需要实现安全访问算法，通常由整车厂提供密钥计算库或算法文档。此外，UDS还定义了通信控制（0x28）、测试仪在线（0x3E）、例程控制（0x31）等服务，用于控制ECU的通信行为和执行特定功能。

3.3.2 判断方法：会话切换与服务响应的时序验证

在HIL测试中，验证诊断会话和服务的核心是检查ECU的响应时序和参数。以下是一个典型的会话切换测试流程：

1. 发送会话切换请求：向ECU发送0x10 0x03（切换到扩展会话）。
2. 检查响应：ECU应返回0x50 0x03，并附带P2和P2*值。例如，P2=0x0032（50ms），P2*=0x01F4（500ms）。
3. 验证会话生效：在扩展会话下，尝试执行默认会话中不允许的服务（如写入参数0x2E），确认ECU允许该操作。
4. 检查会话超时：如果客户端在P2*时间内未发送任何请求，ECU应自动回退到默认会话。HIL测试中需验证该超时逻辑。

以下是一个诊断服务响应时间参数的参考表：

服务名称	SID	P2 (默认)	P2* (扩展)	典型应用
DiagnosticSessionControl	0x10	50ms	5000ms	会话切换
ReadDataByIdentifier	0x22	50ms	500ms	读取数据
WriteDataByIdentifier	0x2E	50ms	500ms	写入参数
RoutineControl	0x31	50ms	5000ms	执行例程
ReadDTCInformation	0x19	50ms	500ms	读取DTC

3.3.3 案例拆解：OTA升级中的会话切换与安全访问

在某车型的OTA（空中下载）升级流程中，HIL测试需要验证ECU从默认会话切换到编程会话，并完成安全访问后执行Flash写入。测试环境：HIL机柜模拟整车网络，包含网关、多个ECU和诊断工具。初始现象：OTA升级过程中，ECU在编程会话下无法执行Flash写入，返回错误码0x33（安全访问被拒绝）。分析判断过程：检查安全访问算法，发现HIL测试工具使用的密钥计算逻辑与ECU固件中的算法不匹配；进一步检查发现，ECU要求使用基于AES-128的密钥算法，而测试工具使用的是CRC16算法。实际操作步骤：更新HIL测试工具的安全访问算法库，重新计算密钥；同时增加安全访问失败后的延时重试机制（如等待10秒后重试）。结果对比：安全访问成功后，ECU允许执行0x31例程控制（擦除Flash）和0x2E写入数据，OTA升级流程顺利完成。风险与代价：安全访问失败可能导致ECU锁定，需要等待解锁时间（如30秒），影响测试效率。复盘经验：在HIL测试中，应提前获取ECU的安全访问算法文档，并建立算法库管理机制，避免因算法不匹配导致的测试中断。

3.3.4 常见误区与总结复盘