汽车电子诊断服务的自动验证

GME开发部在诊断验证过程中第一次引进了全自动的测试例程生成工具。该文档由GME与Vector共同完成，描述在新Opel Insignia的诊断实现过程中的自动测试。与在Opel Corsa进行手工验证相比，将Vector工具集成到现有的工具环境中，能够降低成本，节约时间，并改善流程。

1 概述

全球汽车市场竞争的日益激烈，导致了汽车电器网络越来越复杂，对开发周期的要求也越来越短。由于电器系统替代传统系统的核心目的是降低成本，提升系统的安全性与可靠性，同时方便管理。这里，暂不考虑这些好处，但是随着系统电器部件的增加，必然会导致与电器相关故障的增加。由于用户购买新车的重要评价指标是可靠性，因此有必要引进一种新的方法，能够适应这种复杂，快速的开发流程，并保证每一个已经装车的ECU正常运行。尤其是在ECU的诊断功能，必须保证诊断服务的正确性。其传输的信息能够帮助服务站的维修师快速准确的定位故障并修正这些故障。这些信息还要能够让维修师查出问题的根源，知道那些部件需要更换。如果这些内容不能保证的话，可能会导致不正确的更换一些正常工作的部件，这必将导致维护成本的增加以及客户满意度的降低。

Opel Insignia的电器系统结构包括几个CAN和LIN网络。所有的总线系统都通过中央诊断口（DLC）访问（图一）。通讯由GM协议定义，该诊断协议以KWP2000和CAN 2.0A为基础，包括所有访问ECU诊断系统的服务，用来获取诊断信息。这些诊断服务由诊断仪发出，建立诊断通讯。一旦请求被发出，被查询的ECU会根据情况发出肯定或否定响应。

·肯定响应包括诊断仪请求的所有诊断信息，如果诊断信息过长，响应包含多帧报文
·否定响应包括一个明确定义的否定

图一 Opel Insignia的电器结构与诊断通讯接口

根据这些响应，维修师能够判断导致问题的原因，并采取相应的措施予以解决。

因此，在服务站对于故障的正确维修得益于诊断系统大量准确的输出信息。在进行快速、专业的服务或维修来让客户满意的过程中，执行合适的诊断服务致关重要。诊断在下线测试的过程中也扮演重要的角色：其用来对ECU编程，保证产品的质量。这便是为什么要进行复杂的诊断验证的原因。

2 在GME的验证流程与工具环境

在Opel Insignia的开发过程中，GME引进了从Vector第一次“CANoe.DiVa”（诊断集成验证辅助）工具。“DiVa”自动生成诊断测试用例并执行诊断测试。图二显示了Opel Insignia和Opel Corsa的工具环境。在两个案子中，CANoe均为测试工具，但在Corsa开发过程中，大量测试均手动完成，而Insignia开发过程中，自动测试覆盖了绝大多数测试内容。

图二 Opel Insignia和Opel Corsa诊断验证工具环境对比

图三显示了GME测试工程师典型的诊断验证流程。ECU的软件开发被分为了几个阶段，在ECU开发的初期，重点在于实现ECU的功能而不是诊断服务，后者是在后续的软件版本中进行详述，开发的。就如图三所示，在阶段1软件版本（SWR1）中，仅实现了很少一部分的诊断服务，GME使用了诊断软件模块（CANdesc），使得在开发的初期就能够实现一部分的诊断内容，这样，就能够较早的集成到ECU中（见图三）。

图三 GME在ECU开发不同阶段诊断的实现情况

诊断功能测试的数量随着每一个开放循环不断增加，一旦所有的诊断服务被实现，就要进行回归测试（SWR7）。如果在此阶段没有缺陷报告，则表明该ECU的诊断功能已经成熟。

一般来讲，测试工程师会同时测试许多不同的ECU，如果没有合适工具的支持，测试工程师便不能很好的对每一个软件版本实现的诊断功能进行全面的测试。这样，只有新增的服务进行了详细测试，对于以前集成的服务仅根据自己的经验进行有代表性的回归测试。使用合适的自动工具，在提供效率的同时还能够进行更多的验证测试。 [page]

3 验证工具应具备的条件

一个自动诊断验证工具必须具备下述条件：

·与现有工具链无缝集成
·透明，可重复：测试工程师必须能够追踪测试并能够复现测试
·遵循GM的现有测试方法：该工具必须支持现有的测试方法；在诊断这一块，GM的诊断规范已经定义了ECU诊断服务的强制测试流程
·方便测试工程师扩展
·自动生成测试例程：为了实现该功能，规范必须能够机器可识别

4 从规范到测试执行，生成报告

如图二所示，“DiVa”建立了“CANdelaStudio”（诊断规范）与验证工具（“CANoe”）的联系。“DiVA”能够无缝集成到GME现有工具链中，根据“CANdela”的诊断规范（CDD文件），自动生成检验各诊断服务的测试例程。生成的代码是基于CANoe的编程语言“CAPL”的，所以能够在任何时候被执行。如果发现问题，测试工程师察看测试系列，找出错误所在（透明性）。另外，CANoe的纪录功能够在通信层记录诊断数据流。

使用“DiVa”，通过下述步骤来控制测试：

·选择ECU及其变量
·配置测试
·生成测试例程
·将测试模块添加到“CANoe”的测试环境中
·执行测试
·生成测试报告

用户可以在任何时候修改“DiVa”的测试约束，此外，范围参数用来配置测试内容，例如全范围测试，快速测试和正常例程测试。另外，在支持的服务中，用户可以从测试中去除部分服务，或者在数据对话窗口中修改服务的内容，如图四。

图四 DiVa配置窗口

当诊断规范（CDD文件）更新，“DiVa”能够同步更新并保留以前的设置。从技术的角度讲，“DiVa”生成的“CANoe”测试的CAPL程序的目的是测试ECU支持的所有诊断服务。为了保证遵循GM的诊断规范，“DiVa”的扩展功能对应了GM的标准测试程序。测试例程生成过程中会产生测试例程的详细描述文件，用作“CANoe”测试模块的CAPL程序以及相关的CANoe测试环境。

5 测试执行与报告评估

测试例程生成后，用户将生成的测试环境加入到“CANoe”中便可进行测试。测试的时间依据诊断规范的复杂程度以及用户选择的测试范围而定，可能会从几分钟到几个小时不等，如表一所示。在GM，“CANoe”的测试环境作为一个测试自动化的共同平台，被重复用到现有的ECU测试程序中。例如，EOL编程测试也在“CANoe”上通过CAPL实现。为了让测试工程师分析起来更加容易，测试报告的结构遵循GM的诊断规范，如图五所示。

表一 Opel Insignia中，生成的ECU测试例程的数量以及测试的时间

图五 DiVa生成的测试报告

6 测试覆盖范围

自动测试扩展了测试覆盖度同时缩短了测试执行所需时间。下面将描述GM诊断规范所定义的测试范围以及“DiVa”测试程序的覆盖范围。“DiVa”生成的测试例程的质量与数量大部分由诊断规范（CDD文件）决定，所有产生的测试均源于此。 [page]

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”能够在不同的开发阶段，完成针对不同诊断规范的测试并能够增加测试的范围。

图六 手工与自动测试效率的对比

7 经济效益及效率的提升

当引入一个工具，首先要考虑的是经济效益。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)