诊断事件管理(Diagnostic Event Manager, DEM)模块作为AutoSar诊断模块的重要组成部分，主要负责处理和存储诊断事件(错误)和关联数据。 DEM模块相关的标准主要包括两部分：ISO 14229(UDS，车身域诊断遵循的主要标准)和ISO 15031(OBD，该标准制定较早，主要针对排放相关的诊断)。

主要作用： 1、汽车检修提供数据：汽车售后会通过诊断仪去读取诊断仪读取诊断数据，主要包括诊断故障码(DTC)、扩展数据及冻结帧等。根据故障码能够判断出出现故障的汽车部件，根据具体的关联数据可以读到出现故障的时间以及当时的ECU的一些状态数据(记录易于判断故障原因的数据) 2、汽车错误状态处理提供依据：故障信息是ECU的运行重要依据，出现影响功能的故障时，应对功能禁止或功能降级以保护ECU或者负载。下面举两个例子： 1）、功能禁止：当电机出现短地这种情况时，处于保护负载及ECU的目的应该关断输出 2）、功能降级：如车窗反复操作时，车窗电机出现温度升高的情况，处于保护会将温度分为几个保护level，在这几个level中分别禁止相应的功能(如自动上升、自动下降等) 3、汽车重要故障显示：某些重要组件出现出现问题，需要警示用户(仪表盘上显示或者中控屏显示等)避免出现安全事故，主要看OEM如何定义这些故障等级。

诊断事件管理模块(DEM)是Autosar架构的重要组成部分，各功能模块之间存在依赖关系，下面围绕DEM模块介绍相关部分与DEM模块之间关系。对于各部分完整关系可以查阅AUTOSAR_SWS_DiagnosticEventManager文档，及相关联部分的文档(ClassicAutosar标准文档下载地址)。

功能禁止模块(FIM, Function Inhibition Manager): 在监控状态发生变化时，Dem通知和更新功能抑制管理器(FiM)，根据指定的依赖关系停止或释放功能实体。简而言之，就是根据检测到的DTCs来确定是否禁用或者打开某些功能模块。

软件组件(SWC, Software components)和基础软件模块(BSW, Basic Software): 检测到监控对象状态变化时，通知DEM模块更新数据，以及将错误状态数据通知给监控器以警示状态呈现给用户(状态位warning Indicator)。 简而言之，SWC和BSW可以充当错误检测的功能，还有就是Monitror模块可以通过渠道把一些重要错误(OEM或者标准规定)呈现给用户。

非易失性存储管理(NVM, NVRAM Manager): NVRAM块分配给Dem，由Dem使用以实现永久存储UDS状态信息和相关数据(例如，开机后复位)。 简而言之，NVM给存储DTCs提供永久空间，避免在断电或者复位的过程中造成诊断数据丢失。

诊断通信管理(DCM, Diagnostic Communication Manager): DCM模块处理来自外部测试人员或机载测试系统的诊断请求，转发来自外部诊断扫描工具的请求，并进一步负责响应消息的组装(DTC，状态信息等)，之后将传输到外部诊断扫描工具。 简而言之，两个主要功能： 1）、读取DTC(0x19服务)；2)清除DTC(0x14服务)。

诊断故障码(DTC, Diagnostic Trouble Code) 用来指示故障类型的独特ID，用于汽车检修时对故障部位及原因的精确排查，它包含了故障所属系统(底盘域、动力域、者车身域或者网络)、故障定义类型(ISO、OEM)、故障具体部件(如车窗电机等)、故障错误类型(开路、短路或者信号错误等)。它包含两种定义方式包括3个字节长度(ISO 14229-1, ISO14229 1-7)或者2个字节长度(SAE J1979)。故障码具体定义方式SAE J2012 OBD及SAE J2012 DA（没找到合适的版本)。

下面以三位DTC码作为实例进行说明故障码确定说明： 1、DTC High Byte(Bit7+Bit6): 表示所属系统

2、DTC High Byte(Bit5+Bit4): 表示故障定义者

3、DTC High Byte(Bit0-Bit3)+DTC Middle byte: 表示发生故障的目标系统，例如，属于车门域车窗模块升降电机，该部分由OEM定义(涉及到整车故障码分配)

4、DTC Low Byte：表示故障的类型，bytes 1(high)用于表示错误类型(如信号、电路、存储等等)，bytes 1(low)表示错误具体子类型(如开路、短路等)，该部分主要由OEM定义(部分依据标准内容)

诊断故障码掩码反应了该故障处于的状态，计数主要作用是对DTC进行滤波避免出现误诊断的情况。DTC状态掩码为一个字节数据： 1) TestFailed (bit0)： 逻辑1表示一个故障被监测到，逻辑0表示最近的故障测试通过或已存在的故障所有的故障条件已不满足，ClearDiagnosticInformation命令可清除此状态位。 2) TestFailedThisOperationCycle (bit1)： 逻辑表示当前操作周期或从上一次ClearDiagnosticlnformation命令清零后已经监测到一次故障，ClearDiagnosticInformation命令或新的操作周期都会清零此状态位。 3) PendingDTC (bit2)： 逻辑1成立条件与TestFailedThisOperationCycle相同，不同之处为清零条件，此位清零条件为一个完整的操作周期内未出现故障或ClearDiagnosticInformation命令。 4) ConfirmedDTC (bit3)： 逻辑表示一个已经被确定的故障被监测到，被确定的条件有：在连续操作周期内都检测到故障（TestFailed），且检测到的计数（TripCounter）已经达到定义的次数值。可通过ClearDiagnosticInformation命令或当Aging Counter 达到Aging threshold满足时清零此位，此外，故障的记录信息被新故障记录覆盖时，也会清零此状态位。 注：ISO14229-1建议，非排放相关的ECU服务器TripCounter=1 Aging Counter：当一个操作周期完成且本周期内没有出现TestFailed，则Aging Counter加1. 5) TestNotCompletedSinceLastClear (bit4)： 逻辑1表示从上次ClearDiagnosticInformation命令复位（置1）后，新的故障测试还未完成，逻辑0表示从上次清零后，新的故障测试已经完成（Failed or Passed） 6) TestFailedSinceLastClear (bit5)： 逻辑1表示从上次ClearDiagnosticInformation或其他条件清零后，已经监测到被确定的故障，逻辑0表示从上次清零后，测试未完成或测试已经Passed(而不是Failed)。 需要确认Aging Counter达到Aging threshold和内存记录被覆盖是否需要复位此状态位？ 7) TestNotCompletedThisOperationCycle (bit6) 逻辑1表示从上次ClearDiagnosticInformation命令复位（置1）后，本操作周期内当前测试未运行完成，逻辑0表示从上次清零后，本操作周期内已经出现TestFailed或者TestPassed，操作周期切换也会复位（置1）此状态位。 8) WarningIndicatorRequested (bit7) 逻辑1表示需要故障报警标识的故障已经处于ConfirmedDTC状态(bit3)和TestFailed状态(bit0)，逻辑0表示无故障需要报警标识提示。无需报警标识故障存在或ClearDiagnosticInformation都可以清零此状态位。 注意，如果报警标识被一个锁定的故障打开，就算有ClearDiagnosticInformation清零命令，也不能清零此状态位，仍然要保持开启状态，直到被锁定的故障TestPassed。

基本概念及术语(仅列举部分，详细说明查阅14229-1)： 1、操作周期(Operation Cyle)： 定义要运行的检测的开始和结束条件，Operation Cycle开始时开始检测故障，结束时停止检测。车身与底盘域由OEM或者供应商自己确定(如上下电、休眠唤醒等)，对于动力域会存在其它标准规定(没有深入研究)

2、监控周期(Monitoring cycle): 检测时会存在一些列条件，并不是操作周期开始就开始检测错误，可以是周期型(Period)、事件型(Event)。同时检测条件满足一定条件(依据实际情况而定)，如灯负载(HSD)开路故障，只有在打开输出时才能检测电流判断是都开路

3、确认阈值(Confirmation Threshold) : 确认此故障一直存在的Operation Clycle数，将其认定在历史DTC，在老化(aging)或手动清除前confirmed DTC状态位会一直存储在EEPOM

4、老化计数(Aging Counter): 连续报告没有故障的Operation Cycle数

5、老化阈值(Aging Threshold): Aging Counter达到次数之后，DTC的Confirmed状态位将会被清除

6、错误计数(FDC, Fault Detection Counter)：为错误计数，当然这个步长可以设定，向上(Step up)或者向下(Step down)均可以设置(计数值位-128-127，不同DTC需要的滤波次数不一致，通过设置此项值设置滤波次数)。同时还可以设置jump down(即在检测通过时是否跳转到0或者其它数，并从这个数开始向下减) 下图是非排放相关错误计数示例(来源于ISO 14229-1) 下图是非排放相关DTC aging示例(来源于ISO 14229-1)

扩展数据(Extended)：该数据在DTC的状态Pending置上后便会一同保存在非易失性存储单元(EEPROM)，对两个常用数据进行说明(其余可以看标准或者依据OEM要求) 1)错误计数(Fault Detection Counter): 检测到错误的计数，具体可以查询上文定义 2)老化计数(Aging Counter): 连续的Operation Cycle未检测到错误(DTC检测为passed，FDC为-128)的计数，当达到老化阈值时，会将DTC状态confirmed位置为0

冻结帧(Freeze Frame): 记录发生故障时的工况(SnapShot：由一些列的DID组成)，当DTC状态位Confirmed位由0置为1时将记录snapShot。 例如，可以环境温度、ECU供电电压等可能与故障相关的一些数据，用于后续的车辆故障分析。

EB配置可以手动配置或者直接导入OEM提供的arxml(符合autosar标准的xml)文件。 配置项太多，下次有时间再补上。 1、导入配置文件(arxml)(一般OEM会提供相应的设计文件): 右键->im- and Export->选择导入文件 2、修改错误: OEM文件导入一般会存在错误的(不敢私自用公司文件)，把描述(Description)窗口打开，把鼠标移到响应需要配置位置，会显示它的描述。 或者将需要配置的条目名称复制下来去AUTOSAR_SWS_DiagnosticEventManager文件中找到描述。

配置工具EB tresos24.0：EB收费只能在NXP官网下载老版本 1、NXP官网下载(参考这篇blog)：NXP_AUTOSAR_MCAL开发环境搭建引导_S32K14x系列 2、CSDN下载链接：EB Tresos24.0 Autosar软件标准： 1、Autosar官网下载：ClassicAutosar标准文档下载地址 2、CSDN下载链接：AUTOSAR_SWS_DiagnosticEventManager ISO 14229: ISO14229_2013(1-7)标准文档下载：ISO14229 1-7 ISO 15031:ISO 15031 (1-7)