第2章 UDS诊断协议基础

2、UDS诊断协议基础：ISO 14229-1 标准解读，诊断会话控制（0x10），安全访问（0x27）

好，咱们今天聊聊UDS诊断协议。说实话，这玩意儿是车载通信里绕不开的坎儿。你想想看，一辆车从生产线下来，到4S店做保养，再到远程升级，哪一步都离不开诊断。

ISO 14229-1这个标准，说白了就是定义了诊断服务的"语法"和"语义"。它规定了ECU该怎么听话，怎么回话。我刚开始啃这个标准的时候，也觉得头大——几百页的文档，全是术语。但后来我发现，只要抓住几个核心服务，其他都是变种。

这个标准的核心，其实就是一套请求-响应机制。诊断仪（Tester）发一个请求，ECU回一个响应。就这么简单。

但这里有个关键点：所有的诊断通信都是基于客户端-服务器模型。诊断仪是客户端，ECU是服务器。嗯，这里要注意，ECU不能主动发诊断消息，它只能被动响应。我在项目中遇到过有人想用ECU主动上报故障码，结果发现协议根本不允许——这就是没吃透标准。

标准里把诊断服务分成了几大类：

我个人习惯，把0x10和0x27看作是"门卫"——你想进ECU的"房间"做事情，得先过这两关。

0x10服务，说白了就是告诉ECU："嘿，我要开始干活了，你换个模式。"

ECU平时在车上跑着，处于默认会话（Default Session）。这个模式下，很多"危险"操作是被禁止的——比如刷写程序、修改配置。你想想看，要是车在高速上跑着，突然有人远程把ECU的程序给刷了，那不出事才怪。

0x10服务可以切换到以下几种会话：

请求格式很简单：

请求: 0x10 + SubFunction
例如切换到编程会话: 02 02

响应格式：

肯定响应: 0x50 + SubFunction + P2_Server_Max + P2*_Server_Max
例如: 50 02 00 32 00 0A

这里有个坑——P2定时器。响应里的0x32（50ms）和0x0A（10ms）分别表示ECU处理请求的最大时间和扩展时间。我曾经在调试时发现，ECU响应总是超时，后来一查，原来是P2时间设得太短，ECU还没来得及处理完就超时了。

⚠️ 注意：切换会话时，ECU会重置一些状态。比如你之前在安全访问状态，一切换到默认会话，安全状态就丢了。我见过有人刷写时先切到编程会话，然后做安全访问，结果中间不小心发了个0x10 0x01切回默认会话，安全状态没了，刷写失败——白白浪费了10分钟。

0x27服务，说白了就是"对暗号"。你想做敏感操作（比如刷写、校准），ECU会要求你先证明身份。

流程是这样的：

请求格式：

第一步 - 请求种子: 27 01
响应: 67 01 + Seed (例如 67 01 A5 B6 C7 D8)

第二步 - 发送密钥: 27 02 + Key (例如 27 02 3C 4D 5E 6F)
响应: 67 02 (成功) 或 7F 27 35 (失败，无效密钥)

这里有个关键点——安全等级。0x27服务支持多个安全等级，通过子功能区分：

每个等级有自己的种子和密钥算法。我见过有些ECU设计得特别"贼"——等级1的算法很简单，但等级2的算法复杂到需要查表。为什么？因为等级2用于更敏感的操作。

    💡 避坑指南：我曾经遇到过一个ECU，它的种子生成算法有问题——每次请求种子，返回的都是同一个值。这等于安全访问形同虚设。后来发现是随机数生成器的种子没初始化。所以，种子一定要真随机，否则安全访问就是个摆设。

说实话，0x10和0x27这两个服务，看起来简单，但实际用起来坑不少。我总结几个常见问题：

会话超时：ECU在非默认会话下，如果一段时间没收到诊断请求，会自动切回默认会话。这个时间通常是5秒左右。所以，如果你在做刷写操作，记得定时发0x3E（Tester Present）保持会话。
安全访问次数限制：很多ECU会限制安全访问的尝试次数。比如连续3次密钥错误，ECU会锁定一段时间（比如10秒）。我见过有人调试时疯狂发错误密钥，结果ECU锁了半小时——只能断电重启。
算法保密性：密钥算法通常由OEM定义，不会公开。所以，你在做第三方诊断仪时，得找OEM要算法。我有个朋友，项目做到一半才发现算法没拿到，结果延期了两个月。

🔧 小技巧：调试时，可以用CANoe的CAPL脚本模拟诊断仪。先发0x10切到扩展会话，再发0x27做安全访问，然后发0x22读数据。这样一步步验证，比直接上刷写流程靠谱得多。

嗯，0x10和0x27就聊到这儿。这两个服务是UDS的"门面"，搞懂了它们，后面的0x22、0x2E、0x34这些服务就顺理成章了。记住一句话：先会话，再安全，后操作——这是UDS通信的铁律。