引言

下一代系统建模语言SysML v2的正式规范即将发布，其全新的 文本化建模 、 标准API接口 等特性，预示着 MBSE （基于模型的系统工程）将迎来积极且深远的影响，涵盖 AI集成应用 、 数字主线构建 等多个方面。全球范围内，众多标准组织、企业和工具厂商也在积极推动和实践SysML v2的应用。

对于国内而言，无论是在企业数字化转型，还是对于行业从业者个人的职业发展， SysML v2都将是MBSE领域未来相当长一段时间的核心关注点 。对SysML v2及其潜在应用的深入了解，已成为绕不开的话题。为此，特撰写本文，以供参考。

本文章节安排如下：

1. SysML v2概述

2. SysML v2语言规范

      2.1 SysML v2语言规范组成

      2.2 KerML语言规范

      2.3 SysML v2语言规范

      2.4 SysML v1 > SysML v2转换规范

      2.5 API & Service规范

3. SysML v2与AI

      3.1 系统工程与AI

      3.2 AI系统需求分析

      3.3 SysML v2& AI

      3.4 MBSE & AI应用案例

4. SysML v2与数字主线

5. 企业和组织中的SysML v2实践

      5.1 NASA

      5.2 DoD & INCOSE

      5.3 Lockheed Martin

6. SysML v2软件工具

7. 总结

8. 参考资料

1. SysML v2概述

作为全球主流的系统设计建模语言，SysML自推出以来，已被广泛应用于各类系统工程项目中。第一代SysML（1.x版）基于UML Profile扩展机制，较好地解决了系统层级的设计数据表达和存储问题。然而，随着基于模型的系统工程（MBSE）不断深入，SysML 1.x在许多领域遇到了瓶颈，无法满足日益复杂的系统工程需求。因此，OMG（对象管理集团）启动了SysML v2的定义工作，旨在突破这些局限。

SysML v2的正式发布预计将在 2024年底至2025年一季度 之间。自2017年启动RFP以来，已有超过80家组织参与了语言规范的制定工作。2023年7月，OMG发布了SysML v2的Beta版本，目前最新版本为Beta 2.2 [1] 。与此同时，OMG也正在筹备 SysML v2语言认证考试 [2] 。

SysML v2在语言架构、模型展示、互操作性等方面进行了改进和提升，具体包括：

1. 语言架构 ：SysML v2摒弃了基于UML元模型的架构，采用了专门为SysML v2定义的KerML语言，并通过元模型和模型库的方式实现语言扩展。

SysML v2语言架构

2. 模型展示 ：除了传统的图形化展示，SysML v2新增了文本和表格形式的模型展示和 编辑方式。文本化展示为建模和编辑提供了更高效、简洁的方式，且具有更强的与人工智能技术结合的潜力。NASA等组织已开始探索此方面的应用 [6] 。

SysML v2的文本与视图展示

3. 互操作性 ： SysML v2定义了标准化的API和服务接口，旨在提升模型数据的开放性，解决模型数据依赖工具平台、跨工具集成接口难以迁移等问题。这一标准化接口对企业构建数字主线具有重要意义。

基于标准API的SysML数据交互

软件工具 方面，在SysML v2 beta版本发布后，十多家软件工具供应商发布了其对SysML v2的支持计划 [3] ，部分软件工具已具备基础功能试用。

在 企业和组织 方面，包括NASA、DoD、Lockheed Martin等在内的企业和组织都已着手SysML v2的转型计划，并积极投入到当前的语言规范定义工作中。

后文将对上述内容进行展开介绍。

2. SysML v2语言规范

本章节介绍SysML v2语言规范的基本内容。

SysML v2能力分类

2.1 SysML v2语言规范组成

SysML v2语言规范 目前在GitHub上公开并持续更新 [4] 。该规范由以下四部分构成：

a) Kernel Modeling Language（KerML） ： SysML v2的底层建模语言，替代了UML的底层元模型。

b) SysML Language Specification ： SysML v2语言规范，包含元模型定义、语义定义、文本和图形展示规范，以及案例讲解。

c) SysML v1 to SysML v2 Transformation ： 定义了从SysML 1.x版本到SysML v2的转换规范。

d) Systems Modeling Application Programming Interface (API) and Service ： 定义了模型对外的API和服务接口规范，涵盖模型数据的获取、导航和操作等。

SysML v2规范组成

2.2 KerML语言规范

KerML作为SysML v2的底层语言，提供了完整的 元模型、文本语法和语义定义 ，并支持 扩展机制 ，能够适应SysML v2语言或其他语言的开发。KerML仅定义了模型的文本（Textual）表示规范，尚未涉及图形化展示规范。

KerML语言分为三层架构：

a) Root Layer ： 包含最抽象的元素类型，用于结构化模型，如元素（Element）、关系（Relationship）和注释（AnnotatingElement）等。

b) Core Layer ： 包含一般的元素类型，通过分类（Classification）对这些构造进行语义定义。

c) Kernel Layer ： 提供常见的建模元素类型，如结构、行为和数据等。

KerML语言架构

KerML元模型 中的所有元素类型，以及每个元素类型在三个层级中的对应位置如下图所示：

2.3 SysML v2语言规范

SysML v2继承并扩展了KerML语言，形成了一套完整的系统工程建模语言规范。SysML v2对KerML的扩展包括但不限于：

a) 基于KerML 元模型 的扩展，增加了SysML v2层的元模型。

b) 扩展了 语法模型库 ，涵盖SysML特定的语法规则。

c) 定义了 图形化展示规范 。

d) 扩展了 领域模型库 ，支持特定领域的建模需求。

基于KerML扩展的SysML v2建模语言

在 元模型 方面，SysML v2扩展了KerML中的79个metaclass，增加了93个新的metaclass，进一步丰富了建模能力。

SysML v2 metaclass与KerML中metaclass的扩展关系如下图所示：

SysML & KerML metaclass

文本化建模 方面，SysML v2沿用KerML中的EBNF规则，并扩展定义SysML层元素的文本表达方式。通过下图可以看到，文本描述提供了相对间接、明确的模型表达。

SysML v2的文本和图形表达

图形化建模 方面，SysML v2采用类似SysML v1的图形化展示方式，但视图的种类做了变更，如下表所示。对于熟悉SysML v1视图的建模人员来说，这方面的变化很容易快速接受和掌握。

SysML v2中的标准View定义

2.4 SysML v1 > SysML v2转换规范

对于企业而言，通常如果某个研制型号已经固定了工具和语言版本，通常不会在研制过程中更换，但历史模型的 资产复用 和格式统一常常需要通过 模型转换 来实现。

《SysML v1 to SysML v2 Transformation》详细定义了如何从 SysML 1.7 版本的模型转换为 SysML v2 的规则，同时也可以作为对比SysML v1和SysML v2的参考资料。

SysML v1与SysML v2元素映射示例

由于SysML v2在未来MBSE和数字研制中的重要作用，美国国防部专门赞助了INCOSE SysML v2 Transition Activity Team 开展相应的研究工作 [5] ，对 建模工具选择、模型转换流程 等给出建议和示例。

INCOSE SysML v2转换研究部分成果

2.5 API & Service规范

《Systems Modeling Application Programming Interface (API) and Service》规范定义了标准化的模型数据API和服务，包括：

a) 平台无关模型（PIM）： 提供独立于平台或技术的服务规范。

b) 平台特定模型（PSM）： 将PIM与具体技术（如REST/HTTP、SOAP、Java等）绑定。

对于PIM、PSM、服务提供者、服务使用者之间的逻辑关系如下图所示：

API & Service架构

这一标准化接口为企业实施 数字主线 提供了便利，使模型数据的获取不再依赖于特定工具厂商的 API接口 ，提升了 集成接口的可移植性 ，并降低了工具选择变动对已有模型和集成接口的影响。

3. SysML v2与AI

3.1 系统工程与AI

随着人工智能（AI）技术的飞速发展，它在各种工作领域中的应用价值日益凸显，特别是在系统工程活动中，AI的引入已成为不可忽视的趋势。

在INCOSE发布的《系统工程2035展望》 [7] 中， 基于模型的系统工程（MBSE） 与 人工智能（AI）技术 被列为未来发展的两大核心内容。在未来的系统工程模式中，AI与MBSE的融合将为工程活动提供创新的人机交互方式，使工程师能够从繁琐的重复性工作中解放出来，专注于更具创造性的设计任务。

INCOSE SE 2035中的MBSE & AI

系统工程2035场景展望

作为MBSE的领先应用者， NASA 也将 AI 与 模型化技术 列为其数字化技术的六大核心之一，并通过大量的研究与应用推动AI在系统工程中的深度融合。

NASA定义的6项核心基础数字化技术

AI作为一项底层使能技术，其如何在系统工程的全流程中发挥最大价值，成为了当前研究的一个重要课题。为了深度挖掘AI在系统工程中的应用潜力，许多研究从不同角度对其 应用场景 进行了详细分析。

MITRE在其研究 [11] 中，从 系统工程流程 的角度出发，深入分析了当前系统工程模式中的痛点问题，并识别了AI能够介入的关键点。

Selive的研究 [8] 进一步细化了这一分析，不仅考虑了 系统工程流程 ，还加入了 模型数据生命周期的维度 -从模型的创建、应用、管理到复用，提出了更加细化的AI应用场景。通过这一分析，Selive识别出AI在模型生命周期中潜在的37个应用点。

系统工程流程vs模型生命周期角度的AI应用场景分析

Doug等人则在其新出版的书籍《AI Assisted MBSE with SysML》 [9] 中，专门探讨了AI在 概念建模、逻辑与物理架构建模、软件和代码自生成 等方面的潜力，并基于SysML v2语言开展了多个案例验证。

3.2 AI系统需求分析

在MBSE工作中开发、部署、应用一套AI系统辅助相关工作，那么这套 AI系统应该满足哪些需求 ？本章节针对此问题开展初步分析。

从 相关方 和 AI系统的全生命周期 两个维度综合分析，可识别出AI系统在MBSE中应用的潜在用例，示例如下。

MBSE & AI 用例分析

为支撑上述用例执行，对AI系统就提出了一系列核心的功能需求、接口需求等。

功能需求 方面，AI系统需要具备如 模型数据理解、模型数据生成、建模工具集成与调用、提示词指令响应、数据安全控制、AI升级与更新 等基础核心功能。

用例到AI功能识别示例

接口需求 方面，AI系统需要构建与各个外部相关方的接口，如AI对系统建模工具中 模型数据的获取、操作 ，系统设计与建模人员、研发管理人员等的 提示词输入以及对应的反馈 等。

AI系统与外部相关方交互的抽象接口示例

3.3 SysML v2 & AI

SysML v2中的文本化模型表示、标准API&Service规范，为支撑上述AI系统的建设提供了更简单、标准、开放的解决方案。

文本化的模型表征方式，使得SysML v2模型文本的 可读性更强、数据表达更简洁 ，天然适合与当前的大模型技术融合， 简化模型训练、模型数据理解、模型数据生成 等流程；标准API&Service规范，使得模型数据的开放性更强， AI与建模工具之间的集成更规范和通用， 可移植性更强 。

3.3.1 文本模型：与AI的天然结合

SysML v2文本化的模型是 人、AI、建模工具都可以直接理解的“通用语言” ，这意味着SysML v2原生模型无需进行任何复杂的前后处理，即可直接实现AI与人、AI与建模工具的数据交互。

相对而言， SysML v1模型的文本化表达 ，一种方式是使用xmi格式，但此种形式的模型表达存在大量 冗余信息 ，仅有几个元素的模型导出为xml就可能是几千行的数据，数据可读性相对较差，且通过AI 反向生成xmi的可靠性 完全无法保证，格式不正确的xmi将完全无法被建模工具解析；另外一种思路是自定义一套相对简洁的 中间数据格式 ，将模型数据的导入和导出按照此中间格式开展，但此种方式难度高、工作量大，企业自定义的中间格式缺乏权威性，以及长期看其可维护性较差。

以下以标准SysML v2文本模型和某通用大模型的交互为例，演示在 模型理解、模型生成 等方面的潜在应用。

SysML v2模型理解 ：基于SysML v2文本模型，自动生成针对 模型内容的概要描述 。

输入AI的提示词问题

AI对SysML v2模型的理解

SysML v2模型生成 ：通过文本指令生成符合SysML v2语法的模型，虽然生成结果在模型元素的 复杂依赖关系处理方面存在问题 ，但 基本语法正确 ，可以作为初步的参考和开始，后续通过更多的训练和优化，其将会有更好的表现。

根据提示词自动生成SysML v2文本模型

将上述生成的模型结果 导入到建模工具 ，得到的初步模型如下：

直接使用AI输出得到的模型

3.3.2 SysML v2 API规范：AI与建模工具的集成

如上文分析，AI系统要在MBSE中发挥更好的作用，必然面临与建模工具的集成问题。

下图是将 AI与建模工具集成 ，实现 从文本到模型 的流程示例 [11] 。可以看到，其中AI的输出响应对模型起作用需要通过调用建模工具所提供API实现。

而当前各类建模工具所提供的API都由各软件厂商自己定义，如果企业从一个建模工具平台切换到另一个平台（如国产化替换），则面临 AI集成接口 需要重新开发的问题。

AI和建模工具集成

SysML v2定义了标准化的API与Service规范，支持对模型数据的 标准CRUD（创建、读取、更新、删除）操作 ，使得AI系统 不再依赖特定建模工具 的自定义API，确保AI与各类建模工具的良好对接，这种标准化接口极大提升了AI集成的 灵活性 与 可移植性 。

3.4 MBSE & AI应用案例

3.4.1 NASA

NASA将模型和AI列为其数字工程的6大核心技术，在NASA的公开项目清单 [15] 中，与AI相关的项目检索结果有200余项，其中多数已实施完成。

在其“ AI for Systems Engineering, a Digital Design Assistant ”项目 [6] 中，NASA利用SysML v2进行模型构建与表达，并结合 GPT-3 AI技术，探索 模型识别、分类和检索 等任务的智能化。

NASA AISE研究项目框架

此外，在NASA的 Air Mobility Pathfinders (AMP)项目 [17] 中，NASA的Jet Propulsion Laboratory（JPL）也探讨了SysML v2与AI的结合应用

NASA AMP项目工具链

3.4.2 Boeing

波音Boeing就 生成式AI在系统设计中的未来潜在应用 做了分析和探索 [19] ，包含 设计模型生成、模型优化、基于文本描述生成模型元素 等应用场景，并通过技术实践，验证了AI在当前阶段能够实现的效果与存在的约束。

3.4.3 OMG SysML v2 pilot implementation

在OMG发布的SysML v2 pilot implementation中，内嵌了一个AI助手，可以开展针对SysML v2模型的解释等工作 [18] 。

5. SysML v2与数字主线

数字主线 [20] 是从 数据 的角度出发，构建贯穿产品全生命周期、可追溯、且数据源唯一的数据链条，涵盖产品概念定义、设计、制造、运行、退役等阶段，以支撑研发和企业决策。

数字主线概念图

数字主线构建的一个 关键挑战 在于，企业在不同产品生命周期阶段使用的工具通常各不相同，且这些工具的 数据开放性 存在差异。开放性较好的工具提供如OSLC标准支持和REST API等，但仍有部分工具无法提供数字主线所需的完整接口，这使得数字主线的构建面临一定挑战。

OSLC支撑数字主线构建 [7]

在数字主线的构建过程中， SysML模型 通常占据设计阶段的关键位置，并与 需求、详细设计、测试 等环节紧密相关，其所要构建的数据集成接口更多、更复杂。

SysML模型与数字主线 [21]

以SysML 1.x版本为基础的系统设计建模，在构建数字主线构建方面存在诸多挑战，如SysML模型中缺少与 专业领域相关的数据定义 ，导致SysML模型与详细设计模型的映射 必须通过定制化扩展 实现，而这种扩展 缺乏统一标准 支撑，维护困难；另一方面正如在AI系统与建模工具中讨论的那样，由于不同的SysML建模工具提供不同的API，当企业面临工具升级或迁移时，其前期构建的 集成接口 面临重建的问题。

SysML v2语言定义过程中很好的响应了这两方面的诉求。

一方面，SysML v2中构建了如下 领域模型库 ：

- The Metadata Domain Library

- The Analysis Domain Library

- The Cause and Effect Domain Library

- The Requirement Derivation Domain Library

- The Geometry Domain Library

- The Quantities and Units Domain Library

通过 领域模型库 的构建，支撑专业领域数据在模型中的表达，包含但不限于 数组 、 几何图形 等元素类型的定义。这将使得SysML模型能够更好的与各专业领域模型数据的 映射、集成、同步 。

SysML v2中的领域模型库内容示例

另一方面，SysML v2标准API提供了针对SysML模型数据的 标准CRUD方法 ，使得未来针对SysML模型数据的集成操作不依赖某个单独的建模工具或数据管理平台，从而提升数字主线中与SysML模型相关的集成接口的可维护性和可迁移性。

基于上述原因，在当前部分研究工作中，我们已经逐步在更多的数字主线构建工作中看到了SysML v2的出现，包含NASA JPL提及的 Dragon Architecture [16,22] ，以及已经发布演示应用的Syndeia产品等 [10] 。

Dragon数字主线中的SysML v2

Syndeia中的SysML v2支持

5. 企业和组织中的SysML v2实践

由于SysML v2的正式规范尚未发布，多数企业和组织的实践都在围绕SysML v2的技术探索、试点验证和转型规划。本章节以较为有代表性的 美国国防部DoD、INCOSE、NASA、Lockheed Martin 为例，介绍相关企业和组织围绕SysML v2的实践内容。

5.1 NASA

在NASA的Small Business Innovation Research/Small Business Tech Transfer已完成项目中，我们可以看到两个与SysML v2相关的项目，包含SysML v2+AI数字化设计助手项目、基于状态设计和仿真的故障管理项目，两个项目的技术成熟度都是从Applied Research开始，并希望通过项目将技术推进到Development阶段。

SysML v2+AI数字化设计助手项目

项目技术成熟度：开始和结束预期

基于状态设计和仿真的故障管理项目中的SysML v2

5.2 DoD & INCOSE

美国国防部Digital Engineering, Modeling and Simulation office (DEM&S)办公室赞助了INCOSE SysML v2 Transition Activity小组的“SysML v1 to SysML v2 Transition Guidance Project”项目 [5] ，以期更好的帮助企业和组织将MBSE活动顺利从SysML v1转换到SysML v2。

项目成果包含SysML v1到SysML v2转换的大纲和建议、SysML v2工具选择因素清单、SysML v2建模环境配置、模型转化流程、模型转化案例等。

SysML v1>SysML v2转换项目计划

5.3 Lockheed Martin

作为最早参与定义和应用SysML v1的Lockheed Martin，在SysML v2语言规范的定义方面也投入了大量精力，包含参与起草SysML v2 RFP、定义底层KerML等。

Lockheed Martin的MBSE历史

LM在SysML v2语言定义中的活动

在对SysML v2的态度方面，LM认为标准API、全新底层元模型、更全面建模概念支持等将为MBSE带来多方面的提升，同时也意识到语言换代带来的挑战不仅仅是工具升级的问题，而是近20年资产的转换。

为此，围绕SysML v2语言的转换推进，LM开展的工作包含：

1. 与工具厂商积极沟通

a）了解v2建模工具的开发实施计划

b）尽早试用

2. 成立企业级v2实施工作组

a) 熟悉v2语言的设计意图和当前开发状态

b) 构建测试环境，熟悉v2语言

c) 评估v2工具对企业内部自研工具、当前MBSE实践/指南、培训等的影响

d) 验证v2与其他工具的集成优势等

6. SysML v2软件工具

在SysML v2语言规范beta版本发布后，全球范围内十多家软件厂商都陆续发布了SysMLv2的计划 [3] ，包含但不限于 ANSYS - System Architecture Modeler、Dassault – CATIA Magic、IBM - Rhapsody、PTC - Windchill Modeler、Siemens - Simcenter Studio、Sparx - Enterprise Architect 等。

开源工具 方面，也涌现出了多款开源建模工具，包括OMG pilot implementation [12] , SysON [13] , SysIDE [14] 等。

此外，国内多家工具厂商也已着手开展SysML v2工具的开发，以期在新一代建模语言标准上，与国际上在同一时间发布。

宣布支持SysML v2的工具厂商

8. 总结

SysML v2语言的升级换代将逐步成为MBSE领域的主流趋势，为企业提供更加高效的数字化解决方案，助力企业提升质量和效益。然而，这一转变也意味着企业、设计人员和工具厂商需要投入大量的精力和智慧，以更好地应对变化并发挥其价值。

对于 企业 而言，如何充分利用SysML v2带来的增强能力，构建更为完善的 数字化解决方案 ，培养公司内部的 SysML v2专家 ，并有效管理 历史积累的数据资产 ，是需要尽早规划和探索的关键任务。

对于企业内部的 研发设计人员 而言，最终的战略落地需要依靠一线设计人员的执行。因此，尽早熟悉并掌握下一代建模语言，了解其潜在应用，以及如何将其 与自身工作结合 起来，从繁重、重复的任务中解脱出来，更好地 发挥个人创造力 ，将是亟待关注的核心课题。

对于 工具厂商 ，尤其是国内软件供应商来说，近年来的行业发展揭示了 MBSE领域人才严重短缺 的现实，而SysML v2带来的挑战和机遇远超当前人才储备的应对能力。因此，如何 在市场需求中精准定位 ， 避免重复建设和低效竞争 ， 实现差异化发展 ，不仅能为企业提供更多选择，还能为厂商自身带来更广阔的市场空间，是工具厂商需要深思熟虑的问题。