【UDS】ISO14229之0x19服务


->返回总目录<-

前言

简称: “ReadDTCInformation”,读取DTC信息
功能: 用户通过请求该服务,读取ECU的故障诊断码(DTC)信息,服务的sub-function代表了各式各样读取DTC的方法,UDS给19服务的sub-function从0x00到0x19进行了明确定义。
通俗解释:例如ECU功能工作电压一般在6V~18.5V之间。当软件通过ADC采样发现该模拟量通道输入电压低于6V时候,会经过一段时间的软件消抖后记录该供电电压欠压故障码,并通过0x19的子服务类型读取出来。如(是否为当前正在发生的故障,记录该故障那一时刻的其他快照信息 ,如车速,IGN状态等)。


一、理论描述

1.服务分类

0x01 reportNumberOfDTCByStatusMask(读取客户端定义状态掩码匹配的DTC(Diagnostic Trouble Code)数量)
0x02 reportDTCByStatusMask(读取客户端定义状态掩码匹配的DTC)
0x04 reportDTCSnapshotRecordByDTCNumber(检索客户端定义DTC掩码的记录数据(快照)如发生某一故障记录DTC时的车速,电源电压状态等)
0x06 reportDTCExtDataRecordByDTCNumber(读取某个DTC及其相关的环境数据,环境数据包括DTC状态,优先级,发生次数,老化计数器,时间戳,里程等,厂家还可以根据自己的需求定义一些此DTC产生时的测量数据。)
0x0A reportSupportedDTC(读取ECU支持的所有DTC的状态,包含支持的各个DTC编号以及相关状态)

博主在工作中基本上只用到这些sub-function,如果想了解所有的,大家可以参考规范手册哦!

2.状态掩码

由八个DTC状态位组成,占一字节。应用于请求消息中,以便客户端为状态与DTC状态掩码相匹配的DTC请求DTC信息。在这里插入图片描述
bit 0 : testFailed
指示最近执行test的结果,test失败置1,但是它不一定被ECU存储到EEprom中,只有当bit2或bit3被置1时DTC才会被存储。test通过则置0,如果调用了14服务清除DTC的话,也需要重新置0

“0”= DTC测试的最新结果表明未检测到故障。
“1”= DTC测试的最新结果表明了一个成熟的失败结果。

在这里插入图片描述

bit1:testFailedThisMonitoringCycle
该位表示在当前test中,诊断test是否已经报告了一个testFailed结果。当新的检测循环开始时,这个位需要置0,在调用了14服务后也需要置0。如果该位置1,那么一直保持置1状态直到新的检测循环开始,因此bit1可以理解为当前DTC。如果bit2和bit3通常一起使用。

“0”= testFailed:在当前操作周期内或在当前操作周期内调用ClearDiagnosticInformation后,尚未报告testFailed结果。
“1”= testFailed:在当前操作周期中至少报告了一次testFailed结果。

在这里插入图片描述

bit2:pendingDTC
根据ISO 14229的定义,当一个test结束时,若某个DTC满足故障触发条件,则bit2置1。bit2位其实是表示DTC处于testFailed和confirmedDTC之间的一个状态,称为待定DTC。因为DTC并不是一达到触发位就会被报出来的,而是故障出现一段时间后才会被确认,而中间的这个状态就用bit2位来表示,因此bit2位又可被称为待定DTC。当某个DTC刚达到判定条件的时候,bit2被置1,若一段时间后故障条件不满足了,则bit2置0,若一段时间后故障仍然存在,那么bit3就要置1了。

“0”= 在完成测试完成且未检测到故障的操作循环后或调用ClearDiagnosticInformation服务时,该位应设置为0。
“1”= 如果在当前操作循环中检测到故障,则该位应设置为1并锁定。

在这里插入图片描述

bit3:confirmedDTC
当bit3置1时,说明故障已经发生了一段时间,也就是bit2至少有一次被置1了。需要注意的是,bit3置1的时候,DTC被存储在EEprom中,但并不代表现在故障还存在,所以可以理解为历史故障。在调用14服务清除DTC后需要置0。

“0”= 自上次调用ClearDiagnosticInformation后,或在满足故障诊断码的老化条件(或由于故障记忆溢出而清除了故障诊断码)后,从未确认过故障诊断码。
“1”= 自上次调用ClearDiagnosticInformation后至少确认一次的DTC,且尚未满足老化标准

在这里插入图片描述

bit4:testNotCompletedSinceLastClear
因为并不是所有的DTC测试都是从上电就开始的,所以该位用来表示上次调用14服务清除诊断消息后,是否进行过完整的test。如果进行了完整的test,无论结果如何,都置0,否则置1。

“0”= 自上次清除诊断信息以来,DTC测试至少返回一次测试结果(无论通过或失败)。
“1”= 自上次清除诊断信息后,DTC测试尚未运行到完成。

在这里插入图片描述

bit5:testFailedSinceLastClear
该位表示在上次调用14服务清除后DTC后,若test DTC未进行测试或者测试了但结果是pass时置0,如果test运行完成并且返回结果为fails,那么该位置1。在调用14服务清除DTC后需要置0。bit4和bit5通常一起使用。

“0”=自上次清除诊断信息后,DTC测试未显示失败结果。如果满足老化阈值或发生故障记忆溢出,则车辆制造商应负责将该位重置为零(“0”)。
“1”=自上次清除诊断信息以来,DTC测试至少返回一次失败结果。

在这里插入图片描述

bit6:testNotCompletedThisOperationCycle
该位表示在当前检测循环周期过程中DTC test是否完成,若完成了置0,未完成置1。在调用ClearDiagnosticDTC后需要置1。

“0”= DTC测试在当前驾驶循环期间(或自上次在当前操作循环期间清除诊断信息以来)完成。
“1”= 此操作循环(或自上次清除此操作循环的诊断信息后),DTC测试尚未运行到完成。

在这里插入图片描述

bit7:warningIndicatorRequested
该位报告警告指示,比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示,如果没有和DTC相关的警告存在,该位应置0;如果该DTC有相关警告指示,bit3置1的时候,bit7也要置1。在调用14服务清除DTC后需要置0
在这里插入图片描述

举个栗子:博主项目中基本上都是状态掩码设置为0x09,即上图标红位置1。启用第0位和第3位(软件中配置)。当某一DTC发生且一直保持,则在ECU回复报文中的状态掩码字节为0x09。若该DTC发生过了,并且在我请求19服务时候已经不发生了,那么ECU回复报文中的状态掩码字节就变成了0x08(testFailed位不满足,置0)。

二、操作步骤

1.请求

19 01 / 19 02
在这里插入图片描述
如状态掩码设置为0x09,则图中第三个字节XX应该为09

19 04
在这里插入图片描述
该服务请求报文分为四段,在UDS中,每个DTC都有个名称–DTCMaskRecord。我们举个栗子,假设转向灯故障码名称设定为0xC14041。快照包含电源电压状态,车速信息。则该请求报文应为:19 04 C1 40 41 FF (读取转向灯故障发生时的快照信息), FF代表读取所有快照数据。

19 06
在这里插入图片描述
同理19 04服务,区别在于最后一个字节是DTCExtDataRecordNumber(DTC扩展数据记录编号),读取所有也设置为FF。按照上面转向灯故障的例子,扩展数据包含该故障发生次数。则该请求报文应为:19 06 C1 40 41 FF (读取转向灯故障发生次数信息)

19 0A
在这里插入图片描述
发送指令19 0A ,读取ECU支持的所有DTC列表以及各DTC的状态。

~

2.回复

1)积极响应

19 01
在这里插入图片描述
哇,请求报文辣么简约,ECU回复这么长。 ~~“有我在!别害怕”
解析:前两个字节就不解析了,看过之前的文章就知道了。
DTCStatusMask: (这一项客户会告诉你他的要求,莫担心)就是我们上面所说设置的状态掩码,我们就用0x09作为状态掩码。
标准上是DTCStatusAvailabilityMask,开发中都是我们设置好的掩码,可以理解成同一个数据09.只是为了筛选DTC的状态08 / 09

DTCFormatIdentifier: 故障码格式标识符,也就是说客户选择哪个标准的格式,如下图,我们选择SAE_J2012-DA_DTCFormat_00, 0x00。在这里插入图片描述

DTCCount: 满足DTCStatusMask的DTC个数。

综上所述ECU回复报文如下图所示:在这里插入图片描述

~

19 02
在这里插入图片描述
DTCAndStatusRecord: 满足DTCStatusMask 0x09(当前故障)的DTC以及状态。如:故障码0xC14041,0xC14042两个故障都正在发生。则ECU回复 59 02 09 C1 40 41 09 C1 40 42 09 (这种情况ECU回复的是多帧数据,下图仅供参考)如下图是发生一个故障时候的回复格式
在这里插入图片描述
~

19 04
在这里插入图片描述
举例读取转向灯故障码0xC14041发生时的快照数据
DTCAndStatusRecord :C1 40 41 09,其中09为设置的状态掩码
DTC快照记录组号: 占一字节,标准中要求的组号,就是为了分类下。
快照DID个数: 占一字节,该组号中的快照DID个数。
快照DID: 占两字节,每个快照数据都有它的ID。
快照DID的数据: 该快照具体的数据,具体占字节数,看客户要求的快照数据占多少字节。
我们假设快照记录组号为01,该组中有两个快照DID:0x0112电源电压,0x0113车辆启动按钮状态。则ECU回复数据如下:
59 04 (C1 40 41) 09 01 02 (01 12) 00 78 (01 13) 01 当转向灯发生故障时,电源电压为12V供电(0x0078转换十进制为120)。
启动按钮按下(01).

~

19 06
在这里插入图片描述
DTC扩展数据组号: 分类作用
扩展数据: 具体记录该故障时保存的数据,如发生故障次数。

我们假设DTC扩展数据组号为01,该组中有一个扩展数据:故障发生次数。则ECU回复数据如下:
59 06 (C1 40 41) 09 01 05。表示,故障C1 40 41发生了5次。

2)否定响应:
在这里插入图片描述

总结

是不是发现0x19服务相比较之前的服务要复杂些。的确如此。稳住!我们能赢。下一章0x14服务见~

->返回总目录<-

### UDS 19服务代码的静态代码分析 对于UDS 19服务代码的静态代码分析,可以采用多种工具和技术来确保代码质量和功能正确性。这些方法不仅有助于发现潜在错误,还能提高开发效率并增强系统的可靠性。 #### 使用静态分析工具 静态分析工具可以在不执行程序的情况下检查源代码中的缺陷和不符合编码标准的地方。针对UDS 19服务代码,推荐使用如下几种工具: - **Cppcheck**: 这是一个开源C/C++代码质量检测器,能够识别常见的编程错误如内存泄漏、数组越界访问等问题[^2]。 ```cpp // Example of Cppcheck command line usage $ cppcheck --enable=all path/to/uds_service_19_code/ ``` - **PCLint/FlexeLint**: 提供更深入的语法语义检查,并支持自定义规则集配置,适用于复杂项目的全面审查[^4]. ```bash # Running PCLint on a project directory containing UDS service code lint-nt.exe +config.lnt *.c ``` #### 编写单元测试框架辅助静态分析 除了专用的静态分析工具外,在编写过程中加入充分的单元测试同样重要。通过构建专门用于验证特定行为和服务响应逻辑的测试案例,可以帮助提前捕捉可能存在的问题。 例如,利用Google Test库创建针对UDS 19请求处理函数的测试用例: ```cpp #include <gtest/gtest.h> extern "C" { #include "uds_service_19.h" } TEST(UdsService19Test, PositiveResponseHandling) { uint8_t request[] = {0x19, /* ... */ }; uint8_t responseBuffer[64]; EXPECT_EQ(STATUS_OK, ProcessUdsRequest(request, sizeof(request), responseBuffer)); } ``` #### 遵循良好的编码实践 遵循一致性的命名约定、模块化设计原则以及详细的文档记录也是有效提升代码可读性和维护性的手段之一。这使得后续进行任何形式的手动或自动化审核都变得更加容易。 ---
评论 35
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

&春风有信

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

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

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

打赏作者

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

抵扣说明:

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

余额充值