EEPW论坛

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

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

分析、仿真和测试工具

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的诊断功能。测试描述文件除了包含系统的基本信息外，还包含了信号、报文和诊断服务等的符号化名称。这简化了测试人员和测试开发者的工作，并且在测试和通信描述之间创建了一个抽象层。

图1：CANoe包含针对网络系统的分析、仿真和测试功能。

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

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

测试与开发的集成

如今的开发模型在各个开发阶段都要求进行测试(图3)。通常，个体测试是独立的、分离的活动，是由专门的人使用专门的工具、语言和方法在有适当配置的专用工作站上完成的。这里，创建测试通常是一项独立的工作，与其他开发活动是分开的。

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

{pagination}

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

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

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

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

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

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

成熟度评估和误差分析

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

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

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

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

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

基于上述原因，测试台上的测试步骤以及每一个与DUT间的交互动作都将被强制记录，特别是总线通信。在分析阶段，CANoe允许重放和分析任何需要的记录(日志)。从而有可能在开发场所使用与测试台上相同的测试系统以从中受益，这样开发者就可以独立地再现生成错误的测试用例。在很多情况下，甚至是有必要进行简化时(比如为了避免选择不存在的测量硬件)都可以执行相关测试用例。

信号抽象和诊断

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

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

图5：信号一方面提供了消息和I/O线路间的抽象，另一方面提供了测试定义和仿真模型间的抽象。

{pagination}

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

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

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

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

高效的测试生成

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

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

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

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

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

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

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

本文小结

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