下载文档原格式
基于模型的系统工程方法论引言在科技不断发展和实践的推动下，系统工程方法论作为一种跨学科的综合性方法，已经成为驱动创新和解决复杂问题的重要工具。
基于模型的系统工程方法论是系统工程方法论的一种重要分支，通过建立模型来描述和优化系统的行为和性能，从而实现有效的系统设计和管理。
本文将探讨基于模型的系统工程方法论的基本原理、流程和应用，以期更深入地了解和应用这一方法论。
什么是基于模型的系统工程方法论基于模型的系统工程方法论是一种系统工程方法论的具体应用，其核心思想是通过建立和利用模型来理解和设计复杂系统。
模型是对系统的抽象表示，可以是数学模型、物理模型、仿真模型等。
基于模型的系统工程方法论强调系统工程师将系统问题具象化为模型问题，并通过模型分析和验证来推导解决方案。
基于模型的系统工程方法论的基本原理基于模型的系统工程方法论有以下几个基本原理：1. 抽象和建模基于模型的系统工程方法论的第一个基本原理是抽象和建模。
通过抽象，系统工程师可以将系统问题简化为模型问题，从而消除系统复杂性带来的困扰。
建模是将系统的实体、行为和关系用模型来表示，可以是数学方程、图表、图形等形式。
通过抽象和建模，系统工程师可以更清晰地理解系统，准确地描述系统的需求和性能。
2. 集成和协同基于模型的系统工程方法论的第二个基本原理是集成和协同。
复杂系统由多个部分组成，它们之间存在着复杂的相互作用和依赖关系。
通过建立模型，系统工程师可以将系统的各个部分集成在一起，形成一个整体。
集成不仅是将各个部分连接在一起，还要解决各部分之间的接口问题，确保系统的协同工作。
3. 管理和优化基于模型的系统工程方法论的第三个基本原理是管理和优化。
通过建立模型，系统工程师可以对系统进行管理和优化。
管理是指对系统的整个生命周期进行有效的规划和控制，包括需求管理、变更管理、配置管理等。
优化是指通过分析模型，找到系统的瓶颈和潜在问题，并提出改进措施。
通过管理和优化，系统工程师可以提高系统的性能和可靠性。
MBSE（基于模型的系统工程）实践案例包括以下几种：
1. **美国宇航局喷气推进实验室（JPL）**：JPL已经将MBSE成功应用于实际项目的系统工程问题，覆盖了项目类型、项目活动和生命周期阶段。
例如，在火星2020探测车、Orion、欧罗巴卫星、欧罗巴快船、地球观测卫星SMAP等项目中应用了MBSE。
这些项目涵盖了多领域的机器人太空探索，如火星、太阳系、系外行星、天体物理学、地球科学和星际网络。
2. **军事系统研制**：采用MBSE方法进行系统研制，在设计阶段早期，应用建模和仿真手段实现需求的早期验证，保证设计过程的正确性。
MBSE持续贯穿整个武器系统的生命周期过程，开展体系建模、系统建模、专业领域建模，实现系统整个设计过程的模型化表达，并采用模型仿真手段，提升需求分析和验证能力，降低型号验证风险。
这些案例显示，MBSE在复杂系统的设计、开发和验证中具有显著的优势。
它能够提供一种直观、可追溯的模型表示形式，使各方更好地理解系统的整体结构和行为，提高设计的可靠性和有效性。
谈谈MBSE--基于模型的系统工程(图片来自网络)文/侯哥1.最近几年，系统工程的概念越来越火热。
其中MBSE是目前最受大家推崇的，也可以说是最时髦的。
在复杂系统的开发领域，如果你不能说出一些跟MBSE有关的一些词儿，那么你是无法号称自己站在时代前沿的。
国外把基于MBSE视为系统工程的“革命”、“系统工程的未来”、“系统工程的转型”等。
国内的很多大型组织也已经在开展了相关研究和应用了。
其中，包括大飞机和汽车等复杂的系统设计。
在汽车的开发，尤其是汽车的电气架构开发领域，MBSE已经被越来越多的公司所引入，并且通过使用相关的软件工具，把MBSE应用到电子电器开发的各个领域。
包括用户场景的描述、功能的开发、系统的详细设计和相应的测试验证。
由于现在已经有了直接把模型转换为代码的工具，所以，很多OEM可以通过MBSE的使用，具备或提高了一定的上层应用软件的开发能力。
以前的文章介绍过SDV（软件定义汽车）的概念，无论是否达到了SDV的阶段，OEM开发部分软件已经是一个明显的趋势和不争的事实了。
而MBSE的应用和推广必将助力OEM和整个行业的软件质量的提升和开发速度的提高。
有个大佬曾经说过：MBSE下，工程研制工作由过去的“80%劳动、20%创造”转变为“20%劳动、80%创造”。
为啥呢？一句话：MBSE可以让工程师更多的时间投入在设计中，而不是文档上。
2.那么MBSE究竟是何方神圣？今天给大家介绍一下相关的概念，让大家有一个初步的认识。
MBSE是Model-Based SystemsEngineering的缩写，翻译成中文就是：基于模型的系统工程。
这里面有三个关键词：模型，系统和工程。
模型是一个含义丰富的词。
在MBSE里，特指描述待研究的对象，把待研究的对象的一些特性抽象出来，并使用标准化的表达方式来进行描述，从而能够进一步进行研究的一种形象化的表达方法。
工程这个词就不需要解释了。
什么才是“系统”呢？系统的定义：系统是由两个以上有机联系、相互作用的要素所组成，具有特定功能、结构和环境的整体。
基于模型的系统工程最佳实践
在现代系统工程中，基于模型的方法已经成为了一种重要的工具和最佳实践。
这种方法通过使用模型来描述和分析系统，帮助工程师们更加有效地设计、开发和维护复杂的系统。
基于模型的系统工程最佳实践包括以下方面：
1. 采用适当的建模语言和工具
选择适当的建模语言和工具是基于模型的系统工程的关键。
不同的系统和应用场景需要使用不同的建模语言和工具，以便能够更好地描述和分析系统。
一些常用的建模语言包括UML、SysML、MATLAB和Simulink等。
2. 建立全面的系统模型
基于模型的系统工程需要建立全面的系统模型，包括系统的结构、功能、性能和接口等方面。
通过建立全面的模型，可以更好地理解系统的行为和交互，并且能够更快地发现和解决问题。
3. 利用模型进行系统分析和优化
通过模型，可以进行系统分析和优化，以寻求系统的最佳性能和效率。
例如，可以使用仿真工具对系统进行模拟，以便发现和解决系统中的问题和瓶颈。
4. 采用模型驱动的方法进行软件开发
基于模型的系统工程可以采用模型驱动的方法进行软件开发。
这种方法可以将开发过程中的模型和代码密切结合，以便更好地管理和维护软件系统。
基于模型的系统工程最佳实践已经在许多领域得到了广泛的应用，包括机械、电气、航空航天和汽车等工业领域。
这种方法不仅可以提高系统开发的效率和质量，还可以帮助工程师们更好地理解系统的行为和交互，从而更好地满足用户的需求和期望。
基于模型的系统工程(mbse)方法论综述概述说明1. 引言1.1 概述引言部分主要旨在介绍本篇长文的主题——基于模型的系统工程（MBSE）方法论，并概述文章的结构和目的。
MBSE是一种系统工程方法论，通过建立和使用模型来描述、分析、设计和验证系统，以提高系统开发过程中的效率和质量。
1.2 文章结构本文将按照以下结构展开对MBSE方法论的综述。
首先，我们将对系统工程和模型驱动工程进行简介，为读者提供一定背景知识。
接着，我们将详细探讨MBSE 方法论的定义与特点。
随后，我们将重点关注MBSE方法论中的三个关键要点：模型建立与表示、模型验证与验证以及模型驱动设计与开发。
最后，在应用层面上，我们将通过案例分析来展示MBSE方法论在不同行业领域中的应用情况。
最后一部分是结论与展望，在此部分我们将总结文章中阐述的观点和发现，并对MBSE方法论未来发展进行展望。
1.3 目的本文旨在全面回顾和概述基于模型的系统工程（MBSE）方法论，并探索其在实践中存在的关键要点和挑战。
同时，本文也将通过应用案例分析，展示MBSE 方法论在不同行业领域中的应用情况。
通过阅读本文，读者可以深入了解MBSE方法论的定义、特点以及其对系统工程过程的价值和影响。
最后，我们希望能为读者提供对MBSE方法论发展趋势的展望，引发更多关于此领域未来可能性的思考。
2. 基于模型的系统工程方法论概述2.1 系统工程简介系统工程是一门综合性学科，它解决了复杂系统设计和开发过程中遇到的各种问题。
它通过从整体上考虑、分析和优化系统的需求、功能、结构和性能，以及在整个生命周期中管理系统各个方面的交互作用，实现了有效的系统集成与开发。
2.2 模型驱动工程概念模型驱动工程（Model-Driven Engineering, MDE）是一种软件开发方法，其核心理念是将模型作为软件开发过程中的主要产物和交流媒介。
MDE通过建立抽象、可执行的模型来描述系统需求、设计和实现，并通过自动化转换或代码生成来实现软件开发生命周期中的各个阶段。
基于模型驱动开发的软件工程方法研究与应用随着软件开发的不断发展，模型驱动开发（Model-Driven Development，MDD）已经成为了软件工程领域的一个重要研究方向。
MDD是一种基于模型的软件工程方法，它通过建立和操作软件系统的模型来实现软件的开发和维护。
本文将对MDD的相关概念、方法和应用进行研究和探讨。
一、MDD的相关概念MDD是一种基于模型的软件工程方法，它将软件系统的开发和维护过程中的各个阶段都建立在模型之上。
在MDD中，模型是软件系统的核心，它代表了软件系统的各个方面，包括结构、行为、功能等。
通过建立和操作模型，可以实现软件系统的自动化开发和维护。
MDD的基本思想是：先建立一个高层次的模型，然后通过模型转换自动生成低层次的代码。
这种方法可以在不同的平台上生成不同的代码，从而实现跨平台开发。
同时，MDD还可以提高软件开发效率、降低软件开发成本和提高软件质量。
二、MDD的方法MDD的方法包括模型建立、模型转换和代码生成三个阶段。
1. 模型建立模型建立是MDD方法的第一步，也是最重要的一步。
在这个阶段中，需要根据软件系统的需求和规格说明书来建立一个高层次的模型。
这个模型需要包括软件系统的各个方面，例如：结构、行为、功能等。
2. 模型转换模型转换是MDD方法的第二步，它主要是将高层次的模型转换成低层次的模型。
在这个阶段中，需要使用一系列的转换规则和工具来实现模型之间的转换。
这些规则和工具可以将高层次的模型转换成低层次的模型，并且还可以进行模型验证和优化。
3. 代码生成代码生成是MDD方法的最后一步，它主要是将低层次的模型转换成代码。
在这个阶段中，需要使用一系列的代码生成工具来实现代码的自动生成。
这些工具可以根据不同平台的特点生成不同的代码，并且还可以进行代码优化和调试。
三、MDD的应用MDD已经被广泛应用于软件开发领域。
下面以汽车电子控制系统为例，介绍MDD在实际应用中的效果。
1. 汽车电子控制系统汽车电子控制系统是一个典型的嵌入式系统，它包括多个子系统，例如：发动机控制系统、刹车控制系统、空调控制系统等。
在本系列的第 1 部分中，我们获得了UAV 地面控制器的系统设计，我们使用IBM Rational Harmony 系统工程作为一个流程，指引我们了解子系统和逻辑接口。
不过，分布式系统的设计往往以数据为中心，而数据实体在系统设计中又占据最重要的位置。
因此，很显然，我们只好稍微调整一下Rational Harmony 系统工程流程，让设计流程把重点放在数据实体上，同时继续将Rational Harmony 系统工程等成熟的MBSE 流程的优势融入设计中。
在分布式系统设计中，使用一个先进的接口语言来定义这些数据交互是有必要的，这样做不仅可以在整个交互过程中确保各子系统的一致性，还可以捕获设置在语言本身中的数据的交互目的和行为。
在不断变化的接口规范语言中，类似的步骤是通过OMG 数据分发服务(Data Distribution Service, DDS) 规范（参阅参考资料）实现。
在派生的逻辑接口中的子系统之间弹出操作性ICD（界面控制文件）时，标准的Rational Harmony 系统工程流程结束时的切换（参阅参考资料）已经足够用，但是，在利用数据分发服务(DDS) 将这些逻辑接口映射到信息交换结构时，可能并不简单。
在本文中，我们将尝试调整标准的Rational Harmony 系统工程流程的工作流，让它支持分布式不协调性，而不是支持Rational Harmony。
首先，我们将介绍DDS 规范和Problem-frame Analysis 的结构（请参阅参考资料）。
然后，我们遵循修改过的MBSE 流程中所涉及的步骤，这些步骤及时采用了DDS，并在整个分布式系统的分析和设计过程中体现它。
最后，您应该能够通过使用与本文第 1 部分中相同的案例研究来运行这些步骤。
了解DDS 和问题框架分析OMG 数据分布服务(Data Distribution Service, DDS) 规范被划分为两个架构层次。
下层是以数据为中心的发布和订阅(Data Centric Publish and Subscribe, DCPS) 层，其中包含了发布和订阅通信机制的类型安全的接口。
《MBSE建模方法研究_业务、系统和软件建模》篇一MBSE建模方法研究_业务、系统和软件建模MBSE建模方法研究：业务、系统和软件建模一、引言随着信息技术和数字化时代的快速发展，模型化方法在业务、系统和软件工程中扮演着越来越重要的角色。
MBSE（基于模型的系统工程）建模方法作为一种新兴的建模技术，其重要性日益凸显。
本文旨在研究MBSE建模方法，探讨其在业务、系统和软件建模中的应用，并分析其优势和挑战。
二、MBSE建模方法概述MBSE建模方法是一种以模型为中心的系统工程方法，它通过建立各种模型来描述系统、业务和软件的需求、设计、实现和验证。
这种方法强调在项目开发过程中使用统一的、可视化的模型，以支持开发团队之间的沟通与协作。
MBSE建模方法具有以下特点：1. 统一性：所有相关的模型都在一个统一的框架下进行建模，方便团队成员进行沟通和协作。
2. 可视化：模型以图形化的方式呈现，易于理解和分析。
3. 完整性：模型涵盖系统、业务和软件的各个方面，确保了项目的完整性和一致性。
三、业务建模业务建模是MBSE建模方法的重要组成部分，它主要关注企业的业务流程、组织结构和业务规则。
通过建立业务模型，可以清晰地描述企业的业务需求、业务流程和业务规则，为后续的系统和软件建模提供基础。
在业务建模过程中，需要关注以下几个方面：1. 业务流程分析：通过分析企业的业务流程，确定需要改进或优化的环节。
2. 组织结构建模：建立企业的组织结构模型，描述各部门之间的协作关系。
3. 业务规则建模：建立业务规则模型，描述业务过程中的各种规则和约束。
四、系统建模系统建模是MBSE建模方法的核心部分，它主要关注系统的结构、功能和行为。
通过建立系统模型，可以清晰地描述系统的需求、设计和实现。
在系统建模过程中，需要关注以下几个方面：1. 系统需求分析：通过分析用户需求和业务需求，确定系统的功能和性能要求。
2. 系统结构设计：建立系统的体系结构模型，描述系统的各个组成部分及其之间的关系。
国外基于模型的系统工程方法研究与实践王崑声袁建华陈红涛蒲洪波引言自上世纪60年代以来，系统工程一直是国外航天和国防领域所惯常采用的研制管理方法，保障了自“大力神”导弹及阿波罗计划以来众多项目的成功。
然而，自1969年形成美国军用标准《系统工程管理》（Mil-Std-499）以来，该方法变化很小。
与此同时，系统的规模和复杂性却在显著地增长，传统系统工程（Traditional Systems Engineering，TSE）方法已经不能满足需求。
2012年1月，在NASA的项目管理挑战研讨会上（PM Challenge），来自约翰逊航天中心的技术人员介绍了在航天服开发中应用“基于模型的系统工程”（MBSE，Model-Based Systems Engineering）的情况。
目前，NASA所属的兰利航天中心、喷气推进实验室等都在项目研发、技术管理等方面积极地应用MBSE方法。
MBSE作为一种新的范式（Paradigm），NASA、DoD、ESA等政府组织和相关承包商积极在项目中应用，IBM等软件和方案提供商也在积极地开展研究，并开发相关的支持环境。
有关MBSE的研究与应用正在快速地扩展开来，影响越来越大。
MBSE方法已经成为最近几年系统工程界研究与应用的热点。
一、基于模型的系统工程的概念与内涵2007年，国际系统工程学会（INCOSE）在《系统工程2020年愿景》中，给出了“基于模型的系统工程”的定义：基于模型的系统工程是对系统工程活动中建模方法应用的正式认同（formalized application of modeling），以使建模方法支持系统要求、设计、分析、验证和确认等活动，这些活动从概念性设计阶段开始，持续贯穿到设计开发以及后来的所有的寿命周期阶段。
从MBSE的定义可以看出，MBSE强调了建模方法的应用问题。
我们知道，模型就是针对建模对象（研究对象）中建模者感兴趣的某些方面特征的近似表征，建模就是运用某种建模语言和建模工具来建立模型的过程，仿真是对模型的实施与执行。
模型是我们思考问题的基本方法，是设计工作的思维基础。
实际上，各专业学科及系统工程一直在使用建模与仿真方法，MBSE并不是对建模方法的首次采用，也就是说，MBSE与传统系统工程（Traditional Systems Engineering，TSE）的区别并不在是否采用建模方法。
（一）系统工程的关键在于构建一个系统架构模型在整个系统工程工作过程中，人们不仅要在头脑中建立（具备）一个关于该系统的全面的“概念”（想法、构思、构想），而且在现实中要针对这个“概念”建立某种类型的模型，如草图、文字描述、表格、图片、图示、实物模型等，这些模型统称为工件（Artifact），是人们自己思考和与他人沟通交流的工具。
现实中工件和头脑中的概念相互启发，不断深化和具体化，最终变成生产人员可以使用的蓝图，再由生产人员把蓝图变成最终交付的系统。
这实际上是所有设计工作的一般流程，并非系统工程所独有，只是系统工程需要考虑的因素更多罢了。
在设计过程中，需要从各个方面建立模型来对该系统进行详细刻画，才能够准确地、全面地描述系统，比如修建一座大厦时要画出立面图、管道图、电气图、楼层分布图等，这些称为系统的视图（View），分别对应相关的专业学科、不同的工作角色及不同的利益相关者。
系统的视图实际上是从不同方面描述刻画了系统的某个方面的特征，因此，系统的各个视图要紧密关联、保持一致，才能够保证最终的系统是正确的、优化的。
这其中，系统架构模型（System Architecture Model）的建立是至关重要的，也是必需的。
系统架构模型是对系统整体的、全面的描述，相当于通常所说的总体设计方案，是整个研制工作的首要的工件（Primary Artifact）。
系统架构模型与各个视图相互关联，各方人员针对一个共同的系统架构模型来分析和优化。
因此，系统工程的关键，就在于构建出一个完整的系统架构模型。
（二）传统的系统工程用各种文本文档构建系统架构模型传统的系统工程中，系统工程活动的产出是一系列基于自然语言的、以文本格式为主的文档，比如用户的需求、设计方案，当然也包括一些用实物做成的物理模型等。
此时，系统架构模型由“一大包”各种各样的文档共同组成，如火箭的总体布局方案、推进系统、控制系统等分系统的设计方案以及弹道方案、分离方案等。
把这些文档“串起来”的东西是一系列的术语及参数，这些术语对系统进行了定性描述，文档中包含了系统的各种各样的参数，它们是系统的定量描述。
各专业学科的分析模型（公式）从文档中抽取相关参数进行计算（先找到术语，再找到参数），计算之后再把相关参数写入文档，转交给其它学科和相关人员，也就是说，参数在各个文档之间“来回流动”，这种设计流程也被称作“抛过墙的设计”。
很显然，在这个过程中，文档管理的机制、配置管理的机制非常地重要，总体设计的工作主要就是抓总和协调，并控制这些术语和参数。
TSE的文档在描述系统架构模型时具有“天生的缺陷”。
TSE的文档是基于自然语言、基于文本形式（Text-Based），当然也包括少量的表格、图示、图画、照片等。
由于自然语言并非专门为系统设计所发明，而是要表示大千世界的万事万物，还要表示纷繁复杂的各专业学科知识。
所以TSE的文档要依靠相关工程设计的术语（也是基于自然语言的组合），来使各方对系统有一个共同的理解和认识。
所以各方的沟通交流要依赖不断更新的术语表、词汇表等，否则就容易产生理解的不一致性。
尤其是当系统的规模越来越大、涉及的学科越来越多、参与的单位越来越多时，这个问题就更加地突出了。
文档的电子化、网络化并没有从根本上改变各方对文档理解的不一致性。
随着信息技术的发展，系统工程的文档从过去的纸质方式，发展到电子化地处理方式，比如Word、PDF等电子格式，这只是便利了存取、复制、修改，其编码格式依然是基于文本的，各方人员从文档中读取信息依然是“逐行扫描”方式。
对于相关各方对文档的内容形成共同一致的理解，并没有根本的改观。
也就是说，TSE实际上并没有充分地利用信息技术的进步和成就。
因此，传统的系统工程就是以文档为中心的系统工程，这个文档又是“基于文本的”，所以也可以说传统的系统工程是“基于文本的系统工程”（Text-Based Systems Engineering，TSE）。
（三）基于模型的系统工程用系统建模语言构建系统架构模型在MBSE方法中，用系统建模语言来描述系统架构模型，作为系统开发全过程中首要的工件，并且对它进行管理、控制，并和系统技术基线的其它部分进行集成。
用面向对象的、图形化、可视化的系统建模语言描述系统的底层元素，进而逐层向上组成集成化、具体化、可视化的系统架构模型，增加了对系统描述的全面性、准确性和一致性。
借助相关的软件环境及模型和数据交换标准，可以对系统架构模型进行存取操作：系统架构模型存储在一个共同的数据库中，相关参数之间是自动关联的；可以生成系统的多个视图，比如导弹的任务剖面、结构图、电气图等，因此，各个学科的专业工程师、各种角色，都可以基于这个系统架构模型来工作，从共同的数据库中取数、并用本学科的模型及软件工具来进行分析。
图1：系统架构模型的中心位置很显然，要实现上述目的，MBSE需要相应的理论基础、建模语言及工具，这包括来自软件工程领域的面向对象的分析与设计思想、系统建模理论、系统建模语言、扩展标记语言元数据交换标准（Extensible Markup Language Metadata Interchange，XMI）、系统工程数据的交换标准（AP233）等。
二、基于模型的系统工程相对于传统系统工程的优势MBSE和TSE的区别，就在于系统架构模型的构建方法和工具的不同，以及由此带来的工作模式、设计流程等方方面面的区别。
也就是说，传统的系统工程变成基于模型的系统工程，实际是从“基于文本”（Text-based）向“基于模型”（Model-based）的转变，这个模型，指的是用系统建模语言建立的系统架构模型，或者说是系统架构模型的建模语言从“自然语言、文本格式”转向了图形化的系统建模语言（SysML）。
但MBSE并不是完全抛弃过去的文档，而是从过去“以文档为主、模型为辅”向“以模型主、文档为辅”的转变。
（一）系统工程过程产生系统建模语言框图，并组成系统架构模型1、传统的系统工程过程三个步骤分别生成三种文本文档系统工程过程是系统工程方法的“发动机”，主要包括三个步骤、四个回路（Loop），生成三种文档。
第一步的要求分析负责把用户的需求及外部环境的约束变换成系统要求。
第二步的功能分析与分配负责把系统要求变换成系统的功能，并把功能分解为系统的一个一个的“小动作”，形成的文档是功能架构。
第三步的设计综合，则根据现有的产品及技术条件，把功能架构“映射”到物理架构上，完成设计过程。
四个回路则负责把三个步骤各自的产出和输入进行对比，看是否匹配，这个过程叫作验证（Verification）。
这其中，设计师要在功能架构和物理架构之间进行多次的、双方向的反复迭代，直至所有的功能架构和物理架构都被试验过，并且二者要一致，这里包含了巨大的工作量。
图2：系统工程过程2、基于模型的系统工程的三个步骤各自生成三种图形在MBSE方法中，系统工程过程的每一步产生的不再是文本文档，而是用系统建模语言所构建的模型：在要求分析步骤产生要求图、用例图及包图，在功能分析与分配步骤产生顺序图、活动图及状态机图，在设计综合阶段产生模块定义图、装配图及参数图等。
图3：运用SysML后的系统工程过程在系统不同层次反复应用这一过程建模，可以深入到系统最底层的元素，把最底层元素的模型集成起来，就形成了一个完整的系统架构模型。
在支持SysML 的软件中，框图所代表的系统设计的相关数据被存储在数据库中。
可以借助不同“颗粒度”的系统架构模型来进行可行性研究、备选方案研究等工作。
可以自动生成相关文档，以供相关的决策者使用。
尤其需要重点指出的是，需求者也可运用SysML画出需求图，用例图，以此驱动整个过程，这样就可以使用户的参与程度更深，并进而改进整个的设计工作。
（二）系统架构模型成为沟通各学科的“集线器”目前，各专业学科的模型已经被大量应用于工程设计的各个方面，但模型缺乏统一的编码，也无法共享，建模工作仍处于“烟囱式”的信息传递模式，而没有与系统工程工作流相结合。
TSE下，文本文档是各专业模型接入系统架构模型的枢纽和渠道，比如，电子工程师和力学工程师都在分析研究同一个部件，但它们所使用的术语、模型都不一样，无法进行直接的交流和沟通，因此总体设计和协调的工作量就十分巨大。
需要指出的是，MBSE并不是要抛弃掉各专业学科原来所使用的模型，而是要用统一的系统建模语言来沟通各专业学科、专业工程。
