UDS协议简介

图1 诊断仪测试，来源于网络

写在开始：

在我的印象里，刚进入汽车行业时，总听到有人说拿诊断仪去查下什么故障，或者清下故障之类的。到后来做软件开发时，总听见有人提UDS服务，UDS测试有bug之类的。而现在终于知道什么是ISO14229，什么是ISO15765，它们是用来干什么的。像CAN通讯一样，UDS协议也是无处不在，因为有控制器就要有诊断服务，有诊断服务就要用到UDS协议--ISO14229。

我想：一个东西或事物既然普遍而通用，那么写出来于己于人或多或少都会有点价值。如果只是纯粹去看UDS协议，肯定是糊里糊涂。但如果辅以实例解析，似乎就不那么难了，如果再能对其软件实现加以概括，那么UDS协议就会更好理解了。这就是本系列UDS协议详解的写作动力之一。其实网上已经有了一些非常精彩的博文，我为何还继续这个主题，主要还是希望能给大家提供另一个选择：一个比较系统比较全面的讲解UDS协议，这也是我的写作动力之二吧。

图2 诊断测试，来源于网络

UDS协议

1.诊断服务的概念

首先了解下汽车诊断服务的概念，我们知道人生病了去看医生，医生会先问病人有什么症状，持续多久了，确定大概是什么病，然后去做什么检查，再来确定是什么病开什么药，这个过程就可以说是一个诊断服务的过程。类比到汽车，车主可能发现一些故障灯亮起（图3）或者感受到了车辆状态不对，这时就需要诊断具体的原因。

图3 故障灯，来源于网络

先用诊断设备去连接汽车控制器，如图4所示。然后可能需要解锁，再读取故障信息，或故障出现时冻结的数据，或读取内部某个参数的值等。最后找到问题后，可能需要刷写新的软件，读取当前故障信息，再清除故障使车辆恢复到正常状态。这就是一个汽车诊断服务的过程。

图4 诊断设备连接汽车（某个或某些控制器）

2. ISO14229协议简介

为了规范以上所述的诊断服务，所以就提出了UDS协议。

引自百度：UDS协议即ISO14229，是Unified Diagnostic Services，统一诊断服务，是诊断服务的规范化标准，比如读取故障码应该向ecu发什么指令，读数据流又是发什么指令。
OBD是关注车辆售后实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范，只是应用层的规范。
UDS(Unified diagnostic services)，与OBD最大的区别就在于“Unified”上，它是面向整车所有ECU(电控单元)的，而OBD是面向排放系统ECU的。单说UDS而言，它只是一个应用层协议(ISO 14229-1)，所以它既可以在CAN线上实现，甚至也能在Ethernet上实现。并且，UDS提供的是一个诊断服务的基本框架，主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来，所以基于UDS协议的诊断又常常被称为Enhanced diagnosic(增强型诊断)，UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。

根据OSI参考模型来分层的话，ISO14229协议中定义了UDS的所在位置如图5所示。

图5 基于OSI参考模型的诊断通讯，引自[1]

根据ISO14229协议定义了6类功能，26种服务，分别是：

• 1）诊断和通信管理功能单元，包括10，11，27，28，3E，83，84，85，86，87共10种服务；

• 2）数据传输功能单元，包括22，23，24，2A，2C，2E，3D共7种服务；

• 3）存储数据传输功能单元，包括14，19共2种服务；

• 4）输入输出控制功能单元，包括2F服务；

• 5）例行程序功能单元，包括31服务；

• 6）上传下载控制功能单元，包括34，35，36，37，38共5种服务。

通过上述定义的这些服务，就可以实现诊断服务过程，后续将展开详细介绍。

3. 通讯机制

为了实现上述的诊断服务，那么通过怎样的通讯机制来实现？简单地说如下图6所示：诊断仪先发送一个诊断服务请求给ECU，这里诊断仪称为客户端或测试端，ECU称为服务端；然后ECU（服务端）根据诊断服务按一定的机制回复给诊断仪（客户端或测试端）。（注意下这里专业术语，方便阅读协议标准）

图6 诊断服务通讯机制，引自[2]

比如诊断仪请求10 03，然后ECU回复50 03 00 32 01 F4。

以上通讯机制在ISO14229协议中定义如下图7所示：

图7 诊断服务通讯机制，引自[1]

4. 应用协议控制信息

为了便于下一篇文章对功能单元服务的描述，这里有必要对ISO14229-1协议的第7章进行部分说明，如下图8所示的部分协议数据单元的定义：

图8 协议数据单元定义，引自[1]

这里只关注红框内容A_Data，如上述的举例，A_Data指的是10 03，50 03 00 32 01 F4，而10 03中10，50 03 00 32 01 F4中50，就是上图A_Data组成部分之一--A_PCI，根据下图9所示的A_PCI定义，10和50更准确地称呼应该是SI。

图9 引自[1]

当然A_PCI还有另一种形式，如下所示，即下文会介绍的负响应格式。

图10 引自[1]

上图8中，A_Data组成部分除了A_PCI，还有Parameters，这些Parameters可能是sub-function（SF），也可能是data-parameter，或两者都包含。

图11 引自[1]

了解上述理论后，就可以引出下图12所示的服务请求/响应行为的定义:

图12 引自[3]

对于客户端请求（Request）服务有下列几种格式：

• 1）SID，比如待机握手服务（$3E）,请求格式为3E；

• 2） SID+SF，比如诊断会话控制服务（$10）的编程会话，请求格式为10 02；

• 3）SID+SF+Parameter，比如安全访问服务（$27）的发送密钥，请求格式为27 02 XX XX;

• 4） SID+Parameter，比如读取数据服务（$22）, 请求格式为 22 XX XX。

对于客户端请求服务，服务端有两类响应，一类是正响应，另一类是负响应。

正响应规定响应的SID必须是请求的SID+40，即请求SID为10，则响应SID为50；请求SID为27，则响应SID为67。

负响应规定响应格式必须是7F SID NRC,与正响应不同，这里SID仍为请求的SID，即请求SID为10，那么响应SID仍为10。NRC可理解为什么不能提供正响应的原因，比如说请求的SF不支持，请求的长度不对，等等原因。

以上就是对应用协议控制信息的介绍，将会后续文章介绍各种服务提供基础，比如就知道请求信息和响应信息的格式规范。

5. 应用

UDS协议主要用于控制在相应的会话层，去执行相应的功能，比如解锁访问，读写信息，刷写软件，清楚故障等。后续讲解6大功能时将详细介绍。

到此就简单介绍了下UDS协议的基本内容，在此基础上，后续将介绍：

1）基于ISO14229和示例讲解6大功能单元的相关服务；

2）基于ISO14229和AUTOSAR架构的UDS协议软件实现。

文章转载自公众号：汽车电子与软件