logo资料库

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

发布时间：2022-06-03 发布人：admin 分类：说明书 资料大小：1.62M 资料格式：docx 举报 版权申诉
第1页 / 共10页
第2页 / 共10页
第3页 / 共10页
第4页 / 共10页
第5页 / 共10页
第6页 / 共10页
第7页 / 共10页
第8页 / 共10页
资料共10页，剩余部分请下载后查看
    UDS（统一诊断服务）的理解——0x19 服务 一、 简述 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 协议不单单只 是为了 CAN 总线而设计的，避免不了传输数据流的情况，ISO 15762-2 的诞生就是为了能够 安全、快速的将多个字节通过经典 CAN 来进行传输。 总的来说 ISO 15762-2 是基于经典 CAN 通讯来实现的，它只不过是将数据帧分成四类方 便管理分别为：单帧、首帧、流控帧、连续帧。 1、 单帧 字节1 7-4位 帧类型 SE_DL值（Hex） 3-0位 SF_DL 0 1~6 7 8~F 字节3 N/A 字节2 N/A 说明 保留，如果是则忽略该帧 单帧数据长度 单帧数据长度 SE_DL=7时，只允许使用标准地址，如果 使用扩展地址则忽略该帧 无效，如果是则忽略该帧 对于未拆分的信息，网络层提供了一个优化的网络协议，即将信息长度值仅放 置在第一个字节的后四位。单帧支持在单个 CAN 帧中的信息传输。 帧类型等于0时表示单帧，SF_DL代表从第2个字节开始（包括第二个字节）有 多少个有效数据，表中“N/A”即是UDS应用层的数据。
    2、 首帧 字节1 7-4位 帧类型 3-0位 FF_DL 字节2 字节3 N/A FF_DL值（Hex） 说明 0~6 7 8~FFF 无效，是则忽略该帧 表示该条信息中（包括首帧和连续帧） 的有效数据字节的个数 只允许扩展地址或混合地址，否则忽略 该帧 表示该条信息中（包括首帧和连续帧） 的有效数据字节的个数 首帧只支持一条信息无法在单个 CAN 帧中传输时使用。 3、 流控帧 字节1 7-4位 帧类型 FS值（Hex） 3-0位 FS 0 1 3 3~F BS值（Hex） 00 01~FF 字节3 STmin 字节2 BS 说明 促使发送方继续发送连续帧，意味着接 收者准备好接收最大BS各连续帧 促使发送方等待新的流控帧到来，如果 有，则发送方要重新设置定时器。 促使发送方终止信息的发送，仅能在首 帧接收后并且判断数据长度将要溢出时 使用 保留 说明 指示发送者在发送连续帧时不再传递流 控帧，发送者应该不停的发送剩下的连 续帧。 指示发送者发送最大数目的连续帧，是 连续帧的帧数不是字节数，之前口述有 误
    STmin值（Hex） 说明 00~7F 80~F0 F1~F9 FA~FF 相邻两个连续帧之间的最小时间间隔 范围0~127ms（绝对单位） 保留，如果是则选择127ms 相邻两个连续帧之间的最小时间间隔 范围100~900us （最小细分100us） 保留，如果是则选择127ms 流控帧一般是客户端发送给服务器（仅包括 0x19 服务）。 4、 连续帧 字节1 7-4位 帧类型 3-0位 SN 字节2 N/A 字节3 N/A SN 为连续帧编号，开始于“0”，在同一个数据流中每新增一个连续帧则 SN+1, 当到达值“15”时在下一个连续帧中置为“0”，第一个流控帧后的编号为“1”。 当接收者发现连续帧编号错误时，信息的接收将被终止。
    5、 在 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 状态位，其位定义如下：
    2、 0x19 服务 02 子服务 按照定义的状态掩码的形式去查找匹配的故障，将匹配的 DTC 标识符（3 个字 节）、DTC 状态（1 个字节）信息返回。01 子服务只统计与状态掩码相匹配的 DTC 个数，02 子服务则会将这些匹配的 DTC 信息返回。请求格式如下： 收到请求后，ECU 的响应报文格式如下： 3、 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。
    4、 0x19 服务 06 子服务 扩展信息，用于记录故障的一些其他信息，比如故障发生的次数、老化次数、 已老化次数等。06 服务就是用于请求指定故障码（DTC）的扩展信息。请求格式如 下： DTCExtDataRecordNumber 值（Hex） 说明 0 01~8F 90~EF F0~FD FE FF 不可用（保留） 请求服务器报告汽车制造商指定存储 的 DTCExtendedData（DTC 扩展数据） 记录。 请 求 服 务 器 报 告 法 定 OBD 存 储 的 DTCExtendedData（DTC 扩展数据）记 录。 保留 请求服务器报告单条响应消息中所有 法定 OBD 存储的 DTCExtendedData（DTC 扩展数据）记录。 请求服务器报告单条响应消息中所有 存储的 DTCExtendedData（DTC 扩展数 据）记录。 收到请求后，ECU 的响应报文格式如下：
    分享到：
    赞 收藏

    相关推荐

    资料库

    行业

    共收录7266份资料，累计15个分类，关注成员有19位，主要包括：物流,旅游,餐饮零售,网络游戏,咨询,金融,电子政务,外包,教育,制造,医疗,嵌入式,互联网,交通,电信

    热门标签

    物流 旅游 餐饮零售 网络游戏 咨询 金融 电子政务 外包 教育 制造 医疗 嵌入式 互联网 交通 电信

    最新资料