一种排放相关网络故障码的测试方法与流程

1.本发明涉及汽车电子技术领域，尤其涉及一种排放相关网络故障码的测试方法。


背景技术：

2.车上电控单元(简称ecu)一般都具备故障自诊断和保护功能，当系统产生故障时，它还能在ram中自动记录故障代码并采用保护措施从上述的固有程序中读取替代程序来维持发动机的运转，同时这些故障信息会显示在仪表盘上并保持不灭，可以使车主及时发现问题并将车能开到修理店。在一些中高级车上，不但在发动机上应用ecu，在其它许多地方都可发现ecu的踪影，例如，防抱死制动系统等都配置有各自的ecu，多个ecu之间的信息传递采用多路复用通信网络技术，将整车的ecu形成一个网络系统。
3.随着汽车功能日益增多和配置多样化，ecu的数量也越来越多，各ecu之间通过总线的交互也越来越多，当某ecu需要的总线信号丢失或无效时，其功能会受到影响，此时ecu会按照一定规则将该问题通过诊断故障码(简称dtc)的形式记录并上报，主机厂一般通过台架搭建测试系统，在单节点条件下，模拟相关总线故障，对ecu所记录的网络dtc进行逻辑合理性测试。
4.然而，对于发动机、变速箱等排放相关的ecu而言，某些总线信号的丢失或无效，会导致车辆进入跛行等极限工况，从而影响排放。根据相关法规要求，对于排放相关的dtc根据不同的故障等级，需要两个驾驶循环或者两个暖机循环才允许确认，而驾驶循环和暖机循环需要满足转速、车速、水温等条件，单节点条件下无法实现。
5.目前主机厂对于这部分dtc要么缺少相关测试用例，要么在实车条件下通过拔插相关ecu的方式粗略测试，显然，这些草率且尚不完善的测试方式无法达到准确验证dtc逻辑的目的，也给售后分析故障增加了难度。
6.本发明技术方案设计人员结合以上分析以及现有的针对汽车网络故障码测试的常见技术手段进行总结可知，这些方法在实施应用之后各自均存在着相应的弊端，主要暴露于以下几个方面：
7.其一，在测试用例缺失或测试不准确的情况下，实际上，已经无法达到验证dtc逻辑的目的；
8.其二，实车测试中，某些ecu已被其他零件覆盖或操作空间十分有限，导致接插件较难拔插；
9.其三，进行测试环节所采用的一些大型dtc测试机柜受其体积、线束、场地等因素影响，难以应用在实车测试中；
10.其四，售后问题缺少试验数据支持，较难复现和排查。
11.综上分析，本发明正是在现有公知技术的基础上，通过实际应用进行经验总结，提出一种排放相关网络故障码的测试方法，其在给测试车辆上on档后，先使用诊断服务停止相关节点报文的发送，以此来代替常规方法中拔掉节点接插件的操作，再模拟发送相关报文，使得总线报文与实际情况无差异，继而通过启动车辆、踩油门、行驶等操作来人为满足
驾驶循环的要求，最后按照故障产生条件停止发送一定周期的相关报文，使得总线上出现相关故障，熄火，重复操作，即可模拟多次操作循环发生故障的情况，来判断ecu是否按照既定策略正常报出dtc。因而，所提出的技术方案能够缓解、部分解决或完全解决现有技术存在的问题。


技术实现要素：

12.为克服上述问题或者至少部分地解决或完全解决上述问题，本发明提供一种排放相关网络故障码的测试方法，该方法通过诊断数据库及网络dbc数据库编制，停发车上报文并用测试软件模拟发送被停发的报文，编辑测试用例和测试脚本等主要步骤，最终达到判断ecu是否按照既定策略正常报出dtc的目的。
13.为实现上述目的，本发明采用以下技术方案：
14.一种排放相关网络故障码的测试方法，包括以下步骤：
15.i、使用便携式诊断设备在实车环境下进行半自动测试，即测试车辆与便携式测试设备之间以obd方式连接，测试设备再接至操作终端；
16.ii、编制诊断数据库和网络dbc数据库，以便后续操作使用相关诊断服务及模拟报文发送；
17.iii、在给测试车辆上on档后，先使用诊断服务停止相关节点报文的发送，以此来代替常规方法中拔掉节点接插件的操作，其中，诊断服务包括诊断数据库及网络dbc数据库编制；
18.iv、停发车上报文之后，用测试软件模拟发送被停发的报文，使得总线报文与实际情况无差异；
19.v、通过启动车辆操作、踩油门操作以及行驶操作来人为满足驾驶循环的要求；
20.vi、最后按照故障产生条件停止发送一定周期的相关报文，使得总线上出现相关故障，熄火；
21.vii、如此一个驾驶循环已完成，重复之前操作，即可模拟多次操作循环发生故障的情况，从而判断ecu是否按照既定策略正常报出dtc。
22.进一步地，对于诊断数据库及网络dbc数据库编制的方法为：
23.测试某一dtc之前，需辨别清楚该dtc指向的报文来自于总线上哪个ecu的哪条报文；
24.在测试软件中添加对应的ecu及其报文，设置好对应ecu需要使用到的诊断服务及报文中的各信号内容，以便后续可更改报文信号中的相应值来达到模拟不同故障的目的；
25.待全部诊断服务及报文均添加并设置完成后，可尝试模拟发送，若总线上可读取到相关报文，则数据库编辑成功。
26.针对以上技术方案，技术人员还可在具体实施时根据不同设计需求利用一些技术手段做出不同的改进，形成在同一构思基础上的技术方案，具体技术手段包括如下：
27.诊断服务用于对某ecu或者整车所有报文的停发工作；
28.在报文停发后，需要继续使用编辑好的dbc数据库，模拟发送被停发的报文，即可通过测试软件精确控制报文发送的内容及周期；
29.在模拟报文正常发送之后，首先对被测ecu进行dtc清除操作，并通过读取dtc操作
确保在测试之前没有待测试的dtc出现，至此，第一个操作循环正式开始；
30.进一步地，在模拟发送相关报文一定时间后，根据dtc列表中描述的待测试dtc产生条件，精确停发一定周期相关报文后再恢复正常发送，通过读取dtc操作判断是否已经产生了待确认的dtc，如果已产生则可以结束当前操作循环，如果未产生则对停发报文的周期进行微调，直至产生待确认的dtc为止。
31.此外，测试用例中各种不合格的情况包括：还未开始测试就已经出现了待测dtc、第一个操作循环无法产生待确认dtc、第一个操作循环还未达到故障码产生条件就已经出现了待确认dtc、第一个操作循环超过了故障码产生条件才出现待确认dtc、第一个操作循环就已经产生了已确认dtc、第二个操作循环无法产生已确认dtc、第二个操作循环还未达到故障码产生条件就已经产生了已确认dtc、以及第二个操作循环超过了故障码产生条件才出现已确认dtc。
32.对于以上所实施的技术方案，技术人员还可进行适应性的设计，包括：
33.该测试方法通过便携式设备软件脚本编辑，模拟相关ecu实车报文，复现实车环境；
34.该方法按编程逻辑自动停发一定周期报文，精确制造网络故障条件；
35.该方法用于为故障码策略提供评估。
36.本发明采用在实车环境下半自动测试，经过一系列步骤，通过可模拟多次操作循环发生故障的情况，来判断ecu是否按照既定策略正常报出dtc，从而避免人为拔插实车ecu接插件的困难，轻松实现报文发送及停发，还可根据实际需要模拟发送实车数据，而不拘泥于实车本身状态；同时，能够自动停发一定周期报文以达到精确模拟故障状态的效果；补全了排放相关网络故障码测试的不足，为故障码策略提供评价；另外，还可为售后故障案例提供排查方向和数据支持。
附图说明
37.下面根据附图对本发明作进一步详细说明。
38.图1是本发明所实施的排放相关网络故障码的测试方法，其排放相关网络dtc测试操作示意图；
39.图2是本发明所实施的排放相关网络故障码的测试方法，其流程示意图。
具体实施方式
40.本发明拟实施的排放相关网络故障码的测试方法，所实施的技术手段要达到的目的在于，解决以往在对ecu所记录的网络dtc进行逻辑合理性测试的过程中，经常因测试用例缺失或测试不准确、接插件较难拔插、测试设备空间所限等因素而无法达到准确验证dtc逻辑的目的。
41.本发明所实施之技术方案，是基于实车环境下的半自动测试方法，具体步骤包括诊断数据库及网络dbc数据库编制、停发车上报文并用测试软件模拟发送被停发的报文、编辑测试用例和测试脚本等。对于数据库具体设计方式、算法、测试装置、诊断设备等均可结合技术人员的实际实施需求来选配，本发明不便于详细限制这些算法的类别、测试装置采用的具体型号以及诊断设备的安装方式等，凡是能够适合于本发明技术方案的装置、设备
等均可尝试采用，技术人员也均可依据本发明所实施的技术方案来轻易地实施。因而，包括数据库设计方式、算法、测试装置、诊断设备等选择，这些均属于本领域常规技术手段，根据市面产品或以往的技术都可以选取合适的技术手段，对于不在本发明技术方案范围之内的这些常规技术手段，本发明具体实施方式无必要将每一个细节都细化出来，若要全部列举出来是不现实的。显然，本发明所实施的技术方案实际上是一种能够让本领域技术人员结合常规技术手段参照及实施的排放相关网络故障码测试方法，而并非是对电路模块或装置构造的设计，技术人员根据不同的应用条件以及使用需求，按照本发明技术方案进行实际应用与测试，能够实际获得其带来的一系列优势，这些优势将会在以下的解析中逐步体现。
42.如图1
‑
2所示，技术人员首先在进行可行性分析之后，设计了方案步骤执行的具体路线，现分析如下：
43.①
使用便携式诊断设备(vehicle spy)在实车环境下进行半自动测试，具体连接方式参照如图1所示，即测试车辆与便携式测试设备之间以obd方式连接，测试设备再接至操作终端；
44.②
在给测试车辆上on档后，先使用诊断服务停止相关节点报文的发送，以此来代替常规方法中拔掉节点接插件的操作；
45.③
再模拟发送相关报文，使得总线报文与实际情况无差异；
46.④
相应地，通过启动车辆、踩油门、行驶等操作来人为满足驾驶循环的要求；
47.⑤
最后按照故障产生条件停止发送一定周期的相关报文，使得总线上出现相关故障，熄火；
48.⑥
如此一个驾驶循环已完成，重复之前操作，即可模拟多次操作循环发生故障的情况，来判断ecu是否按照既定策略正常报出dtc。
49.如图1
‑
2所示，本发明所实施的排放相关网络故障码的测试方法，为了进一步对以上所提出的技术路线施以实践的论证，针对测试方法具体分析，以下列举优选实施例，步骤如下：
50.步骤之一，诊断数据库及网络dbc数据库编制：
51.测试某一dtc之前，需辨别清楚该dtc指向的报文来自于总线上哪个ecu的哪条报文；
52.在测试软件中添加对应的ecu及其报文，设置好对应ecu需要使用到的诊断服务及报文中的各信号内容，以便后续可更改报文信号中的相应值来达到模拟不同故障的目的；
53.待全部诊断服务及报文均添加并设置完成后，可尝试模拟发送，若总线上可读取到相关报文，则数据库编辑成功。
54.步骤之二，停发车上报文并用测试软件模拟发送被停发的报文：
55.由于车辆总线上由ecu发出的报文一般不会有故障，因此需要停掉相关ecu发送的报文，通过拔ecu保险或者接插件的方法可以让其报文停发，但由于总线报文周期都是毫秒级的，无法精确控制停发报文的时间，况且某些ecu藏在车辆地毯、扶手箱等下方，拔其接插件需要对车辆进行破坏性操作，人力、财力均会有较大损耗，因此，采用前期编辑好的诊断数据库，通过诊断服务来实现对某ecu或者整车所有报文的停发工作，省时省力；
56.在报文停发后，需要继续使用编辑完成的dbc数据库，模拟发送被停发的报文，这样便可通过测试软件精确控制报文发送的内容及周期。
57.步骤之三，编辑测试用例和测试脚本：
58.从整车上电后停发相关ecu报文，到设备模拟发送被停掉的报文这段时间，被测试ecu有可能已经记录了某些dtc，因此，为了排除测试未开始阶段的其他因素干扰，在模拟报文正常发送后，首先对被测ecu进行dtc清除操作，并通过读取dtc操作确保在测试之前没有待测试的dtc出现；
59.至此，第一个操作循环正式开始，在模拟发送相关报文一定时间后，根据dtc列表中描述的待测试dtc产生条件，精确停发一定周期相关报文后再恢复正常发送，通过读取dtc操作判断是否已经产生了待确认(pending)的dtc，如果已产生则可以结束当前操作循环，如果未产生则对停发报文的周期进行微调，直至产生待确认的dtc为止；
60.在第二个操作循环执行与第一个操作循环同样的操作，直至产生已确认(confirm)的dtc为止，至此，测试完成，根据具体情况判断测试结果是否合格。
61.步骤之四，施行测试结果准确性保障机制：
62.由于测试用例中最终结果的判断都是要以读取到相应dtc为条件，如果一直读取不到dtc或者尚未满足条件就已经读取到了dtc，均属于测试不合格，测试用例中将各种不合格的情况均已考虑在内，以确保测试结果的绝对准确，具体包括以下几种情况：
63.①
还未开始测试就已经出现了待测dtc；
64.②
第一个操作循环无法产生待确认dtc；
65.③
第一个操作循环还未达到故障码产生条件就已经出现了待确认dtc；
66.④
第一个操作循环超过了故障码产生条件才出现待确认dtc；
67.⑤
第一个操作循环就已经产生了已确认dtc；
68.⑥
第二个操作循环无法产生已确认dtc；
69.⑦
第二个操作循环还未达到故障码产生条件就已经产生了已确认dtc；
70.⑧
第二个操作循环超过了故障码产生条件才出现已确认dtc。
71.可见，施以上述步骤主要的优势在于，能够通过诊断服务停止实车相关ecu报文发送，代替人为拔掉ecu接插件；可通过便携式设备软件脚本编辑来模拟相关ecu实车报文，复现实车环境；按编程逻辑自动停发一定周期报文，精确制造网络故障条件。
72.除了以上本发明所实施的技术方案之外，技术人员可根据实施不同的优化方法来设计不同的拓展方案，对于其它的各种拓展根据技术人员不同需求而另自行设计，此处不再赘述。
73.在本说明书的描述中，若出现术语
″
实施例一
″
、
″
本实施例
″
、
″
具体实施
″
等描述意指结合该实施例或示例描述的具体特征、结构、材料或特点包含于本发明或发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例；而且，所描述的具体特征、结构、材料或特点可以在任何一个或多个实施例或示例中以恰当的方式结合。
74.在本说明书的描述中，术语
″
连接
″
、
″
安装
″
、
″
固定
″
、
″
设置
″
、
″
具有
″
等均做广义理解，例如，
″
连接
″
可以是固定连接或在不影响部件关系与技术效果的基础上通过中间组件间接进行，也可以是一体连接或部分连接，如同此例的情形对于本领域普通技术人员而言，可根据具体情况理解上述术语在本发明中的具体含义。
75.上述对实施例的描述是为了便于该技术领域的普通技术人员能够理解和应用，熟
悉本领域技术的人员显然可轻易对这些实例做出各种修改，并把在此说明的一般原理应用到其它实施例中而不必经过创造性的劳动。因此，本案不限于以上实施例，对于以下几种情形的修改，都应该在本案的保护范围内：
①
以本发明技术方案为基础并结合现有公知常识所实施的新的技术方案，该新的技术方案所产生的技术效果并没有超出本发明技术效果之外，例如，采用诊断数据库及网络dbc数据库编制，停发车上报文并用测试软件模拟发送被停发的报文，编辑测试用例和测试脚本等主要步骤形成的技术方案，并且没有产生超出本发明之外的技术效果；
②
采用公知技术对本发明技术方案的部分特征的等效替换，所产生的技术效果与本发明技术效果相同，例如，本发明技术方案实施是选择所需测试装置和诊断设备等；
③
以本发明技术方案为基础进行拓展，拓展后的技术方案的实质内容没有超出本发明技术方案之外。