UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（例如CAN, LIN, Flexray, Ethernet 和 K-line）上实现。UDS协议的应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。

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，回复的是一个声明。

肯定响应和否定响应的形式一定要熟记。

常用服务介绍

UDS的26种服务中，有7种很重要。它们分别是：

• $10 Diagnostic Session Control（诊断会话），
• $14 Clear Diagnostic Information（清除诊断信息），
• $19 Read DTC Information，
• $22 Read Data By Identifier（通过ID读数据），
• $27 Security Access（安全访问），
• $2E Write Data By Identifier（通过ID写数据），
• $3E Tester Present（待机握手）。

下面对这7个服务进行解读。

$10诊断会话

$10包含3个子功能，

• 01 Default，
• 02 Programming，
• 03 Extended，

ECU上电时，进入的是默认会话（Default）。如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。

报文包含4种类型，即

• SID，
• SID+SF（Sub-function），
• SID+DID（Data Identifier）（读写用），
• SID+SF+DID。

NRC：Negative Response Code（否定响应码)。如果ECU拒绝了一个请求，它会回应一个NRC。不同的NRC有不同的含义。

例子：以CAN总线网络举例。

八个数据字节，第一字节被网络层占用。

• 请求（Request）:

02 10 02 xx xx xx xx xx

02中的0代表网络层单帧SF，2代表 数据域有2个字节；10是SID，02是子功能。

• 肯定响应:

02 50 02 xx xx xx xx xx

02同上，10+40表示对SID的肯定回复，02是子功能。

• 否定响应:

03 7F 10 22 xx xx xx xx；

03同上，7F表示否定响应，10是SID，22是NRC。

$3E待机握手

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

例子：

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

$27安全访问

27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。

比如下面的例子，2n-1是某个子服务，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成k1（不一定是1个字节），那么发送请求，27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时，解锁（Unlocked）成功。

• 例子：

Rx： 02 27 05 00 00 00 00 00 安全访问，05子功能
Tx： 07 67 05 08 27 11 F0 77 肯定响应，回复了对应安全级别的种子
Rx： 06 27 06 FF FF FF FF 00 发送密钥，4个FF。注意06是与05成对使用的。
Tx： 03 7F 27 78 00 00 00 00 否定响应，7F+27+NRC
Tx： 02 67 06 00 00 00 00 00 肯定响应，通过安全校验

$22读数据

$22读数据，
Request（请求）：

22+DID（Data Identifier，通常是两个字节）

Response（响应）：

62+DID+Data

DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符，0xF187就是车厂备件号数据标识符，0xF188就是车厂ECU软件号码数据ID，0xF189就是车厂ECU软件版本号数据标识符。

$2E写数据

$22写数据，
Request（请求）：

2E+DID+Data

Response（响应）：

6E+DID

注意，比如0xF186这个DID不支持直接写入数据，需要用$10来进行会话转换。也就是说，对于写数据的请求，一般来说需要在一个非默认会话，或解锁的状态下才能进行。

$19 读DTC

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

故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。

DTCHighByte	DTCMiddleByte	DTCLowByte	DTCStatus
Byte 1	Byte 2	Byte 3	Byte 4

$19 拥有28个子服务（Sub-Function）。常用的子服务有02（通过DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读ECU支持的所有DTC数据）。

$14清除DTC

清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。

Request：14+FF+FF+FF；
Response：54 。

诊断报文解析

UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构

CAN Message =CAN ID + CAN DATA

根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data.

网络层 PDU（协议数据单元）PCI（协议控制信息）格式：具体如下图所示：

帧类型	bit7-4	bit3-0	Byte 2	Byte 3
单帧	PCItype=0	SF_DL	N/A	N/A
首帧	PCItype=1	FF_DL	FF_DL	N/A
连续帧	PCItype=2	SN	N/A	N/A
流控帧	PCItype=3	FS	BS	ST_min

综上所述，N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节，N_DATA值主要集中在后面7位字节。其中，

• SF_DL 代表单帧中数据字节数（取值0-7），
• FF_DL代表 连续帧中的数据字节数(12bit可表四8~4095)，
• SN代表此帧为连续帧中的第几帧，（0、1、2...E、F、0、1...）
• FS流控制帧，有三种状态：继续发送0、保持等待1、数据溢出2
• BS规定发送端允许持续传输连续帧数目的最大值（0~255），
• STmin限定连续帧相互之间所允许的最小时间间隔。

先面用连个例子进行说明，请参考！

例子 1--- 单帧的数据传输与接收

[图片上传失败...(image-b66bab-1538824826939)]

数据发送： 02 27 09
数据反馈： 03 7F 27 7E ---==否定的响应==（Negative Response），回复==7F+SID+NRC==，回复的是一个声明

数据发送： 02 10 40
数据反馈： 06 50 40 00 32 01 F4 ---==肯定的响应==（Positive Response），回复[==SID+0x40==]，就是请求10，响应40；回复的是一组数据

由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个字节的低四位，02，03，02，06代表的为此帧数据含有几个字节，多余的数据位都用 00或者AA行填充。

例子2 --- 多帧的数据接收与传输

[图片上传失败...(image-b5e84b-1538824826939)]

数据发送：

• 06 19 04 00 01 00 00 00

数据反馈：

• 10 1E 59 04 00 01 00 27
• 30 00 00 00 00 00 00 00
• 21 00 0B FF FF FF FF FF
• 22 FF FF FF FF FF FF FF
• 23 FF FF FF FF FF FF FF
• 24 FF FF FF AA AA AA AA

数据发送为单帧，所以06代表发送的数据中含有6个字节，

回复为Positive Response，为连续帧。

• 10中的1代表连续帧的首帧，==01E代表此连续帧含有30个字节==，
• 30代表此连续帧的流控制帧，
• 21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。