基于Vehicle Spy 的排放相关网络故障码测试方法实现

田 丰，林家强，周军成，韦佳萍，周国林，许运灼

（1.上汽通用五菱汽车股份有限公司，广西 柳州 545007；2.柳州孔辉汽车科技有限公司，广西 柳州 545026；3.湖南湖大艾盛汽车技术开发有限公司，湖南 长沙 410221；4.柳州沪信汽车科技有限公司，广西 柳州 545616）

1 引言

随着汽车功能日益丰富，配置也多样化，车载电控单元ECU的数量在不断增多，各ECU之间通过总线的信息交互也越来越多。当某ECU需要的总线信号丢失或无效时，其功能就会受到影响，此时ECU会按照一定规则将该故障通过诊断故障代码DTC的形式记录并上报。对于DTC的产生及恢复逻辑测试，一直以来都是各大主机厂诊断测试的重要内容。裴伟军、毛鸿霖等人提出的基于VT System和CANoe系列软件的故障码测试是一种通过搭建台架测试系统，在实验室单节点条件下，模拟相关总线信号故障的测试方法[1-2]，目前几乎所有开展此项测试的主机厂也都是采用这种方法。

然而，对于发动机控制模块ECM、变速器控制模块TCM等排放相关的ECU而言，某些总线信号的丢失或无效，会导致车辆进入跛行等极限工况，从而影响排放。根据相关法规要求，排放相关的DTC需要2个或2个以上的驾驶循环才允许确认，而DTC的消除更是需要经过多个无故障暖机循环才能满足要求。驾驶循环和暖机循环需要满足发动机运转、车速、水温等条件，然而要想在实验室环境下实现这些条件只能斥巨资搭建复杂的硬件在环（HIL）测试系统[3]，这对主机厂而言是个不小的挑战。因此，目前大多主机厂对于这部分DTC的逻辑确认直接采用ECU供应商的测试结果或者在实车上粗略测试。显然，这并不能达到准确验证DTC逻辑的目的，也会给售后分析故障增加难度。为此，本文提出一种使用低成本标准设备在实车上精确测试排放相关故障码的方法，利用简单的测试环境补充了此项测试的空缺。

2 基于Vehicle Spy的半自动化测试

美国因特佩斯公司的Vehicle Spy是一款汽车总线仿真测试软件，可以实现节点仿真、数据解码、自动测试、数据采集等多种功能[4]，满足实验室和实车环境中对车辆ECU的基础测试需求。本文所介绍的就是利用Vehicle Spy软件在实车环境下进行的排放相关故障码测试方案。

将Vehicle Spy硬件一端通过在线诊断（OBD）连接线接至整车OBD口，另一端通过USB接口接至装有Vehicle Spy软件的电脑上，测试环境即搭建完成，其整体连接示意如图1所示。本测试方法以实车环境为基础，免去了复杂的测试硬件方案设计，仅需通过标准工具中的相关软件脚本编辑，配合人为的车辆操作，即可完成排放相关网络DTC测试，大大降低测试成本的同时，也能精确地验证DTC的设计逻辑。

图1 排放相关网络DTC测试环境整体连接示意图

3 软件方案设计

3.1 网络数据库（DBC）建立

由于测试内容涉及到网络报文的丢失、无效、错误等故障现象，在进行测试之前需要编制好DBC数据库。这需要识别被测DTC指向的是总线上的哪些ECU所发出的哪些报文。根据具体车型的通信矩阵，在Vehicle Spy软件中的Message Editor界面进行发送信号编制，网络数据库编制如图2所示。编制完成后即可在Tx Panel面板对所编辑的报文进行周期性模拟发送，如图3所示。

图2 网络数据库编制

图3 网络报文发送面板

3.2 诊断数据库建立

由于在测试过程中需要用到停止通信、读故障码、清故障码等UDS诊断服务，因此诊断数据库的编辑也至关重要。停止通信服务用于整车特定ECU报文的停发，结合之前编辑的DBC数据库，即可实现在不对整车电子元器件及线束接插件做任何改动的情况下，精确控制被测DTC所对应报文的内容和周期，轻松制造期望的网络故障，方便快捷。读故障码、清故障码服务用于测试过程中判断故障是否产生及手动清除。

3.3 测试脚本生成

Function Block是Vehicle Spy软件中的一个脚本编辑工具，提供了一种列表式的命令执行步骤编辑方式，用于创建可直接执行的测试脚本序列。用户无需了解具体编程语言，也可轻松操作完成测试用例编辑。结合前面两步中所编辑的应用报文及诊断报文内容，在Function Block中给每一个步骤设置具体的指令，如发送应用报文、设置信号值、等待特定条件、发送诊断报文等，搭配工具提供的循环设置，即可实现自动执行制造故障、读取故障码、判断测试结果等操作。Function Block测试脚本编辑界面如图4所示。

图4 Function Block测试脚本编辑界面

4 测试流程设计

4.1 测试流程实施

对于排放相关的ECU，在整车上电后即开始监控相关的网络报文故障。第1个操作循环，从使用诊断服务停发相关ECU报文，到测试设备模拟发送被停掉的报文这段时间，ECU可能已经记录了某些DTC。为了排除第1个操作循环中测试尚未开始阶段的其他因素干扰，需要先对ECU进行清除DTC操作。在模拟发送相关报文一定时间后，根据DTC列表中描述的待测DTC产生条件，精确停发一定时间（如10个报文周期）相关报文后读取DTC，判断是否已经产生了待确认（Pending）DTC，若已产生则可以结束当前操作循环，若未产生则对停发报文的周期进行微调，直至产生待确认的DTC为止。整个操作循环过程中，需要配合车辆，至少启动一次发动机（若为混动车型，则需要至少达到一次高压状态），以满足驾驶循环的条件，否则ECU会一直处于第1个操作循环过程中，无法结束，从而影响测试结果。

第2个操作循环，执行与第1个操作循环同样的操作，直至产生已确认（Confirm）DTC，测试完成。根据具体DTC策略，此方法还能应用于更多驾驶循环甚至暖机循环才能确认故障的情况测试，具体测试及判断流程如图5所示。

图5 排放相关DTC测试流程

4.2 测试结果确认

由于测试用例中最终结果的判断都是要以读取到相应DTC为条件，如果一直读取不到DTC或者尚未满足条件就已经读取到了DTC，均属于测试不合格。测试用例中将各种不合格的情况均已考虑在内，以保证测试结果的准确性。具体包括以下几种情况。

1）还未开始测试就已经出现了待测DTC。

2）第1个操作循环无法产生待确认DTC。

3）第1个操作循环还未达到故障产生条件就已经出现了待确认DTC。

4）第1个操作循环超过了故障产生条件才出现待确认DTC。

5）第1个操作循环就已经产生了已确认DTC。

6）第2个操作循环无法产生已确认DTC。

7）第2个操作循环还未达到故障产生条件就已经产生了已确认DTC。

8）第2个操作循环超过了故障产生条件才出现已确认DTC。

本文以ECM排放相关网络DTC C15100为例，在实车上验证了此方法的可行性和准确性。在第1个驾驶循环中按设计条件制造故障后，读出了状态位为0x27的Pending故障。配合发动机启动、熄火、重新上电等操作，结束第1个驾驶循环，并进入第2个驾驶循环。继续按DTC设计条件制造故障，读出了状态位为0x2F的Confirm故障。测试结果示例如图6所示。

图6 测试结果示例

5 结论

通过基于Vehicle Spy的半自动化测试方法，实现了对排放系统ECU的排放相关网络故障码逻辑测试，避免了复杂的硬件系统设计，同时节约了测试成本。利用Function Block功能，保证了测试过程的严谨性和测试结果的准确性，对DTC设计逻辑给出了评价，也为售后排查相关问题提供了试验数据支持。