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。

preview

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。

                   preview

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

### UDS协议中的DTC定义与解释 #### 1. DTC的基本概念 在汽车电子领域,UDS(Unified Diagnostic Services)是一种标准化的诊断通信协议,用于车辆内部ECU之间的诊断信息交换。DTC(Diagnostic Trouble Code),即故障码,在UDS协议中扮演着重要角色。它是用来表示特定故障条件的一种编码形式[^2]。 #### 2. DTC的格式 尽管ISO 14229-1作为UDS的核心标准并未明确规定DTC的具体格式,但它引用了多个国际标准来补充这一部分的内容。例如: - **SAE J2012** 是定义DTC代码及其含义的主要标准。该标准规定了如何构建和解读这些故障码。 - **ISO 15031-6** 主要针对排放相关的OBD(On-Board Diagnostics)系统进行了详细的DTC定义,并同样基于SAE J2012制定其规则。 - 随着技术的发展,某些新引入的标准如 **ISO 27145** 提出了增强型诊断需求下的三字节DTC格式,这与传统两字节OBD DTC有所差异。为了兼容不同类型的DTC解析方法,通常会借助DTC格式标志位来进行区分处理[^1]。 #### 3. DTC的状态及相关附属信息 除了基本的故障指示功能外,围绕每一个具体的DTC还存在一系列附加的信息帮助更深入理解当前系统的健康状况以及发生问题时的情境数据。主要包括以下几个方面: - **DTC状态 (Status)** 描述了一个给定DTC在其生命周期内的各种可能阶段或情形,比如是否已经被确认、目前处于活动还是历史记录等等。 - **快照信息 (Snapshot Information)** 当某个事件触发并关联到相应的DTC时所捕获的一组瞬态参数集合。这部分资料有助于分析人员重现当时环境条件下导致错误发生的因素。 - **扩展数据信息 (Extended Data Records)** 这些额外的数据字段提供了关于已报告DTC更加详尽的技术细节支持进一步排查工作。 ```python def interpret_dtc(dtc_code, dtc_format='standard'): """ Interprets a given DTC code based on the specified format. Args: dtc_code (str): The diagnostic trouble code to be interpreted. dtc_format (str): Format of the DTC ('standard' or 'enhanced'). Returns: dict: A dictionary containing interpretation details. """ if dtc_format == 'standard': # Standard two-byte OBD DTC parsing logic here... pass elif dtc_format == 'enhanced': # Enhanced three-byte ISO 27145 DTC parsing logic here... pass return {"code": dtc_code, "format": dtc_format} ``` 上述函数展示了根据不同DTC格式对其进行适当解析的一个简单框架示例。 ---
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

king110108

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

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

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

打赏作者

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

抵扣说明:

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

余额充值