【UDS】ISO14229之0x14服务

&春风有信

已于 2023-04-18 17:29:26 修改

阅读量5.3k

点赞数 7

分类专栏： UDS诊断从入门到熟练文章标签： autosar can 自动驾驶汽车

于 2022-06-04 20:25:00 首次发布

本文链接：https://blog.csdn.net/weixin_48498880/article/details/125115549

版权

UDS诊断从入门到熟练专栏收录该内容

19 篇文章 268 订阅

订阅专栏

文章目录

前言
一、理论描述
二、使用步骤
- 1.请求
- 2.响应
总结

->返回总目录<-

前言

简称： “ClearDiagnosticInformation”，清除DTC信息
功能： 用户通过请求该服务，清除一个或者多个指定ECU记录的DTC故障信息，这些故障信息存储在NVM（非易失性存储）中。

一、理论描述

总而言之，相比较0x19服务，该服务相对比较简单。当请求该服务之后，ECU回复正响应，即使没有存储任何DTC故障信息。若ECU支持内存中多份DTC状态信息副本（例如：一份存在RAM里，一份存在EEPROM里，当然大部分是用flash模仿EEPROM的功能），则ECU会清除0x19 Sub-function 02的服务（ReadDTCInformation）请求的信息副本，即RAM中的那份。

通过本服务重置/清除的DTC信息包括但不限于以下各项数据：
1，DTC状态字节（见0x19服务那章的02子服务）
2，捕获的DTC快照数据（见0x19服务那章的04子服务）
3，捕获的DTC扩展数据（见0x19服务那章的06子服务）
4，其他特定于DTC的相关数据，如最近的DTC，标志，计数器，计时器等。

二、使用步骤

1.请求

在这里插入图片描述
第一个字节就是SID，
后边的三个字节用于标识将要被删除的DTC种类，UDS规定用FF FF FF表示所有种类的DTC，由厂家自定义代表Powertrain、Chassis、、Body、Network Communication等种类DTC的值。
通常博主在工作中，该服务请求请求报文为14 FF FF FF：清除所有存储的DTC信息。在这里插入图片描述

2.响应

1）正响应
这个相对比较简单，像上述理论描述中一样，只要请求的报文符合UDS定义的标准格式，ECU都会正响应，无论是否有存储的DTC信息。
见上图报文截图。

2）否定响应
支持的否定响应如下，一般工作上大部分支持前三个。在这里插入图片描述
~

NRC13： 老话常谈咯，请求服务的报文长度不对。正确应该是19 FF FF FF。而下图我们只发送3字节数据。蓝色框框里的在这里插入图片描述
~

NRC22： 这个客户会在诊断需求文档告诉你，所以你不用太担心满足条件。我们以满足支持诊断服务的工作电压为例。例如7V ~ 18V。诊断模块必须在该电压范围内，才可以工作。此时ECU供电电压突然低于7V，这个时候你就不能请求诊断服务了。如下图在这里插入图片描述
~

NRC31： 请求DTC组的信息不对。根本没有01 01 01的组号。蓝色框框告诉我i们该服务在扩展会话下执行的。在这里插入图片描述 —

总结

0x14服务相比之下，较简单。就是清除存储的DTC故障数据。强调下，当我们使用该服务清除了那些过去发生的DTC故障（即满足DTC状态掩码0x08），则使用19 02服务读取DTC状态信息的时候，满足0x08状态掩码的DTC信息会被清除，19 02不该再读出该掩码状态的DTC信息，下一章0x22读DID服务见！

->返回总目录<-