高效的汽车电子测试――一种贯穿HIL仿真到诊断的测试环境

这种测试的一个重要基础是残余总线仿真。理想情况下这种仿真并非由手工建立，而是从系统的描述数据库中自动生成和参数化的。实际工作由所谓的建模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线路间的抽象，另一方面提供了测试定义和仿真模型间的抽象。