【UDS诊断协议--0x19服务】DTC之状态位

最新推荐文章于 2024-03-29 21:45:57 发布

.桃花依旧笑春风

最新推荐文章于 2024-03-29 21:45:57 发布

阅读量1.1w

点赞数 24

分类专栏： # 智能驾驶（入门）文章标签： autosar

本文链接：https://blog.csdn.net/qq_43620805/article/details/122811738

版权

智能驾驶（入门）专栏收录该内容

20 篇文章 199 订阅

订阅专栏

接这上篇博客简单介绍了0x19服务，现在我们就讲解下19服务的重点状态位以及在代码中Event是如何关联DTC的，同时Autosar Event的滤抖机制，都会在这篇博客中讲解，希望能够对新入门汽车行业的你有些帮助
好吧！言归正传

1.备忘录

在这里插入图片描述
dtc的状态位是一个字节，其中每个Bit都对应这具体的含义，对应着上面的图片（之前在学习的时候这个不理解，弄了好久才明白，之后就豁然开朗，所以不要怕遇到问题，停滞不前，一旦你明白了现在就问题，就会打通你的任督二脉，关联其他的问题你也将会解决，感受到成长进步的快感！！！）

2.状态位的介绍

在这里插入图片描述

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个状态位只用文字描述的话会略显抽象，如果在工作中看到这些状态位的变化，那么就很好理解它了。

3.DTC故障类型

以非排放相关的ECU为例，可以将DTC故障类型分为以下几个部分：

硬件故障；如RAM、Flash、CPU时钟等硬件本身失效的问题

软件故障；如配置字故障，标定故障或客户定义的软件功能性故障

外部环境故障；电压过高或者欠压、环境温度过高或过低等

通讯相关故障；如报文丢失、信号无效，Checksum/AliveCounter故障等

4.DTC与Event的区别与联系

区别：

DTC是某类故障的统称，能够大体定位到某个模块的故障，而event则是故障监控的基本单元，能够定位某个模块中的某个具体故障；

多个event可以mapping 同一个DTC；而同一个event不能mapping 多个DTC；
DTC可以直接可见，但Event需通过进一步手段才能看到，有时仅对ECU供应商可见；
联系：

DTC代表某类event集中表现，而event则是某个DTC的具体实例；
DTC的状态位是其map的所有event的状态位的或集；
event之间的依赖关系决定了DTC的依赖关系；
event的优先级决定了DTC的优先级；
2. DTC状态位

当出现DTC时，我们只知道有故障发生了这一个基本事实，但是并不知道该故障什么时候发生，现在是否已经恢复、发生过几次，恢复过几次等细节性信息，因此国际标准组织ISO发布14229-1来引入DTC状态位这一概念来得到上述细节性信息，使我们对该故障的生前生后有个清晰的认识，便于我们快速定位问题所在。每一个DTC均有对应的DTC状态位，该DTC状态位由一个字节表示，每个bit都有其重要含义
具体解释如下：

Bit0: 请求时刻测试结果为失败；

Bit1: 在当前点火循环至少失败过1次；

Bit2: 在当前或者上一个点火循环测试结果不为失败；

Bit3: 请求时刻DTC被确认，一般确认是在一个点火周期内发生错误1次；

Bit4： 自上次清除DTC之后测试结果已完成，即测试结果为PASS或者FAIL结果；

Bit5: 自上次清除DTC后测试结果都不是FAIL;

Bit6: 在当前点火周期内测试结果已完成，即为PASS或FAIL状态；

Bit7: ECU没有得到点亮警示灯请求；

5.DTC的信息存储

事实上当DTC产生时，并不会直接存储在NVM中，而是直接存储故障e event的方式，然后间接通过event-DTC的mapping关系来存储DTC，而DTC的状态位则是由其mapping的所有event的状态位的或集，如下图3-1所示。大多数情况下光有DTC号以及状态位信息往往不能一步到位定位root cause，需要引入环境信息才能够进一步确定问题所在，因此ISO组织便引入了以下两个基本概念：快照数据（Snapshot Data）、扩展数据（Extended Data）。

If Event 1 -> DTC A; Event 2 -> DTC A; … Event N -> DTC A;

Then DTC A Status = Event 1 Status | Event2 Status | …| Event N;

    DTC A 同时Map了Event 1 ～ Event N，则DTC A Status即为上述map的或集，但是具体是哪个event先报，则取决于event之间的优先级以及上报策略来综合判断。

Snapshot Data：顾名思义快照信息即为故障发生时刻存下来的瞬态的环境数据，一般是指电源模式、温度、时间戳、车速等信息。

Extended Data：即为在故障发生时其他的辅助故障信息，如aging counter、aged counter 、Fault Counter以及event id等。

另外，对于DTC信息存储一般简单理解可以分为两部分存储空间，该划分更多的是逻辑意义上的定义，这样区分的意义在于能够更好的实现主机厂与供应商的信息隔离，防止出现不必要的误解与多余信息的讨论。

Primary Memory：对主机厂以及ECU供应商可见的DTC信息空间，如DTC Status、Snapshot Data、Extended Data等；

Second Memory：仅ECU供应商内部可见的信息，如event ID、ITC等信息。

限于主题，所以NVM信息存储点到为止，后续关于NVM信息存储的机制会通过专题与大家一起分享学习。

6.DTC信息及状态的读取

DTC会在ECU运行过程中产生、变化并被实时记录下来，对于ECU供应商或者主机厂则可以通过诊断服务的方式来实现DTC信息及状态位的读取，如下图4所示，通过以下几种方式便可以得到ECU支持的DTC、当前或历史DTC、Snapshot Data、Extended Data ，DTC status等信息。

在这里插入图片描述