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

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 权限不对的情况

实例截图，长度不对的命令长度只给了1个字节 我这里演示给了1个字节，相应就是长度不对，其他几个NRC 0x22 0X33 ECU的10服务没有设计限定条件，因此暂时无法演示。 好到这里10服务就将完了 // 未完待续。。。2022/4/7日更新 //