在汽车电子诊断领域，在新车型定义诊断需求时，会给每一个ECU的故障类型定义一个DTC，ECU中运行代码判定DTC是否产生（判定机制和原理我会在关于Service 19文章分享）。对应DTC故障产生后，ECU会将该DTC以及DTC Status存储到ECU芯片内存中。当用Tester发送：Service 19 02可获知ECU中DTC那些状态位被置一，那些DTC对应的故障产生

Service 19 04 可获知ECU中发生故障时，记录当前的环境信息（快照信息）。

而对应本文主题Service 14，是车辆维修或者保养后，用于清除ECU芯片上记录的DTC功能。

使用Service 14后，ECU芯片中所有的DTC信息都不存在啦！

通过如下内容详细连接该服务：

1. UDS协议对服务的定义
2. 用图形说明Service 143、手动测试
3. UDS协议对服务的定义

一、UDS协议关于Service开篇有云：

The ClearDiagnosticInformation service is used by the client to clear diagnostic information in one or multiple servers’ memory.

关于该服务有以下注意事项：

1. 当Server端（ECU）完全处理Clear Diagnostic Information服务后，Server端应发送肯定响应；
2. 即使ECU没有存储DTC内容，Server端也应回复肯定响应；
3. 若Server支持DTC状态信息在内存中多处备份（e.g.一份在RAM，一份在EEPROM），Server端应该清除通过Server 19服务读取并报告DTC信息的那份备份。此外也应注意长期记录DTC信息的那份备份也要根据适当的备份策略进行更新（e.g. 在电源锁存状态）
4. 对应Service 14后带的参数：

A：可以清除一组DTCs（e.g. Powertrain, Body, Chassis, etc.）；

B：可以清除特定DTC；

C：FF FF FF意味清除全部DTC

1. 除非另有说明，否则服务器应清除排放与非排放相关的所有DTC

关于该服务的格式在协议定义如下：

响应格式如下：

对应这个Service的NRC优先级UDS推荐如下：

1. 用图形说明Service 14

如上图所示，关于Service 14需要特殊说明：

1. Tester是通过Service 19 02读取RAM中DTC状态信息；
2. 在需求规范中需要特别定义RAM和EEPROM两者之间DTC同步更新策略。

1. 手动测试

首先在CANoe中添加待测ECU的CDD数据库（当然ODX也可以）

通过诊断控制台发送Service 14：

在CANoe中也有一个交互界面，可以快速获取ECU的故障状态：

以上分享，希望有所帮助！

愿您我相信时间的力量，

做一个长期主义者！

-----------------------------------

作者简介 | 穿拖鞋的汉子

汽车电子工程师

公众号：车载诊断技术

chuantuoxiedehanzi@163.com

来，每天进步一点点！