AUTOSAR - DEM

1 诊断事件管理(DEM)概念

诊断事件管理(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如何定义这些故障等级。

2 DEM模块及关联模块关系

诊断事件管理模块(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服务)。

3 DEM模块介绍

3.1 诊断故障码(DTC)概念及确定方式

诊断故障码(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): 表示所属系统

Byte 3: High	标准故障码的表示字符	所属系统
00	P	Powertrain：动力系统故障
01	C	Chassis：底盘故障
10	B	Body：车身故障
11	U	Network：网络故障

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

Byte 3: Low	标准故障码的表示字符	所属系统
00	0	SO/SAE标准定义的故障码
01	1	制造商自定义的故障码
10	2	ISO/SAE预留
11	3	ISO/SAE预留

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

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

3.2 诊断故障码(DTC)的掩码及计数方式

诊断故障码掩码反应了该故障处于的状态，计数主要作用是对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)

3.4 扩展数据及冻结帧的含义

扩展数据(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供电电压等可能与故障相关的一些数据，用于后续的车辆故障分析。

4 EB Tresos配置简要说明

EB配置可以手动配置或者直接导入OEM提供的arxml(符合autosar标准的xml)文件。
配置项太多，下次有时间再补上。
1、导入配置文件(arxml)(一般OEM会提供相应的设计文件): 右键->im- and Export->选择导入文件

2、修改错误: OEM文件导入一般会存在错误的(不敢私自用公司文件)，把描述(Description)窗口打开，把鼠标移到响应需要配置位置，会显示它的描述。
或者将需要配置的条目名称复制下来去AUTOSAR_SWS_DiagnosticEventManager文件中找到描述。

5 相关资源下载

配置工具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)