UDS_1_基础知识

一. 概述

什么是UDS

UDS: Unified Diagnostic Service， 统一诊断服务。

UDS是一个在整个汽车系统上经常使用的设备维护协议。其主要遵循：ISO-15765、ISO-14229 等协议。经常应用在整车的各种ECU上面。是一个在整车ECU应用层开发常用的协议之一。

UDS用途：

可以通过诊断仪Tester连接到支持UDS服务的车辆总线系统上，来读取存在ECU内的一些信息，包括软，硬件版本，故障信息，还可以对写入一些配置参数，比如VIN 码，另外，使用bootloader 也会使用UDS中上传下载服务来进行ECU版本升级。

除了CAN总线以外，UDS也可在不同的汽车总线（例如 LIN, Flexray, 以太网）上实现，下文为基于标准CAN总线

 

UDS通讯模式：由客户端(Tester)发起请求，服务端响应客户端请求。客户端可以使用功能id和多个服务端进行通讯，即一对多模式。客户端也可以使用物理ID单独跟某个服务端进行通讯，即一对一模式。

UDS安全访问：安全访问主要是防止设备被非法访问读取重要信息和篡改设备数据，如读取汽车VIN、刷写flash程序等受限的诊断服务。

服务端Server: 每一个具备uds诊断功能的ecu，都具有三个特殊的can id，分别为功能寻址和物理寻址：功能寻址（一对多通信，仅仅支持单帧通讯）整车上规定每个ECU功能寻址 can id 相同，一般设置为0x7DF。物理寻址（一对一通讯，支持网络层所有类型通讯），即请求can id，响应can id。整车上每个ECU的物理寻址can id 都是唯一的。

客户端（Tester）与服务端（ECU）通过物理ID实现一对一的诊断通信；通过功能ID实现一对多的诊断通信；

服务端（ECU） 发送给客户端（Tester）的响应报文必须采用物理通信，即服务端（ECU）以can id为响应id响应报文发送给客户端（tester）；

 

诊断服务数据格式

UDS服务是通过诊断请求和诊断响应组成的，一股情况下是诊断仪发出诊断请求，ECU根据诊断请求执行具体诊断服务，并将结果通过诊断应发出给诊断仪。
诊断服务分为带子服务的请求和不带子服务的请求，响应分为正响应和负响应，正响应会区分对应带子服务的响应和不带子服务的响应，负响应都是一样的。 

 

诊断寻址方式

CAN 总线是广播形式的通信，即一条报文发送后，CAN网络中的所有节点都可以收到该报文，诊断仪在发送诊断请求报文后，具体是想跟网络中的哪个ECU进行诊断会话呢，这个是通过什么方式判断的?这就引出了寻址方式的概念。
寻址方式有两种，物理寻址和功能寻址。

物理寻址
是诊断仪和单个ECU之间的诊断，也就是诊断请求报文发出去后，根据报文ID，CAN网络中只会有对应的一个ECU进行诊断响应

功能寻址
是诊断仪和多个ECU之间的诊断，也就是诊断请求报文发出去后，CAN网络中支持该功能寻址报文ID的ECU，一般功能寻址报文ID为0x7DF，这些ECU都会执行诊断服务，并且发出诊断响应。
一个 ECU 内部一般会定义3条诊断报文:
诊断请求接收报文(物理寻址报文ID用户自定义同一网络中的每ECU不一样)
诊断请求接收报文(功能寻址，一般为0x7DF)
诊断应答发送报文(同一网络的每个ECU的ID不一样)

例:整车同一网络中有ECU  A，B，C，D多个节点，假设他们的物理请求消息ID为0x701，0x702，0x703，0x704，响应消息地址分别为0x70A，0x70B，0x70C，0x70D，所有ECU的功能寻址ID为Ox7DF。

物理寻址时:
0x701   0x10   0x01  (对ECU  A  进行诊断请求)
0x70A   0x50   0x01  xx  xx  xx  xx (仅 ECU A 响应)
功能寻址时:
0x7DF 0x10  0x01 (对所有ECU进行诊断请求)
0x70A  0x50   0x01  xx  xx  xx  xx (ECU A响应)
0x70B  0x50   0x01  xx  xх  хx  хх (ECU B响应)
0x70C  0x50   0x01  xx  xx  xx xx  (ECU C响应)
0x70D 0x50    0x01  xx  xx  xx  xх    (ECU D响应)

为什么要设计功能寻址

场景1）需要对某个ECU进行刷写（bootload操作）

因为刷写（bootload操作），需要两个前提：

1；关闭网络上的所有通讯

2：刷写（bootload操作）具体ECU的过程中，会对被刷写（bootload操作）产生干扰，导致误报DTC

对应的解决方法，调用uds中的0x28（通讯控制) ，和0x85（DTC控制）服务。

如果依然采用物理寻址，一个个去设置，显得麻烦，实际车上，一个网络上会挂载10个以上的ECU，如果采用物理寻址的方法，一个个设置，就非常麻烦和低效。

如果采用功能寻址，就很方便了。

场景2）整车读取某些数据0x22服务

需要说明：uds设计过程中，没有要求DID或参数的唯一性要求，如;F1 98 在ECU1中可以用来读取，软件版本。在ECU2中同样也可以。

于是主机厂的工程师们，只要采用功能寻址，发送一条DID为 F1 98的报文，就可以读取网络中所有ECU的软件版本。

注意：客户端client 采用功能寻址 时，不同的ECU采用物理回复的ID，进行回复

如：诊断客户端   0x 668 03 22 F1 98

          ECU1应答：0x658 07 62 F1 98 90 90 90 90(90就是对应ascil码的软件版本)

          ECU2应答：0x668 07 62 F1 98 91 91 91 91(91就是对应ascil码的软件版本)

          ECU3应答：0x678 07 62 F1 98 92 92 92 92(92就是对应ascil码的软件版本)

需要注意的是：ECU回复依然是采用的是，物理地址回复。

 

UDS 常用诊断服务

诊断会话控制 DiagnosticSessionControl(0x10)
ECU 复位ECUReset(0x11)
安全访间 SecurityAccess(0x27)
通讯控制 CommunicationControl(0x28)
待机在线TesterPresent(0x3E)
诊断故障码设置控制 ControlDTCSetting(0x85)
读DI数据 ReadDataByIdentifier(0x22)
写DID数据WriteDataByIdentifier(0x2E)
清除故障码ClearDiagnosticInformation(0x14)
读故障码信息 ReadDTCInformation(0x19)
通过 DID 控制输入输出Input0utputControlByIdentifier(0x2F)
例程控制 RoutineControl(0x31)
请求下载 RequestDownload(0x34)
传输数据 TransferData(0x36)
请求数据传输退出RequestTransferExit(0x37)
其他不常用的服务请参考IS014229文档

诊断会话控制 DiagnosticSessionControl(0x10)

会话模式有默认会话模式(default session)和非默认会话模式(non-defaultsession)，非默认会话模式包含编程会话模式 (ProgrammingSession)、拓展诊断会话模式 (extendedDiagnosticSession)及其余会话模式。会话模式可以理解为诊断的功能模式，即在不同的会话模式下，能够支持不同的诊断功能，如在默认会话模式下，一般情况下不允许支持写服务(WriteDataByIdentifier0x2E)，也不允许支持请求下载服务(RequestDownload0x34)，而在拓展诊断会话模式下，就允许支持写服务(WriteDataByIdentifier0x2E)，在编程会话模式下，就可以支持(RequestDownload0x34)。
DiagnosticSessionControl(0x10)为控制切换各个会话模式的服务

如下图，为三种常用会话模式的转换图

默认会话模式(default session 0x01)
编程会话模式(ProgrammingSession 0x02)
拓展诊断会话模式(extendedDiagnosticSession0x03

v 

二. 网络层

2.1 网络层_帧类型

对于网络层来说，报文分为单帧和多帧，单帧只有一种 N_PCI，即单帧；多帧有三种 N_PCI，即首帧、流控制帧、连续帧。

2.2 网络层_单帧SF 

单帧顾名思义就是一帧 can 报文就可以处理完 uds 服务

SF_DL范围如下图所示：

如果网络层接收到单帧的SF_DL范围不在1~7之间，网络层应当忽略该 SF N_PDU 

2.3 网络层_首帧FF

发送方发送N_Data数据过长时，则需要拆分成多帧报文，被拆分后的报文需要通过多个N_PDU来发送，而接收方接收到多个N_PDU信息后进行重组。发送方发送多帧时，需要先发送首帧来告知接收方有多少字节数要发送到接收方

FF_DL范围如下图所示： 

1.如果网络层接收到首帧的FF_DL范围小于8并且使用标准地址，或者小于7并且使用扩展地址或者混合地址时，网络层应当忽略该首帧并且不必发送一个流控帧FC N_PDU。

2.如果网络层接收到的首帧FF_DL大于接收方缓冲区时，应当被认为错误情况。网络层应当放弃该信息的接收。并且发送包含参数FlowStatus = Overflow的 流控帧FC N_PDU。

2.4 网络层_流控帧FC

 

UDS多帧通讯时：

从上图可知，can 报文首字节 byte1 高 4 bit 为3时表示该帧为流控帧 FC。byte1低 4bit 为流状态FS，byte2 为块大小（允许一次可连续发送连续帧CF的次数），byte3为发送方发送连续帧CF与连续帧CF间的最小间隔时间 

流状态FS

发送方接收到流控帧FC的流状态FS来判断是否继续发送信息

块大小BS 

允许发送方一次最大可发送连续帧 CF 次数，即一次发送连续帧帧数要小于等于块大小 BS。当块大小为0时，发送方可无限发送连续帧直至信息发送完毕，再无流控帧FC。

间隔时间STmin

STmin 是发送方发送连续帧CF与连续帧CF间的最小间隔时间，即STmin的度量是在一个连续帧发送完开始到请求下一个连续帧时的间隔时间。

 网络层_连续帧CF

发送方发送首帧FF，然后接收到接收方的流控帧FC后，若条件允许可继续发送信息，则需根据连续帧CF的控制信息格式来发送信息。

从上图可知，CAN报文首字节byte1高4bit为2时表示该帧为连续帧CF。byte1低4bit 为连续帧的顺序号SN 

顺序号SN

SN开始于0， 第一个流控帧FC后的连续帧SN设置为1；同一拆分信息上，每一个新增的连续帧顺序号SN增1；连续帧顺序号SN的值不受流控帧的影响；当连续帧顺序号SN值为0xF时，下一个连续帧中将顺序号SN重置为0。

三. 应用层协议

请求服务标识符SI

类型：1字节无符号整数
范围：00-FF
请求服务的ID：X0XXXXXX（bit6为0）
示例：ReadDTCInformation服务Request 0x19 00011001

肯定响应服务标识符SI

类型：1字节无符号整数
范围：00-FF
肯定响应服务的ID：X1XXXXXX（bit6为1）
肯定响应服务的ID = 请求服务的ID + 0x40
示例：ReadDTCInformation服务Response 0x59 01011001

否定响应服务标识符NR_SI

类型：1字节无符号整数
范围：7F

网络层报文收发举例

单帧举例：

02 10 03 00 00 00 00 00
06 50 03 00 32 01 F4 00

多帧举例 

网络层时间参数 

网络层定义了N_Ar、N_As、N_Br、N_Bs、N_Cr、N_Cs六个时间参数。

 

N_As超时：发送方没有及时发送N_PDU。

N_Ar超时：接收方没有及时发送N_PDU。

N_Bs超时：发送方没有接收到流控帧。

N_Cr超时：接收方没有收到连续帧。

N_Br超时：接收方没有发出流控帧。

N_Cs：即STmin，发送两个连续帧需要等待的最短时间，N_Cr最大1000ms。

应用层协议 

UDS服务格式 

Diagnostic Request格式：

Diagnostic Request有两种类型：第一种为 SID + sub function + parameter，第二种为 SID + parameter；注：parameter字节数 >= 0；

SID的长度固定为1个字节，代表了这条诊断命令执行的什么功能。sub-function的长度也是1个字节，它通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务。而后面的parameter则根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。parameter的一个重要应用是作为标识符，标识诊断请求要读出的数据内容。

注意：其实sub-function严格来说是7个bit，而不是1个byte，因为它的最高位bit被用于抑制正响应（suppress positive response, SPR），如果这个bit被置1，则ECU不会给出正响应（positive response）； 如果这个bit被置0，则ECU会给出正响应。这样做的目的是可以告诉ECU不要发不必要的response，从而节约通信资源。

Diagnostic Response格式：

Diagnostic Response 分为两类。

第一类为positive response意味着诊断仪发过来的诊断请求被执行了。格式：response SID + sub function + parameter 或 response SID + parameter 。注：parameter字节数 >= 0； response SID 为诊断请求的SID + 0x40；如下如所示：

第二类为negative response则意味着当前ECU因为某种原因无法执行诊断仪发过来的诊断请求，而无法执行的原因则存在于negative response的报文中。格式：negative response SID + request SID + negative response code； negative response 固定3个字节，negative response SID固定为：7F， request SID为诊断请求的SID， negative response code为负响应的原因；negative response code如下图所示：