汽车诊断服务协议（UDS）基本原理

汽车诊断服务协议（UDS）基本原理

一、UDS诊断方法

现代汽车内部普遍使用了数十个以上的控制器（Electronic Control Unit，ECU），用于控制发动机、变速器、底盘、仪表、空调、灯光、车窗座椅、车锁等部件，从而使得车辆具有良好的动力性、安全性和舒适性。但是大量电子设备的使用也造成了车辆电气故障排除的复杂性，因此大多数ECU都装有自诊断系统（On-Board Diagnostics, OBD），能够及时发现传感器、执行器、ECU和通信网络产生的电气故障，以大幅提高故障诊断的效率。当OBD检测到故障时，会生成相应的故障码信息，并点亮故障灯。此时，把诊断仪插入OBD接口，即可以和OBD系统进行通信，从而获取故障码和相关信号流等数据，实现快速定位故障源和故障类型。

附赠自动驾驶最全的学习资料和量产经验：链接

由于全球有大量的汽车和诊断仪生产商，所以诊断仪和OBD系统之间的通信都遵循统一的汽车诊断服务协议（Unified Diagnostic Services，UDS），以实现诊断仪和OBD系统之间诊断数据的有效传输，如图1所示：

图1 UDS功能示意图

UDS把所有的OBD诊断功能规范成26种诊断服务，归为6大类，每种服务用SID进行编号，如表1所示：

表1 UDS诊断服务类型

从表中可知，这些服务涵盖了ECU数据流的读取、ECU故障码读取与清除、ECU程序更新等OBD诊断功能。

为了便于描述，把通信的双方分别定义为客户端和服务端。诊断仪一般充当客户端角色，ECU一般充当服务端角色。客户端和服务端采用“请求服务—响应服务”的方式完成一次故障诊断服务，既首先由客户端向服务端发出诊断服务请求消息，服务端接收到请求消息后再给出诊断服务响应消息。服务响应消息又分为正响应和负响应两种，分别对应服务端接收服务请求和拒绝服务请求两种情况。

UDS服务请求消息和服务响应消息都以报文的形式呈现。UDS明确定义了服务请求报文的基本格式为“SID+其他参数“，正响应报文的基本格式为“[SID+0x40]+其他参数“，负响应报文的格式为“0x7F+其他参数“。图2所示的是一个读取油门开度信息的例子（其报文内容只作为解说用，不具有真实意义）。

图2 读取油门开度服务过程示意图

图中可见，诊断仪向ECU发出了请求报文“0x22 0x01 0x0a"，该报文中的第一个数据“0x22”表示当前请求的服务为SID为22的“通过ID读数据”服务，该报文中的“0x01 0x0a”表示要读的数据的ID为“010a”，其含义为油门开度，由汽车生产商指定。如果OBD给出了正响应，则发送报文“0x62 0x01 0x0a 0x00 0x23”，该报文的第一个数据值”0x62”是0x22加上0x40的结果，后面第二、三个数据为请求报文中指定的ID值“0x01 0x0a”，第四、五个数据 “0x00 0x23”为当前油门开度值“0x23（十进制为35）”，表示当前发动机油门开度为35%。如果OBD给出了负响应，则发送报文“0x7f 0x22 0x11”。该报文的第一个数据值为“0x7f”，表示拒绝服务，后面第二个数据为被拒绝的服务的SID值“0x22”，第三个数据为拒绝服务的原因，该值由UDS定义，“0x11”表示当前服务不支持。

UDS协议定义了所有服务的报文格式和参数含义（见ISO 14229-1），诊断仪和OBD都必须遵循该协议，才能正确完成各种诊断服务。参照ISO网络通信体系，该部分协议称为UDS应用层协议。

二、UDS传输方法

诊断仪和OBD生成的UDS报文需要通过通信网络进行传输。目前汽车ECU普遍使用CAN总线进行数据通信，因此UDS报文必须加载到CAN帧中才能发送。但是每个CAN帧的最大传输数据量只有8个字节，而UDS报文的数据量是根据服务内容进行变化的。最小的UDS报文有2个字节，大的UDS报文可以达到几千个字节以上。这意味着超过8个字节的UDS报文需要多个CAN帧才能完成传输。为了保证报文传输的有效性和可靠性，需要定义UDS报文在CAN总线上的传输协议（ISO-15765-2），其一般称为UDS的网络层或传输层协议。

UDS定义了四种类型的CAN帧来传输UDS报文，分别是单帧（Single Frame, SF）、首帧（First Frame, FF）、 连续帧（Consecutive Frame, CF）和流控帧（Flow Control, FC）。以上四种CAN帧的内容格式如表2所示：

表2 UDS CAN帧格式

从表可知，每种CAN帧都占用第一个字节的高4位来存放帧类型数据（单帧是0、首帧是1、连续帧是2、流控帧是3）。单帧的第一个字节的低4位存放了该帧传输的报文数据量，剩余字节存放UDS报文数据。以图2中传输的请求报文 “0x22 0x01 0x0a”和正响应报文“0x62 0x01 0xa 0x0 0x23”为例，其单帧数据区的内容如图3所示：

图3 单帧数据区内容（16进制数）示意图

可以看到，单帧最多可以传输数据量为7个字节的UDS报文，不足7个字节则用约定的数据进行填充；当要发送的报文的数据量大于7个字节时，就需要使用首帧、连续帧和流控帧了，其运用机制如图4所示：

图4 首帧、连续帧和流控帧运行机制示意图

从图中可知，发送端首先会把UDS报文数据填入首帧，填满后发出；接收端接收到首帧后回复流控帧，其作用主要是控制后续报文数据的发送速率；发送端接收到流控帧后会把UDS报文剩余的数据依次填入若干（BS值）个连续帧，并按序发出，以此重复直到UDS报文数据全部发送完。

首帧的第一个字节的低4位和第二个字节存放了需要传输的UDS报文总数据量，剩余字节存放UDS报文前6个数据。

流控帧的第一个字节的低4位存放FlowStatus(FS)值，该值如为0表示可以继续发送后续连续帧；如为1表示暂停发送后续连续帧；如为2表示接收端已经溢出。流控帧的第二个字节存放BlockSize(BS)值，该值如为0表示接收端后续将不会再发送流控帧，发送端直接发送余下的所有连续帧；如为01-0xff之间的某个值，表示发送端在连续发送了该值数量的连续帧个数后，需要等待接收方再次发送流控帧。流控帧的第三个字节存放Stmin值，该值为两个连续帧传输的时间间隔，单位ms。流控帧的剩余字节存放填充数据。

连续帧的第一个字节的低4位存放连续帧的序号SN值。第一个连续帧的序号为1，后续连续帧的序号依次加1，直到0xf后，后续连续帧的SN值从0开始依次加1。

以传输17位VIN码为例：

（1） 诊断仪向ECU发出“0x22 0xf1 0x90”的UDS报文，请求读取车辆VIN码；

（2） ECU收到请求后回复正响应报文“0x62 0xf1 0x90 0x57 0x30 0x4c 0x30 0x30 0x30 0x30 0x34 0x33 0x4d 0x42 0x35 0x34 0x31 0x33 0x32 0x36”，共20个字节的数据量。因此ECU先发出首帧，其数据区内容为如图5所示：

图5 首帧数据区内容（16进制数）示意图

（3） 诊断仪收到首帧后，向ECU回复流控帧，其数据区内容为如图6所示：

图6 流控帧数据区内容（16进制数）示意图

（4） ECU收到流控帧后，会依次发送剩余2个连续帧，其数据区内容为如图7所示：

图7 连续帧数据区内容（16进制数）示意图

三、UDS时间管理

UDS在传输的过程中，可能会遇到因网络故障或节点故障导致的通信延迟或中断的情况，因此UDS定义了通信时间管理机制来保证其工作的时效性，并基于设定的时间参数来实现。以下列出几个基本的时间参数：

（1）UDS应用层时间参数

— P2 Client：诊断仪成功发送请求报文之后，接收到ECU响应报文的时间间隔；

— P2 Server：ECU接收到诊断报文请求后，发出回复响应报文的时间间隔；

如图8所示：

图8 P2 Client、P2 Server时间参数示意图

（2）UDS网络层时间参数

— N_As：发送端发送一帧所需的时间，若超时表明发送端没有成功发出帧；

— N_Ar： 接收端发送一帧所需的时间，若超时表明接收端没有成功发出帧；

— N_Bs：发送端等待成功接收流控帧的时间间隔，若超时表明发送端没有成功接收流控帧；

— N_Br：接收端等待发送流控帧的时间间隔，若超时表明接收端没有成功发送流控帧；

— N_Cs：发送端等待发送一连续帧的时间间隔，既stmin；

— N_Cr： 接收端等待成功接收一连续帧的时间间隔，若超时表明接收端没有成功接收连续帧；

如图9所示：

图9 网络层时间参数示意图

UDS协议明确给出了各个时间参数的取值范围，具体取值可以根据网络环境、节点速率和诊断应用需求进行调整。