从桌面仿真到实时测试自动化，分析自动化的发展之路

随着系统设计变得越来越复杂，依靠原型来确定系统性能是否满足设计需求的风险也变的复杂：在需要启动测试时，原型可能成本高昂，操作风险大，甚至不可用或不完整。因此，越来越多的工程团队在设计过程的早期就使用仿真和其他测试技术，此时错误更易于修复，且成本更低。

Simulink Test 提供了一个集成框架，使您可以在整个设计过程（从桌面仿真到硬件测试）中执行自动化、可重复的测试（图 1）。

图 1：通过桌面和硬件在环仿真进行可重复系统测试的框架。

我们将使用一个颤振抑制示例来演示这种工作框架。

颤振抑制系统测试目标和设置

颤振是由作用在机翼上的空气动力引起的振动。这种现象可以导致机翼振动，严重时会导致机翼损坏。控制颤振的一种方法是使用控制表面并试图抑制振动。

我们的颤振抑制系统有三个输入：所需的角度（度）、速度（马赫）和海拔高度（英尺）。它的单一输出是机翼的测量偏差（弧度）。

我们需要根据两个设计需求测试系统：

系统在施加扰动的两秒内将颤振抑制在 0.005 弧度以内

颤振随时间呈指数衰减 — 具体而言，系统具有正阻尼比

系统需要在各种操作条件下满足这些需求，以最大限度地减少在现场部署或投入生产时的意外行为。

图 2 显示了我们的颤振抑制系统的 Simulink 模型。

图 2：飞机颤振抑制系统模型。

在这个模型中，我们将在三秒钟后引入扰动，然后测试控制器是否能够抑制各种马赫和海拔高度点的颤振。

要执行测试，我们需要具备以下条件：

可以在仿真的每个时间步长监控颤振的测试环境

记录数据以确定颤振是否随时间呈指数衰减的能力

依托各种马赫和海拔高度值进行迭代的能力

设置测试框架测试序列模块

控制设计工程师有时会创建两个独立的模型，一个用于测试的基础模型，另一个用于布置。确保基础模型和布置的模型等效具有一定难度。此外，根据测试任务，可能需要自定义输入或记录其他数据，这些会更改基础模型。

Simulink 提供了两个工具，使我们能够避免此版本控制问题：测试框架和测试序列模块。测试框架是一个与被测系统模块关联的模型。它有单独的模型工作区和配置集，但仍然存在于主模型中。它有效地为我们提供了一个沙盒来测试我们的设计，而不会改变或破坏基础模型。

要在 Simulink 中从头开始创建测试框架，我们只需右键单击子系统，或者从工具条中选择 Analysis（分析），然后在选择 Test Harness（测试框架）后，选择 Create Test Harness（创建测试框架）。随后，以交互方式配置新测试框架（图 3）。

图 3：Simulink 中的测试框架对话框。

测试序列模块（图 4 中红框表示）使用 MATLAB 作为动作语言（图 5）。它允许您在评估被测组件时有条件地在测试步骤之间转换。您可以使用条件逻辑、时序算子（例如 before 和 after）和事件算子（例如 hasChanged 和 hasChangedFrom）。 

图 4：测试序列模块（红框）和数据记录（蓝框）的测试框架模型。

图 5：支持 MATLAB 动作语言的测试序列。

第一个需求规定颤振应以施加初始扰动的两秒内被抑制。我们合并了一个测试序列模块来实施这个测试用例。我们将期望设置为 0 弧度，并在五秒后计算每个时间步长下的误差。使用verify函数记录每个时间步长是否满足条件。

为了计算阻尼比，我们使用图 4 中蓝框内的 To Workspace（到工作区）和 File Scope（文件范围）将数据以仿真和实时方式记录下来。

创建和运行桌面仿真

被测系统有两个输入：马赫和海拔高度。需求定义系统应在各种操作条件下进行测试。我们可以使用 Simulink Test Manager 创建各种条件下的自动化测试用例。测试用例使我们能够在不同的输入条件下自动测试这两个需求，并生成有关它们是通过还是失败的报告。当设计的更改时，可以重新运行这个测试用例。

使用 Test Manager，我们可以为颤振抑制系统新建一个测试框架，添加测试目的描述，并将其链接到需求。最后，我们使用脚本迭代为马赫和海拔高度指定了一些操作条件（图 6）。

图 6：在测试管理器界面中使用 MATLAB 脚本为不同的马赫和海拔高度值设置迭代。

我们现在将使用此测试自动化工作流程来测试我们的两项需求。第一项需求已使用测试序列模块予以处理。重新调用 verify 函数。如果验证标准在任何时候出现失败，则整体测试将失败。

对于第二项需求，我们添加了模块来记录仿真数据。我们需要对测量的角度进行一些数据分析，以确定测试是通过还是失败。通过在每次运行仿真后执行 cleanup 回调函数可完成这项分析（图 7）。我们可以利用以前的数据分析工作来进行指数拟合，并根据拟合参数声明通过或失败。

图 7：在测试管理器界面中为自定义标准设置cleanup回调函数。

从现在开始，测试将根据我们指定的操作条件自动检查我们的系统。我们可以在 Results and Artifacts 窗格中看到测试结果（图 8）。我们可以检查 verify 语句的输出，确定未评估测试标准、评估通过及评估失败的时间。此外，我们可以可视化记录的指定和测量角度数据。

图 8：verify语句的输出（需求 1）。

系统在仿真中通过了所有测试，但让我们仔细研究以确保满足需求。颤振应以施加扰动的两秒内为界的需求。鉴于扰动在仿真中施加了三秒，预期 verify 语句在仿真的前五秒未经测试。从那以后，我们可以看到测试通过了。

测量角度数据表明，颤振不仅是有界的，而且是衰减的，这符合第二个需求（图 9）。

图9：测量角度输出。

实时测试

我们现在准备使用硬件在环 (HIL) 仿真来测试硬件。HIL 的目标是实时仿真被控对象模型动态，同时与将在实际使用的嵌入式控制器连接。为了进行 HIL，我们将运行 Simulink 的笔记本电脑、Speedgoat 实时仿真机以及嵌入式控制器通过模拟和数字 I/O 进行连接连接（图 10）。

图10：测试硬件：Windows PC（红）、Speedgoat目标（蓝）和嵌入式控制器（绿）。

在笔记本电脑上，我们从模型中生成 C 代码并将其编译为实时应用。该应用可通过以太网连接下载到 Speedgoat 实时目标计算机。生成的代码包括被控对象模型动态、与控制器通信所需的 I/O 驱动程序以及包含 verify 函数的测试评估模块。

仿真与实时测试之间的关键区别在于我们删除了仿真控制系统并使用在嵌入式处理器上布置的控制系统。然后，我们可以在其实际工作频率下测试已布置的控制系统及其输入和输出。

我们现在将使用测试管理器创建实时测试（图 11）。

图11：设置实时测试的Test Manager界面。

在实时测试中，我们构建与之前一样的环境，外加一个被测系统环境 Target Computer（目标计算机）。测试将允许在实时仿真机中。

我们将在与以前相同的各种操作条件下测试需求，并且对测量的角度进行相同的数据分析，以确定测试是通过还是失败。我们可以在测试管理器中查看测试结果（图 12）。

图 12：实时测试结果。

我们发现某些测试条件下的实时测试失败了。如图 12 和图 13 所示，verify 语句在各个点处失败，并且测量的角度不会衰减，从而导致系统不稳定。 

图13：来自实时测试的测量角度输出。

是什么差异导致仿真中通过，而 HIL 测试时失败？

测试失败有多种原因，这些原因凸显了使用硬件进行测试的重要性。首先，在仿真模型中，使用双精度值作为接口直接连接控制器和被控对象。实时仿真与生产控制器之间的连接通过数字和模拟信号建立，因此，由于量化误差，我们在接口中立即失去精度。其次，仿真测试没有考虑实际系统中存在的实际延迟。第三，在仿真中测试的控制设计可能未在生产控制器中正确实施。

尽管这些测试没有通过，但我们仍有工作要做，我们需要创建一份报告发送给同事。我们要使用测试管理器中的报告生成器创建一个报告，记录执行测试的人员、测试标准、需求的链接以及结果摘要。

随着系统设计的发展，我们可以使用测试管理器和我们已经创建的测试来自动执行迭代测试并为这些测试生成报告。