达索析统公司的MBSE方法实践-MagicGrid

任何理论都需要实践。

而实践要经得起检验的方法是在实际工作中对那些使用该实践的项目成员有充分的指导性和充足的自洽，若此，则该实践方才有用。当然，达索析统公司的MagicGrid方法也不例外。

关于达索析统公司收购No Magic后及其所属CATIA品牌下的产品矩阵关系不在我们本次讨论范围，同样，达索析统原生的MBSE最佳实践 Modeling Methodology for Systems(简称，MMS)我们会另选时间详细分享。

 

在与国防，汽车，航空航天和高科技等各行各业的企业及组织合作时，大家需要一种明确的方法来使用SysML开发系统模型，SysML是国际系统工程理事会（INCOSE）定义的MBSE事实上的建模语言。当然，目前市场上有很多MBSE方法可供使用，而现有的方法对于解决现实世界的问题来说过于抽象。达索析统的MagicGrid方法恰好是通过总结和提炼众多企业在MBSE项目的最佳实践经验而来，所以，MagicGrid方法反过来又可以通过修改或扩展以灵活有效地支持特定客户需求。

何来如此底气呢？

因为默识在实际工作中，体会最深的就是MagicGrid方法的以下三方面在实践中得到了充分的验证：

 

• 它明确定义了建模框架(Framework)及详细过程，该过程又是基于行业中系统工程过程的最佳实践。
  

• 它与SysML完全兼容。绝大多数情况下不需要对SysML进行扩展。

• 它与工具无关，只要该工具支持SysML即可。
  

 

MagicGrid方法基于框架

---

是的，MagicGrid方法基于框架。首先，框架无论从支持复杂体系的系统系建模到具体的工程建模，乃至嵌入式软件建模，都是旨在指导工程师完成建模过程并回答他们的如下问题：

• 如何组织模型？

• 什么是建模工作流程？

• 什么模型工件应该在该工作流程的每个步骤中生成？

• 这些工件如何链接在一起等等问题？
  

所不同的是，这样的框架按照系统的复杂程度、受众和外延边界，也同样存在不同层级和对应的相应实践。例如，全球信息栅格(也有称为宫格、矩阵的)体系结构(简称，GIG)，这是在系统系的级别和角度构建的框架，提纲挈领。（注：图片拍自《体系结构设计方法的发展及应用》，梁振兴、沈艳丽编著）；

也有软件工程领域的RUP框架，知微见著。

还有现在的敏捷开发(图片拍自《用户故事地图》，作者是Jeff Patton,李涛等翻译)。

而MagicGrid恰好是涵盖了以上不同维度和复杂度的方法实践，即可以面向系统工程，也可以裁剪后适用于敏捷开发，它的组织和表现方式如下图所示，对我们大家来说，应该不陌生。

如您所见，该方法包括MBSE中问题领域、解决方案和实现域的定义。它们与ISO / IEC / IEEE 15288定义的流程一致：问题域与利益相关者需求开发流程，解决方案域与架构定义流程，以及实现域与设计定义流程。

每个域都表示为MagicGrid框架的单独一行。

• 其中表示问题域的部分被分为两部分，以表明应该通过从黑盒中查看感兴趣的系统（SoI,System of intrest）然后从白盒的角度来定义问题域。

• 表示解决方案域的部分被分成许多行，以表明可以在多个详细级别中指定系统的解决方案体系结构。

• 表示实现域的行没有拆分，也不像上面的行那样完全突出显示，以表明除了此域中的物理需求规范之外，其他所有内容都不是MBSE的一部分，因此这些栅格元素表示为在MagicGrid方法的范围之外。
  

 每个域定义包括要在模型中考虑和捕获的系统的四个不同方面。这些方面与SysML的四大支柱(PILLAR)相匹配，即需求，行为，结构和参数（也称为指标）。它们表示为矩阵的列。

                       

某行和列交叉处的单元格表示系统模型的视图，该视图可以包含一个或多个可以展示的工件。 展示工件可以是图表，矩阵，地图或表格。

 

注意，虽然权衡分析(Trade-Off)没有在MagicGrid方法框架中显性表达，但是在架构设计或详细建模中我们经常要考虑针对某个问题去提供多个解决方案时，就一定会用到它，而且这是经常性的。 在这种情况下，执行权衡分析以选择用于实现的最佳解决方案。

问题域

---

问题域定义的目的是分析利益相关者的需求(Needs)并使用SysML模型元素对其进行优化和分析澄清，以便清楚、一致地描述SoI必须解决的问题。如下表所示，问题域分析分两个阶段进行。

在第一阶段，SoI被认为是一个黑盒子，主要关注的是它如何与系统的周边环境相互作用而不了解其内部结构和行为。换句话说，执行的是针对的SoI的操作分析。

在第二阶段，打开黑盒子，从白盒的角度分析SoI，这有助于详细了解系统的运行方式。换句话说，执行SoI的功能分析。

同样重要的是要注意问题定义不包括SoI的物理体系结构。

问题域定义的两个阶段都包括分析SoI的需求，行为，结构和参数。唯一的区别在于透视。即在相关页面中逐步描述问题域中的建模视角不同。

解决方案域

---

一旦完成问题域分析并将利益相关者的需求转移到模型中，就该开始考虑解决方案了。 解决方案体系结构定义了系统逻辑设计的精确模型，甚至包括它的几种变体(与产品线有关)。 换句话说，这个抽象层为第一个抽象层中定义的问题提供了一个或多个解决方案（包括黑盒和白盒透视图）。 

有几种解决方案，就可以进行与之对应的多种权衡分析，以选择实施该系统的最佳方案。

在定义了整个系统的解决方案体系结构并选择了最佳系统配置之后（通过权衡分析），系统已准备好实施。 此时的系统已经从抽象演进为真实的，我们可以借助一维仿真对架构的逻辑正确性进行仿真了。

实现域

---

正如在下表中所看到的，MagicGrid框架仅部分涵盖了实现域。 该方法定义了正在实施的系统的物理需求规范，但其详细设计不是MBSE的一部分，也不是MagicGrid方法的一部分。 该系统的详细设计是基于模型的设计（MBD）的一部分，可以使用电气和机械CAD软件，如果针对ESW(嵌入式软件)，则进入详细设计领域并/或由自动代码生成工具等工具进行开发，这也正是体现机电软高度协同工作的一个重要环节。

总结

---

MagicGrid方法的每个域都表示为MagicGrid框架的单独一行。

• 其中表示问题域的部分被分为两部分，以表明应该通过从黑盒中查看感兴趣的系统（SoI,System of intrest）然后从白盒的角度来定义问题域。

• 表示解决方案域的部分被分成许多行，以表明可以在多个详细级别中指定系统的解决方案体系结构。

• 表示实现域的行没有拆分，也不像上面的行那样完全突出显示，以表明除了此域中的物理需求规范之外，其他所有内容都不是MBSE的一部分，因此这些栅格元素表示为在MagicGrid方法的范围之外。

文章来源：默识沙龙