在系统工程初期阶段，系统产生的信息均以文档形式描述和记录。但是随着系统规模和复杂程度的不断提高，基于文档的系统工程面临的困难越来越突出，如信息表示不准确造成歧义、难以从海量文档中查找所需信息、无法与其他工程领域的设计相衔接（如软件、机械、电子等）。于是基于模型的系统工程（MBSE）应运而生，这也是未来系统工程发展的必然趋势。

MBSE基本概念

国际系统工程学会（International Council of Systems Engineering，INCOSE）在2007 年提出了基于模型的系统工程，它是系统工程领域发展的一种基于模型表达的方法。一方面，MBSE 通过标准系统建模语言构建需求模型、功能模型、架构模型，实现需求、功能到物理架构的分解和分配；另一方面，MBSE通过模型执行实现系统需求和功能逻辑的确认和验证，并驱动产品设计、实现、测试、综合、验证和确认环节。

MBSE的优势

相对基于文档的系统工程方法，MBSE的优势主要体现在以下 4个方面：（1）信息表达唯一性。系统模型具有直观、准确唯一、结构化的优点，可以准确统一地描述系统的各个方面，对整个系统内部的各个细节形成统一的理解。（2）一体化设计。系统模型提供了一个覆盖全生命周期的完整的、信息一致且可追溯的系统设计方案，避免各组成部分间的设计冲突，降低风险。（3）知识积累和沉淀。成熟型号的知识是以系统模型的形式表示和存储的，便于捕获、查询、理解和重用，而且重用的级别可以大幅度提高。（4）早期全系统仿真。利用系统建模语言及支持软件，可以建立动态可执行的系统模型，对系统模型进行全系统仿真、随时仿真和全周期仿真，及时发现设计的问题并加以修改。

MBSE 过程最终的输出是一个可重用的系统数据模型。MBSE的落地实施依赖于3个方面：建模语言、建模工具和方法论。

系统建模语言SysML

为了支持 MBSE，INCOSE 和对象管理组织（Object Management Group，OMG）联合提出一种通用的针对系统工程应用的“标准系统建模语言”SysML（Systems Modeling Language），它可以支持系统工程应用的多领域系统，包含硬件、软件、信息等系统的需求分析、系统设计、功能描述及系统验证等。

建模工具

建模工具是利用SysML实现MBSE的关键，业界主流建模工具包括Rhapsody、CORE等，建模工具厂商结合各自对MBSE的不同理解，开发出各具特色的建模工具。

IBM Rational Rhapsody产品系列是一个协作设计和开发环境，以分析需求、在开发生命周期的早期优化设计决策和验证功能、执行设计复审并实现高质量创新产品的自动交付；Modelio是由法国Modeliosoft公司开发的一款提供分析、设计和开发环境的建模工具，其开发环境可以整合到整个产品开发生命周期中并帮助管理复杂性；CORE是Vitech公司为实现其系统建模方法论的建模工具，以需求分析、功能/行为分析、架构综合、设计确认和验证这 4 个系统工程活动为基础，注重实用性；Enterprise Architect是Sparx Systems公司开发的产品，覆盖了系统开发的整个周期，可以进行用例分析、场景分析、状态与模式分析，支持双向工程（RoundTrip-Engineering）。

各主要建模软件对比见表1，从工具应用情况可以看出航空航天行业国内以Rhapsody为主，国外以CORE为主。

表1  主要建模工具对比  

方法论

MBSE问世之后，国内外围绕这一思想核心在不同系统、不同建模背景下进行实践，总结出诸多具有国际影响的方法论，这些方法论规定了系统开发过程所包含的模型构建内容，以及各个阶段模型所产生的视图产品和模型视图的时序关系，规定了图形的使用、模型的组织结构等（图1）。

图1  MBSE实施的基本方法

面向对象的系统工程方法（object-oriented systems engineering, OOSEM）集成使用OMG SysML标准，包括分析定义系统需求、定义逻辑体系结构、合成候选分配架构、优化和评估可选方案、验证和确认系统等开发活动；Harmony-SE采用了“服务请求驱动”的系统建模方法，使用 SysML 建模标准，利用 SysML 结构视图中的block作为描述系统结构的基本单元，利用活动图、状态图、序列图描述系统结构组成部分的行为；Vitech MBSE 方法采用MBSE 的系统定义语言（system definition language，SDL）管理模型产品；state analysis以目标为导向的闭环运转，是时间区间上状态变量的约束。

国外在MBSE的方法及应用方面开展了广泛研究与实践：空客公司在A350系列飞机的开发中全面采用MBSE，在飞机研制中逐层细化需求并进行功能分析和设计综合；洛克希德·马丁公司采用MBSE统一进行需求管理和系统架构模型，并向后延伸到机械、电子设备以及软件等的设计与分析之中；罗·罗公司依据 INCOSE系统工程手册制定了其自身的系统工程能力框架，实现了从航空动力系统到子系统到部件的系统工程迭代；波音公司构建了以任务和需求定义、逻辑和功能集成、功能和逻辑架构设计为核心的、覆盖产品全生命周期的MBSE过程，从运行概念到需求到设计到生产。

近年来，中国航空航天领域也开展了MBSE的应用研究，中航工业西安航空计算研究所利用基于模型的系统工程需求分析、功能分析、架构设计方法在某型动力电子控制系统设计中得到了初步应用；中国空间技术研究院载人航天总体部将 MBSE方法应用于载人飞船交会对接任务中，提高了设计效率、改善了人员沟通、进一步降低了设计风险；中航工业飞行自动控制研究所对MBSE流程进行了结构化定义，明确了系统工程活动、输入输出及相应的岗位角色，并在飞控、惯导等复杂系统开发过程中进行了 MBSE方法论与工具的实践；中航工业第一飞机设计研究院采用 Rational DOORS进行需求管理，并按照 Harmony-SE 流程，采用Rhapsody工具完成空中交通防撞系统以及航电系统的系统分析、设计与建模。   

一般地，航空发动机3个主要用例场景分别为发动机装配、运行和维护，如图2所示。其中，装配场景包括发动机制造组装、物料清单（BOM）跟踪确认、运输、接收等子场景；运行场景包括发动机起动、运行、停车、在翼运行、试车台运行等子场景；维护场景包括发动机健康数据分析、维修和替换组件、上载全权数字电子发动机操给机构（FADEC）数据等子场景。

图2  航空发动机全生命周期功能场景分解   

本文主要聚焦航空发动机地面起动场景，将MBSE应用于航空发动机控制设计过程。采用SysML语言，在Rhapsody软件上进行航空发动机控制设计的功能分析和系统建模，从而探索适合航空发动机功能建模的解决方案。

航空发动机地面起动过程包含起动机运转、点火、供油、关闭点火、进入慢车等主活动及起动故障处理等其他活动。通过用例图、活动图、时序图、状态机图等模型对地面起动过程进行建模分析，发现并完善了自然语言在起动控制逻辑描述方面存在的不足。最后利用状态机进行了发动机地面起动模型仿真，对地面起动控制逻辑进行了验证。

在利用活动图梳理发动机地面起动功能流过程中，发现使用自然语言描述复杂系统时存在以下 2 类问题。

1）文字表述存在二义性。例如，发动机起动时间的描述“发动机应在 t时间内完成起动”存在歧义。对于“发动机应在 t时间内完成起动”的理解，设计方案想要描述的是“起动机带转发动机的起动时间最长为t，否则需要关闭起动机”；设计人员的理解为“若发动机起动时间超过 t，则需要终止发动机起动全过程”，两者存在理解分歧。

2）存在功能逻辑缺失。例如，方案中描述“当高压相对物理转速达到一定速度时，开始供油”，若高压相对物理转速未达到限定速度，发动机需要进行的动作和所处状态未明确。

通常，使用类似 Visio的图形设计工具辅助描述设计信息。然而，由于缺乏统一的语义规范和信息关联机制，无法对活动流程中的并行、引用、延时等特殊状态进行准确唯一的描述，这类图形信息就相当于图形化的自然语言。在描述发动机起动时间控制逻辑中，设计人员会用一个框图表示，如图3红框所示。如果想要描述更加详细的控制逻辑，只能用更加复杂的活动流图代替之前的框图，从而导致整个活动流缺乏层级，逻辑混乱。如此一来，既不利于设计人员理解设计方案，也会造成不同人员的理解偏差，带来信息二义性。   

图3  航空发动机起动时间控制Visio

在MBSE方法论中，通过SysML中的标准模型元素来准确表达设计信息，得到如图4所示的发动机起动时间的活动图，其中红色区域表示发动机正常起动的活动流，黑色区域表示同时进行的发动机起动时间控制活动流。其中黑色区域所表示的活动流采用子活动图的方式表达，子活动图的具体信息如图5所示。   

图4  航空发动机起动时间控制活动

图5  航空发动机起动时间控制子活动

SysML模型中的时序图是根据活动图所描述的行为逻辑，建立多个对象之间的动态协作和行为顺序关系以及不同对象之间的消息传递，明确了起动过程中的系统与外部角色之间的交互关系，从而确定系统与外部的接口和端口关系。

状态机通过分析和确认每个对象所经历的状态序列、在特定状态下的行为、引起状态转移的条件、因状态转移而伴随的动作、以及对异常做出的响应等内容，确立系统在其生命周期内的完整动态行为。发动机地面起动过程主要包含以下状态：等待驾驶舱指令状态、起动状态、故障处理状态、慢车状态和关闭起动状态。根据不同的判断条件和触发事件，发动机处于其中某一个状态，并且可以在不同状态之间进行切换。

Rhapsody提供了通过界面交互方式执行状态机的模式，通过给定的 Web界面，可以通过参数注入的方式输入测试用例，实现不同场景、不同状态之间的仿真测试，从而验证功能逻辑完备性和需求满足性。

通过传递参数，状态机图实现了地面正常起动、起动超温、余热超限、滑油压力低等10余种测试用例的仿真测试。以滑油压力低为例，表2列出发动机地面起动过程发生滑油压力低时的参数注入信息，当对状态机注入以下参数时，发动机进入地面起动滑油压力低故障处理状态，验证了故障处理控制逻辑的正确性，如图6所示。

表2  航空发动机地面起动滑油压力低测试用例参数

图6  航空发动机地面起动滑油压力低状态机仿真

由于 SysML 语言来源于 UML 语言，擅长对离散事件驱动的系统，即发动机控制功能逻辑描述和仿真，但对于真实连续运行的物理系统的描述仍存在局限性，有待进一步的研究。

从系统建模语言、建模工具和方法论 3个方面详细介绍了基于模型的系统工程相关理论知识，并且通过不同角度对不同方法、工具进行了对比，为寻找适合航空发动机功能建模的解决方案进行了初步探索。在航空发动机控制设计起动场景功能建模实践中，选用Rhapsody 建模工具，基于 Harmony-SE 方法论开展 SysML 建模，详细描述了利用活动图、时序图描述复杂系统交互活动的过程，解决了自然语言无法描述复杂活动的问题；利用状态机图通过参数注入方式进行起动功能逻辑的仿真和验证，为后续航空发动机全系统建模和功能逻辑仿真提供了解决思路。

在未来的研究中，将继续在航空发动机控制设计或者其他子系统设计开发中探索和实践MBSE方法，制定统一的建模标准与模型管理规范，形成企业自主的MBSE流程和工程手册。另外，尝试将MBSE向航空发动机整机建模仿真推广，从而实现系统级的仿真验证和综合优化，为早期的设计方案测试和验证提供技术支持。

MBSE 通过构建以模型为中心的可追溯信息集成框架，利用模型的不断迭代贯穿整个产品研发和后续生命周期全过程。然而现阶段 MBSE在建模标准规范统一、建模方法的推广和应用、上下游模型的数据传递、模型与仿真分析工具的集成等方面还有待进一步的提升和发展。可以预见，随着 MBSE工程成熟度的不断提升和应用领域的不断扩大和深入，MBSE将会形成一套体系完备的开发流程和标准，为复杂产品的正向设计提供强大的平台支撑。