UDS诊断服务基础详解之五-14服务

ISO14229——UDS诊断协议中的14服务：清除故障码

如果问题依然存在或不能通过UDS 0x14服务进行清除，则车主必须找到更深层次的问题，并可能需要进行更加复杂的故障排除和修理。执行ClearDTC：一旦技师确定DTC已经被记录并处理完毕，他们可以使用UDS 0x14服务执行ClearDTC操作，以清除记录的DTC信息。为此，车主可能需要带着车辆到附近的修车店，让维修工人查询故障，并使用UDS诊断工具进行清除操作。总之，通过使用UDS 0x14服务清除故障码，技师可以解决许多车辆故障问题，并保证发动机、传动和制动等关键系统的正常运转。

14服务，即 ClearDiagnosticInformation（清除诊断信息）服务，清除一个或多个服务器内存中的诊断信息。

文章目录一、服务概述二、报文1.请求报文定义2.肯定响应3.否定响应码4.报文讲解4.1格式及内容4.2举例 一、服务概述 14服务用于清除存储的故障诊断信息 二、报文 1.请求报文定义 2.肯定响应 3.否定响应码 0x72-通用编程错误：这个是指在擦除EEPROM中的DTC信息时，对EEPROM的操作发生错误，导致清除失败 4.报文讲解 4.1格式及内容 发 送： 19 +0A+DTCStatusMask（DTC状态掩码） 正响应： 59+01+DTCStatusAvailabilityMas

一、UDS简介

而后面的parameter则根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而UDS就是为不同的诊断功能请求和响应之间定义了统一的内容和格式。而negative response则意味着ECU因为某种原因无法执行诊断仪发过来的诊断请求，而无法执行的原因则存在于negative response的报文中。

UDS概述及常用服务介绍，浅显易懂，快速上手

3.UDS的报⽂是整体放在CAN报⽂数据域中的。UDS遵循的ISO标准。

统一诊断服务否定响应码的判定适用所有诊断服务的NRC及其优先级适用于带子功能参数的诊断服务的NRC及其优先级ISO14229-1中做了具体的NRC判断逻辑描述的诊断服务的NRC优先级通过ID写入数据服务(WriteDataByIdentifier, SID 0x2E)所支持的NRC优先级通过ID读取数据服务(ReadDataByIdentifier，SID 0x22)支持的否定响应码优先级清除故障信息服务（ClearDiagnosticInformation， SID 0x14）支持的否定响应码优先级通过I

UDS服务应该支持哪些否定响应码所有服务都需支持的否定响应码具体的服务需要支持的否定响应码否定响应码定义及其取值 USD诊断服务的否定响应中包含有导致否定响应原因的编码，称为否定响应码(NRC, Negative Response Code)。否定响应码的取值范围为0x00 - 0xFF，被分为三组： 0x00：服务器内部实现否定响应码判断逻辑时使用，表示要给出肯定响应。 0x01 – 0x7F：诊断通信相关的否定响应码。 0x80 – 0xFF：服务器收到诊断服务请求时，由于某些条件不满足要求而给出的否定

UDS可以基于不同的总线网络来实现，诊断服务，发送SID给ECU如果ECU认可，就发送SID+40（肯定响应），如果没有认可，会回一个7F，7F是否定响应的标识符。

🔓 在本篇文章中，你将会了解到OBD诊断口的结构和协议，UDS诊断协议，UDS帧结构，ISO-TP，还有DTC诊断码的相关知识。文章中所有诊断协议均是基于CAN来展开。当仪表板出现故障提示或者感受到实车故障时，工程师当然能通过ECU发出的报文来分析。但是CAN报文人类不可读，且需要解码，而UDS诊断协议能够帮助工程师快速定位到故障。在售后，你会看到工程师拿出诊断仪连接OBD2口为车子做扫描和诊断。

UDS诊断服务基础篇之22 前言 22服务作为诊断服务种的基础服务，可以简单理解为就是一个用于读取ECU数据的外部接口，可实时获取软件内部的相关的状态信息。 鉴于本文是基础入门介绍，小T还是会问下大家有关22诊断服务的相关问题？ 22服务的实际用途是什么？ 22服务的应用场景有哪些呢？ 22服务的诊断治疗格式如何？ 这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲： 正文 服务功能 功能描述 根据ISO14119-1标准中所述，诊断服务22主要用于Client向Server

本文主要简介14服务的内容，不涉及autosar配置

14 服务看似是 “简单的删除操作”，实则是 UDS 故障诊断流程的 “闭环关键”—— 它不仅要 “清除无效故障”，还要 “保护有效故障”，平衡 “诊断准确性” 与 “操作安全性”。精准：通过子功能和 DTC 掩码，实现 “按需清除”，避免误删关键故障记录；规范：标准化的权限控制，防止恶意清除故障，保障车辆维修的真实性；高效：无需拆卸 ECU 或断电，通过指令即可远程清除，大幅提升维修效率。

UDS（统一诊断服务） 是汽车电子系统中广泛使用的诊断协议，基于ISO 14229标准的汽车电子诊断协议，用于ECU（电子控制单元）的诊断、调试、编程和维护。"UDS诊断"指通过访问车辆电子控制单元（ECU）提供的服务，获取车辆实时状态信息。技术人员可主动请求这些数据服务，从而分析车辆运行状况、定位故障原因，并据此进行维修维护或系统配置。形象点说，就是用一套仪器对当前汽车出现的问题进行分析，而这套仪器与汽车交谈所使用的语言就是UDS。

本文介绍了0x14服务(ClearDiagnosticInformation，清除诊断信息服务)的使用说明

这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲： 根据ISO14119-1标准中所述，诊断服务14主要用于Client向Server(ECU)请求清除诊断相关信息。一般而言，14诊断服务，主要应用场景为以下场合：上述这些应用场景较为常见，除此以外，当然还有很多面向ECU内部测试的应用场合，这里就不一一列举。注意事项：14服务可以指定某个DTC Group组(如Powertrain, Body, Chassis等)进行清除或者指定DTC进行清除。同时除非有特殊说明，否则将会清除所有

根据ISO14229-1标准所述，14服务主要用于Client向Server（ECU）请求清除诊断相关信息。简单说客户端可以利用此服务来清除一个或多个服务端内存中的诊断信息。该服务可设置，可控制单个服务端或多个服务端诊断信息的清除。关于诊断相关信息见文章该服务不支持子功能参数。（肯定也没有抑制肯定响应位，因为没有子功能参数）