在环测试

嵌入式系统软件是一个竞争优势。软件可以使得已经舒适的乘坐更具吸引力，比竞争性交通工具更好。它还可减少驾驶室噪音，或降低燃油消耗。可轻松地配置嵌入式软件，以符合用户的喜好 – 只需按一下开关便可将舒适的公路汽车变为更具运动特色的交通工具。

当然也可在硬件中实现那些可以通过软件获得的功能，但是这样做会相应地增加制造成本和产品价格。嵌入式软件还可实现重复利用利用，并且可更加频繁地更新，以满足不断增长的需求。


   
图1，在环测试示意图

所有这些以及其他更多原因造成了嵌入式软件应用的复杂性。很难测试和验证复杂嵌入式软件的功能。验证和确认费用、解决缺陷的成本以及没有及时发现的缺陷问题会抹杀掉软件功能具有的所有优势。  

嵌入式软件开发行业意识到这一点，并基于图形化模型进行软件开发，以应对不断增长的复杂性。图形化的产品功能还具有仿真能力，可提高验证和确认方法。本文简要概述通过基于模型的设计的关键软件测试方法。

1 通过模型开发和测试嵌入式软件

建模是设计和开发中的一个重要步骤，它发生在收集高层需求之后以及进行任何实现之前。模型还允许在开发的同时，进行持续地进行测试和验证。


图2，建模是设计和开发中的一个重要步骤

在早期的设计阶段，开发者可开发纯粹的行为模型，以阐明并定义软件的详细要求。

虽然此类模型已经具备了基本解决方案的轮廓，但是它们依然独立于目标平台。这些目标独立的行为模型将用于设计验证和早期的需求确认。

用于捕获关键需求、在仿真中展示正确行为以及展示对高层需求可追溯性的模型通常被称为“可执行规范”。

对可执行规范的进一步开发和具体实现可产生代表最终实现的模型的定义。这就是用于产品代码生成的模型。通常，这些模型会对代码生成做优化；它将从数据类型、目标架构以及要求的代码风格。所有这些变更需要一个验证过程，确保产品代码生成模型中引入的变更不会改变软件的行为。确认生产代码生成模型以及生成代码的正确行为的测试为代码验证。
把验证分布在设计验证和代码验证阶段允许我们更早地开始验证工作，更多的关注在测试上和更短的时间去修复在测试中检测到的错误。在本文的其余部分，我将介绍两个设计验证方法：

·模型在环测试
·软件在环测试

以及用于代码验证的两个方法：

·处理器在环测试
·硬件在环测试

2 设计验证

设计验证的主要目的是确认所有关键要求和设计概念是否已正确体现在设计模型中。

·模型在环测试

与“静态”的书面设计不同，可在仿真过程中评估可执行规范。通常，通过改变一组模型参数或输入信号，或通过查看输出结果或模型的响应，来完成这一操作。依据模型执行的仿真顺序也称为模型在环测试。

模型在环测试的测试数据可来自测试矢量数据库，或来自实际系统的模型，在后一种情况下，我们讨论闭环控制系统。  

可执行规范通常不仅仅包含功能设计模型和软件逻辑，还包括设备和环境模型、高层需求的链接以及其他文件。它通常还包括用于自动化仿真结果评估的验证数据。
模型在环测试的结果可用于验证软件行为是否正确，并确认开发流程的初始需求。通过仿真收集的信息会成为代码验证的基准。

·软件在环 (SIL)

在许多情况下，在目标环境中部署软件之前，确保所设计的系统的软件组件能够按预期运行，这一点非常重要。


图3，软件在环（软件算法测试）

软件算法的测试（在主机上的联合仿真中评估生成的函数或手写的代码）称为“软件在环”。与模型在环测试类似，输入测试矢量可来自于测试数据库或来自设备模型，并且可与 MIL 测试共享。

当软件组件包含需要在目标平台上执行的生成代码（例如，更新控制器逻辑以满足新要求）和手写代码（例如，现有驱动程序和数据适配器）的组合时，此类验证尤其有用。  
通常利用软件在环测试来验证图形化模型中现有算法的重新实现。可能很难或需要花费较多成本来维护一些旧的但是正确的代码，这对于在建模环境中重新实现及验证而言意义重大。在这种情  

况下，仿真成为比较新模型实现和旧代码中已有算法的输出的环境。

3 代码验证

验证设计质量及其对现有的需求的兼容性之后，我们可专注于代码验证。代码验证的关键目标是确保软件行为匹配在仿真中捕获的模型行为。

·处理器在环 (PIL)

从概念上来说，处理器在环 (PIL) 测试类似于软件在环测试。关键的差别在于 PIL 代码在嵌入式处理器硬件或指令集仿真器上执行，以便该验证可考虑在目标处理器上执行的算法的特定具体条件。在模型与部署的目标代码之间传递的数据通过 CAN 或串行设备之间通过真正的输入输出来完成。


图4，处理器在环

用于 MIL 和 PIL 的模型现在可用作处理器板的测试框架。通过处理器在环，我们仍然可在主机上运行模型，并使用它对软件组件输入生成实际数据。除此之外，我们还可使用调试器分析代码（已编译的代码）逐步说明装配级别说明，就像在完全嵌入式系统中那样进行链接和部署。

通过 PIL，我们还可查看代码函数的执行顺序，并确认操作系统函数的调用或在目标上执行时所需的其他库，以及在执行验证方案过程中监控内存容量。

在一些项目中，PIL 可在符合相同规范当来自不同厂商的处理器板上比较算法行为。  

正如 SIL 一样，此验证方法并不用于非实时分析。

·硬件在环 (HIL)

目前提到的所有测试方法不能用于实时地验证设计。仿真以及与目标板通信的负荷不允许算法的实时测试。

图5，硬件在环

为了重新利用为前面描述的测试方法创建的数据，并继续使用该结果作为实时测试的指导和基准，我们为模型生成代码并在实时环境中部署它。此类配置可降低在实际且通常较昂贵的设备上的测试风险，但是它允许我们验证算法的实时方面。

此类型的验证要求尖端的信号调节和电力电子技术，以便正确地模拟输入并接收目标硬件的输出。HIL通常在系统集成和现场测试之前，作为最后一个实验室测试步骤。

4 结论

嵌入式系统开发的技术为提升验证和确认方法提供了一次绝好的机会。通过仿真建模以及代码生成使快速原型和更加系统的测试和早期验证成为可能。

上述的每个在环测试方法解决了特定类型的问题，并且具有某些优势。本文中描述的不同方法在严格的开发过程中均出现过，每个方法有助于将巨大的验证挑战分为更小、更易管理的验证和确认活动。