UDS的全称为Unified Diagnostic Services，关于UDS的详细描述和定义，大家可以查阅ISO 14229标准的系列文件来深入了解。网络上能够找到的关于UDS的文章非常多，我们这里从通俗易懂的角度给大家进行介绍，适合测试工程师快速入门，然后在实际项目中有工作经历之后可以通过其他方式再深入了解相关知识。

之所以一直强调UDS功能比较重要和基础，是因为USD功能在车辆生产和使用过程中对很多其他功能模块和基本操作有直接的影响。首先在车辆生产线下线时，产线电检会使用电检仪通过UDS对多个ECU写入很多必要的预设值信息，如写入对应车辆的VIN码、零件号、物流信息等，还可以激活某些特定设置，或者锁定一些特定状态以防止零部件的随意变更等等。车辆在4S店进行维护保养时，ECU固件的升级、故障码的读取和消除等等，也是通过OBD口连接使用UDS相关服务来完成的。

在上一篇文章中我们提到了，CAN网络上设备间通信基本可以分为3种情况，分别是：设备周期性主动发送一些状态报文；某个条件发生改变并符合设定要求，从而被动触发型信号发送；查询和回复型信号。这里查询和回复型主要就是UDS功能产生的。

为了方便理解，我们可以不是很准确地把UDS看作一个应用层协议（实际肯定不准确），因为在项目开发、测试、标定、排错等过程中接触最多的就是应用层相关的功能。

基于查询和回复这种问答式通信方法，在CAN网络上可以实现很多功能，如获取信息、写入信息、会话控制、重启设备、上传下载等等。我们把每种实现了特殊功能的查询和回复称为一种服务，UDS总体上有6大类，共26种不同服务。至于在具体项目中，网络架构工程师和系统设计工程师会根据实际情况对ECU支持的UDS服务种类进行裁剪，所以一般情况下ECU支持的服务种类要少于26种，通常还会对服务的对子功能做自定义设计。

请求报文的格式比较简单，通常由3部分组成，首先是Service ID固定长度1字节，Service ID直接表明了本服务支持的功能类型，就是前面我们说的26种服务中的一种，Sub-Function是对应的具体服务的每个子功能项设置，有的服务有多个子功能，也有的服务没有子功能，所以Sub-Function项是可选项，最后Parameter项是对应到最详细子功能的属性参数配置项，属性参数的配置也是根据实际情况来进行配备。

图 3

通常Parameter在具体项目中是工程师自定义最多的对象，也有主机厂在诊断规范中会自定义子服务。

我们举一个常见的服务来给大家说明下，如10服务。Service ID是10，功能是用来做会话控制，子功能通常是3个，分别为01、02、03，没有parameter参数，3个子功能分别代表了3种不同会话模式。在某个主机厂的诊断规范中自定了子功能04，为特殊场景自定义了该会话模式。综上所述10服务的请求报文通常会有：10 01、10 02、10 03。

对应于UDS请求报文，ECU通常有3种不同的响应处理。

1）Positive Response正响应

正响应是ECU对接收到的请求给予明确的成功内容结果返回，意味着请求得到成功执行。例如请求是读取车辆VIN码，正响应就是回答VIN是XXX。

正响应返回的报文格式跟请求报文类似分为3个部分，首先是Response SID是对请求服务的回显，Response SID的值为请求报文中SID + 0x40；其他两部分内容为Sub-Function和Parameter，这两部分的内容根据具体情况确定，在项目诊断规范中有明确规定。

正响应的报文格式如下图所示：

图 4

例如：请求10 01，正响应为50 01；请求22 XX XX，正响应为62 XX XX XX。

2）Negative Response负响应

负响应是ECU收到请求之后，无法对请求的内容正确执行，回复了失败，并附带了失败的原因。

负响应回复报文的格式同样可以分为3个部分，首先第一个字节是0x7F，表明请求失败，第二个字节为请求的服务ID，第三个字节为失败原因代码NRC。NRC代码具体对应的失败原因可以查阅NRC的表格来确定，在具体的项目中这部分内容可以查阅项目中的零部件网络诊断规范，在文章中我们多次提及了该文档，这个文档是由车型项目组的网络电子架构团队负责整体汇总发布，零部件的产品系统设计工程师负责维护和变更，所以在实际项目中可以找这两个岗位的工程师获取。

负响应报文格式如下图所示：

图 5

例如：请求10 02，负响应7F 10 7E，7F表明该相应失败，对应的失败服务是10，失败原因是7E，查阅NRC表知道7E的含义是“Sub-function not supported in active session”，提醒使用请求10 02子功能请求时不应该在当前会话模式下，当前的会话模式不支持10 02子功能请求使用。

3）无响应

无响应的出现是网络架构部门为了降低CAN网络上报文环境的复杂情况而做的设计。目的是不回复请求方正响应数据帧，即，当即将答复的响应帧为正响应时，不发送响应帧。

无响应是通过请求报文中子功能的抑制肯定响应指示位实现的。在某些服务的子功能中，最高的bit7位置为1时即设置为正响应抑制，该位置为0时关闭响应抑制。支持响应抑制设置的服务有10、11、28、3E、85等等。

图 6

例如：发送10 81，当回复是正响应时，ECU不答复；发送10 82，答复7F 10 7E，同样是请求带正响应抑制，但是ECU执行失败，此时则进行了回复。

我们之前强调，可以把UDS视为应用层协议，各主机厂对规范的自定义空间比较大，可以自由进行定制化修改。我在一个项目中遇到工程师设计了负响应抑制，跟本章节我们前面内容说的场景恰好相反，前面我们细说了当ECU响应为正响应时进行抑制，只回复失败。在一个项目中我遇到的是某些特定服务ECU正常发送正响应，只有负响应被抑制处理。所以诊断规范的自定义操作空间较大，测试设计时一定要仔细查阅相关规范。

在上一章节中我们使用了一些服务来举例，实例中包含了的是有效的数据内容，在CAN网络上进行UDS报文传输时，CAN网络的特性对于传输内容长度有一定要求，普通的CAN数据帧每帧8字节长度，在这个长度的报文上传输UDS协议数据时肯定会受到相应的限制，如果1帧报文长度不满足载荷需要，那就需要使用多条数据帧来信息承载。

1）单帧通讯

我们在上一章节列举的例子内容长度均比较短，7个字节的单个数据帧足够使用，这样的数据帧为单帧。

我们通过工具来查看网络上服务问答真实数据报文形式，如下所示：

图 7

我们可以看到两条报文：报文1)，Tester传输，ECU接收ID717，数据长度8字节，我们使用了SID10的会话控制服务，发送了报文“02 10 01”，其中首字节“02”表明本报文后面有效数据长度为2字节，第二字节“10”表明服务为SID10，第三字节“01”表明子功能为01，剩余4-8字节使用AA自动补全。报文2) Tester接收，ECU发送ID71F，数据长度8字节，正响应SID10的会话控制服务，发送了报文“02 50 01”，其中首字节“02”表明本报文后面有效数据长度为2字节，第二字节“50”表明SID10+0x40属于SID10服务的正响应，第三字节“01”是对应子功能。

2）多帧通讯

当一个数据帧7个字节不能完成一次通讯时，就需要把数据拆分到多个数据帧进行传输。我们同样通过下面的实例来进行讲解。

图 8

我们首先看请求报文“03 22 F1 80”，首字节“03”表明报文后面有3字节有效数据，第二字节“22”表明是SID22读取服务，22服务没有子功能，第三、四字节是$22服务读取的参数；返回报文的首帧为“10 10 62 F1 80 56 30 2E”，第一个字节“10”表明本条回复报文是多帧的第一帧，第二字节“10”表明后继有效数据长度为0x10字节，换成10进制为16字节，第三字节“62”是正响应服务SID22+0x40，第四、五字节表明Parameter参数为F1 80，后继的有效数据13字节的信息即为F1 80的读取值；第三帧报文“30 00 00 00 00 00 00 00”，为多帧的流控帧，提示首个响应报文成功发送，继续发送剩余帧；第四帧“21 30 30 2E 30 30 46 42”首字节“21”表明是多帧的第二帧，本帧其余字节均为有效数据内容；第五帧“22 4C 42 31 AA AA AA AA”，首字节“22”表明是多帧的第三帧，因全部多帧的有效长度在第一帧中记录为16字节，所以至此第三响应帧时有效数据内容只有3个字节，加上首字节的序号位，前4字节为有效位，剩余4字节自动填充。

03

部分诊断服务