【车载开发系列】UDS诊断 |
您所在的位置：网站首页 › 冬奥之约冰雪友情征文1000字怎么写 › 【车载开发系列】UDS诊断 |
【车载开发系列】UDS诊断
|
【车载开发系列】UDS诊断—读取DTC信息（$0x19）
UDS诊断---读取DTC信息（$0x19）
【车载开发系列】UDS诊断---读取DTC信息（$0x19）一.概念定义1）DTC概念2）故障类型3）快照数据
二.DTC相关子功能1）匹配故障个数（0x01）2）DTC的状态码获取（0x02）3）读取DTC的快照数据（0x04）4）获取DTC扩展数据（0x06）5）请求支持的DTC信息（0x0A）
三.报文格式1）SubFunction$0x01和$0x02的场合1.请求报文2.$0x01肯定响应报文3.$0x02肯定响应报文4.否定响应报文
2）SubFunction$0x04的场合1.请求报文2.肯定响应
3）SubFunction$0x06的场合1.请求报文2.肯定响应
4）SubFunction$0x0A的场合1.请求报文2.肯定响应
一.概念定义
UDS可以简单理解为一套完整的通讯协议框架，其目的在于规范各种行车电脑和ECU之间的通讯。0x19服务其实是读取DTC信息的服务。 1）DTC概念故障存储相关的0x19和0x14服务。 当系统检测到了一个错误或者是一个故障发生的时候，会将相对应的数值故障码进行存储，那么这个对应的数值故障码，我们称之为故障码，就是DTC。 一个DTC可以反应出一个故障发生的具体位置，和这个故障发生原因和类型，我们通过读取的DTC信息，可以为维修提供一些依据。除此以外还有与法律有关的故障，比如说排放有关的，在未来还会有安全相关的故障 2）故障类型在很多国际标准里面都定义了DTC的格式。比如说UDS里定义DTC由3个字节组成，而ISO 15031-6里定义了DTC格式由“两个字节根基+一个字节的故障类型”组成。有95%用到的DTC格式都是ISO 15031-6里定义的DTC的故障类型和格式 3）快照数据快照数据是指当这个错误发生，或者当这个DTC存储的时候，记录的一些环境数据，比如说车速，水温，发动机转数等这些数据，从而我们读取这些数据之后，能够更好的判断DTC产生的原因以及发生故障原因。 二.DTC相关子功能在14229-1中定义的19服务读取DTC信息里，定义28个Subfunction，根据不同的Subfunction来获取不同的诊断信息 Hex(位 6-0)描述Description0x01通过状态掩码报告 DTC 数目reportNumberOfDTCByStatusMask0x02通过状态掩码报告 DTCreportDTCByStatusMask0x04通过 DTC 码报告 DTCSnapshot 记录reportDTCSnapshotRecordByDTCNumber0x06通过DTC码报告 DTC 扩展数据记录reportDTCExtendedDataRecordByDTCNumber0x0A报告支持的 DTCreportSupportedDTC 1）匹配故障个数（0x01）通过状态掩码去查找与其相匹配的故障个数。 通过该服务诊断仪能够请求ECU中DTC状态与DTC状态掩码相匹配的故障码个数。 如果某一个故障码的实际状态位为“1”，并且DTC状态掩码中的相应位也为“1”，那么就认为该故障码的状态与DTC状态掩码相匹配（即：如果DTC状态掩码字节与DTC实际状态字节进行逻辑“位与”运算后的结果为非零值，那么两者就相匹配）；此时则将故障数+1。如果客户端定义了一个状态掩码，其中包含ECU不支持的位，那么ECU仅使用本身支持的位进行处理故障信息。 2）DTC的状态码获取（0x02）按照定义的状态掩码的形式去查找匹配的故障，将匹配的DTC标识符（3个字节）、DTC状态（1个字节）信息返回。01子服务只统计与状态掩码相匹配的DTC个数，02子服务则会将这些匹配的DTC信息返回。 3）读取DTC的快照数据（0x04）为了方便找到故障的原因，在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据。 在14229里定义的数据叫做快照数据；在Autosar里定义的数据叫做冻结帧，其实他们指的是一类数据。 4）获取DTC扩展数据（0x06）19 06是来获取DTC存储的时候一些扩展数据，这个数据常用的比如说有一些计数器，比如说老化计数器，这样的数据。 5）请求支持的DTC信息（0x0A）19 0A是来读取这个ECU所支持的全部的DTC。其响应报文与02服务一致；但要区分，该服务返回的是所有DTC的信息，ECU支持的哪些DTC是在ECU诊断规范的时候已经定义好的，所以我们通过19 0A读取的DTC是这个ECU应该支持的所有的DTC，即使这个DTC没有产生，也能够被读取的； 而02服务是返回与请求时状态掩码相与不为“0”的DTC信息。 三.报文格式 1）SubFunction$0x01和$0x02的场合$0x01是通过状态掩码报告DTC数目服务。 $0x02是通过状态掩码报告DTC子功能服务。 1.请求报文SubFunction为01，02的场合的请求如下： ReportNumberOfDTCByStatusMask就是Subfunction01，返回通过状态掩码报告DTC的数目。 ReportDTCByStatusMask就是Subfunction02。返回通过状态掩码报告DTC。 
3.$0x02肯定响应报文
ECU须将诊断工具请求的 DTC 状态掩码与它支持的各个DTC实际状态进行“位与”逻辑运算。ECU 将不仅返回 DTC 状态有效掩码，还有所有“与”运算结果为非零的所有DTC。 所有的SubFunction的场合的否定响应是一致的。具体如下： 
2.肯定响应
一个DTC 存储多个SnapshotRecords的典型应用是用于存储 DTC 多次发生时记录的数据，这些数据体现了（每次）发生时的整车状况。如果参数DTCMaskRecord或DTCSnapshotRecordNumber无效或不被ECU支持，ECU应发送否定响应。   C1：此参数只在有可以报告的 DTC 信息时存在。 C2：此参数只在需要报告的 DTC 信息多于一个时存在。
3）SubFunction$0x06的场合
客户端向服务器请求：06 19 06 XX XX XX FF 00 服务器向客户端回复：10 11 59 06 XX XX XX 10； 第一个字节的前四位“1”： 表示该帧为首帧，意味着服务器将等待客户端回复控制帧，以继续发送其余数据 第一个字节的后四位和第二个字节的八个位组成的12位编码：“011” 为当前数据流的总字节数，此处表示有当前数据流中有17个有效字节 第三个字节开始的59 06： 表示0x19服务06子服务的响应。 第五个字节开始XX XX XX： DTC码和客户端请求的DTC码一致。 最后一个字节10： 当前DTC的状态位。 1.请求报文 ReportDTCExtendedDataRecordByDTCNumber就是SubFunction06。DTCMaskRecord是DTC掩码记录，DTC记录包含 DTC 高字节, DTC中间字节和DTC低字节，或者依照SAEJ1939格式的DTC。DTC高字节, DTC中字节 和DTC低字结合起来代表一个唯一的ECU支持的诊断故障码的标识码。如果ECU内DTC的值与 DTC 掩码记录相等（精确匹配需求），则与其匹配DTCExtendedDataRecordNumber表示向服务器获取该DTC的所有的扩展数据
2.肯定响应
DTCAndStatusRecord由三个字节所构成， 包含了DTC码和ECU支持的DTC状态记录。DTCExtendedDataRecordNumber就是DTC扩展数据记录号码，占用1字节，用于表示 DTC 对应的扩展数据记录号码。0x00和0xFF不使用之外，其他的值定义是由车厂决定的。DTCExtendedDataRecord就是具体的报告DTC扩展数据记录的内容。 
4）SubFunction$0x0A的场合
读取 DTC 信息–报告支持的 DTCs ReadDTCInformation – ReportSupportedDTCs 1.请求报文 ReportSupportedDTC就是SubFunction0A。只有两个字节被用到，是19服务中最简单的请求了。
2.肯定响应
DTCStatusAvailabilityMaskDTC状态有效掩码。用于表示ECU支持的DTC状态位DTCAndStatusRecord中包含了ECU支持的所有DTC码和ECU 支持的每个DTC 状态。 
|
C1：此参数只在有可以报告的 DTC 信息时存在。 C2：此参数只在需要报告的 DTC 信息多于一个时存在。
【本文地址】
今日新闻 |
推荐新闻 |