前言

1.诊断故障基础

1.1 DTC的组成

1.2 DTC的意义

故障码有以下两点意义：

1）产线下线检测：一辆车的零部件的开发，系统集成，整车组装，其中涉及的流程之长，零部件数量之多，可以说是相当复杂。为了产线生产的车能正常下线，安全上路，就需要确保在车辆下线前，各零部件本身以及零部件相互配合是没有问题的。因此在产线电检流程中，会读取整车故障码，通过故障码说明车辆是否正常。

2）车辆维修：当车辆出故障时，维修工程师是如何快速定位到故障零部件呢？车辆是由上万个零部件组成，如果依赖于维修工程根据经验慢慢排查，效率会极其低下。因此，维修工程师会使用诊断仪读取整车故障码，并将故障码与故障现象对照，快速得出维修策略。

(资料图片)

1.3 DTC故障类型

以非排放相关的ECU为例，可以将DTC故障类型分为以下几个部分：

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

1.4DTC状态位介绍

1.5冻结帧与扩展数据

2.DEM详解

2.1 DEM主要功能

3. 故障确认后：故障的老化，替代，实现故障修复后，故障能被清除的功能。例如，仪表上的发动机故障灯，在发动机修好后一段时间后就会熄灭。

2.2 DEM与其他模块关系

1）DEM在AUTOSAR架构位置

Dem位于AUTOSAR架构系统服务层，系统服务层提供了以下服务：

1.操作系统调度与监控服务、

2.通信与网络管理服务

2）Dem与其他模块依赖关系

2.3 DEM核心Event

在介绍DEM的具体功能前，先引入概念“Diagnosticevent”，“Diagnostic event”也是DEM模块中最重要的元素。对于AUTOSAR软件架构，DTC只是展示给诊断仪使用者，而Event才是DTC状态实际操控者，同时Event也是诊断NVM数据存储实际控制者。

为什么要引入 “Diagnostic event”呢？

“Diagnostic event”来源？

“Diagnostic event”有哪些特性呢？

“Diagnostic event”怎么控制DTC?

“Diagnostic event”怎么控制诊断数据存储？

接下来将会给大家一一解答上述问题。

1）Event与DTC的联系与区别

1．描述层级：DTC是系统层面对于故障的描述，而Event是软件层面对故障监控的最小单元。

3.event之间的依赖关系决定了DTC的依赖关系；

2）“Diagnostic event的上报方式

3）“Diagnostic event”有哪些特性呢？

2.Event priority

对于诊断，能够存储的故障事件以及对应冻结帧等相关数据的数量是恒定的，需要软件开发工程师提前配置。当内部存储的故障事件已经满了，Event优先级可以解决新的故障事件如何存储的问题。

诊断事件优先级有下面几个重要特点：

2）Event优先级仅在诊断事件已经存满情况下发挥作用，其余情况根据FIFO原则存储。

3.Event occurrence

Event occurrence顾名思义就是故障事件上报计数器，故障上报次数越多，Event occurrence值越大，标志着该故障越“老”。“新”‘老’故障标签在后续新的故障事件如何存储的仲裁机制上也会发挥重要作用，这部分内容在后面的内容会详细说明。

1.每一个event memory entry都有对应的Event occurrence。

2.Event occurrence最大值为255。

3.Event occurrence的计数方式有如下两种配置选择：

2.4 EventMemory存储内容

上文对Event，冻结帧，扩展数据等作了详细描述，那么，这些数据在DEM中是怎么存储的呢？DEM提供了Event Memory概念，将Event，冻结帧，扩展数据全部归纳起来做了统一管理。废话不多说，开始探索Event Memory吧。

EventMemory分类：

Event Memory组成架构图

2.5 EventMemory management

当SWC或者BSW上报Event后，会经过哪些处理最终变成Flash中的Event Memory呢？

Event Memory management流程图

1）Event使能条件检测

Event使能条件流程图

S1:首先，需要判断当前是否开启了操作循环，操作循环一般指的是点火循环，一个操作循环可以认为是DTC检测的一个周期。如果操作循环开启了，则开始下列的Enable Condition判断，否则直接退出整个Event Memorymanagement流程。

S2:：EnableCondition判断指的是Event上报增加的一个附加条件判断，Dem通过对应的接口给SWC使用，SWC实现附件条件处理。一般可以用来处理一些电压，车辆模式等限制条件。如果Enable Condition条件满足，则进行85服务判断；如果Enable Condition条件不满足，则直接退出Event Memorymanagement流程。

S3: 若现在使用了85服务抑制DTC使能，则直接退出整个Event Memory management流程。若没有执行85服务，开始Event Debounce流程。

S4:经过Debounce后，如果最终Event结果为Pass或者Fail，则开始下一阶段Event控制DTC跳变；否则直接跳出退出整个Event Memory management流程。

本质上，Dem提供的Debounce为通过特定机制，处理PrePassed/Prefailed至Passed/Failed状态变化。

Dem提供了两种Debounce机制，即“Base Time”和“Base Counter”。

1.基于计数器的Debounce策略

基于Counter的Debounce策略的几个重要参数如下表格：

基于Couneter的Debounce机制

如上图所示，在基于Counter的Deboucne机制中，Dem会提供一个计数器（FDC）用于记录判断的结果，当SWC上报给Dem的Event状态为Prefialed，计数器会按照步长增加，当达到设定的限值时，故障状态变成Failed。当上报状态为PrePassed时，计数器按照步长减少，当达到设定的限值时，故障状态变成Passed。

2.基于时间的Debounce策略

基于时间的Debounce策略的几个重要参数如下表格：

基于时间的Debounce机制

3）Event 控制DTC状态更新

当Event经过一系列处理，最终能够对DTC状态进行更新，DTC 8个bit更新逻辑如下：

DTC Bit0 更新逻辑

DTC Bit0 更新逻辑图

DTC Bit1更新逻辑

DTC Bit2更新逻辑

DTC Bit2 更新逻辑图

DTC Bit3更新状态

DTC Bit3 更新逻辑图

DTC Bit4更新逻辑

DTC Bit4 更新逻辑图

DTC Bit5更新逻辑

DTC Bit6更新逻辑

DTCBit6更新逻辑图

DTC Bit7更新逻辑

DTCBit7更新逻辑

4）Retention条件检测

5）Event Memory Retention处理

基本思路如下：

Event Memory Retention处理机制

下图展示了整套Event Displacement机制，体现了三个核心原则在替换机制中的作用。

Event Displacement机制

总结

DEM是以DTC为核心的AUTOSAR基础软件模块，实现了对DTC的监控上报，存储等功能，如果需要对AUTOSAR诊断进行进一步学习，还需要对DCM，Doip，Cantp等模块进行系统性学习。

分享不易，恳请点个【】和【在看】

标签：