基于模型的空间应用系统工程

打开工程

要创建基于 CubeSat 模型的系统工程工程的新实例，请在 Simulink 开始页中选择创建工程。加载工程后，CubeSat 的架构模型将打开。

open("asbCubeSatMBSEProject.sltx");

定义系统级需求

为任务定义一组系统级需求。您可以从第三方需求管理工具（例如 ReqIF（需求交换格式）文件）导入这些需求，或者直接在需求编辑器中编写它们。

此示例包含一组存储在 SystemRequirements.slreqx 中的系统级需求。在需求编辑器中打开此需求规范文件。通过 App 选项卡或双击工程文件夹浏览器中的 SystemRequirements.slreqx 来访问需求编辑器。

我们对这次任务的最高需求是：

从这个顶级需求中分解出额外的需求，以创建架构的需求层次结构。

构建系统架构

System Composer 支持基于模型的系统工程架构的规范和分析。使用上面定义的系统级需求来指导在 System Composer 中创建架构模型。本示例中的架构基于国际系统工程理事会 (INCOSE) 空间系统工作组 (SSWG) [1] 开发的 CubeSat 引用模型 (CRM)。

该架构由组件、端口和连接器组成。组件是系统的一部分，在架构的背景下实现明确的函数。它定义了一个架构元素，例如系统、子系统、硬件、软件或其他概念实体。

端口是组件或架构上的节点，代表与其环境的交互点。端口允许信息与其他组件或系统之间流动。连接器是提供端口之间连接的线。连接器描述信息在架构中的组件之间如何流动。

使用原型和接口扩展架构

您可以使用原型和接口为架构添加额外的细节层次。

原型

原型通过向每个元素添加特定于领域的元数据来扩展架构元素。原型应用于组件、连接器、端口和其他架构元素，为这些元素提供一组通用的属性，如质量、成本、功率等。

一个或多个架构使用的原型包存储在配置文件中。此示例包括一个名为 CubeSatProfile.xml 的原型配置文件。要查看、编辑或向配置文件添加新的原型，请在配置文件编辑器中的建模选项卡中打开此配置文件。

该配置文件定义了一组应用于 CubeSat 架构中的组件和连接器的原型。

原型还可以从抽象基本原型继承属性。例如，上面配置文件中的BaseSCComponent包含尺寸、质量、成本和功率需求等属性。我们可以向配置文件添加另一个原型CubeSatTotal，并将 BaseSCComponent 定义为其基本原型。CubeSatTotal 添加了其自己的属性，nominalVoltage，但也继承了其基本原型的属性。

在架构模型中，将CubeSatTotal原型应用于 CubeSat 系统组件（asbCubeSatArchModel/CubeSat Mission Enterprise/Space Segment/CubeSat）。选择模型中的组件。在属性检查器中，从下拉窗口中选择所需的原型。接下来，设置 CubeSat 组件的属性值。

接口

数据接口定义了流经端口的信息类型。同一个接口可以分配给多个端口。数据接口可以是复合的，这意味着它可以包含描述接口信号属性的数据元素。从界面编辑器创建和管理界面。Simulink 的现有用户可以将 System Composer 中的接口与 Simulink 中的总线进行比较。事实上，总线可用于定义接口（反之亦然）。例如，数据字典 asbCubeSatModelData.sldd 包含多个总线定义，包括ACSOutBus，可以在接口编辑器中查看并应用于架构端口。

使用架构视图实现系统可视化

现在我们已经使用组件、原型、端口和接口实现了我们的架构，我们可以用架构视图来可视化我们的系统。在建模选项卡中，选择视图。

使用组件层次结构视图来显示我们的系统组件层次结构。每个组件还列出了其原型属性值和端口。

您还可以查看架构不同深度的层次结构。例如，通过双击视图浏览器中的组件导航到架构的 Power System Plant 组件。

将需求链接到架构组件

要将需求链接到实现它们的架构元素，请使用需求管理器。将需求拖到相应的组件、端口或接口上。利用这种链接机制，我们可以确定架构模型中是如何满足需求的。需求管理器中标有“已实施”的列显示文本需求是否已链接到给定模型中的组件。例如，我们的顶级需求“提供视觉图像”与我们的顶级组件CubeSat Mission Enterprise相链接，而分解的需求则与各自分解的架构组件相链接。

将架构与设计模型连接起来

随着设计过程通过分析和其他系统工程过程而日趋成熟，我们可以开始用动态和行为模型填充我们的架构。System Composer 构建于 Simulink 之上的一层，这使得 Simulink 模型可以直接从我们创建的组件中引用。然后，我们可以将我们的架构模型仿真为 Simulink 模型并生成分析结果。例如，GNC subsystem 组件包含 3 个 Simulink模型引用，它们是 CubeSat 仿真工程的一部分。

双击这些引用组件以打开底层的 Simulink 模型。请注意，架构中定义的接口映射到 Simulink 模型中的总线信号。

此示例使用来自 Aerospace Blockset 的 Spacecraft Dynamics模块来传播 CubeSat 轨道和旋转状态。

仿真系统架构以验证轨道需求

我们可以使用仿真来验证我们的系统级需求。在这个场景中，我们最高级别的需求是，CubeSat 机载摄像机每天一次以 10 米分辨率捕捉位于 [ 42.2775 N, 71.2468 W] 的 MathWorks 总部的图像。我们可以使用各种任务分析工具手动验证这一需求。如需查看这些分析的示例，点击工程快捷方式使用 Mapping Toolbox 分析和使用卫星场景分析。

上图显示了使用卫星场景分析快捷方式示例中创建的卫星场景。

使用 Simulink Test 验证轨道需求

虽然我们可以使用 MATLAB 来可视化和分析 CubeSat 行为，但我们也可以使用 Simulink Test 来构建测试用例。该测试用例通过使用测试框架来自动化基于需求的测试过程，以测试我们的立方体卫星轨道和姿态是否满足我们的高级需求。测试用例方法使我们能够根据文本需求创建可扩展、可维护且灵活的测试基础设施。

此示例包含一个测试文件 systemTests.mldatx。在工程文件夹浏览器中双击此文件，即可在测试管理器中查看它。我们的测试文件包含一个测试来验证我们的顶级需求。“验证视觉图像”测试点映射到需求“提供视觉图像”，并定义一个 MATLAB 函数作为测试的自定义准则。虽然这个测试用例并不是对我们整体任务的全面验证，但它在早期开发过程中很有用，可以确认我们最初的轨道选择是合理的，使我们能够继续改进和添加架构的细节。

在测试管理器中运行测试点并确认测试通过。通过结果表明，CubeSat 机载摄像机在仿真窗口期间对成像目标具有可见性。

引用

[1]“空间系统工作组”。INCOSE，2019 年，https://www.incose.org/communities/working-groups-initiatives/space-systems。