DTC（诊断故障码，长度3字节），用来记录ECU发生故障时的故障信息，比如故障触发条件、故障解除条件、系统功能表现等。

ISO15031-6标准中规定了DTC的数据组成，DTC命名方式等信息。

DEM支持的DTC类型如下：

DTC的故障类型如下：

● 硬件故障：如RAM、Flash、CPU时钟等硬件本身失效的问题

● 软件故障：如配置字故障，标定故障或客户定义的软件功能性故障

● 外部环境故障：电压过高或者欠压、环境温度过高或过低等

● 通讯相关故障：如报文丢失、信号无效Checksum/AliveCounter故障等

DTC产生时，并不会直接存储在NVM中，而是间接通过Event-DTC的mapping关系来存储DTC，而DTC的状态位则是由其mapping的所有event的状态位的或集。只有DTC以及状态位信息往往不能一步到位定位故障的root cause，需要引入环境信息才能够进一步确定问题所在，包含：

● Snapshot Data：快照信息即为故障发生时刻存下来的瞬态的环境数据，一般是指电源模式、温度、时间戳、车速等信息

● Extended Data：即为在故障发生时其他的辅助故障信息，如aging counter、aged counter 、Fault Counter以及event id等

3.3

Event

Event是故障监控的基本单元，能够定位某个模块中的某个具体故障。

Event和DTC的区别

● 多个Event可以mapping 同一个DTC

● 而同一个Event不能mapping多个DTC

● DTC代表某类Event集中表现，而Event则是某个DTC的具体实例

● Event的优先级决定了DTC的优先级；Event之间的依赖关系决定了DTC的依赖关系

Event生命周期

一个事件从发现到老化需要经历多个阶段，例如Event使能条件满足后才能上报，DEM内部去抖且满足存储条件后才能存储，存储后需要进行老化处理。

Event Report

故障上报，SWC或者BSW向DEM报告诊断事件的状态。它由两个部分组成，一个是诊断事件（diagnostic event），一个是滤波（debounce）。DEM会给每个诊断事件分配一个独一无二的识别码（EventId），用来区分不同的事件。

Event上报流程

● 判断是否开启了Operation Cycle

● Event使能条件是否满足

● 是否使能了85服务（ControlDTCSetting）

● 去抖处理

● 判断存储条件是否满足

Event使能条件

Event开启监控绝大部分情况下都需要满足一定条件，若不加以相关的限制条件，那么会导致增加诸多的信息干扰，无法快速排查Root Cause，通过Event过滤器，可以达到所允许或者抑制的Event上报的效果。

Event上报方式

● 循环上报：不会被14服务清除，可实时监控故障状态，但上报的Event数量过多，增加RTE负载

● 触发上报型：能降低RTE负载，但也容易被14服务清除