2. UDS协议基础

UDS（Unified Diagnostic Services，统一诊断服务）是ISO 14229标准定义的一套应用层诊断协议，广泛应用于汽车电子控制单元（ECU）的研发、生产、售后和OTA远程升级环节。在基于CANoe的UDS诊断测试中，理解协议本身是搭建测试工程、编写CAPL脚本、分析诊断报文的前提。本章将围绕ISO 14229标准的核心框架，系统讲解诊断服务的分类逻辑、服务ID（SID）与子功能的编码规则，以及正负响应格式的判定方法，并结合CANoe实际测试场景给出可操作的判断流程与常见误区。

上图展示了UDS协议的核心结构：ISO 14229标准定义了诊断服务的分类、SID与子功能的编码规则，以及正负响应的格式。在CANoe测试中，测试人员需要从这三个维度理解诊断报文的构造与解析逻辑。下面分别展开讲解。

2.1 ISO 14229标准与诊断服务分类

核心原理

ISO 14229（统一诊断服务）是应用层协议，它不关心底层是CAN、CAN FD、LIN还是以太网，只定义诊断数据的语义和交互规则。该标准将诊断服务划分为六大类：诊断管理类（如0x10诊断会话控制、0x11 ECU复位、0x27安全访问）、数据读取类（如0x22按DID读数据、0x23按地址读内存）、数据写入类（如0x2E按DID写数据、0x3E待机握手）、输入输出控制类（如0x2F输入输出控制）、例行程序类（如0x31例行程序控制）、以及上传下载类（如0x34请求下载、0x36传输数据、0x37请求传输退出）。每一类服务对应不同的测试目的和测试方法。

判断方法

在CANoe中，测试人员通过诊断控制台（Diagnostic Console）或CAPL脚本发送诊断请求时，首先需要确认该服务属于哪一分类，因为不同分类的测试策略差异很大。例如，数据读取类服务（0x22）通常用于验证ECU的传感器值、版本信息等，测试重点是DID的合法性、数据格式和更新周期；而安全访问类服务（0x27）则涉及种子与密钥的算法验证，测试重点是安全等级切换和失败计数器的行为。判断服务分类的快速方法是查看SID的高四位：0x1x为诊断管理，0x2x为数据读取/写入，0x3x为输入输出控制，0x3x中的0x31为例行程序，0x34-0x37为传输类。

服务分类	典型SID	测试关注点	CANoe测试方法
诊断管理	0x10, 0x11, 0x27	会话切换、复位类型、安全等级	状态机测试、超时测试
数据读取	0x22, 0x23	DID范围、数据长度、更新频率	轮询测试、边界值测试
数据写入	0x2E, 0x3E	写入条件、掉电保持、握手周期	写入-回读验证、休眠唤醒测试
输入输出控制	0x2F	控制模式、参数范围、恢复机制	实时控制测试、故障注入
例行程序	0x31	程序ID、启动条件、结果反馈	触发-等待-结果验证
上传下载	0x34, 0x36, 0x37	块大小、地址对齐、校验机制	刷写流程测试、中断恢复测试

案例拆解

在某BMS（电池管理系统）项目中，测试人员需要验证ECU是否支持0x22服务读取电池电压。初始现象是：使用CANoe发送0x22 0xF1 0x90请求后，ECU无响应。通过分析发现，该ECU在默认会话（Default Session）下仅支持0x10、0x3E等少数服务，0x22属于扩展会话（Extended Session）才允许的服务。测试人员先发送0x10 0x03切换到扩展会话，再发送0x22请求，ECU正常返回正响应。这个案例说明，服务分类不仅决定测试内容，还决定了测试前置条件——会话状态。

常见误区

2.2 服务ID（SID）与子功能编码

核心原理

SID是诊断请求的第一个字节，取值范围0x00-0xFF，其中0x00-0x3F为ISO 14229定义的标准服务，0x40-0x7F为OEM扩展服务，0x80-0xFF为供应商自定义服务。子功能（Sub-function）是请求的第二个字节，用于区分同一服务下的不同操作模式。子功能字节的最高位（bit 7）是抑制正响应指示位（Suppress PosRsp Indication Bit, SPI），当该位为1时，ECU不发送正响应，只发送负响应（如果出错）。例如，0x10 0x03表示请求切换到扩展会话，0x10 0x83表示请求切换但抑制正响应。

判断方法

在CANoe中，测试人员需要区分SID和子功能的不同作用。SID决定服务类型，子功能决定具体操作。判断子功能是否合法的依据是ECU的诊断规范，通常规范中会列出每个服务支持的子功能列表。测试时，应使用边界值法：测试最小子功能（0x00）、最大子功能（0x7F）、以及带抑制位的子功能（0x80-0xFF）。例如，对于0x31例行程序控制，子功能0x01表示启动例行程序，0x02表示停止例行程序，0x03表示查询例行程序结果，测试时需要逐一验证。

// CANoe CAPL示例：发送带抑制位的诊断请求
byte request[2] = {0x10, 0x83}; // 0x83 = 0x03 | 0x80，抑制正响应
DiagSendRequest(request, 2);
// 预期结果：ECU不发送正响应，若出错则发送0x7F 0x10 NRC

案例拆解

在某OEM的OTA项目中，测试人员需要验证ECU在收到0x31 0x01 0x02 0x03（启动刷写准备程序）后，是否返回正响应。测试中发现，当发送0x31 0x81（带抑制位）时，ECU没有发送任何响应帧。测试人员通过CANoe的Trace窗口确认，ECU确实收到了请求，但按照协议抑制了正响应。此时，测试人员需要额外发送0x31 0x01（不带抑制位）来验证程序执行结果。这个案例说明，抑制位是测试中容易忽略的细节，它会影响测试结果的判定。

常见误区

2.3 正响应与负响应格式

核心原理

正响应（Positive Response）的格式为：第一个字节是SID+0x40，后续字节为服务特定的数据。例如，0x22请求读取DID，正响应为0x62 + DID + 数据。负响应（Negative Response）的格式为：第一个字节固定为0x7F，第二个字节为请求的SID，第三个字节为NRC（Negative Response Code，负响应码）。NRC用于指示ECU拒绝请求的原因，常见的NRC包括0x11（服务不支持）、0x12（子功能不支持）、0x13（请求长度错误）、0x22（条件不满足）、0x31（请求超出范围）、0x33（安全访问被拒绝）等。

判断方法

在CANoe中，测试人员通过诊断控制台或CAPL脚本接收响应帧，判断响应类型的方法如下：

1. 检查响应帧的第一个字节：若为0x7F，则为负响应；否则为正响应。
2. 若为正响应，检查第一个字节是否等于请求SID+0x40，并验证数据长度和内容是否符合预期。
3. 若为负响应，提取NRC码，对照ECU规范确认错误原因。

测试中还需要注意响应超时时间。ISO 14229规定，ECU应在收到请求后50ms内发送响应（P2默认值为50ms），若超过P2时间未响应，测试人员应发送0x3E 0x80（待机握手）保持通信，并等待P2*（扩展超时）时间。

响应类型	格式	示例	测试判定
正响应	SID+0x40 + 数据	请求0x22 0xF1 0x90 → 响应0x62 0xF1 0x90 0x0A 0x1C	数据长度和值符合预期
负响应	0x7F + SID + NRC	请求0x22 0xF1 0x90 → 响应0x7F 0x22 0x31	NRC=0x31表示请求超出范围
无响应	无帧	请求后超过P2时间无响应	检查通信线路、会话状态、服务支持性

案例拆解

在某ADAS（高级驾驶辅助系统）控制器测试中，测试人员发送0x2E 0xF1 0x90（写入标定数据）请求，ECU返回0x7F 0x2E 0x22（条件不满足）。通过分析发现，该ECU要求写入前必须先进入编程会话（0x10 0x02），并且需要完成安全访问（0x27）。测试人员按照规范先发送0x10 0x02切换会话，再发送0x27 0x01请求种子，计算密钥后发送0x27 0x02，最后发送0x2E请求，ECU返回正响应0x6E。这个案例展示了负响应NRC的排查思路：NRC 0x22通常表示前置条件未满足，需要检查会话状态、安全等级、DID写保护等条件。

常见误区