【Diagnosis基础】Dem模块详细介绍

目录

1.功能概述

2.关键概念理解

3.DEM与其他模块交互

4.Dem模块详细介绍

4.1Dem模块启动行为

4.2监视器（Monitors）重新初始化

4.3诊断事件Event定义

4.3.1事件优先级

4.3.2事件发生

4.3.3事件类型

4.3.4事件存储

4.3.5事件监控定义

4.3.6事件依赖关系

4.3.7组件可用性

4.3.8小结

4.4诊断故障码DTC定义

4.4.1 DTC类型

4.4.2 DTC格式

4.4.3 DTC组

4.4.4 DTC严重性

4.4.5 功能单元

4.4.6 DTC显著性

4.4.7 抑制DTC输出

4.4.8 事件的可用性

4.4.9 小结

4.5 操作周期--Operation Cycle

---

1.功能概述

服务组件诊断事件管理器(Dem)负责处理和存储诊断事件(错误)和相关数据。此外，Dem向Dcm提供故障信息(例如，从事件内存中读取所有存储的DTC)。Dem提供到应用层和其他BSW模块的接口。如DCM可以通过

Dem_ReturnGetStatusOfDTCType Dem_DcmGetStatusOfDTC(

uint32 DTC,

Dem_DTCOriginType DTCOrigin,

uint8* DTCStatus)

这个标准接口同步或异步的读取到指定的DTC的故障状态。

2.关键概念理解

Aging：在定义的操作周期数后从事件存储器中取消学习/删除不再失败的事件/DTC--自愈功能。

Aging Counter：“Aging Counter--老化计数器”或“Aging Cycle Counter--老化周期计数器”或“DTC Aging Counter --DTC老化计数器”指定用于执行老化的计数器。 它计算操作周期数，直到从事件存储器中删除事件/DTC。

Debounce counter：基于计数器的去抖动算法的内部计数器。

DTC group：唯一标识一组 DTC。 DTC 组被映射到有效 DTC 的范围内。 通过提供一组 DTC，表示对该组的所有 DTC 请求某个操作。 DTC 组定义由 ISO 14229-1 提供。

Event combination：事件组合是一种将多个事件合并到一个特定组合 DTC 的方法。 用于使不同的监测结果适应一个重大故障，这在服务站中是可以明确评估的。

Event debouncing：去抖动是一种评估诊断事件是否合格的特定机制（例如基于计数器）。 这适用于潜在的信号去抖动，可以在 SW-C 或 Dem 内完成。

Event confirmation：如果通过故障确认计数器评估的循环或时间重复检测合格事件，则确认诊断事件。 因此，UDS 状态位 3（ConfirmedDTC）也被设置。

Event memory：一个事件存储器（例如主存储器）由多个事件存储器条目组成。

Event memory entry：事件存储器条目是事件及其事件相关数据的单个存储容器。 事件存储器条目动态地分配给特定事件。

Event memory overflow indication: 事件存储器溢出指示，如果该特定事件存储器已满并且下一个事件发生将存储在该事件存储器中。

Event qualification: SWC或者BSW模块检测到诊断事件passed或者failed。

Event related data： 事件相关数据是附加数据，例如 传感器值或时间戳/里程，与事件一起存储在事件存储器中。 ISO 定义了两种类型的事件相关数据：冻结帧（快照记录）和扩展数据。

Event status byte：ISO 14229-1 [1] 中定义的状态字节，基于事件级别。

Extended data record：扩展数据记录是用于存储分配给故障的特定信息的记录。

Failure counter：失败计数器对发生故障的操作周期（驾驶周期）进行计数。 如果计数器达到阈值（例如，2 个驱动周期），则确认位从 0 变为 1。

Freeze frame：冻结帧被定义为数据记录（DID/PID）。 冻结帧与 ISO-14229-1[2] 中的 SnapShotRecords 相同。

Healing：诊断事件确认后，如果一定周期或者事件后事件没有发生，则关闭警告指示器，包括在一段时间/几个操作周期内处理报告的通过结果。

Operating cycle：“操作周期”是事件确认的基础，也是 Dem 调度（例如点火钥匙断开周期、驾驶周期等）的基础。

OBD：车载诊断或 OBD 是一个通用术语，指的是车辆的自我诊断和报告能力。 OBD 系统使车主或维修技术人员可以访问各种车辆子系统的健康状态信息。

UDS status bit 0：testFailed bit of the UDS status byte。表示最近执行的测试的结果。

UDS status bit 1：testFailedThisOperationCycle bit of the UDS status byte。指示诊断测试是否在当前操作周期内的任何时间报告了 testFailed 结果。

UDS status bit 2：pendingDTC bit of the UDS status byte。指示诊断测试是否在当前或上一次最后完成的操作周期中的任何时间报告了testFailed 结果。

UDS status bit 3：confirmedDTC bit of the UDS status byte。指示是否检测到故障的次数足够保证将 DTC 存储在长期存储器中。

UDS status bit 4：testNotCompletedSinceLastClear bit of the UDS status byte。指示自上次调用 ClearDiagnosticInformation 以来，DTC 测试是否曾经运行并完成。

UDS status bit 5：testFailedSinceLastClear bit of the UDS status byte。指示自上次调用 ClearDiagnosticInformation 以来 DTC 测试是否已完成但结果失败。

UDS status bit 6：testNotCompletedThisOperationCycle bit of the UDS status byte。指示 DTC 测试在当前操作周期内是否曾经运行并完成。

UDS status bit 7：warningIndicatorRequested bit of the UDS status byte。报告与特定 DTC 相关的任何警告指示器的状态。

UDS status byte：ISO 14229-1 [1] 中定义的状态字节，基于 DTC 级别。

3.DEM与其他模块交互

从架构的角度看DEM，DEM处于BSW的服务层，见图一，与之交互的模块有SWC、BSW、ECUM、FIM、DCM、NVM，见图二。

图一：mapping of basic software modules to AUTOSAR layers

图二：dependencies of the Diagnostic Event Manager to other software modules

DEM和SWC：应用层软件组件SWC会周期调用故障监控函数，并周期调用标准接口Std_ReturnType Dem_SetEventStatus(

Dem_EventIdType EventId,

Dem_EventStatusType EventStatus)

把故障及状态报给DEM，DEM会根据预先配置的debounce方式调用相对应的函数。然后根据debounce的结果决定是否把当前故障加入到fault memory中和触发FIM。该内容的详细介绍在DEM与其他模块的联系章节的SWC部分和DEM内部模块的debounce部分会涉及到。

DEM和BSW：基础软件BSW也会给DEM报故障，根据AUTOSAR规定，BSW通过调用

void Dem_ReportErrorStatus(

Dem_EventIdType EventId,

Dem_EventStatusType EventStatus)

标准接口给DEM报故障，故障内容如NVM写入失败或者排队任务数溢出或者校验错误。该类故障在DEM中的debounce方式是no debounce，不需要debounce，所以故障状态只有DEM_EVENT_STATUS_FAILED或者DEM_EVENT_STATUS_PASSED。

DEM和ECUM：ECUM主要负责在不同时序调用DEM的初始化工作，

DEM初始化应包括对每个故障的debounce status做处理；初始化fault memory相关数据；初始化DEM中存储的BSW的故障数据。

DEM和FIM：FIM全称function inhibition manager，主要负责给SWC提供一个控制机制，可以使能或者失能SWC的功能，如SWC中电压检测功能，此时由于其该功能被抑制，SWC此时使用Dem_SetEventStatus报给DEM的故障状态是no condition。

另外在SWC调用Dem_SetEventStatus时，如果故障状态发生变化，DEM会通过调用

void FiM_DemTriggerOnEventStatus(

Dem_EventIdType EventId,

Dem_UdsStatusByteType EventStatusByteOld,

Dem_UdsStatusByteType EventStatusByteNew )

来抑制SWC本身的功能和与之相关的事件的功能。详细内容请期待FIM模块的分享。

DEM和DCM：DCM和DEM之间有着密切关系，因为DCM中有ReadDTCInformation（0x19服务）和ClearDiagnosticInformation（0x14服务）这两个服务都是都是要从DEM中读取信息或者传递命令，还有PID01请求当前动力诊断数据等服务。比如根据DTC读冻结帧（也叫快照）（19 04 xx xx xx yy），在19服务的自服务的处理函数里面，首先就要调用

Dem_ReturnGetStatusOfDTCType Dem_DcmGetStatusOfDTC(

uint32 DTC,

Dem_DTCOriginType DTCOrigin,

uint8* DTCStatus)

给DEM传递DTC和该DTC所属的memory类型，来获得DTCStatus；然后调用

Dem_ReturnGetSizeOfDataByDTCType Dem_DcmGetSizeOfFreezeFrameByDTC(

uint32 DTC,

Dem_DTCOriginType DTCOrigin,

uint8 RecordNumber,

uint16* SizeOfFreezeFrame)

获得冻结帧（快照）的数据大小，因为数据大小和数据内容是提前配置好的，也可标定。最后调用

Dem_ReturnGetFreezeFrameDataByDTCType Dem_DcmGetFreezeFrameDataByDTC(

uint32 DTC,

Dem_DTCOriginType DTCOrigin,

uint8 RecordNumber,

uint8* DestBuffer,

uint16* BufSize)

获取冻结帧。但是DCM和DEM是两个不同的任务，所以以上几个函数一般是异步执行，DCM只负责把请求命令和写入目标给到DEM，在DEM任务中轮询DCM的任务请求，并实现数据的填充，后通知DCM任务完成。DCM再通过肯定相应回复数据。

DEM和NVM：NVM之于DEM主要在于诊断数据存储（快照信息级诊断状态字），NVM也就是NVRAM manager，司职于非易失性数据的存储和维护。而DEM中又有大量数据需要存储在非易失性存储模块（如Dflash、EEPROM）中，但两者的交互关系都发生在上电初始化（startup）和下电（shutdown）过程中，当然，如果没有NvM_WriteAll的过程，也可以在运行过程中写入。DEM需要存储在非易失性存储模块的数据包括19服务中会用的相关数据（如第一次出现的故障，第一个confirm的故障、最新的故障等等）、primary fault memory中的数据、mirror memory中的故障、OBD相关的数据、冻结帧、预存的数据、Debounce的状态（甚至是debounce counter）等，这些数据会在NVM_Readall的时候读取到DEM的RAM中，下电的时候会在NVM的writeall时从DEM的target RAM写入非易失性存储区（non-volatile memory）。

DEM内部分很多子模块，每个子模块分工不同，任务明确。INIT负责对DEM内部变量根据配置内容进行初始化。debounce负责对事件发生故障的有效性和事件表现正常的有效性的做滤波判断，如KL30电电压超过16伏100ms，该事件才会报KL30过压故障；primary fault memory负责存储当前发生的故障的DTC及相关数据，如冻结帧、扩展数据等。operational cycle management负责管理各种操作循环的判断，如对于OBD-related ECU中OBD drving cycle开启时才能故障状态才能进入confirm的状态，这也和项目配置有关；其它子模块及以上模块详细内容，敬请期待下一次的分享——DEM子模块详细分析。

4.Dem模块详细介绍

Dem模块可以处理和存储BSW和SWC检测到的诊断事件（Dem_SetEventStatus）。同时，BSW模块和SWC可以通过AUTOSAR提供的标准接口获得Dem存储的事件信息（Dem_GetEventStatus）。

4.1Dem模块启动行为

Dem模块应区分预初始化模式和全初始化模式（操作模式）。Dem_PreInit函数应初始化Dem模块的内部状态，并使用Dem_SetEventStatus和Dem_ResetEventDebounceStatus处理事件并重置SW-C或BSW模块报告的Debounce计数器。

在NVM初始化之前，在ECU的启动阶段，由EcuM调用函数Dem_PreInit。NVM初始化之后，也就是NVM调用NVM_ReadAll完成所有NVM数据拷贝到RAM之后，在ECU启动阶段需要调用Dem_Init完成Dem模块的完全初始化。随后，具有诊断事件监控的Monitors(SWC-c or BSW)完成初始化，可以开始诊断事件监控和设置。

Dem_Shutdown之后如果需要调用Dem_Init重新初始化Dem模块。

Note:

1）Dem_PreInit一般在EcuM的Init One阶段调用

2）Dem_Init一般BSWM模式管理的Action中调用（Startup --> Run or PreShutDonw --> Run）

3）如果调用Dem_Shutdown后ECU又需要恢复Dem功能，但是忘记了重新初始化Dem模块（Dem_Init），就会发生很奇怪的现象，比如0x10,0x19服务就会一直Pending后回0x10的否定响应码，这个坑要记得避免（本质就是在Dem_Shutdown后忘记调用Dem_Init导致Dem不能正常使用）。

4.2监视器（Monitors）重新初始化

应用程序中的监视器的主要初始化是通过Rte_Start来完成的。监视器的事件特定部分的初始化可以由Dem触发。

Dem应提供InitMonitorForEvent接口，以触发诊断监视器的初始化。

功能参数InitMonitorReason指示初始化的原因/触发器。

配置容器 DemCallbackInitMForE用来为每个事件（Event）来定义相关的Port和Callback函数。

Note: 这个功能在实际项目中基本没有用到，配置参数也不会配置，这里不详细介绍了，需要用到的时候可以再研究。

4.3诊断事件Event定义

“诊断事件”定义了可由Dem模块处理的原子单元。“诊断事件”的状态表示监视器的结果。Dem通过RTE或其他BSW模块从SW-C接收监控器的结果。

Dem模块使用EventId来管理系统的“诊断事件”的状态，并对单个测试结果执行所需的操作，例如存储冻结帧。

Dem模块应通过事件标识和相关事件名称表示每个诊断事件，所有监视器（SWC）和BSW模块都使用事件Id作为符号事件名称。Dem配置工具将用数字替换符号名称，事件标识和相关事件名称应是唯一的。

Dem模块的设计不能够处理多个监视器共享一个EventId的情况。Dem模块使用内部监视器状态来存储所报告事件的状态。向Dcm报告UDS状态。Dem模块支持几个特定于事件的配置参数，如下图所示。有关详细的描述，请参阅后面的配置规范。

图三：: Event parameter configuration

对于事件的简单理解：

1）比如BSW底层的一个IoHwAb_Bat模块就是一个Monitor（监视器），它会周期性（10ms调度周期）的去检车电源电压Bat_Voltage是否过高（大于16V）这个事件（Event），如果这个在一定时间内Bat_Voltage一直过高，则监视器（Monitor）也就是IoHwAb_Bat这个模块就会调用Rte封装的C-S接口Rte_Call_xxx_SetEventStatus（也就是分装了Dem_SetEventStatus这个接口）向Dem模块报告这个Event实践。

2）而Dem模块对于每个Event定义或者描述不光只包括一个EventId，还需要优先级，属于BSW还是SWC等相关信息，这就需要为每个Event提供一个配置容器（里面包含一个Event需要的所有的配置信息），也就是DemEventParameter这个配置容器。每一个Event都对应一个具体的DemEventParameter配置实例（Instance）。

4.3.1事件优先级

事件优先级被定义为基于重要性级别对事件进行排序。它用于确定当存储的事件数量超过最大内存条目数（事件内存已满）时，可以从事件内存中删除哪些故障条目。

每个支持的事件应具有优先级（参见DemDTC属性中的参数DemDTCPrifisty）。

优先级值1为最高优先级。优先级值越大，重要性就越低。

问题：为什么我们需要定义事件的优先级？

答：当我们的诊断事件树木大于我们设置的诊断事件状态码的存储数据的时候我们需要考虑定义事件的优先级，这样就能保证在诊断事件状态码存储区域已经存满的情况下，也能保证优先级高的诊断事件的状态码还能存储到NVM当中去（删除一些优先级低的）。

4.3.2事件发生

几个相关概念理解：

1）Event memory

An event memory (e.g. Primary memory) consists of several event memory entries.

事件内存（例如主内存）由多个事件内存条目组成。

2）Event memory entry

The event memory entry is a single storage container for an event?and its event related data. The event memory entry is dynamically assigned to specific events.

事件内存条目是事件及其事件相关数据的单个存储容器。事件内存条目被动态地分配给特定的事件。

3）Event memory overflow indication

The event memory overflow indication indicates, if this specific?event memory is full and the next event occurs to be stored in?this event memory.

事件内存溢出指示表明，如果此特定事件内存已满，并且发生的下一个事件将存储在此事件内存中。

Dem模块应为每个事件存储器条目提供一个事件计数器，如果在各自的事件内存中输入了相关事件，则Dem模块应使用值1初始化发生计数器。

如果配置参数DemOccurrenceCounterProcessing为DEM_PROCESS_OCCCTR_TF，则如果相关事件已经存储在事件内存中，则由UDS状态位0（测试失败）由0-->1将触发发生计数器加1。

如果配置参数DemOccurrenceCounterProcessing为DEM_PROCESS_OCCCTR_CDTC，如果相关事件已经存储在事件存储器中，并且UDS状态位3等于1，则由UDS状态位0（测试失败）由0-->1将触发发生计数器加1。

Dem模块应不再增加特定事件的发生计数器，如果它已达到其最大值(255）。

4.3.3事件类型

有两种不同类型的事件：

1）与BSW相关的事件(通过C-API-Dem_SetEventStatus报告)

2）SW-C相关事件（通过RTE操作报告-设置事件状态）

每个事件都需要通过DemEventParameter配置容器下的DemEventKind参数配置事件类型。

这是必要的，因为BSW事件可能在完全Dem初始化之前报告，需要缓冲。

4.3.4事件存储

相关概念理解：

DemMemoryDestinationRef: 内存目标为一个或两个内存目标分配dtc。如果将多个内存目标分配给一个特定的DTC，则该DTC可以出现在相应的事件内存中。在这种情况下，其中一个引用必须是删除镜像内存。该参数可以配置为:

DemMirrorMemory,DemPrimaryMemory,DemUserDefinedMemory

DemPrimaryMemory: 此容器包含Dem模块的主事件内存特定参数。

DemPrimaryMemory: 此容器包含Dem模块的镜像事件内存特定参数。

DemUserDefinedMemory：此容器包含Dem模块的用户定义的事件内存特定参数。

配置参数DemMemoryDestinationRef（参考DemDTC属性）定义了事件及其相关数据的专用存储位置。

不同内存类型的定义和使用是特定于OEM的。

对于Dcm-Dem接口，使用参数DTCOrigin来区分不同的内存区域。其目的是允许对不同的内存区域（主内存、用户定义内存、永久内存和镜像内存）进行特定的操作。

DemMemoryDestinationRef配置参数的限制：

1）如果一个事件的配置参数DemMemoryDestinationRef配置为DemMirrorMemory，则这个事件的DemMemoryDestinationRef配置参数还需要在配置一个DemPrimaryMemory或者 DemUserDefinedMemory。

2）一个DTC通过DemMemoryDestinationRef参数引用 event memories，而这些event memories是在不同的DemEventMemorySet中的，这样的场景Dem模块是不支持的。Dem模块只支持一个DTC通过DemMemoryDestinationRef参数引用同一个DemEventMemorySet中的不同的event memories。

4.3.5事件监控定义

诊断监视器是确定组件的正确功能的常规实体。此监控功能识别特定故障类型（如对地短路、开路负载等）对于一个监视路径。监视路径表示正在被监视的物理系统或电路（例如，传感器输入）。每个监控路径都只与一个诊断事件相关联。

图四：: Example for a monitor embedded within a SW-C

如果监视器（SWC）自己进行Debounces，则只有在限定的结果（已通过或失败）可用后，才会调用报告API。如果结果发生了变化，则需要进行报告。然而，通常监视器总是调用Dem在计算上效率更高，因此应该是首选。

如果监视器使用Dem内部debouncing机制，则在执行具有功能检查的代码时调用报告API。

实例理解：

事件定义：电源电压Bat_Voltage大于16V事件大于3秒后记录一个DTC

实现方式1：检测器（Monitor）检测到电源电压Bat_Voltage大于16V后直接调用Dem_SetEventStatus(EventID_Bat, TRUE)接口向Dem报告过压事件，Dem模块来进行3秒的计时（Debounce过程）。

实现方式2：Dem模块不做Debounce过程，收到Monitor的事件报告后就记录DTC，检测器（Monitor）检测到电源电压Bat_Voltage大于16V后进行计时（Debounce），达到3秒后调用Dem_SetEventStatus(EventID_Bat, TRUE)接口向Dem报告过压事件。

4.3.6事件依赖关系

相关概念理解：

DemComponent: 此容器将配置受监视的组件和系统依赖关系。

分配的DemComponent的优先级以及DemComponent之间的依赖关系用于过滤到故障内存的错误报告存储。

4.3.7组件可用性

Dem应该支持DemComponent的可用性。不可用的组件应被视为不包括在系统中。

Note: 这个功能在实际项目中基本没有用到，配置参数也不会配置，这里不详细介绍了，需要用到的时候可以再研究。

4.3.8小结

BSW或SWC会监控所有的事件Event（过压，欠压，过流等），每个事件发生后SWC或者Dem进行Debounce（计时或者计数），达到确定阈值后Dem模块就会记录一个DTC。而通过DemEventParameter配置容器描述/定义每一个Event。

4.4诊断故障码DTC定义

“诊断故障码-DTC”定义了一个映射到Dem模块的“诊断事件”的唯一标识符（显示给诊断仪）。Dem为Dcm模块提供“故障诊断码”的状态（例如通过：19 06 EF 02 88 FF读取单个DTC（通过EF 02 88唯一标识，代码总线BusOff）状态，）。

图四：:DTC configuration

DemDTC这个配置容器就是对DTC的具体描述，一个DTC对应一个DemDTC的配置。

4.4.1 DTC类型

两种不同类型的DTC：

. 非OBD相关的DTC（统一诊断协议UDS DTC）

. OBD相关的DTC

如果配置了DemObdDTC，则 DemObdDTC配置容器下的DTC及其相关的Event就是OBD相关的。

DTC类型与诊断服务ReadDTCInformation和一些OBD服务(0x19/$03/$07/$0A，参考Dem_SetDTCFilter)所使用的DTC的选择相关。诊断服务ControlDTCSetting (0x85，参考Dem_DisableDTCSetting和Dem_EnableDTCSetting)也与DTC类型相关。

问题：OBD 诊断与 UDS 诊断有什么区别？汽车故障诊断相关。OBD和UDS是在车辆上同时存在还是选择一个？它们有什么不同？

答：OBD（全称：On BoardDiagnostics），即车载自动诊断系统，是汽车排放和驱动性相关故障的标准化诊断规范，有严格的排放针对性，其实质就是通过监测汽车的动力和排放控制系统来监控汽车的排放。当汽车的动力或排放控制系统出现故障，有可能导致一氧化碳(CO)、碳氢化合物(HC)、氮氧化合物(NOx)或燃油蒸发污染量超过设定的标准，故障灯就会点亮报警。

首先，OBD是面向汽车排放问题而制定的规范，也就是说对所有车辆统一适用，在OBDⅡ计划实施之后，任一技师可以使用同一个诊断仪器诊断任何根据标准生产的汽车。而且OBD Ⅱ程序使得汽车故障诊断简单而统一，维修人员不需专门学习每一个厂家的新系统。其次，OBDII使用标准的16针诊断接口，并且统一各车种相同故障代码和意义，这样一方面，这是为了方便技师维修，当故障车辆来到4S店后，技师可用专用的诊断工具读取汽车存在的故障码，故障发生时的时间、里程、故障发生次数等重要参数，从而提高维修效率。而OBD系统更重要的另一方面，也是它设计的初衷，就是为了控制排放，能在发生了尾气排放超标的故障时及时提醒车主，尽快去修复故障。

图四：:OBD接口

UDS（全称：UnifiedDiagnostic Services），即统一诊断服务，是诊断服务的规范化标准，为诊断服务提供一个基本框架，这些诊断服务允许诊断仪在车载电子控制单元里面控制诊断功能，以便维修人员能够准确的解决故障。

UDS在使用过程中除了协议中已经定义好的通用的代码指令之外，还有一部分未定义留给整车厂自行定义，这样就会形成不同厂家ECU的DID不同，所以对ECU的诊断过程需要事先了解内部定义。

对比之下：

. OBD是关注车辆实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范。

. 而且，UDS是面向整车所有ECU(电控单元)的，而OBD是面向排放系统ECU的。

. 两者之间并不存在谁替代谁。

4.4.2 DTC格式

Dem模块应支持的DTC格式：

. ISO-14229-1[2]

. SAE J2012 OBD DTC (aka 2-byte DTC) [14]

. SAE J1939-73[15]

. ISO 11992-4[16]

. SAE J2012 WWH-OBD DTC (aka 3-byte DTC) [14]

配置参数DemTypeOfDTCSupported用来指定ECU支持的一种DTC格式。一个DTC可以有三种格式(UDS、OBD和J1939)的任意组合，即同时使用一种、两种或三种格式。因此，Dem将在内部处理三个DTC值列表。报告的格式取决于Dem_DTCFormatType或由相关API的上下文定义。

DTC应将DTC值报告为uint32，字节0=低字节，1=中字节，字节2=高字节和字节3未使用。对于OBD DTC格式，只有两个字节（高字节，低字节）被使用。Dem服务应将这些dtc报告为uint32，字节1=低字节，字节2=高字节，字节3未使用，字节0=0x00。

图五：DTC Byte Order

函数Dem_GetDTCOfEvent将获得由Dem配置映射到EventId的DTC。

4.4.3 DTC组

除了单个DTC值外，还可以配置由ISO14229-1[2]-附件D.1所定义的DTC组(参见DemGroupOfDTC)。每个DTC组都有自己的DTC组值（该值必须对任何其他DTC和DTC组值唯一）。当请求DTC组的操作（如CleaerDTC和禁用/启用DTC）时，通过DTC值选择DTCGroup。

DemGroupOfDTC配置容器定义了DTC组的边界值。在被请求组的DTC代码和下一个更高的dtc组代码之间的范围内的所有DTC都应被视为属于该组（例如：0x3FFF00和0x7FFFF0是两个组边界值，则0x3FFF00 --> 0x7FFF0F之间的DTC属于0x3FFF00这个组）。

以下的DTC组是预定的：

.‘所有DTc的DTC组(强制，固定值=0x FFFFFF)

. WWH-OBD排放相关的DTC(0x FFFF 33)

请注意，DTC组“所有DTC”将不会在DemGroupOfDTC中进行配置，因为它总是要由Dem模块提供。

DTC组与诊断服务ClearDiagnosticInformation（0x14，参考Dem_ClearDTC）以及诊断服务ControlDTCSetting（0x85，参考Dem_DisableDTCSetting和Dem_EnableDTCSetting）相关。

Note:实际项目中，在定义DTC码的时候会考虑分组（比如动力相关的DTC，车上相关的DTC，热管理相关的DTC会被分配在不同的DTC码端中），但是在Dem模块中不在配置DTC Group。

4.4.4 DTC严重性

根据ISO-14229-1[2]，附录D.3“DTC严重程度和类别定义”，DTC严重程度用于提供有关特定事件重要性的信息。DemDTCS严重性仅可用于UDS?DTC。

如果调用了API Dem_GetSeverityOfDTC或Dem_GetNextFilteredDTCAndSeverity，并为选中的DTC配置了一个在DemDTCSeverity中的严重性值，则Dem应将在DemDTCSeverity中配置的值设置为DTCSeverity。

如果调用了API Dem_GetSeverityOfDTC或Dem_GetNextFilteredDTCAndSeverity，并且对于所选的DTC没有在DemDTCSeverity中配置严重性值，则Dem应将DEM_SEVERITY_NO_SEVERITY设置为DTCSeverity。

4.4.5 功能单元

如果调用了API Dem_GetFunctionalUnitOfDTC，并为所选的DTC配置了一个功能单元值DemDTCFunctionalUnit，则Dem应在输出参数DTCFunctionalUnit中设置该值。

如果调用了API Dem_GetFunctionalUnitOfDTC，并且对于所选的DTC，没有在DemDTCFunctionalUnit中配置功能单元，则Dem应在输出参数DTCFunctionalUnit中设置0x00的值。

4.4.6 DTC显著性

DTC有两种不同的显著性水平：

. 故障：对故障进行分类，该故障与组件/ECU本身有关（例如，需要进行修复操作）

. 发生：对问题进行分类，该问题指示有关系统行为不足的附加信息(例如与ECU控制之外的条件相关)

这个显著性级别是每个事件都可配置的(参考demdtattributes中DemDTCSignificance)，并且可以映射为一个数据元素(参考DEM_SIGNIFICANCE)。

4.4.7 抑制DTC输出

在运行时通过API调用动态抑制事件/ DTC。被抑制的DTC的行为对测试人员来说是不可见的，但可以由诊断监视器连续处理。

如果DTC和事件之间存在一对一的关系，则如果相关事件不可用，则DTC将被抑制。如果DTC是一个组合DTC，则如果所有组合事件都不可用，则抑制DTC。

4.4.8 事件的可用性

Dem模块提供一种将事件标记为不可用的方法，而无需将事件从实际配置中删除。不可用的事件将被视为它没有包含在Dem配置中。

一个示例性的用例可以是控制单元及其软件支持要控制的不同类型的硬件。硬件变体在某些部件可用或不可用时有所不同。仍然应采用相同的控制单元和软件。通过配置参数DemEventAvailable可以配置事件是否可用。Dem提供Dem_SetEventAvailable接口来配置事件的可用性。

如果事件设置为不可用，则将相应事件视为系统中未配置(例如Dem_SetEventStatus和Dem_GetEventUdsStatus应返回E_NOT_OK)。以下api会受到影响：

? Dem_SetEventStatus

? Dem_GetEventUdsStatus

? Dem_ResetEventDebounceStatus

? Dem_ResetEventStatus

? Dem_PrestoreFreezeFrame

? Dem_ClearPrestoredFreezeFrame

? Dem_GetDebouncingOfEvent

? Dem_GetDTCOfEvent

? Dem_GetFaultDetectionCounter

? Dem_GetEventFreezeFrameDataEx

? Dem_GetEventExtendedDataRecordEx

? Dem_ClearDTC

? Dem_DcmGetDTRData

? Dem_RepIUMPRFaultDetect

? Dem_RepIUMPRDenLock

? Dem_RepIUMPRDenRelease

? Dem_SetWIRStatus

? Dem_DltGetMostRecentFreezeFrameRecordData

? Dem_DltGetAllExtendedDataRecords

当API Dem_SetEventAvailable被调用，用状态=为false时，Dem应返回E_NOT_OK：

?对于该事件，有一个事件内存项已经存在

?已设置任何事件状态标志“测试失败”、“待定”、“已确认”或“请求的警告指示符”

4.4.9 小结

本小结着重介绍了DTC的定义及相关属性配置，实际项目开发中对于DTC就可以简单理解为一个3个字节的码（例如：EF0288），一个DTC和一个事件绑定（EF0288和ECAN BusOff这个Event绑定），如果一个事件发生，则这个事件绑定的DTC的状态就会发生改变（状态码的对于标志置位）。本节描述的其他相关属性，实际项目中基本没有用到，如果用到的时候可以在着重研究。不过，在当今芯片短缺经常换硬件元器件的场景下，DemEventAvailable事件可用性这个特性可以考虑利用起来。做到一版软件配置所有硬件方案。

4.5 操作周期--Operation Cycle

待补充。

参考文档：

1. Specification of Diagnostic Event Manager

2.https://www.zhihu.com/question/26374239/answer/369991927