原创：
何强，刘喜莹
科技导报
3天前
基于模型的系统工程（MBSE）是应对系统复杂性和创新设计的一种工程范式变革，是改变CPS设计生产力的一项关键技术。MBSE的应用已经成为在复杂工程领域的重要发展趋势，推进MBSE在中国工程领域的应用是当前的关键任务。但是，MBSE的基础仍是系统工程，不能为了模型而模型，否则将很难发挥MBSE的优势。只有具备扎实的系统工程基础，MBSE实践应用才能事半功倍。
2006
年
10
月，系统工程国际委员会（
INCOSE
）在《
Systems Engineering Vision 2020
》中正式提出“基于模型的系统工程”（
model-based systems engineering
，
MBSE
）概念。
MBSE
使用建模方法支持系统的需求定义、设计定义、分析、验证和确认等活动，这些活动从概念性设计阶段开始，持续贯穿到设计开发以及后来所有的寿命周期阶段。
2012
年，从中航工业与
IBM
开展合作引入
Harmony SE
方法论开始，不同行业的企业开始学习、试点应用
MBSE
，掀起了一股学习系统工程、学习
MBSE
的热潮。这一波热潮的到来，让很多系统工程前辈非常欣喜，认为系统工程的第
2
个春天已经来临。
2017
年
9
月
9
日，军事科学院调整组建
8
个研究院，其中系统工程研究院是
8
个新建研究院之一，各大军工集团与行业纷纷成立各自的系统工程研究机构，各军兵种也相继成立各自的系统工程研究院所，很多知名高校开设了系统工程课程，由此可见各行各业对于系统工程的重视。
然而，在系统工程与
MBSE
的应用推进与实践过程中发现，很多企业对系统工程与
MBSE
的认识存在一些问题，在工程实践中的应用情况也不理想。不管怎样，基于模型的系统工程还是系统工程的范畴，基于模型只是相对于传统的基于文档方式的一种新范式。因此，
MBSE
仍然以系统工程作为基础，同时，
MBSE
作为系统工程新范式，也具有很多新的特征。
不论是基于模型的系统工程（
MBSE
）还是传统的基于文档的系统工程，都是系统工程，是不同的系统工程范式。从国外的应用实践来看，传统的基于文档的系统工程应用基础非常扎实，并在扎实的系统基础上进行了基于模型的范式升级。
20
世纪
80
年代，“星球大战计划”使得当时美国的许多国防军工企业空前繁荣，急需大批具有系统工程思维、技能和经验的工程与管理人员，小规模的培养并不能满足国防军工企业的实际需要，因此
1990
年在西雅图会议上决定成立美国国家系统工程协会（
NCOSE
）。
NCOSE
是国际系统工程协会（
INCOSE
）的前身。可见，
INCOSE
成立的最大动力就是美国国防军工企业的实际需求。而编制《系统工程手册》并在此基础上建立“认证系统工程师”是
INCOSE
满足国防军工企业需求的重要手段。《系统工程手册》目前已被许多国家广泛采用，在确保工程质量和成本方面发挥了有效的作用，并正从国防军工行业走向一般民用企业的工程管理活动。基于需求的工程（
requirements-based engineering
，
RBE
）是空客系统工程的核心流程。
RBE
源于
20
世纪
60
年代早期的美国军方，在空客公司被深入应用，是其系统工程过程的核心，贯穿于空客飞机项目的全寿命周期。
RBE
的重点是确保规范是基于用户需求而不是技术需求，目的是提供一个系统工程方法，使得被定义的要求与用户需求完全一致。空客公司从
1996
年甚至更早的时间开始推进系统工程应用，先后在
A380
、
A350
、
A400
等多个机型中全面推进应用（图
1
）。
图1 系统工程在空客的应用
西方国家很早就开始开展系统工程应用，积累了扎实的系统工程基础。因此，
INCOSE
在
2006
年
10
月正式提出
MBSE
概念，是在传统的系统工程应用基础之上进行的系统工程应用范式的升级。无论传统的基于文档的系统工程（
TSE
）还是基于模型的系统工程（
MBSE
），都是系统工程（
SE
）的范畴，系统工程的基础不扎实，传统的基于文档的系统工程做不好，
MBSE
应用就更加困难。
打好系统工程的基础，需要从认识并理解系统工程的内涵，理解需求，理解并在实践中应用系统工程流程，掌握对应的各种基础的工具、技术与方法开始。
系统工程的内涵
根据
INCOSE
系统工程手册对系统工程的描述，系统工程首先是一种思考问题的视角——用系统思维去考虑问题，系统思维要求既要考虑整体，又考虑局部构成与相互关系，还要考虑系统与环境之间的交互。其次，系统工程又是一套解决问题、工程实现的流程。系统工程不能仅仅停留在思考或者哲学层面，还必须回归工程，考虑实现。因此必须有一套实现系统对象的流程来支撑。最后，系统工程是一个学科。系统工程需要一系列能力支撑，能力的获得需要通过一系列的学习与培训，掌握相关的能力，建设各种使能的文化氛围与制度。
系统思维注重从整体出发考虑问题，避免片面和近视的局部思维方式，加强顶层设计和整体谋划；同时处理好方方面面的关系，解决好各项措施之间的关联性和耦合性。“系统思维”是“系统工程”的思想基础。
系统思维、系统工程流程、系统工程能力培养三者是一个有机的整体，决不能孤立地去看待。在实践中，需要从系统工程内涵的
3
个方面出发去推进与应用，既不能把系统思维从整个系统工程割裂，更不能只注重系统思维培养而忽略系统工程流程与能力建设。前一种情况会让系统工程缺乏灵魂显得特别僵化；而后一种情况尤为突出，不少人以为具备了一些朴素的系统思维后就等于掌握了系统工程。二者是不能划等号的，这种情况会让人觉得系统工程在工程实践中很难落地，对应用与推进系统工程非常不利。
需求是基础，流程是抓手
系统工程是
MBSE
的基础，那么系统工程的基础又是什么？系统思维作为系统工程的思想基础，是系统工程的灵魂，系统工程流程是解决问题、工程实现的抓手，需求是系统工程的主线，贯穿系统整个生命周期过程。早期的
EIA 632
标准将工程化一个系统对象定义为
13
个流程
33
个需求贯穿整个生命周期（图
2
）。
图 2 工程化一个系统的需求（图片来源：EIA632:1998）
需求是系统工程的基础，是因为需求首先定义系统的目标，确定正确的方向，让我们做正确的事。错误的或者不好的需求会对系统整个生命周期造成多米诺骨牌效应，需求遗漏、缺陷或者错误将在系统生命周期的后期阶段被不断地放大，导致系统功能点遗漏、设计遗漏并最终导致返工。
系统生命周期过程集成、价值链集成、端到端的集成，准确地说这
3
个维度的技术主线集成都是通过需求来完成的。需求贯穿产品生命周期所有阶段，所有问题的提出与解决都是基于需求来展开，上下层级之间需求的关联形成需求主线，需求主线在系统研制不同环节间不断地按照“问题
-
解”的递归过程中形成系统从概念到设计、从设计到制造、从制造到运行维护的技术主线。同样，用户与主承包商（
OEM
厂商），主承包商与成品供应商，成品供应商与材料供应商之间，都是通过需求实现技术主线的集成。
用好系统工程依赖于能力体系
系统工程的应用相当复杂，正如系统思维、流程与学科三方面需要有机整合，用系统思维考虑问题有一系列方法、逻辑以及相关的系统科学支撑，每一个工程实现流程中又对应着非常丰富的工具、技术与相关的方法，掌握并应用这些工具、技术与方法来支撑每一项系统工程活动的开展，需要结合企业的业务与组织架构建立一套不断完善的系统工程能力体系，这需要一个相当漫长的过程。图
3
是基于
INCOSE
系统工程能力体系的系统工程能力域模型。
图3 系统工程能力域模型
系统工程能力是面向组织和岗位的能力，不同于
CMMI
（
capability maturity model integration
）是面向组织的能力。因此，系统工程能力模型既要将系统工程流程与组织的业务流程相融合，又需要根据不同岗位的职业需要，形成不同能力等级、不同能力需求的能力模型与能力矩阵。通过能力矩阵建立岗位能力点，以及对应的流程、实践工具、技术与方法。
系统工程能力体系的建设过程比较漫长，国外对于系统工程能力的研究也不是很成熟，
INCOSE
、
INCOSE UK
、
NASA
、
MITRE
公司等对此有比较深入的研究。
Rolls-Royce
公司从
2000
年开始全面推行系统工程的应用，通过持续不断的建设，逐渐将系统工程能力作为公司的重要组成部分，要求每一个项目的每一个角色都必须就有相应的系统工程技能。在中国，有学者基于
CMMI
的方式研究系统工程能力。系统工程能力与
CMMI
有区别，至少不能涵盖系统工程能力的全部。可喜的是，已经有个别的企业和研究院在开展系统工程能力体系建设方面研究并付诸实施。但是一定要有充分的认识，系统工程能力体系建设绝不是一蹴而就的，需要持续的投入。
系统工程流程是一个整体
在
ISO/IEC/IEEE 15288:2015
软件和系统生命周期流程中定义了
30
个流程（图
4
），这
30
个流程被分为
4
个流程组，即技术流程组、技术管理流程组、组织的项目使能流程组及协议流程组。
图4 ISO/IEC/IEEE 15288系统生命周期流程
系统工程的流程是一个整体，不能只重视技术流程、技术管理流程而忽视其他流程，必须与组织的项目使能流程、协议流程一起形成一个完整的整体。工程实践中，大多数人把主要的精力放在技术流程和技术管理流程上，这两类流程固然重要，
NASA
甚至称其为系统工程引擎，但是协议流程是这个“引擎”的输入，而组织的项目使能流程一旦缺失，将使其不能。这也是这些年在企业中推进系统工程与
MBSE
不见成效的原因之一，因为缺乏组织对推进与应用系统工程的使能支撑，系统工程的应用很难落地并见到成效。其中，生命周期模型管理流程、质量管理流程、知识管理流程是比较关键的使能流程。只有把技术流程和技术管理流程同使能流程中的生命周期模型管理流程结合起来，也就是把技术流程与技术管理流程同企业的研发流程、生产制造流程等业务流程结合在一起，并同时与质量管理、知识管理进行整合，系统工程才能得到比较有效的应用与落地。
从工程实践应用看，系统工程应用需要同企业的业务流程相结合，同时还需要基于企业自身业务形成可以指导工程实践的各种程序文件，明确各种规则、约束、规范并提供相应的知识。例如，系统工程的“业务或使命分析流程”与论证阶段之间是什么关系？流程中的活动、交付物与论证报告之间有没有关系，若有关系则是什么关系？很多人可能都遇到过类似的问题，如果不搞清楚这些问题，系统工程想要在实际的型号中推广应用是很有难度的。
图
5
显示了
NASA
飞行和地面系统的系统工程流程。
NASA
将技术流程、技术管理流程与生命周期模型紧密融合，并形成了非常完善的
NASA
程序需求（
NASA procedural requirements
，
NPR
）来指导实践，通过
NPR
程序文件实现质量管理、知识管理等使能流程与技术流程和技术管理流程的融合。整个过程中，设置了
20
个检查节点，定义了
247
个检查项、
139
项成功准则（
NPR 7123.1A
）。此外，系统工程能力体系本身就是一个相当完善的知识体系，这些知识体系跟流程融合才能形成真正的系统工程能力。
图 5 NASA飞行和地面系统系统工程流程（图片来源：NASA系统工程手册）
需要强调的是，
MBSE
还是
SE
，只不过是将过去基于文档（
text-based
）的模式变革为一种基于模型（
model-based
）的新范式。既然还是系统工程，那么
MBSE
一定还是覆盖系统整个生命周期阶段。因此，不要片面地理解
MBSE
就是使用
SysML
语言描述系统行为逻辑与架构这一有限的过程。但不能简单地将
MBSE
理解为把文档换成模型，生命周期不同阶段各种模型的替换与堆积。模型的本质是“
The single source of truth
”。
MBSE
是以模型为中心的整合多领域模型的单一数据来源。
产品复杂性增加带来系统工程范式的变革
随着科学技术的不断创新和深入应用，现代各种产品系统与装备已由过去的比较单纯的“机械系统”发展为由“机械＋电子＋液压＋控制＋软件”组成的复杂系统（图
6
）；“软件定义”使得嵌入式软件、智能型嵌入式系统、智能系统等在复杂产品和系统中的比重迅速增长；移动互联网、物联网、大数据、机器互联突破了系统的传统边界，更多系统一起形成
SoS
；并进而形成赛博物理系统。
图 6 关系复杂性被隐藏
传统研制模式难以准确地预知复杂装备系统内各子系统之间的相互影响和作用，只能通过“样机—试验—缺陷—设计—样机—试验”的往复返工，导致系统研制周期不断拉长，成本超预算。因此，迫切需要研制思想、模式和方法的创新，以实现在更短的时间内、花更少的钱、做出更好的系统（图
7
）。
图7 系统工程应用范式变革
MBSE
将系统的表达由“以文档报告为中心”转变为“以模型为中心”，基于统一建模语言的一系列系统模型成为全生命期各阶段产品表达的“集线器”，可以被各学科、各角色研发人员和计算机所识别，为研发组织内的高效沟通和协同奠定了基础，并将传统系统工程的手工实施过渡到通过软件工具和平台来实施，通过软件工具和平台物化了相应的“方法”，使得系统工程“过程”可管理、可复现、可重用。
图
8
描述了
MBSE
新范式影响矩阵，
MBSE
具有以下
7
项使能能力：增加知识获取与完备性，增加模块化与可重用性，增加可追溯性，减少手动重建，增加自动化，减少建模工作，增加分析强度等。因而，
MBSE
可以产生缩短时间，减少成本，减少风险，增强理解，增加企业资产库，增加工件性能等影响。
图8 MBSE新范式带来的影响与价值
MBSE
是基于对系统行为的理解
在传统的基于文档的系统工程中，主要聚焦于各种规格说明书。规格结构本质上就是一个静态的功能结构模型，功能结构的分解主要借助于一些模板依赖于个人的经验完成，需要通过手工方式建立映射与关联，而且逻辑层面的功能和物理的设计是相互分离的。对于复杂的产品或者从来没有接触过的新生事物需要发挥创造性时，这种静态的功能结构描述几乎不能支撑产品的开发。目前，在很多企业几乎没有企业所开发产品的完整功能结构树，根本原因就是聚焦于规格说明书的传统方法不足以应对系统的复杂性与创新性要求。
MBSE
是基于理解系统行为的一种设计方法。这种方法借鉴了人在完成某一项任务的行为逻辑表达，将这种行为逻辑表达方法应用到系统对象的定义活动中，基于正式的语言来描述系统为了达成某项使命任务或目标，系统对象需要执行的行为活动、对应的时间序列，每一个时间序列上的交互要素、所处的状态描述等。这种方式提供了人们在定义复杂系统对象时一种结构化思考方法，同时提供了人们面对新事物的一种创新思维方法，通过定义系统对象新的行为模式或活动，开发系统对象全新的功能（图
9
）。
图9 从基于文档向基于模型转移
图
10
展示了使用
SysGraph Modeler
建模工具完成对导弹系统的行为建模的结果，通过活动图、时序图和状态图来描述导弹系统在初始段飞行、中段飞行以及末段飞行的行为。在此过程中，工程师可以通过增加导弹系统在飞行过程中对各种数据信息的收集、完成对战场态势的感知、计算分析做出合适的判断并执行等这样的系统行为定义，从而让导弹系统具备一定水平的人工智能。基于对导弹飞行行为的理解与合理的行为，创新与定义对导弹功能进行创新设计。
图10 基于对导弹飞行行为理解的建模（使用 SysGraph Modeler创建）
对系统行为的理解不仅限于应用在系统功能的定义，在系统的性能定义中同样需要基于对系统行为的理解和相关的机理来完成。系统的性能是对系统某项功能实现得多好的程度的描述。因此，系统的性能与实现该项功能的系统行为紧密关联，也就是说，每一项性能指标都是跟实现该项功能的具体活动场景对应的。例如，末端拦截系统的随动系统的性能指标，必须首先理解末端拦截系统在拦截威胁目标时的行为活动，从雷达发现目标（距离）、射击解算、随动调姿、射击等一系列行为，再结合威胁目标的速度、距离、威胁半径等数据，分析确定转向角速度等相关性能指标。
系统工程要求我们在开发新系统的过程中，必须要进行概念设计，尤其是对系统的运行概念要进行详细定义。但实践中，运行概念文档很少有企业写过或者写得不完整，对系统行为理解不完整，将会造成系统功能的遗漏。
MBSE
形成以系统模型为核心的整合模型
MBSE
不是单纯地使用
SysML
语言进行系统逻辑层面的行为逻辑与架构建模，更不是简单的模型堆积。模型包含了系统设计和规格说明，可以提供给生命周期随后的团队使用，所需的系统规格说明能够从模型中产生，完整并且一致。
当前，工程技术人员孤立地使用不同的数据源和模型来支持生命周期内的各种活动，工程实践中主要依赖于特定学科的模型，相互之间的沟通通过静态的分离的文档，依赖于对文档的解释。
MBSE
本质上是要形成以系统模型为核心的一个整合模型，基于这个整合的模型，提供给生命周期不同阶段、不同领域、不同学科的人唯一真实的数据模型，每一个阶段，每一个人所构建的模型，都是从不同的视角对同一个对象的描述，系统模型连接并提供了规划、需求、设计、分析、验证、确认、运营或维护一个系统的权威数据源。这个权威的数据源提供了该系统对象在赛博空间的完整信息（图
11
）。
图 11 以系统模型为中心的多领域模型整合
MBSE
是改变
CPS
设计生产力的关键技术
美国国防部先进计划研究局（
DARPA
）
2010
发起自适应运载器创建（
AVM
）项目组合，经过水陆两栖装甲车的验证项目后，在
2014
年上半年，
AVM
项目并入美国数字化制造和设计创新机构（
DMDII
），进入技术转化阶段。该项目致力于将复杂赛博物理系统的开发时间压缩到原来的
1/5
左右。基于模型与组件设计被公认为是从根本上改变
CPS
设计生产力的关键技术（图
12
）。
图 12 CPS架构
CPS
是新技术革命的中心对象，
CPS
的设计、描述、构建、实现与评价都带来很多挑战。一个核心的观点就是，在设计流中，通过产生抽象层次来管理设计的复杂性，从设计元入手，逐步实现基于模型的系统工程。“软件定义”隐含了一个前提，在更高层次理解系统，在抽象层面理解系统的行为。
CPS
的另一个“跨学科”挑战，需要以系统模型为核心，整合多领域模型形成“
The single source of truth
”。
美国宇航局
NASA
喷气推进实验室制定了
2009
—
2016 MBSE
应用发展战略，提出以模型为中心的集成架构（
NASA integrated model-centric architecture
，
NIMA
），开发、实施和运用一种技术和方法激励途径，帮助机构形成从以文档为中心迁移到以数据
/
模型为中心的能力和文化。目前已有超过
20
个开发任务全生命周期应用
MBSE
。在此基础上，
NASA
工程和安全中心（
