Event和DTC详解
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 | testFailed | 置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的过程。
3.2.4 DTC抑制
通过配置，DTC可以被抑制，DTC抑制的含义是：DTC的状态依然在Dem内部计算和切换，但是不会对外部可见。
4 参考资料
- Specification of Diagnostic Event Manager_AUTOSAR CP R22-11
1168
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
