DTC诊断测试方法

这篇文章用TSMaster工具从实操角度介绍IOS 14299中的诊断DTC测试方法，主要内容为如何搭建DTC测试环境以及测试方法

DTC的命名规则

DTC是Diagnostic Trouble Code的缩写，中文名称为诊断故障码，它的作用是将车辆上发生的故障通过固定的命名规则记录、存储并上传，方便工作人员通过诊断仪或者UDS诊断服务读取到当前故障的一种方法。

DTC由高&中字节和低字节三部分组成，DTC五位标准故障码同高、中字节间的映射关系如下

SAE J2102规定的五位标准故障码格式如下

以U120587为例，根据上述规则要求，其高&中、低字节映射方法举例：

其五位标准故障码为U1205

测试环境搭建

前期输入

诊断调查表：这个表内定义了系统中所有支持的USD诊断服务、请求ID/应答ID、DTC list、DTC产生/消除条件等内容，是测试用例设计以及测试工程配置的基础；

dell文件：包括 Seed&Key 安全算法以及完整的UDS协议

测试环境搭建-以TSMaster为例

硬件搭建

准备好被测件、线束、直流电源、同星硬件、电脑，通过线束连接被测件并将CAN线连接到同星上

TSMaster工程搭建方法

打开TSMaster后选择总线分析-CAN总线测量

通道配置：在硬件-通道选择中配置实际的CAN通道数量并选择对应的硬件通道

DBC载入：在分析-数据库中在对应的CAN通道下加载对应的DBC

添加诊断模块：在应用-诊断模块下添加基础诊断，并在诊断模块-诊断传输层中配置好请求ID、应答ID、功能ID等内容，这些内容在诊断调查表中有定义；诊断服务层中加载dll文件。

配置19、14服务：在刚才添加的基础诊断-基本诊断配置-存储数据传输-19读取DTC信息下右击（14也是在这个路径），点击添加新的服务，将请求值设为01

在IOS 14299中对于19 02服务的DTC状态位定义如下，其中01代表bit 0=1的掩码，即筛选当前测试失败的DTC

14服务的请求值设置为0xFFFFFF，根据ISO 14299中14服务的定义，14 FF FF FF代表清除高、中、低字节的诊断信息请求

E2E算法配置与仿真报文发送：

首先在仿真-CAN总线仿真中添加CAN总线剩余仿真模块，该模块会根据之前配置的CAN通道和DBC自动导入，根据DTC测试所需要的节点、信号勾选激活，并发送正确的值。这里需要注意在模块-设置内将初始值设置为最后值。

在CAN总线剩余仿真模块下的报文内选中对应的CRC信号，右击设置为Checksum校验信号，这时会跳出CRC校验算法的选择框，先不要勾选。回到主界面，点击设计-C小程序，下方会出现C代码编辑器[CRC]，打开后在自定义函数中新建mycrc函数，其中函数参数可直接复制程序库中的适配项目算法函数参数，如图中的mycrc函数是直接复制CRC8的，在mycrc函数中编辑项目的CRC算法，编辑完成后点击编辑器上方的“编译源代码”

这时回到CAN剩余总线仿真里点击设置-算法配置-编辑CRC算法参数，选择我们编辑的mycrc算法参数即可

关于编辑CRC算法参数对话框内的保护起始字节是指在数据帧中，从哪个字节开始进行 CRC 校验计算，如某报文的checksum在第0字节，因此计算checksum时，将保护字节设为1，意味着第0字节不参与CRC校验的计算。保护字节数表示从保护字节起始位置开始，连续多少个字节将参与 CRC 校验计算，例如保护字节数=7，则后续的7个字节都参与校验计算。

RC信号设置也是在CAN剩余总线仿真中响应的RC信号右击，设置为rolling counter信号即可

DTC的制造与消除

在完成上述步骤后运行我们的工程，被测件所有需要的信号和E2E校验均已正常仿真，这时根据诊断调查表中的DTC list中具体DTC制造与消除的条件进行测试

如U120587这个DTC含义为EPS节点丢失，其制造条件为与0x123报文失去通讯，恢复条件为正常接收到0x123报文，这时我们在RBS模块取消勾选0x123报文的激活按钮，然后发送19 02 01服务，根据IOS 14229定义，回复的59 02 09 D2 05 87 09 ，尾数09表示是当前激活的已确认硬故障；当恢复0x123报文通讯后发送19 02 01服务，回复59 02 09 D2 05 87 08 ，尾数08表示该故障是已自愈的历史确认故障，最后发送14服务，清除DTC，进行下一DTC测试。