UDS诊断应用层笔记

UDS概述

UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是在汽车电子ECU环境下的一种诊断通信协议，在ISO 14229中规定。它是从ISO 14230-3（KWP2000）和ISO 15765-3协议衍生出来的。“统一”这个词意味着它是一个“国际化的”而非”公司特定的”标准。到目前为止，这种通信协议被用在几乎所有由OEM一级供应商所制造的新ECU上面。这些ECU控制车辆的各种功能，包括电控燃油喷射系统（EFI），发动机控制系统，变速箱，防抱死制动系统(ABS)，门锁，制动器等。

诊断工具与车内的所有控制单元均有连接，且这些控制单元均启用了UDS服务。不同于仅使用OSI模型第一层、第二层的CAN协议，UDS服务使用OSI模型的第五层和第七层（会话层和应用层）。服务ID（SID） 和与服务相关的参数包含在CAN数据帧的8个数据字节中，这些数据帧是从诊断工具发出的。

目前市面上的新车都具有用于车外诊断的诊断接口，这使得我们可以用电脑或诊断工具（业内称为测试器Tester）连接到车辆的总线系统上。因此，UDS中定义的消息可以发送到支持UDS服务的控制器（业内称ECU）。这样我们就可以访问各个控制单元的故障存储器或用新的固件更新ECU的程序。除此之外，UDS还用于下线检测时把一些信息（如VIN码）写入到汽车的各个零部件中。这些功能也是UDS最为核心的功能。

为什么我们要设计UDS这样的诊断协议呢？在汽车诊断协议诞生之前，修车只能靠师傅的经验，因为汽车零部件不会告诉你它哪里出了问题。但有了诊断协议之后，一旦零部件出了问题或者出过问题，它们会把故障信息保存在内存里面，维修师傅就可以通过通信总线读取这些故障信息，比如一个ECU经历欠压故障之后，它会将欠压故障代表的DTC（诊断故障码）存储起来，可选择性保存的还有发生故障时的快照信息（比如此时的车速、读到的电压值等）。快照信息有助于测试工程师和售后技师查找发生故障的原因。

除了CAN总线以外，UDS也可在不同的汽车总线（例如 LIN, Flexray, Internet 和K-line）上实现。

---

应用层服务

UDS本质上是一系列的服务，共包含6大类26种。每种服务都有自己独立的ID，即SID。

SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），这条数据中需要包含SID。如果是肯定的响应（Positive Response），回复 [SID+0x40]，就是请求10，响应50；请求22，响应62，回复的是一组数据。如果是否定的响应（Negative Response），回复7F+SID+NRC，回复的是一个声明。肯定响应和否定响应的形式一定要熟记。

---

0x10诊断会话

0x10包含3个子功能:

• 01 :默认会话(权限最小,操作服务少)
• 02 :编程会话(用于解锁bootloader相关)
• 03 :扩展会话(解锁高权限服务:写入数据和诊断码)

ECU上电时，进入的是默认会话.如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01(最低权限)。当然，我们有一个0x3E的服务，可以使诊断保持在非默认的状态。

0x10服务否定响应码:

• 0x12:不支持请求服务的功能
• 0x13:请求报文的数据长度或者格式不合法
• 0x22:条件不满足
• 0x31:请求超出范围

02	10	01	00	00	00	00	00	发送
06	50	01	00	32	00	C8	AA	接收
02	10	02	00	00	00	00	00	发送
03	7F	10	22	AA	AA	AA	AA	失败

---

0x3E待机握手

0x3E服务用于向服务器指示诊断仪仍然连接在网络上，之前已经激活的诊断服务功能可以仍然保持激活状态。

0x3E否定码:

• 0x12:不支持请求服务的功能
• 0x13:请求报文的数据长度或者格式不合法

发送一个3E服务的报文，保持非默认会话状态。80表示无需回复。

02	3E	00	55	55	55	55	55	发送
02	7E	00	xx	xx	xx	xx	xx	否定
02	3E	80	xx	xx	xx	xx	xx	接收

---

0x27安全访问

0x27安全访问：ECU当中有很多数据是整车厂独有的，并不希望开放给所有客户，它需要做一个保密的设定。我们在读取一些特殊数据的时候，要先进行一个安全解锁。ECU上电之后是一个锁定的状态（Locked），我们通过0x27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。

比如下面的例子，2n-1是一个子服务，这里我们先用n=1，即01子服务来举例子。通过首轮Tester种子的请求（27+01），ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。之后第二轮，诊断端的Tester会利用种子进行运算（根据整车厂的算法），生成k1（不一定是1个字节），之后发送请求，子服务是2n，这里我们还是假定n=1，即02子服务。这样Tester发出的就是27+02+[k1]。之后，ECU同样也会根据第一轮的种子自行算出k2。当ECU检查出k1和k2完全一致时，解锁（Unlocked）成功。

0x27否定码:

• 0x12:不支持请求服务的功能
• 0x13:请求报文的数据长度或者格式不合法
• 0x22:条件不满足
• 0x24:请求顺序错误
• 0x31:请求超出范围
• 0x35:无效密钥
• 0x36:尝试次数超限
• 0x37:延时数据未到

例子：

Tester： 02 27 05 00 00 00 00 00 安全访问，05子功能

ECU： 06 67 05 08 27 11 F0 00 肯定响应，回复了对应安全级别的种子

Tester： 06 27 06 FF FF FF FF 00 发送密钥，4个FF。注意06是与05成对使用的。

ECU： 03 7F 27 78 00 00 00 00 若为否定响应，7F+27+NRC

ECU： 02 67 06 00 00 00 00 00 若为肯定响应，通过安全校验

细说下安全验证算法。安全验证算法包括1个核心，3个主体。

第一个主体通常和ECU有关。比如我们先用22服务读取ECU的SN，取其中4个字节，作为“调味料”参与，显然这个“调味料”对于这个ECU来说是不变的，也能通过22服务方便的读取到。

第二个主体seed，通常与ECU的运行时间有关系，是主料，在27服务发送奇数子功能时回复。seed通常一直在发生变化，无法发现其规律。

第三个主体是执行次数，就是算法要执行几轮。执行1轮和2轮得到的结果肯定是不一样的对吧。

最大的核心就是算法了。举个简单的算法，比如seed和ECU SN前4个字节加一下，循环左移两位，执行3轮，return这个数作为key，结束。安全验证就是一把锁，算法越复杂，短时间解开的成本越高，越不易被破解掉。如果失败次数过多还会触发惩罚机制，一段时间内都无法再尝试解锁，防止人为的破解。

---

0x22读数据

0x22读数据，Request（请求）：22+DID（数据标识符，通常是两个字节）

Response（响应）：62+DID+Data

DID有一部分已经被ISO 14229-1规定：

1. 0xF186就是当前诊断会话数据标识符
2. 0xF187就是车厂备件号数据标识符
3. 0xF188就是车厂ECU软件号码数据ID
4. 0xF189就是车厂ECU软件版本号数据标识符

---

0x21写数据

0x2E写数据，Request（请求）：2E+DID+Data

Response（响应）：6E+DID

由上图可知，请求格式分为三部分
第一部分：请求SID：0x2E，占用一个字节
第二部分：dataIdentifier（DID），需要写入数据对应的DID标识符值。占用两个字节
第三部分：dataRecord，需要写入的数据

由上图可知，响应格式分为两个部分
第一部分：response SID：0x6E
第二部分：dataIdentifier（DID），请求DID的echo

---

0x19读DTC

19服务是一套诊断服务中的重中之重

DTC：如果系统检测到了一个错误，它将存储为DTC。DTC可表现为：一个显而易见的故障；通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节

故障码包括四个大类，分别是PCBU，P是动力系统，C是底盘，B是车身，U是通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。一个DTC除了它自己的3个字节，还有一个字节专门用于表达DTC的状态，这个字节我们叫它DTC状态掩码 .

第一个字节在乘用车中，前两个bit代表P/C/B/U（动力/底盘/车身/网络）中的一个，之后六个bit是数字，合在一起的样子形如“C01”。第一个字节的前2个bit中，用00/01/10/11分别表示P/C/B/U。

0x19拥有28个子服务。常用的子服务有：

• 01 (读取符合掩码条件的DTC数量)（必须支持）,后面的参数是DTC状态掩码，若为01表示我想读当前故障，若为08表示我想读历史故障，若为09表示当前故障和历史故障都想读。

  在肯定回复时，组合应该是59(19+40) - 01 （子功能） - 09 （本ECU所支持的掩码条件）-01 DTC的格式 - 00 01 （目前满足条件的DTC有一个）

• 02（读取符合掩码条件的DTC列表及其状态）（必须支持），后面的参数是DTC状态掩码，解读同上。

  在肯定回复是，59 - 02（子功能）- 09（本ECU所支持的掩码条件） - XX XX XX ( DTC,车厂定义 ) - 01

• 04（读取快照信息），也叫冻结帧。

• 06（读取扩展信息）

• 0A（读取ECU支持的所有DTC列表及其状态）（必须支持）。这个就不必发DTC状态掩码了。所有支持的DTC列表及其状态都会打印出来。

---

0x14清除DTC

清除（复位）DTC格式，它可以改变DTC的状态。DTC状态中的八个位，除bit4和bit6外均会被清零，包含当前故障和历史故障。bit4和bit6这两个testNotCompleted开头的会被强制置1。

3个FF代表清除所有DTC。

由上图可知请求格式分为两个部分
第一部分：请求SID：0x14，占用一个字节
第二部分：groupOfDTC，由厂家自定义，占用三个字节

由上图可知响应格式只有response SID：0x54，占用一个字节

groupOfDTC为3个FF代表清除所有DTC

---

0x2F IO控制

该服务可以通过DID(数据标识符)来进行输入信号的替换和控制零部件负载输出。这是一个用在产线上较多的服务。该报文的请求至少由4个字节组成。第一个字节是2F，第二第三字节是DID

IO控制类型分为4类，

• 00是控制权还给ECU
• 01是复位为默认值
• 02是冻结当前的状态
• 03是短暂接管控制权

若控制类型是00-02这三种，请求报文是4个字节。

若控制类型是03，请求报文的第5字节是控制代码，可以是数字量，比如01是开，00是关；也可以是模拟量，比如空调风门的开度。

0x2F否定码:

• 0x13:请求报文的数据长度或者格式不合法
• 0x22:条件不满足
• 0x31:请求超出范围
• 0x33:安全访问拒绝

以上内容来自于UDS诊断应用层笔记 - 西故黄鹤楼 - 博客园 (cnblogs.com)，用于个人知识积累，若有侵权，请联系删除