第2章诊断请求与响应机制

2. 诊断请求与响应机制：SID、寻址方式与子功能参数

各位工程师朋友，咱们今天聊聊诊断系统里最基础、也最容易踩坑的部分——请求与响应机制。说白了，这就是ECU和诊断仪之间的“对话规则”。你问一句，它答一句，但怎么问、怎么答，这里头门道不少。

先说说SID，也就是Service Identifier，服务标识符。每个诊断服务都有一个唯一的ID，比如0x10是诊断会话控制，0x22是读取数据，0x2E是写入数据。你发一个请求，第一个字节就是SID。

那响应呢？正常情况下，ECU会回复一个肯定响应，格式是请求SID + 0x40。举个例子：你发0x22去读数据，ECU回复0x62。这个0x62就是0x22 + 0x40算出来的。

但问题来了——如果ECU处理不了这个请求呢？比如你发了个不支持的SID，或者参数错了。这时候ECU会回复否定响应，第一个字节是0x7F + 请求SID。比如你发0x22，否定响应就是0x7F 0x22，后面跟着一个字节的否定响应码（NRC）。

核心记忆点：

我记得刚入行那会儿，有个同事死活想不明白为什么ECU不回0x62而是回0x7F 0x22。后来一查，原来是请求报文长度不对。嗯，这种低级错误其实挺常见的。

接下来是寻址方式。这个我建议你重点理解，因为实车测试时经常搞混。

物理寻址，说白了就是“点对点”。你只跟一个ECU说话，其他ECU不理你。比如你只想读发动机ECU的数据，那就用物理寻址。CAN ID通常是固定的，比如0x7DF是请求ID，0x7E8是响应ID（不同车企定义不同）。

功能寻址呢，就是“群发消息”。你发一条请求，总线上所有支持该服务的ECU都会响应。比如你想让所有ECU都进入扩展会话模式，那就用功能寻址。功能寻址的CAN ID通常是0x7DF（请求），但响应还是各ECU用自己的物理地址回复。

注意：功能寻址时，如果多个ECU同时回复，总线可能会冲突。所以UDS协议规定，功能寻址的请求，ECU可以不回复肯定响应，或者只回复否定响应。具体看服务类型。

我在项目中遇到过一个问题：用功能寻址发0x10 0x03（扩展会话），结果只有两个ECU回复了，第三个没动静。后来发现那个ECU的CAN收发器有问题，根本没收到报文。你想想看，这种问题在实车测试时特别难排查。

子功能参数，就是SID后面的那个字节。有些服务需要子功能，比如0x10（诊断会话控制）后面跟着0x01（默认会话）、0x02（编程会话）、0x03（扩展会话）。

子功能字节的最高位（bit 7）有特殊含义：

举个例子：你发0x10 0x03，ECU会回复0x50 0x03。但如果你发0x10 0x83（0x03 | 0x80），ECU就不会回复肯定响应，只会在出错时回复否定响应。

实用技巧：我个人习惯在批量刷写时使用抑制肯定响应位。因为刷写过程中ECU会频繁回复，总线负载很高。抑制掉肯定响应，能减少总线拥堵。但要注意，如果出错了，ECU还是会回复否定响应的，所以不影响故障排查。

子功能的使用规则其实不复杂，但有个坑：不是所有服务都支持子功能。比如0x22（读取数据）就没有子功能，你发0x22后面直接跟数据ID。如果你给0x22加了个子功能字节，ECU会回复否定响应，NRC一般是0x12（子功能不支持）。

我曾经在集成测试时犯过这个错。当时想当然地以为所有服务都有子功能，结果0x22后面多塞了一个字节，ECU死活不认。查了半天协议才发现，0x22压根没有子功能参数。嗯，从那以后我每次用新服务前都会先翻翻协议。

最后总结几个实车测试时容易忽略的点：

响应超时：ECU处理请求需要时间，一般默认是50ms或100ms。如果诊断仪等不到响应就重发，可能会造成总线混乱。我建议你根据ECU的实际处理能力调整超时时间。
功能寻址的响应风暴：如果总线上挂了20个ECU，你用功能寻址发一个请求，20个ECU同时回复，总线瞬间就满了。所以功能寻址尽量用在不需要响应的场景，或者用抑制肯定响应位。
SID与子功能的组合：有些服务虽然支持子功能，但不同子功能的行为差异很大。比如0x31（例程控制）的子功能0x01（开始）、0x02（停止）、0x03（查询结果），你得搞清楚每个子功能的具体要求。

一句话总结：

SID决定“做什么”，子功能决定“怎么做”，寻址方式决定“跟谁说”。三者配合好了，诊断系统才能稳定可靠。

好了，这一章的内容就这些。下一章咱们聊聊具体的诊断服务实现，比如0x22和0x2E的读写操作，到时候我会分享一些实车测试的踩坑经历。