UDS 故障码——Diagnostic Trouble Code（DTC）

The Lifecycle of a Diagnostic Trouble Code (DTC) 

 请问DTC的作用是什么？

DTC（Diagnostic Trouble Code）是诊断故障码的缩写，用于表示车辆中检测到的某个问题。每个DTC都代表一个特定的故障或问题，通常与生产或维修有关。DTC由3个字节组成，通过诊断事件映射到特定的诊断事件，从而使这些事件通过DTC代码唯一标识。DTC在诊断管理中用于唯一标识事件存储数据库中的数据。

 这些故障码是如何生成的？

DTC（诊断故障码）是由车辆的诊断系统（OBD-II）在检测到故障时生成的。

当系统检测到一个错误，ECU就会存储一个故障码。一个event发生（event是与DTC是有关联关系的）就会导致错误的产生，产生错误的ECU就会存储一个故障码DTC。

一个DTC是可以关联一个或多个event的，一个DTC可能代表多个含义，有的代表这个故障是一个可见故障（会有亮故障灯亮起）比如油压不稳，或者胎压过低，有些故障可能与排放相关的故障。

OBD-II不仅诊断故障，还通过可见的警告（例如点亮发动机故障灯）显示DTC。

在汽车领域，DTC的生成与事件相关，例如传感器故障事件。

SWC（监控传感器状态的监控功能）或BSW模块（监控BSW模块状态的监控功能）可以向DEM模块报告事件状态（通过UDS通信），如果事件失败，DEM模块将根据ISO-14229设置DTC状态字节，并要求/NvM存储事件和事件相关数据到NvM中。

 这些故障码如何帮助车辆维修人员诊断问题？

故障码（DTC，Diagnostic Trouble Code）对于车辆维修人员在诊断问题时非常有帮助。

让我详细解释一下：

• 问题定位：故障码指示了车辆中的具体问题。例如，如果某个传感器出现故障，相应的DTC将指示该传感器的问题。
• 快速诊断：维修人员可以通过读取DTC来快速定位问题，而不必进行繁琐的手动检查。这节省了时间和精力。
• 精准维修：DTC提供了精确的信息，帮助维修人员确定需要修复的部件或系统。这有助于避免不必要的更换和维修。
• 历史记录：DTC还可以记录历史故障，即使问题已经解决，维修人员也可以查看以前的DTC以了解车辆的维修历史。

总之，故障码是车辆维修人员的有用工具，可以帮助他们快速、准确地诊断和解决问题。

当系统检测到故障时，它会通过诊断故障代码（DTC）存储。

DTC代表：可观察的故障，和/或可用的修理指导。此外，还有关于法律或保修索赔和与排放相关的故障。故障总是指一个ECU、一个故障位置和一个故障类型。 

 

Figure 1: Process sequence of a DTC

现今使用的故障码（DTC）基于通过计数测量的控制单元的闪烁代码。随着电子设备复杂性的增加，因此出现了越来越复杂的错误条件，这些专有的诊断过程已不再足够。

因此，开发出了目前已知的2字节（OBD法规代码）和3字节DTC（UDS标准化）。

DTC的交换格式

通过诊断期间获取的数据，可以分析故障的原因以及其对车辆功能的影响。这样做是为了实现高效和有效的故障排除，并能够继续运行或修理车辆，可能会有一些限制。

由于现有的成本压力，对于车辆制造商及其供应商来说，合作并使用共同的交换格式是有意义的。在嵌入式电子开发领域，这导致了AUTOSAR的DEXT格式，而对于离线诊断，ASAM的ODX格式也是类似的。

控制单元中的DTC

从电子控制单元中的检测到诊断车间中的DTC的路径如封面图片所示（图1）。

具有诊断功能（监视器）的应用软件

应用软件通过周期性地使用监视器（也称为诊断功能）监测信号是否符合相关限值来进行监视。符合或不符合限值的情况以事件的形式通知诊断管理器（DM）。

 Figure 2: One monitor for battery monitoring with two events

实际监控功能的限值，在上图中为11.2 V和15.2 V，仍然是专有的，但应用程序的事件在DEXT中定义。

Diagnostic Events 诊断事件

监视器的事件分配给特定的DTC，并通过中间件传输到DM。错误代码主要用于售后服务，并取决于各自的诊断策略。通常，OEM会统一确定用于其车辆的DTC。

多个事件也可以分配给同一个DTC。例如，“过压事件”和“欠压事件”可以分配给两个不同的DTC，或者只有一个共同的DTC，例如“电源”。

编写工具应将监视器的事件与相应OEM的ECU的DTC关联起来。由于不是每个监视器都必须发送事件，但DM中的每个DTC至少需要4个字节的内存，因此必须删除未使用的DTC。

事件的去抖动

并非每个小故障都应立即生成DTC，从而触发相关的故障反应。例如，如果电池电压在几秒钟内过低，那么关闭ABS只是一种过度反应。因此，大多数事件都经过去抖动处理。

总之，有三种不同的策略，其定义有很大的不同。

• 基于时间的去抖动 Time-based debouncing：

在这种情况下，错误必须存在一段时间，才能作为DTC（已确认）生效。

• 基于计数器的去抖动 Counter-based debouncing：

在这里，错误计数器会以不同的步长递增，最多为127（对于“已确认”）或递减到-128（对于“已通过”）。这样可以调节精确的去抖动行为。

• 内部去抖动 Internal debouncing：

DM没有去抖动，监视器已经提供了去抖动的事件。

除了上述3种去抖动策略之外，DEXT中还有许多其他设置，影响DTC的确切行为。例如，将去抖动计数器保存在非易失性存储器中，ClearDTC时重置去抖动计数器以及在新的操作周期中重置去抖动计数器。

功能停用，功能抑制管理器（FIM）

如果DTC被存储为已确认，车辆必须对此错误做出适当的反应。车辆制造商在车辆开发过程中分析此类故障及其影响。这通常是通过FMEA（失效模式和影响分析）来描述的，车辆的相应反应也在其中确定。FIM最终在控制单元中实现了FMEA的部分内容。

操作周期

操作周期是车辆中的一个定义周期，也是DTC的脉冲。它确保DTC被创建并且也能恢复。

每个DTC的动态状态是根据ISO 14229-1:2013（UDS标准）定义的，它受到这个脉冲的驱动和依赖。

StatusOfDTC的位0到6描述了DTC当前在其生命周期中的位置。

Figure 3: The dynamic behavior of DTC in the vehicle

 上图显示了具有周期性监视器的DTC动态行为示例。该周期从“点火开启”开始。

错误存储器（事件存储器）The error memory (Event-Memory)
带有状态的错误代码仅足以处理简单的错误。对于更复杂的错误，还需要考虑环境条件，例如速度、温度、速度以及可能的其他内部信息，以更精确地分析错误。

DTC快照数据（冻结帧）DTC Snapshot Data (FreezeFrames)
通过ReadDataByIdentifier UDS服务，已经可以在没有DTC的情况下检索测量值。为了进行有意义的分析，测量值还必须与触发事件的确切时间相匹配。如果监视器报告“失败”，相关的DID将暂时存储其测量值。

 Figure 4: Details of DTC Snapshot Data (FreezeFrames)

快照记录的数据结构对应于来自ReadDataByIdentifier服务的一系列单独的DID。它与ODX存在很大的重叠。如果已知用于DTC的DID及其数据结构，则可以根据DEXT信息生成readDataByIdentifier和readDTC的ODX数据，反之亦然。

扩展数据

扩展数据块包含有关DTC的其他信息，例如周期计数器、老化计数器、最后出现的时间等，以及冻结帧数据中尚未包含的算法的动态数据。与DIDs类似，1字节的记录号指定了Extended Data块的数据结构。

 Figure 5: Details of DTC Extended Data

 Data块的数据结构。最多可以存在255个存储的扩展数据记录与DTC相关的信息。数据的解释由其RecordNumber明确定义。

更多与DTC相关的信息
快照数据和扩展数据的描述在原则上对于ODX和DEXT非常相似。然而，在DEXT中还有大量其他信息，例如严重性、去抖动、故障指示灯、功能抑制，这些在ODX中没有，但对于ECU中的DTC是强制性的。

诊断通信管理器（DCM）| The Diagnostic Communication Manager (DCM)
在通往测试仪的过程中，最后一步是DCM，它负责对数据进行编码和传输给测试仪。使用ReadDTC（0x19）UDS服务，DTC被编码为根据设置的DTC格式的两个或三个字节值，并通过车辆总线传输。

诊断测试仪中的DTC（ODX）| The DTC in the Diagnose Tester (ODX)
根据所选的0x19-ReadDTC子功能，除了DTC之外，还必须在测试仪中解码FreezeFrame或相应的ExtendedData信息。当然，基于DEXT的ECU中的UDS数据的编码必须与基于ODX的解码相同。

Figure 6: DTCs and associated data objects

Tester➇面临额外的挑战。首先，他必须找出具体的车辆，并从ODX中选择适当的车辆信息表（VIT）。然后，通过变体识别确定了车辆中安装的ECU的确切软件版本，或者在自适应AUTOSAR的情况下，确定了软件集群（SWC）。因此，每个ECU的ODX数据都包含了各种软件变体的必要解释。

除了数据解释和变体外，ODX中还存在其他数据，例如受众、语音信息和元信息，而这些在DEXT中缺失。

唯一的真相来源
ODX和DEXT是在实践中证明有效且广泛使用的交换格式。对于DTC，DEXT和ODX的大部分内容是等效的。然而，这两种格式都不包含DTC所需的所有必要信息。

DEXT反映了车辆电子设备的可变性。在ODX中，ECU的各种软件版本在车辆的整个生命周期内累积。

Figure 7: Uniform data assignment process for DTCs and DIDs

图7：DTC和DID的统一数据分配过程

如果将所有这些信息合并到一个共同的数据库中，就会创建唯一的真相来源。这确保了ODX和DEXT文件始终包含相同的信息，因此是一致的。
KPIT已经在其K-DCP ECU编辑器中实施了这些发现。软件开发人员可以专注于DTC的技术特性和相关信息，无需了解任何格式细节。然后，诊断开发人员输入其他与诊断相关的元数据（文本、变体等）。通过在KPIT ECU编辑器中共同存储这些数据，可以一键生成一致、无冗余和无矛盾的ODX和DEXT文件，并且还可以重新导入。

考虑到DTC的复杂性，以及其对扩展和冻结帧数据的依赖性，由于ECU的可变性和软件的变体而产生的多样性，这样一个具有单一共同数据库的共同流程几乎是必需的。有关更多信息，请参阅Hanser杂志2019年第10期的文章“自适应AUTOSAR中的诊断”。

---

在AUTOSAR诊断中，诊断故障码（DTC）表示车辆中检测到的某个问题（通常对生产或维修很重要）。

DTC由3个字节组成，并通过DiagnosticEventToTroubleCodeUdsMapping ARXML元素映射到诊断事件，从而使这些事件通过DTC代码唯一标识。

DTC用于在事件存储数据库中唯一标识数据。

DTC可以有多种解释，AUTOSAR诊断支持ISO 11992-4、ISO 14229-1:2013和SAE-J2012-DA。不同的解释只影响诊断报告，不影响功能。

多个DTC可以组合使用DiagnosticTroubleCodeGroup，以便诊断一次性处理组中的所有DTC。

DTC组使用超出有效DTC范围的专用DTC值进行标识。

为方便起见，诊断提供了名为“GroupOfAllDTCs”的DTC组（分配给DTC组标识符0xFFFFFF），其中始终包含所有配置的DTC

---

DID与DTC有什么区别和联系？

DID（诊断标识符）和DTC（诊断故障码）是与车辆诊断相关的两个不同概念。

DTC（诊断故障码）：

• 定义：DTC是由车辆的电子控制单元（ECU）生成的唯一代码，用于诊断特定组件或系统的故障。
• 作用：当车辆系统、传感器或组件出现问题或故障时，ECU会检测并分配特定的DTC来识别问题所在。
• 示例：例如，P0010表示进气凸轮轴位置执行器电路/开路（第1缸），P0102表示质量空气流量（MAF）电路低输入。

DID（诊断标识符）：

• 定义：DID是用于描述ECU内部参数、状态或功能的标识符。它不是故障码，而是用于访问ECU的特定信息。
• 作用：DID用于获取有关ECU的详细信息，例如传感器测量值、状态或配置。
• 示例：例如，DID 0x01表示引擎转速，DID 0x02表示冷却液温度。

总之，DTC用于诊断故障，而DID用于获取更详细的ECU信息。