高效的汽车电子测试

　　在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适应这些领域的使用，并为用户提供现代而高效的测试平台支持。