「基于模型的系统工程」的发展历程

节选自《「基于模型的系统工程」的发展历程》，因篇幅有限，完整报告文末领取。

当下，人们热衷于讨论基于计算机的建模、模型、数据库和敏捷设计方法。然而，很少有人会耐心地审视和理解大量的技术创新，这些技术创新和发明是我们当下发展MBSE 技术的重要基石。从近几十年 MBSE 相关技术的发展来看，现在的 MBSE 方法是「站在巨人的肩膀上」所提出的技术创新。如图1所示，MBSE 发展分为五个阶段，在下文中将进行一一介绍。

MBSE孕育期

在这里插入图片描述
MBSE 可以理解为一种工程模型，在 MBSE 启蒙期前，也曾经出现过各类工程模型，这段时间我们定义为 MBSE 孕育期，如图2所示。被认为最早的具备工程特性的模型出自迦勒底的一个叫哥弟的工程师之手。

他在公元 4000 年前，在一个石板上画出了一个要塞的图形，这个石板现存于巴黎的卢浮宫。从石板上可以很清晰地看出它所表达的含义，木头、蓬草、石头等。公元前 5 世纪，希腊数学家阿基米德、毕达哥拉斯和欧几里得创建几何学。希腊建筑师坚持对几何学的研究，并于公元前 4 世纪，将几何应用于帕台农神庙的建立。

在公元前的最后几个世纪，罗马建筑师马库斯·维特鲁威发表题为《建筑学》的十卷论文，直到 19 世纪，这份著作都起到了十分重要的作用。公元 1100 年，宋代李诫创作了建筑学著作《营造法式》，该书成为北宋官方颁布的一部建筑设计、施工的规范书。

在 18 世纪，法国数学家、设计师 Gaspard Monge 提出了采用几何技术解决工程设计问题的思想。法国政府对他的贡献十分认可，并将其思想和相关资料秘密保存了将近 20 年。最终到 1795 年，他才被允许在大学中建立了工程师的培训体系，将他的思想向普通工程师推广。

18 世纪初叶，美国国家国防教育机构建立了图形化研究中心，Christian Zoeller 在 1807 年开设了首批绘图课程。在1926 年，美国国家标准研究所、美国工程教育协会、美国机械工程协会提出了建立机械制图规范草本。在 MBSE 孕育期，科学家关注的工程模型偏向于几何模型，目的也是基于几何技术实现对于工程问题的解决。

MBSE启蒙期：20世纪60年代

直到 20 世纪 60 年代，MBSE 技术进入启蒙期。这段时间对商业及工业计算领域来说，是最富有成效的十年。作者对这么早的时候提出、被人们接受、并进行大量实践，感到十分惊讶。因为，在这段时期，大型计算机还被认为是一种新兴技术，没有多少人能真正了解其全部潜力。随着不断提出新理论、硬件和软件，大型机被广泛应用于工程技术，具体案例如下：

数据库设计
早期用户参与被认为是关键的成功因素
功能分解和定义模块化的规则
定义早期的形式化方法
首次提出软件生命周期

**数据库。**MBSE 生命周期的横轴向集成及管理，在很大程度上依赖于信息存储技术，而近些年信息存储技术的成功又归功于最早期数据库的成熟。随着硬件性能的不断提升，早期的计算机科学家开始研究软件开发过程中的人因要素。当新一代编程语言开发出来时，人类程序员不再需要像机器一样思考，他们可以更加专注于编写代码的过程。

这真是一幅因为太真实而让人感到滑稽的讽刺画：管理者离开满是忙碌程序员的房间说道：「开始编程吧，我去看看我们的客户想要什么。」它表现了当时技术界普遍存在的傲慢，并不是所有人认为早期用户参与软件项目是项目成功的关键因素。

**形式化方法。**在新兴的 IT 行业中，程序员团队如何一起工作和相互沟通是一个值得关注的问题。结构化编程和对形式化方法的研究始于这个阶段，这对 MBSE 的发展至关重要。

常遭人诟病的软件开发生命周期瀑布模型也出现在这个时候，这个新概念消除了人们认为软件开发是随之任之的艺术形式的错觉，并为后续的系统及软件生命周期研究提供了一个基础参考模型。北约科学委员会（NATO Science Committee）于1968 年和 1969 年召开了两次具有里程碑意义的会议，推动了这一势头的发展。

**模块化。**物理系统的模块化为大规模生产带来了经济增长，同时促进了工业设计和制造技术。它将系统分解为具有明确定义和接口的单元并通过它们的交互来实现设计。在 David Parnas（1972）的研究中，首次提出将模块化应用于软件的设计模式。同时，Stevens，Myers 和 Constantine（1974）提出了更加便捷的系统分解方法。

**康威定律。**Melvin Conway 在 1968 年发表了他的假设（Conway 1968）:

Any organization that designs a system will inevitably produce a design whosestructure is a copy of the organization’s communication structure.

系统认知和项目团队创建对系统研发所带来的效果从古至今是一样的。如果项目团队在定义工作模块之前就已经创建了，那么产品系统的主要组件数量和特性将根据组织结构来定义（例如，系统的三个分包商建议用一个系统分解为三个主要系统组件或工作包）。这样的组织并不一定是坏事，但是它表明模块化定义的规则并没有推动系统设计及功能组件的分解，从而导致模块化定义要次优于生产组织结构。

MBSE上升期：20世纪70年代

在 20 世纪 70 年代，计算机的体积随着计算能力的提高而减小。对于这个仍处于起步阶段的新兴行业，技术人员渴望找到提高工作效率和产品质量的方法，以及更加优秀的计算机技术和方法。在这十年里，我们首次认识到在产品研发过程中，人和时间不是可互换的资源。这一时期的技术包括：

CASE/计算机辅助软件工程（从需求工程开始）
结构化方法 (Dahl, Dijkstra and & Hoare 1972)
面向对象方法 (Dahl, Myhrhaug and Nygaard 1970) 迭代和进化的生命周期
程序规格复核和检查
成熟度网格

CASE。当计算机被应用于工业创新时，计算机精英也在寻找将它应用于软件开发的方法。CASE 工具提出一种可以摆脱单调乏味和容易出错的编码工作方式。DanTeichroew 和 E.A.Hershey 创建的 PSL/PSA（问题陈述语言 / 问题陈述分析器），是一个关系数据库，用于维护系统需求，并描述它们与后续设计和研发文档的关系。这套系统通常被认为是最早的 CASE 工具之一。

他们提出的目标很明确：「引入软件开发支持基础设计框架，以中央计算机化数据库为基础，提供一套完整的设计工具」。在这一阶段，这些系统主要服务于文档管理工作。但由于其功能逐渐完善，许多研究和开发工作都在朝着根据特定计算环境的功能要求来设计可执行软件的最终目标迈进。

随之而来的是更多复杂的工具，但这些模型定义及用他们替换代码花费了数年的时间。CASE 工具是 MBSE 的祖先，他们的发明人和倡导人提出利用术语及规范来定义所需模型在其软件中解决实际问题的愿景和总体目标。

他们通过数据存储方式来促进沟通和资源协调，同时发现，目前领域研发软件之间互操作性所带来的集成问题有很大的技术限制。然而，功能建模和自动代码生成技术推动了 CASE 工具的普及，这些方法构成了现代 MBSE 的基础，这套技术的两位主要贡献者是 Wayne Wymore 和 MackAlford 。

前者提出了数学系统理论，支持系统设计的过程，该理论称为Tricotyledon 理论。Tricotyledon 理论基于集合论提出一种描述系统及需求的语言。用该语言可以建立状态机节点的数学模型，以描述需求与需求之间的关联关系。后者发明了 R-Nets 对系统中的信息流进行建模，支持完整性和一致性的自动化检查，以及需求文档的自动生成。同时，解释性结构模型被提出来提供系统图论的迭代应用，用于描述元素之间的关联关系的文本式表达。

**面向对象方法。**该方法提供了现实世界映射到软件虚拟世界的落地方法。同时，科学家在软件开发生命周期中提出了关于迭代开发流程的诉求。在 2009 年，很多研究人员认为系统工程的成功与否与能否应用这些实践有关。

**工程评审方法。**通过引入同行评审的方法，防止个人做出错误判断并提升交付产品质量。Cosby 的质量成熟度网格包含不确定性、觉醒、启蒙、智慧和确定性这 5个阶段，是随后的成熟度模型的先驱。所有这些研究都有助于实现在 MBSE 的全生命周期里的无缝沟通。

MBSE发展期：1980–2010

在 80 年代初期，海外研究人员发现能一劳永逸地解决所有软件工程问题的方法是不存在的。许多技术创新仍在不停支持工业软件解决工业问题的技术革新。几个MBSE 的典型技术在这个阶段被提出，因此我们称这个阶段为发展期。其中有几个亮点技术，值得一提：

统一建模语言（OMG）于1997年结束了面向对象方法争论
软件重用
配置管理
CMM和CMMI（SEI）
架构
敏捷方法

**UML。**在20世纪80年代末和90年代活跃于软件开发行业的人都记得面向对象方法的争论，因为每个领域牵头人都尝试引入他们自己特殊的建模符号：云型与矩形等等。在对象管理组织（OMG）的努力下，建立了一套统一建模符号，即UML，于1997年问世。

UML嵌入了状态机，状态转换图表规范。这种规范拥有自己的交互式图形输入、仿真工具和代码生成工具。这种「状态机」在CASE工具的研发中，取得了一个重大进步，因为它对于精度和符号语义的关注，可以为不同的领域概念，提供不同的图形化符号与分层式模型结构。这些新特性很好地支持纸张、屏幕和对模型大小的认知限制等问题（语义相关概念将在下一章 SysML2.0 与KARMA语言章节介绍）。

**SysML1. X及其他建模语言。**INCOSE在与OMG的合作中发挥了重要作用，将系统特定的元素引入建模语言，从而产生了SysML。在MBSE的领域中，人们已经将经常使用的SysML建模语言集成至MBSE工具，类似建模语言还有OPM，BPMN，EAST/ADL，UPDM等，各类语言在各自领域承担了统一符号化表达的重任。

**重用。**面向对象技术的支持者经常依靠软件或代码重用控制软件生命周期成本。如今，在MBSE环境中也有类似模型重用的概念，重用技术高度依赖于数据存储、检索和版本控制的相关要素，而且在开发管理方面还需要研发人员遵循于良好的设计规范。

模式（Patterns）是一种从面向对象社区中产生的软件工程问题解决域。模式在许多学科被广泛应用，最著名的是Alexander在城市规划和建筑方面的工作，其实现了代码生成中的主动重用和「最佳10实践」。

**配置管理。**如前所述，MBSE的生命周期应用高度依赖于控制基线和修订控制系统。

**质量。**软件质量一直是业界关注的首要问题。能力成熟度模型（CMM）最早发表于1993年。INCOSE曾提出倡议，将系统工程的关键过程和活动纳入一个集成的CMMI。MBSE要求这些模型进一步成熟，以定义维护生命周期模型的横向及纵向规划。

**架构。**架构的早期定义集中于领域分析、产品线和战略管理等领域。Leveson的工作表明，安全（人和自然环境）等因素必须包含在早期的系统需求设计过程中，这就需要在架构设计中尽力考虑所有利益相关方的关注点及对应视角。

**相关工程方法。**关于工程方法的讨论很多，涵盖了原型设计、敏捷设计和精益工程等不同主题，它们都表明MBSE落地依赖于规范和工程实现之间存在的紧密联系。其中，形式化方法的众多支持者更加关注模型的价值。

在软件开发领域的研发人员也面临类似的挑战——他们研究的重点是在集成建模环境中，研究基于模型的一体化开发（数据集成、模型集成等类似概念），即是否可以一种模型包打天下（这部分的难点将在下节中介绍）。图3中描述了过去50年中取得的研究进展。

他们追求的目标是使用更高的抽象层次将软件开发重用率提升到最高，使模型不再是方法论的一部分，而是代表一种支持完整软件生命周期的范式，并使软件开发人员更加接近用户领域（参见DCI）。对MBSE来说，类似的观点可能是我们最终是否能够用具体的产品和其他系统元素来代替「代码」。

正如图3中所示，在早期研发过程中，采用纯代码及文档配合的研发模式，实现基于文档的研发过程。随着建模技术被初步应用于软件及系统研发，工程师采用以文档为中心的研发模式，使文档、模型及代码有机配合，提高研发效率。在这期间，部分代码进行模型化表达，实现代码即是模型。

随后，建模技术的不断发展促使研发方法从文档为中心向模型增强方法转化，实现构建一定抽象能力的模型并实现模型与代码的双向同步。在这种设计方法中，文档的应用将逐步弱化。

当使用以模型为中心的研发方法时，采用建模技术实现研发过程中的代码及方案的自动化生成，实现模型即为代码和方案，这个阶段文档将逐步地被模型取代。最终，实现基于模型的系统工程的研发方法，实现工程师构建模型即自动生成代码及方案，到这个阶段，设计人员就不需要关注代码了。

2010 年以后，迎来了 MBSE 的调整及复苏期。本章节，将从 INCOSE 国际系统工程学会角度，介绍这一时期所提出的 MBSE 相关概念。MBSE 利用统一化、标准化、规范化、形式化及图形化模型实现从概念定义、方案设计、试验验证到工程实施的产品研发周期全过程管理，其核心是建立起以模型为中心的系统工程管理体系。

国际系统工程协会（INCOSE）于 2007 年发布的《SE 愿景 2020》中，对基于模型系统工程提出定义：

「MBSE is the formalized application of modeling to support systemrequirements, design, analysis, verification and validation activitiesbeginning in the conceptual design phase and continuing throughoutdevelopment and later life cycle phases」（对建模的形式化应用，用来支持系统的需求、设计、分析、验证和确认活动，这些活动开始于概念设计阶段并持续到整个开发及以后的生命期阶段。）

自从 2007 年初，INCOSE 面向工业界及学术界发起MBSE 倡议开始，此定义逐渐被业界普遍接受为 MBSE 标准定义。针对此定义，《SE 愿景 2020》中有如下解释：以模型为中心的产品研发方法被广泛应用于机械、电子和软件等工程领域，并将取代原来系统工程所提倡的以文档为中心的设计方法，而 MBSE 正是向以模型为中心的产品研发方法转变的重要一环。

INCOSE 英国分会在 2012 年发布的系统工程系列「MBSE 是什么」技术报告的第一版中除引用 INCOSE 标准定义外，对MBSE 定义有如下解释：MBSE 使用建模方法分析和记录系统工程生命周期的关键要素，它有着极强的适用范围，横跨整个系统生命周期，纵跨体系、系统及单一组件；

在2015 年发布的第二版引用《系统工程中的 SysML》一书中的定义：MBSE 是由逻辑连贯一致的多视角系统模型驱动进而实现系统研发成功的技术手段。其相比于基于文档的系统设计方法，具有如下特点：

设计要素表达无歧义性。产品研发的相关信息描述经常会因个人的知识差异而产生不同的理解。由于模型是一种高度图形化的表示方法，具有图形化、统一化、标准化、模块化等优点，建立系统模型进行精准统一地描述系统工程相关信息，可以提高参与人员之间理解的一致性，实现设计信息的无歧义表达。

研发人员沟通交流效率的提高。随着系统规模和复杂程度的提高，各种文档越来越多，相对于厚厚的技术及研发文档，阅读图形化的模型更加直观，再配以适当的注释，使得不同的人对统一建模规范的同一模型具有统一的理解，同时也使计算机更好地理解相应模型的信息描述，有利于提高系统研发各部门之间的沟通、交流及协调的效率提升及计算机辅助管理能力。

体系、系统、子系统及组件的一体化设计。由于系统模型的建立涵盖了产品研发的整个生命周期，包括系统的任务定义、体系设计、系统能力分解、需求分析、系统设计、架构设计及分析、系统验证和确认等活动。因此能提供一个完整的、一致并可追溯的一体化设计方法，对于保障系统设计一致性管理、追溯性管理及复杂度管理，避免各部分的设计冲突具有十分重要的意义。

增强设计知识的自动化捕捉能力和可重用性。系统研发生命周期中，包括很多点对点的信息创建、删除、修改、查询等过程，如设计人员需要提取客户所提出的需求信息来进行系统的设计。由于模型具有模块化及统一数据源特点，使得信息的捕捉、获取、转换以及再利用都更加方便、有效。

可以进行多视角信息表达、分析及验证。通过模型底层的唯一数据源统一信息表达，支持研发信息的多视角表达及分析。基础计算机辅助设计及分析方法，支持各部分变更对系统本身可能造成的影响分析，并可以在早期进行系统的验证和确认，从而降低设计变更所带来的时间和费用上的设计风险。

INCOSE 于 2007 年发布 2008 年更新的《MBSE 方法学综述》中，对 MBSE 方法学完整的研发体系及其各要素之间关系进行了解释：MBSE 顶层体系愿景包括研发流程、方法论、语言和工具，以支持基于模型、模型中心或模型驱动环境下的系统工程。以《SE 愿景 2020》英文定义为基础，结合 MBSE 方法学综述，本章节结合林雪萍先生所提出中文 MBSE 定义对 MBSE 概念进行中文描述：

基于模型的系统工程是一种采用形式化建模技术的正向设计方法，用于取代传统的基于文档系统工程的研发模式，以统一的体系、系统、领域、项目规划及生命周期管理的多架构视角，包括体系工程视角系统工程视角（需求、功能、逻辑、物理、架构及验证）等模型集为集成研发框架，实现跨领域研发信息的可验证、可追踪、可共享的全生命期内的数据及知识的动态关联，进而贯穿于从概念方案、工程研制、报废更新的系统全生命期、以及从体系、系统、子系统及系统组件的各层级系统工程过程和活动（包括技术过程、技术管理过程、协议过程和组织项目使能过程）。

英文定义中 MBSE 是一种狭隘的形式化建模技术的工程应用，INCOSE《MBSE 方法学综述》将 MBSE 具体化为一种方法学。考虑到作为 MBSE 使能技术的标准建模语言逐渐与 MBSE 过程和工具相融合的发展趋势，以及《SE 愿景 2020》从过程和研发流程、方法论、建模语言和建模工具等几方面讨论出的 MBSE 的现状和发展趋势，中文定义引入广义 MBSE 的说法，将英文定义中的狭义概念具体化为由图 4 和图 5 结合而成广义MBSE 方法学。

因此，对于相关的 MBSE 技术，集成相关研发流程、工具、方法论和建模语言等要素，实现具备跨语言数据集成，是下一代 MBSE 建模语言解决生命周期数据互用性及多视角、全要素大一统集成和开放性等问题的核心要求。2019 年，ISO/IEC/IEEE 准备发布《系统及软件工程的基于模型的系统及软件工程方法及工具》标准，这意味着 MBSE 技术正在走向成熟。

SysML2.0 和 KARMA 语言。目前，INCOSE 和 OMG 等组织的专家研发的SysML2.0 语言与洛桑联邦理工、瑞典皇家理工、北京理工大学、上海交通大学、北京中科蜂巢科技有限公司等机构合作开发的 KARMA 语言采用均文本式建模方式。其中KARMA 语言已推进在多家高校、国内外航天、航空、兵器、电子等相关工业部门、国内外多个国家级（欧盟级）及省部级（瑞士创新项目）科研项目落地验证。

SysML2.0和 KARMA 语言均采用文本及语义式建模方法，其核心的目标如上文所述实现语言的统一描述及表达。下面将以 SysML1.6 及 KARMA 和 SysML2.0 的比较来阐述为何新一代建模语言逐渐由图形化规范向语义为主的规范模式改进。

如图 6 所示，MBSE 语言的目的是实现 MBSE 形式化。MBSE 形式化，即使用 MBSE相关语言、技术和工具，采用形式化（计算机可读、可理解）的表达方式，对系统进行模型化表达。参考本团队的相关文章，MBSE 形式化包括：

具体语法用来显示特定域建模语言中的图形化表达或文本化表达，例如图 6 中语言中（1，+，2）可以被看成是文本式的具体语法（文本化表达），而 1+2 所代表的抽象语法是数字 1 与 2 之间相加（模型的组成元素之间的描述规则）。UML 语言中class 类的图标代表指定类（图形化表达）。
抽象语法定义了建模语言的组成元素及他们之间所构成的关系的连接规则。如SysML 需求图中需求模块之间可以通过六类关系进行连接，其中的连接规则要求即为抽象语法。
语义定义模型在领域中的含义。其中包括语义定义域（什么含义）及语义映射（如何赋予模型含义），具体解释如图中例子。例如，以图中的 1+2 作为一个模型的例子。（1，+，2）可以被看成是文本式的具体语法。而 1+2 所代表的抽象语法是数字1 与 2 之间可以添加「＋」（模型的组成元素之间的描述规则）。这个例子中的语义定义域是自然数的运算，通过语义映射来执行运算。因此，1+2 的含义阿拉伯数字的加法，即为 3。

在以上概念基础上，介绍现在 SysML1.6 与 KARMA 语言或 SysML2.0 的区别。

如图7所示，SysML1.X 为图形化语言，因此规范中规定了图框代表什么，模型中涵盖哪些内容，其对应的图标是什么。基于 SysML 规范，各建模工具开发各自模型库。这会为使用建模工具来建模的过程中带来若干问题：

由于各工具采用技术路线不同，因此可能存在对规范的理解不同，可能出现基于相同规范，但是在不同建模工具实施方法不同，如同样基于 SysML 规范，时序图在 Magic draw 中采用的表达与Rhapsody 中采用的表达（同步信息组件的固定语法不同，条形及圆角框）不一样，虽然两个工具中所描述的本质信息都相同，但是从前端表现上不同；

为了可以实现不同 SysML 工具之间的交互，基于 SysML 规范，研发了 XMI （ XML MetadataInterchange）的文本语言。XMI 文本语言本质与 SysML1.X 上所描述的内容相同，但是却是两种不同语言；

在使用 XMI 进行 SysML 建模工具的模型交互过程中事实上集成的是 XMI 语言，而非 SysML 语言。这同样对建模工具提出了较高要求，即需要支持两种语言的语言解释器及编译器。为了解决这种问题，SysML2.X 和 KARMA 语言，采用文本式（语义式）建模规范，将图形化表达和语义文本表达集成，因此在建模工具中只需要使用一种语言即可。

结合 MBSE 发展史可以发现，从 MBSE 启蒙期到上升期（1960 到 1970），专家和学者更加关注的工业需求是如何将代码及系统采用模型化手段表达支持重用等。直到MBSE 发展期（1980 到 2010），随着 OMG 及 INCOSE 逐渐确定了图形化规范，各种方法及工具百花齐放，MBSE 开始在企业中初步应用，但是在应用过程中发现图形化的问题。在 2010 到 2030 甚至更远，采用语义化建模手段实现生命周期的模型集成，使现有MBSE 真正落地。

关注「迪捷软件」公众号，后台回复「MBSE」，查看完整报告。