MBSE建模学习之十一：MBSE方法论及MagicGrid方法

方法论，即方法的理论。宏观上讲，是人们认识世界、改造世界的方法的理论。MBSE方法论，是如何应用建模语言，按照什么样的流程建立系统模型，以实现建模目的一套通用的理论方法。每种MBSE方法，涉及到用什么建模语言、建模流程、模型的基本架构等等。而且，由于MBSE的建模方法要通过软件工具实现，所以和具体的软件工具也是紧密相关的。首次提出方法论的公司、机构也都希望自己的方法能够成为行业的主流方法，并不排斥其它公司的软件实现自己提出的方法。所以，同一种方法是可以在多个软件中应用和实现的。

MBSE方法论是MBSE技术三大支柱之一。详细且全面论述MBSE方法论的文章是INCOSE在2008年的一个调研报告“Survey of Model-Based Systems Engineering (MBSE) Methodologies”，（中文翻译《基于模型的系统工程（MBSE）方法论综述》）。由于方法论和软件工具是紧密关联的，而MBSE建模软件在日新月异的不断改进，所以这篇文章我觉得只是了解参考即可，没必要去花费好几千去买这本已经绝版的书了。

参考各种资料，MBSE的建模方法有如下这些：

● 达索公司（收购No Magic）提出的MagicGrid方法（MagicGrid1.0、MagicGrid2.0）；

● Hoffmann和Hans-Peter提出的IBM Harmony-SE、aHarmony-SE方法；

● Friedenthal、anford等提出的INCOSE面向对象系统工程方法（OOSEM方法，基于SysML语言）；

● Vitech公司提出的基于功能分析的方法，实现软件工具：CORE，建模语言：System Definition Language (SDL)；

● JPL（Jet Propulsion Laboratory）提出的 State Analysis(SA)法，软件工具：State Database，建模语言：SQL；

● Dov Dori提出的对象过程方法（OPM），建模语言：OPL（Object-Process Language），软件工具：OPCAT；

● Weilkiens、Tim等提出的Weilkiens系统建模方法；

● Thales公司提出的Thales Acradia方法。

MagicGrid是No Magic公司(被达索收购)提出的基于SysML的MBSE方法论。Magic Grid建模方法基于SysML语言，支持SysML语言的建模工具都可采用。

MagicGrid建模方法基于框架来表达，框架可以表示为一个矩阵表格（这个矩阵表格的方法来源于体系工程的提出者Zachman提出的表格。智睿思维基于模型的系统工程软件已经支持DoDAF等体系工程建模，有需要可联系18022886980）。如下图所示，旨在指导工程师完成建模过程和回答它们的问题，例如，“如何组织模型？”“什么是建模流程？”“在建模流程的每一个步骤中应生成哪些模型？”“这些模型如何关联？”等。

3.1 问题域建模

问题域定义的目的是分析利益相关者需求，并使用SysML模型元素对其进行细化，以清晰、一致地描述系统必须解决的问题。问题域分析分两个阶段，第一阶段，系统被认为是一个黑盒子，主要关注其如何与环境交互，而不必了解其内部结构和行为。第二阶段，打开黑盒，从白盒的角度分析系统，进行系统的功能和架构分析。问题域定义的两个阶段都包括系统的需求、行为、架构和参数，区别是两个阶段的视角不同。

3.2 解决方案域建模

解决方案域模型定义了系统逻辑设计的精确模型，也可以定义系统设计的几个不同方案。换句话说，解决方案为问题域中定义的问题提供了一个或多个解决方案。在有多个解决方案的情况下，可以进行权衡分析，选择系统实现的最佳方案。对于一个大型的复杂系统，往往问题域由一个部门负责设计，解决方案可能由另一个部门负责。

解决方案域模型包括系统需求、行为、架构和参数。构建解决方案模型通常需要多次迭代，从系统级到子系统级，从子系统级再到组件级，甚至更深层次。解决方案模型可以为一个单独的项目模型，也可以和问题域模型定义在同一个项目模型中。然而在大多数情况下，解决方案模型的范围和复杂性超过问题域好几倍，特别是当它包含多个解决方案时。在两个或多个单独的项目模型中定义解决方案模型有助于解决管理的复杂性问题。此外，这种划分能够实现更细粒度的模型数据权限管理，能够实现变更分析和控制，以及开发、修改和重用。

利益相关者需求分析

依据图3.1中的建模工作流示意图，从问题域的黑盒开始。黑盒是以高层次的视角从整体来审视系统，黑盒中的系统上下文、用例场景，都体现了这一点。首先应该进行利益相关者需求分析，组织B1-W1模型，如图4.1所示。

系统上下文分析

通过分析B1-W1模型中捕获的利益相关者需求，可以识别系统上下文。通过分析利益相关者对车辆气温控制的需求，能够识别系统上下文为“在用车辆”。创建SysML内部模块图来指定“在用车辆”系统上下文中的构成。在这个内部图中，在用车辆上下文包括“空调设备”和执行者“汽车乘员”。同时，系统上下文中需要一个为系统提供能量的外部系统“能量供应”模块，如图4.2所示。

用例场景分析

接下来使用用例来完善功能性利益相关者需求。用例场景可以应用SysML活动图或序列图详细的建模。以“获得舒适的温度”用例场景为例，应用图4.3所示活动图进行详细场景的描述。 当模型中有了获得舒适温度用例的整个场景后，可以指定相关系统上下文的某个组成部分负责执行某个操作，也就是将行为分配给上下文中的结构。对此，可以使用分配活动分区来表示系统上下文的组成部分。分配活动分区代表的元素是系统上下文的部件属性。

系统性能指标分析

依据MagicGrid框架的结构，在B4模型中，对性能指标进行分析。如图4.4所示，将表示“总质量”和“噪音水平”的性能指标建模为一个容器类的值属性，并应用“效能度量”构造型（«moe»）。通过建立系统到这个容器类的继承关系，可以将这些表示性能指标的值属性传递到系统的任何层次结构。

系统功能分解及分析

依据黑盒中的方法分析完后，接下来使用白盒来进行分析。白盒是对系统做进一步的分析，从更深入的角度对系统的功能、架构进行建模。在W2模型中，进行功能分析。例如，把用例活动场景模型中分配给系统的活动作为系统的顶层功能再进一步分解。例如“达到需要的温度”活动，可以通过建立它的下层活动图，分解为“准备系统”、“加热”、“制冷”、“转换数据”、“显示数据”。如图4.5所示：

逻辑架构定义和接口分析

在W3模型中，对逻辑子系统之间的通信接口关系进行分析。组成空调设备的逻辑子系统主要包括：控制系统、制冷制热系统、接口系统，如图4.6所示。在这个图中，外框代表“空调设备”，外框上的端口连接到内部部件属性节点上的端口，使用绑定连接器。端口的接口模块类型一样，它表示外层端口和内层部件属性节点上的端口其实是同一个东西。“代理”的意思，就是外部的端口是虚拟的，其实是有内层部件上的端口（或一个模块）实现的。不同的部件属性节点之间的连接关系，端口的接口模块类型是“共轭”的，表示接口模块中的流属性类型相同，但是方向相反。例如，控制信号从一个端口发出（流出），对应另外一端必须是接收（流入）。

解决方案域分析

创建系统需求图，如图4.7所示。系统需求是系统实现方案的条目化说明。它是在经过详细的系统功能分析、逻辑架构分析基础上，总结出的更明确的设计要求。为了跟踪需求的实现过程，应该创建导出需求矩阵，建立系统需求到利益相关者需求的追溯关系。在理想情况下，每个系统需求都必须在后续的解决方案域模型中得到体现，并且每个元素都必须根据一个或多个系统需求来优化。否则，必须修订和更新系统需求。

系统顶层架构设计

接下来对系统架构进行初始化分析，通过创建模块定义图（BDD）建立空调设备的顶层解决方案架构及子系统。子系统由制冷制热系统、控制系统、传感系统和接口系统组成，如图4.8所示。图中也定义了每个子系统的端口和接口模块类型，作为总体架构的设计标准。

子系统解决方案设计

接下来对子系统架构进行分析，以构建制冷制热系统的解决方案架构为例，如图4.9所示。子系统由更下层的组件组成，子系统的内部模块图说明这些组件的连接关系。外框表示的是子系统，外框上的端口是从顶层解决方案架构中的子系统继承的，原则上是不能改变它们的接口模块类型，以保持和顶层解决方案设计的一致性。在连接端口的连接器上，黑色的三角箭头表示连接器上流过的“项目流”，表示在两个组件之间传递的信号或某种物理量。

下面继续对子系统行为进行分析，进行子系统功能的设计。可通过建立子系统的状态机图，详细分析子系统工作状态的变化过程。并通过状态的内部行为，将整个子系统的功能活动串联起来。如图4.10所示，制冷制热系统的状态机模型如下。状态之间的转换可以由各种类型的事件触发，如时间变化、调用操作或信号事件等。大多数制冷制热系统状态之间的转移是由信号事件触发的。而每个状态内部也不是静止的，可能会有entry(进入)、do（执行）和exit(退出)行为，这些行为可能是另外一个表示功能的活动（图）

系统集成和总体性能指标的验证

在所有子系统解决方案设计完成之后，需要验证子系统设计方案之间的接口关系是否相互匹配，这个工作可以通过建立一个包括所有子系统的顶层配置模块，通过建立这个顶层配置模块的内部模块图来验证。

另外一个集成验证的工作是各子系统的性能指标合成后的系统性能指标是否满足系统需求中的性能需求。这个通过建立顶层系统配置模块的参数图、参数图仿真来验证。如通过下面建立的子系统质量和系统总质量之间的加和关系约束方程，以及参数图来进行系统总质量的计算。参数图的作用本质上是把系统中某个值属性代入到约束模块的约束方程中进行计算。等式形式（一个=号）的约束在参数图仿真时起到了赋值的作用，而不等式（或两个=号）的约束在参数图仿真时起到了验证计算出的性能指标是否满足要求的作用。计算空调设备总质量的参数图如图4.11所示：

通过参数图的仿真计算，能够计算出系统的总质量数据，并根据上图中“{tm<=25}”约束，对总质量是否满足需求进行自动的验证（下图仿真结果变量表中绿色表示满足约束，红色表示不满足）。

本文介绍了MBSE一般的建模流程，但实际的建模工作却并非总是按照这个流程。根据笔者的实践，大多情况下是在一个基本模型框架下，从资料最明确的地方开始着手。例如，也不一定是先有利益相关者需求，再去进行用例场景的分析。而往往是有个基本需求，然后通过应用场景分析，不断的丰富和完善利益相关者需求。而很多系统的架构方案也是基本明确的，可选择性并不多，先确定系统架构，再去分析功能及接口关系，也是经常会采用的方式。MagicGrid方法论，也可以根据具体应用场景、系统所处的产品层级进行裁减。

另外MagicGrd方法论也在不断发展，如今已有2.0版本。MagicGrid 2.0版的流程如下图所示。其主要改变是将“架构”这一列调整到“行为”前面，从左到右的顺序更统一一些。另外也有将“可靠性”作为新的支柱增加到MagicGrid方法网格中的。智睿思维基于模型的系统工程软件MBSES（企业版）已经有MagicGrid2.0方法，有需要的朋友可以加微信索取试用版（18022886980）。