汽车电子诊断服务的自动验证
时间:12-12
来源:互联网
点击:
图四 DiVa配置窗口
5 测试执行与报告评估
测试例程生成后,用户将生成的测试环境加入到“CANoe”中便可进行测试。测试的时间依据诊断规范的复杂程度以及用户选择的测试范围而定,可能会从几分钟到几个小时不等,如表一所示。在GM,“CANoe”的测试环境作为一个测试自动化的共同平台,被重复用到现有的ECU测试程序中。例如,EOL编程测试也在“CANoe”上通过CAPL实现。为了让测试工程师分析起来更加容易,测试报告的结构遵循GM的诊断规范,如图五所示。
表一 Opel Insignia中,生成的ECU测试例程的数量以及测试的时间
图五 DiVa生成的测试报告
自动测试扩展了测试覆盖度同时缩短了测试执行所需时间。下面将描述GM诊断规范所定义的测试范围以及“DiVa”测试程序的覆盖范围。“DiVa”生成的测试例程的质量与数量大部分由诊断规范(CDD文件)决定,所有产生的测试均源于此。
GM诊断规范定义了大约350个测试序列,包括正确工况与不正确工况,“DiVa”全自动生成的测试程序能够覆盖大约%80的测试要求,另外用户需要添加45(%15)个在GM诊断规范中定义的与应用相关的测试到DiVa中。在这种情况下,“DiVa”将暂停测试并告知用户将ECU设置到一个所需的状态。剩下的%5 的测试程序不能由DiVa完成,必须通过手工或其它途径完成。例如涉及到有风险的ECU置位测试(如产生并检测EEPROM错误)或导致ECU大量变更的测试(如没有标定数据的ECU)。测试的深度可以通过添加一些GM规范上没有定义的测试来提升。
GME将验证Opel Corsa与Insignia进行了对比,以自动测试为主导的“DiVa”大大缩短了测试时间,如图六。表一显示了Opel Insignia上,“DiVa”产生的测试例程的数量以及执行的时间。通常由于时间的限制,手工测试仅进行随机测试,测试结果很大程度上依赖于测试工程师的经验及测试的时间。在GME,“DiVa”能够在不同的开发阶段,完成针对不同诊断规范的测试并能够增加测试的范围。
图六 手工与自动测试效率的对比
当引入一个工具,首先要考虑的是经济效益。Opel Corsa在市场上非常成功,没有诊断相关电器问题的负面报告。这是为什么选择手工进行验证的Opel Corsa项目作为参考的原因。作为对比,在新的Opel Insignia上,“DiVa”作为验证服务的主要工具,这是第一次被用作自动化的验证测试。为了对比,研究了在有代表性的ECU上在验证阶段的进行测试和评估所花的时间。这些值是在SWR5阶段获得的,在这一阶段,绝大多数服务均已被实现了,发现了很多失败的测试例程。图六显示了单位时间内,在Opel Corsa进行手工测试与在Opel Insignia进行自动测试的验证效率的对比。使用“DiVa”,执行和评估时间降低了3~5倍。特别是在诊断服务非常多的情况下,节约的时间非常的大。如果考虑后续的开发阶段,如SWR6,SWR7,时间消耗会进一步降低。这样可以追溯到在更成熟的实现过程中,最小化失效测试的例程的数量。这样的趋势存在于产品开发的每一个新的阶段。产品ECU要求没有任何明显的缺陷,因此,评估时间等于测试执行时间。在Opel Insignia开发的这个阶段,根据ECU的复杂程度,效率会提升20到40个百分点。
新的解决方案的成本也很低,因为仅需要一个DiVa的license,只要熟悉“CANoe”的工程师就能够进行“DiVa”的测试,不需要专门的培训,同样也不需要专门的硬件。
8 自动测试例程的生成和测试执行的限制
尽管自动工具在测试范围及时间效率上要比手工测试好,但也存在一些约束:
·规范的质量:因为测试规范是生成测试例程的基础,所以,规范的完整性与准确性至关重要。另外规范需要准备GM的诊断规范
·可重复性:考虑到汽车CAN通讯系统不确定性的因素,有些测试过程中的错误很难浮现
·派生错误:在有错误的例程中,自动测试工具不能区分错误是原始错误还是派生错误,要由工程师完成
·用户交互:在用户相关的测试中,有必要输入ECU的状态,这些过程不能完全自动完成
9 小结
没有自动测试工具,很难在现代汽车诊断验证的过程中达到所期望的测试覆盖度。“CANoe.DiVa”适应GM的需求,支持所以已建立的测试流程,而且能够很好集成到GME现有的工具链中。它作为一个自动测试工具,已经被用到了Opel Insignia的诊断验证中。
使用“DiVa”,GME不仅缩短了测试周期,还增加了测试的覆盖度,因为其具备频繁进行回归测试的能力。另外,测试范围与覆盖度通过添加一些GM诊断规范没有定义的内容而得到了扩展。与前面,全手工测试的成功项目对比,提升了技术效益与经济效益。根据不同的开发阶段以及实现的质量,效率提升了4到20个百分点。同时,从长期的质量考虑,能够达到用户的较高的期望值。
参考文献
[1] T homas, D.; Ayers, K.; Pecht, M.: The “trouble not identified” phenomenon in automotive electronics. In: Microelectronics reliability, Vol. 42, S. 641-651,2002
[2] L IN Consortium: LIN Specification Package Revision 2.1, OV . 2006
[3] R obert Bosch GmbH: CAN-S pezifikation 2.0, 1991
[4] International Organization for Standardization:Keyword Protocol 2000, ISO 14230, 1999
[5] Krauss, S.: Testing with “CANoe”, Application Note AN- IND-1-002. Vector Informatik, 2005
[6] General Motors. GGSE EC U Diagnostic Infrastructure Requirements, Version 1.07, 2007(end)
汽车电子诊断服务 相关文章:
- Windows CE 进程、线程和内存管理(11-09)
- RedHatLinux新手入门教程(5)(11-12)
- uClinux介绍(11-09)
- openwebmailV1.60安装教学(11-12)
- Linux嵌入式系统开发平台选型探讨(11-09)
- Windows CE 进程、线程和内存管理(二)(11-09)