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

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

1.备忘录

【UDS诊断协议--0x19服务】DTC之状态位_第1张图片
dtc的状态位是一个字节,其中每个Bit都对应这具体的含义,对应着上面的图片(之前在学习的时候这个不理解,弄了好久才明白,之后就豁然开朗,所以不要怕遇到问题,停滞不前,一旦你明白了现在就问题,就会打通你的任督二脉,关联其他的问题你也将会解决,感受到成长进步的快感!!!)

2.状态位的介绍

【UDS诊断协议--0x19服务】DTC之状态位_第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等信息。

【UDS诊断协议--0x19服务】DTC之状态位_第3张图片

下面篇内容 我们了解Autosar DEM DCM 模块 这两个模块就是对诊断与故障的处理,管理。内容比较多,希望读者能够好好理解前面的内容在去学习后面的进阶内容

你可能感兴趣的:(#,智能驾驶(入门),autosar)