摘要

基于模型的系统工程（Model-Based Systems Engineering，MBSE）及其应用是近年来的研究热点。实践MBSE需要建模语言、建模方法和建模工具，建模的目的是为了更好的理解（沟通）和管理复杂性，其核心是模型，元模型是创建模型的构建元素。本文首先对架构和框架进行了辨析和定义，再辨析了模型和元模型两个紧密联系的概念，指出明确元模型的定义、存储和实现是建模的重要前提，并结合相关探索和应用实践阐述了理解此概念在基于模型的系统工程领域的诸多优势。

引言

1978年9月，钱学森在《文汇报》发表《组织管理的技术-系统工程》，文中结合系统工程在中国的工程实践，形成了具有中国特色的系统工程思想，这种思想指导了中国多种行业的发展。此时的系统工程还是一种基于文本的系统工程（Text-Based Systems Engineering ,TSE）,在航天和国防科技等领域，系统架构构建过程中的需求规格、功能指标要求、接口规范要求都是通过各种文档描述管理的，在这些文档的编撰和管理过程中需要耗费大量的人力物力。并且由于文件中语言的局限性，在传递和辨识上很难保持一致，加大工作的开发周期和成本。[1-4]

2007年国际系统工程学会（International Council of Systems Engineering，INCOSE）提出了基于模型的系统工程（Model-Based Systems Engineering，MBSE），这是将系统工程通过模型驱动形成的一种新方法，国外甚至把此方法视作“系统工程的革命与未来”。近些年，基于模型的系统工程在国内的发展越来越火热，包括航天航空、兵器、电子、船舶等军工行业以及政府、新能源等相关行业都在积极探索MBSE的研究应用，同时一些科研院校和民营企业积极开发国产建模工具。

概念辨析

1 架构

架构翻译自英文单词Architecture，在没有限定词和上下文语境的支持下，很难对其描述的领域进行界定，比如美国国防部体系架构框架DoDAF中的Architecture指的是体系架构，而到了HLA标准中，这里的Architecture指的却是仿真架构。架构代表着人们对目标对象的设计过程的抽象思考的结果，来自不同领域的人在谈论架构本身时，还是应该结合特定的领域和所研究的目标对象，才不至于引起沟通障碍，比如体系架构、系统架构亦或软件架构。

架构总是和系统或者体系（系统之系统）联系起来，而这个系统或体系，通常会是人工复杂系统。一个简单系统比如一个二极管是不需要做复杂功能架构设计工作才能完成生产；相反，也不能要求一个人靠某一类架构模型就能完成如飞机的复杂系统的设计工作。架构和目标对象的涉众相关，反应的是所有涉众在同一个抽象层次上的统一的解决方案。那么在此，我们就需要给架构一个明确的定义。

我们可以先看看美国国防部体系架构框架标准中对架构的描述：“一组用于简化和沟通复杂结构、流程、规则和约束的抽象概念和模型，以达到提升理解、促进实施、改善预测和优化资源的目的。”虽然该标准（实际上来自DoDAF1.X标准，在DoDAF2.0标准中取消了这一描述）给出了一个简短定义，但它并没有真正告诉我们描述架构所需的信息。[5]事实上，DoDAF这一概念本身就已经远远超出了这个简单定义的范畴。

在《系统架构的艺术》一书中，Maier和Rechtin将架构定义为“产品、流程或元素的结构——从组件、连接和约束的角度来看”。这个定义开始定义描述架构所需的参数（组件、连接和约束）。它还为如何开发好的架构提供了一些“经验法则”。架构不仅仅是一门工程学科，同时也是一种艺术形式。

基于以上的概念进行综合，在这里提出一个基于自身理解的定义——架构：由组成元素、信息、接口、流程、约束和行为构成的一种基本的、统一的集合。这个集合表达了目标对象A之所以为A的原理以及其运行机理。

这个定义意味着我们需要一些基本元素（或维度）来描述架构，包括风险、问题/决策、输入、输出、资源（系统、组件、组织）、行动（任务、功能、活动）、声明（要求、约束）以及特征（性能、属性）等。这些元素都影响着采购的决策过程，且这些元素在架构开发中与系统工程很类似，他们都需要技术和管理方面的内容。

除基本元素外，我们也需要一种统一的结构。统一结构指的是元素之间的关系。例如，“行动”由“资源”执行。这些关系还为同一类中的元素建立了上下文联系（例如，资源可能会被分解为许多其他资源）。通过这种方式，无需创建长名称就可以显示出元素的上下文联系。在以数据为中心的世界中，各个元素之间的明确关系至关重要。

架构和结构有明显区别。通常，结构翻译自英文单词structure，它仅仅指的是元素间的组成关系，但对于描述系统的运行机理而言，显然单纯的结构不能满足。行为是指架构的工作方式，通常表现为执行的功能、功能的执行顺序、调用关系、使用的资源以及交互的信息等等，行为可以反映整体系统的性能。作为架构师，我们希望尽可能多地控制架构中捕获的系统行为，而不是“紧急”或不可预测的行为。

2 框架

如果说架构由各类组成要素、信息、接口、流程、约束和行为等元素构成，那么架构的设计就需要考虑至少两方面的内容：

1) 这些元素的设计过程如何推进；
2) 这些元素的存储该如何组织。

由于涉众的角色和专业限制，架构对于每一个涉众所展示出的剖面和行为都不一致，因此设计过程需要按照自顶向下或者自底向上的规范方式和流程进行。无论选择哪种方式，都需要“一步一步”地从无到有，渐进明细，将架构表达出来；另外，在“每一步上”，具体要设计哪些要素，这些设计要素的设计输入是什么、设计过程是什么、结果怎么存储等等问题，也需要相对完善的表达方式。因此，描述和讨论架构，就需要针对各类涉众，同时兼顾复杂性处理，采用合理的描述手段。这个手段，就是框架。

框架由不同视角和每个视角的不同视图组成，这些视角和视图就是用来表达或者组成，或者交互或者行为的。框架不等于架构，它是人们当前认知下的一种相对完整的表达。随着人们认识的加深和表达业务的变迁，架构会变化和升级，但这种升级都是因为人们对目标对象的架构设计需求理解越来越深入了。

比如体系架构框架从C4ISR到DoDAF1.X再到如今的UAF，框架在不断完善，可能对某个防空反导体系架构的描述越来越好；再比如IBM的HarmonySE、达索的Magicgrid、泰勒斯的Arcadia以及ViTech各家公司的方法论，都是不同的框架杂合了一些建模流程在里面，他们都可以对同一个对象，比如某复杂嵌入式系统的架构进行描述。[6-9]这些方法建出的架构模型，每一个都有各自的特点，但都是通用的领域框架，对于航天乃至具体的武器系统设计领域，需要进一步扩展和定义。

3 语言的二义性

“系统正在做材料研发”，当文档出现这样的句子时，不同的领域专家看到会有不同的理解：“正在为系统的构建做材料研发”、“系统根据特定程序正在做材料研发”；由此可以看出基于文档的系统工程不仅仅会耗费更大的人力物力，表达也具有一定的二义性。而MBSE则是利用数字化手段通过构建模型的方式来代替文档编撰进行系统方案设计，把设计文档中各种信息转化为数字化模型表达。

4 模型

模型的定义方式很多，其中典型的分别来自综合定义方法的类比定义和美国国防部的数据模板定义：
综合定义方法IDEF（Integration Definition Method，IDEF）对模型的定义是：“不管以何种形式，只要 M 能回答有关实际对象 A 的所要研究的问题，就可以说 M 是 A 的模型”。[10]这个定义强调模型是不限于形式的，可以是数据，可以是数学公式，可以是图形，还可以是物理实体。例如用实心金属制作的飞机风洞模型就是物理实体模型。

美国国防部在其体系结构框架DoDAF(Department of Defense Architecture Framework，DoDAF)标准中对模型的定义表述为：“模型作为一种模板，以易于理解的格式来组织和显示数据”。并进一步定义：“当以此方式来收集和呈现数据的时候，其结果就称为视图”。[11]按此定义内容，可以将视图理解为数据实例。

目前这两种定义方式被已被国内外众多学者广泛认可和接受。尽管作为模板的“模型”与作为数据实例的“模型”同样被称为“模型”，其内涵却不完全相同，比如基于SysML语言和特定的HarmonySE系统架构框架构建的武器系统功能架构模型显然是针对真实武器系统的业务表达，符合IDEF的定义，然而在DoDAF2.0标准中，基于该框架构建出来的一个野战防空体系架构工程按照美国国防部DoDAF标准的定义，却不能叫模型，而称其为一个体系架构实例或者体系架构应用。

其实这种看起来存在的混淆本身并不矛盾。其问题的根源在于“研究对象”发生了变化——基于SysML的武器系统模型，其研究对象是武器系统本身，而美国国防部的定义，其研究对象不是一个具体的体系架构应用或者体系作战解决方案，而是构建军用体系的全部设计要素、术语以及它们之间的关系。而且美国国防部的这种模型定义，也是有转变过程的，在DoDAF2.0标准中强调的从以产品为中心到以数据为中心，其本质就是研究目标的转换，以产品为中心，就是把具体的体系应用或者体系解决方案定义为模型，以数据为中心，就是把体系论证领域能够使用的通用的业务数据作为模型。

正如以上两种对模型的阐述，作为模板的“模型”与作为数据实体的“模型”有不同的定义；因此基于SysML语言和工具构建出来的工程称为一个系统架构模型，基于UPDM（Unified Profile for DoDAF and MODAF，UPDM）配置文件和工具构建出来的工程称为一个体系架构模型。

IDEF对模型的定义与DoDAF对模型的定义相比，是更一般性的定义。那么就应该能推出，IDEF定义的模型是上位概念，DoDAF定义的模型是下位概念。即“回答问题说”的IDEF对模型定义是所有模型的共有特征，而“用模板组织显示数据”是DoDAF定义的模型的区别特征。也就是说，所有符合DoDAF定义的模型也都符合IDEF定义。

以上是模型的基础概念。谈论模型之前，必须先确定目标对象，不然容易造成概念混淆。而元模型作为构建模型的基础要素，其本身也是一个相对的概念，谈论元模型，也需要明确地指出，是哪个模型的元模型。

5 元模型

元建模理论是从80年代后期发展起来的，最早由电子工业协会EIA（Electronics Industry Association，EIA）定义了CIDF（CASE Data Interchange Format，CIDF）元元模型。后期为了实现不同的目的，不同协会针对其所在的领域又定义了很多元元模型和元模型,如对象管理组织OMG（Object Management Group，OMG）定义的MOF（Meta Object Facility，MOF）元元模型等，这些元元模型的建立都是以经典的四层元模型架构为基础的。采用元模型的各类架构框架对于对应领域解决了产品数据一致性与信息共享问题。

四层元模型架构是OMG组织指定的UML的语言体系。这种架构是精确定义一种复杂模型语义的基础。它的特点是，通过递归地将语义应用到不同层次上，完成语义结构的定义，为UML的元模型扩展提供架构基础。四层的划分如下：

1）信息层（information layer）

这一层也叫应用层，其主体（信息）是由用户希望描述的数据组成，通常是一些用户数据(user data)，主要职责是描述和表达用户的业务。

2）模型层（model layer）

模型层是由元模型组成，元模型是描述信息层的基础概念数据，元模型的集合被称作为模型。由模型概念的的辨析得知，在讨论模型时，必须先确定目标对象。

模型层是为描述信息层而定义的一种“抽象语言”（类似于C语言的语法和语义）。信息层的数据，即用户数据，是模型层的一个实例，对应着模型层的某一个数据类型。

3）元模型层（meta-model layer）

元模型层是由元元模型组成，元元模型定义了元模型的结构和语义，元元模型的集合被称为元模型。元模型层对模型层的进一步抽象，是为描述模型层而定义的一种“抽象语言”。模型是元模型的实例，模型层描述的内容通常要比元模型层描述的内容丰富、详细。

4）元元模型层（meta-meta-model layer）

元元模型层是由元元模型的结构和语义的描述组成，是为了描述元模型而定义的一种“抽象语言”。元模型是元元模型的实例，元元模型的定义要比元模型更加抽象、简洁。一个元元模型可以定义多个元模型，而每个元模型也可以与多个元元模型相关联。通常所说的相关联的元模型和元元模型共享同一个设计原理和构造，这也不是绝对的准则。每一层都需要维护自己设计的完整性。

按照四层OMG元模型概念来说，在DoDAF2.0标准中的模型概念与之是完全对应的，但这种对应也仅在DoDAF2.0以及其后的标准中，因为元模型是一个相对的概念，谈元模型，首先要明确模型是谁，而谈模型，又要确定目标对象。

6 视点、视角与视图

视图的英文单词是view，这个概念最早来自IDEF方法和系统结构分析理论，可以认为是框架的组成部分。视图描述的是系统的静态或者动态侧面。以功能架构为例（无论是体系级的还是系统级的功能架构），在这个分类中，有以下几种视图：活动图、交互图（包括时序图、通信图、概况图和时间图）、用例图和状态机图。

在DoDAF2.0标准之前，美国国防部的体系架构框架还处于“以产品为中心”的年代，那时候描述不同业务的视图被架构框架组织在一起，形成一组“Views”，比如Operational Views、System Views以及Technical Views等。当时国内的同行业专家将“Views”翻译成视角，用于指明这些视图描述的都是架构方案的同一个角度，这恰恰超出了“Views”的内涵，因为“Views”这个词仅仅是“View”的复数形式，它即没有体现观察角度的问题，也没表达这组视图间是有关系的。可以说，当时国内的翻译比DoDAF框架标准本身的定义，高明得多。

进入DoDAF2.0时代，人们逐渐认识到视角内的视图在表达业务上的统一性，以及视图间的相关性，便使用“ViewPoint”这个词取代之前的“Views”，并给它下了一个定义：该组织下的所有视图的共同规范。国内同行在区别于之前翻译版本的基础上，使用视点一词作为“ViewPoint”的中文释义。通过查证所有的关于视点和视角的中文定义，发现其起源都类似，在影视业的定义中稍显不同，但都是人们看待一类事情的角度。因此，上升到体系架构设计这种高维逻辑层面，可以不加区分。

结论

对基于模型的系统工程的模型和元模型要有全面、准确的理解，需要明确讨论的对象、模型具体定义的是那一类。在基于模型的系统工程的工程实践中，跨团队甚至跨领域的工程师可以根据自身业务需求选择适用的模型，在团队内明确了对象和模型这两个概念有很多好处，表现在以下几个方面：

1) 方便在一个架构方案内部与相关涉众沟通；
2) 方便跨架构进行更广泛的业务问题的交互；
3) 方便向下传递跨领域的数据、信息与设计需求。

参考文献：

[1] 钱学森．智慧的钥匙——钱学森论系统科学[M].上海：上海交通大学出版社，2000.
[2] 涂元季．钱学森书信（1-10）[M].北京：国防工业出版社，2006.
[3] 中国系统工程学会.2009-2010系统科学与系统工程学科发展报告[R].北京:中国科技术出版社，2010.
[4] 钱学森，许国志，王寿云．组织管理的技术——系统工程[N].文汇报，1978-09-27(01,04).
[5] DoD Architecture Framework Working Group. DoD architecture framework version 1.5，volume I,II,III[R] . Washington D.C. :DoD,2007.
[6] CAO L.C4ISR system[M].Beijing:National Defense Industry press,2012.
[7] Object Management Group. Unified Architecture Framework (UAF) Traceability between Framework Views and Elements: Version 1.0[S /OL].Object Management Group,(2017-07-15)[2019-09-27].
[8] Hoffmann, Hans-Peter, “Harmony-SE/ SysML Deskbook: Model-Based SystemsEngineering with Rhapsody,”Rev. 1.51, Telelogic/I-Logix white paper, Telelogic AB,May 24, 2006.
[9] Douglass, Bruce P.,“The Harmony Process,” I-Logix white paper, I-Logix, Inc., Mar.25, 2005.
[10] 陈禹六．IDEF建模分析和设计方法[M].北京:清华大学出版社, 1999: 4.
[11]DoD Architecture Framework Version 2.0 Volume 1[R/OL].2009:18.https://vdocuments.mx/dod-architecture-framework-version-20.html.