[汽车电子/UDS] DTC := 故障诊断码
概述： DTC := 故障诊断码DTC的定义
[*]DTC的全称是Diagnostic Trouble Code，即诊断故障码。
它是由车载诊断系统识别的故障状态的数字通用标识符。
[*]怎么理解呢？
可以去想象一个场景，如果我们的汽车在运行时出现的故障，我们很大可能会送去维修。
那么维修人员如何快速的定位到汽车出现故障的地方呢？这时候他们就会使用专业的诊断仪器直接读取出当前车辆的故障码。
他们之所以能读出故障码是因为汽车的车载控制器会时刻监控汽车的运行情况，在发现汽车故障的时候会将相关信息进行存储，维修人员通过【诊断仪】向汽车发送19服务（请求读取故障信息）的请求，车载控制器就会反馈对应的故障信息，而故障码DTC就是这些故障信息的身份ID。
DTC的组成
[*]DTC由3部分组成：DTC High Byte、DTC Middle Byte、DTC Low Byte(采用ISO15031-6定义的标准)。
其中DTC High Byte、DTC Middle Byte这两个字节表示故障内码，对应5位标准故障码。
下表为故障内码和5位标准码的位置对应关系。
下图是每一位故障标准故障码所代表的含义及分类。
[*]DTC Low Byte
描述了故障种类和子类型，该部分遵循ISO 15031-6，常见的timeout就用0x87来表示，一般对于排放相关的ECU的`DTC最低字节均为0x00，而对于非排放相关的ECU则需要参考ISO标准来定义。
[*]举例： 如P010016，第一位是P代表此故障码和动力系统相关，第二位是0.第三位是1，表示燃油和空气供应的测量相关，第四位和第五位是都是0，第六位和第七位16则是DTCLowByte的内容。
[*]`P010016：
二进制表示为：0000 0001 0000 0000 0001 0000
十六进制表示：0x10010
故障码的作用
故障码在汽车故障诊断和维修过程中具有多种重要作用。它们不仅有助于确保车辆的安全性和性能，还能提高维修效率和准确性。以下是故障码的主要作用：
[*]故障指示：当车辆出现故障时，相应的故障代码会被存储在电子控制单元（ECU）中。这些代码可以指示出故障的类型、位置和严重程度，帮助维修人员快速定位问题。
[*]故障诊断：通过读取和分析故障代码，维修人员可以了解车辆出现故障时的具体状况和可能的原因。这有助于制定准确的维修方案，避免盲目拆卸和更换零件。
[*]维修指导：故障代码通常与特定的维修程序相关联。维修人员可以根据故障代码查找相应的维修手册或技术指南，获取针对该故障的详细维修步骤和建议。
[*]预防性维护：通过分析历史故障代码数据，可以了解车辆在过去出现过的故障类型和频率。这有助于预测未来可能出现的问题，并制定相应的预防性维护计划，降低故障发生的风险。
[*]提高维修效率：故障代码的存在使得维修人员能够更快地找到并解决问题，减少了诊断时间和维修成本。同时，故障代码的标准化和通用性也有助于不同维修人员之间的交流和协作。
总之，故障码在现代汽车故障诊断和维修中发挥着至关重要的作用，它们为维修人员提供了准确、快速和有效的故障诊断和维修指导。
汽车上常见的故障码
汽车上常见的故障码有很多种，这些故障码是由车辆的电子控制系统生成的，用于指示车辆各个系统中出现的故障或问题。以下是一些常见的汽车故障码及其相关的系统故障：
[*]P0100系列代码：与燃油和空气计量有关。例如，P0101表示空气流量计线路不良，P0102表示空气流量计线路输入电压太低，P0103表示空气流量计线路输入电压太高，P0104表示空气流量计线路间歇故障等。
[*]P0200系列代码：也与燃油和空气计量有关。这些代码可能涉及燃油喷射、燃油泵或相关传感器的问题。
[*]P0300系列代码：与点火系统和缺火状态有关。例如，P0300表示多个气缸缺火，P0301表示第一缸缺火等。
[*]P0400系列代码：与辅助排放控制系统有关。这些代码可能涉及氧传感器、三元催化器、EGR阀等排放控制部件的故障。
[*]P0500系列代码：与车速、怠速控制系统和辅助输入有关。例如，P0500表示车速传感器故障，P0501表示车速传感器范围/性能问题等。
[*]P0600系列代码：与控制单元内部故障或在多路通信系统内连接控制单元和其他控制模块的专用电路有关。例如，P0600表示控制单元内部故障，P0601表示内部控制模块存储器检查错误等。
[*]P0700系列代码：与变速箱控制功能有关。这些代码可能涉及变速箱传感器、执行器或控制单元的故障。
需要注意的是，以上只是汽车故障码的一小部分示例，实际中汽车可能出现的故障码种类非常多。不同的汽车制造商和车型可能会有一些特定的故障码定义。当车辆出现故障时，最好使用专业的故障诊断工具来读取和解析故障码，以便更准确地确定故障原因并进行维修。
如何处理DTC故障码
处理DTC故障码主要包括以下几个步骤：
[*]故障码读取：在进行DTC故障处理之前，首先需要通过汽车诊断仪或者车载诊断系统读取故障码。故障码的读取可以帮助技师快速定位故障的位置和原因，从而有针对性地进行修复。
[*]故障码解读：每个故障码都有其特定的含义，可以通过故障码手册或者在线数据库查询相应的解释。故障码的解读可以帮助技师了解故障的性质、严重程度和可能的原因。
[*]故障修复：根据故障码的含义和解读，技师可以定位到具体的故障部件或系统，并进行相应的修复。这可能涉及到更换故障部件、修复电路连接、更新软件等。
[*]故障码清除：在故障修复完成后，需要利用解码仪或其他诊断工具清除电控单元内的故障码。这样，DTC灯才会熄灭，车辆的诊断系统也会重新恢复正常状态。
另外，有些情况下，DTC故障可能是由于临时的操作或环境条件引起的，而不是由于实际的硬件故障。在这种情况下，可以尝试重新启动发动机，按下车辆上的DTC开关按键，重新开启DTC，看是否能够消除故障码。
DTC状态掩码 / DTC状态位定义
[*]这一小节介绍与 19服务（ReadDTCInInformation ）一起使用的 DTCStatusMask / statusOfDTC 参数的映射。
每个服务器都应遵循下表中定义的存储位打包 DTC 状态信息的约定。位域的实际用法应在实施标准中定义。
[*]TestFailed 位的状态不应直接链接到与监视器状态关联的故障安全行为。
这意味着为了触发与某个监视器的状态相关的故障安全行为，需要维护一组单独的状态位。
车辆制造商应定义是否以及如何应用和实施DTC状态和故障安全相关监视器状态之间的任何同步机制。
DTC状态位
位名称定义简单理解bit 0testFailed指示最近执行test的结果，test失败（Failed）置1，test通过（Passed）则置0，如果调用了14服务清除DTC的话，也需要重新置0。最近的一次测试是否失败，0：没有失败，1：失败了bit 1testFailedThisOperationCycle该位表示在当前test中，诊断test是否已经报告了一个testFailed结果。在当前操作循环内的测试结果，该操作循环内只要发生过failed，则置“1”；开始新的操作循环或发送清故障码服务后，置“0”。当前循环，故障检测是否失败。0：没有失败，1：失败了至少一次bit 2pendingDTC在当前操作循环或上一个完成的操作循环内，测试是否报告过“Failed”；该状态位只在测试运行和操作循环完成后在该操作循环内从未“Failed”过或发送清故障码服务后才置0；如果在当前操作循环内未完成测试，则状态不变。pending处于TestFailed和Confirmed的中间状态。是否有待处理的故障，0：没有待处理的故障，1：有bit 3confirmedDTC表示故障是否检测到足够的次数，以保证DTC存储到long-term memory中。若足够，则置“1”；表为1的时候并不意味着此刻故障存在（testFailed可用于确定请求时是否存在故障）。发送清除故障码或达到aging阈值（40个warm-ups循环里未检测到故障）则置“0”。故障是否确认，0：没有确认，1：确认了bit 4testNotCompletedSinceLastClear表示一个DTC测试从上次清故障码开始，是否运行过或完成过测试；若没有，则置“1”；否则置“0”；清故障码置“1”。清除DTC之后，是否完成过故障检测，0：完成了，1：没有完成bit 5testFailedSinceLastClear表示一个DTC测试从上次清故障码开始，是否测试失败过；若没有，则置“0”；否则置“1”；清故障码置“0”。清除DTC之后，故障检测是否失败，0：没有失败，1：失败过，0的情况下，也可能是故障检测没有完成。bit 6testNotCompletedThisOperationCycle表示一个DTC测试在当前操作循环内是否运行完成；若没完成，置“1”；否则，置“0”；开始新的操作循环或清故障码后则置“1”。当前循环，是否完成故障检测，0：完成了，1：没有完成bit 7warningIndicatorRequested报告与特定DTC相关的任何警告指示器的状态；没有警告，则置“0”；有警告，则置“1”；如果有警告，则confirmedDTC也应设置为1；清故障码或满足制造商定义的要求，则置“0”。ECU是否请求点亮警告灯，0：没有请求，1：请求了DTC Aging (DTC 老化)
此段转载于: 漫谈DTC之DTC老化 - 东信创智的文章 - 知乎
[*]在诊断系统设计时，我们需要设置每一个DTC的"故障恢复条件"。简单的理解就是满足一定的条件，系统会认为从故障中恢复。
例如：欠电压故障（又称“电压过低故障”）
[*]故障的设置条件：Voltage < 9V；t > 500ms。
[*]故障的恢复条件：9.5V < Voltage < 18V；t > 500ms。
[*]我们认为达到故障的恢复条件即为TestPassed。那么问题来了：是不是达到了这个条件，系统就会清除这个DTC呢？答案是否定的。故障的设置条件中需要增加一个自恢复（self-healing）的条件。
原因是，车辆行驶的过程中所记录的DTC，并不会一直被记录下去，而是需要通过一个过程。当一直处于TestPassed，才可将这个DTC清除掉，这个过程的结果被称为self-healing，而这个过程，我们就叫做DTC的老化。
DTC设计条件
[*]DTC的老化是一个过程，这个过程是以循环周期作为单位。有几种周期被采用：
[*]上下电作为一 个循环周期；
[*]warm-up作为一个循环周期。
注：warm-up是指发动机预热达到某个预设温度。warm-up循环一般是针对排放相关DTC所设定的循环周期。
[*]在诊断自恢复过程中，往往我们会定义30个或40个循环周期作为自恢复的条件。
原因是，在一个相对较长的过程中，如果车辆没有发生这个故障，我们可以认为这个故障是一个偶发的现象，也可以认为现在的车辆处于一个相对稳定的状态。因而，可以将这个故障码清除。
DTCAgingCounter 例子
[*]DTCAging计数器在完成测试未失败的操作周期后递增，DTCAging计数器开始计数的条件是：testFailed=0,PendingDTC= 0,ComfiredDTC=1。
[*]pendingDTC=0的条件是在一个操作周期后测试完成且未失败（testNotCompleted-ThisOperationCycle = 0，tesetFailed = 0，tesetFailed-ThisOperationCycle=0）。如果ECU不支持掉电顺序（即在关闭点火开关时立即关闭），则将无法检测到操作周期的结束。因此，在下一个操作周期开始时将pendingDTC设置为零也是有效的。
[*]DTCAging计数器在完成测试未失败的操作周期后递增。ttestNotCompleted-ThisOperationCycle = 0，tesetFailed = 0。
[*]DTCAging计数器继续递增，因为测试在这些操作周期中没有失败。tesetFailed = 0。
[*]当完全满足老化标准时（例如，DTCAging计数器达到特定值），confirmedDTC 设置为零，DTC会从内存中清除掉。
[*]DTCAging计数器达到最大值（例如，40），此时confirmedDTC 被清除。
[*]车辆制造商有责任指定testFailedSinceLastClear位是否通过老化标准或由于故障存储器溢出而重置。
UDS统一诊断服务-读取DTC信息(0X19服务)
UDS 统一诊断服务 及其 0x19服务(读取DTC)
[*]UDS（Unified Diagnostic Services）统一诊断服务中的0x19服务是用于读取诊断故障代码（DTC，Diagnostic Trouble Code）信息的服务。
DTC是车辆故障诊断系统中的重要部分，当车辆发生故障时，相应的DTC会被存储在ECU（电子控制单元）的故障代码存储器中。
0x19服务包含了多个子服务，每个子服务用于读取不同类型的DTC信息。以下是其中一些常用的子服务：
[*]0x01子服务：读取符合特定掩码条件的DTC数量。客户端可以定义掩码来筛选要读取的DTC类型，例如当前故障、历史故障或全部故障。
[*]0x02子服务：读取符合特定掩码条件的DTC列表及其状态。与0x01子服务类似，客户端可以使用掩码来筛选要读取的DTC。
[*]0x04子服务：读取与特定DTC关联的已存储数据记录，即DTC快照信息。这些信息提供了故障发生时的车辆状态和参数，有助于诊断工程师定位和解决问题。
[*]0x06子服务：读取指定DTC的扩展信息。扩展信息可能包括与故障相关的额外数据或故障代码的解释。
[*]0x0A子服务：读取ECU支持的所有DTC列表及其状态。这个服务不需要掩码，它会返回ECU中存储的所有DTC信息。
[*]通过0x19服务，诊断服务工程师可以检索存储在车辆ECU中的DTC信息，进而对车辆进行故障诊断和维修。
这些DTC信息对于确保车辆的安全和性能至关重要，因此，UDS统一诊断服务在汽车行业中得到了广泛应用。
UDS交互过程案例
[*]在UDS（Unified Diagnostic Services）诊断协议中，与ECU（电子控制单元）的交互命令通常是按照ISO 14229标准来定义的。
这些命令被封装在CAN（控制器局域网）消息中，并通过特定的服务标识符（Service ID）来区分。
以下是一些UDS诊断服务及其交互命令的例子：
[*]诊断会话控制（0x85）
[*]命令示例：0x85 0x01- 请求进入默认会话（Default Session）
[*]响应示例：0x65 0x01- 表示成功进入默认会话
[*]读取DTC信息（0x86）
[*]命令示例：0x86 0xF1 0x00- 请求读取所有已存储的DTC
[*]响应示例：0x66 0xF1 0x01 0x23- 表示有一个DTC（例如0x23）已存储
[*]清除DTC信息（0x84）
[*]命令示例：0x84- 请求清除所有DTC
[*]响应示例：0x64- 表示清除操作成功
[*]读取数据流（0x8D）
[*]命令示例：0x8D 0x02 0x01- 请求读取PID（参数标识符）为0x0201的数据流
[*]响应示例：0x6D 0x02 0x01 0x5A- 表示PID 0x0201的当前值为0x5A
[*]写入数据（0x87）
[*]命令示例：0x87 0x02 0x01 0x33- 请求将PID为0x0201的数据写入值为0x33
[*]响应示例：0x67 0x02 0x01- 表示写入操作成功
[*]例程控制（0x31）
[*]命令示例：0x31 0x01 0x01- 请求执行例程（Routine）编号为0x0101的特定操作
[*]响应示例：0x71 0x01 0x01- 表示例程执行成功
[*]安全访问（0x27）
[*]命令示例：0x27 0x01- 请求种子（Seed）以进行安全访问
[*]响应示例：0x67 0x01 0xA5 0xB6 0xC7 0xD8- 提供种子值（例如0xA5B6C7D8）
[*]后续命令：0x27 0x02 A5 B6 C7 D8 EE FF- 使用收到的种子和密钥（例如0xEEFF）进行安全访问
请注意，这些示例中的数值（如PID、DTC代码、例程编号等）都是假设的，实际应用中会有不同的值。此外，UDS命令的响应可能会包含额外的数据，如状态代码、DTC状态掩码等，具体取决于服务的定义和实现。
在实际应用中，诊断工具（如诊断仪或诊断软件）会负责生成和解析这些CAN消息，使得技术人员能够通过用户友好的界面与ECU进行交互。
X 参考文献
[*]汽车诊断中常说的DTC是什么？ - CSDN
[*]UDS统一诊断服务读取DTC信息0X19服务 - 网易
本文作者： 千千寰宇
本文链接： https://www.cnblogs.com/johnnyzen
关于博文：评论和私信会在第一时间回复，或直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
日常交流：大数据与软件开发-QQ交流群: 774386015 【入群二维码】参见左下角。您的支持、鼓励是博主技术写作的重要动力！
来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除
页:
[1]