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

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

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

任何复杂系统的开发始于要求。通常在文本文档中提供或使用需求管理工具，它们成为系统设计和验证的基础。要求通常还具有某种类型的标记信息，以允许跟踪和链接要求。

在直升机控制系统示例中，我们将使用与态度/标题参考系统（AHRS）的投票相关的要求。这些是兴趣的五个要求：

HLR_9 AHRS有效性检查

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

HLR_10 AHRS输入信号处理

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

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

HLR_11 AHRS投票支持三重传感器

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

HLR_12 AHRS对双传感器的投票

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

HLR_13 AHRS使用单个传感器

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

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

通过仿真,验证

为了验证针对软件需求的设计，我们使用Simulink Test™中的Test Manager将测试用例链接到Simulink中创建的模拟测试工具(图2)。金宝app

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

工具中的Test Sequence块包含我们根据需求创建的测试。我们可以使用它来定义测试中模型的输入数据的测试步骤，以及测试的预期结果数据。测试序列语言中有一个Verify函数，用于评估每个测试步骤是否通过(图4)。

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

该报告显示所有三个测试用例通过，但模型覆盖率并不完整。虽然执行了模型中的所有块，但仅采用了该模型中的97％的决策。详细的模型覆盖报告显示，第一个缺失的决定是用于多端口交换机块;0从未测试的输入条件（图6）。

中值投票子系统中的MinMax块还有第二个决策缺失(图7)。

这些缺失的决策需要得到解决，因为当我们测试软件时，它们将导致缺失代码覆盖率。安全标准如DO-178C和ISO 26262要求在测试过程中覆盖完整的代码。

补充模拟情况下

通过将覆盖率数据导入Simulink Design Verifier™，我们可以自动生成缺失覆盖范围的测试用例，并使其忽略先前模拟满足的模型覆盖目标（图8）。金宝app

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

一旦我们执行测试用例并导出它们，就会生成测试生成报告，其描述生成的测试用例和所涵盖的模型目标。图10示出了来自报告的一部分，指示输入2的多端口开关输入0和Minmax元素3是最大值。

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

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

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

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

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

现在我们可以通过简单地切换测试管理器中的模型模式来重新运行模拟测试，以便在测试管理器到PIL（图11）。

当在软件上运行测试时，我们会得到一个测试结果报告，非常类似于我们以前运行的模拟结果报告。图12显示了软件的测试结果。

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

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

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

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

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

我们选择了1e-7的绝对公差和0.1%的相对公差来比较Simulink模型输出和软件输出。金宝app用户可以选择这些值。

运行这些测试用例会产生一个测试报告和一个包含代码覆盖摘要的代码覆盖报告(图16)。

如预期的，这两个测试用例的两个测试用例通过，并且由于它们的目的仅达到多端口开关输入0和输入2的MINMAX元素3，因此对这两个测试用例的代码覆盖结果相对较低。为了获得整个测试套件的代码覆盖，这两种情况加上三个案例先前运行，我们必须将覆盖率数据与两种不同的测试运行合并。

当两组覆盖数据合并时，我们得到一个报告，表明软件的完整结构覆盖已经实现(图17)。

测试1是先前在代码上运行的基于要求的测试。测试2是在代码上运行的Simu金宝applink设计验证程序测试。摘要结果表明通过运行两组测试来实现的总覆盖范围。

总结

我们已经了解了如何使用Simulink模型从需求到设计再到代码。金宝app在此过程中，许多验证活动都是自动化的，以减少所需的手工工作。结果是一个软件系统已经根据需求进行了充分的验证，并且具有完整的代码覆盖范围。

这个示例只涉及实际系统的一小部分。同样的过程可以扩展到一个完整的系统，如完整的直升机飞行控制系统或固定翼飞机的自动驾驶系统。