MBSE架构图：一种集成系统建模与多学科分析的MBSE开发框架

随着大型、复杂系统的发展，系统工程方法被用于管理系统的复杂性，并确保交付的系统能满足所有需求。MBSE是一种通过使用系统模型改善传统的基于文档的系统工程的方法。SysML是一种图形化的建模语言，作为一种国际标准支持MBSE。使用SysML定义的系统工程模型本质上是描述性的，不直接产生分析结果，将导致系统工程活动和工程分析之间存在着巨大的差异。因为系统工程师和工程分析师使用不同的模型、工具、方法和术语，他们不得不依靠特别的通讯和人工翻译的设计规范和数据。这种差异导致了效率低下并需要花费昂贵代价去修复质量问题。因此，迫切需要将SysML模型与分析模型连接起来。

图1 系统模型与领域分析模型的差异

目前， SysML建模工具内部的系统级分析通常仅限于对简单参数方程式的评估。这意味着尽管SysML模型能够详细地描述一个给定的系统配置，却很难恰当地评估设计与需求的契合度或对性能、成本和风险执行重要的权衡分析。因为缺乏便利地可获取的分析能力，使得系统工程师很难快速地了解需求和系统配置不可避免的变化带来的后果，并采取必要的行动。

另一方面，域/多学科工程师(结构、热力、电力、软件、成本等)通常使用各种先进的分析工具来分析和设计系统。因为这些工具没有连接到系统模型，很难使用系统模型设置分析问题或使用分析结果更新系统模型。如果可以填补这个空档，域/多学科工程师可以使用MBSE数据存储库获取所需的设计信息去创建他们的分析模型，并进行分析以支持系统开发。使用此功能，域/多学科工程师可以减少多学科建模和分析活动中由于手工数据转换和失效信息的使用所导致的常见错误和修正工作。

将建模和分析集成的功能弥补了以上缺陷。这种技术方法是将SysML建模工具与过程集成和优化设计框架（Process Integration and Design Optimization，PIDO），如Model Center，进行集成。这种方法的优点是使用PIDO框架提供的通用接口将SysML与各种工程分析工具连接，如CAD / CAE，遗留代码，数学解算器和电子表格等。此方法具有从系统模型自动生成分析模型，然后执行分析模型的能力。集成的工具套件允许工程师使用现实的分析模型快速评估系统配置并自动检查需求的一致性。

本方案旨在开发集成的建模和分析功能，它将支持系统工程师和领域/多学科工程师的不同视角。系统工程师主要关注系统架构和系统级的权衡，并不一定对工程分析的细节感兴趣。另一方面，领域/多学科工程师负责创建工程分析模型，它可以准确地代表当前设计但不需要理解SysML模型的细节。集成的工具套件使用一种常见的图形用户界面，可以从SysML工具(为系统工程师)或者从PIDO框架(领域/多学科工程师)运行，允许工程师用他们熟悉的工具和环境进行工作。它允许设计团队在整个设计过程中执行连续的设计、分析和权衡研究，并且可以对需求和设计配置的变化做出快速响应。下图给出了整体方案架构及流程。

图2 整体MBSE集成方案架构

此方案从需求出发（需求可以来自Excel或者Doors等），将需求导入到Sysml建模工具（如IBM Rational Rhapsody或NO Magic Magic Draw等），使用Rhapsody或Magic Draw创建系统架构，使用领域专业工具建立分析模型，在SysML参数图中将系统模型与分析模型建立连接，使用Model Center的MBSE Pak建立中间连接层，执行权衡分析等，并将分析后的结果反馈到描述模型以更新模型。

2

集成建模和多学科分析的方案需要基于一些通用的原则。首先，需要具备支持不同抽象级别的模型。SysML提供了许多建模构图来支持抽象模型，但模型的抽象需要包含多学科分析模型。第二，需要寻求通用系统工程模型和领域特定模型之间适当的平衡，因为他们有各自的优缺点。SysML在定义系统架构和关系时非常有用，也需要结合很多专门特定领域的建模和分析工具。相比通用的SysML模型，领域特定模型可以更有效地准确地描述系统的特定方面。第三，工程分析需要更好的与整体系统开发的上下文关联。因为当执行一个复杂的系统的分析时，不能很好的把握大局。第四， 在创建模型时需要结合自顶向下和自底向上的方法。SysML模型通常使用自顶向下方法创建，从高度抽象演变到更多细节。但SysML模型可能基于负责创建分析模型的领域/多学科工程师的输入去做更新。

3

根据图2给出的整体MBSE集成方案架构，将通过以下六个主要步骤完成整个建模与分析过程。此模型框架建模步骤包括：

1) 生成需求图及系统架构；

图3 创建需求和系统架构

a) 最初的需求规格可以是用DOORS/Excel进行描述，将早期的需求规格说明导入到Rhapsody/MagicDraw中，创建需求图，在需求图中包含相应指标的上下限以及需求目标。

图4 建立需求图

b) 基于需求生成系统架构，定义SysML原型，使用SysML的BDD图对系统架构进行描述。

本方案中，将SysML进行了扩展来描述建模分析组件，这些组件运行在ModelCenter框架。下图给出了配置属性中定义的原型。MC_Component原型用于指定一个约束模块(例如，分析块)的可执行的分析模型的位置。MC_Variable 原型来创建SysML端口(例如，参数)和分析模型变量之间的映射。InOut枚举来指定由MC_Variable原型实例化参数(输入或输出)的因果关系。在这个功能中，工程分析被用于自动检查需求的一致性。为了达到这个目的，RequirementVerification模板可以应用于需求块。

图5  定义SysML 原型用于连接SysML模型和工程分析

下面通过一个汽车刹车片设计的示例来描述这种方法。我们的目标是设计一个刹车片，需要满足几个性能需求，如刹车距离、生命周期、刹车过程中产生的热量等。下图是系统分解的SysML块定义图。用SysML中的blocks代表系统的物理实体，每个block都可以有值属性。图中箭头代表整体与部件的关系。例如，brake包含rotor，caliper和pad这些部件。在这个示例中， c++程序和Excel电子表格被用来计算性能和刹车片的成本。

图6  系统分解(SysML BDD)

2) 将系统架构与需求进行连接，在参数图中建立属性与分析模型的连接。

a) 先将系统架构与需求进行连接，建立可追溯性，连接系统性能属性与需求，在Rhapsody/MagicDraw中建立satisfy关系。

图7 设置使用Model Center提供的扩展属性

将需求模块的Applied Stereotype设置为PropertyBasedRequirement，这些是MBSE Analyzer对SymML 的扩展属性。

图8 使用“satisfy”关系关联系统属性和需求

本方案的目标之一是利用工程分析来检查需求规格合规性。该方案使用的方法是，用文本描述需求，然后给每个需求附加上下限。SysML 标签被用来给需求添加上下限。图8给出了刹车片生命周期的需求，标有一个LowerBound的标签。该需求通过satify关系连接到“life”参数。如果“life”参数的值比下限低，则不满足需求。此方法具备自动检测需求一致性的功能。如果需求不满足，则会在图中自动高亮显示一个红色的“X”。

b) 创建SysML参数图

SysML参数图用于指定系统属性之间的定量关系。参数图使用分析模块(即约束块)，表示模型中系统属性之间的物理或逻辑关系。然而，约束块的原有功能是有限的代数方程。为了克服这个限制，SysML约束块被扩展，使它们指向一个黑盒分析模型，这些分析模型可以是脚本、电子表格、CAD / CAE工具，或遗留分析代码。本方案中，分析模型分布在分析服务器上，它能够共享工程分析并远程运行它们。每个分布在分析服务器的黑盒分析模型通过一个URL识别。

下图展示了刹车片成本分析的约束块。该成本分析是基于一个使用Analysis Server封装的Excel电子表格。MC_Component原型的url标记制定了封装分析的位置。

图9 使用SysML原型定义一个黑盒分析的URL位置

每个约束块都带有参数，如下图参数分隔区所示。代数方程通常用来定义参数之间的约束。在此案例中，约束块是用黑盒分析替代方程。每个黑盒分析有一组输入和输出参数。除了简单的分析关系，想要改变黑盒分析参数的因果关系(输入/输出)是不容易的。因此，每个参数的因果关系是在相应的黑盒分析中显式地定义的。如上图所示，MC_Variable原型是用来定义参数的因果关系以及默认值。

图10 在SysML参数图中建立属性与分析模型的关系

约束模块是SysML中可重用的分析模块。参数图可能使用多种约束块来定义更加复杂的解析关系。上图是一个刹车片示例的参数图。该图使用了四个约束块包括基于Excel电子表格的成本分析和刹车片的分析，卡尺， 和基于c++程序的刹车距离。每个约束块通过MC_Component原型实例化，并使用一个图标，表明此约束块隐藏的分析模型的类型。

参数图中的绑定连接器(Binding connectors)代表系统属性之间的平等关系。可以在系统属性和参数之间或者参数之间创建绑定连接器的参数。原则上，平等关系是非因果的，绑定连接器在输入和输出参数之间没有区别。为了解决带有非因果关系的参数图，需要处理一个系统方程组。然而，这种方法仅限于简单方程式的使用，当使用黑盒工程分析时是不适用的。在此案例中，因此，每个约束块的参数根据参数在黑盒分析中的使用，显式地定义为一个输入或输出。上图中的约束块使用约定的布局，将输入和输出参数分别置于约束块的左边和右边。

3&4) 建立系统模型与分析模型之间的连接层

图11 从系统层到专业层

图10中定义的参数图包含创建一个分析模型所必要的信息，这些分析模型可以通过PIDO框架执行。在Model Center中约束块被转换成分析组件，绑定连接器被转换成分析组件变量之间的链接关系。这种功能可以从参数图自动创建一个分析模型。该功能是PIDO 框架的一种SysML插件。这种转换是通过使用SysML工具和Model Center的API，而不依赖形式化的模型转换。SysML插件允许选择参数图，并自动生成一个分析模型。图12显示了从参数图生成的多学科分析模型。一旦创建了一个相关联的分析模型，插件会自动列出参数图中（图13）中使用的系统属性。用户可以改变输入值并运行分析不同的系统配置下的性能和成本指标等。

图12 使用Model Center MBSEPak建立连接关系

图13 参数图中使用到的SysML参数列表

值得注意的是，自动生成的模型是连接到SysML模型的。这种方法允许使用SysML模型作为工程分析设计信息的权威来源。输入参数值使用SysML模型中定义的值进行初始化。这使得领域专家可以迅速建立分析模型，避免了手工数据转换潜在的错误。这种方法还使得它易于使用的工程分析的结果来更新SysML模型。SysML插件提供了一个能够使用从分析模型计算得出的新值更新SysML模型。另一个优点是，PIDO工具包含权衡分析工具，可以用来评估许多设计方案。当找到一个最优设计后，可以用于更新SysML模型中的当前设计。

图14 SysML 插件执行从参数图自动生成的分析模型

5)执行权衡分析及优化空间探索

图15 执行权衡分析

对于成本、性能、风险等变量，可以使用Model Center进行权衡分析及优化空间探索以找到最优方案。

图16 使用DOE工具进行权衡分析

图17 在model center中执行权衡分析

6）基于分析后的新的设计参数更新系统模型

图18 更新系统模型

通过权衡分析，优化设计参数之后，基于新的设计参数，MBSE Analysizer可以自动更新Rhapsody/MagicDraw系统模型并验证新的数据是否满足性能需求。

图19 自动更新系统模型

4

工具和技术的发展弥补了系统工程模型和工程分析之间的差异。本方案通过执行一个PIDO框架Model Center，将SysML系统模型与工程分析模型相连接实现的。该技术的关键是从SysML参数图自动生成分析模型。使用了 SysML建模技术将相关参数图与块联系起来。可以为SysML模型中选定的对象快速识别适用的分析，并有选择地同时处理一个或多个参数图。集成的工具套件允许工程师使用真实的和准确的分析模型快速评估系统配置。通过在SysML模型以及它们的可追溯性系统属性中指定工程分析，SysML模型提供了一个完整的系统模型和工程分析之间的关系。

该集成方案还可以使用工程分析模型检查系统需求。不满足的要求自动高亮显示，以便工程师可以采取必要的行动。此功能提供了一个在提交设计变更之前检测到潜在问题的机会。使用这种集成方案，设计团队可以迅速应对不可避免的需求或设计配置的变化。加上Model Center工具中包含的权衡分析工具，具备执行连续分析，仿真，以及贯穿整个设计过程的权衡分析的能力。

参考资料：

[1] Kima H., D. Frieda, P. Menegaya, G. Soremekuna, C. Osterb,”Application of integrated modeling and analysis to development of complex systems”, Procedia Computer Science   16  ( 2013 )  98 – 107. Available online at www.sciencedirect.com.

[2] Kima H.,” Integrated Model Framework for Concept Development”, Model Center 2015 User’s Conference MBE April 14, 2015.

[3] Phoneix Intergration,Inc.,Model Center Introduction,

See aslo ” https://www.phoenix-int.com”.