UDS(统一诊断服务)的理解 | 您所在的位置:网站首页 › 0209的意思 › UDS(统一诊断服务)的理解 |
简述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 字节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 字节2 字节3 7-4位 3-0位 帧类型 FF_DL N/A FF_DL值(Hex) 说明 0~6 无效,是则忽略该帧 7 表示该条信息中(包括首帧和连续帧)的有效数据字节的个数 只允许扩展地址或混合地址,否则忽略该帧 8~FFF 表示该条信息中(包括首帧和连续帧)的有效数据字节的个数
首帧只支持一条信息无法在单个CAN 帧中传输时使用。 流控帧字节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 字节2 字节3 7-4位 3-0位 帧类型 SN N/A N/A SN为连续帧编号,开始于“0”,在同一个数据流中每新增一个连续帧则SN+1,当到达值“15”时在下一个连续帧中置为“0”,第一个流控帧后的编号为“1”。 当接收者发现连续帧编号错误时,信息的接收将被终止。 在0x19服务中一般的使用顺序单帧的使用情况 多帧的使用情况1 多帧的使用情况2 客户端以单帧的形式向服务器请求0x19服务01子服务 客户端以单帧的形式向服务器请求0x19服务02子服务 同多帧的使用情况1 服务器收到请求(如果符合单帧的规范)以单帧的形式回给客户端相应的信息 服务器收到请求,发现将要回复的数据量大于单帧要求的最大数据量,此时向客户端回复首帧 同多帧的使用情况1 结束 客户端收到首帧后,判断缓存空间是否大于首帧包含的该条数据流的长度,如果是则向服务器发送流控帧,使服务器一次性全部将数据送出 客户端收到首帧后,判断缓存空间是否大于首帧包含的该条数据流的长度,如果不是,向服务器发送流控帧,使服务器只发送部分数据流 服务器收到流控帧后,根据客户端要求,将数据以连续帧的形式送出,直到送完为止 服务器收到流控帧后,根据客户端的要求向客户端回复定量的连续帧,完成后,等待下一个流控帧的到来 结束 客户端收到部分数据流处理完毕后,再次向服务器发送流控帧,使服务器再次发送 直到全部数据传输完毕 结束 应用层 0x19服务01子服务通过状态掩码去查找与其相匹配的故障个数。 通过该服务诊断仪能够请求ECU中DTC状态与DTC状态掩码相匹配的故障码个数。如果某一个故障码的实际状态位为“1”,并且DTC状态掩码中的相应位也为“1”,那么就认为该故障码的状态与DTC状态掩码相匹配(即:如果DTC状态掩码字节与DTC实际状态字节进行逻辑“位与”运算后的结果为非零值,那么两者就相匹配);此时则将故障数+1。如果客户端定义了一个状态掩码,其中包含ECU不支持的位,那么ECU仅使用本身支持的位进行处理故障信息。请求的格式如下: 收到请求后ECU响应的格式如下: DTC状态掩码参数包含8个DTC状态位,其位定义如下: 0x19服务02子服务按照定义的状态掩码的形式去查找匹配的故障,将匹配的DTC标识符(3个字节)、DTC状态(1个字节)信息返回。01子服务只统计与状态掩码相匹配的DTC个数,02子服务则会将这些匹配的DTC信息返回。请求格式如下: 收到请求后,ECU的响应报文格式如下: 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子服务该服务用于请求所有支持的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 |
CopyRight 2018-2019 实验室设备网 版权所有 |