第3章诊断请求与响应

3、诊断请求与响应：请求与响应的那些事儿

大家好，我是你们的老朋友。今天咱们聊聊诊断通信里最核心的一对儿——请求（Request）和响应（Response）。说白了，这就是ECU和诊断仪之间的对话方式。你问一句，它答一句，或者它直接执行动作。

我在项目里见过不少新手，上来就写诊断报文，结果ECU死活没反应。为什么？因为没搞懂寻址方式和子功能参数。嗯，今天咱们就把这些坑填平。

诊断通信遵循一个简单的规则：请求-响应。诊断仪发送一个请求报文，ECU收到后，要么给出肯定响应，要么给出否定响应。

举个例子，你发送一个读取数据的请求：

// 诊断请求：读取ECU的VIN码（0x22服务，DID为0xF190）
发送：02 22 F1 90
// 肯定响应：ECU返回VIN码
接收：06 62 F1 90 4C 4D 56 47
// 否定响应：ECU说“我不支持这个DID”
接收：03 7F 22 12

这里有个细节：肯定响应的报文ID通常是请求ID+0x40。比如请求ID是0x7E0，响应ID就是0x7E8。但这不是绝对的，有些ECU会使用不同的ID，我建议你查一下具体的网络设计文档。

核心要点：每个请求必须对应一个响应。如果ECU没响应，要么是报文没到，要么是ECU不支持该服务。我曾经遇到过ECU因为CAN总线负载过高，直接丢弃了诊断报文，排查了好久才发现是总线拥堵问题。

这是诊断通信里最容易混淆的概念。我刚开始做的时候也搞错过，后来才明白它们的区别。

物理寻址：一对一通信。诊断仪只跟一个特定的ECU对话。比如你只想读取发动机ECU的数据，就用物理寻址。报文ID是唯一的，比如0x7E0（请求）和0x7E8（响应）。

功能寻址：一对多通信。诊断仪发送一个请求，总线上所有支持该服务的ECU都会响应。比如你想让所有ECU同时进入扩展会话模式，就用功能寻址。报文ID是固定的，比如0x7DF（请求），但每个ECU的响应ID是各自的物理地址。

寻址方式	通信模式	请求ID示例	响应ID示例	应用场景
物理寻址	一对一	0x7E0	0x7E8	读取特定ECU数据
功能寻址	一对多	0x7DF	各ECU物理响应ID	广播请求（如进入扩展会话）

个人经验：我在做网关项目时，功能寻址经常被忽略。你想想看，如果网关不转发功能寻址报文，那么挂在网关后面的ECU就收不到广播请求。所以，一定要确认网关的路由表里是否包含了功能寻址ID。

很多诊断服务都支持子功能参数。比如0x10服务（诊断会话控制），它的子功能有：

子功能参数放在请求报文的第二个字节。比如：

// 请求进入扩展会话
发送：02 10 03
// 肯定响应
接收：02 50 03

注意看，响应里的子功能是0x50，也就是请求子功能0x03加上0x40。这是UDS协议的规定，表示肯定响应。

但这里有个重要的位——抑制正响应位（SPRMIB）。它位于子功能字节的最高位（bit 7）。如果这个位被置1，ECU就不会发送肯定响应，但否定响应还是会发的。

举个例子：

// 请求进入扩展会话，但抑制正响应
发送：02 10 83  // 0x83 = 0x03 | 0x80
// ECU不会发送肯定响应
// 但如果请求有错误，ECU会发送否定响应

注意：抑制正响应位只适用于某些服务，比如0x10、0x11、0x2E等。不是所有服务都支持。我曾经在项目里误用了这个位，导致ECU一直没响应，我还以为是通信断了，后来才发现是SPRMIB搞的鬼。

为什么要用SPRMIB？说白了，就是为了减少总线负载。比如你想让所有ECU同时进入扩展会话，如果用功能寻址，每个ECU都会回复一个肯定响应，总线瞬间就爆了。这时候，你可以在请求里设置SPRMIB，让ECU只执行动作，不回复响应。

嗯，这里我要分享几个我踩过的坑：

响应超时：ECU处理请求需要时间。我建议你设置至少50ms的超时时间，有些复杂的服务（比如写入数据）可能需要更久。
功能寻址的响应风暴：如果总线上有10个ECU，功能寻址请求后，你会收到10个响应。处理这些响应时，一定要做好去重和超时管理。
SPRMIB的误用：有些ECU对SPRMIB的实现有bug。我曾经遇到一个ECU，即使设置了SPRMIB，它还是会发送肯定响应。所以，测试时一定要验证。

总结一下：诊断请求与响应是UDS通信的基础。物理寻址用于一对一，功能寻址用于一对多。子功能参数让服务更灵活，而SPRMIB则帮你控制响应流量。记住这些，你在CANoe里写诊断脚本时就会少走很多弯路。

好了，今天就聊到这儿。下一章咱们会深入讲诊断服务的分类与常用服务，到时候见。