大白话给你讲明白UDS诊断(汽车诊断服务实例应用图文讲解）（一）

李友一

已于 2022-07-08 08:59:55 修改

阅读量1.4w

点赞数 54

分类专栏：敲开汽车软件研发的大门文章标签：汽车嵌入式硬件

于 2022-04-08 15:02:43 首次发布

本文链接：https://blog.csdn.net/liaoyingjun/article/details/123902976

版权

敲开汽车软件研发的大门专栏收录该内容

2 篇文章

订阅专栏

本文介绍了汽车UDS诊断的基本概念和作用，通过比喻和实例展示了诊断仪如何检测汽车状况，强调了ISO-14229标准的重要性。UDS诊断通过CAN总线与ECU通信，利用功能寻址和物理寻址进行精确操作，并通过10服务进行会话控制。文中还探讨了错误处理和不同类型的会话功能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

UDS诊断(汽车诊断）是啥，我知道肯定有很多人不知道
1、这个是什么东西？
2、有什么用？
先看个百科截图，引出诊断的概念！
在这里插入图片描述
有什么用
这个用处是我在不拆车的情况下，检测汽车的状况，以确定具体故障。
这就跟一个人去医院做检查一样，通过各种检查看你是否健康，或者哪里有病灶，医生检查手段有望闻问切，抽血，B超，CT等。

汽车呢？
诊断汽车的故障，最直接快捷准确的就是通过诊断仪连接到汽车的OBD端口读取车况信息。
汽车诊断仪下图
在这里插入图片描述
有车的朋友可能见过，这个东西在汽车维修店经常用到，这个诊断仪像一个平板电脑，另一个头连接到汽车的OBD口。

那OBD口在汽车的那个位置？一般在主驾驶膝盖位置.

如下图OBD接口所在的地方在这里插入图片描述
链接好后，检修人员就可以在诊断仪的屏幕获取到车辆的数据信息，如果有问题，就会在诊断以上显示出来，以方便维修人员针对性的检修。
有的故障是会显示在汽车仪表上，但是有的故障是不显示出来的。

下图就是仪表指示故障灯亮的实拍，正常情况下汽车启动了是不会有图标点亮的。
在这里插入图片描述

好那显而易见是，诊断仪和汽车之间肯定是约定好了才能进行通讯对吧，总不能把你手机数据线插进去也能读到信息。
这里就要引出一个标准了，他就是“ISO-14229”
这是一个汽车诊断（UDS诊断）国际标准，这个标准里面，详细定义了汽车诊断的规范，任何车厂或者零件供应商都需要遵循这个标准去设计。

就像USB接口，网线接口，无论哪一台电脑都是一样的。如果你不按照这个设计，那你在这个行业肯定是没办法生存的，因为你是一个孤立存在，现有的资源和你不兼容，就很难生存。除非你足够强大，强大到你能制定行业游戏规则，比如某水果。。。

好，在回到我们的诊断这边，我们汽车里面的控制器是很多的，这些控制器我们叫做ECU，一部现代轿车大约有十几个ECU，某些豪华轿车甚至多达几十个，这些电子设备的价值，几乎占掉车身价值的35%以上。诊断其实就是检测这些ECU有没有存在故障

那这些ECU之间,ECU和诊断议之间是通过什么相互通信？
是通过CAN总线，城市和城市之间互联互通是通过公路，ECU之间的“公路”就是CAN总线了，诊断仪接上这条公路就能访问到每一个ECU了。

当然除了ECU还要其他的总线类型，比如LIN 和以太网。CAN是汽车通讯的基石，这个我们前一篇“白话CAN总线”已经讲过，这里不再赘述，这篇文章主要是讲诊断。诊断活动也是通过CAN总线进行，目前来看，不拆车的情况下接入CAN总线是我们了解ECU状况的唯一办法。诊断仪器通过发送CAN数据问ECU，ECU回复CAN数据，这样一问一答的形式把ECU的信息，通过这样的诊断报文传输。

敲黑板！敲黑板！重点又来了，
那么诊断仪如何精确无误的访问到某个ECU呢？因为我们已经讲过，汽车里面的ECU多达十几个，甚至几十个。

下图示意电脑诊断仪连接到汽车的样子
在这里插入图片描述
诊断议为客户端，汽车（ECU）为服务端.

我们这里还要引入一个重要的知识，功能寻找，和物理寻址。
我举个简单的例子，一看就明白：
**功能寻址：**校长（诊断仪）在升学典礼上用话筒喊道，三年级一班的全体同学们，请站到舞台中间来。
然后三年级一班的同学全都站起来了。
**物理寻址：**校长（诊断仪）在升学典礼上用话筒喊道，三年级一班的张三，请你站到舞台中间来，然后只有张三站了过去。

这就是功能寻址和物理寻址的区别，诊断过程中，功能寻址对一类ECU而言。物理寻址针对某个ECU而言，前提是诊断仪（校长）要知道这个ECU的ID（张三的名字）。

ISO14229里面定义了很多类型的服务。我们这边主要讲经常用到的服务，这足以覆盖98%诊断开发情况了。当你理解了现有的服务，不常用的也可以触类旁通。

首先第一个 10 服务，这个英文全称
“DiagnosticSessionControl (10 hex) service”
直译诊断会话控制，通俗一点讲就是授权控制。汽车ECU里面可以对某些操作设定有特定权限，你如果需要操作这些功能，诊断仪需要请求到对应权限才能允许操作。

实例诊断报文截图,只看TX和RX行
在这里插入图片描述
如图所示，ID为0x726的报文是我们模拟诊断仪，使用的是物理寻址方式，发送的会话控制命令 10 01，我们注意到前面中括号的**[2]，这代表这个报文数据字节数，简单讲就是后面只有两个字节是有效的**。
ECU在接收到这个报文的时候就用ID为0x7A6（RX）回复了诊断仪,内容为50 01 00 22 01 F4，同理的**[6]也是有效位为6个**。

实例演示一个物理寻址的控制命令
在这里插入图片描述 ID为0x7DF的报文是我们模拟诊断仪，使用的是功能寻址方式图上实例看出，10 服务同时支持功能寻址和物理寻址，因此这两种请求方式都会得到ECU的响应。

回到前面讲的发送报文，10 01，第一个数据10是服务号，10服务，第二个数据01是子功能，01代表默认会话。子功能可以有多个比如 02 03 04 等，02 一般用作编程会话，比如我这个ECU需要做在线升级，就必须先到这个02会话。03 一般用作扩展会话，这个会话可以放一些读写数据的操作或者控制外围设备的操作。根据产品的需要进行划分，每个会话模式可以放置对应操作的权限。

第二个ECU回复报文50 01 00 22 01 F4，首先，50是10+0x40后的响应，所有服务的ID的响应报文都是服务”“ID+0x40“第二个01就是响应对应子功能。00 22 01 F4官方的解释是P2Server_max和P2*Server_max，这两个是ECU性能参数，先不展开讲，意思ECU通过这几个反馈是告诉诊断仪，我的处理能力就这样，你自己看着办。然后呢诊断仪秒懂，你不会做一些超出你能力范围的事情。

实例截图，命令10 03的TX 和RX。
在这里插入图片描述
这个是在我发10服务命令正常的下的回，这样没有错误的回复叫做正响应，我们看下如果我把这发错了ECU在遵循这个ISO 14229 协议情况下是如何回复的。

实例截图错误的命令10 66
在这里插入图片描述
上图所示，我用10服务发了一个命令，10 66这个66是子功能，但是我的ECU没开发这个66的子功能，ECU不认识，就回复了7F 10 12,7F是负相应的代码，也就是出错了，任何服务的ECU负响应都是7F开头然后带上第二个服务ID，第三个12是负响应代码NRC 0x12，
12的在ISO里面解释是sub-functionNotSupported，不支持这个子功能。
下图来自ISO 14229原文
在这里插入图片描述
同样的还会有其他的0x13 长度不对， 0x22 条件不对，还有0X33 权限不对的情况