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

信号抽象也表示了——至少在协议层——残余总线仿真。比如，它保证周期性信号的确是按周期发送的。在测试中，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：使用生成器可以从完全不同的来源创建测试。