DTC相关内容梳理

前言

  为了了解DTC相关知识，博主也翻看了很多博主的文章，因为DTC涉及的知识点很多，所以大部分文章都介绍的比较散，为了后期查找方便，防止遗忘，也是对DTC内容的梳理，博主将大佬们的文章进行了整理。对于DTC，博主也是小白一个，如果文章中有不尽不实的地方，也请同学们在评论中指出，大家一起探讨进步，谢谢！（不定时更新）

参考

1、汽车诊断中常说的DTC是什么
2、《UDS协议从入门到精通》系列——到底什么是DTC？
3、UDS DTC老化机制
4、【AutoSar_诊断协议栈】Dem模块详解（2）_Event和DTC详解
5、深度解读：车辆诊断之DTC的状态位

一、DTC的定义

  DTC全称（Diagnostic Trouble Code）即诊断故障码，它是由车载诊断系统识别的故障状态的数字通用标识符。
  如果车出现了故障时，维修人员可以通过专业的诊断仪器直接读取出当前车辆的故障码。他们之所以能读出故障码是因为汽车的车载控制器会时刻监控汽车的运行情况，在发现汽车故障的时候会将相关信息进行存储，维修人员通过诊断仪向汽车发送19服务（请求读取故障信息）的请求，车载控制器就会反馈对应的故障信息，而故障码DTC就是这些故障信息的身份ID。

二、DTC的组成结构

  DTC由三部分组成：DTC High Byte、DTC Middle Byte、DTC Low Byte(采用ISO15031-6定义的标准)。其中DTC High Byte、DTC Middle Byte这两个字节表示故障内码，对应5位标准故障码。下表为故障内码和5位标准码的位置对应关系

  下图是每一位故障标准故障码所代表的含义及分类:

   DTCLowByte描述了故障种类和子类型，常见的timeout就用0x87来表示。关于DTCLowByte的内容可参考：

DTCLowByte

举例DTC：D14C51
对应的故障内码：0xD14C（二进制：1101000101001100）
对应的五位标准故障码：U (11) 1 (01) 1 (0001) 4C
对应的DTCLowByte ：“0x51”

三、DTC状态位

1、DTC状态位概述

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

2 、DTC状态位跳转变化

• bit 0:
  
    置1条件：表示当前发出请求时故障存在（当前FDC10达到或超过了正向阈值，一般为127）。
    置0条件（①or②）：
    ①14服务清除DTC；
    ②当前请求时故障不存在（当前FDC10达到或低于负向阈值一般为-128）。

testfailed状态位在ETAS工具中可以配置是否存储到Memory中如下图所示

• bit1:
  

  置1条件：在当前operation cycle中的任意时刻，只要出现了testFailed，此位就会置1。
  置0条件（①or②）：
  ①新操作循环开始时此位清0；
  ②14服务清除；

• bit2:
  

  置1条件：
  ① 在当前operation cycle中的任意时刻，只要出现了testFailed，此位就会置1。
  ②（未执行14清除服务）在上个操作operation cycle中出现过testFailed，则在新operation cycle中此位保持1
  置0条件（①or②）：
  ①在某个operation cycle已完成且当前operation cycle已经成功完成过测试(bit6=0)且在当前operation cycle测试通过(bit1 = 0)时清0

根据下面测试过程可以看出，pending清0操作是在下一operation cycle的开始执行的

  ②14服务清除；

pending位实测结果：
operaction cycle1：
failed(0x27)$\to$passed(0x26)，
pending：0 $\to$ 1 ；
下电
operaction cycle2：
DTC状态：0x64；pending = 1；
passed（0x24），
下电
operaction cycle3：
DTC状态：0x60；pending = 0

• bit3:
  
    置1条件：
    当故障检测计数器OCC4达到或超过confirmDTCLimit时，该位被置1
    置0条件（①or②or③）：
    ①当DTC达到老化阈值时清0
    ②14服务清0
    ③当故障记录由于故障内存溢出而被更新或覆盖时 。

confirmedDTC =1时故障不一定存在（即testFailed此时可能为0）

• bit4:
    置1条件(①or②)：
    ①从上次调用14服务以来，DTC测试未完成时，即FDC10未达到-128（Passed）或127（Failed）
    ②14服务清除
    置0条件：
    从上次调用14服务以来，完成过DTC测试，无论结果是Passed还是Failed。
• bit5:
  
    置1条件：
    从上次调用14服务以来，至少出现过一次testFailed,该位被置1
    置0条件(①or②or③)：
    ①在上次调用0x14服务清除DTC后，若DTC未进行测试或者测试了但结果是passed时置0
    ②14服务清除
    ③达到老化阈值被老化
• bit6:

  置1条件(①or②or③)：
  ①在当前operation cycle中测试未完成，即FDC10未达到Failed(127)或者Passed(-128)
  ②14服务清除后
  ③新operation cycle开始时清0
  置0条件：
  在当前operation cycle中成功完成过DTC的测试

• bit7:

  置1条件：
  当DTC Failed且满足警告指示灯开启条件时，该位被置为1.
  置0条件：
  14服务清除

四、DTC附属信息和术语

1、常见术语

1.1 操作周期(OCC:Operation Cycle)

  常见的操作周期有以下几种类型操作周期

操作循环的类型	描述
DEM_OPCYC_IGNITION	KL15电on与off之间的循环，也叫点火循环
DEM_OPCYC_POWER	KL30电on与off之间的循环，可以理解为ECU从完全断电到供电的过程。
DEM_OPCYC_OBD_DCY	Master ECU通过总线提供driving cycle的信息。Primary ECU不应当内部计算driving cycle。
DEM_OPCYC_WARMUP	warm-up是指发动机预热达到某个预设温度。warm-up循环一般是针对排放相关DTC所设定的循环周期

具体的关于操作周期的描述可看下篇文章：
诊断基础：如何理解Operation Cycle？

1.2 错误检测计数器(FDC:Fault Detection Counter)

  FDC的步长可以设定，向上(Step up)或者向下(Step down)均可以设置，计数范围一般为 -128~127，不同DTC需要的滤波次数不一致。同时还可以设置jump down或者jump up(即在检测通过时是否跳转到0或者其它数，并从这个数开始向下减)

在ISOLAR工具中，相关配置在Debounce中，详细配置可见此篇文章：
DTC故障Debounce策略

1.3 确认阈值(confirmation Thresold)

AutoSar中配置项为DemEventConfirmationThreshold定义了DTC的状态字节bit3：ConfirmedDTC置1时所需要的测试失败的Operation Cycle。

常见的confirmedDTCLimit和confirmation Thresold含义相同

1.4 unconfirmedDTCLimit

  此值通常与冻结帧的捕获时机相关，在工具中配置snapshot的更新时，有选项DEM_TRIGGER_ON_FD
C_THRESHOLD(即为：FDC $\ge$ unconfirmedDTCLimit时采样冻结帧数据)。
  有人可能会问，在这个时间点故障还没有出现，为什么采集冻结帧。因为在实际工况中，某些Event关联的冻结帧数据变化频率快，如果等到Event完全成熟再去捕获，所捕获的冻结帧数据可能已经没有太大的分析价值了，所以可以提前采样快照数据。

详细可参见此篇文章诊断基础：你还见过怎样的快照数据(Snapshot Data)采样和存储策略？

  在工具中，unconfirmedDTCLimit可通过配置项DemRbDebounceCounterFdcThresholdStorageValue配置。

1.5 DTC老化(DTC Aging)

  老化概念：当某个DTC在一定次数的操作循环内不在出现时，将存储中关于这个DTC的信息从内存中清除的行为称为老化

1.5.1 老化计数(Aging Counter)

  连续报告没有故障的Operation Cycle数.。（Aging Counter开始计数的条件是：testFailed=0，PendingDTC=0,ConfiredDTC=1）

1.5.2 老化条件

• 诊断故障已经存在在primary memory中
• 在连续的aging cycle中，诊断故障结果都为passed
• operation cycle次数增加，aging counter累加，当aging counter大于等于DemAgingCycleThreshold（老化阈值）时，该故障会老化，从primary memory中消失

1.5.2 已老化计数(Aged Counter)

  报告一个DTC已经被老化的次数。当aging counter $\ge$ DemAgingCycleThreshold 时，Aged Counter加1。

2、附属信息

2.1 DTC快照信息(Snapshot)

  比较详细的大家可以看下面这篇文章
诊断基础：快照数据与DTC关系及存储时机
这个大佬很多文章都很值得一看。本文中做概要性介绍。

2.1.1 DTC和Event是什么？

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

2.1.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的状态位的或集。
  

2.1.3 Snapshot快照数据

  DTC快照信息（Snapshot Record） 就类似照相机一样，在故障发生的时刻，对整车信息按下快门，做个记录，以便后续分析问题。常见一些数据有：故障发生时的时间戳、ECU电压值、电流值、温度或者由故障Event引起的相应DTC等等。
  由于Event和DTC之间存在多对一的关系，通过Snapshot数据，也可以进一步区分这个DTC具体是由哪个Event触发的。

eg:CAN收发器故障。这个故障事件可能因为多种因素诱发，比如：欠压、过温等。为了区分出到底是欠压还是过温引起的CAN收发器故障，就需要将故障发生时的这些信息捕获出来，如下所示：

2.1.4 Snapshot快照数据捕获

  在故障发生时，需要将与故障关联的数据记录下来，在软件层面，这些数据例如温度、电压等就被定义为一个个的变量，为了更好的区分和识别这些变量，为每个变量分配一个独有的DID(Data Identifier,数据标识符)。

  当Event发生故障时，预期关联的DTC#1(例如D14B51)将相关的变量信息（例如DID:F001）一并存储到NVM中。后续问题排查时，通过上位机发送19 04服务读取对应DTC的快照数据，进行分析和问题定位。
  因为DTC关联的DID多且不同DTC可能服用相同的DID，那么如果每个DTC都去一一对应这些DID的话操作上就比较冗余。所以为了便于处理与维护，在工程上常常将一系列DID进行分组，这些分组称之为快照组（Snapshot Group）。
  为了区分不同的Snapshot Group，可以为每个Snapshot Group分配一个识别号，即DTCSnapshotRecordNumber。
  UDS要求，DTCSnapshotRecordNumber由1 byte组成，0x00一般预留给OBD协议使用，0xFF表示ECU一次将所有的快照数据上报，0x01~0xFE由OEM自行设定。
  一个DTC可关联一个或多个快照组甚至不关联快照组：

部分配置工具不支持一个DTC关联多个快照组。

2.1.5 Snapshot快照数据捕获时机

  在AutoSAR DEM规范中定义了以下几种快照数据捕获时机：

在实际工作中遇到客户提供的诊断需求表中关于Snapshot的描述中有Snapshot Data Identification：Snapshot DID 2100这种，找到了大佬的解释

2.2 DTC扩展信息(Extended Data)

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