验证高完整性系统的模型和代码

作者:Bill Potter, MathWorks

软件测试是开发复杂系统中要求最高、最耗时的方面之一，因为它涉及到确保所有需求都经过了测试，并且所有软件都经过了测试。以直升机飞控系统中的传感器投票算法为例，介绍了一种基于Simulink的简化验证流程金宝app^®并支持验金宝app证工具。涵盖的主题包括从需求创建测试用例，为模型和代码重用那些测试用例，为缺失的模型覆盖生成测试用例，以及在可执行的目标代码上实现完全的结构覆盖。

直升机控制系统要求与设计

任何复杂系统的开发都是从需求开始的。通常在文本文档或使用需求管理工具中提供，它们成为系统设计和验证的基础。需求通常也有一些类型的标记信息，以支持需求的跟踪和链接。

在直升机控制系统示例中，我们将使用与姿态/航向参考系统(AHRS)投票相关的需求。这是兴趣的五个要求:

HLR_9 AHRS有效性检查

在使用AHRS数据之前，飞行控制软件应验证AHRS数据是否有效。

HLR_10 AHRS输入信号处理

飞行控制计算机硬件处理三个AHRS数字总线输入。

下表定义了从三个传感器中每个输入到软件的AHRS的特征。

信号	输入信号	输入范围
明显有效	N/A	1 =有效 0 =无效
俯仰姿态	Up = +	正/负90度
卷的态度	右= +	正/负180度
俯仰身体率	Up = +	+/- 60度/秒
横摇速度	右= +	+/- 60度/秒

HLR_11 AHRS投票三重传感器

当三个ahrs是有效的，飞行控制计算机应使用三个传感器的中间值从ahrs的每个单独的参数。

HLR_12 AHRS投票双传感器

当只有两个AHRSs有效时，飞行控制计算机应使用两个传感器对来自AHRSs的每个单独参数的平均值。

HLR_13 AHRS单传感器使用情况

当只有一个AHRS有效时，飞行控制计算机应使用该AHRS的单个参数。

我们创建一个Simuli金宝appnk模型来实现这些需求(图1)。

图1。金宝appAHRS投票算法的Simulink模型。

仿真验证

为了根据软件需求验证设计，我们使用Simulink Test™中的测试管理器将测试用例链接到Simulink中创建的模拟测试控制(图2)。金宝app

图2。Test Manager界面。

我们为AHRS投票算法实现了三个测试用例，每个测试用例对应一个投票需求。图3所示的用例用于测试三个有效的传感器，可以追溯到需求文档中的HLR 11 AHRS Voting for Triple sensors。图3显示了相应的测试束，一个驱动测试下组件的test Sequence块。

图3。用于测试传感器的测试线束。

套件中的Test Sequence块包含我们根据需求创建的测试。我们可以使用它来定义带有被测模型输入数据的测试步骤，以及测试的预期结果数据。在测试序列语言中有一个验证函数，用于评估每个测试步骤的通过或失败(图4)。

图4。测试序列块。

测试管理器中的其他测试用例对于它们各自的需求有额外的测试工具和测试序列块。我们从测试管理器运行模拟;金宝appSimulink Test自动生成一个结果报告。在仿真过程中，通过Simulink coverage™测量模型覆盖率，以确定在仿真过程中模型被覆盖金宝app的程度。为三个测试用例生成的报告的摘要部分，包括模型覆盖率评估的摘要，如图5所示。

图5。测试报告总结结果。

报告显示所有三个测试用例都通过了，但是模型覆盖还不完全。虽然模型中的所有块都被执行了，但模型中只有97%的决策被执行。详细的模型覆盖报告显示，第一个缺失的决策是针对Multiport Switch块的;输入条件0从未被测试过(图6)。

图6。Multiport Switch block missing coverage。

对于中间值投票子系统中的MinMax块，存在第二个缺失的决策(图7)。

图7。最小最大块丢失覆盖。

这些缺失的决策需要被处理，因为当我们测试软件时，它们将导致缺失的代码覆盖率。诸如DO-178C和ISO 26262等安全标准要求在测试期间覆盖全部代码。

补充仿真案例

通过将覆盖数据导入Simulink Design Verifier™，我们可以为缺失的覆盖自动生成测试用例，并让它忽略先前模拟所满足的模型覆盖目标(图8)。金宝app

图8。金宝appSimulink设计验证器测试生成选项。

我们设置Simuli金宝appnk Design Verifier，将生成的测试用例导出到带有测试工具的Simulink test文件中，使用如图9所示的设置。

图9。金宝appSimulink设计验证器结果选项。

一旦我们执行测试用例并导出它们，就会产生一个测试生成报告，该报告描述了生成的测试用例和覆盖的模型目标。图10显示了报告中的一个部分，该部分指出Multiport Switch输入0和输入2的MinMax元素3是最大值。

图10。测试生成报告。

现在我们应该有了完整测试软件所需的所有测试用例。

测试软件和测量代码覆盖率

我们使用Embedded Coder从AHRS_voter模型生成代码^®并使用目标编译器将其编译成可执行文件。现在我们可以测试编译后的软件并测量代码覆盖率了。我们分两步来做，第一步是重复需求文档的模拟用例，第二步是在生成和编译的软件上运行Simulink Design Verifier自动生成的测试用例。金宝app这种方法允许我们检测编译器或目标硬件注入的任何错误。

我们使用嵌入式编码器提供的处理器在环(PIL)功能建立了一个软件测试环境。嵌入式Coder中的API允许运行在主机上的Simulink将软金宝app件下载到外部硬件开发板，并与该软件通信以执行该软件。API可以设置为直接与电路板通信，也可以通过连接到电路板的集成开发环境(IDE)进行通信。最好的做法是在主板上使用与最终目标硬件上相同的CPU部件号，并使用与最终目标硬件上相同的编译器和优化设置。

嵌入式编码API在主机上提供接口代码，允许Simulink将输入数据发送到模型参考块，然后在每个时间步骤的块输出处读取软件的输出。金宝app实际上，Simulin金宝appk正在模拟对代码函数的调用。此特性可用于单个模型引用块或模型引用块的层次结构。在PIL中运行的代码可以使用Simulink coverage或第三方工具(如LDRA或VectorCAST)进行代码覆盖金宝app^®．代码分析还可以逐帧测量执行时间。

现在我们可以通过简单地在test Manager中将测试模型的模式切换到PIL来重新运行模拟测试(图11)。

图11。Processor-in-the-loop选择。

当在软件上运行测试时，我们得到的测试结果报告与之前运行的模拟结果报告非常相似。图12显示了该软件的测试结果。

图12。软件测试结果。

当三个软件测试用例通过时，就像模拟用例一样，软件的覆盖结果略有不同。软件的决策和执行覆盖比模型的要少，并且代码覆盖指示了不在模型中的条件和关系边界覆盖。这些结果不是由于不同的功能，而是由于代码和模型语义之间的差异。

代码覆盖率报告阐明了这些相似点和不同点。该软件使用Switch-Case语句实现了模型中的Multiport Switch，我们可以看到，对应于Switch输入0的Case 0没有在代码中进行测试。这是预期的，因为模型模拟没有覆盖设置为0的开关控制输入，但是这个测试用例还包括未执行的代码行，导致不到100%的语句或执行覆盖率。图13所示的覆盖率报告突出显示了代码中缺失的覆盖率。

图13。缺少代码覆盖。

另一个区别涉及到MinMax3块。这个块缺少模型中元素3的覆盖，但是没有迹象表明代码中缺少覆盖。因为代码在for循环中实现了vector操作，所以这个块的代码被完全覆盖了(图14)。

图14。MinMax3全代码覆盖。

在这种情况下，覆盖模型的测试用例的标准比覆盖代码的标准更严格。

为了完成软件测试，我们运行Simulink Design Verifier生成的测试用例并金宝app测量覆盖率。金宝appSimulink Design Verifier已经生成了两个测试用例，以及预期的结果，并自动将它们导出到Simulink test，以便它们可以使用PIL模式运行。图15显示了test Manager中的测试迭代。