UDS（统一诊断服务）的理解——0x19服务

• 简述UDS、0x19服务

UDS可以简单理解为一套完整的通讯协议框架，其目的在于规范各种行车电脑和ECU之间的通讯。ISO 15765-2规定了UDS的网络层，ISO14229规定UDS的应用层。

UDS可以在不同的汽车总线上实现，但本文重点讨论UDS on CAN的诊断协议。

UDS包含一系列服务，每种服务都有自己独立的ID，即SID（Service Identifier），0x19服务其实是读取DTC信息的服务，其SID为0x19。

• 网络层

经典的CAN数据链路层最大能够支持单帧8个字节的数据传输，但是UDS协议不单单只是为了CAN总线而设计的，避免不了传输数据流的情况，ISO 15762-2的诞生就是为了能够安全、快速的将多个字节通过经典CAN来进行传输。

总的来说ISO 15762-2是基于经典CAN通讯来实现的，它只不过是将数据帧分成四类方便管理分别为：单帧、首帧、流控帧、连续帧。

1. 1. 单帧

字节1		字节2	字节3
7-4位	3-0位
帧类型	SF_DL	N/A	N/A

SE_DL值（Hex）	说明
0	保留，如果是则忽略该帧
1~6	单帧数据长度
7	单帧数据长度 SE_DL=7时，只允许使用标准地址，如果使用扩展地址则忽略该帧
8~F	无效，如果是则忽略该帧

对于未拆分的信息，网络层提供了一个优化的网络协议，即将信息长度值仅放置在第一个字节的后四位。单帧支持在单个CAN 帧中的信息传输。

帧类型等于0时表示单帧，SF_DL代表从第2个字节开始（包括第二个字节）有多少个有效数据，表中“N/A”即是UDS应用层的数据。

1. 1. 首帧

字节1		字节2	字节3
7-4位	3-0位
帧类型	FF_DL		N/A

FF_DL值（Hex）	说明
0~6	无效，是则忽略该帧
7	表示该条信息中（包括首帧和连续帧）的有效数据字节的个数 只允许扩展地址或混合地址，否则忽略该帧
8~FFF	表示该条信息中（包括首帧和连续帧）的有效数据字节的个数

      

首帧只支持一条信息无法在单个CAN 帧中传输时使用。

1. 1. 流控帧

字节1		字节2	字节3
7-4位	3-0位
帧类型	FS	BS	STmin

FS值（Hex）	说明
0	促使发送方继续发送连续帧，意味着接收者准备好接收最大BS各连续帧
1	促使发送方等待新的流控帧到来，如果有，则发送方要重新设置定时器。
3	促使发送方终止信息的发送，仅能在首帧接收后并且判断数据长度将要溢出时使用
3~F	保留

BS值（Hex）	说明
00	指示发送者在发送连续帧时不再传递流控帧，发送者应该不停的发送剩下的连续帧。
01~FF	指示发送者发送最大数目的连续帧，是连续帧的帧数不是字节数，之前口述有误

STmin值（Hex）	说明
00~7F	相邻两个连续帧之间的最小时间间隔 范围0~127ms（绝对单位）
80~F0	保留，如果是则选择127ms
F1~F9	相邻两个连续帧之间的最小时间间隔 范围100~900us （最小细分100us）
FA~FF	保留，如果是则选择127ms

流控帧一般是客户端发送给服务器（仅包括0x19服务）。

1. 1. 连续帧

字节1		字节2	字节3
7-4位	3-0位
帧类型	SN	N/A	N/A

SN为连续帧编号，开始于“0”，在同一个数据流中每新增一个连续帧则SN+1,当到达值“15”时在下一个连续帧中置为“0”，第一个流控帧后的编号为“1”。

当接收者发现连续帧编号错误时，信息的接收将被终止。

1. 1. 在0x19服务中一般的使用顺序

单帧的使用情况	多帧的使用情况1	多帧的使用情况2
客户端以单帧的形式向服务器请求0x19服务01子服务	客户端以单帧的形式向服务器请求0x19服务02子服务	同多帧的使用情况1
服务器收到请求（如果符合单帧的规范）以单帧的形式回给客户端相应的信息	服务器收到请求，发现将要回复的数据量大于单帧要求的最大数据量，此时向客户端回复首帧	同多帧的使用情况1
结束	客户端收到首帧后，判断缓存空间是否大于首帧包含的该条数据流的长度，如果是则向服务器发送流控帧，使服务器一次性全部将数据送出	客户端收到首帧后，判断缓存空间是否大于首帧包含的该条数据流的长度，如果不是，向服务器发送流控帧，使服务器只发送部分数据流
	服务器收到流控帧后，根据客户端要求，将数据以连续帧的形式送出，直到送完为止	服务器收到流控帧后，根据客户端的要求向客户端回复定量的连续帧，完成后，等待下一个流控帧的到来
	结束	客户端收到部分数据流处理完毕后，再次向服务器发送流控帧，使服务器再次发送
		直到全部数据传输完毕
		结束

• 应用层
  1. 0x19服务01子服务

通过状态掩码去查找与其相匹配的故障个数。

通过该服务诊断仪能够请求ECU中DTC状态与DTC状态掩码相匹配的故障码个数。如果某一个故障码的实际状态位为“1”，并且DTC状态掩码中的相应位也为“1”，那么就认为该故障码的状态与DTC状态掩码相匹配（即：如果DTC状态掩码字节与DTC实际状态字节进行逻辑“位与”运算后的结果为非零值，那么两者就相匹配）；此时则将故障数+1。如果客户端定义了一个状态掩码，其中包含ECU不支持的位，那么ECU仅使用本身支持的位进行处理故障信息。请求的格式如下：

收到请求后ECU响应的格式如下：

DTC状态掩码参数包含8个DTC状态位，其位定义如下：

1. 1. 0x19服务02子服务

按照定义的状态掩码的形式去查找匹配的故障，将匹配的DTC标识符（3个字节）、DTC状态（1个字节）信息返回。01子服务只统计与状态掩码相匹配的DTC个数，02子服务则会将这些匹配的DTC信息返回。请求格式如下：

收到请求后，ECU的响应报文格式如下：

1. 1. 0x19服务04子服务

为了方便找到故障的原因，在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因。请求格式如下：

其中，DTCSnapshotRecordNumber表示DTC快照记录码，占一个字节，表示特定的 DTC快照数据记录编号。例如当我们需要记录某个DTC第一次发生（假设用1表示）和最近一次发生的快照数据时（假设用2表示）；那么当DTCSnapshotRecordNumber为1时，则表示请求该DTC第一次发生时的快照信息。

如果ECU支持多个DTC快照数据记录，那么该纪录码应使用0x01~0xFE范围内的数值。当该参数值为FF（Hex）时，要求ECU一次性报告所有存储的DTC快照数据记录。

收到请求后，ECU的响应报文格式如下：

如上，响应报文中DTCSnapshotRecordNumber表示返回的是该DTC的哪一个快照记录；DTCSnapshotRecordNumberOfIdentifiers表示快照信息中定义的成员量；如定义的快照数据有四项信息，则该值为4。

1. 1. 0x19服务06子服务

扩展信息，用于记录故障的一些其他信息，比如故障发生的次数、老化次数、已老化次数等。06服务就是用于请求指定故障码（DTC）的扩展信息。请求格式如下：

DTCExtDataRecordNumber值（Hex）	说明
0	不可用（保留）
01~8F	请求服务器报告汽车制造商指定存储的DTCExtendedData（DTC扩展数据）记录。
90~EF	请求服务器报告法定OBD存储的DTCExtendedData（DTC扩展数据）记录。
F0~FD	保留
FE	请求服务器报告单条响应消息中所有法定OBD存储的DTCExtendedData（DTC扩展数据）记录。
FF	请求服务器报告单条响应消息中所有存储的DTCExtendedData（DTC扩展数据）记录。

收到请求后，ECU的响应报文格式如下：

1. 1. 0x19服务0A子服务

该服务用于请求所有支持的DTC信息（3个字节的DTC标识符加1个字节的DTC状态位），其响应报文与02服务一致；但要区分，该服务返回的是所有DTC的信息；而02服务是返回与请求时状态掩码相与不为“0”的DTC信息。请求格式如下：

收到请求后，ECU的响应报文格式如下：

• UDS报文解读举例

以0x19服务06子服务为例解读真正在CAN总线上的UDS报文。

客户端向服务器请求：06 19 06 XX XX XX FF 00

06	前四位“0”，表示该帧数据为单帧数据；后四位“6”表示该帧中有六个有效的字节：“19 06 XX XX XX FF”
19 06	表示0x19服务06子服务
XX XX XX	代表DTC码
FF	DTCExtDataRecordNumber=0xFF；表示向服务器获取该DTC的所有的扩展数据
00	无效字节

服务器向客户端回复：10 11 59 06 XX XX XX 10

1	第一个字节的前四位表示该帧为首帧，意味着服务器将等待客户端回复流控帧，以继续发送其余数据
0 11	第一个字节的后四位和第二个字节的八个位组成的12位编码为当前数据流的总字节数，此处表示有当前数据流中有17个有效字节
59 06	表示0x19服务06子服务的响应
XX XX XX	DTC码和客户端请求的DTC码一致
10	当前DTC的状态位

客户端收到后回复流控帧：30 00 00 00 00 00 00 00

3	表示当前是流控帧
0	促使服务器继续发送数据
00	该字节表示允许服务器下一次最多发送多少个连续帧，如果为“0”则将所有数据全部发送
00	指定服务器发送连续帧时的最小时间间隔，当前为“0ms”
00 00 00 00 00	无效数据

服务器收到后回复了两帧数据：21 10 00 00 00 00 20 00

                            22 00 30 01 00 00 00 00

21和22	为两帧数据的帧头，前四位表示当前是连续帧，后四位表示在收到当前流控帧之后的连续帧编号
10 00 00 00 00 20 00 00 30 01 00	三组扩展信息的数据，“10”、“20”、“30”为DTCExtDataRecordNumber（自定义），其每个DTCExtDataRecordNumber的长度也是自定义
00 00 00	无效数据

在word中排版排的好好的，懒得整了。

word文档链接，需要自取：UDS（统一诊断服务）的理解——0x19服务.docx-嵌入式文档类资源-CSDN下载

————————————————

版权声明：本文部分参照CSDN博主「第55号小白鸭」的原创文章

原文链接：https://blog.csdn.net/weixin_44536482/article/details/93090417