作者 | 李伟 上海控安安全测评中心安全测评部总监
来源 | 鉴源实验室
01 DTC-Diagnostic Trouble Code（诊断故障代码）
车辆在运行的过程当中，控制器会监控状态，特定故障发生时控制器会记录这些故障。车辆送4S店进行维修保养时，工作人员会通过智能终端（实际就是诊断仪）来读取这些故障，以配合问题定位，方便维修和保养。这里工作人员读取的故障信息是一系列的字符代号，即DTC诊断故障代码。主机厂预先设定好故障跟代码的映射关系（类似于DID与数据内容间的映射），根据取得的代码号可以很快从故障代码表中定位到与之映射的实际故障内容（诊断仪程序中这些工作都是自动完成的，无需人工查找）。
在这里读取故障代码的服务不是我们之前介绍的$22服务，而是专用的$19服务。工程师根据各种信息完成车辆修复之后，确认DTC上报的故障消除，会使用智能终端清除ECU记录的故障信息，清除操作使用了$14服务来实现。
1.1 DTC的分类
对于UDS DTC的详细分类在ISO14229的附录中有具体的描述，本篇的目的是为了方便初学者入门，就不做过于深入的分析，随着在相关领域内的工作深入，今后可以进一步学习，入门后的工程师会更加容易理解规范的定义。
通过上一章节的叙述我们可以理解，车辆零部件可以记录的故障很多，主机厂设计DTC有两种选择，分别按照ISO15031和ISO14229进行，在主流的乘用车和商用车上，主机厂使用ISO14229相对多一点。
无论按照哪种设计，主机厂通常将DTC的故障分为4类，通过PCBU来表示，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统，这里我们又一次见到了车身、动力、底盘这三大件分类的强大，也证明了分类的经典和实用。
1.2 UDS DTC
对于各主机厂遵循的DTC Format Identifier具体定义在ISO14229标准附录部分有表格说明。我们举例了基于ISO14229的DTCFID-0x01格式的情况，这也是主机厂使用比较多的一种格式（如果这段内容不是很理解的话，继续往下看吧，后面会有对应的知识分享与这段进行呼应）。数据部分长度为3字节，格式如下图所示：
图 1
DTC的代码长度为7个字符，如：B1525_11实际在诊断中对应的16进制数显示为0x952511，各字符对应的bit位关系如下图所示：
图 2
实际上在主机厂设计DTC时具体的故障定义还会参考《SAE J2012DA：2013车辆诊断故障码定义》。在这个标准定义中将4个系统的故障码使用范围进行了划分，大体划分如下：0x0xxx-0x3xxx 划分P动力系统使用；0x4xxx-0x7xxx 划分C底盘系统使用；0x8xxx-0xBxxx 划分B车身系统使用；0xCxxx-0xFxxx 划分U网络系统使用。
将上文中0x952511，从16进制转换为2进制后，我们就可以发现，分类方式和第1位字符可以对应的系统，跟我们上文说的PCBU是一致的，通常对应关系为00：P、01：C、10：B、11：U。
第二位字符故障分类的定义大体如下：0XXX ISO/SAE控制定义、1XXX制造商自定义、2XXX制造商自定义、3XXX预留。对于DTC low byte如果主机厂未使用一般置零。
1.3 DTC状态
DTC status状态码是用来表明故障在指定时间上是否存在，以及故障测试状态情况的。总共1个字节表示8种不同的判断条件。ISO14229附录D有详细描述。
从bit0-bit7分别为：
· testFailed 当前时间点故障状态，0表示没有检测到故障，1表示检测故障。
· testFailedThisOperationCycle 当前操作周期故障状态，0表示本周期（从本次被唤醒，到进入休眠，一般情况下也可以用车辆上电启动，到熄火休眠为周期）未检测到故障，1表示本周期内检测到故障。
· pendingDTC 当前及上个操作周期故障状态，0表示上个周期或本周期没有故障，1表示有。
· confirmedDTC 确认存储故障状态，0表示没有达到存储触发条件故障，1表示有。
· testNotCompletedSinceLastClear 上次清除开始故障检测未完成，0表示完成检查，1表示未完成。
· testFailedSinceLastClear 上次清除以来检测已完成，且检测到故障失败。0表示未运行检测或检测完成但未发现故障。1表示检测已运行且发现失败。
· testNotCompletedThisOperationCycle 本操作周期测试未完成，0表示本周期测试完成，1表示本周期测试未完成。
· warningIndicatorRequested 警告指示请求，0表示没有警告指示，1表示有警告指示。
02 $19服务
本文开篇时提到过$19服务是专门用来配合DTC进行读取相关操作的。相对于其他服务，$19服务的结构要复杂得多。
2.1 $19服务发送报文
服务发送报文第1部分为SID即$19；第2部分为subfunction子功能段，ISO14229规范定义中$19服务是比较复杂的，其subfunction项有31种不同定义，包含了ISO组织预留字段，因此$19服务的发送报文帧结构比之前我们分享的其他服务要复杂的多；第3和第4段参数部分对应于报文第2段subfunction的不同而各不一样，发送报文总体结构如下图：
图 3
对应于标准规范定义发送报文第2字段子功能分类，配合第3和第4段，$19服务的发送报文从总体上在规范中有13种不同格式。在具体项目中均是根据实际需要选取几种进行设计，因此测试过程中对于项目诊断规范的熟悉非常重要。
我们前文讲述的DTCStatusMask即在参数字段中，还包括DTCMaskRecord、DTCSeverityMask，以及快照相关的其他参数项，规范大约定义了9种不同参数来配套不同的子功能项实现不同功能。
我们举例使用$19 01 01，第2字段子功能01，该subfunction功能为根据DTC掩码上报检测的DTC故障数量。对应于第2段子功能为01，第3段标准定义要求DTC状态和DTC掩码对应状态全为“1”时进行匹配，即当前周期的故障检测状态。综合上面的描述我们可以知道$19 01 01读取了当前周期内DTC故障的数量个数。
跟子功能01类似要求的需要DTC状态掩码配合使用的子功能还有0x02、0x0F、0x11等，其服务发送报文架构如下图所示：
图 4
其他子功能还有参数配合使用的情况，我们需要根据诊断规范定义具体情况具体分析。
2.2 $19服务响应报文
$19服务的响应报文格式总体与第三篇文档的描述一致。正响应报文的服务号为$59，第2字节对应请求报文的子功能号。第3字段开始跟其他服务有所区别，本段响应报文的参数跟请求报文的逻辑一样，字段参数跟第2字段的子功能是对应的。响应帧的总体结构图如下所示：
图 5
举例上文$19服务的响应报文为：$59 01 01 01 00 01，响应报文第1、2字段对应请求报文SID19和子功能01；对于第2字段子功能为01，响应报文第3字段为参数DTCStatusAvailabilityMask；第4字段为参数DTCFormatIdentifier，这个参数即前文我们提到的DTCFID；第5、6字段为请求报文要求的上报DTC本周期故障数量为1个。对于每个参数的预置值定义，产品诊断规范中在每个子功能的参数定义中均有详细描述。
对应于请求报文的不同子服务格式有十几种，也会有每种分类的响应报文进行对应。
$19服务的负响应跟第三篇文档的描述一致，这里不再重复。
03 $14服务
$14服务跟$19服务是配套进行使用的，本服务的作用是清除诊断信息。在进行DTC相关测试时，会使用本服务执行清除工作，确保DTC的状态不影响测试结果。
3.1 $14 服务请求报文
$14服务请求报文相对比较简单，本服务的请求报文无子功能，只有唯一参数为groupOfDTC，对于参数的定义，可以参考ISO14229的附录相关内容，对于项目中的实际定义大家一定要仔细阅读项目诊断规范。发送报文帧结构如下图：
图 6
在实际测试过程中我们用的比较多的是全部清除，举例$14服务的全部清除请求报文为：$14 FF FF FF。
3.2 $14 服务响应报文
$14服务的正响应报文格式非常简单，就一个字节SID服务自己$54。响应报文帧的结构图如下所示：
图 7
举例$14的正响应报文格式为：$54。
负响应的报文格式可以参考第三篇的相关章节，负响应NRC代码表一般在项目中是通用的。
04 总结
DTC是配合$19和$14服务来使用的，DTC故障代码表的所有故障代码我们要进行遍历测试，所以环境的搭建会花费大量的时间，需要准备其他的测试配合零部件。每个故障测试前都需要使用$14服务将已存储的DTC清除并确认已清除成功，才能制造DTC对应的故障，并通过$19服务来读取来确认制造的故障被设备识别，并遵循记录规则进行了对应的存储。
05 测试要点
在执行DTC的测试前必须和诊断设计系统工程师和DRE确认，DTC表中的所有故障如何在测试环境制造出来，且可以被设备检测出来。设备检测上报DTC有一定的过滤条件，即使是同一个故障，哪怕我们在试验环境下制造并观察到故障已出现，在触发条件没有达到时，设备也检测不到，读取不到对应的DTC。
在制造一些短路故障前一定要跟DRE或者硬件工程师确认，测试操作不会烧毁相关电路或电容。