UDS结合实例——DTC执行的逻辑和DTC的存储

最新推荐文章于 2025-03-10 16:05:52 发布

帅气小胖子

最新推荐文章于 2025-03-10 16:05:52 发布

阅读量1.8k

点赞数 19

文章标签：服务器 linux 前端车载系统汽车

本文链接：https://blog.csdn.net/WE_BIG/article/details/145105106

版权

开篇总述：

DTC的结构和基本信息之前一篇文章就讲解过，如何理解汽车诊断中的，诊断故障代码DTC_dtc故障码-CSDN博客，不过对DTC的执行逻辑和存储策略讲的不是很清晰，于是专门来讲清楚。

1、DTC执行的逻辑

规范中的这个图就非常直观的显示了DTC的执行逻辑：

x轴主要是时间信息，已经在下图标注了一个完整的Operation Cycle的时间周期。主要关注Y轴，我们从上往下看：

1.1、Operation Cycle

操作循环，大致等于很多资料中说的“点火循环” ，我所知道的大部分的DTC的“操作循环”=“点火循环”，点火循环的意思就是key="OFF"->"ACC"->"ON"->"CRANK"->"OFF",如果不理解，先记住即可。

1.2、Test Sample

测试采样点:"Test Sample",了解这个概念之前。我先举个比较简单的实例：

报文0x110丢失DTC (U1 22 12)，在检测前提条件满足的情况下，CDD或诊断调查表中会描述：“连续500ms未检测0x110报文则报出0x110丢失DTC (U1 22 12)”。这里假设0x110发送周期为100ms。

那500ms内，查询几次0x110报文接收的状态，就是“Test Sample”

接着玩下看：

1.3、"Fault detected at moment of test run"

错误在测试运行中被检测到、 "Fault not detected at moment of test run"错误未在测试运行中被检测到。可以看到这两个检测的频率之和="Test Sample"检测频率。也就加深了我们对"Test Sample"的理解，即“在每一个 "Test Sample" 中必须得出一个测试的结果，错误被发现或没有错误”

1.4、“Fault Detection Count

”错误检测计数，有分为两个参数:如下

1、prefailed：预定义错误计数，这个值为（0-127），这里有一个问题，每次错误被检测到错误计数+多少的问题？

答：这个是主机厂或供应商自己定义的，下图可参考

我们来计算一下连续10次检测失败，则 128/10=12.8，商取整数=13。则每次检测到错误，prefailed +13。

2、prePassed：预定义通过计数，这个值为（-128,0），这个值没检测到一次通过，prePassed+（-13）

小结：

1、两种参数的变化是独立的，没有线性的关联关系。一种参数只能连续自增或自减。当自增、自减被中断会直接被重置为0。

继续往下看：

1.5、testFailed 初始值00

testFailed=01的判断条件其实，只有一条当prefailed >=127时，testFailed =01、当prefailed<127时，testFailed =00。

不过还存在几种特殊情况，

（1）当本次操作循环结束后，到下次操作循环开启时，testFailed会被初始化为0。

（2）0x11服务，复位后，testFailed也会被初始化，同理断电上电也会被初始化！

1.6、testFailedThisOperationCycle

初始值00

就是本次操作循环中，只要触发一次prefailed >=127，该位就会一直置位=01。

不过还存在几种特殊情况，

（1）当本次操作循环结束后，到下次操作循环开启时，testFailed会被初始化为0。

（2）0x11服务，复位后，testFailed也会被初始化，同理断电上电也会被初始化！

1.7、pendingDTC

默认初始值00 ,挂起DTC，结语当前DTC和确认DTC之间的一种DTC形态，这有涉及到DTC存储策略中的另外一个计数器参数“Occurrence Counter”，错误发生计数，详情下文会在讲解DTCExtented中讲解。但是具体Occurrence Counter=多少时，可以由主机厂或供应商自行决定。

注意pendingDTC的状态，并不会再“操作循环结束后重置”，也不会因为0x11复位，或重新上下电而被重置！！

1.8、Confirm DTC

默认初始值00,确认DTC,同样和，DTC存储策略中的另外一个计数器参数“Occurrence Counter”，错误发生计数有关。

注意pendingDTC的状态，并不会再“操作循环结束后重置”，也不会因为0x11复位，或重新上下电而被重置！！

1.9、testNotCompleteSinceLastClear：

“自从上次清除后，测试未完成”，这里的概念可以分为两个部分理解：

（1）“测试完成”或“测试未完成”的概念，判断标准只有prePassed<128,或prefailed >127,时认为测试完成。

（2）“上次清除”中的“清除”概念，这个概念比较复杂，首先我们知道prePassed和prefailed是必须连续变化的，只要计数中断后，立即=0，例子如下：prePassed先自增到-110，然后立即prefailed自增到5，此时prePassed立即=0。

结合理解；即prePassed或prefailed被重置为0后，prePassed或prefailed还没有达到阈值。

不过还存在几种特殊情况，

（1）当本次操作循环结束后，到下次操作循环开启时，testFailed会被初始化为0。

（2）0x11服务，复位后，testFailed也会被初始化，同理断电上电也会被初始化！

1.10、TestFailSinceLastClear

prePassed或prefailed被重置为0后，prefailed还没有达到>127的阈值。

不过还存在几种特殊情况，

（1）当本次操作循环结束后，到下次操作循环开启时，testFailed会被初始化为0。

（2）0x11服务，复位后，testFailed也会被初始化，同理断电上电也会被初始化！

1.11、testNotCompleteThisOperationCycle

测试未完成，在这个操作循环中，初始默认值为0x01，这个很好理解，此操作循环中prePassed或prefailed还没有达到阈值，就认为是测试未完成。

1.12、思考问题？

如果你有耐心看到这里，说明你是用心读了，

那么你们心中是不是有个疑问？怎么搞出这么多状态，可能大家实际接触的项目中也基本只支持

testFailed，pendingDTC 和ConfirmDTC,这几种。一般来说其实也够用了。

但是只要我们理解了上文的描述，实际情况可能更复杂：如下

prePassed先递减到-10，然后preFailed开始递增到 150，然后prePassed从0开始又递减到-10,然后，然后preFailed开始递增到 150。这种状态下，明显是错误被检测出来的概率，比测试通过概率大的多，但是确不会报出任何DTC,以及任何错误状态下的DTC?，这样合理吗？明显是不合理的。

于是我们使用testNotCompleteSinceLastClear这个服务，就能够检测到这种错误

1.13、补充一个DTC老化的逻辑

“DTC老化”，我觉得这个翻译不太好，有些资料把DTC老化叫做"DTC的自恢复"，个人觉得这种翻译说法更接近于实际意义。

DTC老化的解释：系统中已经检测到一个ConfirmDTC了，但是后续，在满足检测条件的前提下，100个操作循环中，都没有检测到该DTC，那么这个DTC是否还有存在的必要？DTC老化就是这个意思。即固定的检测环境下，对特定类型的DTC(一般都是ConfirmDTC),一个操作循环中，没有检测到DTC，则老化计数自动加上一个“固定值”。当连续若干个操作周期内都没有检测到错误后，老化计数器>设定的一个值后。DTC被清除（连带该被清除的DTC相关的快照和拓展信息全被除）。

规范中并没有规定，老化计数自动加上一个“固定值”这个固定值的大小，只是必须是正整数（不包括0），一般都是+1。

连续检测的意思是，如果出现中断，就是指中间掺杂了一个检测到DTC的操作周期后，老化计数会被重置，一般都是重置为0.