跟我学UDS(ISO14229) ———— 0x19 服务参数介绍
相关链接:跟我学UDS(ISO14229) ———— 0x19(ReadDTCInformation)目录前言工作状态bit 作用说明bit 切换逻辑19 01(reportNumberOfDTCByStatusMask)请求正响应19 02(reportDTCByStatusMask)请求正响应19 03(reportDTCSnapshotIdentification)请求正响应前言 虽然在上面
相关链接:跟我学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) | Name | Description |
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 位被清除。
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)