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诊断协议中服务ID为35的功能和用法 #### 1. 服务ID为35的定义 在UDS(Unified Diagnostic Services)协议中,服务ID为`0x35`对应的是“报告事件检测状态”(Report Event Detection Status)。该服务用于查询特定DTC(Diagnostic Trouble Code)的状态变化情况。通过此服务,诊断工具可以获取到某个DTC是否发生了新的状态变更,例如从正常变为激活或从激活变回正常。 这一功能的核心在于提供一种机制来监控车辆内部系统的健康状况以及故障码的变化趋势[^1]。 #### 2. 请求消息结构 当诊断设备向ECU发送关于服务ID `0x35` 的请求时,其PDU(Protocol Data Unit)通常由以下几个部分组成: - **Service ID**: 始终固定为`0x35`。 - **Sub-function**: 表明具体的操作子类型,对于某些实现可能不需要额外参数即可完成操作。 - **DTC Identifier (可选)**: 如果指定,则仅返回与此识别符关联的信息;如果不指定,默认针对所有已知DTCs执行相应动作。 以下是构建这样一条基本请求的一个Python示例代码片段: ```python def create_request(service_id=0x35, sub_function=None, dtc_identifier=None): request = [service_id] if sub_function is not None: request.append(sub_function) if dtc_identifier is not None and isinstance(dtc_identifier, int): # Assuming DTC identifier fits into three bytes as per ISO standards. request.extend([(dtc_identifier >> 16) & 0xFF, (dtc_identifier >> 8) & 0xFF, dtc_identifier & 0xFF]) return bytearray(request) # Example usage of the function to generate a minimalistic 'report event detection status' request without specifying any particular DTC. minimal_request = create_request() print(minimal_request.hex()) ``` 上述脚本展示了如何创建一个最简单的不含任何附加选项的服务调用实例[^2]。 #### 3. 响应消息解析 来自ECU的回答同样遵循严格的格式规范,它至少应该包含以下几项内容: - **Positive Response Service ID**: 正常情况下回应的服务编号将是原数值加$40_{hex}$即成为`0x75`. - **Echoed Subfunction**: 反射回来最初询问里携带的那个细分函数值用来确认双方讨论同一话题. - **EventStatusMask Record(s)**: 这些记录包含了实际的数据字段描述当前各个条件下的触发情形. 下面是一段伪代码展示怎样处理接收到的标准回复包: ```python def parse_response(response_bytes): parsed_data = {} service_id = response_bytes[0] echoed_subfunciton = response_bytes[1] parsed_data['Service_ID'] = hex(service_id) parsed_data['Echo_SubFunction'] = hex(echoed_subfunciton) start_index = 2 while start_index < len(response_bytes): record_length = response_bytes[start_index] current_record = response_bytes[(start_index + 1):(start_index + 1 + record_length)] # Process each individual record according to specification... start_index += (record_length + 1) return parsed_data example_positive_response = b'\x75\xFF\x0A\xAB\xCD' parsed_example = parse_response(example_positive_response) for key,value in parsed_example.items(): print(f"{key}: {value}") ``` 注意这里只是简化版示意程序,并未完全按照标准文档编写全部细节[^3]. #### 结论 综上所述,UDS中的服务ID `0x35` 主要负责追踪并汇报有关于不同错误编码(DTCs)之间转换活动的相关情报。尽管初次接触可能会觉得抽象难以掌握,但随着实践经验积累自然能够更加深入领会其中奥秘[^4]。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

king110108

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

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

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

打赏作者

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

抵扣说明:

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

余额充值