摘要：
DEM是以DTC为核心的AUTOSAR基础软件模块，实现了对DTC的监控上报，存储等功能，如果需要对AUTOSAR诊断进行进一步学习，还需要对DCM，Doip，Cantp等模块进行系统性学习。
前言
Dem是AUTOSAR中配置项最多，实现功能最为复杂的模块之一，主要负责记录故障诊断以及其关联数据，是实现诊断功能至关重要的模块，本文将以最简单的方式将Dem的功能聊具体，聊透彻。为了方便大家学习，以下是本文的大纲。
1.诊断故障基础
当人患了疾病，便需要医治，医生根据各种检验结果找出病因，并得出诊治策略。当汽车出现故障时，DTC故障码就等同于“检验结果”，汽车工程师通过该标识码便可以查表的方式获得该故障信息，如故障触发条件、故障解除条件、系统功能表现等，得出解决该故障的策略。
DTC（Diagnostic Trouble Code）顾名思义诊断故障码，一种用来记录当ECU发生或者检测到某种故障时呈现给大家的标识码。
1.1 DTC的组成
DTC故障码是一个4个字节的标识符，由以下两部分组成：DTC Catogory 与Failure Type，其中DTC Catogory 又可以根据Powertrain、Body、Chasis、N etwork四大子系统来进一步定义其范围，简称PBCU四大子系统，如下表所示：
1.2 DTC的意义
故障码有以下两点意义：
1）产线下线检测：一辆车的零部件的开发，系统集成，整车组装，其中涉及的流程之长，零部件数量之多，可以说是相当复杂。为了产线生产的车能正常下线，安全上路，就需要确保在车辆下线前，各零部件本身以及零部件相互配合是没有问题的。因此在产线电检流程中，会读取整车故障码，通过故障码说明车辆是否正常。
2）车辆维修：当车辆出故障时，维修工程师是如何快速定位到故障零部件呢？车辆是由上万个零部件组成，如果依赖于维修工程根据经验慢慢排查，效率会极其低下。因此，维修工程师会使用诊断仪读取整车故障码，并将故障码与故障现象对照，快速得出维修策略。
1.3 DTC故障类型
以非排放相关的ECU为例，可以将DTC故障类型分为以下几个部分：
硬件故障：如RAM、Flash、CPU时钟等硬件本身失效的问题软件故障：如配置字故障，标定故障或客户定义的软件功能性故障外部环境故障：电压过高或者欠压、环境温度过高或过低等通讯相关故障：如报文丢失、信号无效，Checksum/Rolling 障等
1.4 DTC状态位介绍
每个DTC都有一个字节用来表示该故障的状态，这个字节中每个bit的含义如下：
| status Of DTC: bit field name |
Bit | Bit state | Description |
| testFailed | 0 | 0 | DTC is not failed at the time of the request |
| testFailedThisOperationCycle | 1 | 0 | DTC failed during the current operation cycle |
| pendingDTC | 2 | 0 | DTC was not failed on the current or previousoperation cycle |
| confirmedDTC | 3 | 0 | DTC is not confirmed at the time of the request |
| testNotCompletedSinceLastClear | 4 | 0 | DTC test was completed since the last code clear |
| testFailedSinceLastClear | 5 | 0 | DTC test never failed since last code clear |
| testNotCompletedThisOperationCycle | 6 | 0 | DTC test completed this operation cycle |
| warningIndicatorRequested | 7 | 0 | Server is not requesting warningIndicator to beactive |
具体解释如下：
Bit0:请求时刻测试结果为失败；Bit1:在当前点火循环至少失败过1次；Bit2:在当前或者上一个点火循环测试结果不为失败；Bit3:请求时刻DTC被确认，一般确认是在一个点火周期内发生错误1次；Bit4:自上次清除DTC之后测试结果已完成，即测试结果为PASS或者FAIL结果；Bit5:自上次清除DTC后测试结果都不是FAIL;Bit6:在当前点火周期内测试结果已完成，即为PASS或FAIL状态；Bit7:ECU没有得到点亮警示灯请求
1.5冻结帧与扩展数据
从上文可知，DTC中8bit位可以描述DTC状态，但8个bit位能够承载的信息是有限的，仅能说明故障是当前故障还是历史故障。故障发生时的车速，温度，油量，电量等关键信息怎么记录呢？
UDS中规定了冻结帧可以用来记录故障发生时的详细情况，扩展数据可以提供故障码相关的扩展信息，包括老化计数器。
| 类型 | 组成 | 内容 |
| 冻结帧 | 由一系列DID组成，用户可以自定义DID内容 | 描述车速，温度，油量，等信息 |
| 扩展信息 | 由一系列DID组成，DID内容由BSW规定 | 描述故障码的额外信息，比如老化周期数量。 |
2.DEM详解
2.1 DEM主要功能
Dem全称Diagnostic Event Manager，负责诊断故障事件的处理，存储诊断故障事件以及故障事件相关联的数据（故障发生时温度，车速等）。简而言之，Dem发挥了AUTOSAR架构中故障”中央处理器作用”，用户软件模块只需要将故障上报给DEM，所有故障信息的处理都由DEM执行：
1.故障确认前：用户模块上报故障的Debounce防抖处理，确保对应故障不为误报故障。
2. 故障确认时：故障事件确认时的故障数据存储至NVM，保证故障能长期保存。
3. 故障确认后：故障的老化，替代，实现故障修复后，故障能被清除的功能。例如，仪表上的发动机故障灯，在发动机修好后一段时间后就会熄灭。
2.2 DEM与其他模块关系
1）DEM在AUTOSAR架构位置
Dem位于AUTOSAR架构系统服务层，系统服务层提供了以下服务：
1.操作系统调度与监控服务、2.通信与网络管理服务3.存储服务4.诊断服务（UDS通信服务以及故障服务）5.ECU状态管理服务
从下面架构图可以看出，Dcm与Dem作为“诊断双雄”，完整提供了所有的诊断服务。区别在于，Dcm主修“UDS诊断通信服务”，对下与通信协议栈联系，与外部诊断仪交互提供诊断通信服务（10,22等服务）；Dem主修故障诊断服务，与上层SWC，BSW模块交互，接收故障上报，与NVM交互使用存储功能。
AUTOSAR架构图
2）Dem与其他模块依赖关系
Dem与其他模块关系链路图
NVM: Nvm能够提供存储服务给Dem使用，即提供诊断故障存储所需的NVM BLOCK。需要注意的是，Nvm给Dem提供了两类存储服务接口，Nvm_WriteBlock()供DEM实时存储诊断故障，NvM_SetRamBlockStatus()供Dem下电存储诊断故障，上述存储模式可以在DTC配置属性中体现。
DCM:从上图中可以看出，DCM在接收到诊断仪的19服务（get Dtc），14服务（Clear Dtc）时，需要实时通过Dem获取DTC数据以及对DTC进行清除操作。
ECUM：对Dem模块执行初始化以及ShutDown操作。
SWC(Monitor)：监控诊断故障事件Event,通过使用Dem_SetEventStatus()函数，将Event状态上报给Dem。使用Dem_SetOperationCycleState()对操作循环状态进行控制。
2.3 DEM核心Event
在介绍DEM的具体功能前，先引入概念“Diagnostic event”，“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是软件层面对故障监控的最小单元。
例子：某个电机故障会由电压过高造成，但软件是无法直接识别该故障,软件只能监控是否产生了电压过高的时间Event,从而计算出是否产生DTC.
2.链接关系：多个event可以mapping 同一个DTC；而同一个event不能mapping 多个DTC；
3.可见度：DTC可以直接可见，但Event需通过进一步手段才能看到，有时仅对ECU供应商可见；
联系：
1.DTC代表某类event集中表现，而event则是某个DTC的具体实例；2.event的优先级决定了DTC的优先级；3.event之间的依赖关系决定了DTC的依赖关系；
2）“Diagnostic event的上报方式
上文提到了SWC监控故障Event的状态，并可以通过Dem_SetEventStatus(EventId,EventStatus)向DEM上报Event状态。那么对于SWC，应该怎样上报Event状态呢？周期调用Dem_SetEventStatus上报即为周期循环上报；当Event状态变化时，调用Dem_SetEventStatus上报为触发上报。两种上报方式各有优缺点，如下图所示，切不可一刀切。
一般来说，对于小型控制器，需要上报Event数量不多，可以选择周期循环上报。对于域控制器，需要上报的Event数量庞大，为了保证负载率稳定，应该选择触发上报。
3）“Diagnostic event”有哪些特性呢？
1.Event Kind
Event Kind根据故障事件上报方式可分为：BSW Event与SWC Event。
| Event Kind |
来源 | 上报方式 | 函数名 |
| BSW Event | BSW模块 | 标准C接口 | Dem_ReportErrorStatus |
| SWC Event | SWC模块 | RTE接口 | SetEventStatus（RTE） |
2.Event priority
对于诊断，能够存储的故障事件以及对应冻结帧等相关数据的数量是恒定的，需要软件开发工程师提前配置。当内部存储的故障事件已经满了，Event优先级可以解决新的故障事件如何存储的问题。
一般来说，诊断优先级的设定由诊断系统工程师从整车功能出发，根据诊断故障的重要性,安全性，严重性综合评估。比如汽车的动力故障远比空调故障严重，所以动力相关故障优先级一般会大于空调相关故障。
诊断事件优先级有下面几个重要特点：
1）诊断事件优先级数值越小，优先级越高，数值为1优先级最大。2）Event优先级仅在诊断事件已经存满情况下发挥作用，其余情况根据FIFO原则存储。
3.Event occurrence
Event occurrence顾名思义就是故障事件上报计数器，故障上报次数越多，Event occurrence值越大，标志着该故障越“老”。“新”‘老’故障标签在后续新的故障事件如何存储的仲裁机制上也会发挥重要作用，这部分内容在后面的内容会详细说明。
Event occurrence存在以下特点，如下所示：
1.每一个event memory entry都有对应的Event occurrence。
2.Event occurrence最大值为255。
3.Event occurrence的计数方式有如下两种配置选择：
| 配置属性 | 计数方式 |
| DEM_PROCESS_OCCCTR_TF | Bit0（TestFail）由0跳变至1，Event occurrence +1 |
| DEM_PROCESS_OCCCTR_CDTC | Bit0（TestFail）由0跳变至1和Bit3由0跳变至1，Event occurrence +1 |
2.4 Event Memory存储内容
上文对Event，冻结帧，扩展数据等作了详细描述，那么，这些数据在DEM中是怎么存储的呢？DEM提供了Event Memory概念，将Event，冻结帧，扩展数据全部归纳起来做了统一管理。废话不多说，开始探索Event Memory吧。
Event Memory分类：
| 类型 | 含义 |
| DemPrimaryMemory | 存储EventId，故障状态，冻结帧，扩展数据 |
| DemMirrorMemory | |
| Permanent Event Memory | 用于存储OBD相关的DTC |
Event Memory的组成架构如下图所示：
Event Memory组成架构图
S1:Dem模块必须支持Primary Memory，Mirror和Permanent memory可根据用户需要具体选择,一般用不上。
S2: Primary Memory是一个大小为DemMaxNumberEventEntryPrimary用于存储故障数据的非易失性存储空间。也就是Primary Memory由DemMaxNumberEventEntryPrimary个Event Memory Entry组成。
本质上，DemMaxNumberEventEntryPrimary设置为多少，NVM就会提供多少个NVM Block用于存储Primary Memory，就只能存储多少个Event信息。
S3:每个Event Memory Entry存储的内容有：EventId，Occurance Counter，冻结帧，扩展数据，老化周期等。
2.5 Event Memory management
当SWC或者BSW上报Event后，会经过哪些处理最终变成Flash中的Event Memory呢？
从下图中可以看出，Event上报后需要经过下列处理：
Event使能条件检测
Event控制DTC Bit位更新
Event Memory Retention
Event Memory management流程图
1）Event使能条件检测
Event使能条件就相当于Dem中的一个闸门，只有在条件合适的情况下Event才能真正进入Dem的处理流程中。
Event使能条件流程图
从图中可以看出，Event上报至最终能到第二阶段Event控制DTC bit位跳变，需要经历很多流程，接下来对上述流程进行详解。
S1:首先，需要判断当前是否开启了操作循环，操作循环一般指的是点火循环，一个操作循环可以认为是DTC检测的一个周期。如果操作循环开启了，则开始下列的Enable Condition判断，否则直接退出整个Event Memory management流程。
S2:Enable Condition判断指的是Event上报增加的一个附加条件判断，Dem通过对应的接口给SWC使用，SWC实现附件条件处理。一般可以用来处理一些电压，车辆模式等限制条件。如果Enable Condition条件满足，则进行85服务判断；如果Enable Condition条件不满足，则直接退出Event Memory management流程。
S3: 若现在使用了85服务抑制DTC使能，则直接退出整个Event Memory management流程。若没有执行85服务，开始Event Debounce流程。
S4:经过Debounce后，如果最终Event结果为Pass或者Fail，则开始下一阶段Event控制DTC跳变；否则直接跳出退出整个Event Memory management流程。
Event Debounce
“Debounce”顾名思义，指对于Event的防抖处理，防止Event误报导致DTC误报。
SWC通过Dem_SetEventStatus(EventId，EventStatus)上报Passed/Failed/PrePassed/Prefailed四种状态。
1）当SWC上报Passed和Failed状态时，Dem不需要进行Debounce处理。2）当SWC上报Prefailed和Prepassed状态时，Dem需要进行Debounce处理。
本质上，Dem提供的Debounce为通过特定机制，处理PrePassed/Prefailed至Passed/Failed状态变化。
Dem提供了两种Debounce机制，即“Base Time”和“Base Counter”。
1.基于计数器的Debounce策略
基于Counter的Debounce策略的几个重要参数如下表格：
| 参数 | 含义 |
| FDC(Fault Detection Counter) |
错误计数器，值范围为-128-127 |
| DemDebounceCounterFailedThreshold | 使Event诊断事件状态最终为Failed的Debounce Counter阈值 |
| DemDebounceCounterPassedThreshold | 使Event诊断事件状态最终为Passed的Debounce Counter阈值 |
| DemDebounceCounterIncrementStepSize | 当SWC上报Prefailed，错误计数器增加量 |
| DemDebounceCounterDecrementStepSize | 当SWC上报Prepassed，错误计数器增加量 |
基于Couneter的Debounce机制
如上图所示，在基于Counter的Deboucne机制中，Dem会提供一个计数器（FDC）用于记录判断的结果，当SWC上报给Dem的Event状态为Prefialed，计数器会按照步长增加，当达到设定的限值时，故障状态变成Failed。当上报状态为PrePassed时，计数器按照步长减少，当达到设定的限值时，故障状态变成Passed。
2.基于时间的Debounce策略
基于时间的Debounce策略的几个重要参数如下表格：
| 参数 | 含义 |
| DebounceTimeBasedTaskTime | 基本的检测周期 |
| DemDebounceTimeFailedThreshold | 定义故障状态从PreFailed跳转至Failed需要多少个DebounceTimeBasedTaskTime周期 |
| DemDebounceTimePassedThreshold | 定义故障状态从PrePassed跳转至Passed需要多少个DebounceTimeBasedTaskTime周期 |
基于时间的Debounce机制
在这种策略下，当SWC开始上报Event状态后，Dem模块会提供一个计时器用于记录判断的结果，计时器的增长方向由Event状态决定。当计时器累积到一定阈值后，故障状态变为Passed或者Failed。
3）Event 控制DTC状态更新
当Event经过一系列处理，最终能够对DTC状态进行更新，DTC 8个bit更新逻辑如下：
DTC Bit0 更新逻辑
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为Failed |
| 1 -> 0 | 经Debounce后最终上报状态为PassedOR使用14服务清除DTCOR 复位事件状态 |
DTC Bit0 更新逻辑图
DTC Bit1更新逻辑
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为Failed |
| 1 -> 0 | 操作循环更新OR 使用14服务清除DTC |
DTC Bit1 更新逻辑图
DTC Bit2更新逻辑
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为Failed |
| 1 -> 0 | （操作循环更新 AND TestFailedThisOperationCycle == 0）OR使用14服务清除DTCORTestNotCompeleteThisOperationCycle == 0 |
DTC Bit2 更新逻辑图
DTC Bit3更新状态
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为FailedAND Fialure Counter > = 故障确认阈值 |
| 1 -> 0 | 达到老化条件 OR 使用14服务清除DTC OR 故障溢出被替换 |
DTC Bit3 更新逻辑图
DTC Bit4更新逻辑
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为Failed |
| 1 -> 0 | 使用14服务清除DTC |
DTC Bit4 更新逻辑图
DTC Bit5更新逻辑
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为Failed |
| 1 -> 0 | 使用14服务清除DTC |
DTC Bit5 更新逻辑图
DTC Bit6更新逻辑
| Bit位更新 |
条件 |
| 0 -> 1 |
经Debounce后最终上报状态为Failed |
| 1 -> 0 |
使用14服务清除DTC OR 操作循环更新 |
DTC Bit6更新逻辑图
DTC Bit7更新逻辑
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为FailedAND 点灯条件满足 |
| 1 -> 0 | 使用14服务清除DTCOR点灯条件不满足 |
DTC Bit7更新逻辑
4）Retention条件检测
当DTC状态完成更新后，Dem将开始进行Retention条件检测。Dem给用户提供多种策略用以判断是否需要分配Event Memory Entry。分配策略由配置DemEventMemoryEntryStorageTrigger决定，具体如下面表格所示：
| DemEventMemoryEntryStorageTrigger | 分配条件 |
| DEM_TRIGGER_ON_TEST_FAILED | DTC bit0 由0跳变成1 |
| DEM_TRIGGER_ON_CONFIRMED | DTC bit3 由0跳变成1 |
| DEM_TRIGGER_ON_PENDING | DTC bit2 由0跳变成1 |
| DEM_TRIGGER_ON_FDC_THRESHOLD | DTC bit0 由0跳变成1ORDTC bit1由0跳变成1ORDTC bit2由0跳变成1ORDTC bit3由0跳变成1 |
5）Event Memory Retention处理
Event上报经过了使能条件检测，Event控制DTC Bit位状态更新，Retention条件检测重重难关，最终被允许进入Event Memory，Dem会怎样将Event（DTCs），DTC状态，快照，扩展数据存入Event Memory中呢？
基本思路如下：
Event Memory Retention处理机制
S1:在Event Mmeory所有Event Mmeory Entry中搜索，检查该Event及相关数据是否已经存入Event Memory中，如果已经存在，则进入Event Memory Entry Storage。如果不存在，则在Event Memory中寻找空间用于存储Event内容，如果Event Memory中空间已满，则需要使用Replacement机制。
S2:当进入Event memory Storage，Occurance Counter需要加1，判断是否需要更新冻结帧，扩展数据。
Event Displacement处理
Event Memory存储了数量为DemMaxNumberEventEntryPrimary的Event Memory Entry，当Event Memory Entry已满，需要进行Replacement，即根据一定的策略决定新增的Event如何存储。Dem模块提供了一套完善的机制用于Replacement，该机制有三个核心原则：
1.Event Priority（数字越小存储优先级越高）2.Event Active或者Event Passive状态（Active优先级高于Passive优先级）3.Event Occurance Counter（最近发生的存储优先级高于之前发生的）被替换的Event对应DTC中Bit2，Bit3 ，Bit5会被设置为0.
下图展示了整套Event Displacement机制，体现了三个核心原则在替换机制中的作用。
Event Displacement机制
总结
DEM是以DTC为核心的AUTOSAR基础软件模块，实现了对DTC的监控上报，存储等功能，如果需要对AUTOSAR诊断进行进一步学习，还需要对DCM，Doip，Cantp等模块进行系统性学习。
来源 | 汽车电子嵌入式