第1章 UDS诊断协议概述

1. UDS诊断协议概述

大家好，我是你们的老朋友。今天咱们正式开始聊UDS诊断协议。

说实话，我最早接触UDS是在2015年，那时候刚入行做汽车嵌入式开发。记得第一次看到诊断报文，满脑子都是问号——这玩意儿到底在干什么？后来踩了不少坑，才慢慢摸清楚门道。今天我就把这些经验分享给你。

UDS，全称是Unified Diagnostic Services，统一诊断服务。它是汽车电子领域最核心的诊断协议标准，定义在ISO 14229里。

你可能会问：为什么要有UDS？

我举个例子。一辆车有几十个ECU（电子控制单元），发动机、变速箱、ABS、气囊……每个ECU都可能出故障。如果没有统一的标准，每个厂家各搞一套诊断协议，那维修厂得准备几十种诊断仪，想想就头大。

UDS就是为了解决这个问题而生的。它定义了一套通用的诊断服务，不管哪个ECU，不管哪个厂家，都按同一套规则来。说白了，就是让所有ECU说同一种语言。

核心要点：UDS是汽车诊断的通用语言，所有ECU都遵循同一套规则。

我在一个项目中遇到过这样的情况：客户要求支持UDS诊断，但ECU的MCU资源非常有限。当时我花了很大精力裁剪协议栈，既要保证功能完整，又不能超出内存限制。嗯，这里要注意，UDS虽然标准统一，但实际实现时可以灵活裁剪。

聊到UDS，就绕不开OSI七层模型。你想想看，一个诊断请求从诊断仪发出，到ECU收到并响应，中间要经过多少层？

UDS主要工作在OSI模型的第7层——应用层。但它依赖下面的传输层、网络层、数据链路层和物理层。

我个人习惯把UDS协议栈想象成一个快递系统：

我曾经调试过一个UDS通信问题，诊断仪发请求ECU没响应。查了半天，发现是网络层报文分片重组出了问题。你想想看，应用层代码写得再好，底层传输有问题也是白搭。

经验之谈：调试UDS问题时，先从底层查起。物理层通了吗？CAN报文能收发吗？网络层分片正常吗？一层层往上排查，效率最高。

UDS定义了26种诊断服务，从0x10到0x3E。但咱们先不急着记这些数字，先搞清楚两个最重要的概念：功能寻址和物理寻址。

物理寻址，就是点对点通信。诊断仪发给某个特定的ECU，只有这个ECU会响应。

举个例子：诊断仪想读取发动机ECU的故障码，就发一个物理寻址的请求。发动机ECU收到后处理并回复，其他ECU（比如ABS、气囊）看到这个报文，知道不是找自己的，直接忽略。

物理寻址的CAN ID通常是：

功能寻址，就是一对多通信。诊断仪发一个请求，总线上所有支持该功能的ECU都会响应。

我举个例子你就明白了。假设你想让所有ECU同时进入诊断模式，用物理寻址得一个个发，多麻烦。用功能寻址，一条报文搞定所有ECU。

功能寻址的CAN ID是固定的：

注意：功能寻址虽然方便，但有个坑——多个ECU同时回复，总线可能会冲突。我曾经在项目里遇到功能寻址导致总线负载过高的问题，后来加了随机延迟才解决。

咱们用个表格对比一下：

说到这儿，我想起一个真实案例。有一次客户反馈，用功能寻址发诊断请求，有的ECU响应了，有的没响应。排查后发现，没响应的ECU在功能寻址过滤配置上出了问题。嗯，这里要提醒你，功能寻址的实现一定要仔细核对标准，每个ECU的过滤条件都得配对。

今天咱们聊了UDS的背景、OSI模型的关系，还有功能寻址和物理寻址的区别。这些都是UDS诊断的基础，后面的章节都会用到。

我个人建议你先把这些概念吃透，尤其是寻址方式。很多诊断问题，归根结底都是寻址没搞对。下一章咱们开始讲具体的诊断服务，从0x10诊断会话控制开始。

记住一句话：UDS不难，难的是细节。咱们慢慢来。

课后思考：如果总线上有10个ECU，你用功能寻址发一个请求，理论上会收到多少个响应？为什么实际中可能收不到全部？