目录

1、介绍

1.1 什么是MBSE，为什么行业开始使用MBSE？

1.2 引擎盖下的MBSE：SysML、数字线程和本体

1.3 MBSE到基于模型的企业/工程（MBE）

1.4 MBSE的挑战：工程和IT

1.5 利用云解决挑战

1.6 数字工程：基于云的IT和工程组织转型

2、AWS上的MBSE：从迁移到创新

2.1 概览

2.2 由AWS提供支持的MBSE的企业转换

2.3 迁移

2.3.1 重新承载MBSE应用程序

2.3.2 重构MBSE应用程序

2.4 创新

2.4.1 数字连续性层

2.4.2 扩展基于MBSE的团队协作

2.4.3 面向MBSE的AI/ML服务

2.4.4 共享服务平台（SSP）

3.结论

基于模型的系统工程（MBSE）是传统的基于文档的系统工程实践的一种现代方法。MBSE受益于现代云计算技术、微服务、AI/ML、高级分析等。

这些技术不仅使MBSE能够被工程组织广泛采用，而且还超越了MBSE目前的前景，带来了创新、灵活性、可扩展性和成本优化。MBSE最近已被航空航天、能源和汽车客户采用，并在其他行业中得到发展，在这些行业中，复杂产品（由众多工程学科和协作组成）需要在其整个生命周期中进行设计、制造、测试、维护和监控。

AWS提供构建块技术和根据您的需求量身定制的解决方案。本文既针对开发MBSE技术的MBSE开发人员，也针对使用MBSE工具的MBSE用户。本文还提供了有关MBSE的介绍性信息，以及该技术新手面临的挑战。

1.介绍

1.1 什么是MBSE，为什么行业开始使用MBSE？

当今的多学科、多供应商和多应用程序/工具产品开发环境鼓励客户在规定的截止日期内采用敏捷实践。敏捷性在更传统的工程环境中尤其重要，如航空航天、能源和汽车行业，在这些行业中，瀑布式产品开发已经被长期实践和完善。

由于这些产品非常复杂，因此遵循基于构建的敏捷迭代是昂贵的。此外，这些行业受到高度监管，并以质量为导向。因此，敏捷性不应该承受“匆忙造成浪费”，而应该承受允许数据驱动决策、可见性、可追溯性、简单性，最好是自动化在“坚持最高标准”的同时“快速”进行的技术。

复杂的产品开发需要跨学科和跨供应商/公司的工作。因此，客户在这个复杂而动态的环境中寻找敏捷的方法。在复杂性的中心，我们看到了系统工程（SE）。

根据INCOSE（国际系统工程委员会）的说法，系统工程是一种跨学科的综合方法，利用系统原理和概念以及科学、技术和管理方法，使工程系统能够成功实现、使用和退役。

这里的术语系统是一个广泛的定义，包括硬件、软件、信息、流程、人员、配置、供应链、监管机构和地理位置。SE的基本功能之一是对产品开发和整个生命周期进行验证和确认（V&V）。

通过产品开发、MBSE、传统SE成本和项目缺陷成本进行验证和确认（V&V数据改编自Clarus运营概念，于2009年7月5日存档于Wayback Machine，出版物编号FHWA-JPO-05-072，联邦公路管理局（FHWA），2005年。）

上面你可以通过V&V图看到瀑布式产品开发方法的各个阶段。V&V旨在跟踪产品开发和产品本身是否符合要求。验证会问“我们是否正确地构建了产品？”，而验证会问：“我们是否构建了正确的产品？”。

V&V有助于通过系统工程成本协调的工程和制造功能，最大限度地减少后期缺陷发现，并在接近尾声时发现问题。尽早了解严重问题是件好事。传统上，系统工程师遵循基于文档的方法。挑战在于，由于项目中存在大量利益相关者和移动部件，无法适应协作的变化和复杂性，这总体上减缓了产品开发过程。

基于文档的SE MBSE

同时，在上图中，您可以在左侧看到传统方法的挑战。

它通常涉及大量的会议、文档共享、带附件的电子邮件、电子表格、pdf和模型在基于文档的系统工程环境中在利益相关者之间“飞行”。这也可能意味着在项目接近尾声时容易发现缺陷。正如我们之前所确定的，后期缺陷发现的成本更高。尽早意识到严重问题要好得多。

如果没有这种方法，你最终可能会为工程师提供多个“真相来源”，从而造成数据冲突、使用不准确数据或对源数据进行后期更正等复杂情况。这不仅会损害产品质量，还会因减缓整体产品开发而延误项目。

最后，随着这些行业的物联网/工业4.0转型，现在和将来都会有更多的数据。

数据的大小进一步给已经复杂的情况带来了负担。在这个复杂度、速度和质量的三角关系中，系统工程师用“建模”来取代文档。基于模型的系统工程（MBSE）通过“模型”表达“行为”、“需求”和“结构与关系”。

INCOSE将MBSE描述为“从概念设计阶段开始，在整个开发和后期生命周期阶段持续进行的建模的正式应用，以支持系统需求、设计、分析、验证和确认活动。”

这里的模型对应于一个抽象的概念，如现象、关系、结构或系统，可以用图形、数学或物理方式表示。该模型通过解释行为和模拟事件来促进概念，以帮助决策过程。模型是低保真度系统模型，而不是高保真度工程学科模型，如CAD模型、有限元模型等。我们将在“发动机罩下的MBSE”部分讨论系统模型。

MBSE的另一个组成部分是结构。结构是任何信息（数据或元数据）

其呈现由半静态组件组成的树状表示。例如，这些结构可以是抽象概念，如产品变体和配置，也可以是物理的，如物料清单（BOM）或组件和移动系统的组装，如发动机。

行为定义了结构之间或结构内部零件之间的关系。MBSE中的整个验证过程是通过像这样的低保真度模拟自动化的。这些边界参数基于要求。第7页的图表显示了MBSE下结构、行为和需求是如何连接的。

在本文中，我们将“人”纳入了MBSE框架。这是因为采用MBSE的项目是在多利益相关者（内部和外部）环境中的高度多学科环境中工作的。由于我们谈论自动化和敏捷性、人员/用户责任、访问和身份管理、提供的功能、工作范围等都是MBSE工作流的嵌入式部分。

术语“基于模型”因其范围和领域而异。例如，在软件工程中，基于模型的“软件”工程（MB’S’E）具有其独特的功能，例如用于系统行为和测试的自动代码生成。MBSE的自动代码生成功能对于航空航天等高度监管和安全关键的行业尤为重要。另一方面，“基于模型的”方法可以扩展到基于模型的企业（或工程），它涵盖了产品的整个生命周期，不仅限于虚拟化，还包括产品、制造等物理空间。MBE将在以下章节中讨论。

从公共部门的角度来看，可以参考美国国防部2018年数字工程战略。

该文件描述了MBSE是该战略的核心推动者，其五个支柱中的第一个支柱是正式确定模型的开发、集成和使用，为企业和项目决策提供信息。因此，从事复杂离散制造业的AWS客户希望MBSE能够：

• 缩短现场交付时间（上市时间）

• 通过数字可追溯性提高整个生命周期阶段和项目的效率和重用性

• 实现早期风险识别（质量）和成本降低

• 利用数据和模型作为权威的事实来源

• 建立一个综合数字生态系统的目标，利益相关者可以访问以纯数字方式工作所需的数据、功能和元素

1.2 引擎盖下的MBSE：SysML、数字线程和本体

MBSE的主要目的是用可重用的模型替换文档。因此，模型应该是系统（即规程、类型）和平台（即工具、例程）无关的。因此，在将这些连接到一个共同的语言和模式时，这会造成复杂性。为此，MBSE遵循统一建模语言（UML）标准。

一些例子是SysML（见Burger的《基于视图的模型驱动开发的灵活视图》，Erik.KIT科学出版社，2014年11月14日）。第250页），OPM（见Dori，Dov。“对象过程分析：保持系统结构和行为之间的平衡。”《逻辑与计算杂志》5，第2期（1995）：227-249），ARCADIA，以及其他流行的SysML（系统建模语言）。SysML是专门用于SE应用程序的UML的扩展，最初是作为开源创建的。目前，AWS没有本机SysML库。但是，您可以携带自己的库（BYOL）并根据需要构建SDK。AWS解决方案架构师、AWS合作伙伴和/或AWS专业服务将在每一步为您提供帮助。

利用MBSE来控制需求、结构和行为

MBSE中的下一个重要概念是本体。本体通过引入形式化语义，根据系统内部和系统之间的对象、定义和关系，建立定义良好的领域概念。尤其如此，因为这些是“系统的系统”，其中每个系统由许多系统组成。

模型的含义（不是细节，而是紧急属性和元数据）需要在不调用其主题领域专家的情况下被表达和理解。因此，本体是实现标准化和实现数据交换的必要步骤，从而实现灵活性和互操作性。

这种形式化的建模和仿真应用改进了系统需求定义、设计、验证和确认、操作和整体性能。

由不同类型的对象（节点）及其关系组成的图模型具有随时间变化的不同元数据（左）、向后和向前传播更改的对象更改以及新对象添加兼容性分析（右）。

支持MBSE模型的另一个概念称为数字线程。“线程”应该是将不同类型的模型“连接”或“插入”到系统模型的系统中的标准化方法。您可能会注意到MBSE的总体特征形成了一个“图”或“网络地形”，如上图所示。

它展示了几个例子，说明工程更改对对象或新添加的对象和关系的影响。

在此模型中，MBSE可以模拟向前和向后的更改传播，并根据需求集执行兼容性分析。因此，MBSE是跟踪性和变更管理以及自动化的关键，可以更早地发现缺陷和问题。

MBSE的另一个特点是提供集成（系统）设计环境（isde），它为涉众提供了一个可视化的环境来构建、交互和使用系统模型。

上述讨论和概念对于了解云和AWS技术在实现MBSE和MBSE相关技术方面的优势至关重要，这些技术将在以下部分中讨论。

1.3 MBSE到基于模型的企业/工程（MBE）

今天，业界致力于将MBSE扩展为一个“有能力的系统工程工具”，从而成为一个完整的数字转换，即所谓的基于模型的企业或工程（MBE）。在本文中，我们没有区分MBSE和MBE，而是在MBE的背景下讨论了MBSE，其中MBSE是一种更广泛、更有能力的方法，由多种技术组成，可以利用完整产品生命周期的物理和虚拟方面。

MBE——产品生命周期中心的基于模型的企业/工程

上面的图表试图在一个单独的设置下解释MBE方法，该设置分为完整产品生命周期的物理和虚拟方面。在虚拟中，它包括抽象概念，如“依赖关系”，意味着动态和静态的“关系”或“配置”，而模型和模拟来自工程、管理和操作的所有学科。

在高层次上，物理部分是关于生产，测试/问答，交付，操作，包括产品处理和回收。在这个层次下，有大量相对独立的变量，如利益相关者、服务、物理或工具中的产品、基础设施、需求和虚拟部分中的数据。

特别是“数据”部分至关重要，因为它既是“大数据”，又是非常多样化的数据，包括结构化和非结构化数据。

在本体的抽象定义下，包括语义和不可知论关系，以及元数据的虚拟连接标准化。在物理“领域”，我们可以谈论全球范围内的连通性；高吞吐量的摄取和流，数据库；关系存储、非关系存储或对象存储。

所有这些方面都通过数字连续性连接起来，借助数字线程和api、消息传递、事件和业务逻辑的编排，这些将在以下章节中讨论。

1.4 MBSE的挑战：工程和IT

MBSE也有自己的挑战；对于启用技术的IT部门和使用它的工程团队来说都是如此。在本文中，我们将讨论这两个团队挑战的挑战和解决方案。

也许MBSE的主要挑战是它作为一项整体技术的相对早期的技术准备阶段。学者、大学、行业和从业者都在设想和开发这项技术。随着MBSE功能的发展，人们期望有更多的功能，这就产生了更多的期望，需要在技术上进行更多的开发。与此同时，产品开发的数字化（数字化转型），特别是瀑布式产品开发，为MBSE采用者带来了对MBSE及其相关技术的额外需求。此外，MBSE开发人员致力于在IT领域实现新技术；比如数据库类型、架构和物联网。

在IT空间中实现MBSE的挑战之一是动态可伸缩性。由于MBSE呈指数级增长，因此MBSE的存储和数据库应该是灵活的，因此可以动态扩展。

因此，您可能正在为您的MBSE解决方案寻找几乎无限的可伸缩性、可靠性、持久性、互操作性、灵活性和成本效益。

MBSE不是单独工作的。它工作在一个复杂的和动态的工程环境。MBSE需要支持各种各样的配置。它应该可以在多种设备、软件、api、端点、环境、工程实践、机械共鸣等中操作。挑战在于将MBSE置于工程的中心。这被称为互操作性。

下一个挑战是将MBSE扩展到边缘，反之亦然，将边缘连接到MBSE。随着连接的设备越来越多，构建模型所需的数据和影子设备也越来越多。这与Digital Twins类似。为了使MBSE保持在“正确信息”的中心，MBSE应该达到边缘和其他类型的内部和外部资源。

另一个挑战是模型共享的数据主权和访问管理，因为MBSE将由分布在世界各地的多个供应商使用。因此，具有最小权限的粒度访问管理和模型共享仍然是一个挑战，其失败会给MBSE从业者带来安全风险。

将MBSE置于产品生命周期中的流程和信息的中心，就会有其他功能附加到MBSE上。例如，多学科优化（MDO）或设计空间探索（DSE）都可以依赖于MBSE。

最后一个挑战是人类对采用新技术的整体犹豫。MBSE向好的方向动摇了现有的工程实践。然而，就像所有新事物一样，它也有阻力。因此，MBSE需要灵活地适应当前的工程实践。

MBSE内部部署面临着额外的挑战，因为IT挑战是在上述技术和组织挑战之上添加的。MBSE需要相当大的计算能力、存储空间和各种数据库。它还需要灵活；因此，从长远来看，单块体系结构方法会减慢MBSE工具的功能。

大多数情况下，MBSE的用户不是IT公司。因此，IT基础设施管理、猜测容量、基础设施退役计划、保持基础设施最新，包括物联网等额外技术，都产生了更多的工作，因此增加了间接成本。

此外，随着时间的推移，实践MBSE的工程团队可能会发现更多的不兼容性或缺失的功能。因此，IT团队可能需要处理这些缺失的功能，或者提供额外的变通解决方案，为他们的mbsessolution创建技术债务。因此，客户将努力寻找简单但通用的解决方案，以便从MBSE解决方案或基于MBSE构建的解决方案开始。

1.5 用云解决挑战

MBSE通过提供模型和单一的事实来源，为高质量的产品带来灵活性。上述MBSE的功能和挑战需要各种各样的技术。

因此，云带来了基本的价值主张，如按需资源、不再猜测弹性的容量、按使用付费的成本效益和大规模经济、广泛的最新技术选择、IaS（基础设施即软件）的实验文化、走向全球和弹性。

云优先的方法不仅使MBSE开发人员受益，而且使采用MBSE作为工具的工程公司受益，使其处于工程操作的中心。MBSE开发人员可以使用最先进的技术提供解决方案，这将在本文中提到，例如使用无服务器技术进行计算和数据库。

无服务器方法可以消除管理任务，并提供“按使用付费”的细粒度方式。这对于MBSE尤其有用，因为MBSE主要是事务性的，其中事件驱动的体系结构可以提供潜在的成本节约。

类似地，微服务方法可以进一步解耦功能和服务，从而带来可靠性和高可用性。例如，可以分别使用云原生标准（如Restful api和JSON有效负载）来执行消息传递和本体的标准化。

此外，IaS方法可以进一步为您的IT甚至工程团队提供敏捷性，他们可以“在必要时获得功能”。

MBSE从业者所处的行业具有复杂的产品开发人员，其中许多供应商在同一个项目上工作，并加入世界各地。全球分布的边缘位置，同时专注于特定地理位置的数据驻留要求，使用云很容易。

您可以部署边缘位置以实现低延迟MBSE应用程序，同时在所需位置指定数据驻留位置。

使用AWS，您甚至可以在使用云技术的同时使用AWS前哨来利用您现有的办公室和本地数据中心。与筒仓式MBSE解决方案相比，这种方法带来了灵活性、速度和可靠性。

云的无限存储为MBSE带来了可伸缩性。您还可以部署混合解决方案，其中主存储是云（或辅助存储是云），同时仍然使用本地基础设施。

云计算的最后一个优势是可持续性。根据总部位于阿姆斯特丹的GRI（全球报告倡议组织），环境、社会和治理（ESG）的披露现在已经成为评估组织绩效的主流。

作为亚马逊可持续发展数据倡议（ASDI）的一部分，AWS致力于以最环保的方式运营我们的业务。

截至2018年，AWS已经有50%的能源来自可再生资源，AWS承诺到2025年实现100%的能源来自可再生能源。因此，您可以通过迁移到云和AWS来减少碳足迹。

复杂的离散制造行业正面临着越来越多的全球监管，包括可持续性目标，以及减少新产品上市时间的压力。

因此，在符合可持续性目标的同时提高生产力可以应用于规模应用，例如MBSE/MBE，它跨越了制造、设计、边缘位置、设备等。

利用AWS为您的MBSE/MBE基础设施提供可再生能源资源，可以帮助您实现可持续发展目标。

1.6 数字工程：基于云的IT组织转型和工程

大多数MBSE解决方案都是基于内部部署的孤立解决方案——或者部分利用云的优势。事实上，使用云技术是一段旅程，而不是一种二元方法。

云的企业转型之旅

上图显示了一个企业的典型旅程。我们通常看到客户从一个项目阶段开始，他们开始测试云实现。然后，基础阶段已经建立，采用诸如云采用框架（例如构建云卓越中心（CCoE））和制定良好架构的策略等框架。

迁移和创新的下一个阶段是云的价值变得明显的时候。在这些阶段，我们的客户将受益于差异化的体验。

通过迁移，客户开始利用可伸缩性、弹性和成本节约；通常，通过混合解决方案逐渐将应用程序从本地迁移到云。随着时间的推移，客户开始通过实验文化利用云原生技术，这是通过云的IaS和IT敏捷性实现的。

这就进入了创新阶段，在这个阶段，客户将他们的应用程序现代化，并添加额外的功能，如AI/ML技术、分析、无服务器等。

因此，在下一节中，我们将带有AWS的MBSE分为两类；MBSE的迁移与创新。

二、AWS上的MBSE：从迁移到创新

2.1 概览

AWS为上述挑战提供了解决方案。您可以受益于：

• 可伸缩性和弹性。以下技术和解决方案带来可伸缩性对象存储和数据库、计算和支持基本技术，为您的MBSE应用程序提供几乎无限的空间。我们专注于提供动态扩展并最大限度地减少MBSE IT工作负载管理的AWS托管服务。AWS同时提供关系数据库和非关系数据库，包括图形数据库和对象存储。你甚至可以将无服务器数据库（如用于MySQL或PostgreSQL的Aurora serverless），非关系（键值）数据库（如Amazon DynamoDB），图形原生数据库（如Amazon Neptuneor Amazon S3）作为数据湖，使用AWS Glue对模型数据进行编录，或将Amazon Kinesis用于数据仓库。由于MBSE是关键的基石，任何支持MBSE的技术也必须高度耐用和可靠。

• 可伸缩性的另一个方面是“工程的可伸缩性”，通过增强工程工具的互操作性、工程协作、管理由多利益相关者环境产生的复杂性以及使低延迟应用程序在全球在线来实现。您可以更轻松地在您的MBSE中采用新技术，或者通过api作为“插件”，通过AWS管理所需的资源大小来增加AI/ML、HPC、Analytics等价值交付技术。本文还建议增加基于事件和消息的微流程级工程协作，作为MBSE的扩展。

• IT和工程的敏捷性。您不仅可以为IT操作带来敏捷性，还可以为工程操作带来敏捷性。在大多数情况下，云为IT操作提供的敏捷性可能是显而易见的。另一方面，通过云进行工程的敏捷性可能会被隐藏。事实上，敏捷性是由自动化带来的，“实验”文化可以根据需要自动部署和拆除资源，通过工作流管理实现工程协作的便利性，基于事件和消息的操作透明度，以及利用AWS服务编目的单一数据/信息源。AWS的数据湖（我们称之为MBSE的工件存储和数据目录）可以简化团队和供应商之间的文件和数据协作，您可以将粒度访问管理分配给具有所需特权的相关方。AWS的数据编目工具将进一步减少工程师的数据查询过程。此外，我们将要讨论的基于事件的体系结构将为微观层次的工程事务提供可见性。这带来了更多的实时透明度，这意味着更少的电子邮件、演示和会议——允许专注于工程活动本身。您还可以使用共享服务平台（SSP）来集中管理、治理和部署工程和IT团队所需的资源。SSP也可以作为本文中提到的所有模块的基础。类似地，您可以使用Service Catalog来创建可按需部署的技术选择。这里介绍的技术和方法为您的组织打开了持续集成（CI）和持续部署（CD）功能。

• 互操作性和灵活性。您可以为现有的MBSE和MBSE相关功能带来灵活性和互操作性。您可以现在或随着技术的发展，使用微服务方法增强新功能。您可以使用AWS应用程序集成服务抽象数据连续性层并引入编排工具，以增强MBSE的互操作性。您可以使用以下章节中讨论的数字连续层。AWS应用程序集成服务的广度和深度——主要基于无服务器技术，如消息传递、消息代理服务、队列、工作流管理、Restful api和GraphQL api等——可以为您的MBSE解决方案提供灵活性和互操作性。额外的灵活性支持混合架构，您可以部分使用云构建解决方案。您可以在您的办公室/数据中心或使用AWS前哨站使用本地AWS技术，或在您的设计办公室/数据中心/边缘位置与AWS云（如AWS Storage Gateway和Amazon Direct Connect）之间建立高速、可靠的专用连接。

• 更多的实验。借助AWS中的200多个服务，您可以通过为IT和工程团队进行实验来促进创新。其主要思想是尽量减少维护和管理基础设施和可重复活动所花费的时间。解决方案和服务，如共享服务平台（SSP）、服务目录、AWS CodePipeline，可用于自定义构建和随需应变的临时资源，供您的团队进行实验。截至2021年8月，拥有超过400种不同类型的芯片和自动部署，您的工程团队还可以按需部署，以实现需要大量计算能力的高保真仿真。然后，您可以使用自动化对数据进行编目，并将结果存储在Artifact store中（如上所述）。通过这种方式，MBSE还可以支持高保真度模拟，这在本地基础设施或手动流程中是不可能实现的。结果是提高效率，让您有更多的时间专注于价值交付活动，如创新和实验。

• 全球规模的MBSE。230多个AWS网点服务于245多个国家和地区，AWS全球网络骨干网将帮助您实现MBSE及MBSE相关服务的全球化，带来低延迟应用。这对于解决数据主权、地理访问管理以及提供低延迟MBSE服务尤其重要。此外，MBSE的价值在于带来可用的模型、产品和流程，可以使用ingread-replication、全局表/数据库、主/从连接和无服务器IaS部署在全局执行。这意味着，您可以将数据保存在您认为有意义的主要位置，同时提供针对边缘优化的读访问或API接口（如Amazon CloudFront、AWS Lambda@Edge或在边缘优化的API Gateway）。此外，您可以使用AWS Global Accelerator来使用始终在全局可用的静态ip，即使在您的MBSE后端发生了故障转移。

• 将MBSE扩展到边缘。随着越来越多的处理能力嵌入到设备、车辆和制造业中，将现有（云上或本地）技术扩展到边缘几乎成为一种必要。这对于从设计到生产或相反顺序的更改的可追溯性尤其重要；生产(即。缺陷或问题)的设计。MBSE将由代表产品整个生命周期的数据提供。因此，MBSE扩展到整个产品生命周期，这需要本地，可靠，离线模式能力，轻量级处理能力，存储，AI/ML以及MBSE与边缘设备/车辆/机器和生产线之间的连接。此外，设计过程将扩展到生产中，以加速实验，引入更敏捷的实践，或者只是对生产缺陷或源于任何一方的更改做出快速反应。因此，您可能希望将自动化从使用MBSE的设计扩展到生产。例如，您可以自动化3D打印原型从设计到边缘，并通过AWS物联网从生产到设计团队获取反馈信息。

• AI/ML在MBSE的每一层。我们特别看到NLP（自然语言处理）技术在MBSE中的重要价值。例如，您可以使用Amazon text来自动读取您手工编写的遗留文档/表，或者使用Amazon understand自定义实体在您的本体的规程模型之间建立正式语义。亚马逊翻译可以用来提供更好的国际合作。AI/ML的另一个层次是通过Amazon Neptune ML。由于图形数据库是动态的，您可以为网络使用各种ML算法，例如查找模式，异常检测，最短距离，中心查找，未使用例如，Amazon Forecast可用于此类目的。最后，你可以使用Amazon SageMaker带来大量的AI/ML算法。特别是，对于NLP，你可以使用Amazon SageMaker中的hug Face。我们相信AI/ML部分将在MBSE应用中发挥作用，并将成为该技术领域的未来。

• 无服务器技术：增强MBSE服务的另一个关键的、有前途的技术是无服务器技术。这是由于MBSE的事务性操作——基于更改、提交、模拟和整体CRUD活动。因此，无服务器不仅可以从您的肩膀上接管所有的管理，还可以带来成本效益。如前所述，无服务器不仅限于计算（如AWS Lambda），还包括数据库、工作流管理、消息传递、api等。

• 粒度访问、身份管理和安全：我们的客户希望通过国际、多供应商协作实现敏捷性，同时确保数据不会在定义的设置之外被访问，并且在传输和静止时得到保护。身份和访问管理与安全是一个非常广泛而深入的主题，因此本文提供了有关MBSE的高级信息，并提供了有关该主题的链接。

• 体验。我们的客户对MBSE有不同的需求和目标。自2006年以来，AWS已经帮助了来自不同行业的数百万客户。

2.2 由AWS提供支持的MBSE的企业转换

根据下面分享的企业旅程，我们将这一部分分为两组：

• MBSE应用程序迁移到AWS

• MBSE创新与AWS

AWS上的MBSE和价值交付技术领域的单一视图。

2.3 迁移

您可以在AWS上重新托管或重新搭建MBSE平台。本节介绍AWS中迁移策略的6- r。我们将从重新托管开始，然后直接移动到“r”的另一端，重构。在这两个极端之间的其他4r是它们的组合。

2.3.1 重新托管MBSE应用程序

重新托管MBSE意味着将现有的MBSE服务提升并转移到云中。您可以使用AWS应用程序迁移服务来迁移工作负载，并提供多种芯片和云存储类型可供选择。

您仍然可以在不更改现有设置的情况下带来灵活性、敏捷性、可伸缩性和可用性。您可以构建自己的MBSE Amazon Machine Image (AMI)，并在EC2实例、带有EKS的Kubernetes或带有ECS的容器上部署应用程序。您还可以使用Amazon AppStream 2.0虚拟地部署非持久性桌面和MBSE应用程序虚拟化，例如按需ide。

另一方面，您也可以将您的MBSE数据库提升并转移到AWS。您可以在Amazon EBS和Amazon FSx for Windows File Server上重新托管数据库。除了简单地在Amazon RDS上重新托管和重新搭建数据库平台之外，还可以在自动化耗时的管理的同时，提供经济高效且可调整大小的容量。

Amazon RDS可用于几种数据库实例类型-针对内存，性能或I/O进行了优化-并提供了六种熟悉的数据库引擎供您选择，包括Amazon Aurora， PostgreSQL, MySQL, MariaDB， Oracle database和SQL Server。您可以使用AWS数据库迁移服务轻松迁移或复制现有的MBSE和与MBSE相关的数据库。

您可以通过为MBSE和相关服务提供服务目录来使用基础设施自动化。一旦您有了ami和设计基础设施配置，就可以为所需的MBSE堆栈构建AWS CloudFormation模板。然后，这些堆栈可以由您的IT部署在CI/CD管道中，或者通过自助服务设置（例如使用AWS CodePipeline）进行部署。例如，MDO（多学科优化）或DSE（设计空间探索）类型的计算密集型（但并行处理）作业可以包含在CloudFormation模板中，该模板可以部署短暂的计算部署，但具有持久存储。

因此，部署升降式MBSE的整个过程可以自动化，其中配置可以遵循最佳实践（安全性、成本优化等）。通过使用AWS身份和访问管理（IAM）进行适当的身份和访问管理（IAM），这些配置只能由授权用户构建/修改。

2.3.2 重构MBSE应用程序

我们建议重构，通过api和AWS托管服务将这些庞然大物分解为微服务。微服务方法可以进一步为您的MBSE工作负载带来灵活性，因为新技术可以通过Restful API （Amazon API Gateway）和GraphQL API （AWS AppSync）进行扩展。本章以MBSE后端图的形式进一步说明。

在重构过程中，您可以使用下面的任何建议——或者一次性全部采纳。您可能会注意到，您可以使用无服务器技术来提高成本效益，并完全删除基础设施管理任务。

你可以开始用api重构/重新架构你的数字线程。MBSE Digital Threads的重构之一是采用Amazon API Gateway，这是一个完全托管的服务，允许您大规模地创建、发布、维护、监控和保护API。

对于SysMLv2.0来说尤其如此，它为新的MBSE应用程序支持基于api的通信。您还可以考虑使用AWS AppSync使用GraphQL构建api，因为使用GraphQL更容易开发应用程序，因为它提供了使用单个GraphQL端点查询多个数据库、微服务和api的能力。

另一种重构是使用AWS Lambda，这是一种无服务器计算服务，可以让您在无需管理的情况下运行代码。您可以通过AWS Lambda函数直接对MBSE使用CRUD（创建、读取、更新、删除）操作。这些对MBSE特别有用，因为这些操作是事务性的，而且是基于事件的，比如在CRUD表单中。

AWS Lambda可以与Amazon API Gateway协同工作，在API Gateway触发时为您的数字线程带来无服务器业务逻辑。因此，AWS Lambda的毫秒级定价粒度允许您仅在需要时运行业务逻辑—并且仅使用时间（以毫秒为单位）。

您甚至可以使用AWS Lambda执行低保真MBSE模拟，只要模拟不超过最大15分钟的运行时持续时间，这是AWS Lambda目前的限制。AWS Lambda可以支持6个vcpu和高达10gb的内存，这为大多数低保真度模拟提供了相当大的计算能力。

AWS Lambda可以执行大多数MBSE模拟，而不限于CRUD操作。这可以使MBSE无服务器；因此，您可以从“毫秒级”成本粒度、高可伸缩性、可靠性和零管理业务逻辑中获益。

除了AWS Lambda之外，AWS Step Functions还可以帮助您使用状态机创建复杂的业务逻辑，以执行有状态操作。如果你更喜欢开源的工作流方式，你可以考虑使用Amazon Managed Workflows with Apache Airflow (AMWAA)，这是一种在AWS上为Apache Airflow提供的托管服务。您可以使用几乎无限的存储空间在Amazon S3上保存临时和永久数据，这是具有11倍持久性（99.999999999%）的经济有效的存储。

您可以使用Amazon S3 Lifecycle Management控制存储元数据的成本，它可以自动移动由您定义或由嵌入式AI确定的较冷或成本效益较低的层存储。

如果您想使用容器和Kubernetes而不是AWS Lambda，您可以选择AWS Fargate来坚持适合MBSE操作的无服务器方法。请参阅AWS上的无服务器以了解有关其他资源的更多信息。

下一个重构步骤是针对数据库的。MBSE通常同时使用关系数据库和非关系数据库。Amazon DynamoDB可以作为MBSE的低延迟键值和文档数据库。Amazon DynamoDB承担了服务器管理的负担，同时提供了MBSE所需的高度可伸缩且可靠的键值和文档数据库。

Amazon DynamoDB带来了几乎无限的吞吐量和存储，并具有11.9的持久性。全局共享的多租户和多区域MBSE应用程序可以使Global Tables等技术受益。此外，您的产品开发团队还可以从使用Amazon DynamoDB上的缓存和DynamoDB Accelerator （DAX）的低延迟中获益。

MBSE需要关系数据库。如前所述，您可以在Amazon RDS之上为您的MySQL或PostgresSQL数据库使用Amazon Aurora。Amazon Aurora的特点是分布式、容错、自修复的存储系统，每个数据库实例可自动扩展到128TB。与Global Tables类似，您可以使用Amazon Aurora Global Databases在消费者全局读取的MBSE中使用易于扩展的关系数据库。

Global Databases支持在多个区域进行快速本地读取（通常延迟不到一秒），并在整个区域的中断中提供灾难恢复。这些特性对于全球使用的关键应用程序（如MBSE）尤其重要。

最后，使用Amazon Aurora serverless，您还可以从MySQL和PostgresSQL数据库中的无服务器技术中获益。Aurora的另一个优势是它直接集成了Amazon Sagemaker，将机器学习（ML）和人工智能算法结合在一起。使用此功能，您可以将ML推理速度提高到x100。

所有不同领域和同一领域的多层次关系都需要一个本体图数据库。在这里，您可以从使用Amazon Neptune中获益。Amazon Neptune的核心是一个专门构建的高性能图形数据库引擎，针对存储数十亿个关系和以毫秒延迟查询图形进行了优化。Amazon Neptune支持Property Graph和W3C的RDF，以及它们各自的查询语言，如Apache TinkerPop Gremlin和SPARQL。

Amazon Neptune具有高可用性，具有读副本、时间点恢复、对Amazon S3的连续备份以及跨可用区复制。海王星是安全的，支持HTTPS加密客户端连接和静态加密。Neptune是完全托管的，因此您不再需要担心数据库管理任务和活动。

在开放共享数据之间寻找最佳平衡，以更好地协作和访问控制，以确保意外数据的安全性，而不是共享，主要是在航空航天和国防工业中。

使用AWS，您可以提供身份和访问管理工具，这些工具允许您在多个级别（包括资源、端点和用户）定义粒度访问控制和护栏。您还可以合并解决方案来考虑数据驻留，同时以您定义的方式为您的MBSE数据提供最小权限和联合访问。要了解更多关于身份和访问管理的信息，请访问AWS IAM网站。

2.4 创新

在本章中，我们将超越传统的MBSE软件和应用程序，其高级架构如下图所示。请注意，您在图中看到的“AWS…Services”图标表示一系列服务，而不是单个服务，这是为了将架构限制在特定的服务中，并简化图。

由于我们的客户对MBSE的需求是多种多样的，因此以下技术是模块化的，每个模块都是相互包容和独立的。因此，我们建议读者分别研究每个选项，同时保持整体观点的统一，以防所有解决方案可以同时应用。

本章解释如何：

• 将数字连续性层连接到您的办公室、边缘和车载设备，并以pb级的规模从数千个内部和外部资源中摄取数据。使用数字线程的编排层作为数字连续性的一部分来管理复杂性。

• 通过基于MBSE的扩展团队协作，在微工艺规模上扩展多学科/多供应商协作。

• 采用MBSE的智能数据（“带有工件目录的工件存储”）作为单一数据源，工程师可以在其中放置他们的excel， pdf，模型数据等。

• 为MBSE引入AI/ML，为MBSE提供本体、遗留文档集成的NLP，根据前面提到的整体运营/事件和数据获得有价值的见解和分析。

• 采用共享服务平台（SSP）来集中管理、管理您的应用程序，并为IT和工程实验提供安全的环境。

针对AWS上的MBSE的模块和AWS服务（高级架构）

2.4.1 数字连续性层

MBSE工作在一个复杂的环境下，在不同的期望下。这一事实要求任何MBSE环境都能在各种各样的软件、工作流和环境中展示互操作性。“环境”将涵盖各种各样的api，以便在本地/云混合配置中工作。数字连续性层通过标准化和编排带来了简化，从而增强了扩展MBSE的互操作性和灵活性。数字连续性的促成因素之一是api的编排。可以使用api标准化数字线程，并使用JSON执行消息有效负载。

如上图所示，第一个组件之一是数据网关。MBSE可以通过AWS的边缘技术（如AWS Outposts、AWS Wavelength、AWS IoT和AWS Storage Gateway以及Amazon SageMaker）扩展到现场，这些技术可以将计算、存储、业务逻辑、竞争交付、离线模式或机器学习带到边缘。

其中一个应用是数据摄取。可能会摄取各种各样的数据源。亚马逊Kinesis将带来pb级的数据摄取能力和实时处理能力，作为云上数字连续性的一部分。

如果你想使用一个开源平台来为你的MBSE构建实时流数据管道，比如Apache Kafka，但仍然想使用AWS，你可以考虑使用amazon MSK。数字连续性层的另一部分是ETL（提取-变换-加载）操作。

AWS Glue可以在无服务器模式下执行ETL。您可以创建AWS Glue工作流和端到端数据管道，包括其他AWS服务（如Amazon SageMaker）或外部端点（包括内部部署）。数字连续性还将涵盖现有的数据中心或设计办公室，其中数字连续性可以通过AWS存储网关等方式支持混合云环境。

此外，如前所述，您可以利用AWS的230多个全局存在点来进一步降低延迟并提高交互的可靠性。Amazon CloudFront和AWS Global Accelerator等技术可以通过这些边缘位置接管来自公共互联网的流量。

MBSE中的模拟是高水平的（低保真）和离散的。此外，这些进程是事务性的，而不是连续运行的。例如，产品设计的变更或需求的变更将与消息内容为“变更：元数据”的“事件：变更”相对应。

模型数据也可以按照UML（统一建模语言）规范进行标准化。因此，可以根据事件和基于事务（消息和事件）和附加元数据（主体）的简短模拟来表示整个流程。因此，您的MBSE可以将模型元数据转换为机器可读的轻量级可解释表示。简化和标准化为MBSE启用了事件驱动的体系结构。

您可以使用Amazon EventBridge作为无服务器事件总线，而无需使用任何代码。Amazon EventBridge将是事件驱动架构的一个基本部分，它通过事件地理来管理复杂性。

与Amazon EventBridge、AWS Step Functions或AWS Managed Apache Airflow（一种开源方法）一样，AWS管理的技术可以构建业务流程，并将MBSE和衍生工作负载的复杂性管理为业务流程。

数字连续性将充当编排MBSE和与MBSE相关的服务的“枢纽”位置，否则，它将看起来像下图中所示的“点对点”。然而，这种方法不允许灵活性，例如“点”（服务、api、边缘位置等）的任何更改都会阻碍解决方案的整体性能和可用性。因此，每个新服务或现有服务的替换（“点”）都将插入到编排器中。

通过数字连续性对工具、地点和平台进行编排和连续性。

在底层，消息代理/事件编排器充当单一源——就像中心辐射式体系结构中的“中心”。编排器由消息传递/队列和转换器组成。

需要消息代理将消息分发给接收方或在软件和API编排中执行发布/订阅关系。Amazon Simple Notification Service （Amazon SNS）和Amazon Simple Queue Service （Amazon SQS）分别提供托管的无服务器消息传递和队列服务，不需要您进行任何管理。如果您想使用托管服务，但使用开源消息代理（如Apache ActiveMQ或RabbitMQ），您可以选择Amazon MQ。翻译器部分需要完成互操作性部分。不同类型的应用程序和服务需要不同的格式。

JSON带来了标准化，但需要努力构建数字连续性的翻译器。您可以随时使用您的AWS解决方案架构师和其他资源，例如AWS合作伙伴网络（APN）和AWS专业服务，它们可以帮助您完成需要动手开发的任务。

2.4.2 扩展基于MBSE的团队协作

尽管MBSE正在慢慢被工业所采用，但现有的工程实践仍然存在。换句话说，工程师和实践者可能会彻底抵制使用MBSE。当然，其中一个原因是MBSE在互操作性和灵活性方面的局限性，无法适应已经被公司实践和完善的现有工程工作流。

此时，您可以将前面提到的活动扩展到阶段工程工作流。不同学科、不同供应商的人可以在微观层面的工程交易中进行合作。例如，假设团队希望在向MBSE或PLM提交任何内容之前对设计进行迭代。在这种情况下，他们可以通过使用传统的工作方式执行局部优化或“试错”。

尽管几乎每个活动都有工具，但并非所有工程师都使用它们，所以这是您可以将更多宏观活动引入微观活动的地方。最终，这将为可重复的流程带来自动化，使日常活动透明化，为这些日常输出使用单一数据源，而不必担心对它们进行分类。

基于MBSE的工作流管理

上图解释了基于MBSE的工程协作的概念。在这里，MBSE被视为“真理的单一来源”。然后，工作流是自动化和人工工作流的组合。

例如，如果一个团队从事FEA（有限元分析）操作，并要求供应商快速完成测试，他们可以通过工作流程平台的扩展进行协作，在必要时调用MBSE。在这种情况下，团队从MBSE接收需求或通过MBSE模拟需求，同时执行他们的优化。

同时，临时数据（例如电子表格、演示文稿和文档）可以存储在Artifact Store（即datalake）中。下面的图表提供了一些“工件”的例子。然后，AWS Glue Crawler可以对这些对象（工件）进行编目，形成一个可以通过Amazon Athena访问的数据目录。如果这些工件包括手写文档或表的“图片”，则可能需要Amazon text之类的技术。

对这种方法最重要的贡献之一是来自旧设计的见解（以及对其优点和缺点的分析）。在其他团队、未来的项目和其他部门可以使用公共部分和策略（包括分析、模拟）的行业中，这个概念被称为“通用性”。由于工件存储与MBSE本体一起工作，因此可以增强设计中的通用性。

例如，一个结构分析工程师团队可以查询旧设计的应力结果，看看他们如何利用从中吸取的教训。如果首选开源，则可以使用AWS步骤函数或AWS Managed Apache Airflow定义整个工作流。请注意，如果由于保密问题，您希望向工程师提供粒度访问管理和控制，则可以在该过程中指定授权和身份验证。

工件存储和工件目录

您可以在此设置中引入几乎任何工作流。例如，如果团队需要自动部署HPC集群来执行模拟，则可以将部署集成到此工作流中。结果和运行状态可以提醒工程或相关利益相关者。然后进入人工工作流，操作像这样继续进行。

在流程中对事务、状态和工件进行编目的整体可见性可以提高产品开发的速度。

另一个应用程序是源自MBSE的自动文档（报告）生成。这个过程也可以自动化，并且可以进一步增强，特别是使用无服务器计算。这可以为瀑布式工程实践带来更多的敏捷实践，例如航空航天和汽车工业。由于减少了流程中的人为错误，自动化还提高了工作质量。

工作流可以支持其他AWS技术和微服务。例如，假设团队想要批量嵌入自动HPC模拟，将模拟结果存储到Amazon S3存储桶（Artifact store）中，并自动进行编目，以便他们可以直接查询结果。在这里，流程可以按需自动执行。

同时，部署用于执行模拟的HPC可以“拆卸”，您只需为使用的计算时间付费。由AWS Glue执行的编目部分有其无服务器升级功能，也允许您只支付正在使用的部分（例如x分钟的编目）。

该过程是自动化的和颗粒化的，因此您只需要为正在使用的活动付费，并且团队不会将时间花在不为您的业务创造直接价值的过程上。成功实现这一过程的关键是使用AWS工作流管理工具（例如AWS Step Functions、AWS managed Apache Airflow等）和AWS基础设施堆栈（例如Cloudformation、Terraform等）嵌入这些场景。

正如下一节所讨论的，NLP人工智能服务，如Amazon Textract、Amazon comprehension、Amazon Translate和Amazon SageMaker，以及hug Face算法，尤其在Artifact Store中提供了价值。你可以把你的旧文件和前面提到的人工智能服务将帮助你阅读内容。您也可以创建自己的

最后一部分是将这种监控和透明度带给工程师和所有利益相关者。由于上面解释的整个过程是基于工件（即对象、文档、文件等）和元数据（事件、消息等），可见性是可能的。

使用AWS移动技术的移动应用程序与云上的活动跟踪器是异步的，这将使工程师能够更快地完成任务。此外，如果有问题发生，由于更好的可见性，工程团队和管理层可以更快地对问题做出反应。

我们这里的“可见性”指的是微过程中的透明性，您可以根据自己的需要来定义细节。我们相信活动中的“细节决定成败”；因此，我们建议使用粒度可见性。然而，上面解释的所有组件都是由您定义的。

2.4.3 面向MBSE的AI/ML服务

MBSE被设计为工程操作的中心。考虑到这一点，它提供了有关产品、工程活动、项目活动、需求、人力资源、遥测数据以及在数月或数年的操作期间的更多数据。因此，前面部分中描述的MBSE和支持功能可以提供关于您的产品、操作和项目的独特见解。

您可以使用AWS嵌入式分析（如Amazon Redshift和Amazon QuickSight）来监控、观察和接收商业智能和分析。

机器学习和人工智能可以提供更多的见解。这些操作数据可以预测交付日期、产品和项目中可能的瓶颈，以及基于历史记录的潜在缺陷检测。

• Amazon SageMaker提供有关活动和产品异常检测、模式检测和高级机器学习应用的见解。

• 亚马逊预测使用历史数据进行预测。MBSE中的活动和与MBSE相关的工作负载将构建一个历史数据集。这可以用于预测交付日期、时间表和工程资源的估计。

• Amazon Neptune ML在您的数据本体上执行基于图的机器学习。可能的应用包括本体中的模式检测、设计体系结构中的模式、流程中的最短路径和单点故障识别。

• 亚马逊Kendra将数据扩展到工程师手中的整个企业数据库。

• 亚马逊关注度量，以获得有关度量（任何定量数据）相关或相互关联的人工智能驱动的见解。这对于识别异常、边缘情况检测和模式检测以及缺陷尤其重要。

我们特别看到了利用NLP技术与数据编目（如AWS Glue）合并遗留文档并构建自己的语义的价值。

• Amazon extract从扫描文档中提取文本，手写和数据，超越简单的光学字符识别（OCR），以识别，理解和从表格和表格中提取数据。这对于扫描旧的设计文档、报告、语法图和pdf文件特别有用，这对于您的工件存储来说是一个有用的工具。

• 亚马逊理解提供对你的文本的洞察。Amazon领悟自定义实体可用于创建形式化语义并用于本体。

• 亚马逊翻译可用于翻译71+语言的文本。该服务可以在Amazon understand和Amazon text的基础上加以利用，从而在多语言协作环境中实现更好的协作。

2.4.4 共享服务平台（SSP）

MBSE必须具有统一的标准，以确保其安全性、兼容性和高可用性。集中式共享服务平台（SSP），有时也称为平台即服务（PaaS），可以用作简化部署代码的自助服务接口。您还可以在本节中使用Service Catalog使您的工程师可以使用PaaS。

有了SSP，运营商将完全控制定义与MBSE相关的安全、软件交付、监控和网络等标准。这允许您的开发团队更有效率，因为他们不需要自己配置和管理底层云资源。

SSP通常由您的中央IT团队，或通过云卓越中心（CCOE）团队或云基础设施团队构建。SSP由多个AWS或开源产品组成。

它通常支持运行应用程序的多个目标（例如Amazon EC2、容器、无服务器）、CI/CD管道、捕获日志/指标以及安全执行。SSP将这些工具打包成一个内聚的整体，并通过简化的界面（通常是命令行界面、图形用户界面或清单文件）使开发团队可以使用它们。

3.结论

在本文中，我们首先讨论了MBSE作为一种行业转型技术本身，并强调了当今MBSE采用和技术可能面临的挑战。

然后，我们解释了AWS如何帮助您应对这些挑战，并提供了可能的技术策略，从简单的提升和转移到为您的组织和项目实施附加技术，如数字连续性或人工智能驱动的见解。最后，我们广泛强调了AWS服务，这些服务将是为您的业务需求定制的解决方案的一部分。