MBSE | MathWorks 工具在基于模型系统工程中的应用

前文回顾：MBSE | 基于模型的系统工程系列之基础篇

◆  ◆  ◆  ◆

从上一篇文章我们可以看到，系统工程的活动种类比较多，包括了技术过程的相关活动、技术管理过程相关的活动，以及项目使能过程相关的活动。

这些活动的概念和内容我们已经有了基本的了解， 接下来我们看一看，怎样使用 MathWorks 提供的工具链执行这些活动。

大家知道，MathWorks 在 2019 年推出了一个面向系统工程应用的工具——System Composer，从 2019a 版本发展到今天的 2020b 版本，经过多个版本的迭代，功能更加完备，和 MATLAB/Simulink 的其他工具集成的越来越好，正在得到越来越多系统工程师的关注和使用。

但在这里有必要强调一下，正如前面所说， 系统工程涉及的工程活动非常多，这些工程活动的实施不仅需要 System Composer，还需要 MATLAB 和 Simulink 以及其他 Tooblox/Blockset 的支持。

总体来说，System Composer 在系统层面的描述能力、MATLAB 提供的分析能力以及 Simulink 提供的系统级建模仿真能力，让使用 MathWorks 的工具链开展的系统工程活动，在 “定性” 和 “定量” 方面均有更好的工具基础。

下面我们通过一个实例来看一看，采用 MathWorks 提供的工具链怎么开展系统工程的各项活动。

◆  ◆  ◆  ◆

假设我们接收到的任务是开发一个实时跟踪绿色球的系统。

任务/目标定义 和 需求工程

首先，基于这个任务定义，我们需要细化这项任务需求，比如回答下列问题：

• 目标球的材质是什么？

• 目标球有多大？

• 目标球向几方向运动？

• 目标球是在水下，天空，户外还是户内？

• 需要系统以多快的速度追踪到这个球？

这时，我们使用 Simulink Requirements 来定义和管理这些细化的需求。这里我们将需求大致细化为两类， 一类 是目标球属性的需求（待设计的系统的外部约束）， 第二类 是系统本身特性的需求。

每一类都尽量细化为可定量描述的条目，比如对系统本身的需求描述：

• 支持持续追踪的时长大于等于4分钟；

• 所设计系统在尺寸上，能够容纳于可登机的标准行李箱内。

在这一阶段，我们通常基于经验和行业知识对涉众需求进行归纳和梳理，初步形成专业化语言表达的系统层面的工程需求。

很多时候，我们是凭借专家系统的监督和评审来保证系统需求分解的质量，而在设计复杂系统时，系统涌现性凸显，要想达到如 ARP4754 所提出的系统需求一致性和完整性要求，还需要在架构设计和详细设计等环节，逐步对各条需求进行综合分析和论证（包括：任务/目标定义阶段，MATLAB/Simulink 环境下，构建可仿真的系统级模型，逐条根据需求构建运行场景开展仿真），才能进一步保障系统需求分解的质量。

系统架构

下面我们根据需求使用模型来对这个系统进行设计和描述。

• 整个系统在架构上由三个部分组成：位于地面的控制终端、飞行器（追踪目标）以及目标；

• 控制终端和飞行器间的接口定义为 GCSCmds；

• 通过使用构造型为飞行器和目标定义一些关键属性（基于这些属性可以进一步开展一系列的分析）。

同时，建立清晰的需求和架构模型之间的关联，这也是很多 Safety-Critical 系统设计的时候，相关最佳实践和规范所提倡和要求的。

如上图所示，我们基本完成初步的架构设计：

其中，使用方框图（1）表示 SoS（System of Systems，此处指我们待设计的复杂系统）的组成部分（系统/目标），

Port（2）表示端口（物理属性），

而（4）中的数据结构表示端口（2）关联的接口定义（信息属性），

线（3）表示 SoS 组成部分之间的“关系”，

需求窗口（5）显示了开始系统建模的输入，即前面定义的需求，

而（6）展示了这些需求和SoS组成部分之间的联系，

每一个方框图（1），即每一个SoS组成部分都具有的属性信息，

我们通过（7）中的构造型来表示。

至此，我们使用 MATLAB/Simulink 实现了如下图颜色部分所示的三个关键部分： SoS 需求定义，架构设计（System Architecture，SA），以及架构和需求的关联（追溯） 。

技术分析

我们知道系统工程一个核心任务是确定"做什么"，即在工程域对涉众需求进行完整且一致的描述，从而为下一步的设计和实现提供有效的输入。

确认（Validation），是我们保证这种完整性和一致性的主要活动。正如 ARP4754 中所阐述的，确认的方法可以包括：

追溯（Traceability），

分析(Analysis），

建模（Modeling），

测试（Test），

引用/类比（Similarity）

以及工程评审（Engineering Review）。 

追溯和建模的活动从前面的描述中我们基本已经看到其涵盖的内容，而测试、引用/类比（即基于其他工程的工程经验进行评估）、工程评审是我们当前比较常用的手段，在此我们看一下，在 MATLAB 工具具有的数据科学能力的基础上，我们在“分析”方面还能做哪些事情。

我们以分析机身为例看看怎么开展技术分析（Technical Analysis，TA）。

在这个示例中，假设我们已经确定是要在室内追踪一个泡沫球，当前设计的追踪装置是一个小型的、无人的飞行器，在这种约束下，我们发现货架（COTS）的可选飞行器类型是四旋翼飞行器。

进一步，经过调研，我们发现三种类型的飞行器可能满足我们的初步需求。我们通过图形化的方式，在模型中定义这三种飞行器，并通过构造型对这三种类型的飞行器进行特征描述，包括载荷容量、成本以及可编程的能力。

那么接下来，我们就要采用技术分析的手段，来看一下那种机身更符合当前的涉众需求。这时，我们使用“载荷成本”这个指标做为评价标准：

载荷成本 = 成本/载荷重量 * 可编程性；（具体的评价标准在工程实践中往往要进行科学的设计）

当我们把诸如载荷重量、成本支出以及可编程性等数据与前面提到的构造型建立联系后，即可开展这项成本分析。

从定量的分析结果上看，Crazepony Mini 和 Crazyfile 2.0 两款具有可编程性（2），而 Crazepony Mini 具有更低的成本（1）（每载荷重量下的成本）——90。

这样，基于这些量化的分析，我们可以比价科学的确定采用 Crazepony Mini 的机身设计方案。

随着系统复杂度的增加，我们需要评估和权衡的指标会变得越来越多，需要开展的技术分析也相应增多，而这些多样化、多角度的技术分析将为系统需求的确认提供更为科学的支撑。

系统分解与功能分配

下面，我们要将 SoS，即系统之系统的需求，也就是前面提的涉众需求，继续细化为对各个组成部分的需求，即都要使用什么样的系统来实现，每个系统完成哪些任务？ 即 Physical Allocation 和 Functional Allocation。

以当前这个示例的基础，我们要回答的问题就变成： 对于 AirVehicle 来说，从实物的角度看是由什么来组成（Physical Allocation），每个组成部分应该承担什么任务/实现什么需求（Functional Allocation）？

采用前面提到的需求确认的方法和手段，我们可以设计出最顶层的物理组成：

其中，Quacopter 的各个部分以及与功能的对应关系模型如下图所示，其中，经过前面的架构设计和需求确认相关的分析，我们已经能够细化出 Quadcopter 的需求

（1），进一步，将这些需求映射到 Quadcopter 的物理组件上

（2），这也对应着 Functional Allocation 的活动。

在进行 Physical Allocation 的时候，我们可以充分利用 MATLAB 提供的筛选功能，灵活的调整物理组件的实现形式。

下面就是基于构造型的筛选来构建 Physical Allocation 视图：

首先确认筛选条件

然后，由 MATLAB 自动化生成满足筛选条件的视图：

我们可以看到，Quadcopter 从物理实现的角度，主要由 Payload, Motors, IMU, Battery，OnboardProcessor（承载软件 SW）组成。

Physical Allocation 和 Functional Allocation 是一个持续交互的过程，需要持续不断的在不同的分配策略上做工程权衡，这种权衡有时能够直接根据专家判断得出结论，大多数情况下，需要我们不断的开展工程分析，利用工程分析来科学的指导设计。

系统验证

最后就是开展 SoS Verification 了，即需求的验证，也就是所实现的系统在多大程度上满足需求。

工程实践中的验证过程，往往也带有“确认”的属性，即在验证的过程中，进一步确认需求的完整性和一致性。

因为，虽然在理想的情况下，所有的需求应该在开发开展前进行确认，但实际的工程实践中，特别是当面对的是复杂和高度集成的系统时，直到待设计的系统进入到实际的运行环境，并开始运行和测试时，我们才能最终确认某些需求是不是合理、在工程上是不是可行。

所以，对于复杂系统的工程实现，我们基本上采用阶段性确认的方式开展需求确认，即在整个系统研发生命周期内，持续的开展确认活动，尽可能在每一个研发阶段开展确认活动，尽早的发现那些还有待完善、不一致的需求条目，从而达到减少设计迭代的目标（迭代的产生，要么是因为需求无法实现，要么是因为设计考虑不周）。

这样，测试或验证也会成为确认过程的一部分，这也是“ 持续的确认和测试 ”说法的由来。

以往我们经常在各个系统都已经实现，有物理样机了才能开始验证工作。现在，有了 MATLAB/Simulink，我们可以采用 仿真 的方式，在很早期还没有实物或只有部分实物的时候就开始验证工作。

我们可以对系统架构设计中的各个组成单元建立仿真模型，将整个待设计的系统使用可仿真模型进行表达，再进一步构建系统运行的外部环境模型，然后开展“验证”活动。

◆  ◆  ◆  ◆

至此，我们以一个非常简单的示例向大家简要展示怎样在 MATLAB/Simulink 下开展系统工程的各项活动。

限于篇幅和系统工程本身的复杂性，还有许多内容没能深入阐述，后面会有专门的文章更进一步和大家探讨。 非常期待您的反馈和意见，让我们共同探索系统工程的最佳实践。

◆  ◆  ◆  ◆

文章来源：matlab