UDS诊断

一、UDS诊断简介

汽车诊断技术是指在不拆卸车辆的情况下，通过读取车辆在运行过程中所记录的数据或故障码来查明故障原因，并确定故障部位的汽车应用技术。通过诊断，可以快速检测到汽车故障来提高汽车安全性和维修效率。

    USD协议诊断主要采用“问 - 答”模式，即诊断仪(Tester)像车辆指定的ECU发送请求(Request)，指定的ECU会做出相对应的响应(Response)，并将响应返回给诊断仪。从而可以依据定义好的诊断调查问卷，就可以将相对应的数据转化为相对应的问题和描述。

常用的诊断协议包括：IOS14229位于CAN应用层，还有位于CAN网络层的IOS15765协议（canTP模块）、位于数据连路层和物理层的的IOS11891UDS具体定义在14229协议中体现。

二、UDS诊断请求及其响应格式

Tester请求格式有如下几种：

ECU响应格式有：

1、肯定响应(positive)：

SID+0x40(X1XXXXXX 将bit6位置1)

2、否定响应(negative)：

7F-SID-否定响应码NRC

肯定响应抑制位：

由子服务里的最高位bit7：

Bit7=0时：需要肯定响应

Bit7=1时：禁止肯定响应

例如：ECU收到诊断仪发来的服务为$02 3E 00时，需要给出$02 7E 00的肯定响应。同样是Present服务，如果ECU收到的是$02 3E 80，则无需给出肯定响应。

否定响应不会被抑制。

常用的否定响应码有：

详细否定响应可参考：https://blog.csdn.net/weixin_47890316/article/details/106181730

否定响应码78：

       这里有两个时间参数，P2Sever和P2Sever*。当Tester给ECU发送诊断请求后，ECU需要在P2Sever时间内给出相应的响应，如果ECU当前正在处理别的任务，而不能在P2Sever的时间内给出相应的响应，那么它先在P2Sever时间内给出一个NRC为78，告诉诊断仪ECU正在忙，之后会在P2Sever*的时间内给出其它的响应报文，如果P2Sever*的时间内还是不能给出相应的肯定响应或否定响应，将继续给出78报文，直到能够正确处理请求报文。

否定响应码配置：

        否定响应码在CDD文件中设置，再导入配置工具，依据诊断调查问卷，以我做的项目中的10 01服务为例，10 01服务支持12、13、22否定响应码

三、UDS诊断服务种类

UDS诊断服务分为六大类、26种：

UDS诊断寻址方式：

        在总线上往往有着众多ECU设备，作为诊断设备既可以与所有的ECU一起沟通，也可以指定某一个ECU单独沟通。

功能寻址：可以广播诊断请求Request，同时等待总线上的ECU给与响应，一般功能寻址ID为0x7DF

物理寻址：指定发送特定诊断请求Request，等待指定ECU给与响应，此ID由OEM定义

寻址方式设置：

        服务的寻址方式在CDD文件里配置，这里以27 01服务为例， 27 01服务只支持物理寻址，不支持功能寻址。

诊断和通信管理功能单元

0x10服务(DiagnosticSessionControl)

0x11(ECUReset)                             

诊断仪请求ECU复位                   

0x3E(TesterPresent)

主要用于维持在某一模式下

0x27(SecurityAccess)

        如当写入较为重要的信息过程中，则首先需要使用27服务才能够使用写操作的诊断指令，如2E服务；

27服务否定响应

以我做的一个项目为例（需求再OEM企标中）：失败尝试次数为3次，延时时间为10S

数据传输单元

0x22(ReadDataByIdentifier)

        诊断仪请求读取由提供的DID标识的记录的当前值。该服务允许诊断仪从ECU请求由一个或多个 DID 标识的数据记录值。

例：

22 F1 90 F1 8A  读取车身号码和系统供应商标识符

0x2E(WriteDataByIdentifier)

        本服务是请求写入提供的 DID 指定的数据。该服务允许客户端在由提供的DID 指定的内部位置将数据写入服务器。数据并且可能会受到保护，也有可能不受到保护。

格式Request（请求）：2E+DID+Data

Response（响应）：6E+DID

储存数据传输功能单元

0x19(ReadDTCInformation)

        诊断仪从ECU请求诊断信息(包括DTC，捕获的数据等)。故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。

常用19服务的子服务：

0x01 （通过状态掩码读取DTC数量）

0x02 （通过状态掩码读取DTC状态）

0x04 （读取DTC快照信息）

0x06 （读取DTC扩展信息）

0x0A （读取ECU支持的所有DTC列表及其状态）

DTC状态掩码:

DTC快照信息:

        快照信息是在故障代码设置时存储的一组额外数据，对故障的维修具有辅助作用。根据使用范围的不同，快照信息可分为全局快照和局部快照。对于需存储快照信息的ECU，其必须支持全局快照信息，而选择性的支持局部快照信息。

0x14(ClearDiagnosticInformation)

诊断仪从ECU清除诊断信息（包括DTC，捕获的数据等）。完全处理该服务后，服务器应发送肯定响应。

格式：

Request:14+FF+FF+FF;   3个FF分别代表清除所有DTC高、中、低位。

Response：54 。

例程控制单元

0x31(RoutineControl)

Service 31 01 XX XX：开始执行Routine DID对应的例程；

Service 31 02 XX XX：停止运行Routine DID对应的例程；

Service 31 03 XX XX：请求Routine DID对应的例程运行结果。

四、网络层协议

单帧SF：

    如果UDS数据在网络层是单帧，那么用来表明单帧的标志N_PCI是一个字节，由于网络层标准帧的长度是8个字节，N_PCI占一个字节，UDS数据只能有7个字节。单帧的N_PCI是一个字节，结构是：

多帧：

        如果UDS数据大于7个字节，那么在网络层无法通过一个网络帧发完，就必须把数据分成多帧发送。这里以诊断仪向ECU、2E服务写入为例：

首帧（FF）数据格式：

流控帧FC：

        Tester给ECU发完首帧后，需要等待ECU回复确认信息，所以流控帧就是ECU收到首帧后回复的网络帧，流控帧的数据结构是：

如果bit1=0，代表之后再无流控帧，可以无限制发送连续帧（CF）

连续帧CF：

        连续帧的byte0的高四位是0010，低四位是连续帧的序列号，从1开始，一直到15，如果超过了15，又从1开始。当发完流控帧规定的帧数后，Tester又需要等待ECU的流控帧，确认是否继续发送，发送多少条。