UDS 19服务

UDS 19服务

0x19服务请求的子服务概览：

如下图：

0x19服务01子服务：

如下图：

发送19 01 FF回复：

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

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

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

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

0x19服务02子服务：

如下图：

发送19 02 FF回复：

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

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

0x19服务03子服务：

0x19 0x03 获取DTC快照记录ID
Subfunction=03 reportDTCSnapshotIdentification

client可以通过该子功能请求来检索所有捕获的 DTC快照记录的ID信息。服务器应返回所有已存储 DTC快照记录的 ID信息列表。服务器在响应消息中为单个 DTCSnapshot 记录放置的每个项目都应包含一个DTCRecord [包含 DTC number（high，middle，low字节）]和 DTCSnapshot record number。如果为单个 DTC 存储了多个DTCSnapshot 记录，则ECU应在每次响应时使用1个不同的DTCSnapshot record number（便于后续的查询）来表示。

ECU可支持对单个DTC存储多个DTCSnapshot records来跟踪每次DTC发生时的环境条件。DTCSnapshot records数量应被系统供应商或整车厂定义。

客户端成功发出 ClearDiagnosticInformation 请求后，应清除 DTCSnapshot 记录ID信息。 整车厂需要定义清楚删除已存储 DTC 和 DTCSnapshot 数据的规则以防内存溢出。

0x19 0x03举例：
假设
1.对于某个给定的DTC，ECU支持存储2个DTCSnapshot records；
2.ECU应表明对于DTC 123456，当前存储有2条DTCSnapshot records，DTC已发生3次（此时由于ECU内存不足，仅存储第一次和最后一次DTCSnapshot record）
3.ECU应表明DTC 789ABC，当前存储有1条DTCSnapshot record。
4.所有的DTCSnapshot records按照升序存储。

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。

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的响应报文格式如下：

0x19服务0A子服务：

如下图：

发送19 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	无效数据

《AUTOSAR谱系分解(ETAS工具链)》之总目录

《AUTOSAR谱系分解(ETAS工具链)》之总目录