UDS诊断中DTC的故障Status解析

       UDS协议是描述车载诊断内容的通用协议，诊断的功能伴随着ECU整个生命运行周期一直在运行。当控制器（ECU）运行过程中出现需求规范中所定义的故障类型，控制器通过相应的判定机制来判断这个故障是否达到一定阈值，满足产生DTC的条件（需要将DTC以及Status位存储在ECU内存中）。因此首先明白判定机制。

      对于具体一个控制器，定义诊断需求规范时，首先会定义它支持的DTC以及每个DTC名称、Enable Criteria、Test Frequency、Set condition、Correct Actions等等。比如控制器正常工作电压值是8-12 V，当控制器供电电压超过18 V为电压过载故障，并定义故障码为DTC1。众所周知，车载运行是一个非常复杂的运行状态，运行过程中不可避免会出现电涌等现象（电压出现峰值），当出现电涌，电压值大于18 V，又很快恢复正常电压，因此DTC不应该被记录。所以会有如下机制：

1、 在规范中会定义检测频率，并设置一个Counter值；

2、 每一个检测周期，通过采样模块，获取当前电压值；

3、 若当前检测周期测出当前电压值大于18 V，Counter +1；

4、 若检测电压值在正常工作电压范围，Counter -1；

5、 规范中定义当Counter值 = 20时，才判定此电压过载DTC产生并存储在ECU内存中。

通过以上判定机制来判断DTC对应的故障是否产生。而关于DTC Status状态位：

而在了解关于DTC Status每一个bit位触发条件以及含义前，先搞清楚以下几个概念：

• Test：是一种车载诊断软件算法，根据不同的测试周期，得出最后的测试结果：Pass or Failed;
• Completed： “ 完成”表示测试能够确定当前操作周期是否存在故障 （“完成”并不表示发生故障）;
• Operation Cycle：一个操作周期指监视器运行的开始和结束条件，在一个操作周期内，可能已完成若干个监视周期（无论其测试结果如何）。ECU可以支持多个操作周期， 一个操作周期可以是ECU通电和断电之间或者点火打开和点火关闭之间的时间，也可以是ECU从网络唤醒到网络休眠的时间。
• Pending：根据UDS规范解释，如果在当前或者上一个operation cycle中出现过具体某个DTC，pendingDTC=1。此时状态可以理解为一种中间状态（testerFailed和ConfirmedDTC之间）。

bit 0 : testFailed

通常来说，ECU内部以操作循环的方式不断地针对预先定义好的错误路径进行测试，如果在最近的一次测试中，在某个错误路径中发现了故障，则相应DTC的这一个状态位就要被置1（e.g.在检测周期采样电压大于18 V）。此时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中出过错，但是当前错误又消失了（用0x14清除了，或者DTC置起的条件不满足了，eg. 在检测周期采样电压在8~12V之间了）。

bit 2 : pendingDTC

根据UDS14229规范的解释，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服务（有些硬件故障DTC是不能通过0x14服务直接删除的，需要把内存中记录的数据删除才可以）。

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有些类似，testFailedThisOperationCycle标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况，而testFailedSinceLastClear标识的是在上次执行过清理DTC之后某个DTC是否出过错。

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

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

bit 6 : testNotCompletedThisOperationCycle

这个位与bit 4 : testNotCompletedSinceLastClear类似，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。

                   

对于控制器，在定义其诊断需求规范时会选择支持的DTC Status中的bit位、DTC触发条件、检测频率等，通过软件代码来实现检测功能。