基于汽车电子测试工具实现测试任务的解决方案

1 引言

过去十年，汽车电子行业的状况发生了翻天覆地的变化。起初，在汽车上仅使用了几个ECU，但是现在某些豪华车安装的ECU数量超过了60个。增加的电子系统提高了安全性、舒适性并节约了能源。今天，更多的创新依赖于电子技术，并且很多功能的实现日益依赖于软件。

复杂度的增长使得全面而高效的测试变得比以往任何时候都更加重要。大量电子元件的广泛使用导致潜在错误源的数量急剧增多。测试可以极早发现并改正错误、尽可能降低成本，在ECU开发的所有阶段它都是不可或缺的。只有将部件集成起来并运行于真实环境和实时条件下时，一些系统缺陷才会暴露出来。这让测试成为了一门跨部门和跨厂商的学科。

早期发生的大量电子故障说明在不考虑上述事实、忽视系统测试的情况下会发生什么问题。在开发过程中问题发现的越晚，那么对成本增长产生的影响就越严重。极端情况下由于修正错误而引起的产品召回更加清楚地说明了这一点。虽然汽车工业的成员吸取了这些教训，现在对测试极为重视，然而可以通过利用现有的资源进一步提高效率。虽然测试成本占用了相当的项目预算，但是保证了ECU的正确功能。因此，使用明晰的概念（比如使用现代方法和工具代替不恰当的自动测试步骤）达到最高的测试质量和测试深度是非常重要的。

2 分析、仿真和测试工具

ECU网络是汽车电子的中枢。在这里，残余总线仿真方法为进行ECU测试建立了重要基础。如果没有对ECU环境的初步模拟，那么大多数ECU都不能有意义地运行。比如，很多ECU只有在提供网络管理功能的条件下才能正常运转。

来自Vector Informatik公司的CANoe是一个被广泛使用的用于分析、仿真和测试分布式、嵌入式系统的工具（图1）。它被广泛应用于残余总线仿真并且支持所有重要的总线系统——特别是CAN、LIN、MOST和FlexRay——Vector Informatik公司也提供适用于这些总线系统的PC接口。现有的商业接口卡可用于从CANoe访问ECU的I/O线路。此外，Vector宣布将发布一种带有特定测试功能（比如切换附加负载到ECU终端和将其直接短路）的I/O硬件产品。

不同的分析功能、仿真组件和测试序列依赖于以数据库形式集成在工具中的模型。它们可能是用于CAN的DBC格式的通信矩阵、用于FlexRay的FIBEX文件、用于MOST的XML功能目录或用于LIN的LDF文件。同样地，可使用CDD和ODX描述文件来描述ECU的诊断功能。测试描述文件除了包含系统的基本信息外，还包含了信号、报文和诊断服务等的符号化名称。这简化了测试人员和测试开发者的工作，并且在测试和通信描述之间创建了一个抽象层。

任何运行Windows操作系统的简单PC工作站都可运行CANoe。使用实时配置系统可以建立具备高实时性能的、更为强大的测试站。实时配置系统由两部分组成（图2）：一台运行实时操作系统（Windows CE）的专用电脑，用于执行残余总线仿真和实际的测试；另一台独立的PC机，用作图形用户界面和进行评估。在该设置中，系统也可用作进行部件HIL测试的测试执行环境。

［图2：双机运行的CANoe Real-Time提供了更高的实时性］

3 测试与开发的集成

如今的开发模型在多个开发阶段都要求进行测试（图3）。通常，个体测试是独立的、分离的活动，是由专门的人使用专门的工具、语言和方法在正确装备的专用工作站上完成的。这里，创建测试通常是一项独立的工作，与其它开发活动是分开的。

［图3：测试在所有开发阶段都是不可或缺的］

这种分段式的工作方法产生于将开发过程中众多不同的任务分配给专门的工作组。但是，如果对任务分割的要求太严格，那么存在于不同开发和测试任务间的众多关联点将很有可能不能被优化利用。比如，只有很好地协调部件测试和系统测试才能避免开发大量内容相同的冗余测试用例。当使用兼容工具时，已经开发出来的测试用例可以作为其它不同领域的开发基础。避免冗余开发释放了占用的资源，比如可以将其投入到现有测试用例及其高级开发的确认工作中。全面的测试管理为协作提供了坚实的基础，共用相同的测试用例优化了测试的广度和深度。协调也有助于发现和填补测试缺口。

除了连接不同的测试阶段，开发和测试活动也必须相互联系并互相适应。应当将测试理解为开发的组成部分，需要使用恰当的方法和工具对其进行广泛的支持。这必须从程序上和组织上得到保证。这里，重要的是测试与开发一起进行，而不是只在要求的正式确认阶段进行。理想的情况是，可以直接在ECU开发者的工作地点利用现有的资源直接进行测试。

为此，CANoe提供了一个用来执行测试的运行时环境，并可以与残余总线仿真和分析功能并行使用 。该流程非常容易建立，尤其是在开发者已经使用CANoe进行残余总线仿真和总线通信分析的情况下。

CANoe的测试组件可以手动、半自动和完全自动化的完成测试。开发者可以从简单测试入手，然后对它们进行扩展和完善。通常，复杂测试的创建过程是确认部门的任务，他们要在开发者的测试上建立他们的测试。

这种测试的重要基础是残余总线仿真。在理想情况下，这种仿真不是手工建立的，而是从系统的描述数据库中自动生成和参数化的。实际工作由所谓的建模DLL（比如交互层、网络管理等）完成，它们是随工具一起提供的或者是由Vector作为OEM专用建模包提供的。残余总线仿真为模拟节点提供的信号可以直接从测试脚本获取，或者以手工方式激励或添加。

与在测试阶段系统进行的计划、执行和归档活动相比，伴随开发的测试通常省略了正式的执行和归档。然而，这些测试对提高整体质量做出了实际贡献，因为他们让开发者能够为后续的测试阶段提供更稳定的产品。

4 成熟度评估和误差分析

在开发过程中，为了评估ECU的成熟度，需要对所有执行过的测试进行全面的评价。必须考虑个体测试结果在可靠性和相关性方面的质量，而更加重要的是采用恰当的测试全面覆盖所要求的特性。因此，不怎么正式执行的测试，其结果对成熟度分析也是有帮助的。前提条件是（除了记录测试过程外）使用兼容的配置管理。从完成面向质量的、结构化的开发过程的角度来说，这也是十分必要的。

不论在何时何地（测试实验室或开发场所），使用CANoe执行测试时都会生成一个测试记录，该记录创建时不需要用户或测试用例开发者进行干涉。这样在进行伴随开发的测试时就不需要做额外的工作。用于测试记录的XML是一种开放格式，可供其它工具使用以对结果进行更深入的处理。例如，在进行成熟度分析时可以使用一个测试管理系统来评价测试记录。

该工作的本质是测试结果到测试用例、测试用例到需求的映射。使用唯一的标识符（比如一个需求ID）可以很容易地实现这一点，测试用例开发者在个体测试用例中会引用它。CANoe会自动将该标识符复制到测试记录中，这样所有测试用例、测试结果和需求就可以明确地关联起来（图4）。

［图4：测试用例和测试结果由ID明确地引用］

分析实际发生错误的原因至少与记录和评估测试结果同样重要。大多数测试工具都不会提供任何这样的功能或者仅仅提供不完善的功能。一个重要原因就是错误分析经常被当作开发者的一项完全独立的任务。首先，他们面临理解测试中检测到的错误并跟踪其原因的问题。尤其是，当测试实验室报告错误时，开发者常常甚至不能使用测试中用到的系统。

因此，会强制要求准确记录测试台上的测试步骤并记录每一个与DUT间的交互动作，尤其是总线通信。在分析阶段，CANoe允许重放和分析任何需要的记录（日志记录）。从而有可能在开发场所使用与测试台上相同的测试系统并从中受益，因此开发者可以独立地重新执行错误生成测试用例。在很多情况下，甚至是有必要进行简化时（比如为了避免选择不存在的测量硬件）都可以执行相关测试用例。

5 信号抽象和诊断

抽象是处理软件开发和系统设计中复杂度问题时普遍采用的重要方法。也可用它来处理测试。ECU中增长的功能不仅增加了系统的复杂度，而且需要更加广泛和复杂的测试。选择正确的抽象层组成测试不仅会影响创建测试用例所需要的工作量、进而影响成本，而且会影响测试用例的质量。就像所有其它软件组件一样，测试用例本身也可能会存在错误，应该在使用之前进行检查。另一方面是必要的维护任务，比如适应需求的改变和修订测试用例。

信号层抽象是测试ECU功能的常用方法，这也是为什么在ECU中实际的应用程序通常会基于信号抽象的原因（图5）。例如，在一个CAN系统中，ECU交互层提供了信号抽象。这正是CANoe使用交互层的方式；它从网络描述包含的信息中将自身参数化，而网络描述也用于创建ECU软件。这保证了ECU和测试环境使用相同的抽象层从而在相互间形成最佳的协调。

同时，信号抽象也表示了——至少在协议层——残余总线仿真。比如，它保证周期性信号实际是按周期发送的。在测试中，ECU是运行在有关总线通信的现实环境下的。此外，当修改了系统通信矩阵时，通常可以继续使用保持不变的测试用例。对相同的应用程序，抽象使得相似项目中的测试用例得到重用。

在ECU测试中，重要的并不仅仅是信号接口。只有在对ECU进行较深层访问时，对许多ECU功能的测试才会有意义。这样的访问是由诊断和标定接口提供的，它们通过ECU的现有总线接口接入。使用简单的消息序列对这些接口进行访问是没有意义的，因为在通信进程下面存在着规定的协议。使用合适的诊断和标定抽象 会更加便捷和可靠。

在CANoe中，由来自CANdela工具的描述文件或者ODX描述文件负责诊断访问层的参数化。如果没有对ECU实际诊断能力的描述文件，那么可以使用CANoe提供的针对KWP2000和UDS的一般描述。ECU专用的一般描述文件或诊断描述文件都为方便地访问那里定义的诊断服务提供了便利。有可能获得与前文所述的信号抽象一样的抽象和优点。

通过CANoe中的测试脚本就可以使用测量和标定协议CCP和XCP访问ECU的内部变量。测量和标定工具CANape处理这些协议和需要的ECU描述文件（A2L）。 CANoe通过COM接口控制CANape。这样就达到了与前面所描述的信号和诊断抽象相同的目标。

6 高效的测试生成

对测试用例的精密研究显示：很多测试用例可以仅从几个循环模式中生成。在网关ECU中这一点更为明显：大多数测试用例用于检查信号和报文的路由。最终，使用大量测试用例的唯一原因是存在大量可能的输入和输出数据。但是同样类型的模式也存在于其他类型的ECU中。抽象地说，这意味着许多功能是如此进行测试的：首先使用合适的激励使ECU进入一个特殊状态，然后检查进入的状态。这种测试用例的循环模式是：设置信号（激励），等待最大容许响应时间，然后检查新ECU状态下的信号。根据使用测试模式的经验，用户可能识别几个附加的运行时模式，并从中生成许多测试用例。

这些模式表示有进一步优化测试用例生成的机会。CANoe除了提供典型的测试用例编程外，还为用户提供了基于测试模式定义测试用例的方式。因为测试步骤是已知的而且永久集成在了提供的模式中，所以就没有必要再对模式内容进行编程了（图6）。测试用例的生成被简化为定义目标行为，包括任何需要的补充数据，比如允许的建立时间。

很明显，提供的测试模式位于前文所述的信号抽象之上，借助关联的数据库允许对信号、报文等的符号化访问。也可能使用诊断服务或I/O信号。简而言之：整个CANoe的测试基层结构可与测试模式共用。如果有的需求超出了这些能力，仍然可以选择测试用例编程。

［图6：使用模式抽象了测试用例的实际执行从而简化了测试开发］

测试用例的自动生成是在有合适信息源的情况下有效创建测试的另一种方法。生成的测试内容必然受限于描述水平和来源的深度。然而，生成提供了有价值的支持，主要是当通过测试覆盖正式定义的ECU基本特性时。生成测试需要相当低的工作量，这导致能更快地进行测试从而可能更早地发现不良的动向。

［图7： 使用生成器可以从完全不同的来源创建测试］

Vector的工具链利用了这种测试生成器方法。诸如DBC数据库或CANdela定义等描述文件被用作生成器的来源（图7）。生成器使用这些文件生成测试用例，然后由CANoe执行。因为测试脚本可能使用整个工具的基层结构，所以测试生成器通常都设计的非常简单。比如，只需少量的工作，生成器就可以从用户定义的网关描述（例如数据库形式或Excel电子表格）中创建恰当的测试用例。借助前面讲到的测试模式，从客户的特定数据到测试模式格式只需要简单的转换。用户可直接创建这样的生成器。Vector以项目服务的方式提供进一步的支持。

7 总结

汽车OEM和供应商应对增长的ECU测试需求的唯一途径是高效地创建测试和自动化执行测试。本文介绍的测试工具提供了一种被证明的使用信号抽象、集成的诊断、标定和I/O接口、测试模式概念和测试用例生成器来实现测试任务的解决方案。CANoe是一个高性能的测试ECU和网络的运行时环境。使用该工具在开发者的工作地点、不需要做多少工作就能在早期创建和执行测试。CANoe的开放接口促进了全面的测试策略和受工具支持的测试管理的无缝集成。尽管一些用户还把它当作一种远景设想，然而恰当地集成CANoe可能在今天就可以确定成熟度了。Vector正在持续地开发CANoe适应这些领域的使用，并为用户提供现代而高效的测试平台支持。

责任编辑：gt