在接下来的章节中，我们将回答关于模型驱动系统工程（MBSE）的一些常见问题，包括：什么是MBSE？MBSE的真正目的是什么？MBSE与SysML是一样的吗？
什么是MBSE？
如果你问20个人MBSE的定义，可能会得到20个不同的答案。造成混淆的核心在于“模型”一词。
SE的数据中心实践的数据和信息模型双向可追溯性对于记录关系、评估变化和显示合规性至关重要。INCOSE系统工程手册（SE HB）指出，“代表系统及其环境的模型对于必须分析、指定、设计和验证系统，以及与其他利益相关者共享信息的系统工程师来说尤为重要。不同类型的模型用于代表不同建模目的的系统。”
在INCOSE SE HB中，“模型”一词出现了超过680次！这个术语用于指代各种模型，数据和信息的可视化，以及文档、图表、图纸或系统的任何其他表现形式。
在这个背景下，”模型”可以是任何形式的系统表达或概括，只要它能够最好地适应其被创建的目的。所以，存在许多种类的模型，包括分析模型、逻辑模型、行为模型和架构模型，还有文字描述，以及如文档、功能流程图、数据流程图、接口图、架构图、绘图等其他任何方式的系统表示。
所有这些表示的共同点是它们都是用于构建和表示模型的基础数据和信息的可视化。
再次引用INCOSE SE HB：
“MBSE通常与SE的传统文档驱动方法进行对比。在文档驱动的SE方法中，常常有大量关于系统的信息包含在文档和其他工件中，如规格说明书、接口控制文档、系统描述文档、贸易研究、分析报告、验证计划、程序和报告。这些文档中包含的信息常常难以维护和同步，难以评估其质量（正确性、完整性和一致性）。”
“在MBSE方法中，大部分信息被（电子化）捕获在系统模型或一组模型中。系统模型是SE过程的主要工件。MBSE通过使用模型形式化SE的应用。这些信息在模型中被捕获并在整个生命周期中维护的程度取决于MBSE工作的范围。利用MBSE方法进行SE旨在显著改善系统需求、架构和设计质量；通过在系统定义早期揭示问题，降低系统开发的风险和成本；通过重用系统工件提高生产力；并改善系统开发团队之间的沟通。”
考虑到可以有多种类型的模型，以及在系统生命周期过程中生成的数据和信息的可视化，从数据中心的角度看SE的10,000英尺级别的视图有助于利益相关者理解各种工件及其基础数据和信息生成和使用的背景。
MBSE并非真正关于绘制包含框和线的图表，而是关于能够确保数据和信息在代表各种模型和可视化的过程中保持一致性的底层数据和信息模型本身。
MBSE的真正目标是什么？
一个组织采用MBSE的目标是从20世纪的文档中心的系统工程（SE）实践转向SE的数据中心实践，以实现MBSE的真正意图，即开发、维护和管理正在开发的系统的数据和信息模型，以及所有系统生命周期过程活动、产生的工件及其基础数据和信息的模型。
“从数据中心的角度看，MBSE涉及到正式应用可分享的数据集来表示SE工作产品和为支持生命周期概念成熟、需求定义、设计、分析、验证和验证活动而生成的基础数据和信息，这些活动贯穿于系统生命周期，从概念设计到退役。”
借助这种SE的数据中心视角，我们可以用多种方式捕获、管理和访问数据，并处理系统工程工作产品之间的关系。这些方式可以从创建单一的关系数据库到通过联盟或数据映射/索引不同的数据源实现分布式但却虚拟集成的数据库。
数据和信息可以用各种系统工程工具和应用程序来收集。为了有效管理日益复杂且以软件为中心的系统，我们可以以一种能在系统生命周期过程活动中共享、在用来创建和管理这些数据和信息的不同系统工程工具间共享，以及在参与开发和运营这个系统的各个组织之间共享的方式来管理这些底层数据和信息。这样的共享方式有助于确保数据和信息的正确性、一致性和完整性，这些都是我们日益复杂的系统所必须具备的。同时，这种共享也将促进项目团队成员和参与系统开发的外部利益相关者之间的协作。
为了管理日益复杂的以软件为中心的系统的开发，我们需要以一种可以在系统生命周期的各个过程中，以及所有主要利益相关者之间共享的方式来管理数据，这样可以保证数据的一致性和正确性。
如果我们只从一个角度（比如需求、模型、模式、标准或者特定行业的应用等）去看待系统工程，那么我们就不能有效地进行系统工程实践。成功实践系统工程的工程师会认识到并适当地运用每一个角度。他们会根据自己的需要，选择最适合他们需求的工具和可视化方式。
捕捉和管理数据和信息的程度是由组织和项目的商业和技术需要来驱动的，这些需要基于他们项目的规模和复杂性、产品线、公司文化、流程、员工队伍、供应链的多样性和复杂性，以及组成他们关注的系统技术基线的工程信息类型。
MBSE并不等同于SysML
对于一些从业者来说，MBSE等同于使用SysML和其他基于语言的建模工具。然而，如上所述，MBSE远不止于使用基于语言的建模工具来开发分析、逻辑、行为和架构模型。对于其他人来说，他们所称的MBSE实际上是基于模型的设计（MBD）。
MBD设计从一组需求开始，使用各种基于语言的建模工具来构建和设计系统，开发模拟来评估系统的行为，然后开发一组设计输出规范，根据这些规范构建或编码系统。MBD活动通常在一个与其他SE生命周期过程活动分离的孤岛中完成。
然而，这种方法并未满足MBSE的真正意图。必须开发的数据和信息模型必须代表在所有生命周期阶段活动中的产品开发过程活动中生成的所有SE工件。因此，与利益相关者需求和要求的搜集，生命周期概念定义，分析和成熟，导出一组集成的需求，并将这些需求转化为设计输入需求，定义架构，设计系统，验证系统是否满足这些需求，验证系统是否满足需求的信息也必须在数据和信息模型中捕获。此外，必须捕获单个数据项的关系和依赖性（可追溯性），以帮助确定和确保所有生命周期阶段的一致性，以及帮助评估对任何数据项所做的变更的影响。设计输入必须可追溯到设计输出。
从数据中心视角实施系统工程的好处
SE的数据中心视角补充了系统生命周期过程活动，使得系统开发有更高的质量、更低的成本和更低的风险。采用MBSE并实施数据中心视角使组织能够实现以下好处：
满足与当前和未来系统的日益复杂性有关的挑战，如前一节所讨论的。
提供所有产品的更大一致性，因为任何单一的设计数据和信息都可以在集成/联邦的，可共享的数据集中权威地表示，这些数据集可以在后期被其他人参考以做出决策或形成其他工作产品。
提供对整个集成系统主要特性的更好可视性，因为可以创建从数据和信息模型中得到的多个视图，这些视图能够简洁地满足特定利益相关者的需要、关切和兴趣。
提供文档和现实之间的更大一致性和配置管理。不同的底层数据和信息模型视图可以自动生成为SE工件，减少保持工件及其底层数据和信息的更新和一致性的努力，从而产生符合最佳、最新的数据和信息的工件。
建立“真理的唯一来源”。真理的唯一来源(SSoT)代表了数据和信息的官方状态或基线版本——无论某人说什么或想什么，无论他们“记得”什么或对正在做或建造的事情或已经做出的决定有什么观点，如果它不在项目的配置管理的数据和信息模型中，那么它就不是真理。(这需要所有的底层数据和信息都被配置管理并保持当前和一致。)
方便在所有系统生命周期阶段活动中导航、追溯和查询数据和信息。管理者和工程师可以更快地获得正确、完整和一致的数据和信息，并根据需要获取，而无需通过手动分发或搜索过程。
启用SE和PM工件及其底层数据和信息的重用。当一个组织可以重用SE和PM数据和信息，而不必从头开始每一个新项目(棕色领域系统)时，可以节省大量时间和费用。这种重用能力是有效产品线管理的关键。
方便以一种集成、一致的方式管理利益相关者需求、需求定义、设计、构建/编码、系统验证和系统验证活动。在所有系统生命周期过程活动中与验证和验证活动相关的数据和信息可以具有更高的质量，并提供更大的洞察力，了解验证和验证活动的状态。这使得展示合规性和满足利益相关者需求变得更容易。
降低错误设计和随之而来的返工的成本。对SE工作产品及其底层数据和信息的分析可以在创建时立即揭示出一个错误或不一致，从而在进行下游工作之前进行纠正，如果不立即纠正上游的错误，这些下游工作将是无效的，并且费时费力地纠正。这也有助于避免因召回、退货、保修工作和社交媒体上的负面评论而产生的巨大费用。
方便识别交互(接口)，有助于确保感兴趣的系统可以成功地集成到宏观系统中，并减少与这些问题相关的集成问题和昂贵的返工以及与这些问题相关的进度滑动。
提供识别、管理、互操作性和集成在业务或组织元素中需要的工件和底层数据和信息，以支持项目预算和进度目标。例如，通过对数据、信息和工作产品进行元标签，它们可以直接与工作分解结构(WBS)、预算、进度和风险管理活动进行链接。
确保程序和项目需要的数据和信息（例如，里程碑，关口评审，任务操作，风险缓解和异常调查，决策和结果）被识别并管理，以提供用于决策的数据和信息的可追溯性。
使用测量来更好地管理所有系统生命周期过程活动中的SE活动。测量允许经理和系统工程师监测趋势，评估进度，识别问题，以帮助确保正在开发的系统将满足利益相关者的需求和期望。
结论
为了有效地开发今天的日益复杂和软件密集的系统，避免过时的以文档为中心的SE实践的许多负面后果，组织必须转向以数据为中心的SE实践，这是MBSE的真正意图。组织需要开发一个组织SE能力水平，使他们能够实现上述列出的好处。
由于一刀切并不适合所有人，组织需要评估最适合其领域、产品线（复杂性程度）和文化的SE能力。组织建立的SE能力水平需要根据该组织开发的系统的大小和复杂性进行调整，无论是小型、中型还是大型项目。
基于组织的需求和SE能力水平，他们将需要选择适当的SE工具集，更新他们的流程，并对这些工具和流程进行培训。
