ECU中DTC的状态位

从汽车ECU中读取储存的DTC(故障码)时,除了故障码本身,还可以读出很多其他的信息,包括优先级、发生次数计数器、发生时的里程和时间,以及本文中所讲的状态位(DTC status )。

这个状态位包含1个byte,这里面的8个bit都有各自的含义,但是这8个 bit不一定都要使用,各个主机厂可以根据自己的需求使用其中的几个,当然也可以全部使用。下图是UDS对DTC status这8个bit的定义。

在这里插入图片描述

DTC status中8个状态bit的定义

bit 0 : testFailed

通常来说,ECU内部以循环的方式不断地针对预先定义好的错误路径进行测试,如果在最近的一次测试中,在某个错误路径中发现了故障,则相应DTC的这一个状态位就要被置1,表征出错。此时DTC的testFailed位被置1,但是它不一定被ECU存储到non-volatile memory中,只有当pendingDTC或confirmedDTC被置1时DTC才会被存储。而pendingDTC或confirmedDTC被置1的条件应该是检测到错误出现的次数或时间满足某个预定义的门限。当错误消失或者诊断仪执行了清除DTC指令时,testFailed会再次被置为0。

bit 1 :testFailedThisOperationCycle

这个bit用于标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况,即是否出现过错误。operation cycle的起始点是ECU通过网络管理唤醒到ECU通过网络管理进入睡眠,对于没有网络管理的ECU,这个起始点就是KL15通断。通过bit 0我们无法判断某个DTC是否出现过,比如,当前testFailed = 0, 说明当前这个DTC没有出错,如果testFailedThisOperationCycle = 1的话,就说明这个DTC在当前这个operation cycle中出过错,但是当前错误又消失了。

bit 2 : pendingDTC

根据规范的解释,pendingDTC = 1表示某个DTC在当前或者上一个operation cycle中是否出现过。pendingDTC位其实是位于testFailed和confirmedDTC之间的一个状态,有的DTC被确认的判定条件比较严苛,需要在多个operation cycle中出现才可以被判定为confirmed的状态,此时就需要借助于pendingDTC位了。pendingDTC = 1的时候,DTC就要被存储下来了,如果接下来的两个operation cycle中这个DTC都还存在,那么confirmedDTC就要置1了。如果当前operation cycle中,故障发生,pendingDTC = 1,但是在下一个operation cycle中,故障没有了,pendingDTC 仍然为 1,再下一个operation cycle中,故障仍然不存在,那么pendingDTC 就可以置0了。

bit 3 : confirmedDTC

当confirmedDTC = 1时,则说明某个DTC已经被存储到ECU的non-volatile memory中,说明这个DTC曾经满足了被confirmed的条件。但是请注意,confirmedDTC = 1时,并不意味着当前这个DTC仍然出错,如果confirmedDTC = 1,但testFailed = 0,则说明这个DTC表示的故障目前已经消失了。将confirmedDTC 重新置0的方法只有删除DTC,UDS用0x14服务,OBD用0x04服务

bit 4 : testNotCompletedSinceLastClear

这个bit用于标识,自从上次调用了清理DTC的服务(UDS用0x14服务,OBD用0x04服务)之后,是否成功地执行了对某个DTC的测试(不管测试结果是什么,只关心是否测了)。因为很多DTC的测试也是需要满足某些边界条件的,并不是ECU上电就一定会对DTC进行检测。

testNotCompletedSinceLastClear = 1 : 自从清理DTC之后还没有完成过针对该DTC的测试。

testNotCompletedSinceLastClear = 0 : 自从清理DTC之后已经完成过针对该DTC的测试。

bit 5 : testFailedSinceLastClear

这个位与bit 1 :testFailedThisOperationCycle有些类似,后者标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况,而testFailedSinceLastClear标识的是在上次执行过清理DTC之后某个DTC是否出过错

testFailedSinceLastClear = 0 , 自从清理DTC之后该DTC没有出过错。

testFailedSinceLastClear = 1, 自从清理DTC之后该DTC出过至少一次错。

bit 6 : testNotCompletedThisOperationCycle

这个位与bit 4 : testNotCompletedSinceLastClear类似,后者标识自从上次调用了清理DTC的服务之后,是否成功地执行了对某个DTC的测试。而testNotCompletedThisOperationCycle则标识在当前operation cycle中是否成功地执行了对某个DTC的测试

testNotCompletedThisOperationCycle = 1 : 在当前operation cycle中还没在完成过针对该DTC的测试。

testNotCompletedThisOperationCycle = 0 : 在当前operation cycle中已经完成过针对该DTC的测试。

bit 7 : warningIndicatorRequested

某些比较严重的DTC会与用户可见的警告指示相关联,比如仪表上的报警灯,或者是文字,或者是声音。这个warningIndicatorRequested就用于此类DTC。

warningIndicatorRequested = 1 : ECU请求激活警告指示。

warningIndicatorRequested = 0: ECU不请求激活警告指示。

注意,如果这个DTC不支持警告指示,则这个位永远置0。

总结来说,这8个状态位只用文字描述的话会略显抽象,如果在工作中看到这些状态位的变化,那么就很好理解它了。

<think>好的,我现在需要帮助用户查询ECUDTC是否有新增故障码。首先,我得回忆一下关于DTC的基础知识。DTC是诊断故障代码,用于标识车辆中的问题。用户提到要检查是否有新增项,这可能涉及到比较当前的DTC列表和之前的记录。 根据引用[3],CAPL诊断函数checkDTC可以用来检查特定DTC是否存在。用户可能需要使用这个函数来逐个检查预期的故障码。不过用户的问题是关于新增项的,所以可能需要先获取当前和之前的DTC列表,然后进行比较。 接下来,查阅引用[2]中提到追加DTC故障码对应的Event,并且Event ID必须唯一。这可能意味着在系统中新增DTC需要关联Event,但用户的问题是如何检测新增,而不是添加。因此可能需要读取当前的DTC列表,并与历史记录对比。 引用[1]提到DTC掩码是1字节,用于匹配具体DTC。但用户需要的是检测新增,可能需要读取所有DTC状态,而不仅仅是掩码匹配的部分。 步骤可能包括:1. 读取当前DTC列表;2. 与之前保存的基准列表比较;3. 找出新增的DTC。根据引用[3]中的CAPL函数,可能需要循环检查所有可能的DTC,或者使用读取全部DTC的功能。 用户可能需要知道具体的操作方法,比如使用CAPL脚本中的诊断服务来读取DTC,然后存储并比较。可能需要使用类似ReadDTCInformation的服务,如服务0x19,子服务0x0A(报告支持的DTC),然后解析响应数据。 需要注意的是,不同的ECU可能支持不同的诊断服务,因此需要确认协议,比如UDS(ISO 14229)。另外,DTC的状态(如pending, confirmed, active等)也需要考虑,因为新增的故障码可能有不同的状态变化。 总结步骤:连接ECU,发送读取DTC的请求,获取当前DTC列表,与之前记录的列表对比,找出新增的条目。可能需要使用CAPL中的诊断函数或直接发送诊断指令。</think>要检查ECUDTC新增故障码,需通过诊断协议主动读取并对比DTC状态变化。具体步骤如下: ### 一、读取当前DTC列表 使用诊断服务$0x19$(ReadDTCInformation)配合子服务$0x0A$(报告支持的DTC),发送请求报文: ``` 19 0A ``` ECU响应会包含当前所有存储的DTC列表及状态(如confirmed/pending/active)[^3]。例如响应报文: ``` 59 0A 00 03 C1 01 00 C2 02 80 ``` 表示存在3个DTC:$C10100$(状态字节$C2$)、$C20280$(状态字节需按解析)。 ### 二、建立基准对比数据 1. 在ECU初始状态或无故障时,先保存基准DTC列表 2. 将数据存储为数组格式,例如: ```python baseline_dtc = ["C10100", "B201FF"] ``` ### 三、检测新增DTC 1. **实时读取DTC**: 使用CAPL脚本周期性检测(示例周期5秒): ```python on timer 5 { byte dtcList[100]; int count = diagReadDTC(0x19, 0x0A, dtcList); // 读取当前DTC compareWithBaseline(dtcList, count); } ``` 2. **状态比对**: 重点关注DTC状态字节的第3(新故障标志)。若该从0变为1,表示新增故障: ``` DTC状态字节 = 0x8A(二进制10001010)表示新确认故障 ``` ### 四、使用CAPL函数精准检测 通过预定义的检查函数验证特定DTC: ```python testfunction checkNewDTC(byte dtcNumber) { int result = checkDTC(dtcNumber, 0); // 预期无该DTC if(result == FAIL){ write("新增DTC: %02X", dtcNumber); } } ``` 调用时传入待监测的DTC编号,如$checkNewDTC(0xC101)$ ### 五、新增DTC判定条件 同时满足以下两项时为有效新增: 1. DTC代码不在基准列表中 2. DTC状态字节满足: $$ (CurrentStatus & 0x08) \neq 0 $$ 该公式检测"testFailedSinceLastClear"(bit3)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值