诊断知识:DTC Status中pending位的使用

前言

上一篇文章介绍了ConfirmedDTCLimit的使用,诊断知识:ConfirmedDTCLimit的使用,后面发现理解还是有问题的,其实原来的图画的没有问题,之前对OCC6理解有误,本文进行修正

OCC6的定义

之前理解,只要当前操作周期出现过pass,OCC6就是要清除的,这样就会和confirm的标准定义违背。为此,我查阅了Autosar DEM标准和14229标准,DEM中对于Confirm bit的定义如下:
在这里插入图片描述
其中关于failure counter,上一个操作周期出现故障,则加1,当前操作周期fail,且failure counter + 1大于ConfirmDTCLimit,则confirm位置1

failure counter在上一个操作周期完成测试且操作周期内未出现故障,则在当前操作周期清0。

所以,只要当前操作周期出现过fail,failure counter就不会清0了。

在14229中定义如下:
在这里插入图片描述
这里的TripCounter也就是OCC6。此处清0应该也是上一个周期完成测试且未检测到故障

总结一下OCC6:表示连续出现fail的操作周期,当操作周期内出现fail时加1,当操作周期内出现pass且未出现fail时清0(因为当前周期即使pass也无法判定后面不会出现fail,所以需要到当前操作周期结束才清0,实际表现就是下一个操作周期才看得出来被清掉了),或者达到Confirm时清0

所以OCC6并不是pass就清0的,所以OCC6可以用来作为confirm位的判断条件。

pending位的定义

pending位刚好符合OCC6的这个需求,所以pending位是confirm位的中间状态。pending位表示为当前操作周期或上一个操作周期故障
在这里插入图片描述
pending清0需要当前操作周期测试完成,且一直为pass,在操作周期结束的时候清0,在下一个周期读取的时候就读不到pending了,除非再次触发fail,

pending位的使用

之前的图片画的是对的:confirmDTCLimit = 2
在这里插入图片描述

ColourDescription
1Confirmed
2Pending
3Failed
3Passed

在OCC#1,即使有pass,也不会清OCC6,此时OCC6 = 1且pending位保持。直到#4,出现pass且整个操作周期都未出现fail,则pending位清0.

在OCC#2,再次触发一次fail,此时OCC6 = confirmDTCLimit,触发confirm

总结

本文的关键知识点为,confirm的触发并不是要连续的fail循环,而是连续出现fail的循环。pending位正好是为连续出现fail的循环而设定的。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

赞哥哥s

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值