Tip📌：本文描述中但凡涉及到UDS服务相关的，将陆续提供链接跳转方式以便快速了解他们。（各服务介绍持续更新中…）

学习UDS基础知识以及其他相关内容？>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<

一、简介

  DTC（Diagnostic Trouble Code，诊断故障码）是指车辆电子控制单元（ECU）存储的车辆故障代码，它是一种数字编码，用于标识车辆的故障问题。每个DTC都与特定的故障相关联，这些故障可能会导致车辆的某些系统无法正常工作。

  车辆在运行过程中ECU会持续监控车辆运行状态，检测到故障时，它会记录相应的DTC，并将其存储在车辆的故障存储器中。通过读取故障存储器中的DTC，可以快速确定车辆的故障问题，并采取相应的修复措施（涉及DTC的读取和清除：0x14服务和0x19服务）。

二、DTC字节结构剖析

  DTC的格式定义是依据几个标准来的，比如ISO-14229-1，SAE J2012 OBD DTC和SAE J1939-73等。就学习DTC来说，我们不必关注各个标准间的异同和细节，只需了解DTC分为non OBD和OBD两种格式，具体格式如下所示：

  可以清晰地看到DTC由四个字节组成，最高字节均保留未使用，剩下三个字节我们标记为：DTC HighByte、DTC MiddleByte、DTC LowByte。

• DTC HighByte和DTC MiddleByte两个字节表示故障内码，对应5位标准故障码（一位字母+四位数字）。
• DTC LowByte描述了故障的种类和子类型（可以参考ISO 15031-6以及SAE J2012-DA，比如常见的timeout应该用0x87，信号无效为0x81等等），简单理解就是对故障类别作进一步的区分/描述，未使用这个字节的可以用0x00填充，比如OBD格式的最低字节未使用，默认为0x00。

——举例 DTC：B100016

  其中"B1000"表示故障内码，对应5位标准故障码；"16"是DTCLowByte的内容。故障内码与5位标准故障码的对应关系如下：

  看完上面的DTC五位标准故障码的构成，再来看个例子：

  DTC-P010016：第一位是P代表此故障码和动力系统相关；第二位是0，是ISO标准中定义的故障类型；第三位是1，表示燃油和空气供应的测量相关；第四位和第五位是都是0，是具体的故障对象和类型的一个编码；第六位和第七位16则是DTCLowByte的内容。
  在车载操作系统的代码中，DTC码通常作为十六进制数处理，将P010016转换为16进制数如下所示：
  二进制表示为：P(00) 0(00) 1(0001) 0(0000) 0(0000) 1(0001) 6(0110)
  十六进制表示：0x10016

Tip📌：不必疑惑有些位到底表示什么故障类型，更具体的含义是什么，通常制造商会提供他们每个编码的具体含义。

  完成上面对DTC码的学习后，我们可以根据DTC大致知道是哪个系统什么类型的故障，但不能清晰得知故障是什么时候发生的，是什么原因触发的这个故障、现在是否已经恢复、发生过几次，恢复过几次等细节性信息，因此还需要其他信息：比如DTC状态（DTC status）、DTC快照信息（Snapshot）和DTC扩展数据信息(Extended data)。只有发生故障的时候存储下了这些关键信息，才能有助于故障的解决。下面将具体介绍这些DTC的关键附属信息。

三、DTC关键附属信息

3.1 DTC状态（DTC status）

  DTC状态为1个字节，其8个bit位含义各不相同，如下表所示：

——关于评论区的提问：“博主您好，是不是testfailed一被置1，pendingdtc也会马上被置1呀”
（这里新增一段描述给有同样疑惑的工程师们）

  在车载系统的UDS协议中，DTC（Diagnostic Trouble Codes）状态位的管理是错误监控和故障诊断过程的一部分。这些位的设置与清除取决于特定的条件和故障检测逻辑。testFailed位和pendingDTC位代表了故障检测的不同阶段：

1. testFailed 位通常是实时的，在最近的一次监测周期中，如果某个ECU监测的参数不在预期的范围内，就会将这一位设置为 1。这表明在最近的检测周期中，该ECU监测到了一个故障。但这并不意味着故障会立即被记录下来，因为它可能是暂时的或偶发的。

2. pendingDTC 位则是在故障符合一定条件后才被置为 1，通常是在故障在一个或多个操作周期中被检测到。pendingDTC为1意味着故障已经被记录下来，但还未达到confirmedDTC（确认DTC）的标准。

  关于评论区的这个问题，testFailed位被置为1并不会自动导致pendingDTC置为1。pendingDTC的置位通常需要故障在连续的操作周期中持续出现。具体的置位条件由制造商根据监测策略和法规要求定义。

——举个例子：
  假设有一个监测策略，它要求一个故障必须在两个连续的操作周期检测到才能将pendingDTC置为1。

• 第一个操作周期：故障首次被检测到，testFailed被置为1，但pendingDTC保持为0，因为我们还没有达到故障记录的条件。

• 第二个操作周期：故障再次被检测到，testFailed仍然为1。因为这个故障现在已经在连续两个操作周期中被检测到了，pendingDTC将被置为1，表明故障已经被记录下来，但还未确认。

• 第三个操作周期：如果故障未被检测到，testFailed位将被清除（置0），但pendingDTC可能仍然保持为1，因为它通常需要多个操作周期的故障消失来清除。

  因此，pendingDTC的置位是一个基于监测策略的累积过程，而不是简单地跟随testFailed位的状态。

3.2 DTC快照信息（Snapshot）

3.2.1 DTC和Event是什么？

  DTC是某类故障的统称，能够大体定位到某个模块的故障，而Event则是故障监控的基本单元，能够定位某个模块中的某个具体故障；Event可以由基础模块自行定义监控策略，当发生故障Event时，需要完成这个Event的上报、去抖（防止故障误报）、存储等过程，这些处理流程由DEM模块负责管理（Diagnostic Event Management），本文不对DEM模块做深入介绍。

3.2.2 DTC和Event有什么区别/联系？

• 多个Event可以mapping 同一个DTC，而同一个Event不能mapping 多个DTC；
• DTC直接可见，但Event需通过进一步手段才能看到（比如通过UDS服务获取DTC关联的Event信息），有时仅对ECU供应商可见。
• DTC代表某类Event集中表现，而Event则是某个DTC的具体实例；
• Event的优先级决定了DTC的优先级，Event之间的依赖关系决定了DTC的依赖关系；
• DTC的1字节状态位是其mapping的所有Event的状态位的或集。

3.2.3 DTC快照信息

  DTC快照信息（Snapshot Record）就类似照相机一样，在故障发生的时刻，对整车信息按下快门，做个记录，以便后续分析问题。其所记录ECU发生故障时运行状态信息可以包括多个方面的数据，笼统的说比如故障码、故障条件、传感器数据、控制单元状态等。常见一些数据有：故障发生时的时间戳、ECU电压值、电流值、温度或者由故障Event引起的相应DTC等等。

Tip📌：快照信息存在的意义
  由于一个DTC可由多种故障Event触发（多个Event可以mapping 同一个DTC），因此需要通过快照信息进一步区分这个DTC具体是由哪个Event触发的。

3.2.4 举例说明DTC、Event、快照信息和DID间的关系

  整车系统中可能存在各种故障Event，比如电池低压/过压事件、通信丢失事件、胎压故障事件等。为了更好的区分故障类型，整车制造商会将这些事件关联（mapping）到不同的DTC。同时，为了维修人员更快、更准确的识别故障事件，还需要提供一些额外的辅助信息，比如故障发生时的时间、ECU供电电压、相关传感器数据等。为了获取这些信息，可以将这些信息设置一个快照信息组（Snapshot Group），为了区分不同的Snapshot Group，可以为每个Snapshot Group分配一个识别号，即DTCSnapshotRecordNumber。
  UDS要求，DTCSnapshotRecordNumber由1 byte组成，0x00一般预留给OBD协议使用，0xFF表示ECU一次将所有的快照数据上报，0x01~0xFE由OEM自行设定。

Tip📌：每个DTCSnapshotRecordNumber包含一组快照信息，一组快照信息中可以包含多个DID，每个DID则包含具体的信息。

3.3 DTC扩展数据信息（Extended data）

  和DTC快照信息的功能类似，由于DTC中8bit位可以承载的信息是有限的，仅能说明故障是当前故障还是历史故障。故障发生时的其他重要信息还需要额外的数据存储，常见的一些扩展数据如下所示：

Tip📌：这些DTC信息、状态位信息、快照信息、扩展帧信息都可以通过UDS协议中的0x19服务读取。

>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<