UDS名词解释及分析

简介 

       UDS诊断可以看作是ECU与外部诊断设备间通讯的桥梁，国际标准（ISO14229）中定义了UDS的大致框架，共分为6大类28种服务。

        我们可以通过UDS实现对汽车包括但不限于 功能监控 、故障检测 、记录并存储故障信息 、读取数据 等功能。

        在实际使用上，当汽车出现故障时，维修工人们可以通过 UDS 诊断来甄别故障类型，并得知故障发生在什么条件下。因此，UDS 在汽车行业中十分重要。

        UDS所有诊断服务如下图所示。

子服务

        在上面的表格中，有的服务被标注为支持子服务。有的服务会有多种的用法，通过 子服务（SF，Sub-Function)  我们就可以使用该服务的不同功能。

        比如 10 服务，其作用是将 ECU 切换到不同的诊断会话下。ECU的会话模式有3种，使用 10 01 可以切换到默认会话；10 02 可以切换到编程会话。其中，10后面的 01和02 就是子服务。

 请求

        UDS是一种通讯协议，所以UDS一般都是基于 其他通信方式(CAN、LIN、以太网等) 发送和接收的。

        诊断通信的过程就是发送方与接收方不断的交换数据，UDS的作用就是为所有的诊断功能请求和响应定义了统一的格式和内容。

        建立一个完整的UDS通信最少需要1名发送方和1名接收方，由发送方发出的数据包称为服务请求(Request)，接收方接收到请求后回复的数据包称为响应(Response)。

        请求的常见格式如下:

        上图中，主要的几个参数就是下图所示的三个：

        其中，DTC的全称为 Diagnostic Trouble Code ，也就是诊断故障码。其作用为记录故障的相关信息，一般占用3个字节的大小。

        DID，全称为 Data ldentifier 。在 ECU 中，存储的数据是海量的，通过 DID 可以找到想要读取的数据。

        SID，全称为 Service Identifier ，就是 UDS 28种服务的ID。

        需要注意的是，有的服务在 DID或者SF 后面跟着其他参数，有的却不会，甚至还有的直接就是SID跟着其他参数，需要具体问题具体分析。

响应

肯定响应

        按照以上的正确格式发出请求后，接收方会给予响应。响应分为 肯定响应(Position Response) 与 否定响应(Negative Response) 。

        首先说肯定响应，肯定响应是在 请求SID 的基础上加 0x40，后面依旧是 DID或者SF，在之后可能就是一些参数。其格式如下：

        依然需要注意的是，有的服务比如14服务，其响应可能就只是 54 就结束了，后面没有任何参数，也是要根据服务来分辨。

否定响应

        相比于肯定响应，否定响应的格式就简单许多。首先，第一个字节会回复 0x7F，然后是 请求的SID，最后则是 NRC（否定响应码）。否定响应的格式如下：

        NRC，一般代表着发生否定响应的原因，具体的内容和否定响应原因的对应关系如下：

0x00: 无否定响应码，通常不用于否定响应报文。
0x10: 通用拒绝，表示服务端拒绝了请求的执行。
0x11: 服务不支持，表示请求的服务未被服务端支持。
0x12: 子功能不支持，表示请求的服务中包含服务端不支持的子功能。
0x13: 消息格式错误，表示请求消息的长度或格式不正确。
0x14: 响应超长，表示服务端生成的响应超出了网络层可用的最大字节数。
0x21: 服务端忙，表示服务端暂时忙而无法执行请求的操作。
0x22: 条件不满足，表示请求的服务由于未满足某些条件而不能执行。
0x24: 请求序列错误，表示客户端发送的请求报文顺序不符合服务端的规定。
0x25: 子网组件无响应，表示服务端已收到请求，但子网组件未在规定时间内响应。
0x26: 因失效阻止请求执行，表示由于发生故障，该故障禁止服务端执行请求的动作。
0x31: 请求超出范围，表示请求报文中的参数超出了授权范围或试图访问的数据标识符/例程标识符不被支持。
0x33: 安全访问拒绝，表示客户端未能满足服务端的安全策略。
0x35: 密钥无效，表示客户端发送的密钥与服务端内存中的密钥不匹配。
0x36: 超出访问次数，表示客户端未成功访问的次数超出了服务端安全策略所允许的次数。
0x37: 请求的时间延迟未过期，表示客户端在服务端要求的超时周期未到之前发送了请求报文。
0x70: 上传/下载未被接收，表示由于某种故障条件，上传/下载到服务端内存中的尝试未被完成。
0x71: 数据传输停止，表示由于一些故障，已经激活的数据传输服务应该被停止。
0x72: 一般性编程失败，表示在永久内存设备上进行擦写或编程时检测到错误。
0x78: 请求正确接收，应答待定，表示请求报文被正确接收，但是要执行的操作尚未完成，服务端也还没有准备好接收另一个请求。
0x7E: 会话不支持子功能，表示在当前的会话模式下不支持请求的子功能。
0x7F: 会话不支持服务，表示在当前的会话模式下不支持请求的服务。

DTC解析

        当发生故障时，DTC能够告诉我们具体发生了什么事情。DTC 的长度为3个字节，但在实际应用中，一般后面还会接一个字节DTC状态位，用于提示当前DTC的状态，比如当前DTC是否被清除。该状态位的每个bit都有其含义，实际使用中可以参考车厂的定义。

        DTC的具体结构和含义如下图所示：

        此处我们举个例子，如果现在有个DTC：P123456

        首先，我们进行一下拆分：P12 34 56，后两个字节我们参考上图即可；P12，P代表 00 ，1 代表 01，转化过来就是 12；整体来看，这个DTC的值就是 12 34 56。

        在实际应用中，其实我们基本上不会去看形如 P123456 之类的东西，一般都是直接使用 像123456 这种格式的 DTC码 ，所以这里知道大概有这样的对应关系即可。