【AutoSar_诊断协议栈】Dem模块详解（2）_Event和DTC详解

Gagaaaaaa

已于 2025-03-25 10:03:00 修改

阅读量4.8k

点赞数 30

分类专栏： #诊断协议栈文章标签：车载系统笔记汽车

于 2024-03-05 16:28:11 首次发布

本文链接：https://blog.csdn.net/Gagaaaaaa/article/details/135464587

版权

#诊断协议栈专栏收录该内容

16 篇文章

订阅专栏

Event和DTC详解

1 术语解释
- 1.1 缩略语
2 相关模块
3 功能简介
4 参考资料

1 术语解释

1.1 缩略语

缩写	描述	解释
Dem	Diagnostic Event Manager	诊断事件管理模块
UDS	Unified Diagnostic Services	统一诊断服务
Dcm	Diagnostic Communication Manager	诊断通信管理模块
DTC	Diagnostic Trouble Code	诊断故障码
OC	Operation Cycle	操作循环

2 相关模块

Dcm : UDS服务通过0x14、0x19、0x85服务对DTC进行清除、获取、控制；
SW-C：应用层监测到故障时，会向Dem上报故障；
BSW: BSW层在监测到内部故障发生时，会向Dem上报故障，例如BusOff。

3 功能简介

在讲Event和DTC的具体功能之前，需要先了解一下Event和DTC是什么？Event和DTC具有什么样的关联？

作为故障监控的基本单元，Event在发生故障的时候被monitor通过Dem的接口上报，而Event在经过Dem内部的Debounce，Store, Heeling, Aging一系列策略处理之后会对Event所mapping的DTC状态（1 Byte表示）产生影响。

DTC是指车辆ECU存储的车辆故障代码，它是一种数字编码，用于标识车辆的故障问题。每个DTC都与特定的故障相关联，这些故障可能会导致车辆的某些系统无法正常工作。车辆在运行过程中ECU会持续监控车辆运行状态，检测到故障时，它会记录相应的DTC，并将其存储在车辆的故障存储器中。工程师会通过上位机读取故障存储器中的DTC及其相关信息，可以快速定位车辆的故障问题，并采取相应的修复措施。

从上文中可知，故障（即FAILED的Event）和DTC存在特定的映射关系，且Event的上报会对DTC状态产生影响。

3.1 Event和DTC的关系

3.1.1 事件组合（Event Combination）

Event和DTC存在mapping关系，一般地，Event和DTC是一对一或者一对多的映射关系，换句话说DTC可以映射一个或多个Event，但是Event只能mapping一个DTC，而不是多个。在Dem中多个event映射一个DTC叫事件组合（Event Combination），这种方式能够让多个event影响一个DTC状态；

在事件组合中，DTC状态是通过映射的Events状态集按位或计算而来，当然事件组合（Event Combination）按照存储故障信息的方式也分为两种，具体可以参照一下规范。

3.1.2 Event可用性

在Event的可用性被外部接口设置或配置为不可用，那么monitor在监测到故障时，上报Dem的状态将不会被计算，那么DTC也不会发生变化。

3.1 3 存储条件（Storage Condition)

与使能条件（Enable Condition）相似，存储条件（Storage Condition)就是在Event成为一个故障之后，作为故障相关信息存储的前提条件之一，一般地，我们会为一个事件配置一个Storage Condition Group, 其中可能包含若干条Storage Condition。
在功能的实现中，上层可以通过Dem_SetStorage Condition修改某一条Storage Condition的使能状态，最终Storage Condition Group中的所有Enable Condition都处于TRUE方可进行后续的故障信息存储。

3.1.4 Event优先级(Event Priority)

Event优先级也就是DTC优先级，它和Compoent Priority不同的是，Compoent Priority的使用场景是为了判断同一个Compoent 上的事件是否为连续故障，如果故障被认定是连续故障则该故障信息不应存储；Event Priority则是当故障成立，在存储时作为替换低优先级的故障信息的依据。

3.2 DTC

3.2.1 DTC类型和格式

DTC的类型和格式是根据几个标准定义的，比如ISO-14229-1，SAE J2012 OBD DTC和SAE J1939-73等。一般地，我们主要要关注OBD类型格式和非OBD类型格式。具体这两种格式如下：
在这里插入图片描述
不难看出的是，这两种DTC格式都由四个字节组成，最高字节均保留未使用，剩下三个字节我们标记为：DTC HighByte、DTC MiddleByte、DTC LowByte。

DTC HighByte和DTC MiddleByte两个字节表示故障内码，对应5位标准故障码（一位字母+四位数字）。
DTC LowByte描述了故障的种类和子类型（可以参考ISO 15031-6以及SAE J2012-DA，比如常见的timeout应该用0x87，信号无效为0x81等等），简单理解就是对故障类别作进一步的区分/描述，未使用这个字节的可以用0x00填充，比如OBD格式的最低字节未使用，默认为0x00。详细的DTC解读可以参考下图：
在这里插入图片描述
这里再举个栗子：定义一个底盘的DTC，那么故障内码的第一位为C（01），且DTC定义为OEM定制，则第二位为1（01），且故障和巡航和怠速控制系统相关则第三位为5（0101），且第四、第五位是0(0000)、7(0111)，第六和第七位即DTC LowByte是0x0a(0000 1010)，那么该DTC如下表示：

故障内码+故障子类型： C15070A
HEX : 0x55070A

3.2.2 DTC组（DTC Group）

DTC组的主要用于哪些场景呢？
主要用于uds 0x14服务和0x85服务中参数选择，以清除或控制指定的DTC组（范围）；

DTC组有区别于其他DTC值和其他DTC组的值，那么，如何表示一个DTC组呢？
DTC组的范围可以使用一个开区间表示，而这个开区间的下限值则为DTC组的值，而上限值则为下个DTC组的值；

除此之外，Dem内存预定义的DTC组，如0xFFFFFF，表示所有DTC值，如果有排放相关的DTC组的话，则有0xFFFF33预定义为该DTC组的值。一般地，DTC组的值在 0x000100 and 0xfffe00之间配置，。在下表中可以看到每个子系统都划分为4个子范围，如B0-B3，C0-C3，P0-P3，U0-U3；其中值得注意的是B0、C0、P0、P2、P3、U0、U3这几个子范围被ISO预留以供未来使用，可以按照下图按类别划分DTC组。
在这里插入图片描述

3.2.3 DTC 位状态

DTC状态位包含8个bit，每个bit都有各自的含义，但是这8个 bit不一定都要支持，具体的看客户需求，支持的bit可以在配置中的掩码来确认。各个主机厂可以根据自己的需求使用其中的几个，当然也可以全部使用。下表是UDS对DTC status这8个bit的解释：

bit	含义	置位条件
bit0	testFailed	置0：testpassed（同个OC内可恢复），0x14服务ClearDTC ，Dem_ResetEventStatus调用成功置1：testfailed, 故障上报
bit1	testFailedThisOperationCycle	置0：OC重新启动，0x14服务ClearDTC 置1：testfailed, 故障上报
bit2	pendingDTC	置0：在整个OC没有testfailed在OC结束时置0，0x14服务ClearDTC ，eventmem entry被新故障替换掉置1：当前或上一个周期内发生过testfailed
bit3	confirmedDTC	置0：达到老化阈值，0x14服务ClearDTC ，eventmem entry被新故障替换掉置1：故障被存储在event memory中且该故障在一定时间（OC）发生了指定的次数
bit4	testNotCompletedSinceLastClear	置0：自上次清除诊断信息以来，DTC测试至少返回一次测试结果（无论testpassed或testfailed）置1：自上次清除诊断信息后DTC测试尚未运行到完成，0x14服务ClearDTC
bit5	testFailedSinceLastClear	置0：自上次清除诊断信息后DTC测试未显示失败结果；如果满足老化阈值或发生故障记忆溢出，则车辆制造商应负责将该位重置为0 置1：自上次清除诊断信息以来DTC测试至少返回一次失败结果
bit6	testNotCompletedThisOperationCycle	置0：表示在当前OC周期内tested完成置1：表示在当前OC周期内tested未完成（或OC重启开始），0x14服务ClearDTC
bit7	warningIndicatorRequested	置0：如果没有和DTC相关的警告存在，该位应置0，0x14服务ClearDTC ，healing发生置1：testfailed, 故障上报并达到指定的阈值

bit 0：testFailed
在这里插入图片描述
注：bit 0：testFailed并不一定会存储在EEPROM里。
bit1：testFailedThisOperationCycle

注：bit 1 (TestFailedThisOperationCycle)会被存储在非易失性内存中。
OC可以含有多个检测周期，只要有一个检测周期出现testFailed=1的情况，此bit置1。

一般地，一个OC是ECU通过网络管理唤醒到ECU通过网络管理进入休眠，对于没有网络管理的ECU，这个起始点就是KL15通断。通过bit 0我们无法判断某个DTC是否出现过，比如，当前testFailed = 0，说明当前这个DTC没有出错，如果testFailedThisOperationCycle = 1的话，就说明这个DTC在当前这个OC中出过错，但是当前错误又消失(恢复)了。

bit2：pendingDTC
在这里插入图片描述

DTC的状态位并不是一达到testfailed就会转变，而是故障出现一段时间后才会被确认，就像bit3，而中间的这个状态就用bit2位来表示，bit2位其实是表示DTC处于testFailed和confirmedDTC之间的一个状态，因此bit2位又可被称为待定DTC。

bit3：confirmedDTC
在这里插入图片描述
当bit3置1时，说明故障已经发生了一段时间（具有tested且failed的OC达到阈值次数），也就是bit2至少有一次被置1了。需要注意的是，bit3置1的时候，DTC被存储在EEprom中，但并不代表现在故障还存在，可理解为历史故障。
注：comfirmed的阈值可以通过Dem的外部接口Dem_SetEventConfirmationThresholdCounter更改。

bit4：testNotCompletedSinceLastClear
在这里插入图片描述

不是所有的DTC测试都是从一上电就开始，所以该位用来表示上次调用14服务清除诊断消息后，是否进行过完整的test。如果进行了完整的test，无论结果如何，都置0，否则置1。

bit 5：testFailedSinceLastClear
在这里插入图片描述

该位表示在上次调用0x14服务清除DTC后，若DTC未进行测试或者测试了但结果是passed时置0，如果tested并且返回结果为failed，那么该位置1。在调用14服务清除DTC后，替换发生，老化需要置0。bit4和bit5通常一起使用。

bit6：testNotCompletedThisOperationCycle
在这里插入图片描述

testNotCompletedThisOperationCycle表示在当前OC中是否成功地执行了对某个DTC的测试。

bit7：warningIndicatorRequested
在这里插入图片描述
该位报告警告指示，比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示,需要根据需求配置。bit7(warningIndicatorRequested)置1和bit3(comfirmed)相似，而bit7(warningIndicatorRequested)置0，则需要一个healing的过程。