DO-178B基于模型的设计

在航空航天和其他行业的安全关键应用中部署的软件系统必须满足严格的开发和验证标准。这些标准中使用最广泛的一个是- 178 b吗，“机载系统和设备认证中的软件考虑”。DO-178B指定了66个软件开发过程目标，分布在开发生命周期的各个阶段。它出版于1992年，当时大多数软件都是手工编写的。因此，它没有涵盖高级软件开发技术，并且必须映射到基于模型的设计中的过程和工具。

本文比较了使用Simulink的三种方法金宝app^®系统模型和基于模型的设计，以开发必须满足DO-178B标准的安全关键系统;

• 使用模型只捕获低级软件需求
• 使用模型捕获高级和低级软件需求
• 使用单独的模型来捕获高级和低级软件需求

自动驾驶仪设计演示了一个设计流程，该流程使用单个Simulink模型作为高级和低级软件需求。金宝app

使用模型捕获高级和低级软件需求

在第二种方法中，Simulink模型被认为是高级和低级软金宝app件需求(图2)。

通过减少必须开发的工件的数量，这种方法减少了开发和验证工作。然而，要实现这种方法，系统需求必须足够详细，以使模型能够跟踪并从这些需求中进行验证。

在不同的模型中获取高级和低级软件需求

通过这种方法，Simulink模型可以捕获高金宝app级软件需求。将细节添加到模型中，以捕获低级需求和代码生成(图3)。高级需求模型可能是连续时间的，而用于代码生成的低级需求模型可能是离散时间的。

这种方法的缺点是必须维护和验证两个模型，从而增加了出错的风险。从高级需求模型到低级需求模型的转换是另一个潜在的错误点。

自动驾驶仪示例

本例使用单个Simulink模型作为高级和低级软件需求金宝app。

自动驾驶仪是一种典型的飞机系统，可以使用Simulink和基于模型的设计来设计。金宝app在一个典型的工作流程中，控制系统工程师对自动驾驶仪进行贸易研究和分析，然后向软件组提供设计，以便在目标系统中实现。

因为自动驾驶仪控制着飞机，所以它通常必须达到最高的安全水平。因此，开发团队要进行必要的开发和验证活动，并向认证机构提供证据，证明这些活动得到了适当和完整的执行，这是具有挑战性的。

设计工作流程

设计工作流程从以下步骤开始:

• 获取和验证系统需求
• 系统设计
• 验证系统设计
• 将系统设计分配给软件

然后设计团队完成DO-178B要求的软件步骤:

• 定义和验证软件需求
• 定义软件设计和架构
• 验证软件设计和源代码
• 生成并验证可执行的目标代码

捕获和验证系统需求

自动驾驶仪滚动轴的系统需求在Microsoft Word文档中提供(图4)。团队在文档的一个部分中实现每个需求，该部分还包含需求的基本原理。使用仿真软件金宝app^®验证与确认™软件，他们可以通过超链接直接跟踪需求到设计模型。

需求验证，证明需求是完整和正确的，通常通过审查项目的需求标准检查表来执行。

建模和仿真可以帮助验证需求。在开发系统设计时，您可以模拟模型以确保需求是完整和正确的。模拟可以发现需求中没有考虑到的不需要的系统行为。在某些情况下，它可以证明需求是不可验证的。

系统设计

图5显示了系统设计模型

顶层的布局说明了代表系统设计的基本系统架构，并使我们能够验证系统设计是否满足系统需求。

验证系统设计

随着系统设计在Simulink模型中实现，我们可以根据系统需求验证设计，而不必在实际金宝app的硬件和软件中实现该设计。

该模型的顶层包括三个信号构建块:

• 接合和模式面板
• 参考信号
• 驾驶舱控制

我们可以使用这些模块在模拟过程中进行特定的测试。

当然，单靠测试刺激是不足以验证系统设计是否满足要求的。我们使用包含在子系统Verification_Blocks(图6)中的断言块来确定设计是否满足仿真期间的系统需求。

验证子系统包括四个断言块:

• 检查动态滚转
• 检查滚转范围
• 检查滚转率范围
• 检查副翼范围

检滚范围、检滚率范围和检副翼范围分别提供了检滚角、检滚率和检副翼角度的最小值和最大值。这些断言在所有测试用例中都是启用的。这些值，包括公差，是基于需求文档的。

断言Check Dynamic Roll在最小值和最大值之间提供了一个窗口，该窗口取决于正在执行的测试用例。信号构建块Roll References用于使用信号组为每个测试用例提供最小值和最大值。

因为我们使用三个信号构建块用于测试刺激，一个用于断言控制需求，所以我们必须为这些块中的每一个协调所选择的信号组。与SystemTest™软件我们可以协调测试用例并自动执行测试用例。

SystemTest提供了一个框架，将测试分为三个阶段:前测试、主测试和后测试。

前测试

我们可以使用Pre Test来设置在Main Test的所有迭代中使用的变量。

在Pre - Test期间，执行以下顺序:

获取需求链接、MATLAB^®元素，从模型中的信号构建块获取需求链接

设置描述，一个MATLAB元素，为测试报告中包含的每个测试提供描述和通过/失败标准文本

主要测试

主测试使我们能够通过测试用例进行迭代。在我们的示例中，我们使用Test Vector参数索引来定义我们已经定义的20个测试用例的执行。

在主测试期间，为每个迭代运行以下序列:

运行测试线束，一个执金宝app行模型的Simulink元素

预处理通过/失败数据，一个MATLAB元素，它计算在Run Test Harness元素中执行do178b_dhc2期间记录的每个断言块输出的最小值

验证通过/失败一个Limit Check元素，它检查来自Pre-Process Pass/Fail Data元素的值，以便在SystemTest中报告断言的状态

构建输入数组，一个MATLAB元素，它从do178b_dhc2模型中的Roll_AP参考模型的输入获取记录的数据，并准备该数据用于下一个Simulink元素金宝app

运行roll_ap，一个运金宝app行roll_ap模型的Simulink元素

预处理对比数据，一个MATLAB元素，它计算在Run Test Harness期间生成的roll_ap的模型参考输出和在Run roll_ap期间直接从roll_ap模型生成的输出之间的差异

验证结果是否匹配，一个限制检查元素，用于验证在预处理比较数据中计算的结果之间的最大差异

保存MAT文件，一个MATLAB元素，它将从Simulink元素记录的数据保存到MAT文件中，以便在Post tes金宝appt期间生成测试报告

保存Excel文件，一个MATLAB元素，它保存了在Run Test Harness中为参考模型roll_ap记录的数据，这样数据就可以用来验证可执行的目标代码目标系统

后测试

我们可以使用Post Test来分析在Main Test的所有迭代中计算的变量。在后测试期间，将运行以下序列:

生成测试报告，一个MATLAB元素，它使用主测试期间存储的MAT文件数据生成PDF格式的测试报告(图7)

运行模型顾问，一个为模型roll_ap运行模型顾问报告的MATLAB元素

生成需求报告，为系统需求文档和roll_ap模型生成需求跟踪报告的MATLAB元素

生成目标代码，一个为roll_ap模型生成目标代码的MATLAB元素

定义和验证软件需求

从系统设计中将具体功能分配给软件，形成软件需求。在我们的示例中，Autopilot子系统(图8)被分配给软件，并成为高级软件需求。

自动驾驶仪子系统架构进一步细分为三个子系统:Roll_Autopilot, Pitch_Autopilot和yaw_damping。Roll_Autopilot子系统包含一个模型参考块Roll_AP(图9)。

Roll_AP函数包含在从系统模型调用的单独模型中(图10)。我们可以查看roll_ap模型内部，以查看分配给软件的功能。

roll_ap模型体系结构被分解为两个参考模型(Heading Mode和Roll reference)和一个子系统(Basic Roll Mode)。

对于DO-178B，我们必须提供需求验证工件，演示系统需求的准确性和一致性、可验证性，以及算法的准确性。我们可以使用前面部分中描述的系统设计验证活动来部分地满足这些目标。我们还必须使用检查表或其他度量来根据系统需求检查模型。

我们使用Simulink生成了一个需求跟踪报告金宝app^®报告生成器™产品在SystemTest的Post Test阶段。

作为DO-178B生命周期的一部分，我们必须验证高级和低级需求是否符合DO-178B标准。我们还必须表明需求与目标计算机兼容。金宝appSimulink Model Advisor允许我们对模型执行静态检查，以自动验证许多标准，并验证与硬件兼容性相关的某些代码生成器选项设置。

定义软件设计和体系结构

软件设计和架构在roll_ap模型和Heading_Mode和attitude_controller参考模型中定义，用于滚动自动驾驶仪功能的控制部分。对于这个功能，我们直接从高级软件需求中生成代码。因此，该模型同时满足了高层和低层的软件需求。

将需要额外的设计和架构活动来完全定义高级和低级软件需求。例如，将存在与处理惯性参考和空气数据传感器输入、将这些输入传递给模型输入以及按适当顺序安排这些任务相关的需求和设计。

验证软件设计和源代码

因为我们已经结合了高级和低级的软件需求，我们可以使用前面描述的软件需求验证活动来涵盖软件设计验证。

源代码是使用Real-Time Workshop从roll_ap模型生成的^®嵌入式编码器™．代码包括跟踪每一行代码到模型和需求文档的注释(图11)。

源代码通常通过代码审查来验证。我们使用Polyspace™下载188bet金宝搏对源代码执行自动验证活动的产品。这些检查检测任何MISRA - C遵从性问题、运行时错误、无法访问的代码、未初始化的变量和数据耦合问题。

我们使用第三方编译器和链接从源代码生成可执行的目标代码。我们可以手动或使用Real-Time Workshop Embedded Coder为软件构建过程生成make文件。

在系统设计验证阶段，我们保存了Excel^®仿真期间用于可执行目标代码验证的文件。图12中显示的文件是软件测试平台如何使用数据对可执行目标代码运行测试的典型示例。该文件包含表示时间的数据以及每个时间步骤的输入和输出数据。

在基于需求的测试期间，我们还必须对代码执行结构覆盖分析，以度量语句、决策和修改的条件或决策覆盖。这是DO-178B目标中最昂贵和最耗时的方面之一。

在从SystemTest运行的模拟过程中，一个模型覆盖报告被自动生成，从而在开发过程的早期，而不是在测试代码之后，提供基于测试的需求有效性的度量(图13)。

模型覆盖工具可以提供以下信息:

• 圈复杂度
• 决定覆盖
• 条件覆盖
• 修改条件/决策覆盖范围
• 查找表覆盖率
• 信号范围覆盖