第1章：CAN诊断协议UDS基础

各位同学好，我是老张。在车载行业摸爬滚打了十几年，今天咱们来聊聊UDS诊断协议。说实话，我刚入行那会儿，UDS还没这么普及，大家还在用KWP2000。后来随着CAN总线成为主流，UDS才慢慢成了标配。

嗯，咱们先搞清楚一个概念——UDS到底是什么？

1.1 UDS概述（ISO 14229）

UDS，全称是Unified Diagnostic Services，统一诊断服务。它定义在ISO 14229标准里。说白了，就是一套汽车电子系统通用的「体检和维修」协议。

你想想看，一辆车上有几十个ECU（电子控制单元），每个ECU都可能出问题。如果没有统一的标准，那维修师傅得学几十种不同的诊断方法，这显然不现实。UDS就是为了解决这个问题而生的。

我记得2015年做的一个项目，客户要求所有ECU都必须支持UDS。当时我们团队里有人觉得没必要，说「我们自己的协议用得好好的」。结果后来在产线测试环节，就因为诊断协议不统一，折腾了整整两周。从那以后，我再也不敢轻视UDS了。

ISO 14229这个标准其实挺厚的，我建议初学者先抓住几个关键点：

• 服务标识符（SID）：每个诊断服务都有一个唯一的ID，比如0x10是诊断会话控制，0x22是读取数据
• 请求/响应机制：诊断仪发请求，ECU回响应。就这么简单
• 子功能：同一个服务下可以有不同子功能，比如0x10服务下有0x01、0x02、0x03三个子功能

1.2 UDS服务分类

UDS的服务一共分为6大类，共26个服务。我习惯把它们分成三组来记：

分类	服务范围	典型服务
诊断与通信管理	0x10 - 0x3E	会话控制、ECU复位、安全访问
数据传输	0x22 - 0x2E	读取数据、写入数据
存储数据传输	0x14 - 0x19	清除诊断信息、读取故障码
输入输出控制	0x2F	控制执行器、模拟输入信号
远程激活	0x31	启动例程、停止例程
上传下载	0x34 - 0x37	刷写固件、读取内存

我个人习惯把前两类称为「日常诊断」，后四类称为「高级操作」。为什么这么分？因为在实际项目中，80%的诊断工作都集中在会话控制、读取数据和读取故障码这三个服务上。

我曾经遇到过一个坑：某供应商的ECU，在扩展会话下才能读取某些数据。但我们的诊断仪默认只进入了默认会话。结果测试了三天，一直读不到数据，还以为是硬件坏了。后来才发现是会话没切换对。嗯，这个教训让我养成了一个习惯——做诊断前先确认当前会话状态。

1.3 UDS会话控制

会话控制是UDS里最基础也最重要的服务（SID = 0x10）。它定义了ECU可以处于的三种会话状态：

• 默认会话（Default Session）：上电后的默认状态，只能执行最基本的诊断服务
• 扩展会话（Extended Session）：可以执行更多诊断服务，比如读写数据、控制执行器
• 编程会话（Programming Session）：用于固件刷写，安全性要求最高

你想想看，为什么要有会话这个概念？其实是为了安全。ECU不希望随便一个设备都能控制它的执行器或者刷写它的固件。所以设计了不同级别的会话，就像大楼的门禁系统一样——普通访客只能进大厅，员工可以进办公室，只有管理员才能进机房。

我记得有一次做产线测试，刷写程序总是失败。排查了半天，发现是编程会话超时了。因为刷写文件比较大，传输时间超过了5秒，ECU自动切回了默认会话，导致刷写中断。后来我们在刷写前先发一个保持会话的请求（0x3E服务），问题就解决了。

会话切换的流程其实很简单：

诊断仪发送：02 10 03 00 00 00 00 00
  ↑  ↑  ↑
  长度 SID 子功能（03 = 扩展会话）

ECU响应：02 50 03 00 00 00 00 00
  ↑  ↑  ↑
  长度 SID+0x40 子功能（表示成功）

这里要注意，ECU的响应SID是请求SID加上0x40。比如请求是0x10，响应就是0x50。这是UDS的一个固定规则，我刚开始学的时候经常搞混。

小结

好了，这一章的内容就这些。总结一下：

1. UDS是汽车诊断的统一语言，定义在ISO 14229里
2. 6大类服务，日常用得最多的是会话控制、数据读取和故障码读取
3. 三种会话：默认、扩展、编程，各有各的权限和用途

下一章咱们会深入讲0x22和0x2E这两个数据传输服务，到时候会带大家看一些实际的数据流。嗯，今天就到这里，有问题随时问我。