UDS诊断服务基础详解之三19服务续~

已于 2023-10-10 11:43:44 修改
阅读量3.7k 收藏 48
点赞数 4
分类专栏： UDS诊断基础详解 文章标签： java 开发语言
于 2023-09-21 10:15:54 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/DiR_323/article/details/133080567
版权

目录

1 概述

2 19 02服务

  2.1 请求格式   

2.2 正响应格式

2.3 举例说明

3 19 04服务

3.1 请求格式

3.2 正响应格式

3.3 举例说明

4 19 06服务 

4.1 请求格式

4.2 正响应格式

4.3 举例说明

5 19 0A服务

5.1 请求格式

5.2 正响应格式

5.3 举例说明

6 总结

1 概述

     前面一个章节已经详细介绍了19服务涉及到的DTC、状态位以及19 01服务的使用，这里不再赘述。本章节将着重介绍19服务剩下的几个比较常用的子服务，分别是19 02,19 04,19 06以及19 0A服务。

2 19 02服务

     19 02该子服务为根据状态掩码报告对应的DTC。

  2.1 请求格式   

      19 02服务的请求格式如下：

字节参数名称参数约定数值（Hex）
Byte1Request Service Identifier
请求ID		M19
Byte2SubFunction=ReportDTCByStatusMask
子功能=报告匹配状态掩码的DTC故障码		M02
Byte3DTCStatusMask
DTC状态掩码		M00-FF

图1:19 02服务请求格式 

2.2 正响应格式

       19 02服务的正响应格式如下：

字节参数名称参数约定数值（Hex）
Byte1Positive Response Service Identifier
肯定响应回复ID		M59
Byte2SubFunction=ReportDTCByStatusMask
子功能=报告匹配状态掩码的DTC故障码		M02
Byte3DTCStatusAvailabilityMask
当前ECU支持的状态掩码		M01-FF

Byte4
Byte5
Byte6
Byte7
Byte8
Byte9
Byte10
Byte11
.
.
.
.
Byte(n-3)
Byte(n-2)
Byte(n-1)
Byte(n)		DTCAndStatusRecord[]=
DTCHighByte#1
DTCMiddleByte#1
DTCLowByte#1
StatusOfDTC#1
DTCHighByte#2
DTCMiddleByte#2
DTCLowByte#2
StatusOfDTC#2




DTCHighByte#m
DTCMiddleByte#m
DTCLowByte#m
StatusOfDTC#m
C1
C1
C1
C1
C2
C2
C2
C2




CM
CM
CM
CM
00-FF
00-FF
00-FF
00-FF
00-FF
00-FF
00-FF
00-FF




00-FF
00-FF
00-FF
00-FF

图2:19 02服务肯定响应格式 

2.3 举例说明

       请求：03 19 02 09 AA AA AA AA 

       响应（首帧）：10 1B 59 02 09 91 B6 12

       请求（发送流控帧）：30 00 00 AA AA AA AA  AA

       响应（连续帧）：21 08 A4 13 15 08  D3 18 

       响应（连续帧）：22 31 08 A6 43 14 08 A7 

       响应（连续帧）：23 32 21 08 A8 90 13 08

       说明：该例子响应使用了首帧、连续帧以及流控帧，响应总共传输的数据为（1B=27）个字节，注意，首帧有效的字节个数为6个，连续帧有效的字节个数为7个。

3 19 04服务

     19 04该子服务为根据DTC号报告相关的快照信息，一般会根据主机厂需求记录上车速，电源电压，车辆点火状态，里程，时间等参数，参数的定义会在诊断调查表中明确。

3.1 请求格式

     19 04服务请求格式如下：

字节参数名称参数约定数值（Hex）
Byte1Request Service Identifier
请求ID		M19
Byte2SubFunction=ReportDTCSnapshotRecordByDTCNumber
子功能=根据DTC号报告相应的快照信息		M04
Byte3DTCMaskRecord[]=
DTCHighByte		M00-FF
Byte4DTCMiddleByteM00-FF
Byte5DTCLowByteM00-FF
Byte6DTCSnapshotRecordNumber
DTC快照编号		M00-FF

      备注：当请求格式的第六个字节的 DTCSnapshotRecordNumber为FF时，表示读取当前DTC对应的所有快照组数据。

3.2 正响应格式

     19 04 服务正响应格式如下：

字节参数名称参数约定数值（Hex）
Byte1Positive Response Service Identifier
肯定响应回复ID		M59
Byte2SubFunction=ReportDTCSnapshotRecordByDTCNumber
子功能=根据DTC号报告相应的快照信息		M04
Byte3DTCMaskRecord[]=
DTCHighByte
DTC高字节		M00-FF
Byte4DTCMiddleByte
DTC中字节		M00-FF
Byte5DTCLowByte
DTC低字节		M00-FF
Byte6StatusOfDTC
DTC状态位		M00-FF
Byte7DTCSnapshotRecordNumber#1
第1个快照记录码		C100-FE
Byte8DTCSnapshotRecordNumberOfIdentifiers#1
快照信息中记录的信息成员数		C100-FF

Byte9
Byte10
Byte11
.
.
#Byte[11+(p-1)]
.
.
#Byte[r-(m-1)-2]
#Byte[r-(m-1)-1]
#Byte[r-(m-1)]
.
.
#Byter		DTCSnapshotRecord[]#1=
DataIdentifier#1 byte #1(MSB)
DataIdentifier#1 byte #2(LSB)
SnapshotData#1 byte#1
.
.
SnapshotData#1 byte#p
.
.
DataIdentifier#w byte #1(MSB)
DataIdentifier#w byte #2(LSB)
SnapshotData#w byte#1
.
.
SnapshotData#w byte#m
C1
C1
C1
.
.
C1
.
.
Cw
Cw
Cw
.
.
Cw
00-FF
00-FF
00-FF
.
.
00-FF
.
.
00-FF
00-FF
00-FF
.
.
00-FF

.
.		.
.		.
.		.
.
Byte[ t]DTCSnapshotRecordNumber#x
第x个快照记录码		Cx00-FF
Byte [t+1]DTCSnapshotRecordNumberOfIdentifiers#x
快照信息中记录的信息成员数		Cx00-FF
Byte [t+2]DTCSnapshotRecord[]#x=
DataIdentifier#1 byte #1(MSB)		Cx00-FF

3.3 举例说明

      请求：06 19 04 A5 19 39 01 AA

      响应（首帧）：10 13 59 04 A5 19 39 01

      请求（流控帧）：30 00 00 AA AA AA AA AA

      响应（连续帧）：21 03 0B 00 AA 0B 01 11 

      响应（连续帧）：22 22 0B 02 33 44 45 55

     说明：诊断请求的DTC为A51939，请求的快照编号为01；响应数据字节长度为19个字节，其中快照包含的信息成员个数为3个，分别0B00，0B01以及0B02。

4 19 06服务 

     除快照信息外，还会记录DTC对应的一些扩展信息，如老化计数器及故障发生次数等，这时候就需要用到19 06服务。

4.1 请求格式

     19 06服务请求格式如下：

字节参数名称参数约定数值（Hex）
Byte1Request Service Identifier
请求ID		M19
Byte2SubFunction=ReportDTCExtendedDataRecordByDTCNumber
子功能=根据DTC报告一些扩展信息		M06
Byte3DTCMaskRecord[]=
DTCHighByte		M00-FF
Byte4DTCMiddleByteM00-FF
Byte5DTCLowByteM00-FF
Byte6DTCExtendedDataRecordNumber
DTC扩展数据记录编号		M00-FF

备注：当请求格式的第六个字节的 DTCExtendedDataRecordNumber为FF时，表示读取当前DTC对应的所有扩展组数据。 

4.2 正响应格式

      19 06服务正响应格式如下：

字节参数名称参数约定数值（Hex）
Byte1Positive Response Service Identifier
肯定响应回复ID		M59
Byte2SubFunction=ReportDTCExtendedDataRecordByDTCNumber
子功能=根据DTC号报告一些扩展信息		M06
Byte3DTCMaskRecord[]=
DTCHighByte
DTC高字节		M00-FF
Byte4DTCMiddleByte
DTC中字节		M00-FF
Byte5DTCLowByte
DTC低字节		M00-FF
Byte6StatusOfDTC
DTC状态位		M00-FF
Byte7DTCExtendedDataRecordNumber#1
第1个扩展数据记录码		C100-FE

Byte8
Byte9
Byte10
.
.
#Byte[10+(p-1)]		DTCExtendedDataRecord[]#1=
ExtendedData#1 byte #1
ExtendedData#1 byte #2
ExtendedData#1 byte#3
.
.
ExtendedData#1 byte#p
C1
C1
C1
.
.
C1
00-FF
00-FF
00-FF
.
.
00-FF
.
.		.
.		.
.		.
.
Byte[ t]DTCExtendedDataRecordNumber#x
第x个扩展数据记录码		Cx00-FF
Byte [t+1]DTCExtendedDataRecord[]#x=
ExtendedData#x byte #1		Cx00-FF
Byte [t+2]DTCExtendedDataRecord[]#x=
ExtendedData#x byte #2		Cx00-FF
.
.		.
.		.
.		.
.
Byte [t+q]DTCExtendedDataRecord[]#x=
ExtendedData#x byte #q		Cx00-FF

4.3 举例说明

      请求：06 19 06 12 13 14 01 AA

      响应（首帧）：10 14 59 06 12 13 14 09 

      请求（流控帧）：30 00 00 AA AA AA AA AA

      响应（续帧）：21 01 34 45 A3 42 41 40

      响应（续帧）：22 46 B3 32 15 1F 1E 32

     说明：诊断请求的DTC为121314，请求的扩展数据编号为01；响应数据字节长度为20个字节。

5 19 0A服务

       该服务为请求获取所有支持的DTC。

5.1 请求格式

      19 0A服务请求格式如下：

字节参数名称参数约定数值（Hex）
Byte1Request Service Identifier
请求ID		M19
Byte2SubFunction=ReportDTCByStatusMask
子功能=报告所有支持的DTC		M0A

5.2 正响应格式

     19 0A服务正响应格式如下：

字节参数名称参数约定数值（Hex）
Byte1Positive Response Service Identifier
肯定响应回复ID		M59
Byte2SubFunction=ReportDTCByStatusMask
子功能=报告所有支持的DTC		M0A
Byte3DTCStatusAvailabilityMask
DTC支持的状态掩码		M00-FF
Byte4DTCAndStatusRecord[]=
DTCHighByte#1
DTC高字节		C100-FF
Byte5DTCMiddleByte#1
DTC中字节		C100-FF
Byte6DTCLowByte#1
DTC低字节		C100-FF
Byte7StatusOfDTC#1
DTC状态位		C100-FF
Byte8DTCHighByte#2
DTC高字节		C200-FF
Byte9DTCMiddleByte#2
DTC中字节		C200-FF
Byte10DTCLowByte#2
DTC低字节		C200-FF
Byte11StatusOfDTC#2
DTC状态位		C200-FF
…………
Byte(n)DTCHighByte#n
DTC高字节		Cn00-FF
Byte(n+1)DTCMiddleByte#n
DTC中字节		Cn00-FF
Byte(n+2)DTCLowByte#n
DTC低字节		Cn00-FF
Byte(n+3)StatusOfDTC#n
DTC状态位		Cn00-FF

5.3 举例说明

       请求：02 19 0A AA AA AA AA AA

       响应（首帧）：10 0E 59 0A 09 B2 15 12

       请求（流控帧）：30 00 00 AA AA AA AA AA

       响应（续帧）：21 09 34 35 36 09 A1 A2 

       响应（续帧）：22 A3 09 55 55 55 55 55

       说明：ECU支持的状态掩码为09，读取的ECU的诊断故障码为B2151209，34353609，A1A2A309

6 总结

      19服务是售后最常见的服务之一，也是最为复杂的服务，包含的子功能比较多，但是仔细去分析几个子功能的功能以及相应的参数的含义，19服务本身并不难，如有疑问，欢迎评论沟通。

DiR_323
关注
  • 4
    点赞
  • 踩
  • 48
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
UDS诊断服务列表汇总【个人总结汇总】
03-24
对UDS各类诊断服务进行汇总，可以用来学习，也可以直接进行查询。 主要包括：SID（服务ID），诊断服务名，相应的说明解释，肯定响应，否定相应，是否支持子功能，子功能包括的值及说明，支持的否定响应码
UDS（统一诊断服务）的理解-0x19服务.docx
03-24
uds中 0x19服务的理解，需要可下载
【UDS诊断】——0x19 02
LOVE135149的博客
02-21 1万+
文章目录一、服务概述二、报文1.请求报文定义2.肯定响应3.报文讲解3.1格式及内容3.2举例 19服务作用是允许外部诊断仪（Client）通过该服务读取存储在ECU芯片内的故障码（DTC）状态信息 一、服务概述 按照定义的状态掩码的形式去查找匹配的故障，将匹配的DTC标识符（3个字节）、DTC状态（1个字节）信息返回.简单来说就是通过状态掩码去读取DTC，获取DTC及其状态 二、报文 1.请求报文定义 2.肯定响应 3.报文讲解 3.1格式及内容 发 送： 19 +01+DTCStatusMask（
汽车诊断之UDS入门-0x19 0x01/0x02服务
weixin_44842720的博客
10-14 6824
0x19 0x01和0x19 0x02解析
ISO14229 -1 UDS诊断服务记录-001：0x34\0x36\0x37\0x31\0x19\0x14服务报文格式介绍
最新发布
梦想技术家
05-09 1348
高位表示“Compression Method”，低位表示“Encryption Method”。0x00表示不使用Compression Method和Encryption Method，非0x00值由主车厂自定义。Compression Method：压缩方法Encryption Method：加密方法bit 3-0表示memoryAddress参数字节数，bit 7-4表示memorySize参数字节数。（一般为0x44表示4个字节地址，4个字节数据长度）
通过UDS诊断读取故障码
qq_31074045的博客
11-01 1658
通常来说，使用诊断仪读取控制器的故障码是最为方便快捷的，但俗话说，条条大路通罗马，方法不止是一种，接下来我将分享如何利用UDS诊断来获取故障码信息。
UDS的0x19服务
weixin_59334478的博客
04-24 371
诊断响应报文中的第3个字节，DTC状态可用掩码，表示ECU支持那些种状态的故障码。第4个字节DTC及状态*N，表示响应出所有符合诊断请求条件的DTC.DTC FID（DTC的格式标识符），如下所示。DTC Count存储故障码格式的标识符。DTC FID所支持的故障码状态的情况。19 01 用于读取故障码的数量。19 02 用于读取故障码列表。DTC SM故障码的状态掩码。DTC SM：DTC状态掩码。0x19读取故障码信息。
UDS（统一诊断服务）的理解——0x19服务
热门推荐
qq_38301199的博客
03-24 5万+
简述UDS、0x19服务 UDS可以简单理解为一套完整的通讯协议框架，其目的在于规范各种行车电脑和ECU之间的通讯。ISO 15762-2规定了UDS的网络层，ISO14229规定UDS的应用层。 UDS可以在不同的汽车总线上实现，但本文重点讨论UDS on CAN的诊断协议。 UDS包含一系列服务，每种服务都有自己独立的ID，即SID（Service Identifier），0x19服务其实是读取DTC信息的服务，其SID为0x19。 网络层 经典的CAN数据链路层最大能够支持单帧8个字节的数据传输
UDS诊断服务基础详解之二19服务
DiR_323的博客
09-20 7721
本文主要介绍UDS统一诊断服务的19 01服务，包含状态位和故障码的解析以及19 01服务的具体说明
DTC诊断故障码的获取与清除——0x19服务、0x14服务
weixin_42613638的博客
12-03 5098
1、01子服务——通过状态掩码去查找与其相匹配的故障个数。 通过该服务诊断仪能够请求ECU中DTC状态与DTC状态掩码相匹配的故障码个数。如果某一个故障码的实际状态位为1，并且DTC状态掩码中的相应位也为1，那么就认为该故障码的状态与DTC状态掩码相匹配（即：如果DTC状态掩码字节与DTC实际状态字节进行逻辑“位与”运算后的结果为非零值，那么两者就相匹配）；此时则将故障数+1。如果诊断仪定义了一个状态掩码，其中包含ECU不支持的位，那么ECU仅使用本身支持的位进行处理故障信息。请求格式...
关于DTC诊断故障码的获取与清除（ISO14229系列之14、19服务）
xikangsoon的博客
10-11 6058
关于DTC诊断故障码的获取与清除（ISO14229系列之14、19服务） 1、19服务-——读取诊断故障码信息(ReadDTCInformation) 1、01子服务 2、02子服务 3、04子服务 4、06子服务 5、0A子服务 2、14服务-——清除故障信息 (ClearDiagnosticInformation) 总结 1、19服务-——读取诊断故障码信息(ReadDTCInformation) 1、01子服务 通过状态掩码去查找与其相匹配的故障个数。 通过该服务诊断仪...
UDS——Unified Diagnostic Services
BeginnerMind
12-16 2829
UDS诊断原理分析 根据UDS的诊断协议，汽车上的控制系统需要根据规则化的诊断协议进行故障记录和处理，最终体现为诊断故障编码DTC的方式。 根据ISO-14229协议规定，每个DTC均由DTC内容和DTC状态表示。DTC内容代表了该故障的具体故障方式、故障标志等信息，例如车身系统中ABS传感器故障。DTC状态则表示当前的故障处于什么状态，它由8位组成，每个位代表了不同的故障状态信息，详细意义如下表...
关于DTC诊断故障码的获取与清除（ISO14229系列之14、19服务）.pdf
07-05
关于DTC诊断故障码的获取与清除（ISO14229系列之14、19服务）.pdf
0x19服务04子服务实例分析（14229-1）.docx
07-24
详细解析0x19服务的子服务0x04，举例说明 客户端和ECU之间如何进行数据收发。 例子虽少，但是优点在于透彻理解。
UDS诊断服务详解.docx
08-23
UDS（Unified Diagnostic Services）是汽车电子控制单元（ECU）进行故障诊断和服务的主要协议，遵循ISO 14229系列国际标准。该标准主要分为三部分：ISO 14229-1，定义了诊断服务的应用层，不涉及网络实现；ISO 14229...
UDS诊断服务列表.pdf
11-14
介绍诊断和通信管理功能单元、数据传输功能单元、存储数据传输功能单元、输入输出控制功能单元、例行程序功能单元、上传下载功能单元以及ISO15031-5中具体的每个服务的详细总结。
汽车UDS诊断demo程序
10-19
UDS（Diagnostic Communication over CAN，CAN上的诊断通信）是一种在汽车行业中广泛使用的诊断协议，它定义了控制器局域网（CAN）上车辆电子系统进行诊断和维修时的标准通信流程。这个"汽车UDS诊断demo程序"是针对...
UDS_19服务学习笔记
qq628383的博客
09-22 2万+
1.$19 01(ReportNumberOfDTCBByStatusMask) 服务的目的：通过上位机定义的DTCStatus 来获取服务端与状态掩码匹配的个数。 Request:19 01 +Status Response：59 01 +Status +DTCFormatID +DTCCount 2.$19 02 (ReportDTCByStatusMask) 服务目的：获取...
【UDS诊断】——0x19 06
LOVE135149的博客
04-10 1625
获取DTC存储时候的一些扩展数据，如老化计数器。 19 06与19 04格式与规则都差不多，只不过1904是读取快照信息的，1906是读取扩展信息的。
uds诊断服务基础篇之31
10-13
UDS（Unified Diagnostic Services）是一种用于车辆诊断的标准协议，它定义了一套诊断服务和通讯机制，可用于汽车电子控制单元（ECU）之间进行通信和诊断。 31. 将要求来自所选控制单元的信息发回给UDS诊断工具或依据请求来在所选控制单元中执行一个操作的服务称为？答案是：Read Data By Identifier（按标识符读取数据）。 Read Data By Identifier是UDS诊断服务中的一种基础服务。它通过在请求中指定一个标识符来读取所选控制单元中的数据，然后将这些数据返回给UDS诊断工具。 在使用Read Data By Identifier服务时，UDS诊断工具会向所选的控制单元发送一个请求，请求中包含要读取的数据的标识符。控制单元根据这个标识符，从自己的存储器中读取相应的数据，并将其返回给UDS诊断工具。这样，UDS诊断工具就可以获得所需的数据，用于诊断和故障排除。 Read Data By Identifier服务的应用场景很广泛。例如，当车辆发生故障时，UDS诊断工具可以使用该服务来获取与故障相关的数据，以帮助诊断工程师分析和解决问题。此外，厂商和技术支持人员还可以通过Read Data By Identifier服务来获取车辆的状态信息、性能参数等。 总之，Read Data By Identifier是UDS诊断服务中的一项重要基础服务，它允许UDS诊断工具从所选控制单元中读取数据，并帮助诊断工程师进行故障诊断和解决问题。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值