跟我学UDS(ISO14229) ———— 0x19 服务参数介绍

相关链接:跟我学UDS(ISO14229) ———— 0x19(ReadDTCInformation)

DTCStatusMask

 虽然在上面的文章中,介绍了 0x19(ReadDTCInformation) 服务。但是,对于初学者和项目来说,并不是一定所有的服务都需要使用到。这也就可能导致了对于 0x19(ReadDTCInformation) 服务的使用上存在一定的不足。这篇文章旨在跟大家介绍一些简单易懂的命令已经实现的操作。在此之前,请先明白一个概念 —— DTCStatusMask / statusOfDTC

工作状态

 对于 DTCStatusMask 来说,不同的状态意味着不同的工作情况,具体的情况如下:

工作状态
状态 描述
Test 一种车载诊断软件算法,用于确定组件或系统的故障状态。
部分情况在一个操作周期内只运行一次。
测试结果代表完全成熟/合格的故障条件,也就是说需要在特定时间内出现失败条件或评估额外合理性检查的测试将在满足所有成熟标准后返回“Failed”条件。
每个测试都与一个唯一的 DTC 相关联,代表根本故障和可检测的故障症状。
PreFailed 指示测试当前正在成熟的故障条件。
此信息的一个用例是在制造中加速故障检测以优化工作流程,同时保持现场容错。
Failed 此状态在监视器运行完成并指示完全成熟的故障条件后可用。
Passed 此状态在监视器运行完成后可用,并指示系统或组件没有出现故障
Failure 是组件或系统无法满足其预期功能。
当检测到故障条件足够长的时间以保证存储未决或确认的 DTC 时,即发生故障,这意味着测试返回“Failed”结果。
Monitor 由一项或多项用于确定组件或系统正常运行的测试组成。
Monitoring cycle 监控器运行到其完整性的时间。
是制造商定义的一组条件,在此期间可以运行监视器的测试。
一个监控周期可能在一个操作周期内执行多次。
Operation cycle 定义了监视器运行的开始和结束条件。
在一个操作周期中,可能已经通过了几个监控周期。
一个 ECU 可以支持多个操作周期。
Pending 定义为在当前和/或最后完成的操作周期期间报告了该故障的“Failed”状态的测试结果。
一旦测试报告了此故障的完整操作周期的“Passed”条件,挂起状态将被重置。
Driving cycle 用于排放相关 ECU 的特定类型的操作循环。

bit 作用说明

各个bit的说明
位置 名称 说明 状态
bit0 testFailed  1. 指示最近执行的测试的结果。
 2. 逻辑“1”应表示最后一次测试失败,这意味着失败已完全成熟。
 3. 如果最近执行的测试的结果返回“pass”,则重置为逻辑“0”,这意味着已满足所有去成熟标准
 4. 车辆制造商/实施可以定义额外的重置条件
‘0’ = DTC 测试的最新结果表明未检测到故障(或测试尚未完成此操作周期)。

‘1’ = DTC 测试的最新结果表明成熟的失败结果。
bit1 testFailedThisOperationCycle  1. 指示诊断测试是否在当前操作周期内的任何时间报告了 testFailed 结果(或在当前操作周期内和上次调用 ClearDiagnosticInformation 之后报告了 testFailed 结果)。
 2. 当启动新的操作周期或调用 ClearDiagnosticInformation 后,重置为逻辑“0”。
 3. 如果该位设置为逻辑“1”,则它应保持为“1”,直到开始新的操作周期。
‘0’ = testFailed:在当前操作周期内或在当前操作周期内调用 ClearDiagnosticInformation 之后,结果尚未报告。

‘1’ = testFailed:在当前操作周期内至少报告了一次结果。
bit2 pendingDTC  1. 指示诊断测试是否在当前或最后完成的操作周期中的任何时间报告了 testFailed 结果。
 2. 仅当测试运行并完成时才更新状态。
 3. 设置pendingDTC 位和testFailedThisOperationCycle 位的标准是相同的。 不同之处在于testFailedThisOperationCycle 在当前操作周期结束时被清除,而待处理 DTC 位在操作周期完成之前不会被清除,其中测试至少通过了一次并且从未失败。
 4. 如果在当前操作周期内测试未完成,则状态位不应改变。
‘0’ = 在完成测试完成且未检测到故障或调用 ClearDiagnosticInformation 服务的操作周期后,该位应设置为 0。

‘1’ = 如果在当前操作周期中检测到故障,则该位应设置为 1 并锁存。
bit3 confirmedDTC  1. 指示故障是否被检测到足以保证 DTC 存储在长期存储器中。
 2. 确认的 DTC 并不总是表明在请求时存在故障(testFailed 可用于确定在请求时是否存在故障)。
 3. 在调用 ClearDiagnosticInformation 或满足老化标准后重置为逻辑“0”。
 4. 此外,当与此 DTC 相关联的故障记录被基于车辆制造商特定故障存储器溢出要求的较新DTC 覆盖时,该位将复位。
‘0’ = 自上次调用 ClearDiagnosticInformation 或满足 DTC 的老化标准后或由于故障存储器溢出 DTC 已被擦除,DTC 从未得到确认。

‘1’ = 自上次调用 ClearDiagnosticInformation 以来,DTC 至少确认一次,并且时效标准尚未满足。
bit4 testNotCompletedSinceLastClear  1. 指示自上次调用 ClearDiagnosticInformation 以来,是否曾经运行并完成 DTC 测试。
 2. (‘1’) 表示 DTC 测试尚未完成。
 3. 如果测试运行并通过或测试运行并失败(例如 testFailedThisOperationCycle = ‘1’),则该位应设置为 ‘0’(并锁存)。
‘0’ = 自上次清除诊断信息以来,DTC 测试至少返回了一次通过或失败的测试结果。

‘1’ = 自上次清除诊断信息以来,DTC 测试尚未运行完成。
bit5 testFailedSinceLastClear  1. 指示自上次调用 ClearDiagnosticInformation 以来,是否曾以失败的结果完成 DTC 测试。
 2. (‘0’) 表示测试未运行或 DTC 测试运行并通过(但从未失败)。
 3. 如果测试运行并失败,则该位应保持锁定为“1”。与confirmedDTC 不同,该位不会因老化标准或故障存储器溢出而复位。
‘0’ = 自上次清除诊断信息以来,DTC 测试未指示失败的结果。

‘1’ = 自上次清除诊断信息以来,DTC 测试至少返回了一次失败的结果。
bit6 testNotCompletedThisOperationCycle  1. 指示 DTC 测试是否曾经运行并在当前操作周期内完成或在上次调用 ClearDiagnosticInformation 之后的当前操作周期内完成。
 2. 逻辑“1”应表示 DTC 测试在当前操作周期内尚未运行完成。
 3. 如果测试运行并通过或失败,则该位应设置(并锁存)为“0”,直到开始新的操作周期。
0’ = DTC 测试在当前驱动循环期间或自上次在当前操作循环期间清除诊断信息以来返回了通过或 testFailedThisOperationCycle = ‘1’结果。

‘1’ = DTC 测试尚未运行到完成此操作周期(或自上次清除此操作周期诊断信息以来)。
bit7 warningIndicatorRequested  1. 报告与特定 DTC 相关的任何警告指示器的状态。
 2. 警告输出可能包括指示灯、显示的文本信息等。
 1. 如果特定 DTC 不存在警告指示器,则此状态应默认为逻辑“0”状态。
 3. 激活警告指示器的条件应由车辆制造商/实施定义,但如果警告指示器针对给定 DTC 开启,则确认 DTC 也应设置为“1”。
‘0’ = 服务器未请求激活warningIndicator。

‘1’ = 服务器请求warningIndicator 处于活动状态。

切换逻辑

 1. bit 0
在这里插入图片描述

 2. bit 1
在这里插入图片描述
 3. bit 2
在这里插入图片描述
 4. bit 3
在这里插入图片描述
 5. bit 4
在这里插入图片描述
 6. bit 5
在这里插入图片描述
 7. bit 6
在这里插入图片描述
 8. bit 7
在这里插入图片描述

DTCExtendedDataRecordNumber

 DTCExtendedDataRecordNumber 是一个单字节值,指示通过 reportDTCExtendedDataRecordByDTCNumber 子函数为客户端定义的 DTCMaskRecord 请求的特定 DTCExtendedData 记录的编号。

Introduction of DTCExtendedDataRecordNumber
Value(hex)Description
00 ISO reserved
01 请求服务器报告车辆制造商特定的存储 DTCExtendedData 记录。
...
8F
90 请求服务器报告合法的 OBD 存储的 DTCExtendedData 记录
...
EF
F0 ISO/SAE 为将来在单个响应消息中报告组而保留
...
FD
FE 请求服务器在单个响应消息中报告所有合法的 OBD 存储的 DTCExtendedData 记录。
FF 求服务器在单个响应消息中报告所有存储的 DTCExtendedData 记录

DTCSeverityMask

 DTCSeverityMask 包含三个 DTC 严重性位。 该字节用于请求消息中,以允许客户端为其严重性定义与 DTCSeverityMask 匹配的 DTC 请求 DTC 信息。 如果 DTC 的实际严重性位中的任何一个设置为 1 并且 DTCSeverityMask 中相应的严重性位也设置为 1(即,如果 DTCSeverityMask 与 DTC 的实际严重性逻辑与结果非零,则匹配发生)。每个服务器都应遵守协议中定义的存储位打包 DTC 严重性信息的约定。 严重性信息以一字节值报告。 仅使用一字节值的高三位(位 7-5)来表示 DTC 严重性信息。 其余位(位 4-0)必须设置为零 (0)。 基于此,以下位编码适用于包含在 1 字节 DTCSeverity 参数中的 3 位 DTC 严重性信息。

位置分布

在这里插入图片描述

说明

Introduction of DTCSeverityMask 3 bits
Value(hex)NameDescription
00 noSeverityAvailable 没有可用的严重性信息。
20 maintenanceOnly 指示故障仅请求维护。
40 checkAtNextHalt 表示故障需要在下一次停车时检查车辆。
80 checkImmediately 表示故障需要立即检查车辆。

DTCFaultDetectionCounter

 非排放相关服务器的 DTC 故障检测计数器操作如下图所示。
在这里插入图片描述

数字说明

  1 —— test results = Passed。
  2 —— test results = Failed。
  3 —— 测试在达到最小值 (-128) 或最大值 (127) 时结束。
  4 —— 测试运行失败总是导致故障检测计数器增加到 0 以上(以免在测试完成并通过后将失败检测时间加倍)。
  5 —— 见 3。
  6 —— 设置了 pendingDTC 位,因为此示例用于与排放无关的服务器/ECU。是否实际需要支持每个 DTC 状态位在第一节中定义,不应从本示例中推断出来。
  7 —— 见 6。
  8 —— 不满足试运行条件(例如电压超出范围)。
  9 —— 测试未运行,因此故障检测计数器不变。
  10 —— 车辆制造商特定此位是否在操作周期之间保持或重置为零。

DTCAgingCounter

 此示例概述了 DTCAgingCounter 的操作,该计数器计算自故障上次失败以来的驾驶周期数。
在这里插入图片描述

数字说明

  1 —— DTCAgingCounter 在完成一个测试未失败的操作周期后递增。
  2 —— 在测试完成且未失败的操作周期后,pendingDTC 设置为零。 如果 ECU 不支持断电序列(即在点火开关关闭时立即关闭),它将无法检测到操作周期的结束。 因此在下一个操作周期开始时将pendingDTC位设置为零也是有效的。
  3 —— 见 1。
  4 —— DTCAgingCounter 继续增加,因为在这些操作周期内测试没有失败。
  5 —— 当老化标准完全满足(例如 DTCAgingCounter 达到特定值)时,confirmedDTC 设置为零。
  6 —— DTCAgingCounter 达到最大值(例如 40),此时 confirmedDTC 位被清除。

  • 7
    点赞
  • 56
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
### 回答1: 0x19服务04子服务实例是指在汽车的On-Board Diagnostic(车载诊断)系统中,用来获取车辆发动机转速、车速、油耗、冷却液温度等信息的一种服务14229-1是该服务在诊断码中所对应的故障码。 在实际运用中,当车辆的OBD系统出现故障时,会产生相应的故障码,以便汽车维修工程师进行快速的排故。而14229-1故障码则是指在获取0x19服务04子服务实例时,该服务返回的数据长度错误,可能是由于通讯出现了异常等问题导致的。针对这种故障,技术人员可以通过排查通讯线路、检查插头是否接触良好等方式进行处理。 总的来说,0x19服务04子服务实例与14229-1故障码是OBD系统中的重要组成部分,对于汽车维修工程师而言,熟练掌握其工作原理和常见故障处理方法是十分必要的。 ### 回答2: 0x19服务04子服务实例分析(14229-1)指的是汽车领域中的一种故障代码,也称为OBD故障码。它表示车辆的氧气传感器信号不正常,这可能会影响发动机控制系统的正常运行。氧气传感器是发动机控制系统的重要部分,一旦出现问题,可能会导致车辆的性能下降、油耗增加等问题。 在分析0x19服务04子服务实例时,需要通过故障诊断设备对车辆进行诊断。首先,可能需要检查氧气传感器的电路是否正常,包括检查传感器和相关接线是否损坏,是否存在松动或腐蚀等。其次,需要检查传感器是否需要更换,因为氧气传感器的寿命有限,需要定期更换。 在解决该故障码时,需要考虑到不同车辆的故障原因可能并不相同。例如,可能是由于空气滤清器未及时更换导致空气流量不足,或者是由于车辆行驶时长时间处于怠速状态导致氧气传感器未正常工作。因此,需要根据具体情况进行精细化诊断,以找出故障原因并采取相应措施加以处理。 总之,0x19服务04子服务实例分析是在车辆故障诊断过程中比较常见的故障码之一,需要对车辆进行细致的检查,然后才能确定具体的解决方案。汽车维修保养是一个非常复杂的领域,需要专业的技能和经验才能够胜任,因此建议车主在遇到故障时及时寻求专业技术人员的帮助。 ### 回答3: 0x19服务04子服务实例是指在汽车CAN总线上的诊断服务中的一个特定子服务实例,它通常与故障码读取、清除以及基本的故障诊断有关。该服务实例的标识码为0x19,表示它属于诊断服务的1类。具体来说,该服务实例的功能是用于读取和清除发动机控制模块(ECM)中保存的故障码。 在实际使用0x19服务04子服务实例进行故障诊断时,需要了解其子服务请求参数和响应参数。子服务请求参数一般包括故障码类型、故障码清除标识、故障码指示器状态等。而响应参数则包括故障码数量、故障码内容等信息。通过对这些参数的解析和分析,可以帮助技术人员准确地确定车辆的故障原因,并进行相应的维修和处理。 总的来说,0x19服务04子服务实例是汽车CAN总线诊断服务中的一个重要组成部分,它在故障诊断和维修中具有非常重要的作用。对于经常进行汽车维修和诊断的技术人员来说,了解和掌握该服务实例的使用方法和技巧至关重要,这有助于提高工作效率和诊断准确性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

小趴菜_自动驾驶搬砖人

谢谢大爷赏饭吃

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

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

打赏作者

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

抵扣说明:

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

余额充值