1. UDS协议基础：从汽车诊断的“通用语言”说起

大家好，欢迎来到《从零搭建UDS刷写测试环境》的第一章。

做汽车电子这么多年，我经常被新入行的同事问一个问题：“UDS到底是什么？” 说白了，它就是一套让诊断仪（Tester）和ECU（电子控制单元）之间能“好好说话”的规则。你想想看，一辆车上有几十甚至上百个ECU，博世的、大陆的、电装的，如果没有一个统一的标准，那诊断工具得配多少种“方言”啊？

UDS（Unified Diagnostic Services）就是来解决这个问题的。它定义了一套标准化的服务，无论你刷写哪个厂家的ECU，只要它支持UDS协议，你就能用同样的指令去读取故障码、读写数据、或者刷写软件。我个人习惯把UDS看作是汽车ECU的“通用语言”，掌握了它，你就拿到了进入汽车电子深水区的钥匙。

1.1 OSI模型与UDS：它到底工作在哪儿？

很多朋友学UDS时，容易把协议栈和物理层搞混。我记得刚入行时，也以为UDS就是CAN总线。其实不是的。

UDS主要工作在OSI模型的第7层——应用层。它依赖下面的传输层和网络层（比如ISO 15765-2，也就是我们常说的CAN TP）来把数据打包、拆包。你可以把UDS想象成快递单上的“收件人信息”，而CAN总线是那辆送快递的卡车。卡车怎么开、走哪条路，UDS不管，它只关心信息能不能准确送达。

下面这张图，是我自己总结的UDS在OSI模型中的位置，你看一眼就明白了。

1.2 UDS服务分类：三大类，各司其职

UDS协议里定义了26种服务（SID，Service Identifier），但别怕，它们被分成了三大类。你只要记住这个框架，后面学起来就轻松多了。

嗯，这里要注意，刷写测试主要用到的是第三类——上传下载类服务。但前两类是基础，就像盖楼要先打地基一样。你不可能跳过诊断会话控制直接去刷写，ECU会直接拒绝你的请求。

1.3 诊断会话控制 (0x10)：ECU的“工作模式”切换

这是UDS里最基础、也最重要的服务之一。为什么？因为ECU不是时刻都在“待命”的。为了省电和安全，ECU平时可能处于休眠状态，或者只响应部分服务。

0x10服务的作用，就是告诉ECU：“嘿，我要开始干活了，请切换到XX模式。” 常见的会话模式有下面几种：

• 默认会话 (Default Session, 0x01)：ECU上电后的默认状态。只支持基本的诊断服务（比如读故障码）。
• 编程会话 (Programming Session, 0x02)：刷写专用模式。只有在这个模式下，才能进行0x34（请求下载）等刷写服务。
• 扩展诊断会话 (Extended Diagnostic Session, 0x03)：用于一些高级诊断功能，比如读写特定数据、执行例程等。

0x10服务的请求格式很简单：

请求：0x10 + 子功能（会话类型）
例如：切换到编程会话 -> 02 10 02 00 00 00 00 00

ECU如果支持，会回复一个肯定响应：

响应：0x50 + 子功能 + 附加信息（如P2Server_max, P2*Server_max）
例如：50 02 00 32 00 1E

这里的0x32和0x1E是时间参数，告诉诊断仪：“我处理请求的最长时间是50ms，扩展时间是30ms。” 这个在自动化测试里非常关键，后面我们会详细讲。

1.4 ECU复位 (0x11)：让ECU“重启一下”

这个服务就更好理解了。刷写完软件后，通常需要让ECU复位，让新程序跑起来。0x11服务就是干这个的。

常见的复位类型有：

• 硬复位 (Hard Reset, 0x01)：模拟ECU断电再上电。所有RAM数据丢失，从头开始启动。
• 钥匙关/开复位 (Key Off/On Reset, 0x02)：模拟点火开关关闭再打开。部分ECU会保留一些运行数据。
• 软复位 (Soft Reset, 0x03)：仅复位软件，不涉及硬件电源。常用于快速重启。

0x11服务的请求格式：

请求：0x11 + 子功能（复位类型）
例如：硬复位 -> 02 11 01 00 00 00 00 00

ECU收到后，会先回复一个肯定响应，然后执行复位：

响应：0x51 + 子功能
例如：51 01

注意，复位后ECU会回到默认会话（0x01），所以如果你要继续刷写，需要重新发0x10 02切换会话。

1.5 本章小结：一张图看懂UDS基础

好了，这一章的内容就这么多。我们聊了UDS是什么、它在OSI模型中的位置、服务的三大分类，以及两个最基础的服务——0x10和0x11。

最后，我用一张图把本章的核心知识点串起来，方便你复习。