MBSE Data Interoperability Data Interoperability_Problem Statement, Assessment, and Go Forward Plan

近期在学习MBSE Data Interoperability Specification Report_Process Use Cases and Data Exchange Criteria，其中书中提到

项目团队的目标是评估航空航天和国防OEM及其供应商开发和传达系统设计要求、行为模型以及相应的系统架构的能力，这些都是通过数字数据建模标准实现的。团队一致认为，个别要求和行为模型的数据交换标准已经相对成熟，因此项目团队的注意力转向了如何利用支持ADL

在第一阶段，数据交换练习评估了在基于SysML（系统建模语言）的创作工具中定义的基于模型的系统架构的生成、交换和使用的可行性。相应的一组新系统设计要求被分配给模型的特征和元素。一个非常简单的子系统示例被用来进行演示，即一个轻控制系统。

在最初的概念设计场景中，OEM向供应商发送了一个基于模型的请求，要求供应商开发和定义他们的解决方案。OEM会分析返回的模型，并确定供应商的响应是否传达了他们满足所述OEM性能要求的能力。这个概念设计场景模拟了OEM如何从供应商那里征求设计提案，以建立系统或子系统的设计和开发的合同关系。数字化的交付成果包括系统规范

• SysML或基于SysML的架构图，以及相关的设计要求。OEM可以选择指定初始数字交换格式，而响应的项目团队成员可以使用任何可用的工具来完成数字数据交换。我们之前发表的《基于模型的系统工程（MBSE）数据互操作性》（Model-Based Systems Engineering (MBSE) Data Interoperability）立场文件提供了第一阶段MBSE数据交换练习的概述，以及对行业准备状态的后续结论。

这一篇文章就是用于记录学习Model-Based Systems Engineering (MBSE) Data Interoperability Data Interoperability, Problem Statement, Assessment, and Go Forward Plan

Executive Summary摘要

航空航天产品生命周期管理行动小组（AD PAG）是CIMdata全球认可的PLM社区计划内的航空航天原始设备制造商（OEM）和飞机发动机供应商的协会，它作为一个PLM倡导团体发挥作用。这个行业团体确定的一个关键业务问题是，在大规模、全球分布式的设计和开发合作伙伴供应链中，依赖传统的基于文件的开发流程严重阻碍了合作。

因此，这个团体确定的一个关键业务挑战是通过双向交换技术数据包来实现OEM和供应链之间的合作，采用数字工具和基于模型的流程。

作为回应，来自AD PAG成员公司的领域专家组成的项目团队已经成立，以评估当前数据互操作标准，实现基于模型的系统工程（MBSE）概念设计过程。该活动的目标是评估在协同产品开发活动中，通过数字需求和系统架构模型的交换来取代文件的可行性。到目前为止，已经完成了两个项目阶段。
• 第一阶段确定了基于SysML（系统建模语言）作者工具的能力在“开箱即用”的数据交换方面存在差距。
• 第二阶段考虑了在短期和长期内解决第一阶段识别出的问题的选项。

建议的短期解决方案是评估、验证和使用第三方MBSE互操作性软件工具/适配器，补充主要SysML创作工具中的基本功能，和/或使用翻译服务实现更强大的MBSE数据交换。从长远来看，该团体强烈希望看到数据和模型互操作性要求纳入SysML2.0建模语言标准，并将倡导所有PLM/MBSE解决方案提供商全面实施SysML2.0标准。

实现这种端到端的数字化和基于模型的策略，通常被称为digital thread，有很多经济业务动因：

• 通过更快的上市时间（更短的产品设计和开发周期）来增加市场份额和盈利能力。
• 通过独特的产品特性（与满足最终客户功能要求直接相关的设计特性）来带来更大的创新。
• 通过在产品开发生命周期中使用强大的数字模型而不是文件，来提高企业工程生产率和供应链合作。
• 通过减少总的研发成本、减少工程变更订单（ECOs）和减少物理原型迭代来降低研发成本。
• 通过持续的设计验证来改善产品质量和可靠性，而不是依赖基于文件的需求（通过在承诺到物理原型和/或制造系统之前对性能进行数字建模和仿真来优化设计）。
• 通过数字模型在其他领域需求上的演变来降低整个生命周期成本，包括制造、保修和运营（这个概念被广泛称为数字孪生）。
• 遵守全球行业倡议和法规（安全、认证、重复使用、绿色技术等）。

关于digital thread的标准化翻译，可以参考这篇文章
Digital thread中文术语标准化｜Digital thread何时是“数字主螺纹”的意思？

针对这些机会，航空航天和国防原始设备制造商（A&D OEMs）认识到，在大规模、全球分布的设计和开发合作伙伴供应链中，依赖传统的基于文件的开发流程严重阻碍了合作。为了应对这一挑战，原始设备制造商正在扩大其使用数字和基于模型的软件工具，以定义和管理整体系统要求；相关的系统架构；系统模拟；产品开发、认证、维护和安全性；以及监管/合同义务。为确保全面实施，原始设备制造商已经让供应链密切合作，通过交换概念性的数字模型来进行紧密的协作，这些模型在坚固且迭代的产品开发过程中来回传达设计意图，而不依赖于传统的文件、独立工件和/或图纸。

Goal and Approach 目标和方法

为了影响航空航天（A&D）行业中基于模型的协作的未来MBSE数据互操作性解决方案和最佳实践，AD PAG项目团队成立，旨在评估当前的数据互操作性标准，以实现基于数字模型而非文件的MBSE概念设计过程。这个项目团队的目标是评估典型航空航天供应商和航空航天原始设备制造商（OEM）的能力，使用数字数据建模标准，特别是SysML系统建模语言结合ReqIF（Requirements Interchange Format）标准，开发和传达一组系统设计要求和相应的系统架构。

在第一阶段，数据交换练习评估了使用基于SysML的作者工具定义的基于模型的系统架构以及新系统设计的相应要求的产生、交换和使用的可行性。一个非常简单的子系统示例被用于测试，即一个灯和其控制系统。最初的努力集中在一个概念设计场景中，其中OEM向供应商发送请求，要求他们开发和设计满足所述OEM性能要求的新系统设计的解决方案。

这个概念设计场景模拟了OEM如何向供应商征求设计提案，旨在建立用于系统/子系统设计和开发的合同关系。数字交付物应该类似于系统规格（SysML架构图）和相关的设计要求。OEM可以选择使用团队成员可用的任何工具来指定数字交换格式。

这份立场文件提供了关于第一阶段MBSE数据交换练习结果的概述，以及对行业准备状态的后续结论。

第二阶段的活动在2018年进行，项目团队的目标是在A&D行业中就数字数据交换达成最有前途的策略和最佳实践共识。第二阶段是基于最适合的一组MBSE数据标准和工具的当前成熟程度。

本文档的目的

本文档旨在传达行业中数据互操作性的当前状态，识别临时解决方案，并影响未来的MBSE模型交换解决方案和最佳实践，以促进航空航天供应链中基于模型的协作。

这份立场文件回顾了小组考虑的各种替代方案，并对在短期和长期内基于MBSE标准实现OEM-供应链设计协作的最有前途的方法提出了初步建议。

关于作者和认可声明

这份文件代表了一个由大多数AD PAG成员公司的主题专家组成的项目团队的工作。总体而言，团队来自这些公司的贡献者超过20位。经过广泛的审查过程，内容反映了所有成员公司的共识。无论其贡献水平如何，成员的认可表示他们对问题描述、目标和解决方案概念的主要观点强烈支持和同意。

Problem Statement 问题陈述

如“目标与方法”部分所介绍的，该项目的第一阶段旨在展示一个数字化的业务流程，用于生成、交换和使用适用于新系统设计的基于模型的系统架构和需求。所使用的简单示例是一个光源和控制系统设计。

第一阶段的期望是：
• 就实施数字化业务流程所需的行业设计能力的成熟度达成一致
• 就适合的行业数据标准和工具达成一致，以支持数字化业务流程

这个练习侧重于一个业务情景，要求供应商提供设计提案。供应商使用新的或现有技术来回应一个系统概念。

在这个业务情景中，OEM提供了交付物，以从供应商那里征求设计提案，并意图建立合同关系。这些交付物代表了规范控制定义、图纸或文件（SCD）、文件需求清单（DRL）和相关的业务程序。OEM的交付物规定了一个系统架构，格式以及数字数据交换所需的任何工具或行业数据标准。

Context 背景

对参与的成员公司进行了调查，以了解他们当前与新产品的系统工程相关的工作流程，以及与AD PAG项目成员有关的将参与第一阶段数据交换实验的MBSE软件工具。

截至2018年AD PAG成员使用的软件工具

对团队参与者进行了调查，以了解团队成员目前正在使用哪些工具、版本和适配器（翻译工具）。以下是调查结果。

OEM和供应商之间的数据交换流程

为了捕捉当前的流程状态，团队成员被要求定义他们在初步设计阶段与供应链合作的历史流程。这些示例作为确定未来基于模型的数据交换的商业案例的基础。

公司1

• 在早期设计阶段，沟通基于自然语言中的文本要求和初步设计描述，辅以图纸和图表；这些通过PDF、Word和PowerPoint文档传输。
• 合同的基础是采购技术规范（PTS），这是一个包含文本要求和可选的图纸和图表的书面文件。
• PTS可以通过包含更详细信息的附件进行补充。在某些情况下，这些附件从形式上（MBD）的行为模型中提取出来，例如Matlab/Simulink或SCADE。
• 此外，包含要求的DOORS模块可以被提取并转交给供应商。
• 3D模型被导出为STEP文件。

公司2

• 产品开发和采购依赖传统的规范控制图（SCD）格式来传达基于文本的要求，作为主要的沟通/合作机制。
• SCD辅以图像、表格和图表。SCD可能包括一个DOORS提取或模块，或允许供应商直接访问DOORS。
• 在某些情况下，行为模型的定义被添加为补充说明，但在大多数情况下，合作发生在实验室、SIL（软件在环）或HIL（硬件在环）中。

公司3

• 与供应商的初始信息交换是通过RFI（信息请求）进行的。要求在Teamcenter中，供应商没有任何访问权限。
• 第一个正式的交换是使用标准的SVCD（供应商控制规范图）或SCD，以及PCD（用于非CAD数据的采购控制数据集）。
• SVCD由要求、图纸、一些3D模型、零部件清单、属性和其他非CAD信息组成。

公司4

• 规范控制文件（SCD）格式（通常是DOORS模块）用于作为主要合作机制传达基于文本的要求。
• 经常使用行为模型（模拟或形式方法）来验证难以理解的要求。
• SCD辅以图像、表格和图表。
• 需求验证在实验室、SIL或HIL中进行集成时一起进行。

公司5

• 文本要求：OEM从客户那里收到一个PDF文件，然后将其中的信息输入到DOORS模块中进行内部工作。完成后，结果被转移到MS Word和MS Excel中的技术提案中。然后将提案转换为PDF文件并发送给客户。
• 图纸：图片被粘贴到.ppt（PowerPoint）文件中。（然而，这家公司正在转向基于模型的定义。）
• 3D信息：STEP文件以PDF文件格式的附件形式提供。

公司6

• 使用包含每个供应商所需信息的导出DOORS模块与供应商交换基于文本的要求。
• 在Simulink中开发的功能和架构模型用于补充要求。
• 对于捕捉供应商或合作伙伴不想分享的知识产权的Simulink模型，会添加编译代码作为替代。然后，这些dll（动态链接库）将用于在虚拟系统集成活动/分析中进行仿真。

目前状态评估 - 供应商与OEM之间的数据交换能力

利用一个共享的常用存储库，参与者进行了八次软件包交换，每次平均涉及三个设计项。假设成员公司代表行业能力的较高水平，参与者没有使用专门的工具或自定义，并且只使用了每家公司内已有的工具。成功的数字交换翻译发生的次数不到50%。解释设计意图的成功率大致不到20%。

团队的总体结论是，使用当前商业可用工具中所实现的数据标准的当前版本，尚不可行以交换MBSE系统架构和要求。尽管每个提供商的工具通常符合语言规范标准，但实施的导出和导入格式被确定为各个工具品牌的专有。以下表格显示了提供商工具之间每次往返的结果。在相同工具之间的往返是可能的，但只能使用原生文件格式。

以下是对主要与工具相关的发现的总结：

• 商业现成工具（COTS）的开箱即用功能不允许进行模型的导出和导入，即使是对于相同的工具。
• 商业可用的数据交换插件不容易用于不同COTS工具之间的数据导入/导出。
• XMI的实现在COTS工具之间似乎不一致。
• XMI不支持系统图（图形）的交换。
• 在第一阶段使用的COTS工具之间不支持系统图标准（图表交换）。
• 在使用的工具中没有实现行业标准或通用建模框架/本体。

根本原因

基于当前状态评估的结果，以及其他行业研究团体进行的类似研究，很明显，MBSE软件工具的当前成熟度以及与MBSE数据互操作性相关的标准是不足的，无法实现A&D OEMs与他们的供应商之间的健壮、双向和协作的概念系统设计过程。

Business Improvement Objectives 业务改进目标

这个持续性项目工作的预期结果是就MBSE数据互操作性策略和倡议达成一致，以基于适当的MBSE数据建模标准实现A&D OEMs与他们的供应商之间所需的有效协作的业务成熟度水平。

正如在之前的“投资动机”部分中所指出的，以数字形式而不是作为文本文档的方式数字化交换关键的概念设计数据，如需求和系统架构模型，预计将为A&D OEMs和他们的供应商提供显著的业务收益。所进行的工作着重于识别能够在短期和长期时间框架内相对于当前业务流程提供增量业务收益的解决方案。

Desired State 期望状态

为了制定一套可行的策略和倡议，进行了以下活动：
• 检查了不同的数据交换替代方案（包括使用中介进行文件转换、纸质方法）、数据格式、业务限制、工具组合和替代数据标准
• 确定了评分标准、解决方案优先级和解决方案的可行性
• 通过本立场文件向解决方案提供者/行业提供了建议

MBSE数据交换的替代方案

考虑了各种解决方案，以实现OEM-供应链的协作和交换，以解决当前状态评估的发现。

以下列表代表了可行的能力范围，这些能力在技术替代方案评估中被考虑。这些替代方案使用了多种评分系统进行排名，并进行了三轮多次投票。替代方案评估的基础是支持适用于体系结构描述语言（ADL）的数据交换能力，其中SysML是主要的MBSE系统建模标准。

ADL代表Architecture Description Language（架构描述语言），它是一种用于描述系统、软件或硬件体系结构的形式化语言，用于帮助定义系统的整体结构、组成部分、交互和行为等，从而实现系统工程的目标。在该文章中，SysML（Systems Modeling Language）可以视为一种ADL，用于描述系统工程中的模型和需求。

（以下列表的数字顺序并不表示重要性的级别；数字仅用于方便参考。）

1. OEM要求使用预定义品牌的工具（及其版本）。OEM将在合同中确定一个特定的提供商品牌和版本，用于供应商在其适用的工作说明书中使用的基于SysML的语言。
2. 手动将设计数据转换为特定格式（使用多个提供商许可证）。OEM将供应商的设计转换为可以与其他模型集成的形式。
3. 购买每个工具提供商的自定义插件进行数据转换。提供商的导入/导出插件似乎是为有限上下文中的点对点交换而设计的（在大多数情况下，没有图表，或者需要另一个提供商的许可证进行翻译）。多个插件品牌还需要至少一个可转换产品的许可证。预计会有一些数据丢失，并需要手动转录。
4. 确定并使用第三方基于软件的适配器（翻译工具）。有多个第三方翻译工具的品牌，通常设计用于模型的点对点交换。风险适用于新的软件版本和/或由专业工具功能生成的专有数据表示。
5. 支持一个提供商中立的行业研究组织（例如NIST）或大学研究计划，提供支持多个第三方翻译工具（适配器/MBSE工具插件）的Web启用的MBSE数据转换服务。OEM和供应商可以按合同使用此服务，将MBSE模型和数据从一个作者工具格式转换为另一种他们选择的格式。
6. 类似于替代方案5。支持一个中立的、第三方的商业互操作性服务，该服务提供了在使用MBSE提供商插件和多个第三方翻译工具（适配器）方面的专业知识。OEM和供应商可以与IT服务组织签订合同，购买支持在各种提供商格式之间转换各种MBSE数据的各种MBSE软件许可证和插件。翻译提供商还可以提供所需的专业知识，以验证结果并在必要时手动转换数据。与替代方案5相比，商业服务的模型转换结果的可靠性可能会伴随着额外的费用增加。这也可能是将其作为数据共享、模型存档、访问控制和安全性的协作IT环境的一部分的一种可能性和有益性，以实现OEM和供应商之间的标准化以及定制化的工作流程。
7. 使用PDM/PLM集成系统将设计合并到新的格式中（例如，从RDF到MOF或其他格式）。PDM/PLM提供商将替代方案5的能力与数据集成服务以及将所有数据导出到通用格式的潜力相结合。该能力可能已经在特定提供商的产品中实现。
8. 使用替代的ADL标准格式（ISO 42010）。使用非SysML/UML（统一建模语言）语言可能会取得更好的效果，这些语言已经被特定的工具提供商实现。可以选择几种专有或标准化的语言。然而，这个选项可能会涉及与培训、IT基础设施和A&D供应商的许可证相关的潜在新成本。
9. 使用替代的专有格式（例如，Simulink、Modelica）。有一些MBD工具实现了块式建模界面，可以创建功能性和逻辑性模型。虽然有限的支持可以用于分配和分解集成要求，但是如果实现限制在状态流程图中，SCXML（状态图XML）的翻译选项会增加。
10. 使用一组混合导出格式（例如，XMI + SCXML/UMLDI，JSON）。通过使用定制的语言翻译器来补充常规的XMI转换，可能会提高成功率并提供中性的表示。一些第三方工具已经使用这些技术并取得了部分成功。
11. 使用一种可以分解和暴露SysML产品结构的PLM系统品牌。类似于替代方案7，但PLM工具将SysML品牌转换为行业数据标准或专有格式，并从与更多OEM签订的附加许可合同中受益。
12. 行业推荐一个共同的架构框架。类似于统一的SysML配置文件，一个共同的架构框架将简化SysML模型的集成，但对于交换多个品牌的支持有限。这个选项将与另一个替代方案相结合。
13. 行业为所有架构模型确定一个共同的元模型和本体。类似于替代方案7，但依赖于新的或补充标准，而不是依赖于PDM或PLM提供商。许多SysML提供商计划或已经支持将模型转换为Web本体语言（OWL）格式。在转换图表方面可能会有一些限制，可能会发生一些数据丢失。该能力可能已经在特定提供商的产品中实现。
14. 将传统流程与现有的XMI功能相结合。OEM需要就对SysML设计进行文档增强达成一致，但部分模型和已发布的图表的组合可能会优于现有的“全部文档”流程。这个选项可能会被合理化为成本最低的替代方案。

通过将商业开箱即用的MBSE数据互操作性解决方案能力作为基准，团队在投票过程结束时缩小了以下三个备选方案。每个选择都进行了进一步的分析，假设最终的建议将代表最实际、可接受和迅速的解决方案。

1. 使用独立的、工具中立的、第三方服务来进行MBSE模型转换和数据交换，以实现OEM和供应商之间的协作设计过程。
2. 要求使用单一品牌的基于SysML的作者工具，结合系统建模语义和设计规则，创建系统架构模型。
3. 投资于纸质文档的手动转换。

备选方案分析

备选方案1：使用第三方软件适配器工具和/或MBSE数据互操作性服务

寻求一个与提供商无关的MBSE数据互操作性服务组织和/或大学研究组织，该组织将购买每个MBSE工具提供商的应用程序和选择的自定义插件，用于数据转换。所选的组织将与本项目团队合作，开发并演示一个或多个解决方案，以满足异构MBSE作者工具环境中的要求范围和SysML系统架构图。由于工具和行业标准的现状，短期内（一到三年）预计会有一些数据丢失。

Pros 优势:

• 允许供应商和OEM使用他们自己选择的提供商软件
• 防止对单一MBSE软件提供商的“锁定”
• 促进竞争，这有助于持续的技术改进 - 单一提供商占据支配地位会消除竞争
• 如果由多个行业OEM和供应商联合使用，每家公司的成本都会降低

Cons 劣势:

• 服务组织需要愿意在承诺在整个行业广泛使用之前投入软件许可证和IT基础设施的前期成本。
• 在大规模模型（如完整飞机）上未经测试。
• 这个选项可能不会立即适用于每个工具，工具的版本可能会遇到类似于不同品牌的翻译问题。
• 服务的每个用户都负责变更和配置控制。
• 在服务提供商最初投资后，提供商可能会更改API（应用程序编程接口）以停止或限制翻译服务的效果。
• 存在受XMI标准或专有产品功能限制的潜在风险。
• 我们知道我们通常可以在一个工具内交换数据，而任何交换工具、插件或服务都需要经过验证。

备选方案2：使用单个 MBSE 授权工具

在这种方法中，每个OEM都需要使用预定义的ADL工具品牌（及其版本）。OEM将在合同中明确指定一个特定的提供商品牌和版本的SysML（或其他适用的ADL），供应商将使用这些品牌和版本进行适用的工作说明。OEM将规定供应商在撰写和/或修改系统模型图和元素时使用的特定设计规则和配置文件。

优势：
• 立即可用 - 这种方法可以相对快速地实施。
• 短期内，与获取/使用数据交换工具或服务合同成本相比，这个选项可能更便宜。
• 从我们所见，这些类型的强制性流程在历史上通常用于数据迁移，而不是用于跨异构工具的协作。

劣势：
• 现有的OEM工具投资和其他商业现实将与在整个行业范围内采用共同品牌相冲突。每个OEM和供应商的软件选择都是基于其特定的技术、产品和竞争业务策略。
• 这个选项可能需要供应商为多个客户维护多个MBSE作者软件品牌。在汽车和航空航天行业，使用多个MCAD系统也存在类似的成本和效率问题。

备选方案3：手动转换纸质文档

这个选项将涉及手动将设计数据转换为特定格式（使用多个提供商许可证）。OEM将承担将供应商的设计翻译成可以与其他模型集成的形式的成本。

优势：
• 不需要新的技术或能力

劣势：
• 不能实现基于模型的流程和跨生命周期实施数字线程的承诺的业务收益
• 文档流程与数据交换的结合可能过于复杂，从而失去了任何潜在的好处
• 容易出现遗留错误和替代的集成/验证工具/流程
• 过程中的一个额外步骤，增加了延迟
• 与会随着产品开发生命周期而变化的需求脱节
• 缺乏变更控制和配置控制

Recommendations 推荐方案

鉴于当前的MBSE数据互操作性标准尚未足够成熟，无法完全实现数字化和基于模型的OEM-供应链协作系统工程流程，项目团队为未来的努力提出了短期和长期的时间框架内的建议。项目团队得出结论，将在第三阶段的项目活动中重点关注最有前途和可行性的解决方案，即备选方案1：使用第三方、基于软件的适配器工具和/或MBSE数据互操作性服务。

短期时间框架（一到三年）

AD PAG团队在MBSE数据互操作性项目中确定并推荐了以下在一到三年内可能在行业内实现的短期目标：

• 航空和航天领域应该推广使用ISO 42010兼容的ADL作为实施MBSE的建模基线。其他类型的建模语言将作为基线的补充。
• 行业应该定义、征求和认可一个提供商中立的MBSE数据互操作性服务规范，通过增强或替换现有的第三方适配器或插件，为每个MBSE工具提供商的应用提供覆盖范围。符合这些规范的服务将在整个航空和航天工业中使用的异构MBSE作者工具环境中提供重新生成所需范围的MBSE需求和ADL系统架构图的商业解决方案。
• 外部服务机构还可以提供协作的IT环境，用于数据共享、模型归档、访问控制和安全性，以便在OEM和供应商之间实现标准和定制的MBSE工作流。

长期时间框架（三到五年+）

为了实现短期和长期的数据互操作性标准，以便交换数字MBSE模型和相关数据，需要采用一个三方面的策略，并应在AD PAG成员公司内予以采纳。
• 影响并认可SysML 2.0 RFP内容，包括描述模型互换和正式语义的非强制性功能。建议将UMLDI（UML Diagram Interchange）规范或等效规范纳入未来的SysML规范，以支持图表交换。
• 积极参与定义和推广用于系统建模和仿真的共同架构框架，包括正式语义和A&D行业的系统建模规则/最佳实践。
• 鼓励我们的MBSE工具提供商优先考虑行业范围内的开放性交换策略，并在新的行业标准（如SysML 2.0）出现时尽快实施。

更长远的未来，该团体预期和相信，MBSE数据互操作性的当前标准将会演变和成熟，达到一个满足业务要求的开箱即用的软件能力水平。然而，当将这一进程与行业在实现合理水平的3D MCAD数据互操作性方面的经验进行比较时，以几十年为尺度的进展时间线在实现强大的MBSE数据互操作性方面显然是不可接受的。

因此，该团体将继续从这个工作组的集体知识中学习和记录，加速标准组织（如OMG、OASIS和Modelica）以及行业团体（如INCOSE、NAFEMS、Prostep ivip、Automotive Action Group（AAG）、NIST、DoD、NASA和欧洲航天局（ESA））目前正在积极努力评估和改进商业解决方案的进展。

不得不说别人的规划和系统性思维布局，真的是降维打击了

High-Level Requirements 高层次需求

除了对MBSE工具互操作性的要求之外，团队还确定了一些其他的长期、高级别的基于模型的工程（MBE）要求前提，在采用MBE方法之前需要建立和验证这些要求。这些要求列在以下表格中：

尽管上述列表在当前阶段可能还不足够全面，但AD PAG MBSE项目团队将继续与行业标准组织和MBSE倡议合作，以定义和完善实现跨领域系统工程的协作、模型驱动过程所需的最低要求。这一过程将涵盖A&D OEMS及其全球合作伙伴和扩展供应链。

前进计划

在2019年，AD PAG将专注于实施短期时间框架的建议（列于“建议”部分），并影响并协助定义下面所述的长期关键MBSE解决方案要素：

• A&D行业需要在高优先级用例的背景下了解自身的MBSE数据需求，以及为了实现有效的概念设计协作而需要交换的数据。
• 需要定义并解决一套设计表示/图表类型的优先级，这些优先级将由标准机构和行业联盟来定义。
• 行业需要为一个通用的、中立的第三方MBSE模型转换和协作服务定义业务案例和技术要求，这些服务基于商业可用的软件适配器工具，可以作为独立的解决方案或作为主要的PLM/MBSE作者软件工具的插件来使用。这些服务将由AD PAG成员认可并使用，基于他们的特定业务要求和投资回报率（ROI）。
• 应该监控并影响商业软件解决方案市场，特别是在MBSE数据互操作性和第三方适配器软件以及相关的IT协作服务领域。

AD PAG MBSE团队计划在2019年12月前提供有关2019年活动、成果和未来计划的更新报告。

见MBSE Data Interoperability Specification Report Process Use Cases and Data Exchange Criteria_December 2020待学习完附链接

附录：词汇表

个别中文解释：
Application Programming Interface (API)：一种机制，通过预定义的hooks，使外部应用程序可以通过系统的用户界面、技术函数和数据模型与系统交互。

Engineering Change Order (ECO)：一种文档，用于标识和描述对配置、组件或文档的更改，以响应ECP或ECR。ECO标识所有受影响的项目，还可以标识受更改影响的相关项目。此外，还定义了关于更改的元数据，例如更改类别、请求者、批准者、项目。ECO通常是更改或发布包的定义文件。（更改包是由ECO定义的一组文档，必须作为一组进行修改，以实现更改。）
Engineering Change Proposal (ECP)：ECP是一种文档，用于提出对产品、系统或流程进行更改的建议。ECP通常包括更改的原因、范围、影响、成本估算等信息。ECP可以由工程师、设计师或其他相关人员提交，以提出对现有产品或系统的更改建议。一旦ECP被批准，它将成为一个指导性文档，用于引导实际的更改过程。
Engineering Change Request (ECR)：ECR是一个正式的请求，用于提交对产品、系统或流程进行更改的要求。ECR通常包括详细的更改描述、理由、范围、计划和其他相关信息。ECR可以由客户、内部团队成员、供应商等提出，以表达对现有产品或系统的需要进行更改的要求。一旦ECR被批准，它将成为一个指导性文件，用于引导后续的更改过程。

Model-Based Engineering (MBE)：基于模型的工程是一种工程方法，它将数学模型（不仅仅是CAD模型）作为技术基线定义的一个组成部分，包括需求、分析、设计、实施和验证。在整个采购生命周期中，对能力、系统或产品进行定义。[1]设计可以记录在相关图纸中，也可以作为基于模型的设计。模型是系统的权威定义。近期关于基于模型的工程的参考集中在“基于模型的系统工程”。
[1]Final Report, Model-Based Engineering Subcommittee, NDIA, Feb. 2011.

Model-Based Systems Engineering (MBSE)：基于模型的系统工程是将各种级别的建模（从0D到3D）正式应用于评估系统需求、设计、分析、验证和验证活动的一种方法，从概念设计阶段开始，持续到开发和后期生命周期阶段。[2]在最直接的形式中，MBSE应用连续的建模范式（0D、1D、2D、3D…），从最简单的（0D）形式到完全定义的3D表示，然后进一步到更高级别的模型以了解时间问题。这是在书面要求、2D和3D CAD设计的背景下进行的。模型用于从非常早期的阶段开始验证系统是否会按照其要求的构思和定义进行功能。
[2]INCOSE Systems Engineering Vision 2020. INCOSE-TP-2004-02. San Diego, CA. September, 2007.

Product Lifecycle Management (PLM)：一种战略性的业务方法，支持在扩展企业内创建、管理、传播和使用产品定义信息的一致性一组业务解决方案，从产品概念到生命周期结束，将人员、流程、业务系统和信息整合在一起。